---
eip: 8015
title: Remove `deposit` and `eth1data` fields
description: Remove legacy `deposits` and `eth1_data` fields from `BeaconBlockBody` after EIP-6110 finalization
author: Terence (@terencechain)
discussions-to: https://ethereum-magicians.org/t/eip-8015-remove-legacy-deposit-and-eth1data-fields/25401
status: Stagnant
type: Standards Track
category: Core
created: 2025-08-22
requires: 6110, 7732
---

## Abstract

This EIP removes the legacy `deposits` and `eth1_data` fields from the `BeaconBlockBody` structure 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. This cleanup provides 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. EIP-7732 is in effect

#### BeaconBlockBody Modifications

The `BeaconBlockBody` container is modified to remove the following fields:

**Removed fields:**
- `deposits: List[Deposit, MAX_DEPOSITS]`
- `eth1_data: Eth1Data`

The updated `BeaconBlockBody` structure becomes:

```python
class BeaconBlockBody(Container):
    randao_reveal: BLSSignature
    graffiti: Bytes32
    proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
    attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS_ELECTRA]
    attestations: List[Attestation, MAX_ATTESTATIONS_ELECTRA]
    voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
    sync_aggregate: SyncAggregate
    bls_to_execution_changes: List[SignedBLSToExecutionChange, MAX_BLS_TO_EXECUTION_CHANGES]
    # From EIP-7732
    signed_execution_payload_header: SignedExecutionPayloadHeader
    payload_attestations: List[PayloadAttestation, MAX_PAYLOAD_ATTESTATIONS]
```

#### Validation Changes

**Block processing modifications:**

1. Remove `process_eth1_data()` function calls from block processing
2. Remove `process_deposits()` function calls from block processing  
3. Remove eth1_data voting validation logic
4. Remove legacy deposit validation logic

**State transition modifications:**

1. Remove eth1_data related fields from state transition functions
2. Remove legacy deposit processing from `process_operations()`

#### BeaconState Cleanup

The following fields become unused after activation and MAY be removed in future updates:

- `eth1_data: Eth1Data`
- `eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH]`
- `eth1_deposit_index: uint64`

Note: These fields are kept for historical state root verification but are no longer actively used.

## 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

### Dependency on EIP-7732

This EIP requires EIP-7732 because:

- EIP-7732 already modified the `BeaconBlockBody` structure significantly
- It provides the architectural foundation for simplified block bodies
- The timing aligns with the broader consensus layer improvements

## Backwards Compatibility

## 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).