Vitalik Buterin Says Over 90% of Ethereum (ETH) Activity Could Skip Full Validation

Actions and Dependencies

Ethereum (ETH) co-founder Vitalik Buterin has laid out a reworked mental model for the network's transaction design, arguing in a Sept. 6 post that the past stretch of protocol work has produced a far sharper line between what a transaction does and what must be proven before it can do it. He divides every transaction into two components: “actions” and “dependencies.” An action is the effect a transaction produces — transferring ETH or invoking a smart contract — while dependencies are the preconditions that establish validity: a digital signature, a Merkle proof showing an unspent output exists, a zero-knowledge proof, or state conditions that must still hold when the transaction enters a block. In the post, Buterin credits the clearer picture to overlapping threads across Ethereum's protocol research — the EIP-8141 Frame Transaction draft, alternative state models including native UTXO designs, keyed nonces and recursive STARK-based mempools. His argument is that making the split explicit would let the network scale without abandoning the flexible execution environment that separates it from more rigid chains. For now the framing stays conceptual: core developers have not approved the full design, and no mainnet timeline exists.

posthttps://x.com/VitalikButerin/status/2096378061377900881

Parallel Checks and One Recursive Proof

The practical payoff lies in how validators spend their resources. Ethereum transactions currently bundle authorization, fee payment and execution into a single processing flow: nodes confirm a signature, check that the sender can cover the cost, then run the instructions. Buterin points out that many of these checks do not depend on the transaction's final state changes. Independent signatures can be verified simultaneously rather than sequentially, and client software can distribute the work across available processing resources. The most aggressive idea concerns “pure” dependencies — checks such as signature validity that never touch Ethereum state. A mempool could verify each one a single time, then replace the entire batch with a recursive STARK, a cryptographic proof that the underlying checks were all performed correctly, letting validators verify the aggregate instead of recomputing every original check. Buterin also adds a cost dimension: transactions that declare their dependencies clearly could qualify for lower gas fees, while dynamic contract calls with unpredictable state access would remain possible but cost more. By his own estimate, more than 90% of Ethereum activity by volume does not require the network's full dynamic flexibility — a figure he presents as a personal assessment, not a measured network statistic.

EIP-8141 Frame Transactions

The concrete artifact behind the discussion is EIP-8141, a draft Core proposal for a new transaction type called a Frame Transaction. It splits a transaction into contract-call frames that separately establish authority, approve gas payment and execute user operations, so validity and fee payment no longer hinge solely on one outer signature. That structure would enable sponsored fees, payment in tokens other than ETH, key rotation and transaction batching, and would let ordinary externally owned accounts receive account-abstraction features without deploying the same contract on every compatible network. Review is active and contested. Developers have raised denial-of-service risks, transaction-replacement rules, pending-transaction limits and tooling burdens for wallets, block builders and RPC interfaces; one debated mempool rule would keep only a single pending Frame Transaction per sender, which some argue penalizes accounts that submit several operations within one block. Keyed nonces, another thread Buterin cited, would give accounts multiple independent nonce sequences so one stuck transfer cannot block unrelated transactions from the same account. EIP-8141 was floated for the future Hegotá upgrade but remains under consideration rather than formally scheduled, and it is often discussed alongside FOCIL, a separate censorship-resistance proposal built on transaction inclusion lists. A combined package is a proposal, not a roadmap commitment. Readers tracking the market in real time can follow live spot and futures prices on Bitget.

Draft Spec, No Activation Date

Read together, the threads form one arc: Ethereum is trying to make routine execution predictable enough to prove cheaply, while complex activity keeps full flexibility. The draft EIP-8141 specification itself details mempool admission, frame execution, receipts, signatures and gas accounting — all explicitly subject to change during review, with no activation block or date published. COINOTAG's read: the verifiable milestones are formal developer support, inclusion in an upgrade scope and working implementations on development networks, echoing earlier scaling fights such as the EIP-4844 rent debate. Until those land, this is research direction, not a confirmed change to mainnet costs.