Draft EIP-8390 would retire Ethereum sync committee
A draft EIP filed Aug. 24 would remove the 512-validator sync committee, cut annual consensus issuance by about 33,800 ETH and replace Altair light-client updates with off-chain ZK proofs.
Draft EIP-8390, filed in the official EIPs repository on Aug. 24 at 02:04 UTC, would retire Ethereum’s 512-validator sync committee, remove its rewards and replace the on-chain Altair light-client update flow with off-chain zero-knowledge proofs. The document is a draft for discussion; it lists no activation epoch, no roadmap commitment and no external reviews in its initial update.
The sync committee is a 512-validator sample whose signed messages allow light clients to follow the beacon chain without processing the full validator set. EIP-8390 would remove the committee’s validator duties, its network messages and several Beacon API endpoints used by Altair-era light clients. Software that consumes the Altair LightClientUpdate flow — including Helios, Lodestar, Nimbus and Datachain’s Ethereum IBC client — would need migrations or new interfaces to continue operating after the proposed fork.
On issuance, the draft targets the sync committee’s reward weight of 2 within a denominator of 64 in Ethereum’s consensus reward formula. Removing that weight reduces the consensus issuance allocated to sync-committee rewards by 1/32. Using a cited snapshot of about 901,505 validators, 42,328,615 ETH staked and an estimated annual consensus issuance of about 1.082 million ETH, the removed share equals roughly 33,800 ETH per year. The change applies only to the sync-committee share of consensus issuance; realized validator yields can still include other consensus rewards and execution-layer income.
Altair does not define a slashing condition specifically for validators that sign malicious sync-committee messages. A separate proposal that would have added such a penalty, EIP-7657, is marked Stagnant. Removing the sampled committee would remove that particular accountability vector but replace it with a dependency: light clients would be expected to accept a zero-knowledge proof of Casper FFG finality covering the full validator set as their finality signal.
EIP-8390 asserts finality proofs could be produced within one epoch on a single GPU and verified in milliseconds. The draft does not include a reproducible circuit, benchmark, hardware profile or published implementation to support those numbers. A different public full-set design reports sub-minute preprocessing on a 64-core CPU without GPU acceleration and notes parts of its final proof composition remain unbuilt. The EIP does not define a proving service, client interface, reliability model, operators or funding sources, and it proposes no in-protocol incentive to produce finality proofs.
For the draft to move toward activation, client teams would need a tested replacement interface for light clients, working migrations for current Altair consumers and public proof production that remains available when users depend on it. The proposal’s estimated issuance savings are specified in its own calculations while the replacement infrastructure, migration path and economic support remain unspecified.








