The contract allows event creation with customizable start and end timestamps, but does not enforce that the end date must be after the start date.
This could lead to invalid or unusable events being created, where the event ends before it starts or both timestamps are the same, breaking time-dependent logic elsewhere
Likelihood:
Every event creation call risks invalid data entry since timestamps are unchecked.
It’s a high probability developer error during setup, especially with multiple concurrent events.
Impact:
Users and dApps may interact with already-expired or never-starting events.
Causes broken participation logic, e.g., deposits may instantly revert or never open.
Explanation:
Currently, this call succeeds silently, creating an event that ends before it begins.
Any logic that depends on block.timestamp (like participation checks) will break or produce inconsistent behavior.
Explanation:
Prevents logically impossible events from being stored.
Protects the system from downstream time-based logic errors.
Ensures reliable user experience and consistent state integrity.
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.