A Swap Approval Names the Contract That Can Spend Your Tokens

A swap approval lets a named contract move up to a specified amount of one token from your wallet. In the standard ERC-20 flow, you call the token’s approve(spender, amount) function, and the token records an allowance for that owner, token and spender. A swap contract later calls transferFrom; the token checks that allowance and the owner’s balance before moving funds. The approval is a permission to spend, not a swap order or a guarantee that a trade will succeed.

The spender is the contract address that the token sees as the caller of transferFrom. Depending on the route, that may be a router or a permission manager, rather than each pool used in the trade. The routing sequence is covered in more detail in this fermi swap account. Checking the spender and the allowance amount tells you what the permission covers; the interface’s label alone does not.

What does a swap approval actually authorize?

An ERC-20 approval authorizes its spender to withdraw the approved token from your address, up to the remaining allowance. It does not authorize that contract to take every token in your wallet. Each token contract maintains its own allowance, and the allowance is keyed to the owner and spender addresses.

For a direct router flow, the swap transaction usually calls the router, which calls the input token’s transferFrom to pull tokens from the trader. The token sees the router as msg.sender, so the trader must have approved that router. The router then directs the input through the route and delivers the output token according to the swap call. A multi-hop route may pass through several pools, but that does not mean the wallet must separately approve each pool: the wallet-level permission is for whichever contract pulls the input from it.

This distinction matters when a front end uses an aggregator, a proxy or a separate allowance manager. The contract shown as the spender should match the address that ultimately calls the token’s transfer function under that design. If the route changes to a different spender, an existing approval for the former address does not automatically cover the new one.

Why can one swap ask for more than one permission?

A swap can involve separate permissions because a signature and an ERC-20 allowance are different mechanisms. A conventional approval is an on-chain transaction that writes the token’s allowance. An ERC-2612 permit uses an EIP-712 signature to set that same allowance, if the token implements the extension. The signature can be submitted with a later transaction, so it can avoid a separate approval transaction, but it still creates an allowance for the named spender.

The permit’s deadline limits when the signature can be submitted. It does not, by itself, make the resulting ERC-20 allowance expire at that time. Under the basic ERC-20 model, an allowance remains until it is spent or changed; the standard does not impose an expiry. Some token implementations treat the maximum integer allowance as a sentinel and leave it unchanged when spending, so repeated swaps can continue using it.

Permit2-style flows add a second layer. The token owner first approves the Permit2 contract at the ERC-20 level. Permit2 can then record an amount and expiry for a specific application spender, or verify a transfer signature for a one-time spend. In the allowance flow, the application calls Permit2, which checks its own allowance and calls the token’s transferFrom; the token therefore sees Permit2 as its spender. In the signature-transfer flow, the signature authorizes the transfer under its signed terms and is consumed once, but the underlying token approval to Permit2 is still required.

Read the prompt as a sequence of permissions, not as one generic “connect” step:

• For an ERC-20 approval, identify the token, spender address and approved amount.
• For ERC-2612, check the signed spender and amount; treat the signature deadline separately from allowance duration.
• For Permit2, distinguish the token’s approval to Permit2 from Permit2’s permission for the application.
• For a signature transfer, check the token, maximum amount, spender and deadline encoded in the signature request.

Should you use an exact allowance or a standing one?

An exact allowance limits the amount the spender can draw under that approval, which is the narrower choice for an occasional swap. A standing or maximum allowance reduces repeat approval transactions, but leaves that spender able to use the remaining permission later. That exposure persists even if you stop using the interface; disconnecting a wallet does not change the token’s on-chain allowance.

Before signing, compare the spender address and amount with the trade you intend to make. If a token has a nonzero allowance and requires a change to another nonzero value, ERC-20 advises interfaces to set it to zero first; this avoids the allowance-change race where a spender may use the old allowance before the update takes effect. Revoking or reducing an allowance is a separate on-chain state change and requires its own transaction. A swap can still fail after approval if the allowance is insufficient, the balance is too low, the signature has expired, or the route’s execution conditions are not met.

The practical rule is to identify the contract that can pull the input token, then decide how much and for how long it should be able to spend. Multi-hop routing changes where tokens travel after the pull; it does not erase the original permission or make every contract in the route the approved spender.