Uniswap Takes a Checked Token Pair From Quote Review to a Verifiable Onchain Swap

From Wallet Readiness to a Confirmed Record

Swap readiness is the condition in which one wallet, one network, and an identified token pair can support the intended transaction. The wallet needs enough of the input token for the quoted trade. When the wallet pays the execution cost for a direct onchain transaction, it also needs enough of the network's native asset. The selected output asset must be available on that same network; an ERC-20 output must match the expected contract address.

The path then moves through a quote, any required token permission, a final transaction or order signature, and submission. After submission, the transaction hash identifies the onchain transaction, but it does not prove success while the record remains pending. Completion requires a successful status and transfer details that satisfy the quote's execution bound. Those details provide the first reliable stopping point.

Contract Identity Across Networks

An ERC-20 token's identity comes from the network and contract address together, not from a name, symbol, logo, or wallet balance label. Different contracts can display the same symbol. The same project may also have separate deployments on different networks, each with its own address and liquidity. Selecting the wrong contract can produce a quote for an unintended asset or reveal that no usable route exists.

Complete identity checks before accepting a quote because balances, routing, and permissions depend on the selected network and assets. Confirm the connected network, each ERC-20 contract, and the receiving account. A token list can make selection convenient, while direct address comparison resolves ambiguity. If the wallet changes networks or accounts, rebuild the quote because balances, allowances, routes, and network costs may all differ.

Quote Direction as the First Reversible Choice

Quote direction determines which side of the exchange remains fixed. An exact-input quote fixes how much of the starting token will leave and calculates an estimated output. Its protective boundary is normally a minimum output. An exact-output quote fixes the desired receipt and calculates the required input, with a maximum input acting as the corresponding boundary.

Changing direction requires a new quote, but an approval alone does not commit the swap. Once a transaction or signed order is submitted, check its status before starting another attempt. Review the asset identities again after changing direction because similar display labels can hide an accidental reversal. Also distinguish the quoted output from the exchange rate shown for convenience. The quote should identify the input, output, and enforceable amount bound; the route, price impact, pool fees, and estimated network cost provide execution context.

Route Simulation and Execution Bounds

Route simulation compares available liquidity paths and estimates what they would produce under observed pool state and network conditions. A path may use one pool, several hops, or a split across liquidity sources. The most attractive raw exchange rate is not always the best estimated result after pool fees, price impact, and the cost of executing a more complex route.

Price impact describes how the proposed trade changes the available pool price. Slippage describes movement between the quoted state and actual execution. The minimum-output or maximum-input field converts the selected tolerance into an enforceable limit. A quote therefore remains a proposal, not a promise that its headline estimate will survive changing pool state until execution.

What Does a Token Approval Actually Authorize?

A token approval authorizes a named spender to transfer a specific token from the wallet, subject to an allowance. An ERC-20 approval authorizes a specified spender to transfer tokens up to the allowance recorded by the token contract. The approval does not choose an output token, execute a route, or prove that a swap followed. Native network assets do not use ERC-20 allowances, although a route may wrap one during execution.

When a route uses Permit2, the wallet may present an onchain token approval followed by a separate signature. The first permission lets the Permit2 contract access the token. The signature can narrow how another contract uses that permission through an amount and expiration. Signing the Permit2 message does not submit an onchain transaction or charge the signer a network cost, but the spender, token, amount, and deadline still need review.

---

A Hypothetical Minimum-Output Check

This hypothetical case makes every amount, token role, network choice, tolerance, quote, and status illustrative. A checked input token is quoted at 137.4 units for an estimated 84.24 units of the selected output token. The reader chooses a hypothetical 0.5% maximum slippage tolerance, so the minimum acceptable output is 84.24 multiplied by 0.995, or 83.8188 units.

Open full-size image

The approval covers at least 137.4 input units, and the final wallet request repeats the expected pair and execution bound. After submission, the receipt reports success and the transfer record shows 84.08 output units reaching the wallet. That amount exceeds 83.8188, so the observed state satisfies the stated condition even though it is below the estimate.

The edge case begins if execution would return only 83.7 units. That value falls below the minimum, so the transaction should revert instead of accepting the weaker exchange. The recovery boundary is a fresh quote: review its new estimate, route, and limit before deciding whether to sign again. Widening tolerance without examining the changed terms weakens protection rather than addressing the change.

Signature and Transaction Boundaries

A signature proves that the wallet authorized a specific message or transaction, but different prompts have different consequences. An approval transaction changes an onchain allowance. A Permit2 signature grants scoped spending permission. A direct pool swap prompt asks the wallet to authorize executable transaction data. Reading the wallet's request type and spender is therefore more informative than counting how many prompts appeared.

Execution also varies by route. A direct pool route generally ends with an onchain transaction from the user's wallet. An eligible UniswapX order can instead be signed and offered to fillers, with a filler submitting the eventual settlement. In either case, the signature is an authorization boundary. The resulting onchain record remains the place to confirm whether token movement actually occurred.

Broadcast, Pending, and Reverted States

Broadcast status means a network has received the transaction, usually identified by a hash. Pending status means the transaction has not yet reached a final successful or failed state. Sending another swap without checking the existing hash can create overlapping intentions, especially when an earlier transaction is merely delayed rather than absent.

A reverted transaction reached execution but failed its conditions. A reverted transaction does not preserve the attempted token balance changes. A reverted onchain transaction still consumes network gas. A dropped or replaced transaction is different because the original may never execute. A signed order that attracts no fill can also end without a user-submitted swap transaction, so its activity record should not be interpreted as a reverted pool swap.

How Can the Onchain Record Prove Completion?

The transaction receipt proves completion when its status is successful and its transfers match the intended network, asset identities, recipient, and execution bound. Start from the hash supplied by the wallet or activity record, then compare the decoded transaction with the quote that was accepted.

1. Confirm that the explorer is showing the selected network and the expected transaction hash.
2. Read the final status rather than relying on a pending interface notification.
3. Check which account submitted the transaction and which contract handled the call.
4. Inspect asset transfer and balance-change records for the actual input spent and output delivered.
5. Compare the delivered amount with the quoted minimum or the spent amount with the quoted maximum.

A successful status alone can be insufficient when the question is whether the intended swap occurred. Approval transactions can also succeed, and complex calls can contain several movements. The relevant proof joins status with the correct asset identities, transfer direction, recipient, and amount. That combination distinguishes completed execution from a successful preliminary permission.

Balance Reconciliation After Confirmation

Balance reconciliation explains what changed after a successful record. Compare the input reduction and output increase with the transfer details, while keeping the native network cost separate. A wallet may show a stale balance, hide an unfamiliar token, or remain connected to another network. Those display conditions do not alter the confirmed ledger state.

For an ERC-20 output, the contract address is the anchor when the asset is missing from the visible token list. Add or reveal the correct token only after matching its network and address to the receipt. If the receipt contains no expected output transfer, refreshing the wallet cannot create one. Return to the transaction record and inspect the route result, recipient, and status instead.

A Clean Stopping Point

Post-swap handling depends on the final state. A successful receipt with matching transfers needs no repeated submission; retain the hash if later reconciliation is necessary. A pending transaction calls for status review before another attempt. A reverted or unfilled attempt requires a fresh quote because the earlier route, deadline, or pool state may no longer describe available execution.

Allowance management is a separate exit decision. Disconnecting a wallet ends the interface session but does not remove an onchain token allowance. A user who no longer wants a spender to retain permission can submit a revocation on the relevant network, which itself requires a transaction and network cost. The final choice is therefore whether to keep a deliberately scoped allowance for later use or remove it.