The adapters (CurveAdapter, UniswapV2Adapter, UniswapV3Adapter) calculate minimum output amounts for swaps using token prices obtained within the same transaction, which makes the slippage protection ineffective. This can lead to larger-than-expected losses due to price movements between transaction submission and execution.
BaseAdapter.sol:L95~123
CurveAdapter.sol:L75~142
UniswapV2Adapter.sol:L75~136
UniswapV2Adapter.sol:L81~141
The current implementation of slippage protection in the adapter contracts (CurveAdapter
, UniswapV2Adapter
, and UniswapV3Adapter
) has a critical vulnerability in the way it calculates the minimum output amount for swaps.
In CurveAdapter.sol#executeSwapExactInputSingle()
, the amountOutMinimum
is calculated using token prices obtained within the same transaction:
The issue lies in BaseAdapter.sol#getExpectedOutput()
where token prices are used for calculation:
Transaction delays due to network congestion or other factors can result in price changes exceeding the expected slippage tolerance.
Users may experience greater losses than anticipated due to price movements between transaction submission and execution.
Discrepancies between oracle prices and actual pool prices increase the likelihood of transaction failures.
Modify the SwapExactInputSinglePayload
and SwapExactInputPayload
structs to include an amountOutMinimum
parameter.
Update the swap execution logic to use the user-provided amountOutMinimum
for slippage protection instead of calculating it from current prices.
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.