Crypto Permit2 is an authorization system developed by Uniswap Labs to standardize how ERC-20 tokens are used across applications. It does not replace a wallet or make a dangerous signature safe. Instead, it separates the token’s on-chain approval from the permissions a user signs for a particular application. That design can reduce repeated transactions and fragmented allowances, but it introduces a crucial security point: after a token has been approved to Permit2, a malicious signature can carry real financial authority.
Safe use therefore requires three separate checks: which contract receives the ERC-20 approval, exactly what the signed message contains, and which spender will be allowed to act. This guide explains Permit2’s two transfer models, expiration and nonce handling, phishing risks, protocol constraints, and a practical process for reviewing and revoking permissions without mistaking an off-chain signature for a harmless login.
Crypto Permit2: what actually changes
In the traditional ERC-20 flow, a user sends an approve(spender, amount) transaction to the token contract before using a dApp. The spender, usually a router, can then call transferFrom up to the approved amount. Every new spender needs a separate allowance and an on-chain transaction; an unlimited approval may remain active for years.
With Permit2, the user first approves the Permit2 contract as the ERC-20 spender. Integrated applications then request more granular permissions through EIP-712 signatures. Permit2 verifies the signature, domain, spender, token, amount, expiry and nonce before moving funds. The application does not automatically inherit the primary ERC-20 allowance. It receives only the authority described by the signed message and the rules of the relevant module.
One contract can serve many protocols, and later authorizations do not always require another approval transaction. The trade-off is less intuitive consent: a zero-gas “sign” prompt may still authorize movement of tokens previously approved to Permit2.
AllowanceTransfer versus SignatureTransfer
Permit2 provides two distinct mechanisms. The right choice depends on whether the application needs reusable authority or one-time execution.
| Question | AllowanceTransfer | SignatureTransfer |
|---|---|---|
| What is authorized? | A stored allowance for an owner, token and spender | One transfer or batch described by a signature |
| Does permission persist? | Yes, until the remaining amount is spent or it expires | Not after standard execution; its nonce cannot be replayed |
| How is it bounded? | Amount, spender and expiration | Token, maximum amount, spender, deadline and nonce |
| Best fit | Repeated activity with a trusted application | A single action or atomic batch |
| Main risk | An oversized, persistent allowance | A stolen signature executed before its deadline |
AllowanceTransfer stores authorization in the contract. The application can consume it over several operations, within the remaining amount and before expiration. SignatureTransfer uses a signature to authorize an immediate transfer. It uses unordered bitmap nonces, allowing independent permits without a strict sequence. The witness variant can bind extra application-specific data to a signature, but the integration must define, display and verify that data correctly.
The ERC-20 approval to Permit2 is the foundation
The first step remains a normal on-chain transaction sent to the token contract. The spender field must contain the official Permit2 contract address for the active network—not the website, the dApp router or an address copied from a message. Before confirming, compare the chain, token contract, spender and amount against the application’s official documentation.
An exact approval limits exposure but needs renewal. A large allowance reduces friction and future gas costs, but increases the amount accessible if the owner later signs a dangerous permission. An unlimited approval does not by itself let any website take the tokens: it allows Permit2 to move them under valid authorization. It is nevertheless powerful, long-lived authority and should be treated as part of the wallet’s attack surface.
The primary revocation is an ERC-20 transaction that sets the token’s allowance to Permit2 to zero. This is the broadest stop: it prevents further Permit2 transfers for that token even if secondary permissions have not expired. The transaction costs gas and must be submitted on the same chain and token contract as the original approval.
EIP-712 signatures, expiration, deadline and nonce
EIP-712 typed signatures can be decoded because they contain a domain and structured fields. The domain normally binds the signature to a name, chain ID and verifying contract. A neatly formatted wallet prompt is not sufficient proof of safety. Users should still verify that the contract is Permit2, the chain is expected and the named spender is the contract genuinely required for the action.
In AllowanceTransfer, expiration controls how long the spender may use the stored allowance, while the nonce orders updates and prevents an older, replaced permission from being reused. A separate sigDeadline limits when the signature that establishes the allowance may be submitted on-chain. The allowance expiration and signature submission deadline are different controls.
In SignatureTransfer, the deadline determines the last moment at which the signed transfer can execute. Its nonce is marked as used after execution, so a replay fails. A nonce prevents repeated execution; it does not stop a malicious first execution. If a signature was handed to a hostile site, a short deadline narrows the window but cannot recall data already disclosed.
Practical scenario: recurring swaps or a one-off action
Consider a user holding 5,000 USDC who wants to swap 300 through an aggregator. The site first requests an ERC-20 approval from USDC to Permit2. The user verifies the network, the genuine USDC contract and the Permit2 address, then chooses a bounded amount rather than an unlimited ceiling.
For one swap, SignatureTransfer is often the better fit. Its signed message identifies USDC, a maximum of 300, the aggregator’s spender, an unused nonce and a near-term deadline. The calling contract may spend less than the maximum if execution changes, but not more than the signed limit. If the swap fails before consuming the nonce, the signature may remain executable until the deadline. It should not be dismissed merely because the interface showed an error.
If the same user swaps weekly through a well-verified protocol, AllowanceTransfer may reduce repeated prompts. A reasonable choice could authorize its spender for 1,000 USDC with a 30-day expiration, followed by renewal only when needed. At the end of the period, the user reviews both the internal Permit2 allowance and the underlying ERC-20 approval.
Constraints and responsibilities Permit2 does not remove
Permit2 only works with tokens that behave compatibly with the ERC-20 model and for which the owner has granted the necessary approval. It cannot move the native network asset without an ERC-20 representation such as WETH. Non-standard token behavior, pauses, blacklists, transfer fees or insufficient balances may cause execution to fail.
Permit2 does not certify that a spender is honest. It verifies valid authorization and enforces encoded limits; it cannot know that a user misunderstood a counterfeit page. The dApp integration also matters. Incorrect witness handling, inadequate caller binding or ambiguous display can weaken expected guarantees. Readers who need the surrounding model can review CryptoRoad’s guides to smart contracts and their risks and how DeFi works.
Revocation cannot recover assets that have already moved. Revoking only an internal permission also leaves the ERC-20 approval to Permit2 active. Conversely, setting the token approval to zero blocks immediate use but does not necessarily clear Permit2’s internal records. These are separate layers that should be reviewed independently.
Signature phishing: warning signs that matter
Modern phishing often avoids an obviously costly transaction and instead asks for a signature “to log in,” “verify the wallet” or “claim an airdrop.” If the wallet displays Permit2, PermitSingle, PermitBatch or a typed transfer, the request is not an ordinary authentication message. It may establish an allowance or authorize movement of funds.
- The domain came from an advertisement, direct message, urgent email or sponsored result.
- The spender differs from the contract documented by the genuine dApp.
- The maximum amount or batch includes tokens unnecessary for the stated action.
- The expiration or deadline is distant, or the wallet cannot decode important fields.
- The site asks for repeated signatures after an error without explaining the earlier nonce.
Rejecting an opaque message is the correct response. A hardware wallet protects key material, not judgment: when the user confirms a malicious signature on the device, the signature is valid. Meaningful balances should be separated from the daily dApp wallet, following the principles in the guide to custodial, non-custodial, hot and cold wallets.
How to check and revoke allowances and signatures
Start with a reputable explorer or allowance manager opened from a saved bookmark. Select the correct network and inspect the token allowance granted to Permit2. Then review Permit2’s internal allowances by owner, token and spender. A conventional approval checker may expose only the first layer and omit secondary permissions.
To remove a persistent allowance, use Permit2’s lockdown/revocation capability or a transparent interface that composes the correct call. SignatureTransfer has no conventional remaining allowance: used nonces cannot be replayed, while unused ones can be invalidated through the bitmap nonce functions. An undisclosed signature with a short deadline may simply expire; an exposed signature is better handled by invalidating its nonce.
If compromise is suspected, prioritize setting the ERC-20 allowance to Permit2 to zero for affected tokens, revoking direct spenders as well, and moving assets to a clean wallet if the seed phrase or private key may have leaked. CryptoRoad’s operational guide to revoking crypto approvals explains the difference between outstanding authority and transfers that already occurred.
Common mistakes and better decisions
Assuming every signature is harmless. A Permit2 signature can be economically equivalent to an authorization. Always read the token, spender, amount and time limits.
Revoking on the wrong network. Allowances are specific to chain, token and owner. A revocation on Ethereum does not change the equivalent position on an L2.
Checking only a token symbol. Counterfeit tokens can reuse the same name and ticker. Verify the contract address.
Using unlimited approvals by default. They are reasonable only when frequency, gas costs and confidence in the spender justify the exposure. A one-time action usually calls for a limited amount and short deadline.
Signing again after a timeout. The first request may still be valid. Check transaction status, nonce and expiry before producing another signature.
Wallet hygiene checklist
- Open dApps from bookmarks and verify domain, network and contract.
- Keep only the capital needed for current activity in the operational wallet.
- Confirm the official Permit2 address for the chain being used.
- Prefer bounded amounts and short expirations for non-recurring activity.
- Read spender, token, amount, expiration, deadline and nonce before signing.
- Reject undecoded messages and unjustified token batches.
- Review ERC-20 approvals and internal Permit2 allowances periodically.
- Revoke permissions after campaigns, mints, one-off swaps and tests.
- Never enter a seed phrase into a revocation or support website.
- After a suspicious signature, invalidate permissions and move assets if key compromise is possible.
Conclusion: convenience without outsourcing security
Crypto Permit2 improves dApp interaction by centralizing an ERC-20 approval and enabling more granular signed permissions. AllowanceTransfer suits recurring relationships but leaves spendable state until its amount is exhausted or it expires. SignatureTransfer targets one-off execution with anti-replay nonces and deadlines, yet a stolen signature may still be executed once.
The practical rule is to separate the layers: verify the token’s approval to Permit2, then inspect the signed permission for the application spender. Low limits, short lifetimes and compartmentalized wallets reduce the impact of mistakes.
