Uniswap v4 can use native ETH directly in a pool, while WETH remains a separate ERC-20 currency. A user can attach ETH funding as transaction value; WETH uses token transfers and the applicable permissions. Identify the pool currency, pay its actual debt, collect the output and return any unused router funding. A settled v4 swap does not by itself prove that excess ETH reached your wallet.
Read the currency before the symbol
An interface can display “ETH” while a route uses WETH internally. The useful question is which currency each pool requires and which asset the recipient finally receives.
ETH is Ethereum's native asset. WETH9 is a contract representation: in the reference WETH9 implementation, depositing ETH increases the caller's token balance by the deposited amount; withdrawing reduces that balance and returns ETH. An equal conversion amount does not merge the two balance records. The wrapped-token dependency guide explains why the exact contract and chain still matter.
Uniswap v4 adds native ETH support, so a native ETH pool can operate without a WETH conversion. This differs from v3's requirement to wrap ETH for its pools. It does not require every v4 route to use native ETH. Uniswap's v4 and v3 comparison.
In v4, the pool's currency fields settle the question. The native currency is represented by address(0); WETH is represented by its actual token contract address. The zero address here is a protocol identifier, not a destination to which you should send ETH. The v4 Currency library branches between native-value transfers and ERC-20 transfers using that distinction.
| Check | Native ETH pool input | WETH pool input |
|---|---|---|
| Currency identifier | Native-currency sentinel | Verified WETH contract |
| Spendable balance to check | Native ETH available to the paying contract | WETH tokens available from the chosen payer |
| Payment mechanism | Native value sent during settlement | WETH transfer followed by settlement |
| User token permission | No ERC-20 allowance for ETH itself | Required when the route pulls the user's WETH |
| Where unused funding stays | Can remain as ETH already sent to the router | Can remain in the wallet if only actual debt is pulled |
Changing a pool's native ETH currency to WETH changes its identity. A v4 PoolKey also includes the other currency, fee, tick spacing and hook contract. Replacing one field does not select a different payment option for the same pool. Uniswap's PoolKey definition.
This matters for quotes: ETH and WETH pools paired with the same other token need not have the same liquidity or price. Pools can also use different dynamic LP fee rules. Compare complete executable routes rather than inferring a better total price from the absence of a wrapping step.
Separate funding from the amount settled
The following mechanism uses Uniswap's Universal Router source at revision fb25ff0, its v4 periphery dependency at 07336f2 and core dependency at 59d3ecf. The example assumes pools without hooks, standard tokens, a direct user call and successful execution of every required command. A real integration must match its chain and deployed router version; the Universal Router documentation makes that deployment distinction explicit.
During a swap, v4 records currency deltas for the caller interacting with PoolManager. In this example that caller is the router. A negative delta is what the router owes; a positive delta is what it can collect. These accounting entries are separate from tokens or ETH already sitting in the router. The flash-accounting guide develops the broader netting mechanism.
The periphery's settlement helper first calls sync for the currency. For native ETH, it then calls PoolManager's payable settle with the specified value. For an ERC-20 such as WETH, it pays the token and calls settle without native value. v4's settlement helper.
The v4 SETTLE_ALL action obtains the full outstanding debt, checks it against a maximum and pays that debt. For illustration, a maximum of 1 ETH does not instruct the helper to pay 1 ETH when only 0.84 ETH is owed. TAKE_ALL separately collects the output credit, subject to its minimum. V4Router's settlement and collection actions.
PoolManager requires its outstanding deltas to be resolved before its unlock completes. That check does not require Universal Router's external ETH balance to be zero. Returning unused router-held ETH is another operation. In the selected router implementation, an ETH SWEEP checks its minimum and transfers the router's entire remaining ETH balance to the chosen recipient. It does not maintain a separate refund account for each user. PoolManager's unlock check, Universal Router's payment functions.
A 1 ETH cap can leave 0.16 ETH to return
Consider an illustrative exact-output swap for 2,400 units of invented token Q. Q uses six decimals and has no transfer fee or rebasing. The wallet starts with 2 ETH, 1 WETH and no Q. The router starts with none of these assets. Ignore gas initially.
Assume the selected native ETH/Q pool delivers the full 2,400 Q and creates an actual debt of 0.84 ETH, including the swap's input-side fee. This is an assumed execution result, not a live quote or a price calculation. The input maximum is 1 ETH, and the user attaches 1 ETH as transaction value.
The plan performs a v4 single-pool exact-output swap, settles the actual native debt up to the cap, and takes all Q to the calling wallet with a 2,400 Q minimum. After the v4 operation, an outer ETH sweep returns the remaining router balance to that wallet. No unrelated funding or optional failed commands are included.
| Illustrative native ETH step | Wallet ETH | Router ETH | Router's ETH delta at PoolManager | Wallet Q |
|---|---|---|---|---|
| Before execution | 2.00 | 0.00 | 0.00 | 0 |
| Fund router with transaction value | 1.00 | 1.00 | 0.00 | 0 |
| Swap records debt and output credit | 1.00 | 1.00 | −0.84 | 0 |
| Settle 0.84 ETH | 1.00 | 0.16 | 0.00 | 0 |
| Take the 2,400 Q credit | 1.00 | 0.16 | 0.00 | 2,400 |
| Sweep unused ETH to wallet | 1.16 | 0.00 | 0.00 | 2,400 |
The Q credit is positive 2,400 immediately after the swap and zero after taking it. The WETH balance stays at 1 throughout. The native ledger reconciles as 1.00 − 0.84 = 0.16 ETH returned, and 2.00 − 1.00 + 0.16 = 1.16 ETH left in the wallet before gas.
Without the sweep, both PoolManager deltas could be zero while 0.16 ETH remains in the router. The swap cap and settlement checks can pass without completing the user's intended return of change. A shared router balance should never be treated as personal storage awaiting a later withdrawal.
Gas belongs in a separate line. For this native example only, assume 100,000 gas used at an effective 12 gwei per gas. The illustrative fee is 0.0012 ETH, leaving 1.16 − 0.0012 = 1.1588 ETH. Ethereum's network fee is paid in ETH and depends on gas used and the effective gas price. The 0.16 ETH sweep is returned swap funding, not a network gas refund. Ethereum's gas calculation.
The WETH comparison leaves change in a different place
Now construct a separate WETH/Q pool example with the same starting wallet and output target, a 1 WETH maximum and an assumed 0.84 WETH debt. Matching those numbers only isolates payment mechanics; it does not assert equal live prices across pools.
This route attaches zero ETH as swap funding. Assume the required WETH and Permit2 permissions are already valid. Settlement transfers 0.84 WETH from the wallet to PoolManager through Permit2, leaving 0.16 WETH in the wallet. Taking the output delivers 2,400 Q. The wallet's native ETH remains 2 before gas.
Universal Router's payment helper distinguishes payment from its own balance from a Permit2 transfer from the selected external payer. That is why this example moves only the actual WETH debt. Universal Router's payer selection. The unused 0.16 WETH never entered the router, so this construction needs no WETH refund. Prefunding the router with the full 1 WETH would create a different cleanup requirement.
Review token allowances and revocation separately. Neither a token balance nor a maximum-input field establishes valid spending permission, and successful spending can leave permission behind.
Check conversions and failure points before signing
Holding ETH does not settle a WETH debt without conversion. Holding WETH does not supply native value without unwrapping. Universal Router has separate wrapping and unwrapping commands, which a route must compose when required. A multi-version route may therefore accept native ETH at the wallet, wrap it for one hop and later deliver native ETH again. Universal Router command reference.
The output deserves the same check. Receiving WETH from a WETH pool changes a token balance; receiving native ETH changes the native balance. If a route receives WETH but promises native ETH, verify its unwrap step, recipient and final native receipt. Native ETH pool output needs no WETH conversion. Do not count a WETH transfer and its subsequent unwrap as two separate proceeds.
Three failure cases are especially easy to miss:
- A cap without enough funding. A 1 ETH maximum does not provide the router with 1 ETH. Attaching only 0.75 ETH cannot fund the example's 0.84 ETH payment when the router has no other ETH.
- A correct swap with missing change. Omitting cleanup can leave the 0.16 ETH router balance even when v4 settlement completes. Check the actual return transfer and recipient.
- An incompatible native recipient. A contract recipient can reject native ETH. The selected Currency implementation reverts when its native transfer fails; validate the intended recipient's ability to accept ETH.
For a fully reverted transaction, use the receipt and final balances before attempting another route. Included failed execution can still cost gas, as the failed-swap fee guide explains. Ordinary sender-paid Ethereum transactions also need native ETH for fees even when their swap input is WETH.
Verify settlement and returned change
Use this worksheet for one concrete route, including any conversions around its pools.
| Record | Validation |
|---|---|
| Chain and contracts | Confirm router version, PoolManager and WETH contract where used |
| Pool currencies | Read native sentinel versus token address from every relevant pool key |
| Funding and cap | Record attached value, actual payer, maximum input and available balance separately |
| Currency obligations | Check actual debt paid and output credit collected |
| Recipient assets | Verify the final asset, amount and recipient after any wrap or unwrap |
| Remainder and fees | Reconcile returned ETH or WETH, router residuals and network fee separately |
The route is reconciled when its v4 obligations close and its wallet movements match the plan. In the native example, that means 2,400 Q received, 0.16 ETH returned, zero intended router residual and 0.8412 ETH total wallet depletion including the assumed fee. Keep those amounts distinct in the record.