Gas Token Abstraction: Paying L2 Fees in Any Token

Gas token abstraction refers to mechanisms — most commonly built on account abstraction and "paymaster" contracts — that let users pay transaction fees on a blockchain in a token other than the network's native gas token, such as paying an L2 fee in USDC instead of ETH.

Historically, every blockchain has required fees to be paid in one specific native asset — ETH on Ethereum and most of its L2s, MATIC/POL on Polygon, and so on. This is a real usability barrier: a user who receives, say, USDC from a friend or an exchange withdrawal but holds zero ETH literally cannot make a single transaction, including the one needed to swap that USDC for ETH in the first place. Gas token abstraction removes this catch-22.

How it actually works: the paymaster model

The most common mechanism is a paymaster — a smart contract that agrees to cover a user's gas fee on their behalf, typically in exchange for the user paying an equivalent amount (plus a small premium) in a different token, directly to the paymaster. From the network's perspective, the transaction is still ultimately paid for in the native gas token — the paymaster is the one fronting it — but the user experience is that they paid in whatever token the paymaster accepted.

This requires an execution environment that supports account abstraction, meaning accounts can have programmable transaction validation logic rather than being restricted to simple externally-owned accounts that can only pay gas in the native token directly. Ethereum's ERC-4337 standard implements this at the smart-contract-wallet level without requiring a protocol-level change; Starknet has native account abstraction built into its core architecture, making the same capability more first-class rather than an add-on.

Where this shows up across L2 ecosystems

• Starknet supports fee payment in STRK and other tokens through its native account abstraction model, alongside ETH — see our piece on how L2 tokens work for how STRK fits into this.
• zkSync and other account-abstraction-native chains have built paymaster support directly into their protocol design, making stablecoin gas payment a standard, low-friction feature rather than a bolted-on workaround.
• ERC-4337-compatible wallets on Ethereum and various L2s let any supporting smart-contract wallet use third-party paymasters, independent of what the underlying chain natively requires.

Why this matters for real usability

For a new user, "you need ETH to do anything, including acquiring more ETH" is a genuinely confusing onboarding problem. Gas abstraction removes this specific friction point, and it's part of why more recent wallet designs increasingly build in paymaster support as a default feature rather than an advanced option.

It also matters for institutional or business use cases — a company running automated transactions might prefer to hold working capital in a stablecoin and pay fees from that balance directly, rather than managing a separate, volatile-priced gas token reserve purely for transaction costs.

Without gas abstraction	With gas abstraction (paymaster)
Must hold native gas token (e.g., ETH) for every tx	Can pay in stablecoins or other supported tokens
New users need an initial ETH transfer before doing anything	Can transact immediately with whatever token they received
Businesses must manage a separate gas-token reserve	Can pay fees directly from working-capital balances

The trade-offs and things to watch

Paymasters aren't magic — someone still has to actually pay the native gas token to the network; the paymaster is just intermediating that payment. This means:

• Exchange rate risk. The paymaster needs a way to price the non-native token against current gas costs, and a small premium or spread is typically built in to cover this.
• Paymaster reliability. If a specific paymaster service goes down or runs out of native-token reserves, the "pay in any token" feature stops working for that specific integration, even if the underlying chain itself is fine.
• Not universal by default. Just because a chain supports account abstraction doesn't mean every wallet or dApp has integrated paymaster support — check whether a specific wallet actually offers this before assuming it's available everywhere.

How this connects to broader L2 fee trends

Gas abstraction is a user-experience layer sitting on top of whatever the underlying fee actually costs — it doesn't reduce the real cost of a transaction, it just changes what asset that cost is denominated in for the end user. The underlying fee itself is still shaped by the dynamics covered in our piece on how L2 fees have changed since EIP-4844 — abstraction doesn't replace the need to understand what's actually driving cost.

Bottom line

Gas token abstraction, powered by paymasters and account abstraction, solves a real and common onboarding problem — needing a specific native token just to make any transaction at all — by letting users pay fees in stablecoins or other assets instead. It's a genuine usability improvement, but it depends on a specific wallet or dApp actually integrating paymaster support, and it doesn't change the underlying gas cost itself, just who's fronting it and in what currency.