Skip to main content

Gas Abstraction for AI Agents

Gas abstraction lets AI agents pay in stablecoins without holding ETH or SOL. EIP-4337, EIP-7702, paymaster patterns, and the cross-chain orchestration angle.

Written by Eco

Gas abstraction is the set of patterns that let an AI agent submit onchain transactions without holding the chain's native gas token. The agent signs a stablecoin payment; a paymaster contract or a delegated EOA picks up the gas tab. The mechanism matters because gas is the second-most-cited friction (after key custody) in autonomous agent payments — an agent that holds USDC on Base still cannot move it without ETH on Base, and a Solana agent cannot transact without SOL. Two Ethereum upgrades reshape the answer. EIP-4337 deployed its EntryPoint contract on March 1, 2023, formalizing the paymaster role. EIP-7702 activated on May 7, 2025 as part of the Pectra hard fork, letting any externally owned account temporarily delegate to smart-contract code. Production paymaster infrastructure now spans Coinbase CDP Paymaster, Circle Paymaster, Pimlico, Biconomy, Stackup, ZeroDev, and Crossmint. This guide walks the mechanism, the three sponsor patterns, the major implementations, and the cross-chain headache that orchestration layers like Eco resolve.

What Is Gas Abstraction for AI Agents?

Gas abstraction is the architecture that lets an AI agent execute a stablecoin transfer or smart-contract call without owning the destination chain's native gas token. A paymaster contract pays the gas in the native token; the agent reimburses in a stablecoin or the application sponsors the cost outright. The agent's signed payload becomes the only artifact it has to produce.

Every blockchain charges gas in its own native asset. Ethereum charges in ETH; Base, Optimism, and Arbitrum inherit that requirement; Solana charges in SOL; Tron charges in TRX (or burned bandwidth and energy); Polygon charges in POL. An agent receiving USDC payments and sending USDC payments has to acquire and rebalance one or more of those native assets just to keep transacting. Without abstraction, every chain the agent touches becomes a separate native-token-management problem.

The numbers explain the urgency. Stablecoin supply totals roughly $318 billion as of late April 2026, dominated by USDT at $189.5 billion and USDC at $77.3 billion (per DeFiLlama). That supply spans more than fifteen chains. ETH trades around $2,256 and SOL around $83 (per CoinGecko, April 29, 2026); even a $0.01 micropayment in USDC requires the agent to pre-fund an ETH or SOL balance somewhere. Gas abstraction collapses the funding model: the agent holds the unit of account it earns and spends, and lets a paymaster bridge to the unit the chain charges in.

For autonomous agents, the abstraction is not a nicety. The agent wallets explainer describes how the spending surface is shaped by what the wallet can sign without intervention. A gas-token dependency adds a second balance the wallet has to maintain, which adds a second failure mode (running out of native), a second pricing surface (ETH/SOL volatility), and a second key-custody question (where to top up from). Removing the dependency is what makes a closed-loop USDC-only or USDT-only agent operationally feasible.

Why does gas break AI agent payments?

Gas breaks agent payments because the asset the agent earns (a stablecoin) is not the asset the chain charges in (ETH, SOL, TRX, POL). The agent has to source native tokens on every chain it touches, refill them, and absorb the volatility. Each step is a place an autonomous flow can stall.

Three concrete failure modes show up in production. First, balance starvation: an agent with $500 of USDC on Base but zero ETH cannot move the USDC at all. The transaction reverts at the mempool level. Second, refill latency: when a treasury process tops the agent up with ETH, the swap from USDC to ETH adds a route, a slippage budget, and a settlement window. Third, multi-chain compounding: an agent transacting on Base, Solana, and Tron simultaneously needs three native balances tracked separately. If any one runs dry, that leg of the agent's workflow fails silently while the others continue.

The friction also distorts agent design. Without abstraction, agent operators end up writing custom top-up logic for each chain, which is a non-trivial piece of code to maintain across protocol upgrades. Coinbase's x402 protocol docs explicitly call out gas-token availability as one of the reasons servers integrate paymaster support directly, rather than expecting the agent to bring native balance. April 2026 reporting on x402 deployments (per Cryptonews) tracked roughly 69,000 active agents and 165 million transactions cumulatively; a meaningful share of those flows ride paymasters that hide gas entirely from the agent code path.

