EIP-8367: Balance sunset for retired BLS validators

EIPs EIPs core
1

Discussion topic for EIP-8367: Add EIP: Balance sunset for retired BLS validators by ensi321 · Pull Request #12099 · ethereum/EIPs · GitHub

Companion to EIP-8365 ( EIP-8365: BLS withdrawal credential retirement ). Where 8365 retires 0x00 validators from duties and freezes their balances, this EIP proposes the second stage: each retired 0x00 balance is clamped to a ceiling that declines linearly to zero across a published multi-year window. Rotating credentials to 0x01 at any point stops the reduction and releases the full remaining balance through the sweep.

Goal state: by the post-quantum switch, every 0x00 balance is zero, so removing BLSToExecutionChange and the registry entries deletes nothing anyone owns. The schedule constants are plain spec parameters, revisitable at each fork in between if the PQ timeline moves.

Feedback especially wanted on: window length (fairness versus carry), the schedule constants, and the property-norm question (rule-based balance reduction with years of notice versus freezing funds indefinitely, discussed in the Rationale).

EIP-8433: Retire 0x00 validators
2

EIP-8365 effectively handles the Stage 1 necessity of deprecating 0x00 credentials for PQ readiness. However, advancing this stage 2 EIP (balance resolution) forces operators like myself—who have lost withdrawal mnemonics but retain active validator keys—into a dead end.

In the hackMD data on the current 0x00 population, the debate between “Sunset to Zero” and “EL Claim Contract” highlights a gridlock. The former initiates Ethereum’s first non-fault confiscation of honest stake. The latter, in its raw form, either introduces a PQ vulnerability (by relying on the BLS pubkey) or creates an EVM engineering nightmare (attempting to map historical EL deposit addresses on the CL).

I propose a third path: The Optimistic Registry (An Iterated Option F).

Instead of forcing the Consensus Layer to read historical execution data or parse complex cross-layer proofs, we can leverage the existing community-driven DeprecateBLS(dot)com initiative as an off-chain data layer to construct a mathematically sound, trustless Merkle root for an EL Claim Contract.

To satisfy core protocol security requirements and bypass the Principal-Agent problem, this registry would operate under three strict constraints:

  1. Off-Chain Dual-Signature Collection: To be included in the claim registry, an operator must provide at least two verifiable signatures off-chain: one from the Validator Signing Key (proving operational control) and one from the Original Deposit EL Address via standard ECDSA (proving economic ownership). We can also imagine inclusion of more complex situations with multiple depositors. This mathematically prevents malicious node operators from hijacking delegator funds, entirely sidestepping the primary objection to validator-key recovery.

  2. Deterministic State Generation: The community initiative does not provide a trusted, black-box Merkle root. It publishes the raw, dual-signed dataset alongside an open-source state generation script. Any client team, auditor, or independent node runner can execute the script locally, verify the signatures, resolve fractional/proxy deposit edge cases off-chain, and independently arrive at the exact same Merkle root.

  3. On-Chain Challenge Period: The compiled Merkle root is published to an EL smart contract 6 months prior to the L-star hard fork. This serves as a public challenge window. If a fraudulent claim or proxy-contract conflict is detected, the true owner has ample time to flag it before the state is finalized into the client software.

By adopting this Optimistic Registry, the protocol achieves its primary goal—zero legacy 0x00 debt carried forward on the CL post-L-star—without crossing the Rubicon of burning honest collateral. The heavy lifting of edge-case resolution is handled by humans off-chain, while the protocol only enforces the finalized, mathematically proven state.

3

Some stats to help the discussion:

  • 0 of 14,209 validators were created by partial deposits. Every one began with a single complete 32 ETH deposit, so the creating deposit is unambiguous in 100% of cases.
  • There are currently 7 0x00 validators with more than one deposit (all seven are duplicate deposits from the same deposit address i.e. 2 × 32 ETH)
  • There is only 1 validator that has 2 different deposit addresses (both depositing 32 ETH).

DeprecateBLS.com is advocating a validator-key-signed claim to a nominated address, not defaulted payout-to-depositor. So adding a rule-based alternative to (retire, drain, remove) using BLSToExecutionChange by ETHStaker community

Glad to hop on a call to contribute to this and discuss options @ensi321

p.s.
I’m the initiator of deprecatebls.com

1 Like
4

Couple thoughts:

  • Signing key + original EL deposit EL address does not equal to owner. Strong evidence but not proof. It is possible that in a delegated staking setup the operator holds both the signing key and the deposit comes from operator’s wallet.
  • Not sure how the challenge part works. If the challenge is social layer, then it is trusted, and this trust is leaked into the protocol. If it is cryptographic, then the challenger must hold the withdrawal key, but then this person doesn’t need this whole registry at all. He can switch to 0x01 anytime he wants. So this part I think is either trusted or redundant.
  • This idea seems pretty complex, I am not sure how much time between getting everyone onboard, build it, and 6 months before L-star.
  • The registry requires voluntary action from validators. What happens at L-star when a validator never took action? If we drop their balance, it’s exactly what this EIP wants to prevent. As such, this idea sounds like a recovery layer on top of this EIP instead of an alternative.
5

As proposed by Andy, I suggest we hop on to a call and discuss possible paths forward to tackle the lost-mnemonic cases. At this point it is simply hard to accept a solution that relies on simply nullifying the remaining 0x00 stake after deprecation. There are numerous options to debate first, before moving that EIP any further.