Ethereum Proposal Would Let Users Pay Gas Without Holding ETH and Reshape Transactions
Table of Contents
You might want to know
1) How could users pay transaction fees on Ethereum without holding ETH in their accounts?
2) What broader changes to transaction structure and account management does the Frames proposal introduce?
Main Topic
The Ethereum community is actively discussing a proposal — known as EIP-8141 or "Frames" — that would fundamentally change how transactions are represented and how transaction fees (gas) can be paid. Instead of the rigid single-structure transaction model that ties the signer of an operation directly to the account that funds it, Frames decomposes a transaction into a controlled sequence of discrete steps, each implemented as an ordinary contract call. This multi-step design separates validation, payment approval and execution, enabling new patterns such as paying fees in ERC-20 tokens or having third parties sponsor fees on behalf of users.
Under the current dominant transaction model, an externally owned account (EOA) signs a transaction and the same account must hold ETH to cover gas. Various workarounds have existed — notably ERC-4337 smart account abstractions and relay/bundler systems — but these solutions operate outside the core, protocol-level transaction shape or rely on separate mempool and bundler infrastructure. Frames aims to bring these capabilities into the protocol itself. By allowing a distinct "payment" frame to indicate who will fund the gas and how, the direct linkage between the signing account and the payer is broken. That in turn allows wallets that primarily hold stablecoins or other ERC-20 assets to cover fees in tokens, or permits applications to sponsor fees for their users without requiring bespoke relayer services.
Technically, a Frames transaction can include up to 64 frames. One frame can perform the validation logic (verifying signatures, authorizations, or conditions), another frame can approve the payment source or instruct how fees are to be paid, and the remaining frames carry out the desired on-chain operations. Each frame is an ordinary contract call, which means nodes can reason about transaction semantics within the public mempool without relying on off-chain bundlers. This integration into the public mempool is a crucial distinction: nodes can apply deterministic rules to accept or reject a framed transaction, improving interoperability and reducing reliance on separate brokered layers.
Frames also introduces the concept of "default code" for ordinary EOAs that lack deployed account contracts. This default code allows wallets that have not migrated to smart accounts to still benefit from sponsored transactions, token-paid fees and batched operations. In practice, that means existing wallets could obtain the new capabilities without forcing users through a migration path to a new account architecture, easing adoption and minimizing disruption. The result is broader, faster availability of advanced features such as token-denominated fees and sponsored payments.
Another important capability enabled by Frames is transaction atomicity across multiple actions: several frames can be combined so they either all succeed or all revert together. This grouping reduces the risk of leaving behind partial states such as dangling token approvals when an intermediate step fails. It also streamlines complex multi-step interactions — like swaps or batched operations — by ensuring consistent execution outcomes.
Frames further decouples account identities from the ECDSA keys that have historically controlled them. By treating verification and authorization as explicit frames, accounts can support key rotation more naturally and move away from hard-wiring a single elliptic-curve keypair to an account forever. This capability is relevant not only for operational key management but also for long-term cryptographic agility: as quantum computing advances, classical elliptic-curve signatures could become vulnerable. The Frames authors present the proposal as a "native off-ramp" from current ECC-based authentication to post-quantum schemes. Because post-quantum signatures are much larger, the proposal anticipates and encourages developments such as signature aggregation to keep transaction sizes and costs manageable.
Although some similar functionality has been available since 2023 via account abstraction proposals and systems like ERC-4337, those approaches typically require separate mempools and relayers (bundlers) that act outside the base transaction acceptance rules. Frames seeks to provide these features directly inside the protocol layer by defining how frames are represented and validated within Ethereum’s public mempool. This change could simplify developer experience and improve native client support because transaction semantics would be part of the protocol's accepted formats rather than an overlay.
The proposal has seen steady, quiet progress since it was drafted earlier in the year. Developers and researchers running experimental nodes and testnets — for instance, the ethrex client pairing Frames with censorship-resistance components like FOCIL — are exploring how privacy-preserving protocols and sponsored transactions can operate without dedicated relayers. These experiments demonstrate how Frames could create new primitives for applications that previously depended on third-party infrastructure.
Despite its potential, Frames remains a draft EIP and has not been scheduled for inclusion in any concrete network upgrade. The discussion is active, however, and contributors emphasize that Frames could be a long-term, final transaction type for accounts, addressing both practical UX issues (token fees, sponsorship, batched operations) and forward-looking cryptographic considerations (post-quantum readiness and key rotation). Adoption would require coordination across client implementations, node operators and the broader developer ecosystem, plus careful specification work to avoid unforeseen compatibility or security regressions.
In summary, EIP-8141 (Frames) proposes to transform Ethereum transactions from a fixed single-call shape into a structured sequence of up to 64 contract-call frames that explicitly handle validation, payment and execution steps. This architecture opens the door to paying gas in tokens, sponsored fees, batched atomic actions, and improved account-key management. By making these capabilities native to the protocol and part of the public mempool semantics, Frames aims to simplify adoption and enable a wider set of use cases while preparing the network for future cryptographic transitions. The proposal is still a draft, continues to be tested in experimental environments, and is not yet scheduled for a mainnet upgrade.
Key Insights Table
| Aspect | Description |
|---|---|
| Key Fact | Frames (EIP-8141) splits transactions into up to 64 frames for validation, payment and execution. |
| Payment Flexibility | Gas can be paid by a different account or in ERC-20 tokens, enabling sponsored or token-denominated fees. |
| Mempool Integration | Frames operate in Ethereum's public mempool with protocol-level rules, unlike previous off-chain bundler approaches. |
| Backward Compatibility | Default code supports ordinary EOAs, allowing existing wallets to access sponsored and token-paid transactions without migration. |
| Atomicity | Multiple actions can be batched so they succeed or fail together, reducing partial-state issues. |
| Cryptographic Roadmap | Frames facilitate key rotation and prepare for post-quantum signatures, encouraging aggregation strategies for large signatures. |
Afterwards...
Looking forward, Frames could reshape user experience and developer patterns on Ethereum by making fee sponsorship and token-based gas payments native capabilities. If adopted, the proposal would reduce dependence on external relayer networks, simplify wallet onboarding for token-first users, and enable richer batched interactions that avoid common pitfalls like leftover approvals. It also positions the protocol for cryptographic evolution by making account verification more flexible and by encouraging aggregation techniques that mitigate the size of post-quantum signatures. However, the timeline for inclusion remains uncertain: the specification is still draft, requires broader client and community testing, and must be carefully vetted for security and compatibility before any upgrade. Continued experimentation on testnets and client implementations will be essential to determine practical deployment steps and to refine the specification for real-world use.
