Conversation
For London hardfork. See this issue: sc-forks/solidity-coverage#652
bingen
changed the title
|
|
||
| function onSushiReward (uint256, address, address to, uint256 sushiAmount, uint256) onlyMCV2 override external { | ||
| // OHM rewards | ||
| uint256 ohmPendingReward = sushiAmount.mul(ohmRewardMultiplier) / REWARD_TOKEN_DIVISOR; |
There was a problem hiding this comment.
I noticed the OHM token uses 9-digit decimal precision:
https://etherscan.io/address/0x383518188c0c6d7730d91b2c03a03c837814a899#readContract
and SUSHI and LQTY use 18.
It seems here that ohmRewardMultiplier and lqtyRewardMultiplier variables are 18-digit decimal precision, and that's why they're divided by REWARD_TOKEN_DIVISOR.
Perhaps we can add comments to note that:
- These multiplier variables are 18-digit precision
- The value of
ohmRewardMultipliershould take into account the different decimal precision of SUSHI and OHM when it is set at construction.
e.g. if we wanted to reward 2 OHM per SUSHI, the raw value of ohmRewardMultiplier should be 2e9. Then when calculating the OHM pending reward, we'd get:
ohmPendingReward = sushiAmount * 2e9 / 1e18
= sushiAmount * 2 / 1e9
Which is equivalent to 2 OHM per SUSHI, given OHM's 9-digit precision.
Basically at deployment we just need to remember to pass an _ohmRewardMultiplier on the order of 1e9, and _lqtyRewardMultiplier should be on the order of 1e18.
I think tests don't catch this because the OZ ERC20.sol hardcodes decimals = 18.
- Use real sushi per block amount - Use 9 decimals for OHM
To remember to set up correct multipliers at deployment.
2 participants
No description provided.