Permit3 is an open-source token approval protocol that lets one off-chain signature authorize token movements across multiple chains, with the gas cost paid by a relayer rather than the user. Released by Eco and audited as part of the 2025 multichain permissioning push, it removes two distinct frictions from cross-chain stablecoin UX: the native-gas requirement on each destination chain, and the per-chain re-signing that breaks multichain flows.
​

This article focuses on the gas-abstraction half of the protocol, and on the structural pieces that make gas abstraction useful at multichain scale: the Unbalanced Merkle Tree that packs per-chain authorizations under one signed root, non-sequential nonces that let chains execute in any order, and the deterministic deployment that places the same contract address on every supported chain. Gas abstraction removes the native-token tax. Multi-chain execution alignment, one signed Merkle root, non-sequential nonces, same contract address everywhere, is what turns that into a single coherent cross-chain transaction instead of N disconnected ones.
​

Gas abstraction in Permit3 refers specifically to the token-permission layer. A user signs one EIP-712 typed-data message off-chain, costing nothing, and a relayer or spender contract submits that signature onchain on each destination, paying the gas. The user never needs to hold ETH, BNB, MATIC, or any other native token on the chains being authorized.
​

This is narrower than full account abstraction. ERC-4337 sponsors entire UserOperations through a paymaster contract; Permit3 sponsors the approval step itself, and is compatible with both plain EOAs and smart accounts. The signature is a cryptographic artifact, not a transaction. It sits in the application's backend until a relayer is ready to use it.
​

What happens onchain is mechanical. A relayer calls permit(owner, salt, deadline, timestamp, permits, proof, signature) on the Permit3 contract. The contract verifies the EIP-712 signature against the owner address, checks the supplied Merkle proof against the signed root, and updates the allowance ledger. The gas for that verification and ledger write comes out of the relayer's balance. Implementation details are public in the eco/permit3 repository.
​

Permit3 uses an Unbalanced Merkle Tree to commit to per-chain permit data under one root. The user signs that root, and a relayer on each chain submits only the leaf and proof that applies to that chain. Other chains never see other chains' data. The signed root is what binds them together, and one signature is what authorizes the entire set.
​

The structure matters because cross-chain calldata is not free. If a user is authorizing token pulls on Ethereum mainnet, Base, Optimism, and Arbitrum, naive designs would force the relayer on mainnet to submit every chain's permit data to verify the signature, paying L1 gas for L2 bytes. The Unbalanced Merkle Tree lets the mainnet relayer submit only the mainnet leaf plus a short proof path, while each L2 relayer submits only its own leaf. Calldata cost on the expensive chain stays near the minimum, and cheaper L2 chains carry no overhead either.
​

"Unbalanced" refers to the tree's shape: leaves do not need to be equal-depth, so a user authorizing one mainnet permit and four L2 permits can place the mainnet leaf at a shorter depth than the L2 leaves, further trimming L1 calldata. The Eco docs Permit3 overview walks through the leaf encoding, and the Auditless research note on Permit3 diagrams the proof construction.
​

Permit3 abandons strict nonce ordering. Instead of an incrementing counter that forces signed permits to execute in sequence, each permit carries a unique salt that is marked as spent independently on each chain. The result: relayers on Base, Optimism, and Arbitrum can submit the same user's permits in any order, or in parallel, without one chain blocking another.
​

Strict nonces are what break naive multichain permits. If permit nonce 5 must land before nonce 6, and the chain holding nonce 5 is congested, every later chain waits. Worse, if nonce 5 fails for a transient reason on its destination chain, every later permit is stuck behind it. Permit3's non-sequential salts decouple chains. A failure or delay on Optimism does not delay execution on Arbitrum.
​

The salt is what prevents replay. Once a salt is consumed on a chain, that chain's contract rejects any future submission carrying the same salt. The signed Merkle root binds the salt to the owner, the chain, the token, and the amount, so a relayer cannot lift a leaf from one user's signature and reuse it elsewhere. Spent salts are tracked per chain because each chain only ever sees its own leaves.
​

A worked example clarifies the moving parts. Assume a user wants to authorize USDC pulls of 1,000 each on Base, Optimism, and Arbitrum so a payment app can route the cheapest leg. The user signs one Permit3 message whose Merkle root commits to three leaves, one per chain, each with its own salt and a shared deadline.
​

The app submits the signature to three relayers, one per chain. Each relayer calls permit on the Permit3 contract on its chain with the chain-specific leaf and the Merkle proof. All three calls verify the same signature against the same root. Each chain marks its own salt as spent. The spender contract on each chain can now pull up to 1,000 USDC from the user's wallet.
​

If the Optimism leg fails because the relayer hits a deadline or runs out of native gas, Base and Arbitrum still complete. The user did not overspend, because each chain's salt is checked independently and only the salts that landed are spent. There is no global rollback, and the user does not need to re-sign anything on the chains that did succeed. This is the partial-fill semantic that strict-nonce designs cannot offer.
​

