EIP-8367's 64 ETH ceiling is already underwater

A draft proposal to sunset Ethereum's old BLS withdrawal credentials starts from a neat premise: set the initial balance ceiling at 64 ETH, safely above every affected validator, then lower it gradually. Mainnet has already broken that premise. Six active 0x00 validators now hold more than 64 ETH, with a combined 31.31 ETH above the proposed cap.

This is not an argument for or against burning abandoned validator balances. It is a narrower catch in the draft's mechanism. EIP-8367, which is still an open pull request, says the highest observed 0x00 balance is "well below 64 ETH" and that starting there avoids an abrupt reduction. The current maximum is 71.10 ETH.

The old credential tail

Withdrawal credentials beginning with 0x00 are the original BLS-controlled format. Capella added BLSToExecutionChange, a one-way operation that lets the withdrawal key set an execution address. The remaining cohort is small but stubborn: at mainnet epoch 468,233, I found 9,253 latest-state 0x00 validators holding 342,541 ETH. Of those, 9,082 were active and 171 were already withdrawable but had not changed credentials.

A pair of draft EIPs would retire that tail. EIP-8365 would force the active validators through the exit queue while keeping credential changes available. EIP-8367 would then clamp every remaining 0x00 balance to a ceiling that declines from 64 ETH to zero over a multi-year schedule. Rotate the credentials and the normal withdrawal sweep pays the remaining balance; do nothing and the ceiling eventually burns it.

The queries below take each validator's latest credential, filter to 0x00, then resolve balance and status at one exact epoch. I ran them as two bounded steps because these raw tables are distributed; pushing the first result into the second as literal indices avoids a distributed-subquery trap. The argMax calls are deliberate because both tables can retain several processed versions of the same semantic row.

-- Step 1: resolve the current 0x00 index set.
SELECT index
FROM default.canonical_beacon_validators_withdrawal_credentials FINAL
WHERE meta_network_name = 'mainnet'
GROUP BY index
HAVING startsWith(
    argMax(withdrawal_credentials, tuple(epoch, updated_date_time)),
    '0x00'
)
ORDER BY index;

-- Step 2: substitute those 9,253 bounded indices as <bls_indices>.
SELECT
    index,
    argMax(balance, updated_date_time) / 1e9 AS balance_eth,
    argMax(effective_balance, updated_date_time) / 1e9 AS effective_eth,
    argMax(status, updated_date_time) AS status
FROM default.canonical_beacon_validators FINAL
WHERE meta_network_name = 'mainnet'
  AND epoch = 468233
  AND index IN (<bls_indices>)
GROUP BY index
HAVING balance_eth > 64
ORDER BY balance_eth DESC;

It returns six validators, all active_ongoing, at 67.37, 68.14, 68.25, 70.16, 70.29, and 71.10 ETH. Their effective balances are still 32 ETH; the extra ETH is consensus balance above the effective-balance cap, not extra voting weight. A second path through mainnet.fct_validator_balance_daily FINAL returned the same six over-cap validators on August 12 and 31.3069 ETH above 64, versus 31.3095 ETH in the newer raw snapshot. The small difference is normal reward accrual between snapshots.

The first clamp is not gradual

The draft's ceiling function returns 64 ETH before and at SUNSET_START_EPOCH. Once the ceiling begins falling, the epoch processor reduces any larger 0x00 balance to the current ceiling. For these six validators, the first effective clamp would therefore remove roughly 31.31 ETH immediately, then continue with the advertised linear decline.

That immediate cut is tiny beside the cohort's 342,541 ETH total, about 0.009%. But scale is not the bug. The draft explicitly uses 64 ETH because it believes nobody is above it, and from that assumption claims every validator gets the same continuous decline. Both statements are now false. On July 1 the same six were already over the line, with a maximum of 71.02 ETH, so this is not a head-state wobble either.

There is another useful clue in the liveness data. Four of the six attested on August 12 and each delivered more than 99.1% of duties since July 18. Two delivered none during that window. A simple "lost validators are being drained" story does not describe the whole over-cap set: most of the balance that breaks the initial ceiling belongs to validators that are still plainly operating.

A cheap fix while it is still a draft

The proposal can repair this without changing its broader policy. Set SUNSET_INITIAL_CEILING from a state-derived bound at activation, choose a constant with real headroom, or admit that the first clamp includes an intentional one-off reduction. The first option complicates consensus; the second is boring and predictable; the third is honest but weakens the gradual-start rationale.

There is time to choose. EIP-8367 is an open draft with its start and end epochs still marked TBD, and it currently has requested changes. The important thing is to stop carrying a false physical assumption into the specification. Six validators is a small edge case. Consensus rules are where small edge cases become expensive ones.