---
eip: 8390
title: Remove the Sync Committee
description: Remove the onchain Altair sync committee and its rewards, superseded by offchain ZK proofs
author: Lion (@dapplion)
discussions-to: https://ethereum-magicians.org/t/eip-8390-remove-the-sync-committee/29486
status: Draft
type: Standards Track
category: Core
created: 2026-08-22
---

## Abstract

Remove the sync committee from the consensus layer, and with it the Altair light client protocol, which depends on it entirely. `SYNC_REWARD_WEIGHT` goes too, so consensus issuance falls by `2/64`.

The sync committee exists because a light client could not verify the whole validator set. ZK proving has since made that verification practical, so the sample is no longer needed.

## Motivation

The sync committee is a sample of 512 validators, resampled every 256 epochs, about 27.3 hours. A light client believes a header when two thirds of that sample sign it. It exists because a light client in 2021 could not verify the whole validator set.

Three properties make it a poor foundation.

**It is not slashable.** Altair defines no slashing condition for sync committee messages. A corrupted committee can sign a header for a chain that does not exist and lose nothing. [EIP-7657](./eip-7657.md) proposes adding a slashing condition, which is the clearest evidence that none exists today.

**It is a small sample.** The active set is 901,505 validators holding 42,328,615 ETH. The committee is 512 of them, one seat per 1,761 validators. A light client that follows it is backed by 0.06% of the validator set, rotated daily, with no penalty for lying.

**Issuance pays for it.** `SYNC_REWARD_WEIGHT` is 2 against a `WEIGHT_DENOMINATOR` of 64, so the committee takes `1/32` of consensus issuance. At the current stake that is about 33,800 ETH a year, out of about 1,082,000 ETH.

### The replacement is feasible today

A light client could not check a million BLS signatures an epoch in 2021, so it was given 512 to check. Succinct proofs remove that limit.

Proving Casper FFG finality over the full active validator set now fits within one epoch on a single GPU. Verifying such a proof takes milliseconds and needs no key material beyond a commitment to the verifying program. The same proof verifies on other chains, where the sync committee was never usable. Implementations exist today.

A light client backed by such a proof inherits the FFG guarantee. To reverse a finalised checkpoint, a two-thirds coalition must surround its own vote, and a third of the stake is slashed. The sync committee carries no comparable penalty.

## Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).

Names used below without definition are defined in the `ethereum/consensus-specs` repository. `EIP8390_FORK_EPOCH` is the activation epoch.

### Execution layer

This requires no changes to the execution layer.

### Consensus layer

#### Removed constants

`SYNC_COMMITTEE_SIZE`, `EPOCHS_PER_SYNC_COMMITTEE_PERIOD`, `SYNC_COMMITTEE_SUBNET_COUNT`, `TARGET_AGGREGATORS_PER_SYNC_SUBCOMMITTEE`, `SYNC_COMMITTEE_BRANCH_DEPTH`, and the light client generalized indices.

`SYNC_REWARD_WEIGHT`. `WEIGHT_DENOMINATOR` stays at 64, and the weight is not redistributed.

`DOMAIN_SYNC_COMMITTEE`, `DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF` and `DOMAIN_CONTRIBUTION_AND_PROOF`. Implementations MUST NOT reuse these `DomainType` values.

#### Removed containers

`SyncAggregate`, `SyncCommittee`, `SyncCommitteeMessage`, `SyncCommitteeContribution`, `ContributionAndProof`, `SignedContributionAndProof`, `SyncAggregatorSelectionData`, `LightClientBootstrap`, `LightClientUpdate`, `LightClientFinalityUpdate`, `LightClientOptimisticUpdate` and `LightClientHeader`.

#### Removed functions

`process_sync_aggregate`, `process_sync_committee_updates`, `get_next_sync_committee`, `get_next_sync_committee_indices`, and every light client helper built on them.

#### Modified `BeaconBlockBody`

Remove the `sync_aggregate` field. All other fields keep their order and type.

#### Modified `BeaconState`

Remove the `current_sync_committee` and `next_sync_committee` fields. All other fields keep their order and type.

#### Modified `process_block`

Remove the call to `process_sync_aggregate`.

```python
def process_block(state: BeaconState, block: BeaconBlock) -> None:
    process_block_header(state, block)
    process_withdrawals(state, block.body.execution_payload)
    process_execution_payload(state, block.body, EXECUTION_ENGINE)
    process_randao(state, block.body)
    process_eth1_data(state, block.body)
    process_operations(state, block.body)
    # process_sync_aggregate(state, block.body.sync_aggregate)  # [Removed in EIP-8390]
```

#### Modified `process_epoch`

Remove the call to `process_sync_committee_updates`.

#### Rewards

`get_flag_index_deltas` and `get_proposer_reward` do not change. `SYNC_REWARD_WEIGHT` was the only user of the remaining `2/64`, so that share is not issued.

#### Networking

Remove the gossip topics `sync_committee_{subnet_id}`, `sync_committee_contribution_and_proof`, `light_client_finality_update` and `light_client_optimistic_update`.

Remove the `syncnets` ENR field. Remove the Req/Resp methods `LightClientBootstrap`, `LightClientUpdatesByRange`, `LightClientFinalityUpdate` and `LightClientOptimisticUpdate`.

For slots at or after `EIP8390_FORK_EPOCH`, a node MUST NOT publish on these topics. A node MUST ignore messages received on them.

#### Validator duties

Remove sync committee assignment, message production, subnet subscription, aggregator selection and contribution production.

#### Fork transition

The fork upgrade function copies every retained field and drops the two sync committee fields. For slots at or after `EIP8390_FORK_EPOCH`, a block that contains a `sync_aggregate` is invalid.

## Rationale

### Removal instead of repair

[EIP-7657](./eip-7657.md) makes sync committee messages slashable. That improves the current state and it is not enough. Slashing raises the price of corrupting the committee to the stake of 512 validators. It does not make the committee a claim about the validator set. A light client still trusts a sample, still assumes an honest majority inside it, and still pays `1/32` of issuance. A proof of what two thirds of the stake attested to leaves the sample no job.

### The reward weight is not redistributed

Removing `SYNC_REWARD_WEIGHT` and leaving `WEIGHT_DENOMINATOR` at 64 cuts issuance by `1/32` and needs no other change. Lowering the denominator to 62 keeps issuance flat instead. Issuance policy is out of scope. Not paying for a removed mechanism is not.

### The domain types are retired

`DomainType` values are cheap. Retiring three of them stops any pre-fork sync committee signature from being valid in a later context.

## Backwards Compatibility

This is a consensus-layer breaking change and needs a coordinated fork.

**It breaks every deployed Altair light client.** A client that syncs through `LightClientUpdate` stops working at the fork.

**Beacon API.** These endpoints are removed: `POST /eth/v1/beacon/pool/sync_committees`, `GET /eth/v1/beacon/states/{state_id}/sync_committees`, `POST /eth/v1/validator/duties/sync/{epoch}`, `GET /eth/v1/validator/sync_committee_contribution`, `POST /eth/v1/validator/contribution_and_proofs`, `POST /eth/v1/validator/sync_committee_subscriptions`, and `/eth/v1/beacon/light_client/*`.

**Encoding.** `BeaconState` and `BeaconBlockBody` change shape. Tooling that decodes them per fork must be updated. States and blocks from before the fork stay decodable under their own fork schema.

**Validators.** Stakers need to do nothing. Sync committee duties stop being assigned. Staking yield falls with issuance, by `1/32` of the consensus component.

## Security Considerations

### Activating before a replacement

Removing the sync committee removes the only in-protocol way for a light client to follow the chain. Before this EIP activates, public proving infrastructure must exist that publishes finality proofs with characteristics its consumers can rely on. This EIP does not specify that infrastructure, and scheduling is decided by client teams rather than by this document.

### Proof production is not incentivised

This EIP adds no in-protocol incentive to produce finality proofs, and does not propose one.

### Signature replay through a reused domain

`DOMAIN_SYNC_COMMITTEE` (`0x07000000`) and `DOMAIN_SYNC_COMMITTEE_SELECTION_PROOF` (`0x08000000`) are retired. If a later message type takes either value, signatures made by pre-fork sync committees verify against it.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).