The protocol tracks user swap amounts and cooldowns to enforce limits that vary by phase. The design intends for these limits to reset when the protocol transitions from Phase 1 to Phase 2.
The function _resetPerAddressTracking is called during a phase transition to achieve this. However, it incorrectly resets the mapping for address(0) instead of msg.sender or iterating through users (which is not possible in this architecture). As a result, a user's addressSwappedAmount accumulates across phases. A user who swapped 1% in Phase 1 will immediately be at 1% usage in Phase 2, potentially triggering penalties prematurely if they were expected to have a fresh limit.
Likelihood:
Occurs for every user active across the phase boundary.
Impact:
Users are unfairly penalized or restricted in Phase 2 based on their Phase 1 activity, contradicting the intended fresh start for the new phase.
Update state variables to map Phase ID -> User Address -> Data instead of reset.
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.
The contest is complete and the rewards are being distributed.