EIP-8288 Would Aggregate Ethereum Signatures Before They Reach a Block

A draft Ethereum proposal would take most cryptography out of the place it runs today. EIP-8288, titled In-mempool signature and proof aggregation, was created on 3 June 2026 by Vitalik Buterin and the researcher Thomas Coratger, and has sat in the EIP repository as a draft since. Buterin returned to it in a series of posts on Monday. Under the proposal a transaction carries only a short declaration of what needs checking, and nodes in the mempool, the holding area where transactions wait for a block to pick them up, bundle those declarations into a single recursive STARK proof that the block must then contain. Nothing about it is settled.

What a transaction would carry instead

The mechanics are in the EIP text, which is specific where the coverage is loose. A transaction declares its cryptographic dependencies using a verification scheme identifier, a hash of the relevant data and a hash tied to the verification key, as crypto.news described it on Monday morning. The ceilings are low on purpose. The spec allows at most 16 leanSPHINCS signature dependencies and exactly one leanSTARK proof dependency per transaction, and gives each mempool node an aggregation interval of 1,000 milliseconds, after which it broadcasts one wrapper covering the transactions it is holding. Users generate their signatures and proofs off-chain, and proofs can be combined recursively. Both outlets that covered the draft rendered those two names as "hash-based signatures" and "STARK proofs"; the figures below come from them, the limits above from the proposal.

The case against precompiles

Buterin's Monday argument was about placement. A precompile is a built-in contract that performs one cryptographic operation at a fixed gas price, and adding another one has been Ethereum's habitual answer to a new scheme. He said that answer is the wrong one.

"Ultimately, precompiles and EVM are both the wrong place to put most cryptography support into Ethereum," Buterin wrote on Monday.

The reason he gave is bandwidth. Both routes require their input data to be published on the chain, realistically as calldata inside blocks, and calldata is the scarce resource. TronWeekly, writing at 12:24 UTC, put the practical ceiling at about 8 MB/s and said Buterin expects it to hold even once PeerDAS, the data-availability sampling scheme, is in place. crypto.news carried the same 8 MB/s figure four hours earlier but called it a forward engineering estimate and not measured throughput. The number is identical in both accounts; the framing is not. TronWeekly adds that every new precompile also brings client code, audit surface and coordination work between development teams, a cost the draft would sidestep by letting new schemes ship without a protocol change.

Why the post-quantum timing matters

The pressure behind the draft is the move to signatures that survive a quantum computer, and those signatures are large. Hash-based post-quantum signatures run to roughly 2–3 KB and cost 150,000 to 200,000 gas to verify directly, a figure crypto.news and TronWeekly both carry. Client-optimised STARK proofs land between 128 KB and 512 KB. TronWeekly alone reports that a quantum-safe transaction costs about 10 million gas today and would fall to tens of thousands under EIP-8288, against roughly 300,000 gas for a high-quality private transaction; those three numbers appear in no other account and stand unverified. Ethereum's researchers have been circling this problem for months, from a draft that would let validator deposits carry 8,192-byte keys to the debate over an early, defensive move off ECDSA.

What has to happen first

EIP-8288 is a draft standards-track proposal in the core category. It requires EIP-2718 and EIP-8141, lists its reference implementation as forthcoming, and leaves some parameters incomplete. No client team has endorsed it and no mainnet date exists; because it changes consensus rules, it would need a coordinated network upgrade to ship at all. TronWeekly names two open problems the text does not answer: what incentive an aggregator has to do the work, and how the mempool holds up if aggregation becomes a chokepoint. Neither has a published answer yet.