Proposal Timing Aggregate
Returns when the proposals of a set of validators reached one beaconcha.in node, aggregated over a 24-hour, 7-day or 30-day evaluation window, next to the same figures for the whole network over the same window. The validator set may be selected by identifiers, dashboard, withdrawal address, withdrawal credential, deposit address, or entity/sub-entity.
From the Glamsterdam hard fork on, the proposer publishes its own block, so the time at which a block reaches our node follows the proposer’s setup; the winning builder may also forward the block, which can make it arrive earlier. The figures are one node’s view: each node receives a block at its own time, and a proposer’s network position gives it a stable offset to our node, so a difference between proposers is not by itself a difference in when they published. The time is when our node received the block over the peer-to-peer gossip network, relative to the slot start; a block our node imported another way has no time and is counted separately.
publish_time.median_slot_offset_vs_network_ms compares each proposal with the network median of the same hour of slot start, so a slow hour at our node does not count against the validators. The network median includes the validators’ own proposals, which pulls the offset of a large set toward zero.
The attestation deadline is ATTESTATION_DUE_BPS_GLOAS of the slot duration, 3000 ms at 12-second slots. Fork choice counts a block as timely only when it arrives before the deadline, and each node judges by its own arrival time, so a count at or after the deadline describes our node’s view, not the chain’s verdict. A block that our node received but the chain did not include is counted in not_included_count; the arrival time alone does not show why the chain did not include it.
Only finalized slots count, and the window never reaches before the fork. The window ends at the last slot for which both the included and the missed proposals are recorded, at most the last slot of the epoch before the head; range returns the window evaluated. When no slot of the window has a verdict yet, range returns the requested window, and in the fork’s own epoch, before any slot after the fork can have a verdict, the first slot after the fork. Medians and percentiles are exact, not interpolated: for an even count the median is the upper of the two middle values. A median needs at least 20 proposals seen on gossip and a 90th percentile at least 50; below that the field is null and the counts remain. A set of a few validators rarely reaches the minimum within a window, because one validator proposes only every few months on a large network.
Combine this endpoint with others for deeper insights:
- Each proposal of the validators, with its own publish time: v2/ethereum/validators/proposal-slots
- The same figures for an entity or one of its sub-entities: v2/ethereum/entity/proposal-timing
- Before the fork, proposal timing measured from relay bids, which is not comparable with this measure: v2/ethereum/validators/mev-timing-aggregate
Authorizations
Body
Free selectors available to all users:
- validator_identifiers: One or more validator indices or public keys to filter by.
- dashboard_id: Your beaconcha.in dashboard ID (requires a free account).
Premium selectors for Scale & Enterprise plans (https://beaconcha.in/pricing):
- withdrawal: The validator's withdrawal credential or the Ethereum wallet address used for withdrawals.
- deposit_address: The Ethereum wallet address used for the validator's deposit.
- entity: The name of the assigned entity (e.g., "Lido", "Coinbase"). Optionally include
sub_entityfor more specific filtering. Matching is case-sensitive.
Note: The set of validators matched by deposit_address and withdrawal selectors is updated once per epoch (~6.4 minutes). Newly deposited validators may take up to one epoch to appear in query results.
Note: The set of validators matched by entity selector is updated once per day.
- Indices/Pubkeys
- Dashboard
- 💎 Deposit
- 💎 Withdrawal
- 💎 Entity
The Ethereum chain to query.
mainnet, hoodi Response
Successful response.
Response containing when the proposals of the validators reached one beaconcha.in node over the evaluation window.
Proposal timing of the validators over the evaluation window. The window ends at the last finalized slot and starts no earlier than the Glamsterdam hard fork.
The time span actually covered by the returned results — from the first to the last matching data point — specified in slots, epochs, and Unix timestamps.
This reflects the data that was found, not the range that was queried. When the response is 200 but no data is found, it falls back to the requested range, or to the full available history if no range was given. Some endpoints answer 404 instead when no data is found.
For arbitrary (custom) time-range queries the queried range is expanded outward to whole UTC days, so the covered range may be wider than requested. As stated above, the reported range still reflects the data that was actually found — a touched UTC day with no data for the selected validators will not extend it.

