Ethereum co-founder Vitalik Buterin has detailed a conceptual redesign of how transactions are structured and validated on the network. The approach distinguishes the effects a transaction produces from the conditions that must be met before those effects can take place, opening paths for parallel checks and reduced repetitive work by validators.

Buterin framed the change as a clearer understanding that has emerged from recent work on transaction formats, account abstraction, alternative state models, keyed nonces, and recursive STARK-based mempools. The proposal remains research-oriented and has not received final approval for a mainnet upgrade.

Actions Versus Dependencies

In the model, actions represent the state changes a transaction creates, such as transferring ETH or calling a smart contract. Dependencies cover the prerequisites that establish validity. These include digital signatures, Merkle proofs confirming the existence of relevant data, zero-knowledge proofs, and any state conditions that must hold when the transaction enters a block.

Current Ethereum processing typically combines authorization, fee payment, and execution into a single flow. Nodes verify signatures, confirm the sender can cover costs, and then run the instructions. Buterin noted that many dependency checks do not rely on the final state outcomes and can therefore be handled separately.

Independent checks, such as signature verification, can proceed concurrently across available resources. State-dependent conditions require more care because an earlier transaction might alter a balance or storage slot and invalidate a later condition. Declaring the parts of state a transaction will access would allow mempools to reason about these conditions more effectively.

Buterin estimated that more than 90 percent of Ethereum activity by volume does not require the network’s full dynamic flexibility. Predictable operations could adopt more restrictive, statically analyzable formats and potentially receive lower gas costs, while complex dynamic calls would remain available at higher cost. The design preserves Ethereum’s flexible account model and does not replace it with a pure unspent-transaction-output system. Instead, it envisions a spectrum that draws useful ideas from both approaches.

EIP-8141 and Frame Transactions

The redesign aligns closely with EIP-8141, a draft proposal for a new transaction type called Frame Transactions. Under this format, a single transaction is divided into ordered frames that handle distinct roles: validating authority, approving gas payment, and executing the intended operations.

Validity and fee payment would no longer rest solely on a standard outer signature. Account code could define the necessary authorization and payment rules. This structure supports sponsored fees, payments in tokens other than ETH, key rotation, transaction batching, and features previously associated with account abstraction, without requiring identical contract deployments across every compatible network.

Verification frames would establish whether the sender authorized the transaction. Separate frames could determine who pays the fees and then carry out the state-changing actions. The overall format is described as a basic list of calls marked with flags that identify their function—pure dependency, state-dependent verification, or action—alongside standard details such as origin and nonce.

Frame Transactions could improve interoperability among Ethereum Virtual Machine networks by allowing chains to share a minimal structure while applying their own verification tools or account features. The proposal remains a draft Core EIP. Its specification covers mempool admission, frame execution, receipts, signatures, gas accounting, and propagation rules, all of which may evolve during review.

Developers have raised technical questions about denial-of-service risks, transaction replacement rules, tooling adjustments, pending-transaction limits, and restrictions on verification frames. One noted constraint is that the public mempool would typically retain only one pending Frame Transaction per sender, prompting discussion of how that rule would affect accounts that submit multiple transactions in a single block.

Parallel Checks and Recursive STARK Aggregation

Beyond the immediate Frame Transaction design, Buterin described a longer-term path in which pure dependencies—those requiring no access to live state—are verified once at the mempool layer. After successful checks, the network could replace repeated individual verifications with a recursive STARK proof confirming that all such checks were performed correctly.

A STARK is a cryptographic proof that demonstrates a computation was executed properly. Recursive proofs can verify other proofs, allowing many individual checks to be compressed into a compact verification task. Validators would then confirm the aggregated proof rather than re-running every original dependency.

This approach could also reduce the volume of verification data placed on-chain if the recursive proof establishes validity. Such aggregation is not part of the current EIP-8141 specification and would require further work on proof generation, mempool coordination, data availability, and safeguards against invalid aggregation.

EIP-8141 and the broader conceptual framework are positioned as preparation for responsible, decentralization-friendly scaling. Core developers have advanced related discussions, with some reports indicating the proposal is under consideration for a 2027 network upgrade, though no final deployment timeline has been confirmed. Ongoing review will address remaining technical and operational questions before any client implementation can proceed on a stable specification.