--- title: "MEV Timing Aggregate" method: POST path: "/api/v2/ethereum/validators/mev-timing-aggregate" tags: ["Validator"] --- # MEV Timing Aggregate `POST /api/v2/ethereum/validators/mev-timing-aggregate` Returns the overall MEV timing posture and histogram for a set of validators over a fixed evaluation window. The validator set may be selected by identifiers, dashboard, withdrawal/deposit address, or entity/sub-entity. **Use case guide:** [Compare MEV Timing](/use-cases/compare-mev-timing) shows how to profile validator cohorts and interpret their timing distribution. **Protocol caveat:** The 1200 ms and 2600 ms timing bands apply to pre-Glamsterdam slots. [Glamsterdam](https://ethereum.org/roadmap/glamsterdam/) introduces ePBS and restructures slot production, so post-fork classifications may change. **Data provenance:** Timing statistics are derived from offchain relay APIs and streams. Relay-reported timestamps, identities, and bid coverage are not independently verifiable from onchain data; coverage gaps or inconsistent reporting can affect results. Currently only the `180d` rolling window is available (see `evaluation_window`). **Note:** MEV relay and timing data is only available on mainnet at this time. **History:** Relay bid collection began on 2024-06-03 (UTC). The evaluation window only reflects data from that date onward. Data freshness: validator timing profiles are rebuilt nightly over a rolling 180-day window. ## Request body - ValidatorMevTimingRequest - `chain` 'mainnet' | 'hoodi' — The Ethereum chain to query. - `validator` union, required — 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_entity` for 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. - ValidatorsByIdentifiers - `validator_identifiers` ValidatorIndexPublicKey[], required — An array containing either validator indices or public keys. Index and public key can be mixed in the same array. Subscribed users (Hobbyist, Business, and Scale tiers) can include up to 100 entries; free trial users and legacy subscription users (Sapphire, Emerald, Diamond) are limited to 20. - union - integer — Validator Index - string — Public key of a validator - ValidatorsByDashboard - `dashboard_id` integer, required — beaconcha.in dashboard ID. You can find your dashboard ID in the URL of your dashboard page on beaconcha.in (e.g., https://beaconcha.in/dashboard/12345). - `group_id` integer, nullable — Optional beaconcha.in dashboard group ID. If no group ID is provided, all validators in the dashboard are considered. - ValidatorsByDeposit - `deposit_address` string, required — A standard Ethereum address (20-byte hex string with 0x prefix). - ValidatorsByWithdrawal - `withdrawal` string, required — Either an execution layer address (20-byte hex string with 0x prefix) or a full 32-byte withdrawal credential. - ValidatorsByEntity — Select validators by their assigned entity (e.g., staking provider) and optionally a sub-entity. Entity and sub-entity names are matched exactly and are case-sensitive. - `entity` string, required — The name of the entity to filter validators by (e.g., "Lido", "Coinbase"). Matching is case-sensitive; use the exact name as returned by the entities overview endpoint. - `sub_entity` string — Optional sub-entity name to further filter validators within the entity. Matching is case-sensitive; use the exact name as returned by the sub-entities overview endpoint. - `evaluation_window` '180d' — The evaluation window for aggregating validator MEV timing metrics. Currently only `180d` (a rolling 180-day window) is available. - `180d`: Rolling 180-day window. ## Response `200` Successful response. - ValidatorMevTimingContainer — Response containing the aggregated MEV timing posture of the selected validators. - `data` ValidatorMevTimingData, required — Aggregated MEV timing posture for the selected validator set over the evaluation window. - `timing_label` MevTimingLabel, required — Aggregated timing-game posture over a set of slots. - `status` 'on_time_mev' | 'timing_games' | 'aggressive_tg' | 'no_mev' | 'unknown' | 'pending', required — Classification of a block's MEV timing behaviour, derived from how long after the slot start the winning relay bid arrived. **Protocol caveat:** The 1200 ms and 2600 ms thresholds apply to pre-Glamsterdam slots. Glamsterdam introduces ePBS and restructures slot production, so classification rules for post-fork slots may change. **Data provenance:** These statuses are derived from offchain relay observations. Relay-reported timestamps, identities, and bid coverage are not independently verifiable from onchain consensus or execution data. - `on_time_mev`: winning bid arrived ≤ 1200 ms after slot start — MEV was captured without delaying the proposal. - `timing_games`: winning bid arrived 1201–2600 ms after slot start — the proposer delayed to capture more MEV. - `aggressive_tg`: winning bid arrived > 2600 ms after slot start — aggressive timing games with higher orphan risk. - `no_mev`: no relay bids were observed for this slot at all — the block was built locally (or by a proposer not registered with any tracked relay). - `unknown`: relay bids were observed for this slot, but the winning payload could not be identified — either our periodic relay polling missed it, or the slot predates relay bid collection. The underlying block may still be an MEV block; `unknown` is not evidence either way. - `pending`: the slot is newer than the latest aggregated slot, so its timing outcome has not been computed yet. Retry once relay data catches up (per-slot statistics lag the chain head by roughly 4 hours). - `median_slot_offset_ms` number, double, nullable, required — Median slot offset (ms relative to slot start) across the aggregated slots, or `null` if no slots had a winning relay bid. - `total_count` integer, required — Total number of slots with a winning relay bid that contributed to this summary. - `histogram` MevTimingBucket[], required — Distribution of winning-bid slot offsets across 22 fixed buckets, in ascending order. The first bucket covers all offsets below 0 ms, followed by 20 buckets in 200 ms steps from 0 to 3800 ms, and a final bucket for all offsets at or above 4000 ms. - `slot_offset_ms_min` integer, required — Inclusive lower bound of the bucket, in milliseconds relative to slot start. - `slot_offset_ms_max` integer, required — Exclusive upper bound of the bucket, in milliseconds relative to slot start. - `count` integer, required — Number of slots whose winning bid offset falls in this bucket. - `max_value` string, required — Amount in wei (1 ETH = 10^18 wei) - `evaluation_window` '180d', required — The evaluation window for aggregating validator MEV timing metrics. Currently only `180d` (a rolling 180-day window) is available. - `180d`: Rolling 180-day window. ## Other responses - `400` — Bad Request - `401` — Unauthorized - `403` — Forbidden - `404` — Not Found - `405` — Method Not Allowed - `429` — Rate Limit Exceeded - `500` — Internal Server Error - `default` — An unexpected error response. --- [API](https://skmtc.dev/beaconcha/apis/external-service-api.md) · [All operations](https://skmtc.dev/beaconcha/apis/external-service-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/beaconcha/external-service-api/revisions/ad26ad970b4e/schema)