Vitalik Buterin Floats Framework to Split Ethereum Transaction Verification and Execution

Vitalik Buterin has outlined a long-term overhaul of Ethereum's transaction model that would separate what a transaction does from what it must prove before it can run, according to CoinMarketCap. In the proposed framework, transactions are divided into "actions" and "dependencies." Actions are the parts that actually modify on-chain state. Dependencies are preconditions that can be checked ahead of execution, such as signatures, state proofs and other validity requirements. By moving some verification work earlier—potentially before a transaction is even included in a block—the design aims to enable more parallelism and treat verification and execution as distinct steps. Today's Ethereum pipeline typically bundles authorization, fee payment and contract execution into a single flow. Nodes must verify the signature, confirm the sender can pay fees, and determine whether execution succeeds, all in one pass. Buterin argues that several of these checks don't depend on final state changes and could be processed separately. He cited digital signatures, zero-knowledge proofs and certain validity proofs that don't rely on on-chain state changes as candidates for the "dependency" bucket. A key element is predictability: if transactions explicitly declare which state they will access, the mempool can more easily identify which conditions are affected by prior transactions and which checks can be completed in advance. More predictable transactions could, in turn, be verified more efficiently. The draft proposal associated with this approach is EIP8141. It introduces a new transaction type, "Frame Transaction," which breaks a transaction into multiple call frames so authorization checks, fee payment and user operations can be handled independently. Under the draft design, transaction validity and fee payment would no longer be fully tied to standard outer-layer signatures. Instead, account code could define custom authorization methods and payment rules. A verification frame would confirm whether conditions are satisfied, while a sending frame would carry out state changes. Supporters also see the format as a potential step toward aligning underlying transaction structures across different EVM networks. EIP8141 remains a core draft, has not been slated for any Ethereum mainnet upgrade, and has no deployment timeline. Developer discussions have raised several open technical questions, including denial-of-service risks, transaction replacement rules, compatibility with wallets and block builders, and limits on the number of pending transactions from the same sender in the public mempool. These topics remain under review. Buterin's longer-term vision extends beyond EIP8141. For "pure dependencies" that don't require access to on-chain state, he suggests performing an initial check at the mempool layer so validators don't repeat the same work. The network could then compress many completed verification results into a recursive STARK proof that is verified collectively, reducing redundant computation and easing verification load. He also noted this direction could help Ethereum adapt to post-quantum cryptography, since quantum-resistant signatures are typically larger and more costly to verify. If accounts can customize authorization methods and combine them with recursive proof aggregation, verification costs could fall. These concepts remain in the research stage and are not part of the current EIP8141 draft. Full implementation would still require solutions for proof generation, mempool coordination, data availability and safeguards against aggregating errors.