Sushi swap is a DEX aggregator workflow from quote to output checks

From pair selection to an executable route

Four quote inputs - network, input token, output token and exact input amount - let the Sushi swap interface request an executable route without committing funds.

Selection begins on one EVM chain, where an ERC-20 asset is identified by its contract address rather than its ticker. ETH is native on Ethereum, while WETH is an ERC-20 representation with 18 decimals; Ethereum USDC uses 6 decimals. Those decimal counts convert the amount shown in the interface into the integer sent to the router. The connected account supplies the recipient and exposes its balance and allowance. Routing then compares eligible Sushi V2, Sushi V3 and external liquidity paths for that exact amount. Changing any input makes the old comparison obsolete.

A quote is read-only. It neither changes an ERC-20 allowance nor consumes gas, so refreshing after a price move carries no on-chain cost.

After a candidate route appears, the interface builds transaction data for the chosen network. That package identifies the contract call, input amount, minimum acceptable output and recipient. Native input also adds transaction value. The wallet must still be on the quoted chain and hold both the input asset and its gas token before confirmation can proceed.

Quote limits before the wallet opens

Three figures deserve inspection before any signature: quoted output, minimum received and network gas estimate, because each answers a different execution question. The Sushi quote displays a proposal, while the minimum is the enforceable floor.

Quoted output reflects pool reserves at the quoting moment. Minimum received applies the selected tolerance and is encoded into the call; execution reverts if the route returns less. A basis point equals 0.01%, so 50 basis points equal 0.5%. Price impact measures how the trade itself moves through available liquidity, while tolerance sets the range accepted between quote and execution. The gas estimate is paid in the chain’s native asset and doesn’t reduce the stated ERC-20 output.

An extremely wide tolerance enlarges the price range that the transaction accepts. Compare the minimum received with the amount that prompted the trade, then refresh if the route or pool split changes materially.

Does the route use one pool or several?

One Sushi route can use a single pool or divide the input across several pools when that combination produces a stronger executable output after routing costs. Eligible paths include Sushi V2 and Sushi V3, plus established external liquidity from Uniswap V2, Uniswap V3, Curve, QuickSwap, PancakeSwap, Camelot and Trader Joe. A multi-hop route may pass through WETH or USDC before reaching the requested token. Each extra pool adds calldata and gas work, so the largest headline pool isn’t automatically the winning path.

Wallet approval and transaction confirmation

One wallet confirmation broadcasts the swap itself, while an ERC-20 input may require one separate approval transaction before the Route Processor can spend it. Native ETH needs no ERC-20 approval.

The ERC-20 allowance model separates permission from spending. When the existing allowance is below the input amount, the wallet submits an approval to the relevant spender and waits for its receipt. That approval is an independent on-chain transaction. A Permit2-enabled path may also request a typed signature after the token has authorized Permit2. An exact allowance reaches zero after full use, while a larger unused remainder stays live until the holder changes it or later spending exhausts it.

The swap request deserves a second review after approval. Match the chain ID, sending account, contract target, transaction value and input amount. On an EIP-1559 network, the wallet shows two fee caps - maximum fee per gas and maximum priority fee per gas - alongside the gas limit. MetaMask, WalletConnect and hardware-wallet flows all end with the account’s signature over one specific transaction (see V3 Position ).

Network identity and native gas

One matching chain ID is required from quote through signature, because the same hexadecimal wallet address can exist across several EVM networks while balances and contracts remain separate. Sushi routing never moves a same-chain quote onto another chain.

Gas follows the execution network. Ethereum, Arbitrum One, Base and Optimism use ETH; Polygon PoS uses POL; Avalanche C-Chain uses AVAX and BNB Chain uses BNB. Holding USDC, WETH or another ERC-20 input doesn’t replace that native balance in a standard wallet transaction. The gas estimate also changes with route complexity and network demand, so it remains a market value rather than a fixed protocol charge.

Keep enough native currency outside the amount being sold. If ETH is both the input and gas asset, the entered amount must leave room for the wallet’s gas limit and fee caps.

Why can a fresh quote fail at submission?

