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.
On Ethereum, this will be assumed to be fine.
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.
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.
Manual Review
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
.
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.