Validator
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).
Use status_filter to return only validators in the listed lifecycle statuses, for example ["active"] for the currently active validators of an entity or a withdrawal address. Statuses are evaluated at the same epoch as the rest of the response. When the selected validators exist but none of them has a matching status, the response is 200 with an empty data array. The filter reads lifecycle data that is refreshed after each epoch, so a validator that was just deposited or slashed can take up to about one epoch to match it; the returned status always matches the filter. For the same reason a filtered page can hold fewer entries than page_size, even none, while next_cursor is set; keep paging until next_cursor is empty.
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 Cursor value for pagination. See our pagination guide for more details.
The number of items to return per page.
1 <= x <= 10Return only validators whose current status matches one of the listed values. Pass exact statuses, groups (pending, active, exited, withdrawal), or both. Omit the field (or pass an empty array) to return validators in every status.
A validator lifecycle status to filter by. Four values select a group of statuses:
pending:pending_initializedandpending_queued.active:active_ongoing,active_exitingandactive_slashed.exited:exited_unslashedandexited_slashed.withdrawal:withdrawal_possibleandwithdrawal_done.
Every other value selects the single status of the same name, as reported in the status field of the response.
pending, active, exited, withdrawal, pending_initialized, pending_queued, active_ongoing, active_exiting, active_slashed, exited_unslashed, exited_slashed, withdrawal_possible, withdrawal_done Response
Successful response.
Response containing basic information about the validator.
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.

