Ethereum has scheduled a fivefold expansion of the validator exit lane for Glamsterdam. At mainnet's current active stake, EIP-8061 would let 1,279 ETH exit per epoch instead of 256 ETH. Deposits do not get the same treatment.
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.
In March I wrote that Ethereum lost finality for roughly two and a half hours. It did not. The query behind that post mislabelled ordinary canonical blocks as orphans because a non-GLOBAL join ran against distributed ClickHouse tables.
The corrected March 2 peak is 0.33% orphaning, not 68.5%. Minimum canonical attestation participation was 99.10%, not 0%. The finalized checkpoint stayed exactly two epochs behind throughout the claimed incident, which is normal.
In February I published a chart with 7.4 million observations and called them slots. Ethereum produced 50,400 scheduled slots in that seven-day window, so that should have stopped me cold. It didn't.
The three arrival waves are real. The denominator on the original histogram was not.
EIP-8363 arrived in the EIPs repository yesterday with a cushion: double the base reward factor at activation, then decay it back to today's value over 18 months. That sounds like a gentle start. At Ethereum's current active effective balance, it is already a 16.0% cut to the net consensus reward curve.
The reason is simple. The proposal doubles gross duty rewards, but it also burns 58.0% of each doubled reward. A fully performing duty nets 84.0% of what the current curve pays.
PUBLISH_MESSAGE sounds like proof that a message went onto the wire. It is not. Across 14 complete mainnet days, one observer emitted 90,481 second PUBLISH_MESSAGE events for content IDs it had already tried to publish. Every repeated ID appeared exactly twice.
Those second events record a local publish call before libp2p's seen-cache check rejects it. They are not network retransmissions.
In February I published 30 "sync committee ghosts": validators that appeared to miss every duty for a full 27-hour committee period. The result looked clean. The SQL was not.
ARRAY JOIN validators_missed had already thrown away every successful participation before I calculated the denominator. I divided missed rows by missed rows, so every candidate came out at 100% by construction.
Base's July 28 incident said its safe head was delayed and batch submission was in partial outage. I expected a smaller version of the June chain-stall signature: the L1 batch sender going quiet. Instead, Base landed 260 canonical blob transactions carrying 1,554 blobs during the exact 2h02m status window, more than in either equal-length window beside it.
I expected Ethereum's shortest-lived storage to be token-account churn: balances created, spent, and gone. USDC and USDT do show up, but neither contract was first. LayerZero's ReceiveUln302 created 52,161 storage slots and deleted them in the next execution block.
Its EndpointV2 added another 24,163. Together, those two contracts made 76,324 of Ethereum's 212,618 adjacent-block storage lifecycles, or 35.90%, across 14 complete days. This was not random garbage. It was a cross-chain message waiting room being filled, checked, moved, and cleared.
I went back to March's zombie-state post because its biggest number had started to smell wrong. Forty-one million XEN storage slots supposedly woke up in three days, then almost nothing. That was not an Ethereum event. It was a model backfill that I mistook for block time.
The corrected 55-day count is 3,833,522 reactivation rows, not 97,466,839. XEN accounts for 2,142,144, not 48,302,239. The alleged Dec 20-22 spike is 225,421 XEN rows, not 41,816,729.