Uniswap
Uniswap token approvals and spending permissions
Uniswap swaps that spend an ERC-20 input token require sufficient permission for the contract that pulls that token. For routes using Permit2, you approve Permit2 through the token contract and authorize a specific spender through Permit2. An approval alone doesn’t exchange tokens. Its unused allowance can survive a completed swap, and later deposits can fall within that allowance. A signed permit may set an amount or expiry, depending on the mechanism. The spender address, spending cap and relevant deadlines determine what access remains after the trade. A renewed approval request can concern either layer, so identify the contract and spending permission that it changes.
The short version: A Permit2 spender allowance can expire while the token’s separate approval to Permit2 remains active, leaving distinct permissions to review.
Token permissions and swap execution
When a swap needs tokens from your wallet, its spending contract must have authorization that covers the required input amount. Token contracts record allowances for owner and spender addresses. The spender can use that permission when its code permits a transfer. The swap instruction separately specifies what to exchange. A successful approval transaction can therefore leave your token balance unchanged, even though the contract now has spending permission.
Signing a Permit2 message doesn’t mean the blockchain has applied that permission or completed a swap. The Universal Router can process permit authorization and swap actions within one transaction. Existing allowances can remove the need for fresh authorization, so there’s no universal number of wallet prompts.
An allowance doesn’t determine the fee that a pool charges. Pool trading fees and network approval costs follow separate rules.
Who can spend tokens after I approve them?
The approved spender address gains permission for that token from that owner address, subject to the token’s rules and available balance. Permission belongs to those addresses, not everyone associated with a protocol name. An ERC-20 allowance doesn’t expose your private key or authorize spending every asset in your wallet. It permits transfers of the specified token. The spender’s code determines how callers can exercise that permission, so an allowance alone doesn’t guarantee a particular swap or recipient.
Permit2 and the router use separate permissions
With Permit2-based routing, you grant Permit2 an allowance in the token contract, while Permit2 controls authorization for downstream spenders. The Universal Router is one integrating spender. Permit2 requires the owner’s ERC-20 allowance before it can transfer that token. Approving Permit2 doesn’t automatically grant every application unrestricted access. The downstream spender still needs authorization through the applicable Permit2 mechanism.
AllowanceTransfer stores reusable permission with an amount and expiration for a particular owner, token and spender. SignatureTransfer uses transfer-specific authorization and consumes a nonce, a value that prevents reuse of the signature. It leaves no reusable downstream allowance. Both mechanisms retain the underlying token-approval requirement.
A router permission can’t overcome an insufficient token allowance to Permit2 or an insufficient wallet balance.
Finite spending limits and future deposits
If you grant a finite allowance, its amount caps cumulative spending through that permission. A trade doesn’t automatically cancel an unused remainder. The approved amount describes access to the input token, not the output that the swap promises. For a swap with a fixed output amount, authorization must cover the input that execution requires within the swap’s maximum-input limit. An allowance that covers a displayed estimate can still fall short of that requirement.
Some token contracts treat a maximum allowance as unlimited and don’t reduce it after transfers. Permit2’s AllowanceTransfer also treats its maximum amount this way. Unlimited describes the spending cap; it doesn’t remove Permit2’s allowance expiration. A smaller cap limits residual permission, although the interface determines which controls you can use.
An empty balance doesn’t erase an allowance. Later deposits may become spendable under the remaining permission.
The fields that identify your permission
Token and spender addresses
An ERC-20 approval transaction targets the token contract; its approval data identifies the spender. A Permit2 message uses different roles: the verifying contract identifies Permit2, while the spender identifies who gains downstream permission. A familiar label in a wallet doesn’t replace the actual contract addresses for the selected deployment.
Amount and token units
Contract data expresses amounts in token base units. Wallets often convert those values into readable token amounts using the token’s decimal precision. Raw digits alone don’t establish the human-readable cap. Relate the displayed amount to the input limit that you intend to authorize.
Network and verifying contract
Permit2 binds signatures to a domain that includes the chain ID and verifying contract. Permission on one network doesn’t establish the same permission elsewhere, even when your wallet address matches. Router deployments also vary by network and version. Allowance inspection needs the correct account, token contract and network.
A finite approval for a token without native permits
Consider a hypothetical setup with a swap input of 26 token units, an approval cap of 38 units and no existing allowances. The selected ERC-20 token has enough spendable balance and follows ordinary finite-allowance accounting. It lacks token-native permits. The chosen interface allows finite approvals, and the wallet supports Permit2 signing and can cover the required network costs.
Native permit support and the fallback
The missing token-native permit prevents changing this token’s allowance through its own signature extension. The standard ERC-20 approval method remains available. The selected swap route integrates Permit2, which supplies downstream signed authorization without requiring a native permit in the token.
You grant Permit2 a token allowance of 38 units. After that approval confirms, you sign a Permit2 allowance of 26 units for the selected router. The permit’s signature deadline and the allowance’s expiration both cover execution. The swap transaction applies that permit and spends 26 units while both permissions remain valid.
The remaining spending permission
The confirmed spend leaves 12 units of token allowance: 38 minus 26 equals 12. It also exhausts the router’s 26-unit Permit2 allowance. The router has zero remaining permission through that allowance, although Permit2 retains the outer allowance of 12 units. That remainder describes spending permission, not your remaining token balance or swap output.
The next choice is whether to retain or revoke that outer allowance. A larger finite initial cap would leave a larger remainder after the same spend. Increasing the router’s cap could also leave reusable downstream permission if the swap didn’t consume it.
When does a Permit2 allowance expire?
A reusable Permit2 allowance stops allowing transfers after its stored expiration timestamp, while a signed permit has a separate submission deadline. These values serve different purposes. Read the actual permission’s fields rather than assuming every interface grants the same duration.
The signed permit’s submission deadline
The signature deadline limits when a contract can accept the signed authorization. A permit that sets a reusable allowance can establish that allowance before this deadline. Once established, the allowance follows its own expiration. The signature deadline alone doesn’t determine how long that stored spending permission lasts.
The stored allowance’s expiration
The spender can’t use an expired AllowanceTransfer permission even if its recorded amount remains positive. Expiry of a Permit2 spender allowance doesn’t revoke the token contract’s separate allowance to Permit2. A new valid authorization can establish downstream permission again. Spending through it still requires a sufficient underlying token allowance. SignatureTransfer instead checks its transfer authorization’s deadline and whether its nonce remains unused.
Wallet compatibility and alternative approval paths
Missing support for EIP-712 typed-data signing can prevent a Permit2 route even when the token allowance is adequate. Wallet support and token support are separate dependencies. Permit2 supports contract-wallet signature validation through ERC-1271, although the selected wallet and interface must handle that signing path. Connecting an account doesn’t establish that every signature method will work. A token that implements EIP-2612 has its own native permit method. That token-native authorization isn’t interchangeable with a Permit2 message.
The Uniswap API also offers a proxy approval flow for integrations that can’t support Permit2 signatures. The wallet grants an ERC-20 allowance to a proxy contract, which forwards swap execution through the Universal Router. This flow doesn’t support UniswapX orders, which require Permit2 signatures. API availability doesn’t mean every wallet application exposes this option. Switching approval paths also changes the authorized spender; permission for Permit2 doesn’t automatically authorize the proxy.
Revoke the permission that remains
To remove a direct router or proxy allowance, the token owner sets that spender’s token allowance to zero. Revoking the token’s allowance to Permit2 blocks spending through Permit2 for that token. Removing just a stored downstream allowance has a narrower effect. A network’s allowance checker may display token-level approvals without displaying every permission stored inside Permit2, so identify which layer its controls address.
Permit2’s lockdown function sets selected token-spender allowances to zero. Lockdown doesn’t advance the permit nonce. A still-valid unused permit can therefore restore an allowance afterward. Permit2 provides separate nonce invalidation for outstanding allowance permits and for SignatureTransfer authorizations. Clearing a stored allowance and invalidating an unused signature address different permissions.
A pending revocation leaves the old permission active until the network confirms the change.
Signed messages and unwanted transfers
If you sign a valid Permit2 authorization for an attacker-controlled spender, an existing token allowance can enable an unwanted transfer. Another party can pay the network cost to submit the authorization, so the absence of a gas charge while signing doesn’t make the permission harmless. A site can describe a spending signature as a login or eligibility check. Read what its signed data authorizes. A genuine Permit2 verifying contract doesn’t establish that the downstream spender is safe.
Approval errors before another swap
When spending fails despite a visible approval, identify the contract and permission that cover the input token. The token allowance may fall short, the Permit2 spender allowance may have expired or the signature may contain an invalid nonce. A pending approval hasn’t changed the confirmed allowance. Some tokens require resetting an existing nonzero allowance to zero before replacing it, which can explain an additional approval request.
Token transfer restrictions can also prevent execution despite adequate authorization. Approval doesn’t establish that the chosen route supports unusual token behavior. Slippage limits can reject a trade after authorization succeeds. If an entire swap transaction reverts, its allowance changes revert too; a separate earlier approval remains in place. Before granting more access, determine whether the missing permission needs renewal or the token’s transfer rules require a different resolution.
Helpful answers about Uniswap
Does receiving a token in a swap require an approval?
Receiving an ERC-20 token doesn’t require you to authorize a contract to spend it. An ordinary swap approval concerns the input token that execution pulls from your wallet. If you later use the received token as another swap’s input, its existing allowances determine whether that spending path needs fresh permission.
Can I approve more tokens than my wallet currently holds?
Ordinary ERC-20 allowance accounting lets you grant permission above your current balance, although customized tokens can impose additional rules. An allowance doesn’t create tokens or reserve a balance. Actual transfers still need sufficient spendable tokens. Later deposits can fall within the unused permission, which explains why the approved cap and wallet balance can differ.
Will moving the same wallet to another device clear its approvals?
Using the same wallet address on another device doesn’t clear its onchain token allowances, because contracts store those permissions against the owner address on the relevant network, independently of the device or application that signs transactions.
How can I spot an approval request that covers multiple tokens?
A batched Permit2 request contains multiple token-permission entries, so inspect every entry rather than treating the first displayed token as the whole request. Each entry identifies its token and amount. AllowanceTransfer batches also specify expiration and nonce information for the entries. A wallet may summarize this data, while the signed payload carries the full scope.
Why can an approval show no native currency transfer?
A standard ERC-20 approval changes a spending allowance without sending native currency to the spender. The transaction can therefore show zero native transfer value while still granting token access. Its execution can incur network costs. Read the approval’s token, spender and amount fields; the native-value display doesn’t describe the permission that the contract records.
What happens if I revoke permission after tokens have already transferred?
Revoking an allowance restricts future spending through that permission and doesn’t reverse a completed token transfer. For Permit2, the remaining exposure also depends on other valid permissions and unused signed authorizations. Removing one allowance doesn’t automatically cancel every authorization that involves the token.
Does a Permit2 allowance set the minimum output of my swap?
A basic Permit2 allowance grants spending permission without setting the swap’s minimum output. The swap instruction separately enforces its output limit. Some signature-transfer integrations use additional signed witness data to bind trade-specific conditions, but that capability doesn’t turn every permit into a complete trade instruction. Identify the actual authorization and swap conditions that your selected route uses.
Updated ·