Arcade.xyz - giovannidisiena's results

Lines of code

https://github.com/code-423n4/2023-07-arcade/blob/f8ac4e7c4fdea559b73d9dd5606f618d4e6c73cd/contracts/external/council/CoreVoting.sol#L15

Vulnerability details

Impact

CoreVoting::DAY_IN_BLOCKS is a constant set to 6496 based on the assumption of 13.3 seconds per block.

// Assumes avg block time of 13.3 seconds. May be longer or shorter due
// to ice ages or short term changes in hash power.
uint256 public constant DAY_IN_BLOCKS = 6496; // @audit - should be 7200 due to post-merge 12 second block times

However, moving to Proof-of-Stake (PoS) post-Merge, block times on Ethereum are actually fixed at 12 seconds per block/slot.

This issue results in the lockDuration and extraVoteTime variables being initialized to values smaller than intended. These are used to determine the minimum time for which a proposal must be active before executing and the number of blocks after the proposal is unlocked during which voting can continue.

// minimum time a proposal must be active for before executing
// Default to 3 days, this avoids weekend surprise proposals
uint256 public lockDuration = DAY_IN_BLOCKS * 3;

// The number of blocks after the proposal is unlocked during which
// voting can continue. Max vote time = lockDuration + extraVoteTime
// Default to ~5 days of blocks, ie 8 days max vote time
uint256 public extraVoteTime = DAY_IN_BLOCKS * 5;

The time difference can be calculated:

>>> 6496 * 3              # 3 days in blocks / 13.3 sec block period
19488
>>> 6496 * 5              # 5 days in blocks / 13.3 sec block period
32480
>>> 7200 * 3              # 3 days in blocks / 12 sec block period
21600
>>> 7200 * 5              # 5 days in blocks / 12 sec block period
36000
>>> 21600 - 19488         # `lockDuration` difference in blocks
2112
>>> 36000 - 32480         # `extraVoteTime` difference in blocks
3520
>>> 2112 * 12 / (60 * 60) # `lockDuration` difference in hours
7.04
>>> 3520 * 12 / (60 * 60) # `extraVoteTime` difference in hours
11.733333333333333

By using block time of 13.3 seconds, a proposal is incorrectly ready for execution 7 hours earlier than is expected. Voting for such a proposal also ends 11.7 hours earlier than expected. These are significant differences in time which could cause confusion and inadvertently allow a malicious proposal to succeed. Once discovered, an admin transaction is required to rectify this issue by updating the variables, but at this point it may already be too late. I therefore believe this issue to be Medium severity.

This contract is out-of-scope given it is included as one of the external dependencies from the Council Framework, but due to its inheritance by ArcadeGSCCoreVoting and given that it makes up the entirety of this contract's logic I argue that this is a valid finding.

Proof of Concept

N/A.

Tools Used

Manual review.

Recommended Mitigation Steps

uint256 public constant DAY_IN_BLOCKS = 7200;

Assessed type

Timing