The StakingRewards contracts for liquidity mining need some minor enhancements.
Enhancements include:
\nLPTokenWrapperPausable and notPaused to stake() to prevent staking into deprecated poolsWhen providing liquidity to Balancer or Curve.fi and you stake your LP tokens in the Synthetix StakingRewards contract you will also be eligible for BAL and CRV Liquidity Mining rewards also and potentially other AMMs in the future.
This would include a recoverERC20 function that is accessible by the owner only, the protocolDAO and can recover any ERC20 except the staking and rewards tokens to protect the stakers that their LP tokens and their rewards tokens are not accessible by the owner. These additional LP rewards will then be distributed to the LP providers.
Synthetix often runs trials on Liquidity Mining. Right now the Rewards duration is 7 days hard coded. Allowing a configurable rewardsDuration means the sDAO can set the duration and supply the total duration rewards for the trial without having to send the rewards manually each week. i.e. the curve renBTC/sBTC/wBTC pool gets 10 BPT per week. Where the trial is 10 weeks we could have set the duration to 10 weeks and send all 100 BPT upfront and it will distribute for the full term of the trial.
When a trial is complete the contract can either be shut down or wired into the Synthetix Inflationary supply via the Rewards Distribution contract where the rewardsDuration can be set back to 7 days and automatically receive SNX weekly. Similar to current LP SNX rewards incentives.
The LPTokenWrapper added additional complexity to the code without adding any additional benefits. To simplify the code we propose to remove it.
The staking and rewards tokens were hard coded addresses in each contract. Now that there are many of these on MAINNET and deploying almost 1 a week, instead of having to edit the code directly it is prefered to send the staking and rewards tokens as arguments to the constructor on contract creation.
\nWhen a StakingRewards campaign has completed the contract needs to prevent anyone from staking into it. They won't accrue rewards and can cause blocking issues with inverse Synths that need to be rebalanced which need to be purged.\nAdding Pausable.sol and modifier notPaused to stake() will allow the admin to set paused to true preventing anyone from staking. SelfDestructible has not been implemented and given the amount of value in these contracts probably best not to implement.
There is a multiplication overflow that can occur inside the rewardPerToken function, on line 66:
\nlastTimeRewardApplicable().sub(lastUpdateTime).mul(rewardRate).mul(1e18).div(_totalSupply)\nAn overflow occurs whenever rewardRate >= 2^256 / (10^18 * (lastTimeRewardApplicable() - lastUpdateTime)).
This can happen when the updateReward modifier is invoked, which will cause the following functions to revert:
\nearnedstakewithdrawgetRewardexitnotifyRewardAmountThe reward rate is set inside notifyRewardAmount, if a value that is too large is provided to the function.\nOf particular note is that notifyRewardAmount is itself affected by this problem, which means that if the provided\nreward is incorrect, then the problem is unrecoverable.
The notifyRewardAmount transaction should be reverted if a value greater than 2^256 / 10^18 is provided.\nAs an additional safety mechanism, this value will be required to be no greater than the remaining\nbalance of the rewards token in the contract. This will both prevent the overflow, and also provide an additional check\nthat the reward rate is being set to a value in the appropriate range (for example, no extra/missing zeroes).
Specifically, this problem occurs when rewardRate is too high; it is set inside the notifyRewardAmount function on\nlines 114 and 118.
rewardRate = floor(reward / rewardsDuration) = (reward - k) / rewardsDuration\nfor some 0 <= k < rewardsDuration.
For the bug to occur, we need:
\n(reward - k) / rewardsDuration >= 2^256 / (10^18 * (lastTimeRewardApplicable - lastUpdateTime))\nreward >= rewardsDuration * 2^256 / (10^18 * (lastTimeRewardApplicable - lastUpdateTime)) + k\nHence, we can ensure the bug does not occur if we force:
\nreward < rewardsDuration * 2^256 / (10^18 * (lastTimeRewardApplicable - lastUpdateTime))\nSo we should constrain reward to be less than the minimum value of the RHS.
The smallest possible value of lastUpdateTime is the block timestamp when notifyRewardAmount was last called.\nThe largest possible value of lastTimeRewardApplicable is periodFinish,\nand periodFinish = notificationBlock.timestamp + rewardsDuration (line 121).\nPutting these together we have:
(lastTimeRewardApplicable - lastUpdateTime) <= rewardsDuration\nErgo, we need:
\nreward < rewardsDuration * 2^256 / (10^18 * rewardsDuration)\n\t = 2^256 / 10^18\nSo the problem will not emerge whenever we require
\n reward < uint(-1) / UNIT\nrecoverERC20 and setRewardsDuration that have onlyOwner modifiers.constructor to take _rewardsToken & _stakingToken as argumentsLPTokenWrapper contract. The original implementation to not include this.notifyRewardAmount transaction if the computer reward rate would pay out more than the balance of the contract over the reward period.Pausable.sol contract and add modifier notPaused to stake()notifyRewardAmount if reward is greater than the contract balancenotifyRewardAmount if reward plus any leftover from the previous period is greater than the contract balancenotifyRewardAmount if reward is equal to the contract balancePlease list all values configurable via SCCP under this implementation.
\nCopyright and related rights waived via CC0.
"}},"pageContext":{"id":"366928d5-9d06-52ef-919c-418efa521770","frontmatter__sip":68,"__params":{"frontmatter__sip":"68"}}},"staticQueryHashes":[]}