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. 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. No native gas, no per-chain approvals, no retry logic when a new spender ships. The permission lives in a contract deployed at the same address on every chain, so the same signature authorizes action everywhere at once.

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, 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, authorizes permissions across every Permit3-deployed chain in a single action. It uses Unbalanced Merkle Trees for gas-efficient cross-chain proofs, non-sequential nonces for concurrent async operations, and maintains full backward compatibility with Permit2 so apps that already integrated Permit2 can upgrade in place.

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.

The result: the Permit3 team measured that for a five-chain cross-chain permit, the unbalanced structure reduces total gas cost by a large double-digit percentage versus a balanced tree, with all savings concentrated on the most expensive chain.

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 replaces the bitmap with a salt-based nonce that lets the signer create as many concurrent permits as they want without collision. This matters for agentic systems and treasury automation, where permits are minted in bursts across chains.

Permit3 implements the full IPermit interface from Permit2. An integration that accepts Permit2 signatures can accept Permit3 signatures without code changes, because Permit3 exposes the same transferFrom, allowance, and approve entry points that Permit2 defined. Apps that already integrated Permit2 can upgrade to Permit3 by swapping the contract address and gain the cross-chain upgrade for free.

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 authorizes the rebalancer to pull from any position on any chain, drop it into the right destination, and settle without per-chain native-gas prep.

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 never needs to hold or pay native gas on any destination chain to authorize a token movement. 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: the user does not need native gas to authorize permissions, period. 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 one of the core building blocks Eco ships as part of its broader stablecoin orchestration network. Eco Routes handles the execution and settlement of cross-chain stablecoin intents across 15+ chains; Programmable Addresses expose deterministic deposit endpoints with configurable routing logic; Permit3 provides the permission layer that makes all of this usable from a single user signature.

A typical flow: the user signs a Permit3 authorization that covers USDC on Base, Optimism, and Arbitrum. The app's backend quotes the cheapest execution path via Eco Routes. A solver pulls funds from the source chain using the Permit3 signature, submits the intent, and the payment settles on the destination chain with no native gas exposure for the user on any chain involved.

Teams integrating Eco's stack use Permit3 as the permission primitive and Eco Routes as the execution primitive. The two are independent standards with well-defined interfaces, so a team can adopt Permit3 without adopting Routes, or vice versa, but the combined flow is where the full UX win shows up.

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 a superset of Permit2. It implements the full IPermit interface, so applications integrated with Permit2 can swap the contract address and gain cross-chain support without code changes. Teams that need single-chain-only permissions can keep using Permit2, but Permit3 adds multichain support at no compatibility cost.

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 for smart accounts that want to combine permit and execution, 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 every EVM chain. 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.