Three approval checks that can stop a cross-chain swap

A cross-chain swap can stop before routing if the wallet has not authorized the source-chain contract to spend the token being swapped. That permission is separate from the swap itself: an approval transaction grants spending access, while a later transaction submits the trade. A route can therefore look ready in an interface and still fail at the wallet or on-chain step. Readers comparing a Bitcoin-to-Ether route can see the broader flow in thor swap; the narrower question here is why a token permission blocks the first leg.

Why does a cross-chain swap need token approval?

An ERC-20 token contract needs an allowance before another contract can move tokens from a user’s address. The ERC-20 standard describes this as an owner approving a spender for up to a stated amount, after which the spender can use transferFrom. In a swap, the spender is commonly a router or another contract in the route. The token stays in the user’s wallet until the swap executes, but the allowance gives that designated contract permission to take some or all of it.

This makes the flow different from sending a native coin such as ETH directly with a transaction. Native ETH does not use ERC-20 allowances; an ERC-20 token on the same network usually does. A wrapped version of a native asset is a token contract, so it can require approval. A cross-chain route does not change this rule: the relevant permission is generally for the token and spender handling the source-chain leg. An approval on the destination network does not authorize a contract on the source network.

Some tokens and interfaces support signed approvals, such as the permit mechanism specified in ERC-2612. That can combine authorization with a swap flow and avoid a separate on-chain approval transaction, but support depends on the token and the route. It does not remove the need to authorize a spender; it changes how the authorization is delivered.

Which three approval checks should you make?

Check the source network, the spender address and the allowance amount before treating an approval prompt as a routine step. These checks distinguish a missing permission from a routing or pricing problem.

• Network and token: Confirm the wallet is on the network where the source token is held, and that the selected token is the asset the route will spend. A matching ticker or token name on another network is not the same contract or balance.
• Spender: Compare the address in the wallet’s approval request with the spender shown by the swap interface, where available. The spender may be a router or route contract, and it can differ between services or routes. An allowance for one address does not cover another.
• Amount and status: Make sure the allowance covers the amount being swapped and that the approval transaction has confirmed. A pending, rejected or reverted approval has not created usable permission. If the route or amount changed after the approval was prepared, check again rather than assuming the earlier request still fits.

These checks matter because wallet connection and token approval are different permissions. Connecting a wallet shares access to public address information with a site; it does not itself allow a contract to transfer tokens. Conversely, disconnecting later does not erase an allowance already recorded on-chain. The allowance is tied to the token, owner, spender and amount, not simply to whether the site remains connected.

Should you approve the exact amount or a larger allowance?

An exact-amount approval limits what the spender can take under that allowance, while a larger or unlimited approval can reduce repeated approval prompts for later swaps through the same spender. The trade-off is convenience against the duration and size of the permission. ERC-20 allowances do not generally expire by default; the user can reduce or revoke one with another on-chain transaction, which uses network gas.

For an occasional swap, approving only the planned amount is a reasonable default because it limits the permission if the spender is later compromised or misused. Frequent users may prefer a larger allowance to avoid approving each trade, but should recognize that it remains available until consumed or changed. Check the actual allowance before adding another: ERC-20’s approve function sets the allowance for that spender, rather than simply adding the new value to the old one. Some token contracts also have approval behaviors that make a failed approval require a different sequence, so repeated retries without checking the transaction can waste gas.

An approval is not evidence that the swap will succeed. Once the allowance is in place, the trade can still fail for reasons outside token permission, including a changed route, insufficient balance, price movement or network conditions. Keep the distinction clear: an approval failure points first to the token, spender and allowance; a swap failure after approval calls for checking the trade transaction and its route.

Before retrying, watch three signals: whether the approval transaction confirmed on the source network, whether the on-chain allowance covers the current route’s spender and amount, and whether the swap quote is still valid. If those line up, another approval is unlikely to fix a failure in the later swap step.