USD
Ethereum EIP-8141 Could Let Users Pay Gas Without Holding ETH
Frame Transactions would separate validation, fee payment and execution while keeping ETH as Ethereum’s settlement asset
TL;DR
- EIP-8141 would let supported wallets separate transaction authorization from gas payment, allowing sponsors to cover ETH fees while users pay in ERC-20 tokens.
- Frame Transactions could give existing wallets sponsored gas, batched actions, key rotation and alternative signature systems without requiring migration to a smart account.
- The proposal remains a draft, and its deployment status is conflicting: the Hegotá Meta EIP lists it for inclusion, while it is also described as unscheduled for a network upgrade.
Trade smarter on Jupiter, Solana’s leading DEX built for fast execution and deep liquidity.
Swap tokens at competitive rates, route across multiple liquidity sources automatically, and access perpetuals, DCA, and advanced trading tools — all in one place!
Ethereum’s proposed EIP-8141, known as Frame Transactions, would create a new transaction structure that could let users transact without personally holding ETH for gas, provided their wallet, application and a sponsor support the format. The proposal would separate validation, gas-payment authorization and execution into programmable steps, while Ethereum block space would still ultimately be paid for in ETH.
EIP-8141 would replace the fixed structure of an Ethereum transaction with a sequence of up to 64 “frames,” each operating as an ordinary contract call. One frame could validate a transaction, another could determine who pays the gas, and the remaining frames could execute the transfer, swap, mint or other action the user intended.
Separating transaction approval from fee payment would break the direct link between the account signing a transaction and the account funding it. A wallet containing stablecoins but no ETH could therefore pay its fee in an ERC-20 token, while a sponsor provides the ETH required by the Ethereum network. An application could also choose to sponsor the transaction outright.
That structure would not remove ETH from Ethereum’s fee system. Frame Transactions would change who acquires, provides and manages the ETH used for settlement rather than changing the underlying fee market. A user could see a fee quoted in USDC or see no direct fee at all, but the account settling the network charge would still need ETH.
How ERC-20 gas payments could work
The EIP includes an example in which a sponsor pays the network fee and receives an ERC-20 payment from the user. A wallet holding USDC but no ETH could first validate the complete set of intended actions, then reach a payment arrangement under which a sponsor covers ETH gas in exchange for an ERC-20 payment or subsidizes the cost.
The token payment and the intended transfer, mint or swap could then be processed through the same transaction flow. Packaging those steps together would allow a user to initiate the intended operation without first acquiring ETH solely to pay gas.
The proposal does not make transactions free. Instead, it would allow wallets and applications to decide how the cost is presented and funded. An application could pay the fee itself, a sponsor could quote the user a fee in USDC or another supported token, or an application could subsidize selected actions while charging token-denominated fees for others.
A transaction presented as gasless would therefore still be funded by an application, sponsor or separate token charge. EIP-8141 would provide a standardized transaction structure through which that cost could be subsidized or recovered using an asset already held by the user.
Ethereum already supports related account-abstraction functionality. Since 2023, ERC-4337 has allowed sponsored fees and similar features by routing transactions through a separate mempool and relying on third-party bundlers. Frame Transactions would instead operate through Ethereum’s public mempool, with protocol rules allowing nodes to evaluate a transaction’s validation process before accepting it.
Pectra’s EIP-7702 also gave externally owned accounts access to smart-account features including transaction batching, sponsorship and improved recovery options. EIP-8141 would go further by defining a dedicated transaction format in which validation and payment rules can be included natively.
Ordinary externally owned accounts would also be covered. The specification defines “default code” intended to give wallets without deployed contracts access to sponsored transactions, token-paid gas and batched calls without requiring users to migrate their assets into a smart account.
Frame Transactions would also allow several actions to be grouped so they succeed or fail together. That structure could prevent token approvals from remaining active after a later swap fails, because the approval and swap could be handled as part of the same atomic transaction flow.
Frames also target key management and quantum resistance
Gas abstraction is only one part of EIP-8141. The programmable transaction structure is also intended to support key rotation, spending limits, social recovery and alternative signature systems.
Frames would unlink Ethereum accounts from the specific ECDSA keys controlling them, making key rotation possible without tying an account permanently to the original authentication key.
The proposal’s authors also position that flexibility as preparation for quantum-resistant authentication. They describe Frames as a “native off-ramp” from the elliptic-curve cryptography Ethereum currently uses.
Matt Garnett, co-author of the proposal who writes as lightclient, said post-quantum signatures can run to several kilobytes each, creating pressure for signature aggregation as Ethereum considers alternative authentication systems. Garnett wrote that Frames “should be the last transaction type we need for accounts.”
Vitalik Buterin also highlighted the proposal’s progress. On September 5, 2026, Buterin wrote: “A lot of important progress on Frames (EIP-8141) has been quietly happening over the last few months. Highly recommend reading this, also the updated EIP.”
Buterin also pointed to a testnet operated by the ethrex client that pairs Frames with FOCIL, a censorship-resistance mechanism, to allow privacy protocols to operate without relayers.
EIP-8141 has been a draft since January 2026. The Hegotá Meta EIP lists Frame Transactions as scheduled for inclusion, and Hegotá has not yet activated. The proposal is also described as not scheduled for any network upgrade, creating a direct conflict over its deployment status that remains unresolved in the supplied information.
Security rules focus on complete transaction authorization
The draft warns that custom validation code must bind a user’s approval to the complete set of frames being authorized. Without that protection, an approval could potentially be reused with a different set of subsequent actions.
Wallets would therefore need to show users what a signature permits, whether an application is paying the fee and which token will be charged when validation, payment and execution are combined in a single transaction.
Sponsors also face execution risk. Under the ERC-20 payment example, a user could reduce the token balance intended to reimburse a sponsor before the transaction reaches a block. The proposal includes paymaster-solvency and public-mempool rules designed to protect sponsors that fund gas across multiple users.
Adoption would still depend on wallet and application implementation. Compatible products would need to provide pricing, refund logic and transaction previews before Frame Transactions materially change the everyday wallet experience.
The proposal also does not automatically create additional ETH demand. ETH would remain necessary for network settlement, but users could increasingly have that requirement managed by wallets, applications and sponsors. Any longer-term effect would depend on whether simpler wallet flows attract more users and whether applications choose to cover or process gas costs through the new structure.
This article has been refined and enhanced by ChatGPT.
