A first-time ERC-20 approval commonly adds about 45,000–65,000 gas and one source-chain transaction before a cross-chain swap can begin. The exact fee depends on that chain’s gas price and the token’s storage state; if the swap fails later, the approval transaction’s fee is still spent.
An ERC-20 router cannot pull tokens from a wallet until the token contract records an allowance for that spender. Think of the allowance as a warehouse pick ticket: it names who may withdraw and sets a quantity ceiling, but it does not itself move the tokens. When evaluating how quickswap selects a route from your wallet, check which contract needs that authority, because each chain keeps its own token balances and allowances.
A new allowance adds a separate source-chain transaction
For a standard ERC-20 token, the wallet calls approve(spender, amount); later, the authorized spender calls transferFrom(owner, …, amount) during the swap. The approval writes the owner–spender allowance into the token’s storage, so it must be mined before a separate swap transaction can use it. The ERC-20 specification defines this allowance model.
For an initially empty allowance, the storage write from zero to a nonzero value is the main execution cost. Add the transaction’s 21,000 gas intrinsic cost, function execution, and the Approval event, and a normal approval often lands around 45,000–65,000 gas. That is a gas estimate, not a fixed fee: the charge is gas used multiplied by the effective gas price, paid in the source chain’s native asset.
For example, at 20 gwei, 50,000 gas costs 0.001 ETH on Ethereum. A different source chain can price the same approximate gas workload differently. A cross-chain swap may involve later transactions or messages on destination infrastructure, but those do not erase the wallet’s source-chain approval charge.
An existing allowance can remove the approval transaction
If the token’s allowance for the exact spender is already at least the required amount, the integration can skip approval and proceed to the swap call. This is the cheapest case for the current swap, although a standing allowance grants that spender continuing authority up to the remaining amount; a maximum allowance can remain usable well after the current operation.
Before asking the user to approve, read allowance(owner, spender) on the source chain and compare it with the amount the router will pull. The spender must be the actual contract that invokes transferFrom, not merely a bridge or aggregator address guessed from the route. Proxy upgrades and route changes can alter which spender is appropriate, so hard-coded allowances can become stale or expose more authority than intended.
When replacing a nonzero allowance, ERC-20 approve overwrites the old value. The specification advises clients to set it to zero first to mitigate the allowance-change race: a spender could consume the old allowance before the new value lands, then use the replacement allowance too. Some tokens reject direct nonzero-to-nonzero changes, which means a reset and a new approval can require two mined transactions. For repeat usage, the lower transaction count of a larger allowance trades against longer-lived exposure.
A permit can fold authorization into the swap call
If the token supports ERC-2612, the wallet can sign a typed Permit message containing the owner, spender, value, nonce, and deadline. A relayer or router can submit that signature on-chain and then execute the swap in the same transaction, avoiding a separate approval transaction from the wallet. ERC-2612 binds signatures to a token contract and chain through its EIP-712 domain, while the nonce prevents replay.
Permit shifts where the transaction is submitted; it does not make contract execution free. Someone still pays gas to submit the permit and swap call, whether that is the user, a relayer, or a service bundling the operation. This can remove the user’s separate source-chain approval fee and confirmation, but the transaction may consume more gas than a bare swap because it verifies a signature and updates allowance state.
Permit is not universal. Tokens may lack ERC-2612, use a different permit variant, or expose a deadline and signature format that the integration does not support. A permit can also expire or become unusable after its nonce changes. A robust integrator checks token capability and domain data, uses a short deadline suited to the quote’s lifetime, and falls back to a normal allowance path when needed. quickswap, as a cross-chain bridge and swap service, handles moving and exchanging assets across networks in one flow; the integration still needs to account for the source-chain authorization that lets its contracts take custody of the input asset.
For most integrations, the decision is straightforward: reuse a sufficient allowance when its scope matches the intended spender, use a bounded approval when minimizing standing authority matters, and use permit when the token and transaction path support atomic submission. Report approval gas separately from swap execution in estimates; that distinction explains why a first-time user can pay more on the source chain even when the route and swap amount are unchanged.
Top comments (0)