Double-spend across chains is prevented by the salt being chain-scoped at the leaf level. The leaf for Base authorizes USDC movement on Base only; a relayer that tried to submit the Base leaf on Arbitrum would fail the proof check because Arbitrum's contract is looking for an Arbitrum-scoped leaf at the agreed path in the tree.
​

Permit3 is deployed at 0xEc00030C0000245E27d1521Cc2EE88F071c2Ae34 on every supported chain through ERC-2470, the singleton factory standard. Same bytecode, same address, derived from the same salt. That uniformity is what makes a single-signature-many-chains contract trustable: the signature commits to a chain ID and a contract address, and the contract at that address is byte-identical to the audited reference.
​

Without deterministic deployment, an attacker who controlled the deployer key on a new chain could push a malicious contract at a fresh address and convince apps to route permits through it. ERC-2470 removes that attack surface. Anyone can verify the deployed bytecode on any chain by reading the address, and the deployment salt is reproducible. Cross-chain protocols that rely on a known contract presence, including Permit3, lean on this primitive heavily.
​

The practical result for developers: integrating Permit3 on a new chain is one address lookup. No registry call, no configuration map, no per-chain deployment ceremony. The contract is either at 0xEc00030C0000245E27d1521Cc2EE88F071c2Ae34 on the chain, in which case Permit3 works, or it is not, in which case Permit3 is not live there yet.
​

Relayers pay native gas on each chain and recover the cost through the application's fee structure. Three economic models cover most production deployments: app-subsidized, spread into the transferred amount, or extracted in the stablecoin being moved. None of these are visible to the end user as a separate gas line item.
​

The application eats the relayer cost as customer acquisition or retention. This is common in consumer wallets and exchanges running onboarding flows where every dropped user costs more than the gas saved. The model works when per-user lifetime value exceeds relayer spend and when the app can rate-limit abuse.
​

The app marks up the transfer by a small percentage that covers relayer gas. The user moves 1,000 USDC and receives 999.80 USDC, with the spread absorbing the relayer cost. Stablecoin routing platforms already price gas into their quotes, so adding Permit3 authorization costs fits the existing model.
​

A variant where the relayer extracts its cost directly in the stablecoin being moved. The user never touches native gas; the relayer converts the extracted stablecoin to native gas out-of-band. This maps cleanly to the broader "stablecoins as gas" pattern that consumer payment apps have pushed in 2025 and 2026.
​

Permit2 was designed for single-chain gasless approvals and uses sequential nonces tied to one chain at a time. Permit3 retains the gasless-approval property and adds Unbalanced Merkle Trees, non-sequential salts, and deterministic deployment so that one signature can authorize many chains in alignment. The comparison below covers the multi-chain axis specifically, with neutral framing on every other dimension.
​

The full technical contrast lives in the Permit3 vs Permit2 reference, and the public launch context is in the Introducing Permit3 announcement. The Auditless and Eco Docs writeups linked earlier cover the cryptographic detail.
​

The signature-to-execution flow has four stops. Understanding each clarifies which party pays for what and where failures can be retried. The flow is identical whether one chain or ten chains are authorized, because the Merkle structure compresses the multi-chain case into the same shape as the single-chain case.
​

The wallet presents an EIP-712 typed-data prompt listing the tokens, amounts, chains, and deadline. The user reviews and clicks to sign. No transaction is broadcast, no gas is spent, and the signature lives in the application's memory or backend.
​

The app or solver takes the signature plus the per-chain Merkle proofs and queues them for submission. The app chooses which chains to execute on and in what order, since salts are non-sequential and chains do not block each other.
​

The relayer calls permit on the Permit3 contract at 0xEc00030C0000245E27d1521Cc2EE88F071c2Ae34 on each destination, passing the signature, the chain's leaf, and the Merkle proof. The contract verifies the signature and updates the allowance. The relayer pays the gas.
​

A spender contract such as a DEX router, payment processor, or bridge calls transferFrom on Permit3 to pull the authorized tokens. This can happen in the same transaction as step 3 or in a later one. Either way, the spender or relayer covers the gas.
​

At no point does the user need native gas on any destination. The only ETH, BNB, or other native token spent anywhere is from the relayer's balance.
​

Autonomous agents executing across venues cannot pause to re-sign a fresh approval every time they discover a new chain to transact on. Permit3 multi-chain execution alignment is the primitive that lets one human signature authorize a long-running agent to act across chains, with non-sequential salts ensuring that a failure on one chain does not strand the others.
​

An agent allocating stablecoin liquidity across Base, Optimism, Arbitrum, and Polygon needs persistent multichain spend authority. Without Permit3, the agent's principal would have to sign separate approvals for each chain at agent startup and again every time the agent rebalanced into a new chain. With Permit3, the principal signs once. The agent uses a relayer wallet to pay gas as it executes, and salts ensure that any single failed leg does not corrupt the agent's view of which authorizations are still spendable.
​

