Uniswap
Uniswap Supports Token Swaps Through Liquidity Pools or Intent-Based Orders, With Results Recorded Onchain
Uniswap is a decentralized exchange protocol that lets a wallet swap tokens against onchain liquidity without transferring custody to a centralized exchange. A quote identifies the selected assets, network, route, quoted input and output, fees, price impact, and the applicable minimum-output or maximum-input limit. Before signing, those fields define the proposed trade. After submission, the transaction hash, receipt status, token transfers, and wallet balances show what actually executed. A quote is an estimate; the confirmed record is the evidence of the final result.
Pool Routes, Fillers, and Protocol Versions
Pool routes and intent-based orders are distinct paths to the same broad goal: exchanging one token for another. A classic pool swap calls routing contracts that draw from one or more liquidity pools. A route may be direct, pass through an intermediate token, or split the input across pools when that combination produces a better estimated outcome after fees and network costs.
An eligible quote may instead use UniswapX, where third-party fillers compete to execute a signed order. A filler can use onchain liquidity or its own inventory. Its settlement transaction can look different from a classic pool swap, so record the displayed route before signing. The final token changes still need to match the signed order and its output conditions.
Protocol versions also shape execution. Uniswap v2 uses full-range liquidity and constant-product pools. Uniswap v3 introduced concentrated liquidity, while v4 adds hooks that can customize defined parts of pool behavior. A v4 pool with a hook may differ from an unhooked pool in fees or execution logic, so version alone does not describe every condition.
Token Identity and Network Compatibility
Token compatibility begins with the combination of network and contract address. Symbols and names are display labels, and unrelated contracts can reuse them. The input and output asset identities must match the quoted network, and the wallet must hold enough of the input asset there. A contract address copied from another network identifies a different deployment, even when the displayed symbol looks identical.
Before signing, confirm that the wallet and quote still show the same network, then inspect both token contracts. Also confirm that the input balance is available on that network. A balance held on another chain cannot fund an ordinary same-chain pool swap until a separate transfer or bridging process has completed.
Native assets and their wrapped forms also have different onchain identities. An interface may handle wrapping within a route, but the preview should reveal the actual assets and operations. Treat a change in network, contract, or wrapper as a new quote rather than a cosmetic update.
How Does a Swap Change Pool State?
A pool swap adds an input asset and removes an output asset within one atomic transaction, subject to the pool's math and the user's limits. The exchange rate changes as the trade moves the pool price. Larger orders usually move the price further when available liquidity is shallow, while deeper liquidity can absorb the same order with less price impact.
In Uniswap v2, a pair checks a constant-product invariant after adjusting input amounts for the swap fee. Uniswap v3 and v4 divide the price curve into ranges, so a swap can cross ticks and draw on different bands of active liquidity. A v4 hook may run at defined points around that operation, depending on the pool's configuration.
Atomic execution keeps the state transition together. If a required condition fails, the swap reverts instead of leaving a partial pool exchange. Network computation may still incur a cost even though the token state changes are rolled back.
Quote Economics: Price Impact, Slippage, and Fees
A quote is a time-sensitive calculation based on the selected amount, available liquidity, route, pool fees, and estimated network cost. Price impact measures how the proposed order itself changes the pool price. Slippage is the difference between the quoted and executed amounts or prices when market or pool state changes before confirmation.
For an exact-input swap, the slippage setting usually determines a minimum acceptable output. Execution can proceed at or above that minimum; otherwise, the transaction should revert. Raising the tolerance increases the range of acceptable outcomes, including outcomes farther below the original estimate. Lowering it narrows that range but can make a changing market more likely to invalidate the transaction.
Several costs may appear without being interchangeable. A pool fee is part of the swap calculation, while the network cost pays for blockchain execution. A token contract may impose its own transfer mechanics, and an interface or route may disclose an additional fee when applicable. Read each field separately because the quoted output and the wallet's total balance change answer different questions.
A Hypothetical Compatibility Test
Every amount, contract choice, and network label in this worked example is hypothetical. Assume a reader selects Network A, an input-token contract on Network A, and an output-token contract on the same network. The hypothetical input is 37.3 units. The quote estimates 18.47 output units, sets a minimum of 18.20 units, and displays the network cost separately.
The reader proceeds only after the wallet, both token contracts, and the quote all show Network A. The reader signs the displayed authorization, checks that the confirmation still contains the 37.3-unit input and 18.20-unit minimum, and submits the swap. No contract, network, or amount changes between the review and signature.
The hypothetical receipt later shows success, while the token-transfer records show 37.3 input units leaving and 18.31 output units arriving. Because 18.31 is above the 18.20 minimum, the execution satisfies the signed output boundary. It is lower than the 18.47 estimate, so the receipt and balance change, rather than the earlier estimate, define the concrete result.
If the selected output contract belongs to Network B, it cannot identify the intended Network A asset. Recovery remains simple only before submission: switch to the intended network, select the matching contract there, and obtain a fresh quote. Once an unintended asset transaction is confirmed, result verification can document it, but the protocol cannot rename that asset or reverse the transaction.
Approvals, Signatures, and Execution States
Authorization states explain why an apparent transaction may not be the swap itself. An ERC-20 token often requires permission before a router or settlement contract can spend it. A wallet may therefore present an approval transaction, an offchain signature, and an execution transaction as separate actions. Check the details of each approval transaction, signed message, and execution transaction separately.
An ERC-20 approval grants a designated spender authority to transfer tokens up to the recorded allowance. The spender address and allowance amount determine the scope of that permission. A successful approval changes the allowance, but it does not prove that an exchange occurred or that an output token reached the wallet.
A pending pool swap has been broadcast without reaching a final result. A pending intent-based order may instead be waiting for a filler to submit its settlement transaction. A confirmed success records execution, while a reverted transaction records failure and usually consumes network fees. The receipt status separates those outcomes.
How Can You Verify a Swap Result?
A swap result is verified by matching one transaction hash to the intended network, wallet, contracts, status, and net token changes. Start with the hash shown by the wallet or activity record. Open that transaction on the correct network, confirm its status, and compare the initiating wallet or order beneficiary with the address that authorized the trade.
The transaction's destination may be a router or settlement contract rather than the output token contract. Token-transfer logs reveal which assets moved, but multi-hop routes can produce intermediate transfers that never belong to the user. Isolate the transfers into and out of the wallet, check their contract addresses, and compare the received amount with the signed minimum. The network cost and any native-asset value should be reconciled separately.
A success status proves that the submitted call did not revert. It does not prove that the chosen symbol represented the intended contract or that the economic outcome matched an earlier screen. Contract identity, signed limits, transfer records, and final balances supply those additional answers.
Keep the transaction hash as the stable lookup value. A screenshot can omit addresses or truncate amounts, while the hash points to the complete public record. Verifying that record never requires a recovery phrase or private key.
Balance Reconciliation and Display Mismatches
Balance reconciliation explains cases where a successful receipt and a wallet screen appear to disagree. A wallet may hide an unfamiliar token, cache an older balance, or display a different network. Confirm the network first, then add or inspect the exact output contract. A copied symbol cannot resolve a mismatch because symbols do not uniquely identify assets.
Decimals also affect display. Contracts record integer base units, while wallets format them using the token's declared decimal setting. Compare normalized amounts rather than raw integers from a log. Tokens with transfer fees, rebasing behavior, or unusual transfer functions may produce outcomes that differ from a standard ERC-20 route or prevent the route from executing.
Native-asset reconciliation needs another adjustment. The wallet's native balance can fall by the network cost as well as any native amount used in the swap. Wrapped tokens have separate contract balances, so a wrapped output should not be counted as an increase in the native balance.
Liquidity Positions Beyond Swapping
Liquidity provision is the protocol's other principal function. Providers deposit assets into pools and can earn a share of swap fees generated by active liquidity. The position also changes with pool prices, so its later token composition may differ from the original deposit. Impermanent loss describes one way that this position can underperform simply holding the same assets.
Uniswap v3 and v4 let providers choose a price range, while v2 positions cover the full price range. Concentrating liquidity can place more capital near the current price, but the selected range becomes part of the position's operating condition. Hooks can add further pool-specific behavior in v4, which makes the exact pool and hook configuration relevant to evaluation.
A liquidity action has its own evidence. Adding liquidity should create or increase a position, removing liquidity should return the recorded token amounts, and collecting fees should produce the corresponding token transfers, either as its own action or during liquidity removal. A swap receipt cannot establish that a liquidity position was created.
Position ownership, deposited amounts, selected range, collected fees, and remaining liquidity should agree across the receipt and position record. This reconciliation separates realized token transfers from values that an interface merely estimates.
Confirmed Results, Pending Transactions, and Follow-Up Actions
A swap is resolved when the transaction is confirmed, the intended output contract is identified, and the wallet's net token change agrees with the receipt. An interface success message is useful status information, but it should lead back to the transaction hash when amounts or identity remain in doubt.
A pending transaction is not final. Waiting, speeding up, or attempting cancellation uses wallet and network mechanisms, and a replacement is effective only if the network accepts it before the original transaction. Submitting a duplicate swap merely because a screen appears stale can create a second valid transaction.
An allowance remains separate from the completed swap. Spending can reduce it, a time-limited authorization can expire, and the owner can revoke the remaining permission. Reviewing the spender and remaining allowance is therefore a separate post-trade decision.
Once the receipt and balances agree, the next decision is whether any remaining approval or liquidity position should stay active. Revocation, fee collection, and liquidity removal are new onchain actions with their own hashes, costs, and results.
Common questions about Uniswap
Which Balance Pays the Network Cost When Swapping an ERC-20 Token?
The network's native asset usually pays the execution cost for a classic onchain pool swap, even when another token is being sold. With UniswapX, the filler pays most swap execution costs on the swapper's behalf, but an approval or wrapping action can still require the swapper to pay a network fee. The quote and wallet confirmation should identify the payer and estimated cost before submission.
Does a Reverted Swap Still Consume a Network Fee?
Yes, a reverted EVM transaction can consume a network fee because the network processed the attempted computation. The revert rolls back the swap's token and pool state changes, but it does not refund the gas already used. Check the receipt status before searching for output tokens, since a failed approval or reverted swap can still appear in wallet activity.
When Does Concentrated Liquidity Stop Earning Pool Fees?
A Uniswap v3 or v4 position generally stops earning swap fees while the pool price lies outside its selected range because its liquidity is no longer active at the current price. The position remains owned by the provider and may become active again if the price returns to that range. Pool-specific hooks can add conditions that also deserve review.
Can Uniswap Reverse a Confirmed Blockchain Swap?
No, the protocol cannot reverse a confirmed swap after the network has finalized its state change. A user may submit a new trade in the opposite direction if a valid route exists, but that is a separate transaction with a new quote, fees, price impact, and receipt. A mistaken token selection may therefore document a completed outcome without providing an automatic recovery path.