ERC-20 Approval or One-Shot Swap? The Cross-Chain Trade-Off

For an ERC-20 cross-chain swap, approve the source-chain router first if it has no allowance; the swap itself is a separate deposit transaction. Native assets can often be sent in one transaction, while a prior allowance or a supported permit can remove the separate approval step for tokens. The distinction matters because “one swap” describes the route’s outcome, not necessarily the number of transactions your wallet must submit.

What does an ERC-20 approval authorize?

An ERC-20 approval sets an allowance: the maximum amount a named spender can later transfer from the token owner’s wallet. The token contract records that permission when the owner calls approve. The spender, often a router, can then call transferFrom to pull tokens as part of a later transaction.

For a THORChain EVM deposit, the router handles ERC-20 tokens. The first transaction authorizes the router to spend the token; the second calls the router to deposit it, with the swap instructions included. If the wallet already has enough allowance for that router, the approval transaction is unnecessary. The deposit still has to be submitted.

This is the useful distinction behind thor swap: route choice determines where assets go, while allowance state determines whether the wallet needs a separate authorization transaction first. A transaction described as a cross-chain swap may involve a source-chain deposit, protocol processing, and a destination-chain payout, even when the user gives the route one set of instructions.

When can a swap happen in one wallet transaction?

A token swap can avoid a separate approval transaction when the allowance already exists or the route supports a permit or another batching mechanism. The route’s contracts must support that mechanism; a permit cannot be assumed to work with every token and router.

A standing allowance can make repeat swaps simpler. Once granted, it can cover later deposits up to its remaining amount. That convenience creates a trade-off: an allowance remains available to its spender until it is used, reduced, or revoked. A large or unlimited allowance gives the spender room to pull more tokens than a single swap requires if its contract or key is compromised.

Permits can authorize token spending through a signature rather than a separate on-chain approval transaction, where both the token and route support them. Some systems use a preliminary token approval to a permit contract, then accept signatures that scope later spending by amount or time. That is a different contract flow, not a property of cross-chain swaps in general. A bundled wallet transaction can also combine compatible calls, but bundling changes how calls are submitted, not what the underlying contracts authorize.

For a one-off transfer, an exact or limited allowance is easier to reason about than a broad standing permission, though it can require another approval for a later trade. For recurring transfers, a capped allowance to the intended router can reduce repeated approval transactions. The useful choice depends on how often the same wallet will use that same spender.

What should you check before choosing?

Check the source asset, the spender address, the allowance amount, and the route’s transaction requirements. An approval is token-specific and spender-specific. Approval for one token or router does not automatically authorize a different one.

• First use: An ERC-20 source token may require an approval transaction followed by the deposit. A native asset such as ETH can be sent directly to the vault, so it does not need an ERC-20 allowance.
• Repeat use: The router can use an existing allowance if it is still valid and large enough. A changed router address or exhausted allowance can bring back the approval step.
• Permit or batching: Confirm that the specific route supports it. A wallet signature alone does not mean the cross-chain deposit has been broadcast.
• Failure handling: If approval succeeds but the deposit fails, the allowance may remain. Check the token’s allowance for the intended spender and revoke or reduce it if it is no longer needed.

Approval and deposit transactions can each require source-chain gas. An approval does not reserve a quote, guarantee a swap, or send tokens across chains; it only authorizes a spender within the approved amount. The deposit is the action that moves the source asset into the route. After that, processing and destination delivery depend on the route and the destination chain.

For most occasional users, approve only the needed amount when the route requires it, then submit the deposit. For repeated transfers through the same verified router, an allowance can save wallet steps, but its scope should match the operational need. What is confirmed is the contract-level distinction: ERC-20 approval grants spending permission, and the router deposit initiates the cross-chain transaction. Whether a particular interface can combine those actions, or which allowance it requests, depends on that route’s implementation.