EIP-8015 Removal of Deposit and Eth1 Data Fields (Remove `deposit` and `eth1data` fields)
Hegota Scheduled for Inclusion · Consensus & staking · EIP status Draft · created 2025-08-22
Removes the old deposit fields and the Eth1 data voting mechanism that are no longer used from the beacon block body and beacon state. This change cleans up what was left over after EIP-6110 moved deposit processing to the execution layer.
Why it is needed
To become a validator on Ethereum, you must make a deposit, which locks up funds. Previously, these deposit records accumulated on the execution layer (the old Eth1 chain), and block proposers on the consensus layer looked at those records and voted on them to bring them into the beacon chain. EIP-6110 moved this processing into the execution layer and removed the proposer vote. During the move, however, the old and new methods had to coexist. In the Fulu fork, the old deposit processing was already removed, but empty fields and the Eth1 data voting mechanism remain in the block body and beacon state. Once all the old deposits have been processed, these fields will never be used again. This EIP clears out those leftovers, which simplifies validation code and removes the technical debt from the transition period.
What changes
Today
- The eth1_data and deposits fields remain in the beacon block body. After Fulu, deposits must always be empty, but it still takes up space.
- Four fields remain in the beacon state: eth1_data, eth1_data_votes, eth1_deposit_index, and deposit_requests_start_index.
- Proposers include an Eth1 data vote in every block, and clients run vote reset code at the end of every epoch.
After EIP-8015
- Two fields are removed from the block body. Proposers no longer include an Eth1 data vote.
- Four fields are removed from the beacon state, and all calls to the related processing functions disappear.
- The Merkle tree positions of the remaining fields stay the same, so existing Merkle proof verifiers keep working without changes.
Who is affected
- Client teams: Removes the Eth1 data polling, voting, and epoch reset code, along with the empty deposits check. With the deprecated validation paths gone, the code becomes simpler.
- Validators (stakers): It activates only after all old-style deposits have been processed, so no validator is affected. New deposits continue to be processed the EIP-6110 way.
- Merkle proof verifier developers: The generalized indices of the remaining fields do not change, so there is no need to modify existing proof verification code. Past blocks and states can still be verified with the original schema.
- Ordinary users: This change cleans up data that is already unused, so there is no noticeable difference.
In depth
Background and Purpose
EIP-6110 moved validator deposit processing to the execution layer as part of the EIP-7685 request system. As a result, the mechanism by which proposers on the consensus layer voted on Eth1 data to pull in deposits was no longer needed. During the transition, however, the old method (the deposits and eth1_data fields) and the new method remained side by side. The Fulu fork removed the old deposit processing and required body.deposits to be empty. This EIP removes the remaining deposits and eth1_data block body fields, the Eth1 data voting mechanism, and the unused BeaconState fields. The original text lists two benefits. Removing deprecated validation logic and code paths simplifies validation, and removing the technical debt left over from the transition period improves maintainability.
Activation Conditions and Choice of Timing
This EIP activates only when both conditions hold (SHALL). First, EIP-6110 must be fully completed, so that state.eth1_deposit_index == state.deposit_requests_start_index holds. This means all deposits that came in through the old method have been processed. Second, Glamsterdam (EIP-7773) must be in effect. The Rationale section gives four reasons for choosing this timing. The pending deposits of the old system have all been processed, no validator is affected by the removal, the transition is finished and cannot be reversed, and all honest nodes keep the same state.
BeaconBlockBody Changes
Remove two fields from the block body: eth1_data: Eth1Data and deposits: ProgressiveList[Deposit]. Following the ProgressiveContainer rules of EIP-7688, the removal is expressed by setting the active_fields bits at those positions to 0. The new bit array is [1] + [0] + [1] * 4 + [0] + [1] * 6. The second position (eth1_data) and the seventh position (deposits) are 0. The remaining fields are randao_reveal, graffiti, proposer_slashings, attester_slashings, attestations, voluntary_exits, sync_aggregate, bls_to_execution_changes, signed_execution_payload_bid, payload_attestations, and parent_execution_requests. The spec link referenced by the source points to the gloas folder of consensus-specs.
Block, epoch and validator processing changes
Two things are removed from block processing. The process_eth1_data() call is removed from process_block, and the assert len(body.deposits) == 0 check is removed from process_operations. Since the field no longer exists, there is no need to check that it is empty. For epoch processing, the process_eth1_data_reset() call is removed from process_epoch. This is the Eth1 data votes updates step in the phase0 spec that the source refers to. In the honest validator spec, Eth1 data polling and the get_eth1_vote mechanism are removed entirely. Proposers no longer include an eth1_data vote in their blocks.
BeaconState changes
Four fields are removed from the beacon state: eth1_data: Eth1Data, eth1_data_votes: List[Eth1Data, EPOCHS_PER_ETH1_VOTING_PERIOD * SLOTS_PER_EPOCH], eth1_deposit_index: uint64, and deposit_requests_start_index: uint64. The first three sat consecutively right after historical_roots, and deposit_requests_start_index sat after historical_summaries. As with the block body, the removal is expressed by setting the active_fields bits to 0. The new bit array is [1] * 8 + [0] * 3 + [1] * 17 + [0] + [1] * 17. The remaining fields (validators, balances, pending_deposits, builders, ptc_window, and others) keep both their names and their order.
Backwards compatibility and security
Because BeaconBlockBody and BeaconState are ProgressiveContainers, removing fields does not change the generalized index of the remaining fields. Only the bits are set to 0, and the positions are kept. As a result, Merkle proof verifiers that check fields that were not removed continue to work without modification. Past blocks and states keep their original schema and can still be verified. The source states that the security risk is minimal. This is because the removed fields are already unused once EIP-6110 is finished, and all deposits are processed only through the EIP-6110 mechanism.
Status and fork inclusion decisions
This EIP is in Draft status, so its content may still change. According to the core developer call records, it was accepted as a Hegota candidate (PFI) at ACDC #183 on 07.23. It moved up to Considered for Inclusion (CFI) for Hegota at ACDC #187 on 09.17. At ACDT #100 on 10.12, it was decided to include EIP-7805 (FOCIL), EIP-8015, EIP-8365 and EIP-8198 together in heze-devnet-2. At ACDC #190 on 10.29, its inclusion in Hegota was confirmed (SFI). The source lists Glamsterdam (EIP-7773) being applied as an activation condition, and the call records show Hegota inclusion as confirmed.