Ethereum co-founder Vitalik Buterin wants the network to stop adding a new precompile every time a fresh cryptographic scheme shows up. In a post on X on October 19, 2026, he called for "EIP-8288 maximalism" and argued that heavy cryptography should be STARKed client-side rather than pushed onto Ethereum's main chain.
The proposal, first reported by CoinGape, is framed as a way to end what the outlet calls Ethereum's "precompile wars." That's the long-running fight over which cryptographic primitives get baked directly into the protocol as special-purpose opcodes.
What Buterin actually wants
The core of the argument is straightforward. Precompiles are expensive to add, hard to change once they're live, and they bloat the consensus rules that every client has to implement. Buterin's answer is to move the heavy lifting off-chain, let clients prove cryptographic work with STARKs, and verify those proofs on-chain instead of shipping new precompiles for each emerging scheme.
That's a meaningful shift in posture for a protocol that has historically expanded its precompile set as new cryptography gained traction. It also puts a clear limit on what Ethereum's base layer should absorb.
The precompile fight, briefly
Precompiles sit at the edge of the EVM. They're cheap relative to equivalent bytecode, which is why application developers push for them, but they're also permanent. Every added precompile is a commitment that client teams have to maintain and that future upgrades have to work around.
That tension has played out repeatedly as zero-knowledge and other cryptographic schemes matured. Developers want native support. Core contributors want a smaller, more predictable protocol. Buterin's post lands squarely on the second side of that divide.
Where STARKs fit in
The client-side STARK approach isn't new to Ethereum's design vocabulary, but pitching it as the default answer to every new cryptographic request is a sharper line than the network has drawn before. If it takes hold, the pattern would look like this: new cryptography gets proven off-chain, a STARK verifies the work, and the main chain stays relatively clean.
That's cheaper for the base layer and easier for client teams. It's less convenient for developers who'd rather have a dedicated precompile. Buterin's post doesn't offer a middle ground.
What comes next
Nothing is decided by a single X post. "EIP-8288 maximalism" is a slogan, not a finalized specification, and the facts around it stop there. What the post does do is set an agenda: anyone proposing a new precompile from here on will have to explain why a client-side STARK isn't good enough.
For now, the ball sits with Ethereum's core developers. They'll be the ones who decide whether "STARK it client-side" becomes the network's default answer, or just a strong opinion from one co-founder.
