beaconcha.in

Provides comprehensive details about a specific execution layer block, excluding rewards. For reward details, refer to [v2/ethereum/block/rewards](https://docs.beaconcha.in/api-reference/ethereum/block/rewards). Execution layer blocks contain transactions and state changes, while consensus layer slots manage validator duties and finality. Since the Merge (Proof-of-Stake transition), each execution layer block corresponds to a consensus layer slot, though their numbers differ. This endpoint delivers an overview of the requested block, including its slot reference (if applicable), block hash, timestamp, gas usage, transaction counts, and other key metrics. For pre-Merge blocks, consensus layer references will be null. Query options include block number or keywords like "latest" and "finalized" for the most recent or finalized block. beaconcha.in POST /api/v2/ethereum/block. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the full per-relay bid ladder for a single block's slot — every recorded relay bid with its value, arrival time, relay, builder, and source. Intended for research and auditing. **Use case guide:** [Investigate a Block](https://docs.beaconcha.in/use-cases/investigate-mev-block) shows how to filter, paginate, and audit the relay bid ladder. **Data provenance:** The bid ladder is collected from offchain relay APIs and streams. Relay-reported timestamps, identities, and bids are not independently verifiable from onchain data, and coverage gaps or inconsistent reporting can make the recorded ladder incomplete. Verify included block fields separately. Results are ordered by arrival time and paginated. An optional `slot_offset_ms_range` filters bids by their slot offset. **Note:** MEV relay and timing data is only available on mainnet at this time. **History:** Relay bid collection began on 2024-06-03 (UTC). No bids are recorded for slots before that date — including all pre-Merge blocks — so the bid ladder is empty for them. Data freshness: per-slot relay statistics lag the chain head by roughly 4 hours. **Premium Endpoint:** This endpoint requires a Scale or Enterprise plan. beaconcha.in POST /api/v2/ethereum/block/mev-bids. Read-only: POST is how the V2 API takes a query body; nothing is changed.

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](https://docs.beaconcha.in/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](https://docs.beaconcha.in/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. beaconcha.in POST /api/v2/ethereum/block/mev-timing. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Offers detailed insights into the execution layer rewards for a specific block, including transaction fees and MEV (Maximal Extractable Value). You can query using a block number or the keywords "latest" / "finalized". beaconcha.in POST /api/v2/ethereum/block/rewards. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the current configuration parameters of the network. beaconcha.in POST /api/v2/ethereum/config. Read-only: POST is how the V2 API takes a query body; nothing is changed. The spec documents no success body for this endpoint; measured 2026-09-14 on a Free Trial key it answered 200 with an empty object.

Returns an overview of all entities with their validator count, BeaconScore®, and net share. **Use case guide:** [Entity benchmarking](https://docs.beaconcha.in/use-cases/entity-benchmarking-overview) explains how to rank entities and compare an operator with the network baseline. Results can be sorted by `beaconscore`, `net_share`, `validator_count`, or `sub_entity_count` in ascending or descending order. By default, results are sorted by `net_share` in descending order. **Note:** The underlying data is precomputed and updated hourly. `all_time` evaluation window is not supported for this endpoint. **Premium Endpoint:** This endpoint requires a Scale or Enterprise plan. **Attribution Required:** If you display BeaconScore® data publicly, you must include appropriate attribution. See our [BeaconScore® License](https://docs.beaconcha.in/legal/beaconscore-license) and [License Materials](https://docs.beaconcha.in/legal/license-materials) for badges and usage guidelines. beaconcha.in POST /api/v2/ethereum/entities. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns an entity's MEV timing-game statistics as a per-day series. Optionally scope to a sub-entity; omit `sub_entity` for the entity-level rows. **Use case guide:** [Compare MEV Timing](https://docs.beaconcha.in/use-cases/compare-mev-timing) shows how to benchmark an entity or sub-entity against the network. **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. Results can be filtered by a time range (bucketed to whole UTC days) and are paginated. For an aggregated posture and histogram over an entity (rather than a daily series), use [/api/v2/ethereum/validators/mev-timing-aggregate](https://docs.beaconcha.in/api-reference/ethereum/validators/mev-timing-aggregate) with its entity selector. **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 series contains no days before that date; a time range that falls entirely before it returns an empty result. Data freshness: the most recent ~3 days of daily aggregates are reprocessed and may still change. **Premium Endpoint:** This endpoint requires a Scale or Enterprise plan. beaconcha.in POST /api/v2/ethereum/entity/mev-timing. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns an overview of all sub-entities associated with a given entity, including their validator count, BeaconScore®, and net share. **Use case guide:** [Entity benchmarking](https://docs.beaconcha.in/use-cases/entity-benchmarking-overview) explains how to drill from a public entity into its sub-entities and compare them with the network. Results can be sorted by `beaconscore`, `net_share`, or `validator_count` in ascending or descending order. By default, results are sorted by `net_share` in descending order. **Note:** The underlying data is precomputed and updated hourly. `all_time` evaluation window is not supported for this endpoint. **Premium Endpoint:** This endpoint requires a Scale or Enterprise plan. **Attribution Required:** If you display BeaconScore® data publicly, you must include appropriate attribution. See our [BeaconScore® License](https://docs.beaconcha.in/legal/beaconscore-license) and [License Materials](https://docs.beaconcha.in/legal/license-materials) for badges and usage guidelines. beaconcha.in POST /api/v2/ethereum/entity/sub-entities. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a rolled-up overview of a single consensus layer epoch. In Ethereum, an epoch is a fixed window of consensus layer slots (32 on Ethereum Mainnet) over which validator attestations are aggregated and finality is determined. This endpoint summarizes network-wide activity for the epoch: validator participation, balances, block proposal outcomes, and the protocol events (deposits, withdrawals, exits, slashings) included across its slots. Think of it as a per-epoch starting point: the `slots` range tells you which slots belong to the epoch so you can drill into per-slot detail via [v2/ethereum/slot](https://docs.beaconcha.in/api-reference/ethereum/slot/overview), and the counts point you to the more specific endpoints for each topic. You can query by epoch number, or use "latest" / "finalized" for the most recent or finalized epoch. The "finalized" view can lag the chain's latest finalized epoch by up to one epoch so that every metric of the returned epoch is fully populated. Note: for an epoch whose duties have not yet been fully aggregated (the most recent epochs, whether not-yet-finalized or queried by number just after finalization) the participation- and performance-based fields (`attesting_balance`, `participation_rate`, `attestation_participation`, `sync_participation`, `beaconscore`) are `null` — check `finality` to tell an in-progress epoch apart, and query "finalized" for a complete, stable response. beaconcha.in POST /api/v2/ethereum/epoch. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns ETH.STORE® — the staking benchmark measuring the average return that validators on the Ethereum network achieved over each 24-hour period. Each datapoint covers one beaconchain-day (a fixed window of `86400 ÷ seconds_per_slot ÷ slots_per_epoch` epochs, indexed by the number of whole days elapsed since genesis) and aggregates every validator that was active for the full day. Each datapoint reports the effective, start, and end balances, the deposits credited during the day, and the rewards split into consensus-layer (attestation, sync-committee, proposal) and execution-layer (priority transaction fees and MEV) components. The annualized rate of return (APR) is given for each layer and combined, together with 7-day and 31-day trailing averages that smooth out day-to-day variance. Results are returned one datapoint per day, most recent first. Free plans select a trailing evaluation window (`24h` for the latest datapoint, up to `all_time` with pagination for the full history). [Scale and Enterprise plans](https://beaconcha.in/pricing) can additionally request an arbitrary range by Unix timestamp, epoch, or slot. Because a datapoint is computed only after its day has finalized, every returned value is immutable and safe to cache indefinitely. ETH.STORE® is not made available for use as a benchmark, whether in relation to a financial instrument, financial contract or to measure the performance of an investment fund, or otherwise in a way that would require it to be administered by a benchmark administrator pursuant to the EU Benchmarks Regulation. Currently Bitfly does not grant any right to access or use ETH.STORE® for such purpose. beaconcha.in POST /api/v2/ethereum/eth-store. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns network-wide MEV timing-game statistics as a per-day series. Each day carries the slot counts, a timing breakdown, the median slot offset, and the full histogram. **Use case guide:** [Compare MEV Timing](https://docs.beaconcha.in/use-cases/compare-mev-timing) shows how to compare daily network, entity, and validator-set behavior. **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. Results can be filtered by a time range (bucketed to whole UTC days) and are paginated. Use `min_slots_per_day` to exclude sparsely-covered days. **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 series contains no days before that date; a time range that falls entirely before it returns an empty result. Data freshness: the most recent ~3 days of daily aggregates are reprocessed and may still change. beaconcha.in POST /api/v2/ethereum/mev-timing. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns aggregated performance metrics for the entire network in the given time range. **Use case guide:** [Entity benchmarking](https://docs.beaconcha.in/use-cases/entity-benchmarking-overview) uses this endpoint as the network baseline for public and private validator-set comparisons. Must provide either start + end times or epochs **Custom time ranges:** Query arbitrary time ranges using Unix timestamps, epochs, or slots — exclusively for [Scale and Enterprise plans](https://beaconcha.in/pricing). Custom ranges are served at whole-UTC-day granularity (partial days are rounded outward), and the response `range` reports the actual covered range. beaconcha.in POST /api/v2/ethereum/performance-aggregate. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns information about the various staking-related queues (deposit, exit, full withdrawal, consolidation, compounding switch) and how long the expected wait time is. **Use case guide:** [Queue tracking](https://docs.beaconcha.in/use-cases/queue-tracking) explains how to choose between network and validator queue views, estimate wait times, and measure staking flows. The `estimated_processed_at` field in each queue always refers to the very last item in the network queue (i.e. when the entire queue will be fully processed). For per-validator queue details, use: - [/api/v2/ethereum/validators/queues](https://docs.beaconcha.in/api-reference/ethereum/validators/queues) — overview per validator ### Deprecation Notice This notice only affects you if your requests do **not** send the `Accept: application/vnd.beaconcha.in.v2.1+json` header — such requests currently receive the legacy v2 schema. The legacy schema is deprecated and will be sunset on 02.07.2026 23:59:59 UTC. After that date, all requests receive the new v2.1 schema regardless of the `Accept` header, which will break your response parsing if you have not migrated. To migrate, send the `Accept: application/vnd.beaconcha.in.v2.1+json` header and adapt your parsing to the v2.1 schema shown in the response section below. To review the legacy schema you are currently receiving, select v2 from the **Content-Type dropdown** in the top-right corner of the response section. beaconcha.in POST /api/v2/ethereum/queues. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a history of the staking queue sizes — how much ETH is waiting to enter and leave staking over time. Each entry is a snapshot of the staking queues at one epoch. History begins at the Pectra fork, which is where the queues themselves begin: the pending deposit, consolidation and partial-withdrawal queues are Pectra state fields, so there is nothing to report before it. How far back a given request reaches also depends on `granularity` — see that field for the two floors and how out-of-range requests are handled. An epoch with no usable snapshot is omitted from the series rather than returned as an empty entry, so entries are not guaranteed to be evenly spaced. Read `epoch` and `timestamp` on each entry rather than inferring them from position. Each entry covers the four queues the snapshot records. The `withdrawal_sweep` and `compounding_switch_queue` entries of the live endpoint have no historical counterpart and are not returned here. For the current point-in-time queue state, see [/api/v2/ethereum/queues](https://docs.beaconcha.in/api-reference/ethereum/queues). beaconcha.in POST /api/v2/ethereum/queues/history. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns what it costs to submit a withdrawal or consolidation request to the execution layer, as observed history: one entry per execution layer block that saw at least one request, most recent block first. Two contracts charge such a fee, and `type_filter` selects between them — the EIP-7002 contract for execution-layer triggered partial withdrawals and full exits, and the EIP-7251 contract for consolidations and compounding switches. Deposits are free, so they do not appear here. Every request that a validator queue endpoint reports as `pending` paid one of these fees. Both contracts price requests with an EIP-1559 style mechanism: the fee starts at a floor of 1 wei and climbs exponentially while submissions exceed the per-block target, then decays back toward the floor once demand drops. A mass exit or mass consolidation event therefore lifts the fee well above the floor for as long as it lasts. Operators batching many exits or consolidations can use this history to judge whether they are submitting into such a period. ### What these numbers are, and what they are not This endpoint reports **fees actually paid**, derived from the value sent with each request transaction. It is not a fee oracle and does not read the contracts' current fee. - `fee_min` is the best available estimate of the protocol-required fee in that block, because no submitter can pay less than the contract demands. - `fee_max` may exceed it. The contracts do not refund an overpayment, and some tooling deliberately overpays so the transaction still succeeds if the fee rises between signing and inclusion. - Blocks with no requests are absent from the response. A gap does not mean the fee is unknown: with no submissions the fee decays deterministically toward the 1 wei floor, so a long gap implies the fee has returned to the floor. <Warning> This endpoint reports historic state only and must not be used as a fee oracle. Its most recent entry is a fee that was already paid in a past block, not the fee your own submission has to pay. For the fee that applies to the next block, use [/api/v2/ethereum/queues/request-fees/current](https://docs.beaconcha.in/api-reference/ethereum/queues/request-fees/current). To obtain the exact fee for a request you are about to submit, call the contract itself with empty calldata — that is the only authoritative source. </Warning> Results can be filtered by a time range and are paginated. Omit `range` to cover the whole available history starting at the most recent block; this endpoint is network-wide, so no validator selection is involved. Supply a `range` to reach a past congestion event instead of paging back to it. The `range` in the response reports the span the returned entries actually cover, not the span you asked for. You can combine this endpoint with: - Inspect the individual requests that paid these fees, and the fee each one paid: [/api/v2/ethereum/slot/consolidations](https://docs.beaconcha.in/api-reference/ethereum/consolidations) and [/api/v2/ethereum/slot/withdrawals](https://docs.beaconcha.in/api-reference/ethereum/withdrawals) - Check the fee environment your own validators' requests were submitted into, using the execution layer block from their `stage_history`: [/api/v2/ethereum/validators/queues/consolidations](https://docs.beaconcha.in/api-reference/ethereum/validators/queues/consolidations) Data is available from the Pectra fork (7 May 2025) onwards. On mainnet the first consolidation request was submitted in execution layer block 22431119 and the first withdrawal request in block 22431159, both on 7 May 2025. A range that falls entirely before Pectra returns `200` with an empty `data` array. beaconcha.in POST /api/v2/ethereum/queues/request-fees. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns what it costs to submit a withdrawal or consolidation request to the execution layer right now: one entry per request type. The value is the fee that applies to the next block, so it is what your submission pays if it is included immediately. Two request types carry such a fee, and `request_type` tells the entries apart — EIP-7002 requests, which are execution-layer triggered partial withdrawals and full exits, and EIP-7251 requests, which are consolidations and compounding switches. Deposits are free, so they do not appear here. Both types are priced with an EIP-1559 style mechanism: the fee starts at a floor of 1 wei and climbs exponentially while submissions exceed the per-block target, then decays back toward the floor once demand drops. The climb has no per-block ceiling, so a single busy block can raise the fee by orders of magnitude. <Warning> The fee reported here is not guaranteed to be sufficient by submission time, because it can still change in the block your transaction lands in. An overpayment is not refunded, and an underpayment makes the call revert. No fixed margin is safe in all conditions, so you must decide your own trade between paying above the reported value and risking a revert. Read the fee immediately before you submit, and during a congestion period read it again as close to submission as possible. To obtain the exact fee for a request you are about to submit, call the contract itself with empty calldata — that is the only authoritative source. </Warning> ### Freshness The fee is read approximately every 4 seconds, so a new execution layer block is normally picked up within a few seconds of it landing. Every entry carries the execution layer `block` and `timestamp` it was read at, so you can compare `timestamp` to the current time to judge its age. Because `timestamp` is the block's own time, a normal age is anywhere inside the current slot, and a missed slot adds a further slot to it. This endpoint does not serve a fee it knows to be stale. If the underlying data stops advancing, it returns `503` instead of a `200` that carries an out-of-date value, because a fee that is too low makes your submission revert. Treat `503` as retryable, and do not fall back to a cached fee without a new age check. The response always carries one entry per request type. It is never `200` with an empty `data` array: either both fees are known, or the endpoint answers `503`. This endpoint describes only the present. For the fee history, see [/api/v2/ethereum/queues/request-fees](https://docs.beaconcha.in/api-reference/ethereum/queues/request-fees). beaconcha.in POST /api/v2/ethereum/queues/request-fees/current. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns detailed information about a specific consensus layer slot. In Ethereum, "slots" are data containers on the consensus layer where validator duties are scheduled and blocks may be proposed. Each slot may reference a block, but a slot can also be missed. This endpoint provides an overview of the requested slot, including its status (proposed, missed, scheduled), assigned proposer, participation metrics, protocol events (deposits, withdrawals, slashings), and other relevant details. You can query by slot number, block root hash, or use "latest" / "finalized" for the most recent or finalized slot. beaconcha.in POST /api/v2/ethereum/slot. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Provides detailed status and reward information about attestation duties assigned to validators for a specific slot. The validator filter is optional; if omitted, results include all validators assigned attestation duties for the slot. The response only includes attestation duties scheduled for the specified slot, not attestations included in this slot. Use the reward endpoints for epoch based attestation rewards information. You can combine this endpoint with: - Find attestations slots your validators were assigned to: [v2/ethereum/validators/attestation-slots](https://docs.beaconcha.in/api-reference/ethereum/validators/attestation-slots) beaconcha.in POST /api/v2/ethereum/slot/attestation-duties. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the EIP-7251 requests carried by the block at the specified slot: validator consolidations and switches to compounding withdrawal credentials. Both kinds arrive through the same execution-layer contract with the same fields, including a source and a target public key. The consensus layer distinguishes them by whether those keys are equal: - `consolidation` — the keys differ. The source validator exits and its balance moves to the target, which must already have compounding (`0x02`) withdrawal credentials. - `compounding_switch` — the keys are identical. Nothing exits and no balance moves; the request only changes that validator's withdrawal credentials from `0x01` to `0x02`. The `type` field reports which kind an entry is, so you do not have to compare public keys yourself. Use `type_filter` to narrow the response to one kind. Results are anchored to the slot whose block body carried the request. For a consolidation the resulting balance transfer settles later, when the pending consolidation queue drains to it; that settlement slot is reported in `stage_history.consensus_layer_processed` and is not used for filtering. A compounding switch is applied at inclusion, so both slots are the same. Rejected requests are included. A request rejected at inclusion reached a block but changed no state, so `stage_history.consensus_layer_processed` is null and, for consolidations, a `reject_reason` is set. Because of that delay a past slot's response is **not** immutable straight away: a `queued` consolidation keeps its inclusion slot but gains `amount` and `stage_history.consensus_layer_processed`, and flips to `completed`, long after the slot itself finalized. Cache a slot's response indefinitely only once no entry in it is `queued`; entries that are `completed` or `rejected` are terminal. Data is available from the Pectra fork (epoch 364032, first slot 11649024, 7 May 2025) onwards. On mainnet the earliest request observed is in slot 11649029. Slots before Pectra, and slots that carried no such request, return `200` with an empty `data` array. The validator filter is optional; if omitted, results include every request in the slot. A validator matches when it is either the source or the target of the request. You can combine this endpoint with: - Track consolidations for your own validators across all slots: [/api/v2/ethereum/validators/queues/consolidations](https://docs.beaconcha.in/api-reference/ethereum/validators/queues/consolidations) - Track compounding switches for your own validators: [/api/v2/ethereum/validators/queues/compounding-switches](https://docs.beaconcha.in/api-reference/ethereum/validators/queues/compounding-switches) - Compare the fee in `request.fee` against every other request submitted in the same execution layer block: [/api/v2/ethereum/queues/request-fees](https://docs.beaconcha.in/api-reference/ethereum/queues/request-fees) beaconcha.in POST /api/v2/ethereum/slot/consolidations. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns comprehensive details about all validator deposits processed in the specified slot. The validator filter is optional; if omitted, results include all deposits processed in the slot. Results may include *system deposits* — protocol-generated deposits that are not initiated by a user, such as the deposit created when a validator switches to compounding. See [System deposits and withdrawals](https://docs.beaconcha.in/faqs/system-deposits-and-withdrawals) for details. You can combine this endpoint with: - Find deposits associated with your validators: [v2/ethereum/validators/deposit-slots](https://docs.beaconcha.in/api-reference/ethereum/validators/deposit-slots) beaconcha.in POST /api/v2/ethereum/slot/deposits. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Provides status and reward information about sync committee duties for a specific slot for each validator. The validator filter is optional; if omitted, results include all validators assigned sync duties for the slot. This endpoint currently only supports finalized data. Use the reward endpoints for epoch based attestation rewards information. You can combine this endpoint with: - Find periods your validators were part in: [v2/ethereum/validators/sync-committee-periods](https://docs.beaconcha.in/api-reference/ethereum/validators/sync-committee-periods) - Sync committee overview: [v2/ethereum/sync-committee](https://docs.beaconcha.in/api-reference/ethereum/sync-committee/overview) beaconcha.in POST /api/v2/ethereum/slot/sync-committee-duties. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns comprehensive details about all validator withdrawals processed in the specified slot. The validator filter is optional; if omitted, results include all withdrawals processed in the slot. Results may include *system withdrawals* — protocol-generated withdrawals that are not initiated by a user, such as the withdrawal created when a validator switches to compounding. See [System deposits and withdrawals](https://docs.beaconcha.in/faqs/system-deposits-and-withdrawals) for details. Use this endpoint to quickly identify all relevant withdrawals for a slot. You can combine this endpoint with: - Find withdrawals associated with your validators: [v2/ethereum/validators/withdrawal-slots](https://docs.beaconcha.in/api-reference/ethereum/validators/withdrawal-slots) beaconcha.in POST /api/v2/ethereum/slot/withdrawals. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the explorer's current view of the Ethereum chain, including network health, validator counts, balances, and finality status. Unlike most API endpoints where processing lag is invisible, this endpoint explicitly exposes how far behind the explorer is relative to the actual chain head (see `data_freshness`). Use it to determine whether the data you're querying from other endpoints is sufficiently up-to-date for your use case. beaconcha.in POST /api/v2/ethereum/state. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the distribution of validator states across the network or a given validator filter. By default it returns the network distribution, but you might pass the optional validator filter to get a breakdown of states for a specific set of validators (e.g. your own). beaconcha.in POST /api/v2/ethereum/state/validator-statuses. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns basic sync committee information for a particular sync period. Use this to determine the range of epochs a given sync period entails. You can combine this endpoint with: - Validators in sync committee period: [v2/ethereum/sync-committee/validators](https://docs.beaconcha.in/api-reference/ethereum/sync-committee/validators) beaconcha.in POST /api/v2/ethereum/sync-committee. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the validators in the sync committee for a particular sync period. You can combine this endpoint with: - Sync Committee Period Overview: [v2/ethereum/sync-committee](https://docs.beaconcha.in/api-reference/ethereum/sync-committee) Response can be filtered to a specific set of validators by providing optional **validator** identifiers in the request body. beaconcha.in POST /api/v2/ethereum/sync-committee/validators. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns basic information about a set of validators at the current epoch. Data returned by the endpoint is based on the latest completed epoch of the beacon chain (not finalized). beaconcha.in POST /api/v2/ethereum/validators. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the annual percentage yield (APY) and return on investment (ROI) for a known collection or group of validators. Known collections are referenced by index, public key, deposit address, or withdrawal address. **Use case guide:** [APY & ROI metrics](https://docs.beaconcha.in/use-cases/apy-roi) explains how to choose a window, interpret return metrics, and decide when BeaconScore® is the better comparison. For comparing performance across different staking providers, we recommend using the BeaconScore® from the Performance Aggregated endpoints instead of APY or ROI, as BeaconScore® normalizes for luck and provides a fairer comparison. Note that some residual luck factors outside a validator's control can still influence BeaconScore®, especially over short evaluation windows. See the Residual Luck Factors section in the BeaconScore® documentation for details. **Coming Soon:** Support for querying arbitrary time ranges using Unix timestamps, epochs, or slots — exclusively for [Scale and Enterprise plans](https://beaconcha.in/pricing). beaconcha.in POST /api/v2/ethereum/validators/apy-roi. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns all slot numbers where the specified validators were assigned attestation duties, grouped by slot. Each result shows a slot number and the count of your validators that attested in that slot. This is useful for tracking when your validators attested and identifying slots where they may have missed attestations. For example, querying one epoch with 200 validators returns up to 32 results (one per slot in the epoch) rather than 200 individual validator-slot pairs. Combine this endpoint with others for deeper insights: - Consensus slot information: [v2/ethereum/slot](https://docs.beaconcha.in/api-reference/ethereum/slot/overview) This endpoint serves as a high-level overview, while other endpoints provide detailed data for specific slots or validators. Results can be filtered by a time range. Note: This endpoint supports **only finalized** data at this time. beaconcha.in POST /api/v2/ethereum/validators/attestation-slots. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the balances for a set of validators at a particular epoch beaconcha.in POST /api/v2/ethereum/validators/balances. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the optimal window for node maintenance with the lowest predicted impact on BeaconScore® and rewards for a pre-computed set of validators, considering the current and next epoch. The endpoint analyzes upcoming validator duties (attestation, proposal, sync committee) and predicts, for the next two epochs, the time range where missing a sequence of slots would have the least negative effect on your BeaconScore® and earnings. - The response includes a recommended maintenance window, warnings if a proposal or sync committee duty is imminent, and a "try next" field indicating when new predictions will be available (e.g., after the next epoch transition). - If a sync committee period is about to start in the next epoch, the endpoint will recommend maintenance now, as the next safe window may not occur for ~28 hours. - The algorithm simulates missing x sequential slots and identifies the period with minimal predicted loss. **Fields:** - `best_maintenance_window`: The suggested time range for maintenance. - `warning`: Alerts for upcoming proposal or sync committee duties that may impact risk. - `try_next`: Timestamp when new predictions will be available (e.g., after exporter finishes processing the next epoch). **Note:** The optimal window is based on the latest available duty assignments, which are only known one epoch in advance and may change as new data is processed. beaconcha.in POST /api/v2/ethereum/validators/best-maintenance-window. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a list of deposit events for your selected validators. Use this endpoint to quickly identify all relevant deposits for your validator set. You can combine this endpoint with: - Deposit detail from slot: [v2/ethereum/slot/deposits](https://docs.beaconcha.in/api-reference/ethereum/slot/deposits) - Consensus slot information: [v2/ethereum/slot](https://docs.beaconcha.in/api-reference/ethereum/slot/overview) Note: [v2/ethereum/slot/deposits](https://docs.beaconcha.in/api-reference/ethereum/slot/deposits) returns deposits by the slot they were **processed** in. Rows whose `observed_stages` do not include `consensus_layer_processed` describe a deposit that was still queued at that slot and cannot be looked up there. To get only rows with detail available, set `stage_filter: ["consensus_layer_processed"]`. Results can be filtered by a time range. beaconcha.in POST /api/v2/ethereum/validators/deposit-slots. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns metadata for a set of validators, including their index, public key, deposit address, withdrawal address, entity, and sub-entity. **Use case guide:** [Entity benchmarking](https://docs.beaconcha.in/use-cases/entity-benchmarking-overview) uses validator metadata to map validators to public entities and sub-entities. Results are paginated with a default and maximum page size of 10. Ideal for discovering validator associations; use the results to supply filters in other endpoints via the validator selector. **Note:** Entity and sub-entity assignments are updated once per day. **Premium Endpoint:** This endpoint requires a Scale or Enterprise plan. beaconcha.in POST /api/v2/ethereum/validators/metadata. Read-only: POST is how the V2 API takes a query body; nothing is changed.

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](https://docs.beaconcha.in/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 `range.evaluation_window`). Omit `range` to use it. **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. beaconcha.in POST /api/v2/ethereum/validators/mev-timing-aggregate. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns aggregated performance metrics for a known collection or group of validators. Known collections are referenced by index, public key, deposit address, or withdrawal address. **Use case guide:** [Validator performance](https://docs.beaconcha.in/use-cases/performance-introduction) explains how to monitor BeaconScore®, select evaluation windows, and compare validator sets. This endpoint includes the **BeaconScore®** metric, which measures how well validators perform their duties. Learn more about [how BeaconScore® is calculated](https://docs.beaconcha.in/beaconscore/introduction). **Custom time ranges:** Query arbitrary time ranges using Unix timestamps, epochs, or slots — exclusively for [Scale and Enterprise plans](https://beaconcha.in/pricing). Custom ranges are served at whole-UTC-day granularity (partial days are rounded outward), and the response `range` reports the actual covered range. beaconcha.in POST /api/v2/ethereum/validators/performance-aggregate. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a list of a validator's performance for a specific epoch for a set of validators. **Use case guide:** [Validator performance](https://docs.beaconcha.in/use-cases/performance-introduction) explains when to use per-epoch performance and how it complements the aggregate endpoint. This endpoint includes the **BeaconScore®** metric, which measures how well validators perform their duties. Learn more about [how BeaconScore® is calculated](https://docs.beaconcha.in/beaconscore/introduction). beaconcha.in POST /api/v2/ethereum/validators/performance-list. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a list of block proposal slots during which one or more of your selected validators were assigned a proposal duty. Use this endpoint to quickly identify all relevant proposals for your validator set, making it easier to explore proposal performance and related activity. You can combine this endpoint with: - Reward: [v2/ethereum/block/rewards](https://docs.beaconcha.in/api-reference/ethereum/block/rewards) - Consensus slot information: [v2/ethereum/slot](https://docs.beaconcha.in/api-reference/ethereum/slot/overview) - Execution block information: [v2/ethereum/block](https://docs.beaconcha.in/api-reference/ethereum/block/overview) or use it alongside reward and performance endpoints for deeper analysis, depending on your needs. Results can be filtered by a time range. Note: This endpoint supports **only finalized** data at this time. beaconcha.in POST /api/v2/ethereum/validators/proposal-slots. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Provides a rough overview of staking-related queue positions (deposit, exit, full withdrawal, consolidation, compounding switch) and estimated wait times for the selected set of validators. **Use case guide:** [Queue tracking](https://docs.beaconcha.in/use-cases/queue-tracking) explains when to use per-validator ETAs and how they complement the network queue view. Uses the same unified schema as the network-level queue endpoint The `estimated_processed_at` field in each queue always refers to the very last item for that validator. For example, if a validator has multiple pending deposits, `estimated_processed_at` in `deposit_queue` refers to when the last deposit will be processed. `compounding_switch_queue` is the exception: it refers to the validator's **earliest** pending switch request, because the switch takes effect when the first one is processed and any later request is a no-op. For network-wide queue statistics across all validators, see [/api/v2/ethereum/queues](https://docs.beaconcha.in/api-reference/ethereum/queues). beaconcha.in POST /api/v2/ethereum/validators/queues. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a paginated list of compounding switch requests for the selected validators. A compounding switch changes a validator's withdrawal credential prefix from `0x01` to `0x02`, unlocking effective balances above 32 ETH (up to 2048 ETH). Unlike a consolidation, the validator stays active throughout — no exit, no balance transfer. This endpoint covers **self-consolidation requests only** (source pubkey equals target pubkey). For cross-validator consolidations where one validator's balance is merged into another, use [/api/v2/ethereum/validators/queues/consolidations](https://docs.beaconcha.in/api-reference/ethereum/validators/queues/consolidations). A `pending` entry becomes `completed` or `rejected` once the consensus layer picks the request up out of the execution-layer contract, which releases at most two requests per block. Unlike consolidations, switches have no intermediate queued phase — they are accepted or rejected immediately at consensus-layer inclusion. Pending entries appear first. Completed and rejected entries follow, ordered by submission time (most recent first). Use `status_filter` to narrow the response to a single status, e.g. only `rejected` entries. Use this endpoint alongside the queue overview at [/api/v2/ethereum/validators/queues](https://docs.beaconcha.in/api-reference/ethereum/validators/queues) for a complete picture. **Temporary restriction:** the validator selector must resolve to no more than 50,000 validators. A larger selection returns `400`. Narrow the selection — for example, select a sub-entity instead of a whole entity — or page through it with a set of validator indices. This limit will be raised. beaconcha.in POST /api/v2/ethereum/validators/queues/compounding-switches. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a flat, paginated list of consolidation requests involving the selected validators, whether as source (balance being merged away) or as target (balance being received). The response is not limited to requests that are still in flight: it covers the complete history of consolidations for the selected validators, back to the Pectra fork (7 May 2025). Pass `status_filter: completed` to retrieve only consolidations that have already settled. Each entry pairs a source validator with a target validator. A single validator may appear in multiple entries across both roles. Use `role_filter` to keep only the entries where a selected validator is the source, or only those where it is the target — for example, to list every validator that was ever merged into a given target validator. Which fields an entry carries depends on its `status`: | `status` | Fields set | |---|---| | `pending` | `execution_layer` — the submitting transaction | | `queued` | `source_exit_at`, `estimated_processed_at` | | `completed` | `amount`, `processed_slot` | | `rejected` | `reject_reason` | A `pending` entry becomes `queued` once the consensus layer picks the request up out of the execution-layer contract, which releases at most two consolidation requests per block. Pending and queued entries appear first, ordered by queue position (soonest processed first). Completed and rejected entries follow, ordered by submission time (most recent first). Use `status_filter` to narrow the response to a single status, e.g. only `rejected` entries. A rejected entry whose `reject_reason` is `source_equals_target` is not a failed consolidation — it is a failed switch to compounding credentials, which the consensus layer reports through the consolidation path because both requests share one contract and one structure. A common cause is asking a validator that already has `0x02` credentials to switch again. Use [/api/v2/ethereum/validators/queues/compounding-switches](https://docs.beaconcha.in/api-reference/ethereum/validators/queues/compounding-switches) to retrieve those entries as switches. Use this endpoint in combination with the queue overview at [/api/v2/ethereum/validators/queues](https://docs.beaconcha.in/api-reference/ethereum/validators/queues) for a complete picture. **Temporary restriction:** the validator selector must resolve to no more than 50,000 validators. A larger selection returns `400`. Narrow the selection — for example, select a sub-entity instead of a whole entity — or page through it with a set of validator indices. This limit will be raised. beaconcha.in POST /api/v2/ethereum/validators/queues/consolidations. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a flat, paginated list of individual pending deposits for the selected validators. Each entry represents a single deposit or top-up with its amount, estimated processing time, and current stage. A validator may appear multiple times if it has multiple pending deposits or top-ups. Results are ordered by soonest deposit first (ascending). Use this endpoint in combination with the queue overview at [/api/v2/ethereum/validators/queues](https://docs.beaconcha.in/api-reference/ethereum/validators/queues) for a complete picture. The overview endpoint provides a rough summary with `estimated_processed_at` referring to the last deposit for each validator; this endpoint provides the full breakdown. beaconcha.in POST /api/v2/ethereum/validators/queues/deposits. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a flat, paginated list of individual pending exits and partial withdrawals for the selected validators. Each entry is either a full exit or a partial withdrawal, but not both. For full exits, the `exit` object contains exit timing and last duty details. For partial withdrawals, the `amount` field contains the withdrawal amount. Both types include estimated eligibility and completion times. A validator may appear multiple times for multiple partial withdrawals, but at most once for a full exit. Results are ordered by soonest exit/withdrawal first (ascending). Use this endpoint in combination with the queue overview at [/api/v2/ethereum/validators/queues](https://docs.beaconcha.in/api-reference/ethereum/validators/queues) for a complete picture. The overview endpoint provides a rough summary with `estimated_processed_at` referring to the last exit for each validator; this endpoint provides the full breakdown. beaconcha.in POST /api/v2/ethereum/validators/queues/withdrawals. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns the cumulative rewards for a set for a known collection or group of validators. Known collections are referenced by index, public key, deposit address, or withdrawal address. **Use case guide:** [Validator rewards](https://docs.beaconcha.in/use-cases/rewards-introduction) explains when to use aggregate rewards and how to turn the response into reports and comparisons. Use [Rewards](https://docs.beaconcha.in/api-reference/ethereum/validators/rewards-list) for a rewards breakdown of each validator. Note: Only finalized epochs are supported for rewards data. **Attribution Required:** If you display BeaconScore® data publicly, you must include appropriate attribution. See our [BeaconScore® License](https://docs.beaconcha.in/legal/beaconscore-license) and [License Materials](https://docs.beaconcha.in/legal/license-materials) for badges and usage guidelines. **Custom time ranges:** Query arbitrary time ranges using Unix timestamps, epochs, or slots — exclusively for [Scale and Enterprise plans](https://beaconcha.in/pricing). Custom ranges are served at whole-UTC-day granularity (partial days are rounded outward), and the response `range` reports the actual covered range. beaconcha.in POST /api/v2/ethereum/validators/rewards-aggregate. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a breakdown of rewards for each validator for a given epoch. **Use case guide:** [Validator rewards](https://docs.beaconcha.in/use-cases/rewards-introduction) explains when to use per-epoch rewards and links to custom-range, tax, and missed-reward workflows. Use [Rewards Aggregated](https://docs.beaconcha.in/api-reference/ethereum/validators/rewards-aggregate) for a cumulative view of all validator rewards combined. Note: Only finalized epochs are supported for rewards data. **Attribution Required:** If you display BeaconScore® data publicly, you must include appropriate attribution. See our [BeaconScore® License](https://docs.beaconcha.in/legal/beaconscore-license) and [License Materials](https://docs.beaconcha.in/legal/license-materials) for badges and usage guidelines. beaconcha.in POST /api/v2/ethereum/validators/rewards-list. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Claims up to 1000 validator public keys for the entity assigned to the authenticated user on the requested chain. The caller must have an active self-report assignment for the requested chain, and every validator public key in the request must exist on that chain. To get a self-report assignment, contact beaconcha.in support with the API user that will submit claims and the entity/sub-entity name to assign. This endpoint returns forbidden until the assignment is active. Each validator can optionally specify a `sub_entity`. The server trims surrounding whitespace from `sub_entity`; if it is omitted or empty after trimming, the server uses the caller's assignment-level default sub-entity. Duplicate validator public keys with the same resolved `sub_entity` are deduplicated before persistence. Duplicate validator public keys with conflicting resolved `sub_entity` values return a bad request error. Re-submitting validators that are already claimed by the same entity with the same resolved sub-entity reaffirms the existing claim and leaves its entity and sub-entity unchanged. Re-submitting validators that are already claimed by the same entity with a different resolved sub-entity updates the stored sub-entity. If any validator in the batch is already claimed by a different entity, the request returns a conflict error and no claims from the request are applied. **Note:** Accepted unique claims are persisted immediately, but visibility in downstream validator entity metadata and aggregate views remains eventually consistent with the next validator tagger/precompute cycle. beaconcha.in POST /api/v2/ethereum/validators/self-report. WRITES: persists validator claims for the account's assigned entity immediately.

Returns a deduplicated list of sync committee periods during which one or more of your selected validators were assigned sync committee duties. Use this endpoint to quickly identify all relevant periods for your validator set, making it easier to explore sync committee participation and related activity. You can combine this endpoint with: - Resolve to slots/epochs: [v2/ethereum/sync-committee](https://docs.beaconcha.in/api-reference/ethereum/sync-committee/overview) - Sync Duties at slot: [v2/ethereum/slot/sync-committee-duties](https://docs.beaconcha.in/api-reference/ethereum/slot/sync-committee-duties) or use it alongside reward and performance endpoints for deeper analysis, depending on your needs. Results can be filtered by a time range. Note: The `range` in the response spans only the first to the last sync committee period your validators were assigned to — not the full chain history. A validator assigned during periods 370–1218, for example, returns a range covering just those periods. Note: This endpoint supports **only finalized** data at this time. beaconcha.in POST /api/v2/ethereum/validators/sync-committee-periods. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns all upcoming duty slots for a pre-computed set of validators for the current and next epoch. This includes attestation, proposal, and sync committee duties. The protocol allows you to preview upcoming validator duties up to one epoch in advance. At the end of the current epoch, duties for the next epoch become visible; at the start of the current epoch, both the current and next epoch's duties are available. Depending on when you query, you may see between 32 and 64 upcoming slots. You might want to make multiple queries over time depending on your usecase. You can combine this endpoint with: - Consensus slot information: [v2/ethereum/slot](https://docs.beaconcha.in/api-reference/ethereum/slot/overview) - Consensus sync-committee duties at slot: [v2/ethereum/slot/sync-committee-duties](https://docs.beaconcha.in/api-reference/ethereum/slot/sync-committee-duties) - Consensus attestation duties at slot: [v2/ethereum/slot/attestation-duties](https://docs.beaconcha.in/api-reference/ethereum/slot/attestation-duties) beaconcha.in POST /api/v2/ethereum/validators/upcoming-duty-slots. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Returns a list of withdrawal events for your selected validators. Use this endpoint to quickly identify all relevant withdrawals for your validator set. You can combine this endpoint with: - Withdrawal detail from slot: [v2/ethereum/slot/withdrawals](https://docs.beaconcha.in/api-reference/ethereum/slot/withdrawals) - Consensus slot information: [v2/ethereum/slot](https://docs.beaconcha.in/api-reference/ethereum/slot/overview) Note: [v2/ethereum/slot/withdrawals](https://docs.beaconcha.in/api-reference/ethereum/slot/withdrawals) returns withdrawals by the slot they were **processed** in. Rows whose `observed_stages` do not include `consensus_layer_processed` describe a withdrawal request that was still queued at that slot and cannot be looked up there. To get only rows with detail available, set `stage_filter: ["consensus_layer_processed"]`. Results can be filtered by a time range. beaconcha.in POST /api/v2/ethereum/validators/withdrawal-slots. Read-only: POST is how the V2 API takes a query body; nothing is changed.

Retrieve machine monitoring metrics for the authenticated user. Returns system, validator client, and beacon node metrics that were previously pushed via the `--monitoring-endpoint` flag and set up via https://beaconcha.in/user/settings#app. Users can only access metrics belonging to their own API key. Optionally filter by one or more machine names. Provide a time range via unix timestamps to query a specific historical window (maximum 31 days, limited by data retention). Each array is ordered newest first, then paginated toward older data. Pagination uses an opaque continuation token that tracks the last emitted `(timestamp, machine)` tuple separately for `system_metrics`, `validator_metrics`, and `node_metrics`. Clients must treat `paging.next_cursor` as opaque. beaconcha.in POST /api/v2/machine-metrics. Read-only: POST is how the V2 API takes a query body; nothing is changed. Machine metrics belong to the account rather than a network; `chain` is still required here and does not select the data.

List all known machine names for the authenticated user. These are the names that were provided when pushing metrics via the `--monitoring-endpoint` flag. beaconcha.in POST /api/v2/machine-metrics/machine-names. Read-only: POST is how the V2 API takes a query body; nothing is changed. Machine metrics belong to the account rather than a network; `chain` is still required here and does not select the data.