What is Permit2?
A shared approval router for ERC-20 UX - powerful, and very load-bearing.
Permit2 exists because token-native permit did not become universal. Instead of waiting for every ERC-20 to add ERC-2612, Uniswap shipped a shared approval and signature-transfer layer that apps could integrate once.
on this page
The standard, in one card.
- Maintainer
- Uniswap Labs
- Works with
- Existing ERC-20 tokens
- Primary modes
- SignatureTransfer · AllowanceTransfer
- Closest ERC
- ERC-2612 for token-native permit
The origin story.#
The adoption problem was straightforward: ERC-20 is everywhere, ERC-2612 is not. A shared contract could give modern approval UX to legacy tokens, provided users first approve that shared contract.
How Permit2 actually works.#
Permit2 exposes two broad paths: signature transfer for one-off signed movement, and allowance transfer for reusable approvals with expirations and nonces. The asset itself remains a normal ERC-20.
What's broken about Permit2.#
The tradeoff is concentration. A shared router makes integration easier, but it also becomes a spender users must recognize, wallets must label, and security tools must monitor.
-
The approval router becomes load-bearing.#
Permit2 improves UX by concentrating approval logic in one contract. That also means users and wallets must understand when they are approving Permit2 itself and when an app is spending through it.
Permit2approve(Permit2) + signed spendLSP6controller permissionsworkarounds tried- wallet spender labels
- Permit2-specific revoke UIs
- short expirations
- per-token caps
-
It is still an ERC-20 allowance story.#
Permit2 can add deadlines, nonces, and better signature UX, but the underlying asset remains an ERC-20 moved through transferFrom-like authority.
ERC-20spender can move tokensLSP7 + LSP6operator + account scopeworkarounds tried- SignatureTransfer
- limited allowances
- expiry
-
Wallet comprehension is the product.#
A shared approval router is only safe when wallet prompts clearly show token, spender, amount, expiration, and the app receiving the permission. Weak displays turn a UX tool into a signing-phishing surface.
Permit2EIP-712 signatureUniversal Profilevisible account controllersworkarounds tried- typed-data previews
- simulation
- domain reputation
- spender warnings
LUKSO designed it differently.#
LUKSO's account-first model avoids needing a universal approval router for basic app permissions. The account can express what a controller may call directly, and relayed execution is handled by LSP25 rather than by token-specific permits.
Permit2 vs LSP6 in one table.#
| row | Permit2 | LSP6 |
|---|---|---|
| where approval lives | Permit2 contract plus token allowance | Universal Profile permissions |
| works with old tokens | yes | only when using the LSP account/asset stack |
| signature scope | Permit2 transfer or allowance fields | LSP6 allowed calls / standards / keys |
| revocation | Permit2 allowance and token approval | controller permission removal |
FAQ.#
-
Is Permit2 an ERC? #
No. Permit2 is a production contract system from Uniswap, not an Ethereum ERC standard. It is widely used because it gives permit-like flows to ERC-20 tokens that do not implement ERC-2612.
-
How is Permit2 different from ERC-2612? #
ERC-2612 is implemented by each token contract. Permit2 is a separate shared contract that users approve and apps use for signature-based transfer or allowance flows.
-
Is Permit2 safe? #
The contracts are designed for production use, but the user-risk model still depends on clear wallet prompts, limited amounts, expirations, and revocation. It does not remove the need to understand who can move tokens.