Validator Queue Consolidation Details
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 to retrieve those entries as switches.
Use this endpoint in combination with the queue overview at /api/v2/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.
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 <= 10Filter results to a single consolidation status. If not specified, results include all statuses.
pending: recorded on the execution layer; not yet picked up by the consensus layer.queued: included by the consensus layer; the source validator is exiting.completed: balance sweep finalized.rejected: rejected at consensus-layer inclusion.
pending, queued, completed, rejected "rejected"
Restrict results to the role the selected validators play in the consolidation. If not specified, a validator matches in either role.
source: only requests where a selected validator is the source — the validator that exits and whose balance is merged away.target: only requests where a selected validator is the target — the validator that stays active and receives the balance.
A validator is usually only ever one or the other, because a source validator exits as part of the consolidation. Use this filter when you want that guarantee rather than checking source_validator and target_validator yourself, or to avoid paging through the other role's entries for a validator that has served in both.
source, target "target"

