Approval clears the allowance, not the swap

A token approval lets a designated contract spend tokens from your wallet; it does not guarantee that the swap you submit afterward will succeed. That distinction matters because a swap usually has two separate steps: first, permission is granted, then a transaction attempts to trade under a particular quote and set of limits. Compared with a single action that bundles approval and trading, the separate steps give you more control over what a contract may spend, but leave time for the quote, available liquidity or transaction conditions to change.

The approval is an allowance recorded by the token contract, commonly for a particular spender address and an amount. The swap then asks that spender, often a router or an aggregator, to use the allowance while carrying out the trade. A successful approval proves only that the permission transaction took effect. It says nothing about whether the later transaction has enough gas, can find a usable route or can deliver the minimum output you accepted. For a fuller account of how router costs and older liquidity affect a swap on one venue, see biswap.

What does token approval actually authorize?

An approval authorizes a spender to transfer up to a specified quantity of a token from your wallet, subject to the token contract’s rules. It does not move the tokens by itself, and it does not authorize every contract on the network. The spender shown in the wallet should match the contract that will execute the swap; an approval to one address does not automatically satisfy a transaction routed through another.

Some interfaces request an allowance for the exact trade amount, while others ask for a much larger or effectively unlimited allowance so that later trades do not need another approval transaction. The convenience is real: fewer transactions can mean less waiting and fewer approval fees. The trade-off is that a large allowance gives that spender room to transfer more of the token later, if the contract is compromised or behaves unexpectedly. A smaller allowance limits that exposure but may require another approval when you trade again.

Approval can also fail or become irrelevant. The transaction may still be pending, may have reverted, or may have been sent on a different network from the one the swap uses. A token can impose transfer restrictions, and its allowance behavior may differ from the standard pattern. Before retrying, check the approval transaction’s status, the selected network, the token, the spender address and the remaining allowance. Repeatedly approving the same amount will not fix a swap whose failure comes from its quote or route.

Why can a swap fail when approval succeeded?

A swap is a new transaction with its own execution conditions, and the most common mismatch is between the quote and the market when the transaction runs. A quoted output is an estimate based on the route and liquidity available at that moment. If the price moves before execution, the transaction may fall below its minimum-output limit and revert. Raising the slippage tolerance can allow a wider price move, but it also accepts a worse result; it does not add liquidity or make the route safer.

Other failures arise from the path the trade takes or from the token itself. A route may no longer have enough liquidity at the quoted price, a pool may not support the needed trade, or a token may charge a transfer fee that changes how much reaches the pool. Some tokens also restrict transfers or trading. In these cases, the wallet may show a valid approval while the router cannot complete the requested exchange. The precise reason is often in the transaction’s revert message or simulation, though some wallets expose only a generic failure.

Network conditions add another layer. The swap can be submitted with too little gas, a stale deadline, or a nonce that is blocked behind an earlier pending transaction. A transaction on the wrong chain cannot use an allowance recorded on the intended chain. If it reverts after being included on-chain, the trade does not complete, but the network fee for executing the failed transaction is still spent. An approval may remain active after the swap fails, so check the allowance before deciding whether another approval is needed.

What should you check before trying again?

Start with the failed swap’s status and details rather than immediately signing the same request again. A pending transaction, a reverted transaction and a transaction that never reached the network call for different responses. If it reverted, read the reason if available; if it is pending, review the nonce and fee options in your wallet. Then compare the token, network, spender and allowance with the transaction you are about to submit.

• Confirm the swap is on the network where the tokens and allowance are held.
• Check that the approval succeeded and covers the token amount the spender needs.
• Refresh the quote and review its route, minimum output and deadline.
• Check token transfer rules and the transaction’s gas estimate or failure details.

If the refreshed quote is materially different, decide whether the new minimum output still makes the trade worthwhile. Do not keep widening slippage simply to force a transaction through: the setting defines how much worse an execution you will accept. If the route or token behavior remains unclear, a smaller test trade can limit the amount at stake, though it still incurs its own fees and may not expose every failure that a larger trade would.

Is it better to approve once or before each swap?

For most readers, approving only the amount needed for a planned trade is the clearer default: it narrows the spender’s authority while making the cost of another approval explicit. A longer allowance can be reasonable for a spender you already trust and use often, especially when repeated approval fees or delays matter, but it should be an intentional convenience rather than a fix for failed execution. Revoke or reduce allowances you no longer need where the token and wallet support it.

The practical takeaway is that approval and execution answer different questions: permission asks whether the spender may use your tokens, while the swap asks whether the trade can execute now at acceptable terms. Watch the allowance and spender, the refreshed quote and minimum output, and the transaction’s status or revert reason. Those signals show whether the problem is permission, market conditions or the route itself—and whether another attempt changes the conditions that caused the first one to fail.