---
title: "MEV Timing"
method: POST
path: "/api/v2/ethereum/block/mev-timing"
tags: ["Block"]
---

# MEV Timing

`POST /api/v2/ethereum/block/mev-timing`

Returns the MEV timing-game outcome for a single block: the winning relay bid, the earliest later bid that would have beaten it (`first_better_bid`), the highest-value later bid (`best_later_bid`), the value left on the table, and the winning relay and builder.

**Use case guide:** [Investigate a Block](/use-cases/investigate-mev-block) shows how to interpret the winning bid, later alternatives, and missed value.

**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 and bid fields are derived from offchain relay APIs and streams. Relay-reported timestamps, identities, and bid coverage are not independently verifiable from onchain data; verify included block fields separately.

Resolve a block by number or the keywords "latest" / "finalized". Pair this with [/api/v2/ethereum/validators/proposal-slots](/api-reference/ethereum/validators/proposal-slots) to drill into a specific proposal.

**Note:** MEV relay and timing data is only available on mainnet at this time.

**History:** Relay bid collection began on 2024-06-03 (UTC). Blocks before that date — including all pre-Merge blocks — return status `unknown`, since the absence of relay data means the timing outcome is not known rather than that no MEV occurred.

Data freshness: per-slot relay statistics lag the chain head by roughly 4 hours. A block newer than the latest aggregated slot returns status `pending` until the data catches up.

## Request body

- object
  - `chain` 'mainnet' | 'hoodi' — The Ethereum chain to query.
  - `block` union, required — Specify a block using one of the following methods. - Block number - View: "latest" or "finalized"
    - BlockByNumber
      - `number` integer, required — Block by number.
    - BlockByChainView
      - `view` 'latest' | 'finalized', required — - "latest": Refers to the most recent block, which may be subject to reorganization. - "finalized": Refers to the latest block that has been finalized and is not subject to change.

## Response `200`

Successful response.

- BlockMevTimingContainer — Response containing the MEV timing-game outcome for a single block.
  - `data` BlockMevTimingData, required — Timing-game outcome for a single block.
    - `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).
    - `winning_bid` MevWinningBid, required — The winning relay bid for a slot, including the relay that delivered it and the block builder.
      - `value` string, required — Amount in wei (1 ETH = 10^18 wei)
      - `slot_offset_ms` integer, required — Time of the bid relative to the slot's scheduled start, in milliseconds (`0` = on time). Negative values indicate the bid arrived before the slot start; positive values indicate it arrived after. Larger positive values reflect more aggressive timing games. The offset is derived from an offchain relay-reported timestamp and is not independently verifiable from onchain data.
      - `relays` string[], required — The relay(s) that delivered the winning block. Currently only the first relay observed to deliver the block is recorded, so this array contains at most one entry today — it is empty if the underlying relay-bid record for this slot is no longer available. It may include additional relays in the future without being a breaking change.
      - `builder_pubkey` string, nullable, required — BLS public key of the block builder that produced the winning block, or `null` if unknown. Taken from the relay data API, excluding `getHeader` observations.
    - `first_better_bid` MevBid, required — A relay bid summarised by its value and arrival time relative to slot start.
      - `value` string, required — Amount in wei (1 ETH = 10^18 wei)
      - `slot_offset_ms` integer, required — Time of the bid relative to the slot's scheduled start, in milliseconds (`0` = on time). Negative values indicate the bid arrived before the slot start; positive values indicate it arrived after. Larger positive values reflect more aggressive timing games. The offset is derived from an offchain relay-reported timestamp and is not independently verifiable from onchain data.
      - `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).
    - `best_later_bid` MevBid, required — A relay bid summarised by its value and arrival time relative to slot start.
      - `value` string, required — Amount in wei (1 ETH = 10^18 wei)
      - `slot_offset_ms` integer, required — Time of the bid relative to the slot's scheduled start, in milliseconds (`0` = on time). Negative values indicate the bid arrived before the slot start; positive values indicate it arrived after. Larger positive values reflect more aggressive timing games. The offset is derived from an offchain relay-reported timestamp and is not independently verifiable from onchain data.
      - `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).
    - `missed_value` string, required — Amount in wei (1 ETH = 10^18 wei)
    - `relay_count` integer, nullable, required — Number of distinct relays that submitted a bid for the slot. `null` when there is no winning bid.
    - `bid_count` integer, nullable, required — Total number of bids recorded for the slot. `null` when there is no winning bid.

## 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)
