The wrong belief is simple: a SushiSwap quote is a completed trade. It is not. A quote is a conditional execution plan, and the trade exists only after a signed transaction is accepted, included and executed by the selected blockchain. The other wrong idea is that SushiSwap has one universal price. Routes, pools, chain conditions and liquidity can all change the result.
A quote is only a conditional plan until the chain accepts it
SushiSwap is the exchange protocol and interface; SUSHI is its token. The protocol uses automated market makers and liquidity sources rather than a centralised exchange’s matching engine. That distinction matters: a centralised exchange can fill an order inside its own ledger, while SushiSwap must call smart contracts on a particular network.
The normal sequence is quote, wallet approval, signature, broadcast, pending transaction, inclusion in a block, contract execution and receipt. A green button in the interface proves only that a transaction has been prepared. A wallet prompt proves only that the user signed it. Neither proves settlement.
The live SushiSwap interface should be checked for the selected chain, token addresses, route, minimum received and estimated network fee immediately before signing. Those values belong to the transaction being prepared, not to a permanent market state.
The screen can change before the signed transaction does
A serious quote has several separate numbers. The quoted output is the estimated amount at the time of calculation. Minimum received is the lower bound allowed by the slippage setting. Price impact measures the effect of the trade against available liquidity. Network gas pays the chain for execution. Protocol or pool fees reduce the output separately from gas.
Sushi’s general explanation describes a standard 0.3% same-chain swap fee, with 0.25% attributed to liquidity providers and 0.05% to qualifying SUSHI stakers; pool versions, routes and products can differ, so the displayed transaction details take priority over a remembered percentage. The published fee explanation is the relevant reference for that standard split.
A moving quote, a changed gas estimate, a refreshed route or a warning that minimum received has fallen is normal before signing. A price-impact warning is not automatically a hidden fee; it usually indicates that the selected liquidity is shallow relative to the trade. Slippage tolerance is not an expected loss either. It is the maximum movement the contract will accept before reverting.
When the market moves beyond that tolerance, “insufficient output amount” or an equivalent revert is the correct protection. The swap did not complete, although an included failed transaction can still consume gas.
Approval and swap are separate transactions only when token permissions require it
An ERC-20 token commonly needs an allowance before a router can spend it. The first transaction grants that permission; the second performs the swap. Two wallet confirmations are therefore normal for a first-time token, while a later trade may require only the swap transaction if sufficient allowance remains.
Native gas assets do not use the same ERC-20 approval flow. Some wallets and token contracts also support permit-style signatures that combine permission and execution. The decisive evidence is the wallet action and the transaction receipt, not whether the interface shows one button or two.
An approval marked successful does not mean the swap succeeded. It means only that the allowance was written to the token contract. The swap can still fail because of an expired quote, inadequate balance after gas, a wrong network, changed liquidity or a route-specific contract condition.
Pending is a state, not a verdict, while confirmation is only the next checkpoint
On a network such as Ethereum, a broadcast transaction first enters the transaction pool. “Pending” means that the network has not yet included it in a block; it does not mean that SushiSwap is still privately processing the trade.
| Displayed state | What it means | What is normal |
|---|---|---|
| Quote ready | No transaction has been sent | Rates and routes may change |
| Approval pending | The allowance transaction awaits inclusion | Short delay; swap cannot use it yet |
| Swap pending | The signed call awaits inclusion | One or a few blocks on a responsive chain |
| Confirmed or successful | The contract call executed and emitted a receipt | Verify balances and received-token amount |
| Failed or reverted | The call was included but state changes rolled back | Gas may still have been spent |
| Dropped or replaced | The original transaction was not included | Nonce or fee handling may require attention |
Confirmation time follows the chosen chain, its congestion and the fee policy shown by the wallet. A receipt is stronger evidence than a spinning interface, but finality can require additional blocks. A cross-chain swap adds another wait: the source transaction may succeed while the destination-side delivery remains pending. That is normal for a multi-stage route, but the interface’s estimate and provider status should govern the expected window.
These signals separate a normal delay from a broken transaction
-
A quote changes before signing: normal; recalculate and inspect minimum received.
-
An approval remains pending for a short period: normal; inspect the explorer before acting.
-
A swap remains pending beyond the chain’s ordinary inclusion window: investigate the transaction hash, nonce, RPC connection and fee settings.
-
The explorer shows success but the interface shows the old balance: usually a stale display or wrong network view; verify the receipt and token contract.
-
The explorer shows reverted: no completed swap occurred; identify the revert reason before resubmitting.
-
A cross-chain source leg succeeds but the destination leg is absent after the stated route window: check the bridge or routing provider’s status, and avoid blindly submitting a second swap.
Repeatedly pressing Swap is not a recovery method. A pending transaction may already occupy the wallet nonce, and a second submission can create confusion or replace the first transaction. The transaction hash, chain explorer and wallet nonce establish what actually happened.
The trade venue should follow the control the trade requires
For a routine wallet-to-wallet trade, on-chain settlement, access to supported tokens and direct control of assets, the SushiSwap route is the better fit. It leaves execution visible on the selected network and avoids depositing funds with a centralised intermediary.
A centralised exchange is usually the better choice when fiat funding, internal transfers, a conventional order book, advanced custodial controls or guaranteed support for a particular asset matters more than self-custody. SushiSwap does not remove market risk, liquidity risk, contract risk, gas cost or execution delay; it makes those conditions part of the transaction itself.
The accurate picture is therefore narrower and more useful: SushiSwap is not an instant price screen and not a single exchange ledger. It is a route from a live quote to a blockchain state change. The numbers before signing describe what may happen; the receipt and resulting balances prove what did.