The provide_liquidity
function fails to implement slippage protection when calculating the required amount of token B for a given amount_a
of token A. Specifically:
Users supply amount_a
without specifying a maximum acceptable amount for token B (max_amount_b
)
The calculated amount_b
(via calculate_token_b_provision_with_a_given
) is used unconditionally
No validation occurs to ensure the exchange rate is within user expectations
This allows scenarios where:
A malicious actor could sandwich the transaction (front/back-run) to manipulate prices
Users receive an unfavorable exchange rate due to high slippage
Token B provision could become economically nonviable (e.g., 1 unit of token B for 1,000,000 token A)
Financial Loss: Users may receive significantly less token B than expected
MEV Exploitation: Traders could extract value through price manipulation
System Abuse: Attackers could intentionally create unfavorable pools to drain users
Trust Degradation: Users lose confidence in the protocol's safety mechanisms
Implement slippage protection with a user-defined maximum:
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.