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, letting developers simplify cross-chain token operations using a single user signature. Permit2, by contrast, solved the same problem on a single chain. If you already know Permit2 and you are weighing whether the upgrade is worth the integration work, this is the comparison you need.
​

This post walks through the concrete technical deltas between Permit2 and Permit3: the Unbalanced Merkle Tree structure, nonce management, the allowance model, backward compatibility guarantees, where the gas numbers actually land, and the architectural reframe that turns the Merkle root from a UX trick into a cross-chain settlement primitive. If you want the definitional overview of the protocol instead, start with our full Permit3 guide.
​

Permit2 lets a user sign one EIP-712 message to authorize token spending on one chain. Permit3 lets a user sign one EIP-712 message to authorize token spending across every chain where Permit3 is deployed, with the signed payload acting as the canonical permission state that each chain redeems against. The cryptographic mechanism is an Unbalanced Merkle Tree whose root is what the user signs.
​

Each leaf scopes a per-chain permission. Permit3 also ships new nonce semantics, expanded allowance modes, ERC-7702 integration, and multi-token support for ERC-721 and ERC-1155. It keeps the full Permit2 interface intact so existing integrations upgrade in place.
​

Permit3 functions as a cross-chain settlement layer for token permissions. The signed Merkle root is the canonical commitment to a permission state, and each chain's execution is a redemption against that commitment. Permit2 sits one layer lower, as a per-chain approval contract whose authority terminates at the chain boundary.
​

This is the framing shift that explains why everything else in Permit3 looks the way it does. Permit2 was built to replace ERC-20's approve with something safer and more expressive, but it stayed inside the single-chain model: a user authorizes a spender on chain X, the spender pulls tokens on chain X, and any other chain requires a fresh approval. The state of the user's permissions lives in the Permit2 contract on each chain independently.
​

Permit3 lifts that state up a layer. The user signs once, and the signature is the settlement primitive. That single artifact commits the user to a full set of per-chain permissions in one cryptographic object. Solvers, relayers, and spender contracts on any destination chain treat the signed root as the source of truth and prove their slice of it onchain. Permit2 was an approval contract; Permit3 is the settlement layer for token permissions across chains, and once you see it that way, the Merkle root, salt nonces, and 7702 integration all snap into place as one coherent settlement primitive.
​

Three layers describe the integration shape:

The shape rhymes with how rollups settle to L1: a signed state commitment at the settlement layer, per-chain proof verification at the execution layer. The Permit3 signature is the settlement object, and the per-chain redemption is the execution event.
​

The table below pairs every Permit2 capability with its Permit3 counterpart across ten dimensions, from chain scope and contract address to nonce model, allowance modes, supported token standards, ERC-7702 integration, and the architectural role each protocol plays in a modern cross-chain stack. The architectural-role row anchors the rest of the deltas.

The Unbalanced Merkle Tree is the data structure Permit3 uses to authorize permissions across multiple chains in one signature. It is deliberately asymmetric, ordering chains by gas cost so that expensive chains sit close to the root with short proofs and cheap chains sit deep in the tree with longer proofs. The asymmetry is what makes the settlement model gas-viable.
​

A balanced Merkle tree assigns every leaf the same proof length. If you authorize permissions on 8 chains, every proof is 3 hashes deep. On cheap-gas chains like Arbitrum or Optimism, the proof verification is negligible. On Ethereum mainnet, where every hash in a Merkle proof burns real calldata and compute, 3 hashes on a long path still costs meaningfully more than a direct EIP-712 check.
​

Permit3 orders chains in the tree by gas cost. Expensive chains sit close to the root with short proofs; cheap chains sit deep in the tree with longer proofs. The total amount of hashing happens wherever gas is cheap, and the expensive chain pays the minimum verification cost. The signer commits to the same total permission set, but the per-chain verification cost is optimized.
​

The trade-off: proofs for cheap chains are longer than they would be in a balanced tree, which marginally increases their gas. The net is positive because the multiplier on Ethereum gas is so much larger than on L2 gas that every hash moved off Ethereum saves more than it adds elsewhere. With Ethereum holding roughly $37.1B in TVL across DeFi protocols as of Q2 2026 (per DeFiLlama), it remains the most cost-sensitive surface to optimize for.
​

