Technical
Gas Abstraction for Stablecoin Products: A Guide for Wallets, Exchanges, and Fintechs
The onboarding showstopper: users hold USDC but lack ETH for gas. Guide for wallets, exchanges, and fintechs on gas abstraction, EIP-4337 vs EIP-7702, and an 8-point provider checklist.
By The 1Shot API Team
The onboarding showstopper
A user can hold the exact asset your product needs and still be unable to use it.
A customer might have $100 USDC in their wallet but no ETH. They want to send $20 USDC, make a payment, or deposit funds into an application. Yet the transaction can fail because they don't have the network's native token to pay for gas.
For a mainstream financial product, that requirement creates a broken workflow, not a minor inconvenience.
Gas abstraction solves this problem by separating the asset a user wants to transact with from the asset used to pay for blockchain execution.
Before looking at how it works, it helps to understand what gas actually is.
What is gas?
Blockchains charge for the computational work required to process transactions. On Ethereum and other EVM-compatible networks, this computational work is measured in units called gas.
A transaction consumes a certain amount of gas depending on the operations it performs. The user then pays a fee based on the amount of gas consumed and the network's current gas price.
On Ethereum, that fee is paid in ETH. Other networks use their own native tokens.
This creates an awkward separation between the asset a user wants to transact with and the asset required to execute the transaction.
A user might think: “I have $100 USDC. Why can't I send $20?”
The blockchain effectively answers: “You don't have any ETH to pay for the transaction.”
For a crypto-native user, this is an expected part of using a blockchain. For someone using a wallet, exchange, or fintech application, it can feel like a product failure.
The user doesn't care which token the blockchain uses to pay for computation. They care about completing the action they initiated.
That's where gas abstraction comes in.
What is gas abstraction?
Gas abstraction lifecycle
- Step 1
Hold
User holds USDC without native gas tokens.
- Step 2
Initiate
User starts send, pay, or deposit in your application.
- Step 3
Confirm
User approves with the fee shown in USDC—or none if sponsored.
- Step 4
Execute
Infrastructure pays native gas and submits the transaction.
From the user's perspective, those four stages often collapse into three taps — send, confirm, done.
Gas abstraction allows an application to hide or change the traditional gas-payment requirement from the user.
Instead of requiring a user to hold the network's native token, an application can:
- sponsor the transaction and pay the gas itself;
- recover the gas cost from the user in a stablecoin such as USDC;
- allow the user to pay an execution fee in the asset they are already using; or
- incorporate the cost of blockchain execution into the application's existing pricing.
The blockchain still consumes gas. Someone still has to pay for that computation.
In a stablecoin fee flow, a relayer infrastructure provider fronts the native gas, relays the transaction to the blockchain, and recovers the cost from the user in USDC or another agreed token.
“Gasless” therefore doesn't mean that gas doesn't exist. It means the user doesn't have to manage the native gas token directly.
For stablecoin products, this distinction is particularly important. If USDC is the primary asset in your application, requiring users to acquire ETH, MATIC, BNB, or another native token just to move USDC introduces unnecessary friction.
Gas abstraction is part of account abstraction
Gas abstraction is not an isolated blockchain feature. It is one of the capabilities enabled by the broader concept of account abstraction.
Traditional Ethereum accounts, known as externally owned accounts (EOAs), have a relatively rigid transaction model. The account signs a transaction, the transaction specifies a gas payment, and the network processes it.
Account abstraction makes accounts more programmable.
Depending on the implementation, account abstraction can enable:
- Gas abstraction: users don't need to hold the native gas token.
- Gas sponsorship: an application or third party pays transaction costs.
- Token-based gas payments: users pay execution costs in assets such as USDC.
- Transaction batching: multiple operations can be combined into a single user interaction.
- Programmable permissions: applications can be granted limited authority to act on behalf of an account.
- Custom authentication: applications can use authentication mechanisms beyond traditional private-key signatures.
For a product team, the important point is that gas abstraction is a user-facing capability made possible by changes to the underlying account and transaction architecture.
That architectural distinction matters when evaluating vendors.
EIP-4337 vs. EIP-7702
The Ethereum ecosystem has taken several approaches to account abstraction. Two of the most important are EIP-4337 and EIP-7702.
EIP-4337 introduced a new transaction flow built around concepts such as UserOperations, bundlers, an EntryPoint contract, and paymasters. It enabled sophisticated account abstraction without requiring a change to Ethereum's core transaction protocol.
EIP-4337 has seen significant adoption and remains an important account-abstraction standard.
EIP-7702 takes a different approach. It allows an existing EOA to authorize code to operate on its behalf, giving the account smart-account capabilities while retaining its existing address and assets.
For product teams, the question isn't which standard “won.” The more useful question is: which account-abstraction architecture gives our product the capabilities we need with an acceptable level of complexity, cost, and infrastructure dependency?
For applications that primarily need capabilities such as gas sponsorship or stablecoin-denominated transaction fees, an EIP-7702-based architecture can work with EIP-4337 or it can provide an alternative to building around the full EIP-4337 paymaster and bundler stack.
Coupling EIP-7702 with newer standards like ERC-7710 also makes more sophisticated delegation and permissioning models possible. This can be particularly useful for wallets, automated applications, and agentic products that need to authorize transactions without giving an application unrestricted control of an account. See session keys for embedded wallets for how ERC-7710 and ERC-7715 fit into that picture.
The implementation details matter because they affect what your engineering and operations teams ultimately have to maintain.
The hidden complexity behind gas abstraction
What the user sees
Send
100 USDC
Confirm
Approve once
Done
Onchain
That surface flow hides a much heavier backend. Behind those three taps, the application may need to deal with:
- native-token balances;
- gas-price volatility;
- RPC infrastructure;
- transaction submission;
- nonce management;
- failed transactions;
- chain-specific behavior;
- paymaster deposits;
- relayer balances;
- API credentials;
- provider account limits; and
- transaction monitoring and reconciliation.
This leads to an important question when evaluating a gas abstraction provider:
Does the provider eliminate complexity, or merely move it from the user to your engineering and operations teams?
A solution that makes the user's experience easier but requires your company to maintain native-token balances across ten chains may not actually simplify your product.
Likewise, a provider that requires a prefunded paymaster, API account, or proprietary wallet architecture may introduce operational dependencies that aren't obvious from the user interface.
What to look for in a gas abstraction provider
The right gas abstraction infrastructure depends on your product, but there are several questions every team should ask before selecting a vendor.
1. Which account standards does it support?
Ask whether the provider supports the account architecture you already use, rather than assuming you will be able to adopt it later.
Important standards to consider include EIP-4337, EIP-7702, ERC-7710, ERC-7715, traditional EOAs, and smart contract accounts.
More importantly, ask whether adopting the provider requires you to change your wallet architecture.
2. Who actually pays the gas?
“Gasless” is not an economic model.
Determine whether your application sponsors the gas; the user pays in USDC or another token; the provider advances the gas and charges a fee; the gas cost is incorporated into your existing transaction fee; or some combination of these models is used.
This has a direct impact on your unit economics.
3. Does the infrastructure require prefunding?
Some architectures require an application to maintain a balance of native tokens or stablecoins before transactions can be processed.
That creates an operational requirement: you need to make sure the gas infrastructure itself never runs out of gas.
For products operating across multiple chains, this can become a treasury and operations problem.
Ask: do we need to pre-fund a paymaster or relayer? And: who is responsible for keeping that balance funded?
4. Does the provider require an account or API key?
Managed infrastructure often requires an application account and API credentials.
That's not necessarily a problem, but it creates another dependency to evaluate.
Consider what happens if the account is suspended, whether there are transaction limits or rate limits, whether approval is required before going into production, what happens if the provider's API is unavailable, and whether the infrastructure can be accessed without a proprietary SDK.
A permissionless architecture can eliminate some of these operational dependencies.
5. Can users pay fees in stablecoins?
If your application is stablecoin-first, this should be an explicit requirement rather than an afterthought.
A user who holds USDC should ideally be able to use USDC without first acquiring a separate native gas token.
Ask which tokens can be used for gas payments and whether the provider supports the specific assets and networks your product needs.
6. What does the provider charge?
Don't only compare the headline gas fee.
Look for per-transaction fees, gas premiums, per-user fees, per-signature fees, API fees, minimum monthly commitments, paymaster fees, infrastructure fees, and required account or platform tiers.
A provider that appears inexpensive at low volume can have a very different cost profile at millions of transactions.
7. What happens when the provider is unavailable?
Gas abstraction infrastructure sits directly in the transaction path.
That makes availability an architectural consideration, not simply a vendor-management issue.
Ask whether your application can fall back to another relayer, submit transactions directly, detect provider failures, independently monitor transactions, and recover from partially completed operations.
The more critical the transaction is to your product, the more important this becomes.
8. Does it work with self-custodial accounts?
For wallets and fintech applications, custody architecture matters.
A gas abstraction solution should not require you to give a third party control over user assets simply to abstract gas payments.
If your product is self-custodial, confirm that the gas infrastructure preserves that property.
What good gas abstraction looks like
From the user's perspective, a good implementation should be almost invisible.
The user should be able to:
- hold the asset they want to use;
- initiate the desired action;
- see the cost clearly;
- approve the transaction; and
- have the transaction execute without separately acquiring a native gas token.
The underlying infrastructure can be sophisticated. The user experience shouldn't be.
For product teams, the bar is the eight questions above: support the assets users already hold, disclose execution costs, preserve self-custody, and avoid shifting blockchain complexity into your treasury and operations stack.
Gas abstraction should be infrastructure, not a user feature
The goal of gas abstraction isn't to make users understand account abstraction, relayers, paymasters, bundlers, or transaction fee markets. In fact, ideally you wouldn't want your customers to even know these things exist.
Users don't need to know which RPC endpoint submitted their transaction or which token the blockchain used to compensate validators. They need to know what they're doing, what it costs, and that it worked.
For product teams, the challenge is choosing infrastructure that delivers that experience without simply transferring blockchain complexity into their own engineering and operations teams.
For stablecoin products in particular, this matters because a wallet containing USDC isn't necessarily a usable wallet if the user can't pay the gas required to move it. See stablecoin onboarding conversion for how gas fits into the broader funding-to-transaction funnel.
Gas abstraction closes that gap.
The 1Shot approach
Evaluating providers against the checklist above, teams typically choose between embedding gas abstraction in the wallet layer or adding relay infrastructure to an existing stack.
1Shot provides two approaches for teams that want to remove native-token gas requirements from their products.
1Shot Wallet is an embedded, non-custodial wallet with gas abstraction built into the wallet experience.
1Shot Gas Relayer is standalone relaying infrastructure designed around EIP-7702 and ERC-7710, allowing teams to add gas abstraction without adopting a full EIP-4337 paymaster infrastructure.
The relayer is permissionless and supports sponsored transactions and stablecoin-denominated fees without requiring an API key, business account, or prefunded relayer balance. See the gas abstraction quickstart (EIP-7710) to integrate it directly.
For supported flows, 1Shot reports gas savings of up to 50% compared with EIP-4337-based implementations. Actual costs depend on the transaction, account architecture, and network conditions, so teams should benchmark their own workloads before making an architectural decision.
Production-scale gas abstraction in the wild: OKX Wallet Gas Station case study.
The best gas abstraction solution is ultimately the one that makes blockchain infrastructure disappear for the user without making it more complicated for the product team.
Frequently Asked Questions
- Which account standards does a gas abstraction provider support?
- Confirm the provider supports your existing account architecture — EIP-4337, EIP-7702, ERC-7710, ERC-7715, EOAs, or smart contract accounts — and whether adoption requires changing your wallet stack. See the provider checklist above for detail.
- Who actually pays the gas?
- "Gasless" is not an economic model. Clarify whether your app sponsors gas, the user pays in USDC, the provider advances gas and charges a fee, or costs are bundled into your pricing — each choice affects unit economics.
- Does gas abstraction infrastructure require prefunding?
- Some architectures require pre-funded paymaster or relayer balances before transactions can run. Ask who maintains those balances across chains — see the provider checklist above.
- Does a gas abstraction provider require an account or API key?
- Managed infrastructure often requires application accounts, API keys, and production approval. A permissionless relayer can reduce those dependencies — see the provider checklist above.
- Can users pay gas fees in stablecoins?
- If your product is stablecoin-first, this should be explicit. Confirm which tokens and networks the provider supports for fee payment so users are not forced to acquire native gas tokens first.
- What does a gas abstraction provider charge?
- Compare more than headline gas fees — include per-transaction premiums, API fees, paymaster costs, and tier minimums. Low-volume pricing can look very different at scale.
- What happens when the gas abstraction provider is unavailable?
- Gas infrastructure sits in the transaction path, so plan for fallbacks: alternate relayers, direct submission, failure detection, and recovery from partial operations.
- Does gas abstraction work with self-custodial accounts?
- Gas abstraction should not require giving a third party control over user assets. If your product is self-custodial, confirm the relay infrastructure preserves that property.
Add gas abstraction to your product
1Shot Wallet embeds self-custodial accounts with gas abstraction built in. The Gas Relayer adds permissionless EIP-7702 / ERC-7710 relay infrastructure to your existing wallet stack.