Vitalik has proposed a "maximalist EIP-8288" roadmap, which could end Ethereum's practice of adding new precompiled contracts going forward.
Written by Nicky, Foresight News
On October 19, Ethereum co-founder Vitalik Buterin stated in a response to ongoing community debates that the ideal path to support a wide range of cryptographic schemes is EIP-8288: Users can generate arbitrary signatures locally, then commit them on-chain via STARK proofs (a type of zero-knowledge proof that verifies "I have completed this computation and the result is correct" without exposing the underlying process) through STARK aggregators, which will drastically reduce on-chain calldata (raw data carried in transactions, where larger data sizes incur higher on-chain fees) consumption. This approach would allow Ethereum to stop adding new precompiles going forward (precompiles are built-in programs hardcoded into Ethereum’s base layer designed specifically to accelerate specific types of cryptographic operations).
This statement comes against the backdrop of a recent heated debate over the "hash-based vs lattice-based" cryptographic roadmap.
On October 17, a16z crypto published a blog post introducing its new system Aerie, which uses lattice-based SNARKs to aggregate Falcon signatures. It took only 0.65 seconds to aggregate 32,768 Falcon-512 signatures on a single Apple M4 Max laptop.
The post argued that Ethereum’s planned pure hash-based scheme relies on multi-round recursion, has a complex construction, and requires custom non-NIST standard schemes. Specifically, recursive merging introduces coordination overhead and risk of errors, while each step also requires proving statements about the hash function used to generate the proof, whose security is difficult to establish under the random oracle model. Meanwhile, the use of custom schemes means the underlying hash function is not yet finalized, limiting support for the scheme across hardware wallets, hardware security modules, and institutional custody systems.
StarkWare CEO Eli Ben-Sasson immediately responded, stating he "strongly disagrees" with the argument. He noted that the rich mathematical structure of lattice cryptography makes it more vulnerable to AI-driven attacks, and recommended observing the ecosystem for another 3 to 5 years before making a roadmap decision.
Vitalik did not take sides in the debate, instead reframing the discussion at the architectural level: regardless of whether hash-based or lattice-based cryptography is used, heavy cryptographic logic should not be hardcoded into the EVM. The correct path is to generate proofs on the client side, then commit them on-chain via EIP-8288’s aggregation mechanism.
What is EIP-8288?
Officially titled "Mempool Signature and Proof Aggregation", EIP-8288 was submitted as a draft on June 3, 2026 by Vitalik Buterin and Thomas Coratger. It is currently still in Draft status, with no fixed mainnet upgrade timeline attached to the proposal.
To understand the value of the proposal, it is first necessary to examine the current challenges facing Ethereum.
For every transaction submitted on-chain, signatures and proofs must be fully validated at the base layer. Post-quantum signatures (signature schemes designed to resist attacks from future quantum computers) and STARK proofs are notoriously large: hash-based post-quantum signatures are roughly 2–3 KB in size, with a verification cost of 150,000 to 200,000 gas. Privacy transactions that add quantum security layers could see costs skyrocket from around 300,000 gas to nearly 10 million gas, making direct on-chain submission prohibitively expensive for most users.
EIP-8288’s core approach is to require transactions to only carry a lightweight "dependency attestation": a roughly 96-byte tuple consisting of the signature scheme, data hash, and verification key hash. The actual signatures and proofs are incrementally aggregated by nodes in the mempool (the waiting area for transactions before they are included in blocks) via recursive STARKs. Recursion refers to the property that proofs can themselves be proven, merged layer by layer, such that the final block only needs to include a single aggregated proof of 100–300 KB in size to verify the validity of all listed dependencies.
Derek Chiang, founder of ZeroDev and a member of Ethlabs, offered an intuitive explanation of the proposal: EIP-8288 adds a fourth scaling dimension to Ethereum — proof verification — in addition to the existing three dimensions of execution, data availability, and state. Because aggregation work is distributed across the large number of nodes in the mempool, more nodes translate to a higher capacity to process signatures and proofs. The distributed mempool, traditionally seen as a bottleneck, becomes a scaling resource instead.
What problems does EIP-8288 solve?
EIP-8288 directly addresses the inherent cost tension between post-quantum migration and privacy transactions. If Ethereum wants to support quantum-resistant signatures in the future without sacrificing the zero-knowledge proof requirements of privacy protocols, it must bring down verification costs. EIP-8288 leverages recursive mempool aggregation to reduce verification costs to the order of thousands to tens of thousands of gas.
For regular users, everyday transfers and mainstream DeFi interactions will see almost no impact. Noticeable changes will be concentrated across three core scenarios: privacy transaction costs could fall from a "luxury" level to near the cost of regular transactions; quantum-resistant wallet signature fees will drop drastically, eliminating the need to trade off security for cost when upgrading wallets in the future; and verification overhead for AI agents and complex account logic will be reduced, making smart assistant-type products easier to deploy at scale.
EIP-8288 also has close ties to AI development.
The link between EIP-8288 and AI operates on two levels. On one hand, heavy computation can be completed and converted to STARK proofs on client devices (even mobile phones) before being committed on-chain via aggregation, providing a cost-viable path for AI agents to execute complex strategies and validate client-side inference.
On the other hand, the current cryptographic roadmap debate itself is tied to AI. Vitalik has previously emphasized that AI-accelerated mathematical research could weaken the security of structurally rich schemes like lattice cryptography, making hash-based solutions the more preferred choice. But EIP-8288’s design allows users to choose their own preferred scheme, including wrapping lattice-based solutions in STARK proofs.
Current Development Status
EIP-8288 remains in the draft stage, with no mainnet implementation or widespread adoption to date. Related progress is concentrated at the infrastructure layer: testnets for EIP-8141 (Frame Transactions) are already undergoing testing, with early exploration and prototypes built around the Lean Ethereum toolchain, mempool aggregation simulation, and algorithm optimization. Vitalik has expressed hope that the proposal will be included in the "I-star" hard fork following the Hegota upgrade.
There are currently no mainstream launched, tokenized projects that have publicly announced adoption of the technology, as it has not yet been deployed on mainnet. Teams building related infrastructure include those working on Lean Ethereum, Frame Transactions testing, as well as ecosystem projects focused on post-quantum cryptography and high-efficiency ZK. a16z’s Aerie is a research system built in partnership with projects including LayerZero, and is not a deployed, production standard.
From a long-term perspective, the significance of EIP-8288 does not lie in selecting a single winning cryptographic scheme, but in shifting Ethereum from a "world computer that constantly adds precompiles" to a leaner "world verifier": validating results, rather than re-executing heavy computations. If implemented, it will drastically reduce costs for post-quantum signatures, privacy transactions, and ZK proofs, while eliminating the need for hard forks to integrate new cryptographic schemes. The proposal still requires broad community consensus at present, with final parameters and deployment timelines yet to be determined.