eventStartDate and eventEndDate Leading to Invalid or Illogical Time Windows, Potentially Enabling MEV ExploitationThe Brivaul::constructor and related functions do not verify that eventEndDate is later than eventStartDate and do not enforce a minimum participation duration. This can create invalid or extremely short event windows, allowing accidental misconfiguration or administrative errors.
Without a minimum duration, a malicious MEV bot or miner could front‑run or reorder transactions in the mempool, causing honest participants’ actions (e.g., deposits or team selections) to revert or execute outside the intended event window, potentially preventing legitimate participation.
Setting invalid timestamp combinations can immediately disrupt core contract functionality, preventing users from participating in intended activities. If endTime is accidentally set before startTime or in the past, the event may appear concluded instantly, blocking deposits, withdrawals, and other interactions.
Accidentally setting eventStartDate later than eventEndDate.
After advancing time past eventEndDate, users are still able to deposit, joinEvent, and cancelParticipation.
The owner cannot call setWinner function, even though endTime has passed, because startTime has not yet been reached.
Place the following code in briVault.t.sol.
Proof Of Code
Introduce a minimum event duration (MINDURATION) and enforce it in the constructor by requiring that eventEndDate is at least MINDURATION after eventStartDate.
This is owner action and the owner is assumed to be trusted and to provide correct input arguments.
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.