Exchange is a SushiSwap Pending Swap Diagnosis and Onchain Output Verification Workflow

Exchange is the SushiSwap operating workflow for turning a displayed quote into a wallet-signed onchain trade, then separating a pending submission from a confirmed receipt and checking the tokens delivered. The decisive evidence is the transaction hash: it identifies the network transaction, its nonce, destination contract, status, logs, gas use, and block, while the recipient’s token balance confirms the final output.

Diagnosis starts with the quote snapshot and the active chain, continues through the wallet request, and ends at the receipt and ERC-20 balance change. Each layer answers a different question, so a missing spinner or stale wallet display never carries the entire verdict.

An approved allowance is only the first transaction; the swap still needs its own broadcast and receipt.

A USDC-to-WETH swap that stays pending

One transaction hash is the decisive clue when a USDC-to-WETH trade remains pending after SushiSwap wallet confirmation.

A wallet such as MetaMask or Rabby separates three moments the interface may compress into one status. Signing authorizes data, broadcasting gives the transaction a hash, and block inclusion creates a receipt. No hash means there is no stable submission to query. A hash with no receipt means the network has not included that transaction. A receipt ends the pending phase, even when its status reports failure. This distinction prevents an approval receipt, a rejected swap request, and a mined trade from being read as the same event.

Ethereum uses chain ID 1, Arbitrum One 42161, Base 8453, OP Mainnet 10, and Polygon 137.

Search the hash on the explorer for the selected chain, such as Etherscan, Arbiscan, or Basescan. A missing result on one explorer frequently points to a network mismatch, not a vanished transaction. Once the correct chain is established, the next decision is whether to wait for inclusion, replace the pending nonce, or inspect an existing receipt.

Read the quote before opening the wallet

Four fields preserve a usable SushiSwap quote: chain, token contracts, exact input, and enforceable minimum output.

Token identity and units

Token identity comes from its contract on the selected chain, not from the ticker alone. An EVM address is 20 bytes, displayed as 40 hexadecimal digits after the 0x prefix. USDC uses 6 decimals on Ethereum, while WETH and DAI use 18. Therefore, 125 USDC enters contract calldata as 125,000,000 base units, whereas 0.75 WETH appears as 750,000,000,000,000,000 units. Copying a human-readable amount into a base-unit field changes the order of magnitude. That thread continues in Sushiswap exchange overview.

Route and minimum output

SushiSwap Route Processor 7 selects executable liquidity paths and may combine Sushi pools with external venues. A Sushi v2 pool charges 0.3%, while Sushi v3 defines fee tiers of 0.01%, 0.05%, 0.3%, and 1%. Those pool fees influence the quoted output, but the enforceable protection is the minimum output encoded for the transaction. A fresh quote may choose another route as reserves, gas estimates, or available pools change; the signed calldata preserves the route and bounds used for that submission.

Worked quote snapshot

The changing inputs in this hypothetical exact-input example are a 0.750000 WETH quote, 0.50% tolerance, 180,000 estimated gas, and a 20 gwei maximum fee. The minimum output is 0.750000 × (1 − 0.005) = 0.746250 WETH. The wallet’s maximum gas cap is 180,000 × 20 gwei = 0.0036 ETH, although unused gas is not charged. Save the quote and wallet request together, because this calculation separates an output bound from a gas ceiling.

What does the wallet confirmation actually authorize?

A separate explanation covers Sushiswap exchange walkthrough. Two distinct actions may reach the wallet: an ERC-20 allowance change and the swap transaction itself.

An allowance lets a spender contract call transferFrom up to the approved amount; it does not execute a route or preserve a quote. Native ETH input needs 0 ERC-20 approvals, while a first use of USDC may create 1 additional transaction before the swap. Route Processor 7 does not store user token approvals directly in the processor. Compare the connected account, chain ID, destination, token amount, and native value with the quote before signing. An approval receipt alone is not a trade receipt.

