Validators
Returns the validators in the sync committee for a particular sync period, one entry per validator, ordered by validator index. Each entry’s sync_committee_indices holds the validator’s positions in the committee, which give the committee order.
Each validator has one vote per slot of the period. A vote counts as successful or missed once its epoch is finalized and processed; until then it is scheduled. A slot without a block takes the vote away from every member: it is left out of assigned and missed and counted only in missed_including_missed_slots.
The committee of the next period (view next) is known from the start of the current period. Its duties are all still scheduled: assigned and scheduled equal the number of slots in the period, and the other counts are 0.
You can combine this endpoint with:
- Sync Committee Period Overview:
v2/ethereum/sync-committee
Response can be filtered to a specific set of validators by providing optional validator identifiers in the request body.
Authorizations
Body
validator is optional in this request body
The Ethereum chain to query.
mainnet, hoodi Specify a sync committee period using one of the following methods.
- Sync committee period number
- View: "latest", "next"
- Number
- View
Cursor value for pagination. See our pagination guide for more details.
The number of items to return per page.
1 <= x <= 10validator is optional in this request body. If not provided, results will be unfiltered.
- Indices/Pubkeys
- Dashboard
- 💎 Deposit
- 💎 Withdrawal
- 💎 Entity
Response
Successful response.
Response containing the validators in the sync committee.
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.

