Ethereum’s Frames Proposal Rewrites Transaction Execution From the Ground Up

Ethereum co-founder Vitalik Buterin said on Sunday that EIP-8141, a proposal restructuring how transactions are processed on the network, has been quietly advancing for months. The proposal, known as Frames, replaces the fixed structure of an Ethereum transaction with a sequence of up to 64 individual contract calls, each termed a “frame.” One frame handles validation, another approves who covers the gas cost, and the remaining frames execute the user’s intended actions. The specification remains a draft as of January and has not been scheduled for any network upgrade.

Breaking payment approval into its own step separates the account that signs a transaction from the account that funds it, according to the proposal’s authors. A wallet holding only stablecoins could transact by paying fees in ERC-20 tokens, or an application could sponsor its users directly without requiring the user to hold ETH for gas. Ordinary externally owned accounts, or EOAs, are covered under the specification’s “default code,” which grants wallets with no deployed contract the same sponsored transactions, token-paid gas, and batched calls without requiring users to migrate to a smart account.

The ability to pay fees in tokens or have them sponsored has existed since 2023 through ERC-4337, but that system routes transactions through a separate mempool and relies on third-party bundlers to package and submit them. Frames operates in Ethereum’s public mempool, with protocol-level rules that allow nodes to evaluate a transaction’s validation steps before accepting it into the pool. Historical attempts at native account abstraction, including EIP-86 and EIP-2938, failed because permitting arbitrary contract logic during validation exposed the public mempool to unbounded computation and zero-fee spam attacks. EIP-8141 addresses this by enforcing deterministic constraints on the validation frame, limiting the computational work nodes must perform before admitting a transaction.

Frames also allows multiple actions to be grouped into a single atomic unit, meaning they either all succeed or all fail together. This structure eliminates the dangling token approvals left behind when a swap reverts mid-execution, a common issue in Ethereum’s current transaction model. The proposal additionally unlinks accounts from the ECDSA keys that control them, enabling key rotation for the first time on the network. Key rotation is tied directly to the separation of signing from funding: because the signature validation step is independent of the payment step, a user can change the cryptographic key authorizing transactions without altering the account that pays for gas.

Co-author Matt Garnett, who writes under the pseudonym lightclient, described Frames as a “native off-ramp” from the elliptic-curve cryptography Ethereum currently uses for authentication. Ethereum relies on secp256k1 ECDSA signatures, which produce 65-byte payloads. Post-quantum signature schemes—such as Winternitz hash-based signatures, Falcon, or STARKs—run to several kilobytes each, according to Garnett. That payload increase would congest block space under the current transaction format, forcing the network toward signature aggregation and batching to maintain throughput. Frames’ multi-step execution architecture accommodates larger signature payloads by separating the cryptographic validation step from the execution payload, allowing nodes to verify signatures without loading the full transaction data into execution context.

Buterin pointed to a testnet run by the ethrex client that pairs Frames with FOCIL, the Fork-Choice Enforced Inclusion Lists mechanism. FOCIL decentralizes block building by requiring consensus validators to submit lists of transactions that block builders must include, neutralizing the ability of centralized MEV relays to censor specific smart-contract calls or privacy transactions. The testnet combination lets privacy protocols operate without relayers, according to Buterin, by using FOCIL to enforce inclusion of Frames-based transactions that would otherwise be filtered by relay operators.

The proposal has not been scheduled for any core developer call or network upgrade as of the date of Buterin’s statement. Ethereum developers have previously slated EIP-7702, a temporary contract code injection for EOAs, for the upcoming Pectra upgrade. EIP-8141 operates as a more permanent structural overhaul by embedding multi-step execution directly into the base Layer-1 execution environment, superseding interim solutions that modify account behavior through contract code injection. Garnett wrote that Frames “should be the last transaction type we need for accounts.”