Users can still call joinEvent() at the exact eventStartDate , while deposit is already blocked and this creates a scenerio where joining is possible but depositing is not
Once the event starts at eventStartDate, both depositing and joining should be blocked to ensure a fair and consistent cutoff.
However, joinEvent reverts only when block.timestamp > eventStartDate as a result users can still join at EXACTLY the eventStartDate even though deposits can no loner be made.
Likelihood:
This will occur at the exact moment the event starts, a user can still join the event even when when its not supposed to be so
Impact:
Inconsistent state and fairness issues, including an imbalance between who can still join versus who can no longer deposit at the same time.
At exactly eventStartDate, joinEvent() succeeds while deposit reverts.
Modify the check to ensure that users cant join the event once it has already started even at the exact time it started
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.