Ethereum co-founder Vitalik Buterin on October 19, 2026, publicly supported EIP-8288, a draft standards-track proposal designed to handle advanced cryptography more efficiently. The initiative aims to let users generate signatures and proofs on their own devices and submit aggregated evidence for network verification, reducing the data and computation load placed directly on the blockchain.

Addressing Limits of Current Verification Methods

Ethereum currently verifies cryptographic statements through the Ethereum Virtual Machine or specialized precompiles. Both approaches require the relevant data to enter the chain, typically as calldata in blocks. Buterin argued that this model becomes impractical as signature sizes and proof volumes grow. He estimated that even with improvements such as PeerDAS and blocks-in-blobs, practical data handling could face limits around 8 megabytes per second.

In a series of posts, Buterin stated that precompiles and the EVM are not the right long-term place for most cryptography support. Large signatures and proofs would otherwise force repeated protocol changes and inflate block data. Instead, he favored a system in which substantial computation occurs outside the main execution environment while results remain verifiable on-chain.

How EIP-8288 Would Function

EIP-8288, titled In-mempool signature and proof aggregation, was created on June 3, 2026, by Buterin and Ethereum researcher Thomas Coratger. The proposal introduces a new transaction frame mode that declares cryptographic dependencies. Each declaration identifies the verification scheme, a hash of the relevant data, and a hash tied to the verification key.

Users would generate signatures or proofs locally. These proofs can then be combined recursively in the mempool using STARK technology. A STARK allows one party to demonstrate that a computation was performed correctly without requiring every verifier to repeat the full calculation. An aggregation interval of 1,000 milliseconds is specified. Block builders would collect transactions along with the aggregated proofs, and a final recursive STARK would cover the dependencies of the selected transactions.

The design retains necessary transaction information and cryptographic commitments on the blockchain. Original large signatures and proofs would not be published as ordinary calldata. The proposal builds on EIP-8141, which provides a framework for transactions with multiple execution and verification steps, and lists EIP-2718 as a dependency. Each transaction is capped at 16 specified signature dependencies and one STARK dependency to limit overload. Compatibility with FOCIL, a proposed transaction-inclusion mechanism, is also addressed.

Support for Quantum-Resistant Signatures

A central motivation for the proposal is support for larger cryptographic signatures intended to resist attacks from future quantum computers. Hash-based signatures under consideration can require roughly 2 to 3 kilobytes and an estimated 150,000 to 200,000 gas for direct verification. Lattice-based signatures present similar challenges. STARK proofs themselves can exceed 128 kilobytes, with some configurations optimized for faster generation reaching approximately 512 kilobytes.

By aggregating these elements, EIP-8288 would allow Ethereum to verify complex systems without creating a separate precompile for every new signature type. Buterin noted the possibility of using lattice-based cryptography for accounts and wallets if the relevant security assumptions hold. He also referenced cryptography that might prove secure against AI-related attacks, treating this as distinct from standard quantum resistance.

Current Status and Implementation Path

EIP-8288 remains a draft core proposal. It has not received approval for mainnet deployment and carries no activation date. Implementation details, including parameters for the aggregated verification key and dependency hashing, are unfinished. A reference implementation is listed as forthcoming.

Existing test cases cover individual signatures, multiple proof dependencies, invalid recursive proofs, mempool aggregation, and transaction-inclusion-list compatibility. Ordinary transactions without the new frames would continue to operate as before. Nodes that have not upgraded would reject transactions using the new frame mode and blocks containing the recursive proof header. Activation would therefore require a coordinated network upgrade.

The proposal aligns with Buterin’s broader description of Ethereum as a cryptographic world computer, in which the blockchain focuses on shared verification while heavy computation takes place off-chain. Developers continue to examine the practical requirements this model would place on user devices and the organization of aggregated data within the network.