ERC-2612 Permit vs Permit2: How Signature-Based Token Approvals Work

You open a dApp to swap one token, yet your wallet asks for a signature instead of the familiar on-chain approval transaction. Is that safer, or did the approval simply move somewhere less visible? Understanding that question is now part of practical crypto wallet security. ERC-2612 Permit and Uniswap Permit2 both use signed messages to improve the ERC-20 approval flow, but they are not interchangeable and neither makes an untrusted signature safe.

This guide compares what each system authorizes, how the message reaches the blockchain, and what you should verify before signing. It is educational, not financial advice (NFA). Smart-contract and signature risks remain, so verify current interfaces and contracts independently and do your own research (DYOR).

What Problem Do Permit Signatures Solve?

Traditional ERC-20 spending usually takes two on-chain steps. First, you call approve(spender, amount) on the token contract. Then the dApp calls its own contract, which can use transferFrom within that allowance. That first approval costs gas and may force a user to wait for an extra confirmation.

Think of the normal flow as visiting a bank branch to register a direct-debit mandate before paying a merchant. A permit is a signed instruction you hand to the merchant instead. The merchant—or another relayer—can submit it with the intended action. You still authorize spending; the authorization is expressed as a cryptographic signature rather than a separate transaction sent by your account.

The ERC-2612 specification adds permit, nonces, and DOMAIN_SEPARATOR to an ERC-20 token. Its signed data includes the owner, spender, value, nonce, and deadline. The nonce prevents reuse, while the deadline limits how long the permit can be submitted.

How ERC-2612 Permit Works

ERC-2612 is implemented by the token contract itself. A compatible token exposes permit, and the user signs EIP-712 typed data describing an allowance. A relayer submits that signature to the token contract; if the signature, nonce, owner, and deadline are valid, the token updates its allowance and emits an approval event.

A typical flow is:

1. The dApp constructs a typed permit for one token, one spender, one value, and one deadline.
2. Your wallet displays an EIP-712 signature request.
3. You sign off-chain, so signing alone does not create an on-chain transaction.
4. A relayer submits the permit, often alongside the action that uses the allowance.
5. The token contract checks the signature and nonce, then records the allowance.

The main limitation is compatibility. Each token must implement ERC-2612 correctly. Older tokens and tokens with different permit variants cannot automatically use the standard flow.

How Uniswap Permit2 Works

Permit2 is a separate shared contract designed to provide permit-style behavior for ERC-20 tokens, including tokens that do not implement ERC-2612. Before a dApp can use it, the token owner generally gives the Permit2 contract an on-chain token approval. Permit2 then controls narrower permissions expressed through signed messages.

Its two main paths are:

• AllowanceTransfer: a signature establishes an amount- and time-bounded permission for a particular spender. Later transfers must stay inside that stored permission.
• SignatureTransfer: a signature authorizes a transfer for the transaction in which it is consumed, without leaving a continuing Permit2 allowance for that spender.

Permit2 also supports batch operations, contract-wallet signatures through EIP-1271, expiring permissions, and unordered nonces for replay protection. Those features make integration more consistent, but they also make the message fields worth reading carefully.

ERC-2612 Permit vs Permit2

Question	ERC-2612 Permit	Uniswap Permit2
Where is permission verified?	The ERC-20 token contract	The shared Permit2 contract
Token support	Token must implement ERC-2612	Can work with standard ERC-20 tokens after approval to Permit2
Main authorization	Updates the token's allowance	Stored allowance or one-time signature transfer
Expiry	Signed deadline controls permit submission	Signature deadline and, for allowance transfers, permission expiration
Batch support	Not part of ERC-2612	Supported by Permit2
What users must trust	Token implementation, spender, dApp, signature display	Permit2 deployment, spender, dApp, signature display, and the token's base approval to Permit2

Neither option is universally “safer.” ERC-2612 has a smaller, token-local scope, but implementations can vary. Permit2 offers consistent controls and one-time transfers, yet a misleading signature can still authorize an attacker. Security depends on the exact fields, the verified contract addresses, and the spender you authorize.

The Security Risks That Do Not Disappear

A gasless signature can still move value

“Sign” does not mean “log in.” A typed-data request can grant spending authority. MetaMask's signature-phishing guidance warns that off-chain signatures may be collected by a malicious dApp and used later. No gas charge at signing time does not make the request harmless.

The spender matters more than the interface label

A polished site can show “claim,” “verify,” or “connect” while the underlying message names an attacker-controlled spender. Check the domain and the contract address through an independent official source. If the wallet cannot show the token, spender, amount, chain, and expiry clearly, reject the request rather than blind-signing it.

Deadlines are not the same as allowance expiry

In ERC-2612, deadline limits when the signed permit can be submitted. Once submitted, the resulting token allowance follows the token's normal allowance behavior; the deadline does not necessarily make that recorded allowance expire. In Permit2's AllowanceTransfer path, the permission itself can carry an expiration. Read both the signature deadline and the allowance expiration when shown.

Revocation cannot undo a completed transfer

Revoking a live allowance can block future use, but it cannot reverse a transfer already settled on-chain. A suspicious unused signature may also require more than disconnecting the site. Follow the wallet or protocol's current incident guidance, move remaining assets to a fresh account if exposure is credible, and avoid rushing into unverified “recovery” services.

A Five-Point Check Before You Sign

1. Origin: Did you open the dApp from a saved or independently verified official URL?
2. Chain and contract: Are you on the expected network, and is the verifying contract the official deployment?
3. Spender: Does the spender address belong to the dApp action you intend to perform?
4. Token, amount, and scope: Is the permission limited to the asset and quantity you expect? Treat unlimited values as a deliberate high-trust choice.
5. Deadline and expiration: Is the signature submission window short, and does any continuing allowance have an appropriate expiry?

This is where clear signing matters. EIP-712 can structure the data, but a wallet still needs to decode it accurately and you still need to understand it. Structured does not automatically mean trustworthy.

Frequently Asked Questions

Does Permit2 replace ERC-20 approval completely?

Not usually. For standard tokens, you generally first approve the Permit2 contract at the token level. Permit2 then manages dApp-specific signed permissions or one-time transfers within that foundation.

Is an ERC-2612 signature free?

Creating the off-chain signature does not itself consume gas. Someone must still submit it on-chain, and that transaction has a network cost even if a relayer or application pays it.

Can I cancel a permit before it is used?

Cancellation mechanics depend on the system and wallet. Nonces and deadlines constrain replay and validity, but do not assume that disconnecting a site cancels a signed message. Use current official documentation for the token or Permit2 integration and act quickly if a signature may be malicious.

Should I reject every Permit2 request?

No. Permit2 is legitimate infrastructure used by real applications. Judge the actual origin, verifying contract, spender, token, amount, and expiry. The name of the mechanism is not proof that a request is safe or malicious.

The Practical Takeaway

ERC-2612 puts permit logic inside a compatible token. Permit2 provides a shared permission layer with both continuing allowances and one-time signature transfers. Both can reduce approval friction. Both can also express valuable authority that phishers want.

Slow down when a wallet asks for a signature, even if no gas fee appears. Verify the source, contract, spender, amount, and time limits; use bounded permissions where practical; and review active approvals after unfamiliar interactions. This article is educational and not financial advice. Crypto and smart-contract use can result in total loss—only risk funds you can afford to lose, verify current facts yourself, and always DYOR.