Permit3 is an Eco-built token-permission protocol that lets one signed message authorize token operations across many blockchains, deployed at the universal address 0xec00030c0000245e27d1521cc2ee88f071c2ae34 on every supported chain. It extends the Permit2 design with a Merkle-proof signature scheme, removing the per-chain signing prompts that used to dominate multichain UX. Updated April 2026.
​

The why is simple. Stablecoin and DeFi flows now span dozens of chains, and approval UX did not scale with them. Until Permit3, a user moving USDC from Ethereum to Base to Arbitrum had to sign three separate approvals (one per chain) plus the actual transfers. Eco's Permit3 launch described this as "fragmented authorization architecture" — every chain maintains isolated permission state, and the user pays the coordination cost.
​

Permit3 solves the per-chain signature pain that has dogged multichain UX since the first cross-chain bridge shipped. Today a user moving tokens across N chains needs N approvals plus N gas tokens; Permit3 collapses that to one signature plus one approval to the canonical contract. The user no longer holds ETH on every chain just to authorize transfers.
​

The friction is structural. ERC-2612 (the original "Permit1" standard) added gasless approvals via signed messages, but only for the chain the signature was emitted on. Uniswap's Permit2 generalized that across tokens that did not implement EIP-2612 themselves, but stayed single-chain. Cross-chain users still juggled approvals, native gas tokens, and the race conditions that come from multi-step bridge flows.
​

Permit3 uses an unbalanced Merkle tree of cross-chain operations. The user signs the tree's root once; each chain's Permit3 contract verifies its branch independently with a Merkle proof. No bridge confirmations between chains, no synchronization delays. Each chain validates locally against the same signature root.
​

The flow has five steps, documented in the Permit3 docs. First, the user grants infinite allowance to the canonical Permit3 contract (one-time per token per chain). Second, the user signs an off-chain message containing a Merkle root of all intended cross-chain operations. Third, the signed message and per-chain proofs are distributed to the chains where work happens. Fourth, each chain's protocol calls Permit3 with the appropriate proof. Fifth, Permit3 verifies the proof against the signed root and executes.
​

Several design choices matter. Permit3 uses non-sequential nonces with salt parameters (instead of Permit2's bitmap), enabling parallel execution. Chain-ID validation prevents cross-chain replay; timestamp ordering prevents race conditions. Witness functionality lets integrators bind custom data into the signature (an order ID, a deadline) without changing the protocol. The contract supports five allowance modes: transfer, decrease, increase, lock, and unlock. Locking is useful for security freezes during anomalous activity; unlock releases.
​

The three standards target the same problem (signature-based token authorization) at increasing scope: ERC-2612 covers a single token on a single chain; Permit2 covers any token on a single chain; Permit3 covers any token across all chains. Permit3 implements Permit2's IPermit interface, so existing Permit2 integrations work unchanged.
​

The practical implication: a wallet that already supports Permit2 can adopt Permit3 by upgrading the contract pointer; existing dApps continue to work because the IPermit interface is preserved. The new functionality (multichain root signing, witness data, lock/unlock modes) is additive. Permit3 also adds first-class support for ERC-7702 account upgrades, which lets an EOA temporarily execute as a smart contract for a single transaction.
​

Developers integrate Permit3 by calling the canonical contract at 0xec00030c0000245e27d1521cc2ee88f071c2ae34 on every supported chain. Two paths exist: upgrade an existing Permit2 implementation by swapping the contract pointer, or build a new signature-based approval flow from scratch. The contract is non-upgradable. It is unowned and open-source.
​

For new integrations, the steps map to the five-stage flow above. Wallets construct the Merkle tree from the user's intended operations, hash the root, and prompt the user to sign. Backend infrastructure distributes the proofs. Integrators can use the Permit3 GitHub repository for examples in TypeScript and Solidity. Cross-chain settlement pairs naturally with the anychain receive primitive — a single signature can authorize approvals; a single address can receive the resulting transfers.
​

For existing Permit2 users, the upgrade is incremental: keep all current single-chain flows, add multichain root signing where it provides value (cross-chain DeFi, multichain checkout, treasury rebalancing). The witness pattern is particularly useful for stablecoin checkout flows where an order ID needs to be cryptographically bound into the approval.
​

Yes. Permit3 implements the same IPermit interface that Permit2 exposes. dApps already integrated with Permit2 continue to work without code changes; new multichain features are opt-in via the additional Permit3-specific calls.
​

Permit3 is deployed at the same address on every major EVM chain Eco Routes supports — Ethereum, Base, Arbitrum, Optimism, Polygon, Unichain, Ink, Celo, BSC, Sonic, HyperEVM, Plasma, and Worldchain. Solana and Tron are not EVM chains; their token approval models differ.
​

The infinite allowance to the Permit3 contract is one-time per token per chain. After that initial approval, every subsequent multichain action requires only the off-chain Merkle-root signature — no further onchain approvals.
​

The lock mode freezes a token's allowance through Permit3 until explicitly unlocked. It is intended as a security primitive for compromised-key recovery flows, not a default state.
​

Sources and methodology. Permit3 mechanics sourced from Eco's Permit3 docs and launch announcement. Permit2 and ERC-2612 details verified against Uniswap docs and the EIP-2612 specification. Last verified April 2026.
​