On EIP-1559 networks, the common type 2 envelope contains 12 top-level fields, including the chain ID, nonce, fee caps, gas limit, destination, value, calldata, access list, and signature parts. The first 4 bytes of calldata select the contract function. After broadcast, preserve the resulting hash. Without that hash, a wallet confirmation screen has not produced a trackable onchain submission.

Pending, replaced, and confirmed states

Three SushiSwap transaction states - no hash, hash without receipt, and hash with receipt - separate interface delay from onchain execution.

No hash after confirmation

A missing hash keeps diagnosis inside the wallet and RPC submission layer. Check the wallet activity record, active account, active network, and native gas balance. If only an approval has a hash, return to the exchange quote and submit the swap itself. Repeating the approval does not advance the trade.

Hash without a receipt

A pending hash identifies a nonce the network has not yet included. Ethereum divides time into 12-second slots and groups 32 slots into a 6.4-minute epoch, although inclusion is not guaranteed in the next slot. A speed-up or cancellation request uses the same account nonce with replacement fee settings; it does not erase the first signed payload. Track both hashes, because only the included replacement determines the final state. Submitting fresh swaps with later nonces complicates recovery when an earlier nonce remains unresolved.

Receipt status and replacement

An EVM transaction receipt records status 0x1 for success or 0x0 for failure after block inclusion. A typed EIP-1559 receipt payload carries 4 core entries: status, cumulative gas used, logs bloom, and logs. Status 0x0 means state changes reverted, while the network still charged gas for execution. Status 0x1 moves the investigation to emitted events and balance changes, which decide whether the expected output reached its recipient.

How do you prove the output reached the right address?

A 32-byte transaction hash anchors the receipt, but the recipient’s balance delta proves the token output.

The displayed hash contains 64 hexadecimal digits after 0x and identifies one transaction within its chain. Start with receipt status 0x1, then match the sender, destination contract, and block. Next, inspect ERC-20 logs from the actual output-token contract.

The standard Transfer event declares 2 indexed addresses - sender and recipient - and a 256-bit value. Topic 0 holds the event signature, so a normal ERC-20 transfer log has 3 topics and stores the amount in its data field.

For WETH output, compare the wallet’s balanceOf value immediately before and after the receipt block, then divide the base-unit difference by 10 ¹⁸ . For USDC output, divide by 10 ⁶ . An eth_call balance query changes no state and costs 0 gas when called externally. This direct contract read resolves stale wallet indexing, hidden-token displays, and rounded interface values without submitting another transaction.

Native ETH output follows a different record. It has no ERC-20 Transfer event, so compare the address’s native balance around the block and account for gas paid by the sender. The route receipt and recipient balance then provide the execution and delivery evidence needed for the next action.

Recovery paths for concrete failure states

Six recovery checks cover nearly every same-chain SushiSwap interruption without treating the interface message as the final record. Exchange recovery begins at the earliest broken layer, so the next request stays tied to evidence.

Quote or chain mismatch

A quote tied to Ethereum cannot execute on Base, even when both networks display ETH as the gas token. Reconnect the intended account, select the chain matching the quote, confirm the input token contract, and request a new route. If Route Processor 7 returns no executable path, change the amount or pair rather than signing unrelated calldata.

Approval confirmed, swap absent

An approval with status 0x1 changes allowance and stops there. Return to the quote, confirm the allowance covers the exact input, and submit the separate swap request. If a swap hash already exists without a receipt, work with its nonce instead of creating repeated trades. MetaMask and Rabby expose speed-up or cancellation controls for eligible pending EVM transactions, and both actions create a replacement candidate.

Reverted trade or unseen output

A receipt with status 0x0 requires a new quote because its state changes did not persist. Common contract-level causes include an expired deadline, a minimum output the route no longer satisfies, or an insufficient allowance. A receipt with status 0x1 requires no duplicate swap: switch the wallet to the receipt’s chain, import the exact output contract when needed, and query its balance. The earliest broken layer determines the next decision - refresh the quote, finish submission, replace the nonce, or reconcile the confirmed balance.

Recovery ends when the receipt and exact token balance agree; only then does a later swap become a separate transaction.

Details worth knowing about Exchange