Uniswap swaps involve several distinct costs, and understanding how they interact is essential to determining how many tokens a trader actually receives. Although Uniswap Labs set its interface fee to 0% after December 27, 2025, transactions can still involve protocol-level swap fees, Ethereum network costs and execution differences caused by liquidity conditions. These expenses must be assessed separately to avoid confusing the amount deducted during a swap with costs paid outside the token exchange.
A historical Ethereum transaction illustrates the distinction. On September 10, 2024, a trader exchanged 0.001 ETH for USDC through a Uniswap v3 swap and received 2.320837 USDC. The transaction also incurred approximately 0.001263 ETH in network fees, exceeding the amount of ETH exchanged. This example demonstrates how network costs can outweigh the value of a small trade, although the historical figure should not be treated as an estimate of current gas prices.
The transaction receipt also shows why fee accounting requires care. The liquidity pool transferred 2.326653 USDC to Uniswap’s Universal Router, which then sent 0.005816 USDC to an address identified as “Uniswap: Fees 2.” The remaining 2.320837 USDC reached the trader’s wallet. The fee transfer and the wallet receipt together account for the pool’s full output. Deducting the 0.005816 USDC again from the amount received would count the same fee twice. Meanwhile, the ETH network charge represents a separate transaction expense rather than another deduction from the recorded USDC transfers.
Pool fees introduce another layer of variation because their structure depends on the protocol version and the selected pool. In the documented Uniswap v3 example, a pool with a 0.05% fee tier allocates 0.0375% to liquidity providers and 0.0125% to the protocol. Together, those components equal the stated 0.05% fee. Treating the protocol share as an additional charge on top of the full tier would overstate the cost.
Uniswap v4 uses a different fee calculation. Its core mechanism applies the protocol fee to the input amount first, then calculates the liquidity-provider fee on the remainder. Consequently, the v3 allocation should not be applied universally to v4 swaps. Version-specific rules matter when estimating the effective cost of an exchange, particularly when protocol fees and liquidity-provider charges interact.
The selected v4 pool can introduce further variation. Pools may support dynamic swap fees, while custom hooks can impose separate fees alongside protocol charges. Because hooks allow developers to customize pool behavior, the fees and execution conditions associated with one pool may differ from those of another. Traders therefore need to consider the actual pool and route rather than assume that every Uniswap swap follows one fixed fee schedule.
Price impact and slippage also affect the final amount received, but neither should automatically be classified as a fee. Price impact describes how a trade changes the execution price relative to the prevailing price, particularly when the order is large compared with available liquidity. A thinner pool can therefore deliver a worse exchange rate without the difference representing a separate payment to a fee recipient.
Slippage describes the difference between expected and actual execution. A trader’s slippage tolerance sets the maximum permitted deterioration from the previewed execution, rather than imposing an automatic charge. A tighter tolerance can cause a transaction to fail if the market moves beyond the limit, while a more permissive setting allows execution under a wider range of conditions and may result in fewer tokens received. Calculating realized slippage requires the original quote and final output to be compared on the same basis; the transaction receipt alone does not establish the difference from the expected price.
The execution route also determines how network costs are handled. In a classic onchain swap, the trader generally pays the transaction’s network fee separately, with ETH used to pay Ethereum gas. Failed transactions can still consume gas, meaning a trader may incur a network expense without completing the intended exchange.
UniswapX follows a different model. Third-party fillers submit orders onchain and pay gas on the trader’s behalf, recovering those costs through the execution price. In this arrangement, the economic cost of execution can be reflected in the price received, but the same gas expense should not also be deducted as though the trader paid it separately. Comparing classic swaps with UniswapX therefore requires attention to both the final execution price and the way network costs are settled.
Token approvals can add another expense before a swap takes place. A required onchain approval transaction may incur its own network fee, separate from the swap itself. A Permit2 signature, by contrast, does not require an onchain network payment merely to sign. The distinction matters when estimating the total cost of moving from an unapproved token to a completed trade.
Ultimately, the interface fee is only one part of Uniswap’s cost structure. A reliable estimate of the trader’s final outcome must account for the applicable pool fee, price impact, realized slippage, network expenses and any required approval transactions, while avoiding double-counting amounts already reflected in the received output or execution price. The most useful comparison is not simply whether a swap advertises zero interface fees, but how much value the trader gives up across the entire transaction route.
