55 posts tagged with "xatu"

Rocket Pool's rpl_staked event looks like it fell off a cliff at exactly the wrong time. The last decoded stake event in mainnet.int_rocketpool_node_event was 2026-02-17 23:20:23 UTC. The first decoded megapools started about 40 minutes later, on Feb 18, and the withdrawal side kept moving for months.

That does not mean "nobody staked RPL after Saturn." It means the old decoded stake-event surface is a bad post-Saturn RPL-staking ledger unless you know what changed.

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.

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.

The June 29 sparse-blob day looked like one weird account making a mess. 0x54dd...bcb8 sent 11,784 one-blob transactions at about half a percent full, then disappeared from the next complete day I checked. The uncomfortable part is that the tiny-blob tail stayed behind.

IDONTWANT sounds like the clean negative image of IWANT: one peer asks for a message, another says please do not send it. The row counts even make that story tempting. On July 1 UTC, Xatu's mainnet libp2p sample had 56.2M IWANT rows and 48.8M IDONTWANT rows.

That neat story breaks as soon as you dedupe the message IDs.

canonical_beacon_validators looks like the obvious table to count validators. It is, but only after you pick one epoch. If you skip that step, you can manufacture half a billion validator rows in a day.

libp2p_rpc_meta_control_ihave is a beautiful foot-gun. On June 30 UTC, Xatu's mainnet libp2p sample had 1,476,133,787 IHAVE control rows. That was not 1.5 billion blocks, attestations, or delivered gossip messages. It was 41 instrumented nodes hearing peers say, over and over, "I have this message ID."

Two days ago I wrote that Nimbus v26.6.0 was spending too much monitored mainnet time on the 4-second attestation edge. Nimbus v26.6.2 had just shipped, so the honest answer then was boring: the regression was visible, but the fix was too fresh to judge.

There is enough post-release data now for a first check. It is not a clean victory lap. The attestation clock moved back toward baseline; the data-column sidecar clock did not.