# Attestation Arrival Timing on Ethereum Mainnet

This document summarizes single-bit attestation arrival timing from slot 12029000 to 12039000 (\~36 hours between Saturday, June 28, 2025 and Monday, June 30, 2025). It aims to answer:

* How quickly does my local NUC node see validated attestations on all subnets since slot start?

**Why does this matter?** Attestation arrival timing gives a real-time sense of how strong a block is (reorg resistance) and how much slack exists in the system, especially relevant for slot reconstruction proposals.

While [Xatu](https://github.com/ethpandaops/xatu) has similar [measurements](https://x.com/nero_eth/status/1938521769205215524), I wanted a local view. It’s unclear how encoding, decoding, and transmission might affect Xatu's numbers.

To capture this, I [modified](https://github.com/OffchainLabs/prysm/compare/develop...log-att) my Prysm node to log the slot number and local arrival time of every verified attestation received over the network. Delay was calculated as the time since slot start. Logs were collected and analyzed at various threshold levels (40%, 50%, 66%, 80%, etc).

> [!NOTE]
> AMD Ryzen 7 5800XT 8-Core / 64GB RAM
>Download: 282.48 Mbit/s
Upload: 62.78 Mbit/s

**TLDR**:

* My node sees 50% of validated attestations within 1s in most slots
* 66% is often reachable within 1s as well
* 90% starts to show a broad distribution with long-tail delays

**Attestation Arrival Time Distribution**
Boxplots show arrival delays for 40%-80% thresholds. 40%-50% are tightly clustered under 1000ms. 66% performs well, with slightly more spread. 80% has broader delay distribution and more outliers, signaling growing propagation challenges.

**CDF of Attestations**
Cumulative arrival curves show that 40%-50% thresholds are reached rapidly, often before 4s. 66% follows shortly. 80% continues rising into the 5-6s range.

**Attestation Arrival Velocity Distribution**
Histograms show most attestations arrive within the first 1000ms. As thresholds rise, arrivals stretch into the 2000ms range. 80% has a longer tail but remains trackable.

**Attestation Arrival by Threshold**
Time-series shows stable and fast arrival at 40%-66%. 80% has more variance and spikes but generally remains within reasonable bounds.

### Open questions

* Should we focus analysis only on empty slots to get a reliable measure of when attestations are sent?
* What is causing the late attestations we’re seeing? Is late attestation behavior caused by network delays, libp2p issues, or something else? Could we rule out Prysm-specific causes by capturing the time just before validation and seeing if validation is the bottleneck?