The signed Merkle root is the canonical permission state. Each onchain execution is a redemption against that state, not a fresh authorization. A solver on Base presenting a proof for the Base leaf is doing the same shape of work as a rollup posting a state proof against an L1 commitment: the heavy commitment happened once, offchain, at signing time, and the chain only verifies that the local action falls inside it.
​

This is what makes the framing more than a vocabulary choice. The signer is not approving 8 spenders on 8 chains. The signer is producing one settlement object, and the chains take turns reducing it.
​

The Permit3 tree is not purely unbalanced. It is a hybrid: subtrees of related permissions (often per-token groupings) are balanced internally for simplicity, and the top-level structure connecting those subtrees is unbalanced to put the expensive chains near the root. This keeps the signing and verification code tractable while still capturing the gas asymmetry.
​

For applications that only target one chain, this is all moot. Permit2 works fine and the Merkle overhead is pure cost. For applications spanning multiple chains, the unbalanced design is the feature that makes the one-signature settlement model usable without eating the gas budget.
​

Permit2's nonce model uses a 256-bit bitmap, where each signature consumes one bit. This works for sequential operations on a single chain but breaks down when permits are minted in bursts or across chains. Permit3 replaces the bitmap with a salt-based nonce chosen by the signer, eliminating bitmap-slot collisions and letting permits be produced in parallel.
​

Two Permit2 permits signed at nearly the same moment can race for the same bitmap slot, forcing the wallet to pre-serialize signing or introducing retry logic. As long as each salt value is unique per signer in Permit3, permits never collide. This is a small change with large implications.

The trade-off is that the signer is responsible for salt uniqueness. In practice this is trivial (random 32-byte salt) but it is a responsibility shift versus Permit2's bitmap, which handled this automatically.
​

Permit2 exposes two mutation modes on allowances: full transfer and decrease. Permit3 expands that to five: Transfer, Decrease, Increase, Lock, and Unlock. The expanded set lets the settlement object encode richer permission lifecycles, including pre-authorized budgets that grow over time and time-bound freezes during high-risk windows.

The expanded model lets Permit3 express flows that Permit2 cannot represent natively: pre-authorized budgets that grow over time, time-bound locks during high-risk windows, and graceful recoveries without having to invalidate all existing permits. If you are building a stablecoin rebalancing tool or any system that needs long-running authorizations, the five-mode model is notably more ergonomic.
​

Permit2 handles ERC-20 only. Permit3 unifies ERC-20, ERC-721, and ERC-1155 under a single interface, so one signature can authorize any mix of fungible and non-fungible movements. For NFT marketplaces, gaming platforms, and any mixed-asset flow, this collapses three integration paths into one.
​

Teams building with Permit2 either wrote their own per-standard permit contracts or had users sign multiple different approval types. In Permit3 the spender receives the same permit call regardless of token standard and branches on the token type inside the contract. For an NFT marketplace that also accepts ERC-20 bids, this is a meaningful reduction in audit and integration surface.
​

Permit3 ships native support for EIP-7702, the upgrade that lets an EOA temporarily act as a smart contract for a single transaction. An EOA can invoke Permit3 as part of a 7702 delegation, combining permission and execution in one transaction without deploying a separate smart account.
​

For apps that want account-abstraction UX without forcing users into a separate smart wallet, this is the cleanest integration path. Permit2 predates 7702 and has no native integration, so teams that want combined permit-and-execute flows have to build the glue themselves.
​

Permit3 implements the full Permit2 interface. Every function Permit2 exposes is present on Permit3 with the same signature and the same semantics, so any spender contract that accepts Permit2 signatures can swap the contract address and accept both Permit2-style and Permit3-style signatures with no user-facing changes.

This is the pragmatic choice that makes adoption realistic. A team that already shipped Permit2 does not need to re-audit their spender contract logic to upgrade to Permit3. The signature verification path is the same. The new capabilities (Merkle proofs, expanded allowance modes, multi-token) are opt-in.
​

For single-chain usage, Permit3 costs marginally more than Permit2 because of the Merkle verification overhead, even though the tree only has one leaf. The difference is a few thousand gas and usually invisible inside a larger transaction. For multichain usage, Permit3 wins cleanly because the alternative is separate Permit2 signatures on every chain, each requiring native gas to submit.
​

