Glamsterdam SSE event support by client on devnet-6

Networks:

glamsterdam-devnet-6

Time range:

Start 2026-06-25T00:00:00Z

End 2026-07-09T23:59:59Z

glamsterdam gloas epbs xatu devnets

Author

Sam Calder-Mason

Published July 10, 2026 at 06:00 AM UTC

Question

Which consensus clients emit each of the new Glamsterdam (Gloas/ePBS) beacon API SSE events on glamsterdam-devnet-6?

Glamsterdam added six new beacon API server-sent event types, captured into new Xatu tables as beacon_api_eth_v1_events_*. On glamsterdam-devnet-6 (genesis 2026-06-25, Gloas active from epoch 30) every node runs an xatu-sentry subscribed to its beacon node's event stream. Each client is watched by 14 to 18 independent sentries.

With that much redundancy, a zero cell means the client never emitted the event, not that we failed to collect it. One caveat: grandine sentries only came online on 2026-07-02, which still leaves a full week of Gloas-active observation.

client	sentry nodes	observing since	version(s) at window end
grandine	14	2026-07-02	`2.0.4-da4baf15`
lighthouse	16	2026-06-25	`v8.2.0-0daf331`
lodestar	16	2026-06-25	`v1.43.0`
nimbus	14	2026-06-25	`v26.6.2 (b2470f, 4a4ac9, 4973b0)`
prysm	18	2026-06-25	`v7.1.6 (9f03f0a, e733c6a)`
teku	15	2026-06-25	`v26.6.0+56-gac1c8c618f`

▶ View Query: glam_client_coverage

Investigation

Event support matrix

A tick means the client emitted at least one event of this type over the window (2026-06-25 to 2026-07-09 UTC). Counts are total events across all of that client's sentries, from glamsterdam-devnet-6.beacon_api_eth_v1_events_*.

event	grandine	lighthouse	lodestar	nimbus	prysm	teku
`execution_payload`	✅ 45k	✅ 41k	✅ 34k	✅ 39k	✅ 43k	✅ 38k
`execution_payload_available`	✅ 283k	✅ 290k	✅ 216k	✅ 277k	✅ 312k	✅ 265k
`execution_payload_bid`	✅ 273k	✅ 296k	✅ 238k	❌	✅ 291k	✅ 191k
`execution_payload_gossip`	✅ 45k	✅ 41k	✅ 34k	✅ 39k	✅ 37k	✅ 38k
`payload_attestation`	❌	✅ 49.5M	❌	❌	✅ 53.1M	✅ 45.0M
`proposer_preferences`	❌	✅ 300k	✅ 221k	❌	✅ 320k	✅ 265k
`head_v2` not in Xatu yet	❌	❌	❌	❌	✅ probe	✅ probe

▶ View Query: glam_sse_client_matrix

Three gaps show up, and each one holds across every node of the affected client for the whole window:

nimbus never emits execution_payload_bid.
grandine, lodestar and nimbus never emit payload_attestation.
grandine and nimbus never emit proposer_preferences.

These are API gaps, not networking gaps. The corresponding gossipsub topics show messages arriving from peers of every client, so nimbus does forward execution_payload_bid messages on gossip, it just doesn't expose the SSE event. Where a client does emit an event, its volume is in line with its node count. There are no partial or intermittent emitters.

The head_v2 row is different from the rest: Glamsterdam added it to the event stream spec (it replaces the now-deprecated head event and adds payload_status) but Xatu does not capture it yet, so its row comes from the direct probes below rather than from Xatu data.

Probing the gaps

To pin down what each missing cell actually means, we probed every missing client and event pair directly on 2026-07-10: one node per client, curl /eth/v1/events?topics=<topic> held open over SSH for 20 seconds, and 120 seconds (10 slots) wherever the stream stayed silent. The same probe against prysm and teku is what fills the head_v2 row in the matrix above; both emit it with payload_status immediately. Note the SSE topic for payload attestations is payload_attestation_message per the spec; Xatu just stores it as payload_attestation.

client	topic	result	response
grandine	`head_v2`	❌ rejected	`400: invalid query string: topics: Matching variant not found`
grandine	`payload_attestation_message`	❌ rejected	`400: invalid query string: topics: Matching variant not found`
grandine	`proposer_preferences`	❌ rejected	`400: invalid query string: topics: Matching variant not found`
lighthouse	`head_v2`	❌ rejected	`400: BAD_REQUEST: unable to parse query`
lodestar	`head_v2`	❌ rejected	`400: Invalid topic: head_v2`
lodestar	`payload_attestation_message`	❌ rejected	`400: Invalid topic: payload_attestation_message`
nimbus	`head_v2`	❌ rejected	`400: Invalid topics value`
nimbus	`execution_payload_bid`	⚠️ silent	`200, no events in 120s`
nimbus	`payload_attestation_message`	⚠️ silent	`200, no events in 120s`
nimbus	`proposer_preferences`	⚠️ silent	`200, no events in 120s`

The probes split the gaps into two kinds:

grandine and lodestar reject their missing topics with a 400: the topics don't exist in their event stream API at all.
nimbus accepts subscriptions to all three of its missing topics but never sends an event, even over 10 slots. The API routing exists; the emission doesn't. Its head_v2 rejection is the exception.

All six clients still emit the deprecated v1 head event.

Takeaways