Why a token approval must confirm before a source deposit

A token approval must confirm before a source deposit when the deposit contract will pull ERC-20 tokens through an allowance. The approval transaction changes the token contract’s recorded allowance; the deposit transaction then relies on that state to call transferFrom. If the deposit executes first, or the approval is still pending, the allowance may be too small and the deposit can revert.

These are separate on-chain actions in the common allowance flow. A wallet may show them as consecutive steps, but submitting one does not make its state available to the next transaction immediately. For the separate question of choosing a Quickswap route from your wallet, see the route-selection guide. The route determines which contracts and assets are involved; the token approval still has to authorize the spender that will take the source tokens.

What does a token approval authorize?

An ERC-20 approval sets an allowance for a specific spender address. The token contract records how much of the owner’s tokens that spender may transfer. In a bridge flow, the spender is typically the source-side contract that receives or routes the deposit, though the address depends on the selected route and its implementation.

The approval does not move tokens. It grants the spender permission to call the token contract’s transferFrom function, which moves tokens from the owner’s address when the spender’s later transaction executes. The deposit call can therefore succeed only if the allowance covers the amount requested and the owner still has enough balance.

Approval amounts vary by interface. An exact approval covers the intended deposit amount; an unlimited approval authorizes the spender to transfer up to the token’s maximum allowance until that permission is used or revoked. Exact approval narrows the permission granted, but can require another approval for a later deposit. Unlimited approval can reduce repeated transactions, while leaving a larger allowance in place. The relevant spender is the contract address shown for the transaction, not simply the name of the bridge or route.

Why must the approval confirm first?

Each transaction executes against the state available when it is included in a block. A submitted approval is not yet part of that state. If the deposit transaction is sent before the approval is included, the deposit contract’s transferFrom call reads the previous allowance. It can fail for insufficient allowance even if the approval appears as pending in the wallet.

Waiting for the approval receipt before submitting the deposit establishes the ordering: first the token contract records the allowance, then the deposit call consumes it. A wallet or app may automate that sequence, but it still needs to detect the approval’s on-chain result before treating the deposit as ready. A pending indicator is not the same as a successful receipt. Some applications also wait for additional confirmations to reduce the chance that a reorganization removes the approval after it appears in a block.

If the approval reverts, is dropped, or is replaced by another transaction with the same account nonce, the allowance may not change. The deposit should not proceed on the assumption that it did. If the approval succeeds but the deposit later fails, inspect the allowance and balance as well as the selected spender and deposit amount; a mismatch in any of them can produce a similar failure.

When can a deposit avoid a separate approval?

A separate on-chain approval is not required in every token flow. A token and deposit contract may support a permit mechanism, such as an EIP-2612-style signature, that authorizes an allowance off-chain. The deposit transaction can submit that signature and perform the transfer in the same call. This changes the transaction sequence, but it still requires valid authorization for the correct spender and amount. Support depends on the token and the contract handling the deposit.

Native assets also do not use ERC-20 allowances. A deposit of the chain’s native currency transfers value with the transaction rather than asking a token contract to approve a spender. Wrapped versions of that asset are ERC-20 tokens, so they generally follow the allowance flow unless another authorization mechanism is supported.

Before confirming, check the token, amount, spender, and transaction order. The spender should match the contract that needs to pull the source asset for the selected route. When the flow uses a standard approval, wait until that approval succeeds on-chain before sending the source deposit. The key distinction is simple: approval changes permission; deposit uses it.