You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On LiquidityGaugeV5, the add_reward function does not check that _distributor is not the zero address. This is important, because the gauge assumes reward tokens with a zero distributor are uninitialized (i.e. not added to the gauge).
A zero distributor means that deposit_reward_token will not be callable, nor can this situation be fixed using set_reward_distributor. Additionally, the admin would then be able to add the same reward token again to the gauge, since add_reward only checks for the current distributor to be unset.
This is not a security concern due to the following:
if the reward token is only added once, no rewards will be able to be issued for it, and the gauge will behave as if the distributor never sent any tokens
if the reward token is added multiple times, the internal accounting will not be broken since all reward tokens are fully processed before moving on to the next one (see e.g. _checkpoint_rewards)
This does result in extra gas being used by all users, and one (or more) of the 8 reward token slots being forever burned.
The proposed fix is to simply check that _distributor is not the zero address in add_reward. From what I've seen, this issue is not present just on the V5 gauge but also all past gauges. Care should be taken to not add a reward token with a zero distributor in these.
The text was updated successfully, but these errors were encountered:
On LiquidityGaugeV5, the
add_reward
function does not check that_distributor
is not the zero address. This is important, because the gauge assumes reward tokens with a zero distributor are uninitialized (i.e. not added to the gauge).A zero distributor means that
deposit_reward_token
will not be callable, nor can this situation be fixed usingset_reward_distributor
. Additionally, the admin would then be able to add the same reward token again to the gauge, sinceadd_reward
only checks for the current distributor to be unset.This is not a security concern due to the following:
_checkpoint_rewards
)This does result in extra gas being used by all users, and one (or more) of the 8 reward token slots being forever burned.
The proposed fix is to simply check that
_distributor
is not the zero address inadd_reward
. From what I've seen, this issue is not present just on the V5 gauge but also all past gauges. Care should be taken to not add a reward token with a zero distributor in these.The text was updated successfully, but these errors were encountered: