Permit3 is an open-source token approval protocol that enables multichain token permission with a single signature and full gas abstraction. It eliminates the need for redundant approvals and native gas tokens, enabling developers to simplify cross-chain token operations using a single user signature. Understanding why Permit3 exists in the shape it does requires tracing the full lineage: ERC-20's original approve, Permit1 / EIP-2612's gasless upgrade, Uniswap's Permit2, and finally Permit3's multichain extension.

Each step in this evolution was a direct response to a specific pain in the previous design. Reading the history end-to-end is the fastest way to understand the trade-offs and the design choices baked into today's permit-based flows.

The original ERC-20 standard, proposed in late 2015, introduced the two-step allowance pattern. A token holder calls approve(spender, amount) onchain, which registers a spending allowance. The spender can then call transferFrom up to that allowance to pull the tokens.

This design solved a real problem. Before ERC-20, every token had its own interface, and DEXs had to integrate with each token separately. The approve + transferFrom pattern gave DEXs and aggregators a uniform way to move tokens on behalf of users. Uniswap V1, Compound, and every major DeFi primitive built on this pattern.

Three problems emerged as usage scaled.

Every interaction with a token required two onchain transactions: the approve, then the actual action. Each transaction cost gas, each added latency, and users often forgot or failed one of the two. The classic "approve then swap" flow became a UX staple that users endured rather than enjoyed.

To reduce repeated approval transactions, dApps converged on asking users to approve a very large number (often 2^256 - 1) upfront. This gave the spender effectively permanent, unlimited authority over the user's tokens. Multiple high-profile exploits (well documented in the security literature) turned these long-tail infinite approvals into the attack surface of choice for malicious or compromised contracts.

An approval on Ethereum authorizes nothing on Polygon, Arbitrum, or Base. Every new chain required re-authorization. As the multichain ecosystem grew, the UX tax of per-chain approvals grew with it.

EIP-2612, finalized in 2020 and widely called "Permit" or "Permit1" in retrospect, attacked the two-transaction UX problem. The proposal adds a permit function to ERC-20 tokens that accepts an EIP-712 signed message from the token holder instead of requiring an onchain approval transaction.

The key insight: EIP-712 signatures are free. A user signs a typed-data message off-chain using their wallet's existing signing flow. Any relayer can submit that signature onchain as part of a transaction. If the relayer is the spender contract itself, the "approve and transfer" sequence collapses into a single transaction.

For a deeper look at how EIP-2612 works, see our EIP-2612 guide.

EIP-2612 was a meaningful step forward but covered only a fraction of the tokens and flows users interact with daily.

Uniswap introduced Permit2 in November 2022 to extend the permit pattern to every ERC-20, not just those that had adopted EIP-2612.

Permit2's core move: extract the permit mechanism into a standalone contract that sits in front of every ERC-20. A user issues a traditional one-time approve to the Permit2 contract (often for an unlimited amount), and then grants specific, scoped permissions to spenders via Permit2's EIP-712 signed messages. The permit logic moves from the token contract to Permit2, so any ERC-20 can participate.

Permit2 was the dominant permit pattern for single-chain flows through 2023 and 2024 and remains actively used today.

Permit3 launched as an open-source protocol from Eco, designed to extend the Permit2 pattern across chains. The core insight: the Permit2 design treats each chain independently, but in a multichain world, the user almost always wants to authorize coordinated action across chains. Permit3 ships the cross-chain logic as a protocol primitive rather than leaving it to every application to reinvent.

The core technical move in Permit3 is the Unbalanced Merkle Tree. A standard Merkle tree has uniform leaf depth, so every proof costs the same gas to verify. That is inefficient when the verifying chains have vastly different gas costs. Permit3 structures the tree so expensive chains sit closer to the root with shorter proofs, and cheap chains sit deeper with longer proofs. The total signature covers the same permission set, but the gas cost on the expensive chain drops meaningfully.

For a deeper walkthrough, see Permit3 vs Permit2.

Each generation inherited the previous generation's successful patterns and addressed its leftover pain points. Permit3 is not a replacement for Permit2 so much as a superset that extends Permit2 to the multichain context where most stablecoin activity now happens.

Teams evaluating whether to integrate Permit3 today often ask: why not just stick with Permit2? The answer depends on scope.

The lineage matters because the design decisions are non-obvious in isolation. The Unbalanced Merkle Tree only makes sense if you know Permit2's flat structure. The salt-based nonce only matters if you have hit the Permit2 bitmap's limits. The five allowance modes only read as useful if you have tried to express "lock during an incident, then unlock" with Permit2's two modes.

Permit3 is one of several proposals addressing cross-chain permissions and authorization. A short inventory:

None of these are competitors. They stack. A production cross-chain stablecoin app might use ERC-4337 for the account layer, ERC-7683 for the intent format, Permit3 for the permission layer, and Eco Routes for the execution layer. Each handles a well-scoped problem.

It is early to call the next permit standard, but a few directions are emerging in protocol conversations.

Cross-VM permits. Today Permit3 is EVM-only. Extending the Merkle-proof verification to Solana (SVM) or Tron (TVM) is a non-trivial engineering challenge because the cryptographic primitives differ, but it is an obvious next frontier. Bridges like Eco Routes already span EVM and Solana; the permission layer will likely follow.

Privacy-preserving permits. Current permit standards leak the full permission set to any observer. Zero-knowledge proof systems could let a user prove they have authority without revealing the full scope. Research-stage; not yet a production pattern.

Continuous allowances. Streaming-style permissions (analogous to Sablier for token streaming) where the allowance accrues over time. Expressible today via the Increase mode plus off-chain scheduling, but a first-class primitive might be cleaner.

Programmable revocation. Today revocation is manual (signer invalidates a nonce or locks the account). Programmable revocation rules (revoke if a risk signal fires, revoke if the signer's device changes) are plausible extensions.

For now, Permit3 is the frontier. Whether the next step is Permit4 or a different primitive altogether depends on what breaks first in Permit3's model at scale.

For the current-state overview, see our Permit3 guide. For the implementation details, the developer walkthrough is the fastest path. For use cases, check out Permit3 use cases.

EIP-2612 permits remain in heavy use for tokens that implemented the extension natively, especially DAI and several wrapped-token standards. Newer applications prefer Permit2 or Permit3 because those work with any ERC-20, but Permit1 is not deprecated.

Yes. Permit3 implements the full Permit2 interface as backward compatibility. A spender contract can accept both signature formats. Users with older Permit2-integrated wallets can keep signing Permit2 messages; newer wallets can sign Permit3 cross-chain messages. The two coexist.

EIP-2612 requires token-contract opt-in, which is impossible for the thousands of ERC-20s already deployed without the extension. Permit2's standalone-contract approach works for any ERC-20, which was a practical necessity for Uniswap's universal router strategy.

No. ERC-20 approve remains the base primitive, and newer permit standards sit on top of it (Permit2 uses a one-time approve to its contract; Permit3 uses the same compatibility path). The base standard is too widely deployed to deprecate, but most new user-facing flows will route through the permit layer.

For single-chain projects with no multichain plans, Permit2 is still a reasonable choice. For any project expecting multichain usage, Permit3 is the default because it works on a single chain (Permit2-compatible mode) and extends cleanly to multiple chains when needed.