The getUserRemainingLimit view function uses an incomplete conditional check that defaults to Phase 2 parameters when getCurrentPhase() returns 0 (pre-launch phase). Phase 0 occurs when launchStartBlock is 0 or before any blocks have passed since initialization. Users querying their swap limits during Phase 0 will incorrectly see the Phase 2 limit (20% of initialLiquidity), creating false expectations. Once the launch actually starts and enters Phase 1, the effective limit abruptly drops to the much smaller Phase 1 cap (1% of initialLiquidity).
Likelihood:
Low - Only affects pre-launch queries. Most users interact after launch begins.
Impact:
Low - UX confusion. Users see "20% limit" before launch, then hit "1% limit" after launch starts. No fund loss, but potential trust issues.
Below is just a comment about this minor bug
Explicitly handle Phase 0 by returning 0 or a specific indicator that the launch hasn't started yet.
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.