Permit3 consolidates that into one offchain signature. The cross-chain gas cost is paid only by the solver or relayer executing the permit on each destination chain, and the unbalanced tree structure keeps that cost low. For applications that expect users to move stablecoins across more than one chain in a session (the total stablecoin market sits at roughly $315.3B per DeFiLlama as of Q2 2026, with USDC at $75.6B and USDT at $187.2B distributed across many chains), the net is dramatically in Permit3's favor.
​

For a pure single-chain DEX, Permit2 remains slightly cheaper but the gap is small enough that most teams prefer the forward-compatibility of Permit3.
​

Treating Permit3 as a settlement layer changes the integration design. Instead of asking "where do I call approve on each chain," the integrator asks "what does the user's signed permission state need to look like, and which actors redeem against it." The signing surface collapses to one event, and execution becomes a per-chain redemption that solvers and relayers handle.
​

In a Permit2 world, the natural integration is approve-then-spend on every chain the user touches. The app coordinates approvals, the wallet coordinates gas, and the user signs a fresh message every time they hop chains. In a Permit3 world, the integrator wires a single signing flow to a permission spec, the user signs once, and downstream execution is whatever the spec authorized. Cross-chain intent systems like Eco Routes, ERC-7683 intent settlers, and bundler networks become natural consumers of the settlement object, each redeeming the leaf that applies to them. The signing UX, the gas model, and the spender architecture all simplify together because the permission state has been promoted to its own layer.
​

Permit3 is not always the answer. Permit2 still makes sense for single-chain-only applications with no multichain roadmap, for very-high-volume single-chain venues where 2,000 to 3,000 extra gas per permit is material, and for environments where Permit3 has not yet been deployed. Most teams reading this comparison do not fall into those categories, but the cases are worth flagging.

A typical upgrade sequence for an app that already integrated Permit2 swaps the contract address, verifies that existing Permit2-formatted signatures still verify against Permit3, and then opts in to the new cross-chain Merkle signing flow. The order below keeps the migration low-risk and reversible at each step.

For the hands-on code, see our Permit3 developer implementation walkthrough. If you are thinking about the full lineage, our evolution-of-approvals guide traces the design decisions from ERC-20 through Permit3.
​

Permit3 is the permission settlement layer. It pairs with execution layers like Eco Routes for cross-chain stablecoin movement, with ERC-7683 cross-chain intents as a complementary settlement standard for the order itself, and with ERC-4337 account abstraction for teams that want smart-account UX on top of the permit layer.
​

Each standard solves a different slice of the cross-chain UX problem. Permit3 handles the permission slice. ERC-7683 handles the intent slice. ERC-4337 handles the account slice. The three compose: a 4337 account can sign a Permit3 settlement object that authorizes a 7683 intent that a solver executes on a destination chain. The fact that they compose is what makes the layered framing useful instead of academic.
​

Yes. Permit3 functions as a cross-chain settlement layer for token permissions. The user signs one EIP-712 message over a Merkle root, and that signed root is the canonical permission state. Each chain's spender contract redeems against the root by verifying a Merkle proof for its leaf, rather than holding a chain-local approval as Permit2 does.
​

Permit3 is deployed at 0xec00030c0000245e27d1521cc2ee88f071c2ae34 on every chain Eco supports today. The deterministic ERC-2470 Singleton Factory makes adding new chains a one-call operation, so coverage expands as Eco's supported-chain list grows.
​

Yes. Because Permit3 implements the full Permit2 interface, a spender contract that accepts a Permit2 signature will verify and execute a Permit2-formatted signature submitted to the Permit3 address. Cross-chain Permit3 signatures use a different entry point but coexist with Permit2-style signatures in the same spender.
​

Permit3 is an EVM protocol. The Merkle proof and EIP-712 primitives are Ethereum-native. Eco's broader stack supports Solana via Eco Routes, but the Permit3 contract itself deploys on EVM chains only. For Solana flows, teams use Routes' intent model for the transfer and handle SPL token approvals through Solana's native mechanisms.
​

Each Permit3 signature encodes a deadline, a salt-based nonce, and a Merkle root committing to the full permission set. Once a permit is executed on a given chain, the nonce for that (signer, salt) pair is consumed and cannot be replayed. Replay across chains is handled by the per-leaf scoping in the Merkle structure.
​

No. The Permit3 contract deployed at the canonical address is non-upgradeable by design. Upgrades ship as new contract deployments with distinct addresses, and the signing domain makes the contract address part of the signature scope, so permits cannot accidentally target a future version.
​