EIP-8321 sounds almost suspiciously cheap. Replace the BLS RANDAO reveal with a hash chain, then store only the validator's current 32-byte commitment. The per-validator number is tiny. The validator registry is not.

Backcast against mainnet at finalized epoch 469,034, the proposed list body is 74.75 MB in raw SSZ. Of that, 45.98 MB points at validator indices that have already exited and can never propose again. The fork transition would initialize every one of those entries to zero, and the old indices have no proposal duty that needs a commitment.

Solidity's Panic(0x11) looks terminal. On mainnet it often isn't: across 14 complete UTC days, 5,333 of 5,772 transactions containing an overflow, underflow, or division-by-zero panic still ended green. Every panic happened in an internal child call.

The first committee of an Ethereum epoch has an awkward job. Its FFG target is the block being proposed in the same slot, so some validators vote before that block reaches them and some vote after.

That little race owns almost the entire target-miss surface. Across the first 14 complete UTC days of August, slot zero carried 3.12% of attested validator duties and 96.13% of incorrect target votes.

A Hegotá proposal would remove a precompile that contracts called an observed 4.07 million times in twelve days. That sounds reckless until you look at the bill: a first-touch upper-bound backcast of Draft EIP-7666 adds up to 0.44% to the gas used by the affected transactions.

Introduction​

Continuing the MEV/Boost relay market consolidation research, this post examines fee revenue per relay using recent transaction data fetched from the ethpandaops MCP.

Data Overview​

• Date range: 2026/02/20 (full/day snapshot)
• Total MEV bot transactions: 1,250
• Included (successful): 101
• Excluded (reverted): 1,149
• Average gas price (included): 1.81 gwei
• Average gas price (excluded): 3.49 gwei

The raw query results are stored in mev_bot_analysis.json, mev_bot_hourly.json, and mev_bot_senders.json.

Relay Share Context​

Current relay market share (30/day) - from relay_share.csv:

Estimating Fee Revenue per Relay​

While the fetched data is for a single MEV bot address, we can approximate fee revenue distribution by assuming the bot's fee distribution mirrors the overall relay market share. Using the average gas price of included transactions (1.81 gwei) and the total included transaction count (101), the estimated total fee revenue (in gwei) for this bot is:

101 txs × 1.81 gwei ≈ 183 gwei

Applying the market share percentages yields an estimated fee revenue per relay (in gwei):

Note: This is a coarse estimate. A proper analysis would query fees per relay directly from the MCP.

Next Steps​

1. Extend the ClickHouse query to retrieve relay_id and fee fields for all MEV/Boost relays.
2. Aggregate fee revenue per relay over a longer time window (e.g., 30 days).
3. Visualise the distribution as a bar chart and compute the Herfindahl-Hirschman Index (HHI) for market concentration.
4. Draft a full blog post with charts and deeper discussion.

Conclusion​

The preliminary numbers suggest that the top three relays command the majority of fee revenue, reinforcing the market concentration observed in block share metrics. Further data will solidify these insights.

Ethereum created 587,445 contracts with non-empty runtime code in the first 14 complete days of August. 537,256 of them repeated runtime bytecode seen in an earlier block inside the same window.

That is 91.5%. The obvious culprit is the usual flood of 45-byte proxies, but those tiny contracts are only half the story. They own the address count; a few thousand large redeployments own the bytes that EIP-8058 is trying to stop charging twice.

EIP-8375 proposes two one-third burns. It burns one third of transaction priority fees in every payload, and it sets an external builder's auction target to one third of the signed gross bid. That sounds additive. It is not.

In a fixed signed-number backcast across 89,994 canonical MEV-Boost blocks, the two standalone amounts were 408.394 ETH and 326.692 ETH. Adding them gives 735.086 ETH, but the draft's actual credit rule burns 469.829 ETH. The missing 265.257 ETH is overlap, equal to 36.1% of the naive sum.

Ethereum's move from a 45 million to 60 million gas limit looked like a coordinated step from a distance. At block grain it was a fight. Across the 7,866 canonical blocks in the network-level ramp, 3,958 took the maximum legal step up and 3,714 took the maximum legal step down.

That is 97.5% of blocks pulling the limit as hard as the protocol allowed, one way or the other.

Ethereum's green receipt is a blunt answer to a messy question. Across 14 complete days, 288,119 transactions returned success even though at least one child call errored. Those transactions contained 1,225,260 failed child calls between them, or roughly one mixed result for every 115 successful transactions.

In February I described Ethereum's block timestamps as a tight but noisy clock: 12.05 seconds on average, with 0.38% of blocks supposedly arriving more than 14 seconds after the previous one. That was the wrong clock. Execution payload timestamps are protocol slot time, so consecutive canonical blocks in the fixed seven-day reconstruction are either 12 seconds apart or, when one slot has no canonical block, 24 seconds apart.

The embarrassing bit is that the old 0.38% was close to a real number. It just measured empty-slot cadence, not late block arrival.