๐ Proposal Timing
Returns when an entityโs proposals reached one beaconcha.in node, aggregated over an evaluation window, next to the same figures for the whole network over the same window. Optionally scope to a sub-entity; omit sub_entity for the whole 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 the figures show when our node saw a block, not why it arrived then. 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 entity. The network median includes the entityโs own proposals, which pulls the offset of a large entity 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.
Combine this endpoint with others for deeper insights:
- Each proposal of a set of validators, with its own publish time: v2/ethereum/validators/proposal-slots
- The entities and sub-entities to pass: v2/ethereum/entities, v2/ethereum/entity/sub-entities
- Before the fork, proposal timing measured from relay bids, which is not comparable with this measure: v2/ethereum/entity/mev-timing
Premium Endpoint: This endpoint requires a Scale or Enterprise plan.
Authorizations
Body
The name of the entity to aggregate the proposals of (e.g. "Lido", "Coinbase"). Matching is case-sensitive; use the exact name as returned by the entities overview endpoint. An entity without proposals in the window returns zero counts.
The Ethereum chain to query.
mainnet, hoodi Optional sub-entity to scope the figures. Omit or pass an empty string to aggregate the whole entity. Matching is case-sensitive; use the exact name as returned by the sub-entities overview endpoint.
Response
Successful response.
Response containing when the entity's proposals reached one beaconcha.in node over the evaluation window.
Proposal timing of the entity 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.

