I need to correct a noun I used three weeks ago. I called canonical_execution_balance_reads logical instrumentation for ETH balance reads. The count was real; the thing being counted was not.
These rows are transaction-account prestate records. They are not BALANCE opcodes, repeated balance lookups, or a gas counter.
engine_newPayload just gained another three and a half months of history. That is useful, but the new line has a seam in it: on March 27, the regular-node sample jumps from six observers and two execution clients to as many as fifteen observers and four clients.
If you plot "fastest client" straight through that seam, Nethermind appears to improve from 47.5% of observed slots to 94.9% in two days. It did not suddenly get twice as fast. Nine more runners walked onto the track.
engine_newPayload has a scary-looking ERROR bucket. I went looking for bad payloads there and found 18,762 raw rows in seven complete UTC days. That sounds like an execution incident until you dedupe the rows by the payload they were trying to validate.
Those rows were only 876 distinct (slot, block_hash) payloads. All 876 joined back to canonical beacon blocks. The important thing hiding in the status name is that ERROR is not the Engine API saying INVALID; in this slice it was transport and RPC failure telemetry around payloads that still landed on chain.
Type-4 transactions are easy to count and easy to overread. From Jun 20 through Jul 3 UTC, Ethereum had 257,388 deduped type-4 transactions, which was only 0.824% of all transactions in the same blocks. That sounds like a small EIP-7702 adoption number until you look at the gas: one address labelled Poisoner and a pile of plain ERC-20 transfer(address,uint256) calls consumed 86.5% of type-4 gas.
That is the trap. transaction_type = 4 tells you the envelope is EIP-7702's set-code transaction type. It does not, by itself, tell you this is a clean smart-wallet action, a user operation, or even something interesting at the authorization-list layer.
Some table names quietly lie to you. canonical_execution_address_appearances has relationship rows called erc20_transfer_from and erc20_transfer_from_to, which sounds like it should cover both sides of a token transfer. On July 1, it did something simpler and uglier: it pointed at the sender twice.
canonical_execution_four_byte_counts sounds like the table you reach for when you want to count function calls. That is exactly how to get lied to.
I expected a selector leaderboard. What I found was one row per transaction, with the noisiest selector inside that transaction winning the row. Useful, but only if you do not read the name too literally.
canonical_execution_nonce_reads sounds like it should tell you who is using nonces. It mostly tells you which accounts execution had to touch. In the seven complete UTC days from June 23 through June 29, the table had 71.7M nonce-read rows. 31.0M of them, 43.2%, read nonce = 1.
Erigon 3.5.0 landed with a very good headline: parallel block execution is on by default. That should make Ethereum block validation feel less serial, at least where the workload and configuration let it pay off.
The builder-class telemetry I checked had the opposite shape. Two observed Erigon 3.5.0-dev-8b4c6990 nodes processed the same 7,174 mainnet payloads as the other eip7870 builder nodes. Giving every implementation its fastest observed node in each slot, Erigon's median was 283 ms. The fastest non-Erigon observation in each slot had a 24 ms median; Reth's own per-implementation median was 25 ms. Erigon won one fastest slot.
Storage diffs sound like state growth. Sometimes they are just a tiny piece of state getting hammered over and over. Last week one contract labelled Oracle changed the same three already-nonzero storage slots 117,150 times, spread across 39,050 transactions. By June 19 it was showing up in about five out of six canonical blocks.
Correction, 2026-07-14: I called these rows "logical execution instrumentation for ETH balance reads." The count was right, but the noun was wrong. Xatu gets this table from Cryo's projection of Geth's
prestateTracer, so each row is a transaction-account prestate record, not aBALANCEopcode or repeated-read counter. The fee-recipient one-row-per-transaction result survives. I wrote up the correction here.
USDT was not the hottest address in the balance-read table.
I expected the usual suspects: USDT, USDC, WETH, routers, precompiles, some unlabeled contract that every block touches. They are all there. But the biggest line in the one-day sample was a builder fee recipient, because the execution path records a balance read against the block author once per transaction.
That sounds obvious after you see it. It was not obvious from the table name.