At programs/amm/src/instructions/liquidity_operations.rs#209
The current implementation does not sort token_a and token_b before deriving the pool PDA.
This allows users to create two separate pools for the same token pair (e.g., USDC/SOL and SOL/USDC), leading to fragmented liquidity and potential user confusion.
Likelihood:
It's not trivial that a user can creates for example USDCSOL and SOLUSDC liquidity pairs.
Impact:
Fragmented liquidity across duplicated pools
Inconsistent pricing and slippage behavior across mirrored pools
Potential arbitrage abuse
Simply creates SOLUSDC and USDCSOL within the system.
This ensures the same token pair always maps to a single, deterministic pool address.
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.