The research community treats gas abstraction as a precondition for the broader agent-payment thesis. Circle's analysis of EIP-7702 argues that removing native-token requirements is what makes "AI agents that operate across chains with only USDC" practical. Without abstraction, agents are tied to a hot-balance refill loop that itself becomes a security perimeter, a treasury workflow, and a billing line item.

How Does Gas Abstraction Work?

Gas abstraction works by inserting a paymaster contract or a delegated executor between the agent's signed payload and the chain's gas accounting. The paymaster pays the gas in native tokens; the agent supplies a signature, a stablecoin allowance, or both. EIP-4337 defines the paymaster role; EIP-7702 lets EOAs delegate temporarily; EIP-3009 supplies gasless approvals.

The mechanism has three moving parts: a transaction format that lets a third party validate and sponsor the call, a contract role that pays the gas, and a signature primitive that lets the user authorize the spend without a separate onchain approval. Each of the major Ethereum standards covers one of those three.

EIP-4337 (UserOperation and Paymaster). EIP-4337 introduced the UserOperation as the unit of transaction submission for smart-contract accounts. A bundler aggregates UserOperations into a single Ethereum transaction, calling the EntryPoint contract that was deployed on March 1, 2023 (per the CoinDesk launch coverage). EntryPoint's standard interface includes optional Paymaster validation: if the UserOperation specifies a paymaster, EntryPoint calls the paymaster's validatePaymasterUserOp function, which decides whether to sponsor and how the paymaster will be repaid. The EntryPoint then pays gas to the bundler from the paymaster's deposit.

EIP-7702 (Set-Code Transaction). EIP-7702 adds a new transaction type (SET_CODE_TX_TYPE 0x04) that lets an externally owned account authorize a delegation: the EOA's runtime code is set to a 23-byte indicator (0xef0100 plus a 20-byte target address), which causes calls to that EOA to execute the target's code in the EOA's storage context. The mechanism activated on Ethereum mainnet at epoch 364032 on May 7, 2025 as part of the Pectra hard fork (per Alchemy's Pectra writeup). For gas abstraction specifically, an EOA can delegate to a contract that supports paymaster-style sponsorship without first migrating to a 4337 smart account.

EIP-3009 and Permit2 (gasless approvals). A paymaster pays the gas, but the agent still has to authorize the stablecoin transfer. EIP-3009 defines transferWithAuthorization, an off-chain signature that approves a single transfer to a specific recipient for a specific amount within a time window. USDC implements EIP-3009 natively. Permit2, shipped by Uniswap in November 2022, generalizes the pattern across any ERC-20 token by routing through a single audited approval contract. Together they let an agent sign once off-chain and let the paymaster (or a relayer) submit the transfer onchain.

