- EIP-828 moves signatures and proofs outside the execution path, with mempool nodes recursively aggregating them into STARKs.
- Quantum-safe signatures could fall from roughly 10M gas to the low tens of thousands, while supporting Falcon and ML-DSA.
- RISC-V currently leads as the common instruction language for recursive STARKs, potentially becoming part of Ethereum’s core architecture.
Vitalik Buterin has outlined EIP-828, a recursive STARK mempool proposal for Ethereum’s I-star fork after Hegota. The design would move signatures, proofs and related data outside Ethereum’s core execution path. Buterin said the approach could support cheaper quantum-safe signatures, private transactions and account abstraction without repeated EVM changes.
EIP-828 Moves Proofs Into the Mempool
The proposal uses dependency frames containing statements about signatures or proofs. Transactions would carry envelopes with a signature or STARK supporting each statement. Mempool nodes would then aggregate these envelopes every roughly 500 milliseconds.
Each node would remove expired transactions and recursively generate a STARK covering the dependencies. The node would broadcast a new multi-transaction envelope containing that proof.
According to Buterin, this limits outbound bandwidth to one 100-300 kilobyte STARK per interval. The block builder would operate as another mempool node. It would create a STARK covering the transactions selected for the block.
Quantum-Safe Tools Could Use Less Gas
Buterin said the design could reduce the cost of quantum-safe signatures using SPHINCS-. Signature data of about 3 kilobytes would not need onchain storage. Quantum-safe privacy transactions currently require about 10 million gas, according to Buterin.
He said the proposed approach could reduce that figure to the low tens of thousands. The system could also support Falcon, ML-DSA and other signature schemes without EVM changes. Developers would instead wrap those proofs client-side inside STARKs.
Private account abstraction forms another proposed use. Users could keep account logic private while changing ownership across multiple onchain objects.
RISC-V Emerges as a Core Design Choice
Under EIP-828, developers would separate signatures and STARKs from their transaction’s main logic. The core execution would then check whether the required dependency frame exists. Examples include verifying transaction signatures against stored public keys.
Other statements could prove Merkle branches, private addresses or ML-DSA signatures. Buterin said the system requires a common instruction language for recursive STARKs. RISC-V currently leads among candidates for that role.
He described the choice as a major Ethereum design decision. The proposal would therefore make the selected instruction set a canonical part of Ethereum’s architecture.
