28729 - [SC - Insight] MINIMUM_DELAY uses incorrect value of days ins...
Submitted on Feb 25th 2024 at 09:04:26 UTC by @MrPotatoMagic for Boost | Puffer Finance
Report ID: #28729
Report type: Smart Contract
Report severity: Insight
Target: https://etherscan.io/address/0x3C28B7c7Ba1A1f55c9Ce66b263B33B204f2126eA#code
Impacts:
Contract fails to deliver promised returns, but doesn't lose value
Description
Brief/Intro
The Timelock.sol contract currently uses a MINIMUM_DELAY
constant value of 7 days. But according the specification/expected behaviour mentioned by the sponsors in the Technical walkthrough (referenced below), the minimum delay is supposed to be 2 days.
References
https://youtu.be/u1lYGykS-7g?si=-xVed8AAHZ8NkVHh&t=2436
Impact Details
Since the minimum delay is expected to be 2 days, when the operation/community multisig try to set a delay in the range [2,7], the call would revert with InvalidDelay
error.
Due to this, the issue has been marked as low-severity since the contract fails to deliver promised results and does not abide by its specification/expected behaviour.
Vulnerability Details
Here is the whole process:
First , let's take a look at the MINIMUM_DELAY constant value in the Timelock.sol contract:
As we can see, the code is deployed with a constant (immutable) value of 7 days rather than the expected value of 2 days.
This mean that when the operation/community multisig calls the function
setDelay()
through the functionexecuteTransaction()
with a value in the range [2,7], the call would revert with theInvalidDelay
error. This denies the operators/community from setting a value in that range and forces them to set delay to a value greater than 7 days.
Proof of Concept
How to use this POC:
Add the POC to the Timelock.t.sol file.
Run the test using
forge test --fork-url <ETH_MAINNET_RPC_URL> --match-test testIncorrectMinDelayIssue -vvv
Last updated