Sparkn

CodeFox Inc.
DeFiFoundryProxy
15,000 USDC
View results
Submission Details
Severity: medium

[ M ] MAX_CONTEST_PERIOD constant will not apply across contests deployed on different chains

Summary

The MAX_CONTEST_PERIOD constant is used to set the maximum duration of a contest.

The constant is set to 28 days.

When the owner calls setContest on the ProxyFactory contract, it will check the current
block timestamp against the MAX_CONTEST_PERIOD constant.

if (closeTime > block.timestamp + MAX_CONTEST_PERIOD || closeTime < block.timestamp) {
revert ProxyFactory__CloseTimeNotInRange();
}

On Ethereum, this will be assumed to be fine.

Vulnerability Details

However, the MAX_CONTEST_PERIOD constant will not apply across contests deployed on different chains.

This problem is prominent because chains like Polygon, Optimism, Arbitrum, and BSC have a faster block time than Ethereum.

BSC average block times are 3 seconds, Arbitrum is 4.5 seconds, Polygon average block times are 2 seconds, and Optimism average block times are 0.5 seconds.

Impact

Due to these varied block times, the MAX_CONTEST_PERIOD constant may not be universally
applicable across different chains. Contest creators might find that the time interval
between consecutive blocks on these faster chains could lead to situations where the
condition closeTime > block.timestamp + MAX_CONTEST_PERIOD fails, even for closeTime values that would
be considered valid on Ethereum.

Tools Used

Manual Review

Recommendations

You could use an Oracle to get the current block.timestamp across the desired chains of deployment.

Then use the Oracle to check the current block timestamp before setting the closeTime.

Support

FAQs

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