Permit3 is an open-source token approval protocol that lets one signature authorize token permissions across multiple chains. After a one-time token approval to the Permit3 contract, a single user signature can commit to permits on several chains. If you have ever shuffled ETH to Arbitrum, then again to Base, then once more to Optimism just to pay gas on three separate approve transactions for the same stablecoin, Permit3 is the primitive that makes that whole dance disappear.
​

This guide walks through how Permit3 works, where it came from, what it unlocks, and how to start integrating it today. You will learn the mechanics of Unbalanced Merkle Trees, the backward-compatible relationship with Uniswap's Permit2, the deterministic contract address that lets you call the same protocol from any supported chain, and the emerging use cases from treasury operations to agentic payments.
​

Token approvals have been the single most annoying onboarding step in crypto for almost a decade. Every ERC-20 interaction requires a preliminary approve call that spends native gas, returns no value to the user, and usually needs to be repeated the moment a DEX, bridge, or payment app deploys a new spender contract. When you multiply that friction by the fifteen-plus chains a modern stablecoin team operates on, the cost shifts from annoying to prohibitive.
​

The usual workarounds compound the problem rather than solve it. Hot wallets hold native gas on every chain. Treasury ops teams pre-fund ETH, OP, ARB, MATIC, BNB, and SOL balances just to service approvals. Agentic systems stall because the autonomous agent does not have native gas on the destination chain when a new counterparty appears. Every one of these workarounds is a symptom of the same root cause: token permissions are chain-local, and the permission model has not kept up with the multichain reality of stablecoin usage.
​

Permit3 collapses the permission step into a single off-chain signature that works across every supported chain. New spenders do not need fresh onchain approvals once the token is approved to Permit3. The permission lives in a contract deployed at the same deterministic address on supported chains; each chain still executes its own transaction, so a shared signature is not atomic across chains.
​

Every new approval standard is a response to a specific pain in the previous one. Understanding the progression tells you exactly what Permit3 fixes.
​

ERC-20 approve (2015) is the original and still the most widely deployed pattern. The user sends an onchain transaction granting a spender the right to pull a specified token balance. It works, but it requires a separate transaction, uses native gas, and the allowance is reset to a specific number that apps often set to a maximum value as an awkward UX compromise. The widely discussed infinite-approval risk is a direct consequence of this design.
​

Permit1 / EIP-2612 (2020) introduced gasless approvals. The user signs an EIP-712 typed-data message off-chain, and a relayer or the spender contract submits it onchain in the same transaction as the token pull. That eliminates the native-gas dependency for the approval itself and combines two steps into one. The EIP-2612 specification defines the canonical interface. The catch is that it only works for tokens that implement the extension, and each approval is a single-use permit to a single spender.
​

Permit2 (2022), introduced by Uniswap Labs in November 2022, extracted the permit pattern into a standalone contract so any ERC-20 could participate without requiring on-token support. It added time-bound allowances, batched approvals, and a shared nonce space. Uniswap, 1inch, and CoW Swap all integrated Permit2 because it was a universal upgrade to the approval UX on any given chain. It remains chain-local, however. A Permit2 signature on Ethereum does not authorize anything on Base.
​

Permit3 (2025+) is the multichain extension. One EIP-712 signature, signed off-chain, can commit to permits for several Permit3-deployed chains, each executed by its own transaction. It uses Unbalanced Merkle Trees for gas-efficient cross-chain proofs, non-sequential nonces for concurrent async operations, and implements Permit2's basic transfer interfaces as a drop-in replacement for existing integrations.
​

For a deeper walkthrough of this progression, see our companion article on the evolution of token approvals.
​

Permit3 is a single smart contract deployed at the deterministic address 0xec00030c0000245e27d1521cc2ee88f071c2ae34 on every supported chain via the ERC-2470 Singleton Factory. The same address on every chain is not cosmetic. It means the signature a user creates can reference the Permit3 contract without needing to encode chain-specific addresses for every destination.
​

The signing payload is a single EIP-712 message containing the root of an Unbalanced Merkle Tree. Each leaf of the tree represents a set of permissions on one chain. When the user signs, they authorize all leaves at once. To execute a permission on a given chain, a relayer or solver submits the signature plus a Merkle proof for the relevant leaf. The Permit3 contract verifies the proof locally, then executes the permit as if the user had signed a native EIP-712 message for that chain specifically.
​

A standard Merkle tree has uniform depth. Every leaf's proof is the same length. That is fine when every chain charges the same gas, but cross-chain proofs pay dramatically different costs. A proof on Ethereum can cost fifty times more than the equivalent proof on Optimism. Permit3 uses an unbalanced tree that places cheap-gas chains deep in the tree with longer proofs and expensive-gas chains near the root with short proofs. The overall signature covers the same number of chains, but the gas cost is optimized per destination.
​

Permit2 uses a bitmap nonce that works well for single-chain sequential operations but becomes a bottleneck the moment you want parallel or async operations. Two permits on different chains, signed at the same moment, can race to claim the same bitmap slot. Permit3 uses non-sequential, salt-based nonces with bitmap tracking, so the signer can create concurrent permits without ordering conflicts. This matters for agentic systems and treasury automation, where permits are minted in bursts across chains.
​

Permit3 implements Permit2's basic transfer interfaces through IPermit. Code built on Permit2's transfer interface can point the same IPermit calls, such as transferFrom, allowance, and approve calls, at the Permit3 address. The cross-chain features use the separate IPermit3 interface.
​

The single-signature model is not just UX polish. It changes what an app can offer.
​