One changed reserve, allowance or gas estimate between quote creation and submission is enough for a formerly valid Sushi route to fail during simulation or execution. Refreshing rebuilds the route against newer state.

Recovery follows the observable failure point. A wallet rejection creates no transaction hash, so the quote remains only a proposal. A failed preflight simulation also avoids broadcast. After an on-chain revert, confirm the selected chain, input balance, native gas and allowance, then request a new route for the same amount. Reduce the amount when no liquid path appears. If an approval succeeded in a separate transaction, it remains independent of the reverted swap and needn’t be repeated when its allowance is sufficient.

Reading pending, successful and reverted states

Three observable states - pending, successful and reverted - cover the Sushi swap transaction after broadcast and each points to a different next action. The transaction hash is the primary lookup key.

A broadcast EVM transaction receives a 32-byte hash, displayed as 64 hexadecimal characters after the 0x prefix. Pending means the network has seen the transaction but hasn’t included it in a block. The transaction also carries one nonce for the sending account. Wallet speed-up and cancellation features work by submitting a replacement with that same nonce and a higher acceptable fee, so only one version can ultimately occupy the nonce.

A pending transaction hasn’t finalized the swap. Requoting creates a new plan, but another broadcast from the same account needs nonce awareness.

A successful EVM receipt reports status 1 and preserves the token transfers and logs produced by execution. A reverted receipt reports status 0, rolls back the swap’s state changes and still consumes gas for work performed. The earlier approval receipt remains separate when approval and swap used two transactions.

When a replacement occurs, inspect the receipt attached to the transaction that actually consumed the nonce. That record determines whether to check output or rebuild the quote.

How do you prove the output arrived?

Two checks prove whether Sushi swap delivered the expected asset: the successful transaction receipt and the recipient’s balance change for the exact output contract. A wallet’s token list is only a display layer.

An ERC-20 transfer event records two indexed addresses and a 256-bit value, which an EVM explorer decodes into sender, recipient and amount. Decimal metadata then formats that integer for people: WETH uses 18 decimals and Ethereum USDC uses 6. A token can be absent from MetaMask’s visible list even though its balance changed on-chain; adding the correct contract reveals it. Native ETH output uses a balance transfer rather than an ERC-20 event, so the same account’s gas payment must be separated from the received amount.

Compare the credited output with the transaction’s minimum received field, not with a stale quote left open in another tab. Also distinguish ETH from WETH: they represent related value but occupy separate native and ERC-20 balances. The receipt, exact token contract and recipient balance close the workflow with evidence from the executed call.

Fixed identifiers that keep checks grounded

Four fixed EIP-155 chain identifiers anchor the Sushi swap network check: Ethereum uses 1, Arbitrum One uses 42161, Base uses 8453 and Polygon PoS uses 137.

An EVM address contains 20 bytes and appears as 40 hexadecimal characters after the 0x prefix. A transaction hash contains 32 bytes and appears as 64 hexadecimal characters after that prefix. Those shapes look alike at a glance, yet they answer different questions: an address identifies an account or contract, while a hash identifies one transaction. EIP-55 mixed-case checksums help catch mistyped addresses, but the chain ID still determines which deployment and balance the address refers to.

Matching the chain ID first tells you which token contract, gas balance and transaction record belong to the swap.

Route Processor execution under the interface

One Route Processor transaction carries the selected path, input amount, minimum output and recipient into EVM calldata that executes atomically on the chosen chain. Either the call completes or its state changes revert together.

A standard EVM contract call begins with a 4-byte function selector. ABI-encoded arguments occupy 32-byte words, while dynamic route bytes describe the pool sequence and any split. The processor pulls approved ERC-20 input or accepts native value, invokes the specified pools and sends the resulting token to the recipient. The minimum-output check runs inside that call. If any leg can’t satisfy the encoded conditions, the transaction doesn’t leave a partial pool sequence behind.

Route discovery occurs off-chain, but settlement is enforced by contracts on the selected network. The wallet signature authorizes the exact call data, nonce and fee settings that get broadcast. Reading the final receipt and output balance then tests what executed rather than what the earlier quote predicted.