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. This post focuses on the gas-abstraction half of that promise: how one signature authorizes token movement across fifteen-plus chains without the user ever holding native gas on any destination.

If you have tried to build a cross-chain stablecoin app, you know the gas problem. Your user wants to pay 1,000 USDC from Base. Your merchant wants to receive USDC on Optimism. In the standard model, the user needs ETH on Base to approve the transfer and potentially to sign the intent. If the user only holds USDC, they are stuck. Permit3 removes that dependency entirely. Here is how the mechanics work, and what it unlocks.

Gas abstraction in the Permit3 context is narrower than full account abstraction. It specifically refers to the permission layer. Permit3 lets a user authorize token spending without spending any native gas on any chain. The user signs one EIP-712 message off-chain. That signature is cryptographic proof of authorization, and it costs the user nothing to produce.

What happens onchain, a relayer or solver pays for. The relayer submits the signature plus a Merkle proof to the Permit3 contract on each destination chain. The contract verifies the signature and executes the permit, pulling the user's tokens. The gas for those verification-and-pull transactions comes out of the relayer's balance, not the user's.

The economics: relayers recover their gas cost through the application's fee structure. A stablecoin payment app might add a small markup to the transfer amount that covers relayer gas. A cross-chain DEX might include relayer gas in the solver quote. A treasury automation tool might pre-fund a dedicated relayer wallet and reimburse itself from treasury operations. The user sees none of this. They see: one signature, one outcome, no ETH/MATIC/BNB/OP/ARB to pre-fund.

Holding native gas on every chain you use is a tax that almost no one talks about. A consumer who wants to try a DeFi app on Base needs ETH on Base. A team running treasury ops across ten chains needs native balances on every one of them plus a monitoring system to top them up. An agentic system autonomously moving funds across venues cannot pause to beg for gas. The native-gas requirement is one of the most persistent UX barriers in crypto, and it scales linearly with chain count.

Permit3's gas abstraction eliminates that tax for the authorization step. It does not eliminate gas globally (someone still pays, ultimately), but it removes the requirement that the user specifically hold native gas on each chain they want to authorize.

Consider the before/after for a five-chain payment flow:

The "time to authorize" row is the one teams underestimate. If a user does not already hold native gas on a chain, they have to bridge ETH onto it before they can even approve a token. That takes minutes on good days, hours on bad days, and a non-trivial fraction of users bounce during that bridge step. Permit3 collapses the entire pre-authorization cost to one off-chain signature.

The signature-to-execution flow has four stops. Understanding each clarifies who pays for what.

The user's wallet presents an EIP-712 typed-data prompt. The user reviews the scope (tokens, amounts, chains, deadline) and clicks to sign. No transaction is broadcast. No gas is spent. The signature is a cryptographic artifact; it lives in the client app's memory or database.

The app (or a solver, or any third party) takes the signature and relevant Merkle proofs and queues them for submission. This is a backend task, not a user-facing one. The app chooses which chains to execute on and in what order.

The relayer calls permit3.permit(owner, salt, deadline, timestamp, permits, proof, signature) on the Permit3 contract at 0xec00030c0000245e27d1521cc2ee88f071c2ae34 on each destination chain. The relayer pays the gas for this call. The contract verifies the signature, checks the Merkle proof, and updates the allowance.

A spender contract (the DEX, bridge, payment processor, treasury router, whatever the app is) calls transferFrom on Permit3 to pull the now-authorized tokens. This can be in the same transaction as step 3 or in a subsequent transaction. Either way, the spender or relayer pays the gas; the user does not.

At no point in this flow does the user need native gas on any destination chain. The only ETH (or chain-native token) spent anywhere is from the relayer's balance.

Three common economic models for relayer reimbursement.

The application eats the relayer cost as a cost of doing business. Common in consumer apps that are trying to remove all friction for user onboarding. Works when the per-user lifetime value exceeds the relayer gas spend, and when the app has a way to prevent abuse (rate limits, KYC, captchas). Large wallets and exchanges subsidize gas for promotional flows using this model.

