The deposit flow relies on a global counter (counter) and associated state (e.g. depositInfo[counter]) for minting shares and refunding execution fees. This design assumes that deposits are processed strictly sequentially. However, if deposits are not handled sequentially or if flows overlap unexpectedly, the contract may reference the wrong deposit data.
Incorrect Share Calculations: May lead to misallocation of depositor shares.
Faulty Fee Refunds: Users might receive improper fee refunds.
State Inconsistencies: Overlapping flows could lock funds or dilute share values, undermining protocol integrity.
Manual code review.
Static analysis techniques.
Reference Accuracy: Modify the refund logic to reference the correct deposit using the provided depositId instead of the global counter.
Flow Isolation: Implement strict checks to prevent overlapping flows or asynchronous state modifications.
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
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.