You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 implementationconstmustRefund=sampleTrade.inputAmount.currency.isNative&&sampleTrade.tradeType===TradeType.EXACT_OUTPUT// Should beconstmustRefund=sampleTrade.inputAmount.currency.isNative
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.
The text was updated successfully, but these errors were encountered:
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 forEXACT_OUTPUT
trades, 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_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 anEXACT_OUTPUT
trade or anyrefundETH
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.
The text was updated successfully, but these errors were encountered: