--- eip: 8015 title: Remove `deposit` and `eth1data` fields description: Remove legacy deposit and Eth1 data fields from `BeaconBlockBody` and `BeaconState` after EIP-6110 finalization author: Terence (@terencechain), Etan Kissling (@etan-status) discussions-to: https://ethereum-magicians.org/t/eip-8015-remove-legacy-deposit-and-eth1data-fields/25401 status: Draft type: Standards Track category: Core created: 2025-08-22 requires: 6110, 7688, 7773 --- ## Abstract This EIP removes the legacy deposit and Eth1 data fields from the `BeaconBlockBody` and `BeaconState` structures after [EIP-6110](./eip-6110.md) has been fully finalized. These fields become obsolete once all validators have transitioned to the new in-protocol deposit processing mechanism introduced in EIP-6110. ## Motivation EIP-6110 introduced in-protocol deposit processing by moving validator deposits to the execution layer as part of the EIP-7685 request framework. This change eliminated the need for the consensus layer's proposer voting mechanism for deposits. However, during the transition period, both the legacy deposit mechanism (using `deposits` and `eth1_data` fields) and the new mechanism coexist to ensure smooth migration. Once EIP-6110 has been fully finalized and the transition period is complete (when `state.eth1_deposit_index == state.deposit_requests_start_index`), the legacy deposit fields become permanently unused and can be safely removed. The Fulu fork removed legacy deposit processing and requires `body.deposits` to be empty. This EIP removes the remaining `deposits` and `eth1_data` block body fields, the Eth1 data voting machinery, and the unused `BeaconState` fields, providing several benefits: - **Simplified validation**: Removes deprecated validation logic and code paths - **Improved maintainability**: Eliminates technical debt from the transition period ## 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). ### Consensus Layer #### Activation Conditions This EIP SHALL only be activated when both of the following conditions are met: 1. EIP-6110 has been fully finalized: `state.eth1_deposit_index == state.deposit_requests_start_index` 2. Glamsterdam ([EIP-7773](./eip-7773.md)) is in effect #### BeaconBlockBody Modifications The `BeaconBlockBody` container is modified to remove the following fields: **Removed fields:** - `eth1_data: Eth1Data` - `deposits: ProgressiveList[Deposit]` The removal is expressed by setting the corresponding `active_fields` bits of the `ProgressiveContainer` to `0`, as specified in [EIP-7688](./eip-7688.md). The updated `BeaconBlockBody` structure becomes: ```python class BeaconBlockBody( ProgressiveContainer(active_fields=[1] + [0] + [1] * 4 + [0] + [1] * 6) ): randao_reveal: BLSSignature # Removed `eth1_data` graffiti: Bytes32 proposer_slashings: ProgressiveList[ProposerSlashing] attester_slashings: ProgressiveList[AttesterSlashing] attestations: ProgressiveList[Attestation] # Removed `deposits` voluntary_exits: ProgressiveList[SignedVoluntaryExit] sync_aggregate: SyncAggregate bls_to_execution_changes: ProgressiveList[SignedBLSToExecutionChange] signed_execution_payload_bid: SignedExecutionPayloadBid payload_attestations: ProgressiveList[PayloadAttestation] parent_execution_requests: ExecutionRequests ``` #### Validation Changes **Block processing modifications:** 1. Remove the [`process_eth1_data()`](https://github.com/ethereum/consensus-specs/blob/84454a9d57f4f49f74c78e9f375347baf30474f2/specs/phase0/beacon-chain.md#eth1-data) call from [`process_block`](https://github.com/ethereum/consensus-specs/blob/84454a9d57f4f49f74c78e9f375347baf30474f2/specs/gloas/beacon-chain.md#block-processing) 2. Remove the `assert len(body.deposits) == 0` check from [`process_operations`](https://github.com/ethereum/consensus-specs/blob/84454a9d57f4f49f74c78e9f375347baf30474f2/specs/gloas/beacon-chain.md#modified-process_operations) **Epoch processing modifications:** 1. Remove the [`process_eth1_data_reset()`](https://github.com/ethereum/consensus-specs/blob/84454a9d57f4f49f74c78e9f375347baf30474f2/specs/phase0/beacon-chain.md#eth1-data-votes-updates) call from [`process_epoch`](https://github.com/ethereum/consensus-specs/blob/84454a9d57f4f49f74c78e9f375347baf30474f2/specs/gloas/beacon-chain.md#modified-process_epoch) **Honest validator modifications:** 1. Remove the Eth1 data polling and [`get_eth1_vote`](https://github.com/ethereum/consensus-specs/blob/84454a9d57f4f49f74c78e9f375347baf30474f2/specs/electra/validator.md#deposits) machinery; proposers no longer include an `eth1_data` vote in their blocks #### BeaconState Modifications The `BeaconState` container is modified to remove the following fields: **Removed fields:** - `eth1_data: Eth1Data` - `eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]` - `eth1_deposit_index: uint64` - `deposit_requests_start_index: uint64` The removal is expressed by setting the corresponding `active_fields` bits of the `ProgressiveContainer` to `0`. The updated `BeaconState` structure becomes: ```python class BeaconState( ProgressiveContainer(active_fields=[1] * 8 + [0] * 3 + [1] * 17 + [0] + [1] * 17) ): genesis_time: uint64 genesis_validators_root: Root slot: Slot fork: Fork latest_block_header: BeaconBlockHeader block_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] state_roots: Vector[Root, SLOTS_PER_HISTORICAL_ROOT] historical_roots: List[Root, HISTORICAL_ROOTS_LIMIT] # Removed `eth1_data` # Removed `eth1_data_votes` # Removed `eth1_deposit_index` validators: ProgressiveList[Validator] balances: ProgressiveList[Gwei] randao_mixes: Vector[Bytes32, EPOCHS_PER_HISTORICAL_VECTOR] slashings: Vector[Gwei, EPOCHS_PER_SLASHINGS_VECTOR] previous_epoch_participation: ProgressiveList[ParticipationFlags] current_epoch_participation: ProgressiveList[ParticipationFlags] justification_bits: Bitvector[JUSTIFICATION_BITS_LENGTH] previous_justified_checkpoint: Checkpoint current_justified_checkpoint: Checkpoint finalized_checkpoint: Checkpoint inactivity_scores: ProgressiveList[uint64] current_sync_committee: SyncCommittee next_sync_committee: SyncCommittee latest_block_hash: Hash32 next_withdrawal_index: WithdrawalIndex next_withdrawal_validator_index: ValidatorIndex historical_summaries: List[HistoricalSummary, HISTORICAL_ROOTS_LIMIT] # Removed `deposit_requests_start_index` deposit_balance_to_consume: Gwei exit_balance_to_consume: Gwei earliest_exit_epoch: Epoch consolidation_balance_to_consume: Gwei earliest_consolidation_epoch: Epoch pending_deposits: ProgressiveList[PendingDeposit] pending_partial_withdrawals: ProgressiveList[PendingPartialWithdrawal] pending_consolidations: ProgressiveList[PendingConsolidation] proposer_lookahead: Vector[ValidatorIndex, (MIN_SEED_LOOKAHEAD + 1) * SLOTS_PER_EPOCH] builders: ProgressiveList[Builder] next_withdrawal_builder_index: BuilderIndex execution_payload_availability: Bitvector[SLOTS_PER_HISTORICAL_ROOT] builder_pending_payments: Vector[BuilderPendingPayment, 2 * SLOTS_PER_EPOCH] builder_pending_withdrawals: ProgressiveList[BuilderPendingWithdrawal] latest_execution_payload_bid: ExecutionPayloadBid payload_expected_withdrawals: ProgressiveList[Withdrawal] ptc_window: Vector[Vector[ValidatorIndex, PTC_SIZE], (2 + MIN_SEED_LOOKAHEAD) * SLOTS_PER_EPOCH] ``` ## Rationale ### Timing of Removal The fields are removed after EIP-6110 finalization to ensure: - All pending deposits from the legacy system have been processed - No validator can be affected by the removal - The transition is complete and irreversible - State consistency is maintained across all honest nodes ## Backwards Compatibility Because `BeaconBlockBody` and `BeaconState` are `ProgressiveContainer`s, the proposed changes do not affect the generalized indices of remaining fields. Merkle-proof verifiers of unrelated fields continue to work. Historical blocks and states retain their original schemas and remain verifiable. ## Security Considerations The removal of legacy fields poses minimal security risk because: - The fields are already unused after EIP-6110 finalization - All deposits are processed through the new EIP-6110 mechanism ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md).