Ethereum co-founder Vitalik Buterin wants to cut Ethereum transactions in half. In a proposal detailed Sept. 6, he argued the network should separate "actions," the operations that actually change state, from "dependencies," the validity checks that run before execution, because more than 90% of activity by volume is routine transfers that never needed dynamic flexibility in the first place.
The split sounds academic. It is not. Ethereum currently processes authorization, gas accounting and execution in one sequential pipeline, and every node verifies everything, every time. Buterin's redesign would let pure dependencies get validated in parallel across mempool nodes and then compressed into recursive STARK proofs, killing the redundant verification that bogs down clients and layer-2 rollups alike. Think of it as Ethereum borrowing Bitcoin's UTXO-style static predictability without giving up EVM programmability.
"One positive consequence of all the recent detailed thinking about transaction formats is that we have a much more explicit understanding of how transactions have to work." — Vitalik Buterin (@VitalikButerin), September 5, 2026
How Ethereum transactions would change in practice
Under the model, an ETH transfer or a predictable contract interaction becomes a static object that nodes can pre-check, batch and prove. A complex DeFi operation keeps its full dynamic execution path. The distinction matters because static things scale: parallel validation, recursive proof compression, simpler fee estimation. Dynamic things pay full freight. The 90% figure is Buterin's analytical estimate, not a peer-reviewed measurement, and you should treat it as directional. But even at half that share, the efficiency case is obvious.
The proposal dovetails with draft EIP-8141, the Frame Transactions spec that reframes advanced features as contract-call frames instead of transaction-envelope changes. The two designs share DNA: modular pieces, fixed container, no upheaval for wallets and L2s on every nine-month upgrade cycle. The draft spec limits public mempools to one pending frame transaction per sender, a DoS guard that also kneecaps high-frequency dApps. Trade-offs like that one are why this remains a research conversation rather than a roadmap item.
Why the timing matters for Ethereum
The honest caveats: core developers have approved nothing, no hard fork date exists, and the open questions include DoS exposure, fee-estimation rewrites for every wallet, and RPC interface churn. The single-pending-transaction mempool limit would break batch-heavy applications unless redesigned. History says Ethereum's hardest upgrades are the social ones, and this touches infrastructure everyone depends on.
But the direction tells you where the protocol is heading. Ethereum's scaling story has lived on layer-2s for two years while mainnet execution stayed mostly untouched. A redesign that makes the base layer's transaction pipeline cheaper to verify changes the economics of running a node, and cheaper nodes mean more nodes. The detail to watch is whether EIP-8141 makes it into the Hegotá upgrade's Meta EIP alongside FOCIL, which would turn this from a think piece into an engineering plan with dates attached. Until then, treat it as the clearest signal yet of what Ethereum intends to become: a chain where the boring 90% is nearly free, and only the interesting 10% costs real money.
