The _resetPerAddressTracking() function is intended to clear user trading history when transitioning between launch phases (e.g., from Phase 1 to Phase 2). However, the implementation contains a critical flaw: it only resets the entries for address(0) instead of iterating through and resetting actual user addresses. In Solidity, it is impossible to iterate over all keys in a mapping, and the current implementation effectively resets nothing. Consequently, all users retain their accumulated swap amounts from previous phases, preventing them from accessing fresh allowances in new phases and potentially causing permanent penalties.
Likelihood:
Phase transitions are guaranteed to occur (configured at deployment), and the _resetPerAddressTracking() function is automatically invoked on every phase boundary.
Impact:
Users entering a new phase still carry accumulated swap amounts from previous phases. This means:
Users cannot utilize their new phase allowance (e.g., 3% in Phase 2)
Users may be immediately penalized upon phase entry if they exceeded previous phase limits
The anti-bot protection mechanism becomes a punitive trap for legitimate users
The following PoC demonstrates that after a phase transition, user tracking data persists despite the _resetPerAddressTracking() call. We simulate a user trading in Phase 1, then advancing to Phase 2, and verify that their accumulated amount was NOT reset.
The fundamental issue is that Solidity mappings cannot be iterated to reset all entries. Instead of attempting to reset user data, track swap amounts per phase using a nested mapping structure. This allows each phase to have independent accounting without requiring any reset logic.
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.