This pattern is what makes the broader agentic-commerce thesis tractable. The deeper treatment of how gas abstraction and multi-chain alignment unlock autonomous cross-chain settlement is in Gas Abstraction for AI Agents, and the broader payment-flow context is in cross-chain agentic payments.
​

Gas abstraction combined with multi-chain alignment makes several previously awkward flows viable. The common thread is removing per-chain native-gas requirements while keeping per-chain authorization auditable and revocable. Stablecoin volume on the four major chains in the table above sits well over USDC's $75.6B and USDT's $187.2B circulating supply, so the relevant flows touch real liquidity, not theoretical balances.
​

A wallet offering "just use USDC everywhere" needs gas abstraction at the permission layer and stablecoin-denominated fees at execution. Permit3 delivers the permission piece. Users sign one permission at onboarding, authorizing the wallet's routing contract to move USDC across chains on demand, and never see a native-gas balance again.
​

A merchant accepting USDC can pull the customer's USDC from whichever chain has the cheapest gas at the moment without asking the customer to bridge. The customer signs one Permit3 message; the merchant's backend selects the source chain. Stablecoin payment gateways increasingly use this pattern as the default for multichain merchants.
​

Ops teams sweeping balances across ten or more chains stop having to maintain native gas on each. One Permit3 signature authorizes the sweep agent to pull balances above a threshold; the agent executes using a dedicated relayer wallet that carries native gas for all chains. See sweep automation tools for teams running this in production.
​

Institutional traders executing large-volume stablecoin OTC trades sign once and let the counterparty's settlement agent pull funds from whichever source chain is cheapest, without coordinating native-gas balances across multiple chains for each leg.
​

Permit3 does not remove gas from the system. It relocates it. Someone always pays. Teams evaluating Permit3 should be clear about who that someone is in their model, how relayer reimbursement is priced, and what happens when relayer infrastructure or destination chains misbehave during a multichain submission.

Permit3 occupies a specific layer of the gas-abstraction stack. ERC-4337 paymasters sponsor entire UserOperations executed by smart accounts. EIP-2612 permits are gasless approvals built into specific tokens. Permit3 generalizes the gasless-approval pattern across any ERC-20, ERC-721, or ERC-1155 and extends it across chains. The three stack rather than compete.
​

An ERC-4337 smart account can sign a Permit3 message and have a paymaster sponsor the UserOp that submits it onchain. A token that ships EIP-2612 natively can still be moved through Permit3 if the application wants cross-chain coverage and multi-asset batching. See the EIP-2612 explainer for the single-chain precursor and the ERC-4337 overview for the smart-account layer.
​

Meta-transactions via EIP-2771 use a trusted forwarder to relay signed transactions. They predate Permit3, solve a subset of the same problem, and require every participating contract to implement the forwarder pattern. Permit3 is a protocol-level solution that works for any contract on any supported chain in one signature.
​

Permit3 is one layer of a broader stack for multichain stablecoin apps. Permission, execution, and settlement are distinct concerns, each handled by a different standard or protocol, and each contributing to the end-to-end experience of a user moving stablecoins across chains without thinking about gas, nonces, or per-chain configuration.

For the fuller picture of how Permit3 ships, see the Permit3 overview, the Permit3 vs Permit2 reference, and the evolution of token approvals from ERC-20 to Permit3. Source code and audit reports are in the eco/permit3 GitHub repository.
​

Users pay zero native gas directly for the authorization step. The relayer or spender contract pays native gas on each chain and typically recovers the cost through the application's fee structure, often denominated in the stablecoin being moved. The user sees an all-in price, not a separate gas line item.
​

Yes. Permit3 is open-source and permissionless. Any party can submit a valid signature and Merkle proof to the Permit3 contract on any supported chain. Apps that want control over the relayer path run their own infrastructure, while shared community relayers exist for applications that prefer to outsource.
​

The legs that landed remain valid, and their salts are spent on their chains. The leg that failed can be resubmitted up to the permit deadline, or skipped entirely if it is no longer needed. The user does not need to re-sign anything for the chains that already succeeded, because each chain's salt is checked and spent independently.
​

Yes. Permit3 supports ERC-20, ERC-721, and ERC-1155, and the Unbalanced Merkle Tree structure works the same for any token type. An NFT marketplace can authorize a cross-chain NFT sale with a single gasless signature the same way a DEX can authorize a token swap.
​

Not exactly. "Gasless transactions" can refer to meta-transactions, sponsored UserOps, or gasless approvals. Permit3 specifically provides gasless cross-chain authorization at the permission layer. Combining it with a paymaster or relayer gives a fully gasless user experience for cross-chain flows.
​

Each leaf in the Unbalanced Merkle Tree is scoped to a specific chain, token, amount, and salt. A leaf intended for Base will fail the Merkle proof check on Arbitrum because the tree commitment binds the leaf to its position and chain. Once a salt is consumed on its chain, that chain's contract rejects any later submission carrying the same salt.
​