Multichain stablecoin payments. A merchant accepting USDC or USDT can give the customer one signature to authorize payment on any chain the customer happens to hold balance on. The merchant's backend selects the cheapest or fastest source chain, pulls the funds via Permit3, and settles the payment with no manual rebalancing. Teams building on stablecoin routing platforms treat Permit3 as the permission primitive that makes this flow possible.
​

Treasury automation. Ops teams that sweep balances across chains no longer need to pre-fund native gas on each chain. A single Permit3 signature authorizes the treasury's rebalancing agent to pull from any supported chain to a destination chain. This pattern pairs naturally with stablecoin sweep automation tools and cross-chain rebalancing workflows.
​

Agentic commerce. An autonomous agent operating across chains cannot practically hold native gas everywhere. Permit3 lets the agent's principal grant a cross-chain spend authority in one signature; the agent executes on whatever chain the current opportunity appears on. This is the missing permission layer for cross-chain agentic payments.
​

DeFi portfolio management. Rebalancing a multichain portfolio historically required per-chain approvals for every venue. With Permit3, one signature can authorize the rebalancer to pull from positions on several chains, with each chain's transaction submitted separately.
​

NFT and gaming authorizations. Permit3 supports ERC-20, ERC-721, and ERC-1155 in one interface, so a game or NFT marketplace can bundle permissions for fungibles plus collectibles in the same signature.
​

Gas abstraction in the Permit3 context means the user does not submit each chain's permit transaction; for ERC-20 tokens, the owner still approves the Permit3 contract once in the token contract. The user signs once off-chain. The signature is broadcast onchain by a relayer, solver, or the counterparty contract. Whoever submits the onchain transaction pays the gas, and that gas is commonly subsidized by the application or reimbursed by the user in the token being moved.
​

This is not the same as an ERC-4337 paymaster. Account abstraction paymasters pay gas on a per-transaction basis for a smart account. Permit3 gas abstraction is about the permission layer: signing a permit happens offchain, while the token approval to Permit3 is an onchain transaction. The two can stack. An ERC-4337 smart account can sign a Permit3 message, and a paymaster can sponsor the resulting transaction. For the full gas-abstraction mechanics, see our deep dive on Permit3 gas abstraction.
​

Permit3 is an open-source primitive Eco maintains, documented alongside Eco Routes. Eco Routes moves stablecoins between supported chains through intents, and the Routes API accepts a Permit3 authorization as a funding method.
​

A typical flow: the user signs a Permit3 authorization that covers USDC on Base, Optimism, and Arbitrum. The app's backend requests a quote from Eco Routes. The Permit3 authorization funds the intent on the source chain, a solver delivers on the destination chain, and the solver is paid on the source chain after a prover confirms fulfillment.
​

Teams integrating Eco's stack use Permit3 as the permission primitive and Eco Routes as the execution primitive. The two are independent, so a team can adopt Permit3 without adopting Routes, or vice versa.
​

Permit3 has been audited by Cantina, with the public report available in the GitHub repository. The audit covered the cross-chain proof verification path, the nonce handling, the Permit2 compatibility shim, and the witness functionality.
​

Key security properties baked into the design:

The same caveats that apply to any signature-based system apply here: keep signing keys secure, use hardware wallets for high-value principals, and audit the spender contract before granting it authority. Permit3 does not magically make a malicious spender safe. What it does is reduce the attack surface created by per-chain infinite approvals, since every permit carries an explicit deadline and scope.
​

Permit3 is live today in Para, which integrated the confirmation layer with a clear UI showing users exactly what they are signing and from which wallet and chain. Para's integration serves as a reference implementation for other wallet teams. The protocol is open-source, so any wallet can add Permit3 support by surfacing the EIP-712 signature flow with a readable description of the multichain permissions being authorized.
​

For wallets that already support Permit2, the Permit3 integration path is largely additive. The EIP-712 type structure is a superset, the contract address is deterministic, and the Merkle proof verification happens onchain rather than in the wallet, so the wallet's only job is to present the cross-chain scope clearly to the user.
​

The fastest route from zero to a working Permit3 integration:

Walkthrough code, installation instructions, and the full EIP-712 domain specification are covered in the Permit3 developer implementation guide. If you are evaluating Permit3 against Permit2 specifically, the Permit3 vs Permit2 comparison breaks down the technical deltas in depth.
​

Permit3 is designed as a Permit2-compatible replacement. It implements Permit2's basic transfer interfaces, and adds cross-chain features through IPermit3. Teams that need single-chain-only permissions can keep using Permit2, but Permit3 adds multichain support.
​

No. Permit3 works with any EOA that can sign an EIP-712 message, which is every major wallet today. Permit3 has optional ERC-7702 integration that lets an EOA batch its token approvals to Permit3, but the baseline flow uses standard off-chain signatures and onchain proof verification.
​

The Permit3 contract deploys via the ERC-2470 Singleton Factory at the same deterministic address on each EVM chain where it is deployed. Any chain not yet supported can be added by triggering the factory with the same salt. Existing signatures remain valid; they just will not produce proofs for chains that have not yet deployed the contract.
​

Yes. The signer can invalidate individual permits via nonce invalidation, use the account-lock feature to halt all outstanding permits in one call, or let a permit expire naturally by passing its deadline. There is no perpetual, unrevocable permit in the Permit3 model.
​

No. Permit3 supports ERC-20, ERC-721, and ERC-1155 tokens in a unified interface. The stablecoin use cases are the most visible because cross-chain stablecoin movement is one of the highest-volume multichain flows today, but the protocol is token-agnostic and works equally well for governance tokens, NFT collections, and gaming assets.
​