The app marks up the transfer amount by a tiny percentage that covers relayer gas. The user sees an all-in cost (move 1,000 USDC; receive 999.80 USDC at the destination) and does not have to think about gas separately. This is how most cross-chain stablecoin flows price today. Teams using stablecoin routing platforms already price gas into their quotes, so adding Permit3 authorization costs is natural.

A specific variant of "spread into the transaction" where the relayer explicitly extracts its gas cost in USDC (or whatever stablecoin is moving). The user never touches native gas; the relayer sells the extracted USDC for native gas out-of-band. This model maps directly to the "stablecoins as gas" thesis that Eco and others have pushed publicly.

ERC-4337 paymasters sponsor gas for individual UserOperations executed by a smart account. They are per-transaction, per-account, and require the user to have a 4337 smart account. Permit3 gas abstraction operates on a different layer. The user can be a plain EOA. The gas sponsorship happens for the permission layer specifically. The two stack cleanly: a 4337 smart account can sign a Permit3 message, and a paymaster can sponsor the resulting UserOp.

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

EIP-2612 permits are gasless approvals for specific tokens that implemented the extension. They work well but are single-use, single-chain, and only work for tokens that ship the extension natively. Permit3 generalizes the gasless approval pattern to any ERC-20, adds cross-chain support, and extends to ERC-721/ERC-1155. See our EIP-2612 explainer for the precursor pattern.

Permit3 is a piece of a broader shift toward letting users pay for cross-chain activity in stablecoins rather than native tokens. Several pieces have to line up for this to work end-to-end.

When these four pieces stack, the user's entire cross-chain stablecoin experience is denominated in stablecoins. No ETH, no BNB, no MATIC, no per-chain native-gas balances. Just USDC in, USDC out, with a small spread covering relayer and solver costs.

The gas-abstraction property alone makes several previously awkward flows viable.

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

A merchant accepting USDC can offer checkout that pulls 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 and executes. Stablecoin payment gateways increasingly use this pattern as the default for multichain merchants.

Ops teams that sweep balances across ten-plus chains stop having to maintain native-gas balances on each one. One Permit3 signature authorizes the sweep agent to pull balances on any chain above a threshold; the agent executes sweeps using a dedicated relayer wallet that holds native gas for all chains. See sweep automation tools for teams shipping this today.

An autonomous agent operating across chains cannot practically hold native gas on every chain it might transact on. Permit3 lets the agent's principal grant multichain spend authority in one signature; the agent executes wherever the opportunity appears, with a relayer wallet handling gas. This is the foundational primitive behind cross-chain agentic payments.

Institutional traders executing large-volume stablecoin OTC trades appreciate signing once and letting the counterparty's settlement agent pull funds from whichever source chain is cheapest at the moment, without coordinating native-gas balances across chains.

Permit3 does not remove gas from the system. It relocates it. Someone always pays. Teams evaluating Permit3 for a new flow should be clear-eyed about who that someone is in their model.

A few common pitfalls:

Permit3 is one layer of a broader gas-abstraction stack for multichain stablecoin apps. The other layers:

For the fuller picture of how these combine into what Eco ships, see our Permit3 overview. For the technical comparison against Permit2, see Permit3 vs Permit2. For the historical context, see the evolution of token approvals.

You pay zero native gas directly. The relayer or spender contract pays native gas on each chain and typically recovers the cost through the application's fee structure, which is often denominated in the stablecoin you are moving. You see an all-in price, not a separate gas line item.

Yes. Permit3 is open-source and permissionless. Anyone can submit a valid signature and Merkle proof to the Permit3 contract. Apps that want control over the relayer path often run their own, while community relayers exist for applications that prefer to outsource.

The permit simply cannot be executed after its deadline. No tokens move. The user is not charged anything. A robust application monitors permit deadlines and resubmits (with a fresh permit) if a relayer fails.

Yes. Permit3's gas abstraction applies to any token type it supports, including ERC-20, ERC-721, and ERC-1155. 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 mean several things: meta-transactions, sponsored user-ops, gasless approvals. Permit3 specifically provides gasless cross-chain authorization at the permission layer. Combining it with a paymaster or relayer gives you a fully gasless user experience for cross-chain flows.