The BLOCK_LENGTH_SECONDS
constant defined inside C.sol
is fixed to be 12 seconds.
This contract is used in a lot of in-scope contracts . When it's inheriting contracts use the internal method getBlockLengthSeconds
,
this will incorrectly give the block time to be universal as 12 . However ,Ethereum Mainnet does not exactly have 12 seconds block time which will mess up
contract's crucial funds-related operations with this flawed assumption and perform or dos operations which needed to be other way around.
Inside C.sol
, which Contains constants used throughout Beanstalk.
according to code natspec .
There are multiple constants , one of them being
This revolves around the assumption that after PoS migration of ethreum , the block time will always be 12 seconds , however ,
History has given scenarios where block time has deviated from it
https://etherscan.io/chart/blocktime
We can clearly see that block time , even after PoS , has significantly deviated and not a constant 12 seconds .
Any future Beanstalk operations assuming the correct block time to be 12 seconds will be bound to fail because it does not actually depicts the real world block time
Manual Review , Etherscan
A similar finding was uncovered by Hans in cyfrin-goldilocks-v1.1
https://solodit.xyz/issues/in-goldigovernor-wrong-assumption-of-block-time-cyfrin-none-cyfrin-goldilocks-v11-markdown
There can be many better solutions to this problem but the solution that is in my mind is to
update the code to use block numbers paradigm which is better to estimate the number of blocks that has been passed than the current incorrect approach.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.