Normal behavior: The start boundary should be consistent across all user actions; at eventStartDate, both deposit and join should be disallowed.
Issue: deposit reverts when block.timestamp >= eventStartDate, while joinEvent reverts only when block.timestamp > eventStartDate. At exactly eventStartDate, deposit is blocked but join is still allowed if a prior deposit exists, creating a one-block inconsistency.
Likelihood: Low
Happens only at the exact boundary timestamp.
Impact: Low
Allows an extra join at the start boundary while new deposits are blocked; minor fairness inconsistency.
Can cause confusion on edge cases for the user.
Description:
Deposit one block before start; at the exact eventStartDate, deposit is blocked but join still succeeds.
Align both checks to the same boundary by using >= in joinEvent as well.
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.