Closed code423n4 closed 2 years ago
disagree with severity: In an ideal world these will stay the same. If we want to change them it's due to needing to update the values immediately
disagree with severity: In an ideal world these will stay the same. If we want to change them it's due to needing to update the values immediately
The consensus is that this Timelock-related best practice finding is QA: https://github.com/code-423n4/org/issues/7
Lines of code
https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/LiquidityReserve.sol#L92 https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L167-L170 https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L217-L220 https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L226-L229 https://github.com/code-423n4/2022-06-yieldy/blob/524f3b83522125fb7d4677fa7a7e5ba5a2c0fe67/src/contracts/Staking.sol#L235-L238
Vulnerability details
Impact
The owner of the Yieldy contracts (according to the docs this is the ShapeShift DAO's multisig) can change critical parameters such as the liquidity reserve fee, epoch durations, warm-up periods, etc.
None of these setter functions emit events to record these changes on-chain for off-chain monitors/tools/interfaces to register the updates and react if necessary.
Neither of those setter functions uses timelocks to allow users to react in a timely manner.
Proof of Concept
LiquidityReserve.setFee
Staking.setAffiliateFee
Staking.setEpochDuration
Staking.setWarmUpPeriod
Staking.setCoolDownPeriod
Tools Used
Manual review
Recommended mitigation steps
Add timelocks to introduce time delays for critical parameter changes.