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. 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, and where the gas numbers actually land. 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 a single chain. Permit3 lets a user sign one EIP-712 message to authorize token spending across every chain where Permit3 is deployed. The cryptographic trick that makes that possible is an Unbalanced Merkle Tree whose root is what the user actually signs, with each leaf scoping 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.

The core technical innovation in Permit3 is the Unbalanced Merkle Tree used to authorize permissions across multiple chains in a single signature. The tree's structure is deliberately asymmetric, and understanding why reveals the gas-efficiency argument for Permit3.

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 verification cost per chain 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.

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 one-signature cross-chain usable without eating the gas budget.

Permit2's nonce model uses a 256-bit bitmap, where each signature consumes one bit. This works well for sequential operations on a single chain but starts to break when permits are minted in bursts or across chains. Two 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.

Permit3 replaces the bitmap with a salt-based nonce. The signer chooses the salt. As long as each salt value is unique per signer, 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.

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 only handles ERC-20. Teams building NFT marketplaces, gaming platforms, or any mixed-asset flow either wrote their own per-standard permit contracts or had users sign multiple different approval types.

Permit3 unifies the interface. A single permit can authorize any mix of ERC-20, ERC-721, and ERC-1155 movements in one signature. 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 collapses what used to be three integration paths into one.

EIP-7702 lets an EOA temporarily act as a smart contract for a single transaction. Permit3 ships native support for this pattern. An EOA can invoke Permit3 as part of a 7702 delegation, combining permission and execution in one transaction with no upfront smart-account deployment. 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.

The most important engineering property of Permit3 from an upgrade perspective: it implements the full Permit2 interface. Every function Permit2 exposes is present on Permit3 with the same signature and the same semantics. That means:

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.

The honest answer: 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 small (a few thousand gas) and usually invisible in the context of a larger transaction.

For multichain usage, Permit3 wins cleanly. The alternative is separate Permit2 signatures on each chain, each requiring the user to hold native gas on that chain to sign it (because the spender contract needs gas to submit, and someone has to pay). Permit3 consolidates that into one off-chain 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 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.

Permit3 is not always the answer. A few cases where Permit2 still makes sense:

Most teams reading this comparison do not fall into those categories, but they are worth flagging.

A typical upgrade sequence for an app that already integrated Permit2:

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 layer. It pairs with execution layers like Eco Routes for cross-chain stablecoin settlement, with ERC-7683 cross-chain intents as a complementary settlement standard, and with ERC-4337 account abstraction for teams that want smart-account UX on top of the permit layer. Each of these standards solves a different slice of the cross-chain UX problem, and Permit3 specifically handles the permission slice.

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 to fifteen-plus chains.

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 can 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.