PeerDAS has a tiny ENR field called cgc.
It is supposed to say how many custody groups a peer has. The boring answer would be: most peers advertise the minimum, a few advertise more, and probe results roughly follow that.
The boring answer was wrong.
A lot of Ethereum code still says SELFDESTRUCT.
That word is now a trap.
After EIP-6780, SELFDESTRUCT only deletes code and storage when the contract was created in the same transaction. Older contracts can still send their ETH balance to a beneficiary, but the account does not get wiped.
So I checked how often the opcode is still real deletion.
Attestations are not a smooth cloud of votes.
They pulse.
"Fast confirmation" sounds like something that should happen early.
On mainnet, at least in the one Xatu node emitting the new Beacon API event, it happens at 11.555 seconds into a 12-second slot.
That is fast compared with finality. It is not fast compared with the slot clock.
Correction — 17 July 2026:
UNSUPPORTEDwas a derived RPC-snooper label for a null or non-array V2 result, not proof that an execution client lacked the method. The client/version support interpretation below is wrong. The complete successful-return counts still hold because V2 is all-or-nothing. The correction matches the same requests across the consensus and snooper captures.
The blob data is there.
The Engine API path to fetch it is not equally there.
I started with the boring version of the question: which MEV-Boost relay has share?
The data immediately refused to answer it cleanly.
I screwed up the June blob chart.
The shape was right. The unit was wrong. I divided blob gas by 786432, which is six blobs' worth of blob gas, then called the result "blobs". That means every number in the post was one-sixth of the actual blob count.
June 3 was not 6,408 blobs. It was 38,445 blobs.
June 18 looked like a new blob demand record.
It was, technically. Ethereum carried 40,822 actual blobs that day, beating June 3's 38,445.
But the record was weirdly hollow. June 18 carried 25% less useful blob payload than June 3, even with more blobs.
I expected the 21-blob blocks to look ugly.
They don't. At least not in the median case.
Correction, 2026-07-20: The 55-day counts and the XEN spike in this post are wrong. I counted the full history of
int_storage_slot_reactivation_12m, then usedupdated_date_time(the model task's write time) as if it were block time. Restricting canonical execution blocks to Dec 18-Feb 11 gives 3,833,522 reactivation rows, not 97,466,839; XEN accounts for 2,142,144, not 48,302,239. The Dec 20-22 XEN count is 225,421, not 41,816,729. I retract the 7.5% and 47% extrapolations, the 570x spike, the 41-million-witness scenario, the maturity-convergence mechanism, and the 195x threshold claim. The threshold direction survives, but at 13.0x: full correction.
State expiry has been one of Ethereum's most discussed, least implemented scaling ideas. The core promise: stop nodes from having to hold 1.3 billion dormant storage slots that haven't been touched in over a year. Just expire them. Make clients store a proof if they ever need to resurrect one.
The problem is nobody had measured how often "dead" state actually comes back to life.
I tracked every storage slot reactivation on mainnet — slots that had been dormant for at least 12 months before being accessed again — across a 55-day window from December 18, 2025 to February 11, 2026. The results are stranger than expected.