A nonce queue delays an approval until earlier transactions from the same account clear. For a treasury, the wait can be seconds or indefinite: the decisive factor is the oldest unresolved nonce on that chain, not the approval’s own gas estimate.
Why can an approval be stuck behind another transaction?
An EOA’s nonce is a sequential counter for transactions on one chain. A node can include nonce 42 only after nonce 41 has been included, so a slow payout, underpriced swap, or failed-to-propagate transaction can hold up every later transaction from that address on that chain. Ethereum’s transaction documentation describes the nonce as the account’s sequential transaction counter.
An ERC-20 approval is an on-chain transaction calling approve(spender, amount); it changes the token’s allowance when executed. If a treasury signs a payout at nonce 41 and an approval at nonce 42, the approval cannot execute first even if it offers a higher fee. For a cross-chain payment or treasury rebalance, a thor swap service handles the asset move and swap across chains in one flow, but any required EVM approval still waits on the source account’s nonce queue.
The queue is local to the account and chain. A pending Ethereum transaction does not block the same address on an L2, and a Bitcoin transfer has no EVM nonce queue. Teams using thor swap should therefore check the source-chain account’s pending transactions before diagnosing a cross-chain route as slow.
How long does the queue take, and what can you do?
There is no fixed delay. If the head transaction is adequately priced and the network is processing it, the approval may follow after one inclusion interval; if the head transaction is underpriced, dropped by a node, or repeatedly replaced incorrectly, later nonces can remain blocked for minutes or much longer.
For example, suppose nonce 41 is a payout sent with a max fee below current base fee, while nonce 42 is a token approval with a competitive fee. Before: the approval sits queued because 41 is not executable. After: the operator replaces 41 using the same nonce and a fee high enough for current conditions, or cancels it with a same-nonce self-transfer; once 41 is included, 42 becomes eligible. A cancellation is not guaranteed until the replacement is mined.
Replacement rules are client and network dependent. Geth’s transaction-pool documentation describes replacing a transaction with the same sender and nonce at a higher gas price; under EIP-1559, wallets may need to raise both max fee per gas and priority fee to satisfy node policy. Check the nonce and fee fields against the chain’s current base fee, and avoid signing additional transactions from the same account until you know which nonce is next.
If the approval itself reverts, it still consumes its nonce once included; inspect the receipt and allowance before resubmitting. ERC-20’s EIP-20 specification says a new approval overwrites the spender’s existing allowance, and some tokens require setting allowance to zero before changing it. A failed approval can therefore mean a token-specific allowance rule, not a queue delay.
How should a treasury prevent approval delays?
Separate operational flows by signer where policy permits, and reserve a small number of addresses for predictable payout batches. Before a recurring cross-chain transfer, reconcile each EVM address’s confirmed and pending nonce with a trusted RPC, verify native-token gas balance, and confirm whether the exact spender already has sufficient allowance. Reuse of a dedicated signer improves nonce hygiene but concentrates key and balance risk.
For frequent transfers, use the narrowest practical allowance and plan for a separate approval transaction when the token does not support signed approvals. Permit-style approvals can avoid the standalone on-chain approval when both token and application support them, but support is not universal. I would favor a dedicated signer and explicit pending-nonce monitoring over blanket unlimited approvals: it makes blocked work easier to isolate while limiting the allowance at risk.
Does a pending approval block transactions on other chains?
No. EVM account nonces are tracked independently on each chain, so an Ethereum queue does not block that address’s transactions on Arbitrum or BNB Smart Chain. The same key may be used on multiple chains, but each chain has its own account state and pending transaction pool. Check the chain where the approval was submitted.
Can I speed up an approval by sending it again?
Only if the replacement uses the same sender and nonce and satisfies that network’s replacement fee policy. Resending with a higher nonce adds another queued transaction; it does not bypass the earlier one. Wallet labels such as “speed up” usually attempt a same-nonce replacement, but confirm the nonce before signing.
Does a reverted approval leave the nonce available?
No. Once a transaction is included, its nonce is consumed even if execution reverts. The allowance may remain unchanged, so inspect the transaction receipt and token allowance before retrying. A retry must use the next valid nonce and may need different calldata or allowance handling if the token enforces a zero-first change.
What should I do first when a cross-chain transfer is waiting?
Find the oldest pending transaction from the source address on the source chain, then check its nonce, receipt status, and fee against current conditions. I would resolve that head transaction before changing the approval or starting another transfer, because later transactions cannot execute around it.
Top comments (0)