The request was boring: return one blob by versioned hash from canonical Gloas slot 116,671. All 14 Lighthouse nodes answered that the block was pre-Deneb. The same fleet served the same API route for a Fulu control, while every reachable Grandine, Lodestar, Nimbus, Prysm and Teku node returned the expected 131,072-byte blob.
I asked Lighthouse for two blobs from one canonical Fulu block, listing commitment 6 before commitment 0. Every reachable Lighthouse supernode returned them as [6, 0]. That sounds like obedient filtering, but the Beacon API says the response follows the commitments in the block, so the correct order was [0, 6].
One beacon_api_eth_v3_validator_block observer made Ethereum payloads look four times larger than they were.
In a two-hour mainnet sample, 161 prepared blocks from that path matched the canonical execution payload for their slot. The prepared-block rows reported 213,035 transaction entries. The matching canonical blocks contained 51,254 transactions: a 4.156x multiplier.
beacon_api_eth_v1_events_contribution_and_proof looks like a tempting sync committee participation table. It has a slot, a subcommittee index, an aggregator, and the aggregation_bits for that subcommittee. If you sum those bits, though, you do not get sync committee participation. You get the same vote surface counted again and again.
beacon_api_slot sounds like the table you would reach for when you need a slot count. That is the trap. On Jul 5 UTC, mainnet had 7,200 scheduled slots and 7,165 canonical blocks. The raw beacon_api_slot table had 2,550,257 rows and 712,240,161 attestation-count units.
That is not Ethereum having 712 million canonical attestations in one day. It is an observer rollup doing exactly what the schema says, with a name that invites lazy queries.
beacon_api_eth_v1_beacon_blob looks like a blob table until you count it. Across the seven complete UTC days from Jun 26 through Jul 2, it had 5,557,049 rows. The canonical chain had 187,031 blobs in the same window.
That was not a hidden 30x blob burst. It was the same blob commitments being observed over and over by Xatu's Beacon API sentries.
beacon_api_eth_v1_proposer_duty looks block-ish if you only read the name. It has slot, epoch, proposer_validator_index, and a timestamp from the client that fetched it. That is enough rope to build a very wrong proposed-block counter.
The table is not a block feed. From Jun 27 through Jul 3 UTC, it had 1,491,952 raw rows for 50,400 scheduled slots, and the duty for the last slot in each epoch first appeared about 6m12s before that slot could produce a block.
A 65,534-block Ethereum reorg did not happen last week. Caplin still said it did, at least through the Beacon API chain_reorg event stream.
The name is the trap. beacon_api_eth_v3_validator_block has a slot, an execution block number, gas used, transaction count, blob gas, and payload values. It looks like a block table.
It is not a block table in the canonical sense. Across two complete UTC days, I joined Xatu's raw /eth/v3/validator/blocks/{slot} rows to the eventual canonical block for the same slot. Only 82 of 195,448 joined rows matched the canonical execution payload shape. In 14,312 of 14,341 canonical slots, not one observed v3 row matched the payload that actually landed on chain.
block and head sound even cleaner than block_gossip. A block event says the beacon node saw a block. A head event says fork choice moved to it. If those rows show up hours after the slot started, the first question should not be "did Ethereum propagate blocks hours late?" It should be "what denominator did I just use?"
The denominator was the row.