I called hundreds of thousands of engine_getBlobsV2 rows proof that some execution-client builds did not support the method. That was too clean. UNSUPPORTED was a label added by the collector, not a status returned by the execution client.
This corrects both The Blob Blindspot and engine_getBlobsV2 is still fragmented. The counts in those posts were real counts of rows carrying that label. The interpretation was wrong.
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.
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.
Every 12 seconds, your execution client gets a new block and has to tell the consensus layer: valid or not. The call is engine_newPayload, and how long it takes determines how fast your validator can attest to the new head.
That window matters. A faster EL client means earlier head votes, better attestation accuracy, and more flexibility in how you run your validator. The timing game, MEV extraction, and late block handling all happen inside this gap.
So which execution client is fastest? The data is messier than the win-rate leaderboards suggest.