USDC-paid gas. Native USDC paymasters take this one step further by accepting USDC as the unit of repayment. Circle Paymaster is permissionless, charges 10 percent of the gas cost in USDC, and is live on Base and Arbitrum (per Circle's launch announcement). Coinbase CDP Paymaster supports ERC-20 gas payments on Base, with USDC as the launch token (per CDP launch notes). The agent never has to acquire ETH; the paymaster sweeps USDC at execution time.

Composed together, these primitives let an agent sign a UserOperation (or, post-Pectra, a 7702-delegated call) that references a paymaster, the paymaster validates and sponsors the gas, and the agent's only balance requirement is the stablecoin it was already going to spend. The same flow extends to Solana through native fee-payer mechanics and to Tron through energy delegation, with chain-specific implementations that the next section covers.

Three Sponsor Patterns for Agent Gas

Three sponsor patterns have hardened into convention. Third-party sponsor (an infrastructure provider like CDP or Circle pays the gas and bills the agent operator); application sponsor (the destination service or merchant absorbs gas); user-funded with token-paid gas (the agent pays gas in USDC or another ERC-20 via paymaster). Most production deployments mix at least two.

The choice is mostly an economic question, not a technical one. All three patterns use the same EIP-4337 paymaster surface or its 7702 equivalent. What changes is who carries the gas P&L and how repayment closes.

Third-Party Sponsor

An infrastructure platform contracts to pay gas on behalf of all agents using its SDK or API, then bills back monthly. Coinbase CDP Paymaster runs this model: developers apply for up to $15K in gas credits as part of the Base Gasless Campaign, after which CDP sponsors the gas and invoices the developer for the sponsored gas plus a 7 percent fee (per the CDP paymaster docs). Pimlico, Biconomy, Stackup, ZeroDev, and Crossmint run variations of the same pattern with different markup and credit structures. The model fits agent platforms that want a single gas line item across many user agents.

The economic appeal is forecasting. Gas is volatile in absolute terms; a single ETH-price spike can multiply gas costs four-fold over a quarter. A third-party sponsor smooths that volatility into a fixed-margin invoice. The trade-off is dependency: every transaction the agent submits routes through the sponsor's infrastructure, which becomes a chokepoint if the sponsor experiences downtime or rate-limits.

Application Sponsor

The destination service or merchant absorbs gas as part of the cost of accepting the payment. Circle's Gas Station implements this for Programmable Wallets: developers configure sponsorship rules, and the destination application pays the gas without surfacing it to the user. Application sponsorship is also the default model for x402 facilitators when the server runs the facilitator inline — the agent's HTTP 402 retry pays only the protocol fee, while the facilitator absorbs gas and recovers it from its own margin.

The pattern works when gas is small relative to the transaction value. A merchant accepting a $50 stablecoin payment on Base can absorb $0.005 of gas without changing the unit economics. The pattern breaks when gas approaches the transaction value, which is why x402-style sub-cent micropayments rely on stablecoin-paid gas (next pattern) instead.

User-Funded with Token-Paid Gas

The user (or the agent on the user's behalf) pays gas, but in a stablecoin rather than the native asset. Circle Paymaster implements this on Base and Arbitrum at a 10 percent markup over the equivalent ETH cost, charged in USDC at execution (per the Circle Paymaster docs). Coinbase CDP Paymaster supports the same flow for Base smart wallets. Pimlico's ERC-20 paymaster, Biconomy's USDC paymaster, and Stackup's verifying paymaster all sit in the same conceptual slot.

For autonomous agents, this is the cleanest pattern when the agent operator wants neither to maintain a sponsorship balance nor to depend on a third-party sponsor's billing. The agent holds USDC, signs a UserOperation referencing a USDC paymaster, and the paymaster sweeps the appropriate USDC amount at execution. No ETH ever enters the agent's balance sheet. The trade-off is the markup — a 7 to 10 percent surcharge on gas that compounds across high-frequency workloads.

Production Implementations: Coinbase, Circle, Crossmint, Biconomy, Stackup, ZeroDev

Six paymaster providers cover the working production tier in April 2026: Coinbase CDP, Circle Paymaster, Crossmint, Biconomy, Stackup, and ZeroDev. Each is live, each supports an EIP-4337 paymaster (several also support EIP-7702), and each ships an SDK. The choice depends on chain coverage, sponsorship model, and which wallet system the platform already runs.

The table below summarizes the working differences. Pimlico is included as a major bundler-and-paymaster operator alongside the six.

Provider

Chains

Sponsor models

Token-paid gas

EIP-7702 support

Pricing

Coinbase CDP

Base mainnet, Base Sepolia

Third-party sponsor, ERC-20 paid gas

USDC, custom ERC-20 (early access)

Yes (Base Accounts)

Sponsored gas + 7% fee, monthly invoice

Circle Paymaster

Base, Arbitrum

User-funded token-paid gas (Paymaster); App sponsor (Gas Station)

USDC native

Compatible with 7702-delegated EOAs

10% USDC markup over ETH gas equivalent

Crossmint

20+ EVM chains plus Solana, Stellar, Aptos, Sui (50+ total)

Third-party sponsor, App sponsor

Yes via integrations

Yes

Toggle in console; monthly fiat invoice

Biconomy

EVM mainnet + 15+ L2s

Third-party sponsor, ERC-20 paid gas

USDC and partner tokens

Yes (Nexus account)

Tiered, with unified gas tank cross-chain

Stackup

EVM L1 and major L2s

Third-party sponsor, ERC-20 paid gas

Yes

Yes

Per-userop bundling and paymaster fees

ZeroDev

EVM mainnet + 12+ L2s

Third-party sponsor, ERC-20 paid gas

Yes

Yes (Kernel v3)

Tiered SaaS with sponsored-gas allotments

Pimlico

EVM mainnet + 20+ L2s

Third-party sponsor, ERC-20 paid gas

Yes

Yes

Bundler + paymaster usage-based

The split below the table is mostly about chain footprint and developer ergonomics.

Coinbase CDP Paymaster ships as a managed service inside the Coinbase Developer Platform with the smallest possible setup surface for Base-only workloads. The paymaster supports gas sponsorship for ERC-4337 smart accounts and, post-Pectra, for Base Accounts that use 7702 delegation. Developers configure sponsorship rules in the CDP Console, the SDK signs UserOperations against the paymaster, and CDP bills the developer for sponsored gas plus 7 percent (per the CDP product page). The Base Gasless Campaign offered up to $15K in gas credits to onboard developers. The trade-off is single-chain scope: CDP Paymaster is Base-only.

Circle Paymaster is the canonical USDC-paid-gas implementation. It runs permissionlessly on Base and Arbitrum, accepts any ERC-4337 smart contract account, charges a 10 percent USDC markup, and requires no Circle Console account. Circle's launch announcement framed it as the route to "AI agents that operate across chains with only USDC." Circle Paymaster pairs with Circle's Gateway and Gas Station for cross-chain USDC flows where gas is paid out of the same balance the agent transacts in.

Crossmint packages smart wallets with built-in gas sponsorship across 20+ EVM chains plus Solana, Stellar, Aptos, and Sui (50+ total chains across networks), with a toggle in the Crossmint Console (Wallets → Settings) to enable or disable sponsorship per project. The platform abstracts bundlers, paymasters, RPCs, and signers behind a React SDK that ships a non-custodial smart account in roughly five minutes (per the Crossmint gas-sponsorship docs). The model fits consumer agent surfaces that want a managed wallet plus gas in one integration.

Biconomy sits at the modular smart-account end of the market, with a unified gas tank that spans multiple chains. Its Nexus account abstracts the sponsor balance so an agent platform can fund one gas pool that covers Ethereum, Arbitrum, Base, Optimism, Polygon, and other L2s simultaneously. For agent workloads that span chains, this matters: instead of pre-funding a sponsor balance on each L2, the platform funds Biconomy and lets the SDK pull from one tank.

Stackup and ZeroDev are the two infrastructure-first providers most often picked by teams that want a thin, opinionated paymaster layer on top of their own auth stack. Stackup's Userop.js library is the reference TypeScript userop builder; Stackup runs production bundlers and a verifying paymaster. ZeroDev ships the Kernel modular smart account (now at v3 with 7702 delegation), a paymaster suite, and bundler infrastructure aligned with the Arbitrum/Offchain Labs ecosystem. Both are usage-billed.

Pimlico rounds out the bundler-and-paymaster tier. Pimlico relays smart account transactions through ERC-4337 bundlers, manages mempool and nonce semantics, and exposes a paymaster API that supports sponsorship and ERC-20 gas. Pimlico is one of several major ERC-4337 bundler-and-paymaster operators (alongside Stackup, Alchemy, and Biconomy) in production.

Cross-Chain Gas Challenges and the Orchestration Layer

Cross-chain agent payments multiply the gas problem. An agent on Base spending USDC to a Solana counterparty needs SOL on Solana to land the destination, even when the source chain has its own paymaster. Each chain has its own native asset, paymaster surface, and bundler. Orchestration layers fold the gas decision into the same routing surface that picks the bridge.

The problem is structural. EIP-4337, EIP-7702, Circle Paymaster, and CDP Paymaster all live on a specific chain. They do not coordinate cross-chain. An agent that signs a USDC payment on Base via Circle Paymaster pays $0.011 in USDC for the source-chain gas, but the Solana destination still requires SOL paid by something. Native USDC mint via Circle CCTP V2 with Hooks shifts the destination logic into the mint callback, but the chain still charges Solana fees in lamports. The orchestration layer is what decides which paymaster (or fee-payer) carries each leg.

Three cross-chain gas patterns are emerging in production. Pattern A: paymaster per chain, orchestrator picks. The orchestrator maintains paymaster relationships on every supported chain and routes the user-operation to whichever paymaster matches the destination. Pattern B: solver-front-paid. An intent solver pre-funds destination gas as part of its inventory cost; the agent pays a single fee that wraps source gas, destination gas, and the solver's spread. Pattern C: gateway with embedded fee-payer. Circle Gateway and similar deposit-and-forward services hold a single USDC pool that auto-funds gas on whichever chain the user moves to. Circle's Gateway integration uses this model for gas-free cross-chain USDC transfers.

For agent workloads specifically, this is where stablecoin orchestration networks earn their keep. The cross-chain agent payments piece walks the four settlement patterns (bridge-then-pay, native burn-and-mint, atomic intent-based, multi-chain orchestration). Gas abstraction is a sublayer of pattern four: the orchestrator selects the rail and also selects the gas source, so the agent's signed intent never references a native token. Stablecoin distribution makes the case quantitatively. Stablecoin TVL spans Ethereum at $45.0 billion, BSC at $5.5 billion, Solana at $5.4 billion, Tron at $5.0 billion, Base at $4.3 billion, Arbitrum at $1.7 billion, and Polygon at $1.3 billion as of April 29, 2026 (per DeFiLlama). An agent that touches more than one of those chains is doing cross-chain gas work whether it knows it or not.

The orchestration angle is also the place where Permit2 and EIP-3009 stop being enough. Single-chain gasless approval gets the agent a sponsored source-chain transfer, but it does not coordinate the gas-token sourcing on the destination. Solver-based intents and gateway-based deposits both close that gap by treating destination gas as part of the orchestrator's inventory rather than as a separate concern the agent has to solve. The cleanest agent architectures collapse the entire flow to a single signed payload: pay X USDC, deliver Y USDC on chain Z, fees included.

Eco's Role in Agent Gas Abstraction

Eco operates a cross-chain stablecoin execution network across 15 chains. For gas abstraction, Eco folds the native-token decision into the routing layer that picks the bridge or solver. Agents sign a single intent; Eco resolves source-chain paymaster, destination-chain fee-payer, and solver pricing in one pass. Hyperlane carries messaging; Circle CCTP carries native USDC.

Native paymasters like Circle's, Coinbase's, and the smart-account SDKs handle gas abstraction on a single chain efficiently. Cross-chain agent payments — paying Solana from Base, paying Tron from Arbitrum, paying Polygon from Optimism — span chains with different paymaster ecosystems, different native-fee primitives, and different finality windows. Eco sits one layer above paymaster selection, deciding which combination of paymasters, solvers, and bridges fits the specific cross-chain payment, with stablecoin liquidity sourced through Hyperlane warp routes and Circle CCTP. The agent submits one intent — pay X USDC on Base, deliver Y USDC on Solana — and the routing layer resolves both source-chain gas (which paymaster to call, in what token) and destination-chain gas (which fee-payer settles the mint). For a deeper look at how the same orchestration layer handles cross-chain stablecoin movement, see the cross-chain agent payments walkthrough.

Sources and methodology. EIP-4337 spec from eips.ethereum.org; EIP-7702 spec and Pectra activation from eips.ethereum.org and Alchemy's Pectra writeup. Paymaster pricing and chain coverage verified against Coinbase CDP, Circle, Crossmint, Biconomy, Stackup, ZeroDev, and Pimlico documentation as of April 2026. Stablecoin supplies and chain TVL pulled from DeFiLlama on April 29, 2026. Figures refresh quarterly.

Related reading

Did this answer your question?