Ethereum co-founder Vitalik Buterin has endorsed draft EIP-8288 as a way for Ethereum to handle more advanced cryptography without repeatedly expanding the protocol with new built-in verification functions. In a series of posts on X on October 19, he argued that most heavy cryptographic work should happen outside Ethereum’s main execution path, with the chain verifying compact aggregated proofs instead of processing every original signature or proof directly.
The proposal is still only a draft. It has not been approved for Ethereum mainnet, and several technical details, security reviews and implementation steps remain unfinished before developers could consider activation through a coordinated network upgrade.
Why Buterin wants a different model
Buterin’s argument centers on the limits of Ethereum’s current tools for cryptographic verification. Developers can use the Ethereum Virtual Machine for some checks, and the network also offers precompiles, or built-in functions, to verify certain signatures, hashes and zero-knowledge proofs more efficiently than ordinary contract code.
His view is that neither the EVM nor precompiles should become the default path for every new cryptographic system. Both approaches ultimately rely on data being carried onchain, usually as calldata in blocks. In his October 19 discussion, Buterin estimated that even with future upgrades such as PeerDAS and blocks-in-blobs, practical engineering constraints would appear around 8 megabytes per second of additional data.
He framed the issue as part of a broader vision for Ethereum as a “cryptographic world computer,” where only information that needs shared execution and verification stays in the blockchain, while larger computational tasks are pushed offchain and later proven back to the network.
How EIP-8288 is designed to work
EIP-8288, titled In-mempool signature and proof aggregation, was created by Buterin and Ethereum researcher Thomas Coratger on June 3, 2026. The draft would let transactions declare which cryptographic statements must be verified without forcing every original proof or signature into the final block.
Under the specification, a transaction would reference the verification scheme, a hash of the relevant data and a hash tied to the verification key. Users would generate signatures or proofs locally, outside Ethereum’s main execution environment. Those proofs could then be recursively combined so that one proof attests to the validity of several smaller ones.
At the block level, Ethereum would verify an aggregated recursive STARK covering the required transaction dependencies rather than checking each original signature and STARK separately. The design builds on EIP-8141, which proposes a framework for transactions with multiple execution and verification steps, and it would still keep transaction information and cryptographic commitments onchain.
Large signatures and proofs are a key use case
A major motivation for the proposal is support for cryptographic systems that are expensive in either data size or verification cost. EIP-8288 specifically discusses quantum-resistant signatures, which are being studied as possible alternatives if future quantum computers threaten current schemes used for wallet authentication and consensus.
According to the draft, some hash-based signatures could require roughly 2 kilobytes to 3 kilobytes and an estimated 150,000 to 200,000 gas to verify directly. Lattice-based signatures pose similar scaling concerns in the proposal’s cost analysis. STARK proofs are larger still, exceeding 128 kilobytes in some cases and reaching around 512 kilobytes in configurations optimized for faster proof generation.
Buterin said users should be able to create the signatures they prefer locally and then prove validity through STARK aggregation. He also mentioned the possibility of lattice-based cryptography for Ethereum accounts and wallets if the relevant security assumptions are established. His October 19 remarks separately referred to cryptography that might be secure against AI-related attacks, which is not the same claim as standard quantum resistance.
Aggregation would begin before a block is built
The draft does not leave all proof collection and compression to the block producer. Instead, it describes recursive aggregation starting in the mempool, where pending transactions wait to be included in blocks. Users would submit transactions together with the cryptographic evidence needed to authorize them, and mempool participants could validate that evidence and combine several proofs before passing them on.
The aggregation interval in the draft is 1,000 milliseconds. Block builders would then gather the selected transactions and their aggregated proofs and produce a final recursive STARK for the dependencies tied to that block. To reduce the risk of abuse, the proposal suggests limits including up to 16 signature dependencies and one STARK dependency per transaction.
The specification also considers compatibility with FOCIL, a proposed transaction-inclusion mechanism intended to make censorship harder. Even so, the draft says ordinary transactions that do not use the new verification frames would continue to work as they do today.
Draft status and what comes next
EIP-8288 is currently listed in the Ethereum Improvement Proposal repository as a draft standards-track proposal in the core category. Because it would change consensus rules, nodes that do not adopt the update would not understand blocks using the proposed recursive proof format.
The draft still has incomplete elements, including parameters related to the aggregated verification key and dependency hashing, and its reference implementation is still listed as forthcoming. The repository also does not show any approved mainnet activation date.
That means the next confirmed step is further technical work and review. Developers would need to finish the specification, test the security assumptions, build implementations and reach broader Ethereum consensus before any such aggregation system could become part of mainnet rules.
Source: crypto.news