DeFiHardhatFoundry
250,000 USDC
View results
Submission Details
Severity: high
Invalid

Wrong Block Length assumption can jeopardise beanstalk system

Summary

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.

Vulnerability Details

Inside C.sol, which Contains constants used throughout Beanstalk. according to code natspec .

There are multiple constants , one of them being

/// @dev The block time for the chain in seconds.
uint256 internal constant BLOCK_LENGTH_SECONDS = 12;

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

Date(UTC) UnixTimeStamp Value
3/24/2024 1711238400 12.13
3/26/2024 1711411200 12.14
3/27/2024 1711497600 12.39
3/28/2024 1711584000 12.15
5/14/2024 1715644800 12.11
6/28/2024 1719532800 12.05

We can clearly see that block time , even after PoS , has significantly deviated and not a constant 12 seconds .

Impact

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

Tools Used

Manual Review , Etherscan

Reference

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

Recommendations

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.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.