There's a bug in the V3 SDK SwapRouter's swapCallParameters refund logic that can lead to users losing ETH in certain scenarios. The current implementation only triggers ETH refunds for EXACT_OUTPUT trades, but refunds should occur for any trade where native ETH is the input token.
// Current implementation
const mustRefund = sampleTrade.inputAmount.currency.isNative && sampleTrade.tradeType === TradeType.EXACT_OUTPUT
// Should be
const mustRefund = sampleTrade.inputAmount.currency.isNative
|
const mustRefund = sampleTrade.inputAmount.currency.isNative && sampleTrade.tradeType === TradeType.EXACT_OUTPUT |
Impact
When performing EXACT_INPUT swaps with ETH as the input token, if the liquidity pool cannot fulfill the entire order, the unused ETH becomes trapped in the V3 router contract. This ETH remains stuck until the next user performs an EXACT_OUTPUT trade or any refundETH call, at which point the stuck ETH is incorrectly refunded to that subsequent user.
This issue has already been covered in articles such as this one.
There's a bug in the V3 SDK SwapRouter's
swapCallParametersrefund logic that can lead to users losing ETH in certain scenarios. The current implementation only triggers ETH refunds forEXACT_OUTPUTtrades, but refunds should occur for any trade where native ETH is the input token.sdks/sdks/v3-sdk/src/swapRouter.ts
Line 97 in ff2be9a
Impact
When performing
EXACT_INPUTswaps with ETH as the input token, if the liquidity pool cannot fulfill the entire order, the unused ETH becomes trapped in the V3 router contract. This ETH remains stuck until the next user performs anEXACT_OUTPUTtrade or anyrefundETHcall, at which point the stuck ETH is incorrectly refunded to that subsequent user.This issue has already been covered in articles such as this one.