Uniswap swaps become final onchain, and their records show how to verify them

On EVM networks, a direct Uniswap swap moves from a quote to a signed transaction, a pending transaction, and an onchain result. Before inclusion, a direct transaction may still be replaced, or its swap conditions may expire. After successful execution and network finality, the original swap can't be edited, cancelled, or refunded by the interface. Verify the transaction record, token transfer logs, selected network, recipient, and wallet balances before considering a new swap to correct an unwanted result.

Quotes, signatures, hashes, and receipts answer different questions

Four pieces of information can surround one direct EVM swap, and each answers a different question. A quote estimates the output under current pool and routing conditions. The signed transaction records the action the account authorized, while the wallet prompt previews that action before signing. The transaction hash identifies the signed transaction. After processing, the receipt records block inclusion, execution status, gas used, and emitted logs.

None of the earlier records proves the later stage occurred. A quote can change before execution, while a signature may authorize an approval or order without moving tokens. Even a transaction hash proves only that a particular payload exists. Completion requires a successful onchain record, followed by balance and transfer evidence consistent with the intended swap.

The direct EVM path moves from wallet review to receipt and finality

A successful receipt is onchain evidence that a direct swap executed. Before signing, review the selected network, token contract addresses, input amount, minimum acceptable output, recipient, and call details presented by the wallet. If spending authorization is required, it must finish before the swap call can use the input tokens.

Broadcasting moves the transaction into a pending state. The network may include it, a replacement may supersede it, or its encoded conditions may cause execution to revert. A displayed quote remains a preview during this interval. Pool state, available liquidity, the route, and network fee conditions can move before a validator or sequencer processes the call.

After inclusion, the execution status answers whether the top-level call completed. Transfer logs and balances then show what moved. A first confirmation establishes inclusion, while stronger finality depends on the selected network's consensus rules. The transaction can't be rewritten after it enters finalized history.

Can a confirmed Uniswap swap be reversed?

A successfully executed swap can't be pulled back by an interface control. The confirmed transaction changed onchain state according to the signed call and the conditions enforced during execution. Network finality makes that history resistant to reorganization, but the original action is already outside the interface's control once it has executed successfully.

An unwanted output can only be addressed through a new action, such as swapping the received token again. That corrective swap receives its own quote, authorization, transaction hash, execution price, and network cost. It doesn't erase the first record or guarantee restoration of the original amount because pool conditions and fees may have changed.

A pending EVM transaction may still be replaced before inclusion

A pending transaction hasn't produced a settled swap result.

First determine whether the network received it. A wallet can show local activity while a block explorer still has no matching record, particularly after a broadcast or connection problem. Search the correct network by transaction hash and sending address. An absent record doesn't prove success or failure.

On a nonce-based network, a wallet may offer to speed up or cancel a pending transaction. Speeding up normally submits a replacement with the same nonce and more competitive fee terms. A cancellation is also a replacement, commonly carrying no swap call. It succeeds only if the network includes it before the original transaction.

If the original swap is included first, a later replacement can't undo it. If the replacement is included first, the original can't execute unless a chain reorganization removes that replacement. Wallet implementations and network rules differ, so the replacement's own status matters more than a button press or local notification.

A transaction included after its deadline or outside its minimum output condition may revert instead of swapping. Submitting another trade with a different nonce while the first remains viable creates a separate risk: both transactions may execute. Reconcile the first hash, nonce, and status before authorizing another attempt.

The receipt separates block inclusion from swap success

A block can contain either a successful swap or a reverted attempt. The receipt distinguishes those outcomes and anchors them to a specific transaction hash and block.

Status and block placement

A transaction receipt becomes available only after the transaction has been included in a block. Until then, a hash identifies a submitted request, not a completed state change.

Successful execution

A successful status means the top-level transaction finished without reverting. It doesn't prove the token was the intended contract, the recipient was correct, or the economic result matched an earlier quote. Check the executed input and output amounts, contract addresses, recipient, and emitted transfers before treating the status alone as sufficient.

Reverted execution

A failed status means the network included the transaction but rolled back the swap's state changes. The input token shouldn't have moved through that reverted call, although a separately completed approval may remain. The sender's nonce is consumed on nonce-based networks, and the network can still charge for the computation used before failure.

Transfer logs and the call path

Transfer logs connect the successful call to the actual token movements. Compare each token contract, sender, recipient, and raw amount, applying the token's decimal precision when reading displayed units. The call target may be a router rather than the final recipient, so examine the decoded operations and resulting transfers together. Transaction hashes and public addresses are safe to search; recovery phrases and private keys are never needed for verification.

Wallet balances complete the reconciliation

Balance reconciliation should use the same network and token contracts shown in the transaction record. After success, the input balance should fall and the output balance should rise by the executed amounts, subject to each token's transfer behavior. The network's fee asset may also decrease. If the output is missing from the wallet display, compare the onchain balance and contract address before acting. A stale cache or hidden asset can obscure a completed transfer without changing chain state.

Reverts and dropped transactions require different responses

A reverted transaction was processed, failed its execution conditions, and produced a receipt. Common swap-specific causes include an expired deadline, an output below the encoded minimum, incompatible token behavior, or an execution error in the selected path. The state transition rolls back, but the processing cost may remain. A new attempt therefore needs a fresh quote and a review of the failed condition.

Open full-size image

A dropped transaction has no confirmed receipt. It may have been rejected, removed from a node's pending pool, replaced, or never propagated successfully. Copies can also persist elsewhere for a time. Check the sending account's confirmed nonce and transaction history before assuming the request can no longer appear or before submitting the same economic action again.

Approvals and batched actions need separate interpretation

An approval and a swap may create separate records. An onchain approval changes the allowance available to a designated contract and has its own transaction hash. A permit signature can authorize a later call without producing a receipt by itself. If a separate approval succeeds and the swap later reverts, the allowance may remain available until it expires, is used, or is revoked under its own terms.

Batched actions can place an approval-related operation and a swap inside one submitted transaction. Inspect the actions encoded in the batch, its final status, and the resulting logs. A successful top-level label shouldn't replace that review, especially when the wallet presents several actions in one confirmation screen.

Signed orders and crosschain routes add another status layer

Some routes begin with a signed order rather than a direct swap transaction funded by the sender. Before an order is filled, it may remain open, expire, or be cancelled under its terms. A submitted cancellation can race with a fill, so the order isn't safely closed until the cancellation takes effect or the order expires. After a fill, the onchain fill transaction and resulting balances become the completion evidence.

A third-party filler may submit the execution transaction and pay much of its direct network cost. That arrangement doesn't make the signature itself a final swap. Earlier approval or wrapping actions can still have separate costs and records. Verification must follow the fill transaction rather than searching only for a transaction sent by the swapper's address.

Crosschain execution adds source and destination states. A successful source transaction can coexist with a destination step still in progress. Confirm the source action, the bridge or messaging status, and the destination transfer on their corresponding networks. Repeating the whole swap before locating the unfinished stage can create a second independent action.

The verified state determines the next action

If the record remains pending, resolve or replace that transaction before creating another. If it reverted, identify the failed execution condition and obtain a fresh quote. If it succeeded, reconcile the contracts, transfers, recipient, and balances. Only then can a new corrective swap be evaluated as a separate transaction under current pool and network conditions.

Helpful answers about Uniswap