Consolidation Queue Latest

The beacon.validator.consolidation_queue_latest model provides the current snapshot of validators pending consolidation (EIP-7251, Pectra upgrade), along with an estimated processing timestamp for each entry. Consolidation lets a validator with execution withdrawal credentials (source) merge its balance into a validator with compounding credentials (target), effectively raising the target’s effective balance above 32 ETH. This model is derived from the beacon state’s authoritative pending_consolidations list (beacon.raw.pending_consolidations), enriched with validator state from beacon.validator.balances_latest and request provenance from beacon.raw.consolidations, and is updated approximately every 30 minutes.

This is batch data snapshot with approximate consolidation processing times, not a live queue. The queue can be up to ~15-30 minutes stale relative to chain head, and every est_*/hours_until_* timing field is a best-effort estimate, not a guarantee. Do not treat this table as real-time or exact — see Caveats below before building alerts or SLAs on it.

Schema

Column Name	Type	Description
slot_number	bigint	Slot number of the beacon state snapshot the queue was read from.
slot_timestamp	timestamp	Timestamp of the slot the queue was read from.
epoch_number	bigint	Epoch number derived from `slot_number`.
source_index	bigint	Validator index of the source validator (the one being consolidated away).
target_index	bigint	Validator index of the target validator (the one receiving the merged balance).
source_effective_balance	numeric	Effective balance (ETH) of the source validator at the snapshot.
target_effective_balance	numeric	Effective balance (ETH) of the target validator at the snapshot.
merged_effective_balance	numeric	Sum of source and target effective balances — the target’s approximate effective balance once the consolidation is processed.
source_exit_epoch	bigint	Exit epoch assigned to the source validator when the consolidation was accepted into the queue.
est_exit_timestamp	timestamp	Estimated timestamp corresponding to `source_exit_epoch`.
source_withdrawable_epoch	bigint	Epoch at which the source validator becomes withdrawable (`source_exit_epoch` + 256-epoch withdrawability delay). This is the epoch that actually gates processing, not `source_exit_epoch`.
epochs_until_withdrawable	bigint	`source_withdrawable_epoch` minus the current epoch, floored at 0.
est_processing_timestamp	timestamp	Estimated timestamp this consolidation is processed. For entries with no blocker ahead of them, this equals the timestamp of `source_withdrawable_epoch`; for `blocked` entries it is the later of their own withdrawable time and the blocking entry’s.
hours_until_processing	numeric	Estimated hours from now until `est_processing_timestamp`, based on the current time at query time.
queue_status	string	One of `processable`, `waiting`, `blocked`, `skipped_slashed`. See Queue status semantics below.
cumulative_eth_in_queue	numeric	Running sum of `source_effective_balance` ordered by queue position, up to and including this entry.
source_address	string	Execution-layer address that submitted the consolidation request, from the matched `beacon.raw.consolidations` row.
request_slot	bigint	(Nullable) Slot at which the consolidation request was included in a block.
request_timestamp	timestamp	(Nullable) Timestamp of `request_slot`.
source_details	object	JSON object with the source validator’s `pubkey`, `status`, `activation_epoch`, `withdrawal_credentials`, `slashed`, and `raw_balance_gwei`.
target_details	object	JSON object with the target validator’s `pubkey`, `status`, `activation_epoch`, `exit_epoch`, `withdrawable_epoch`, `slashed`, `withdrawal_credentials`, and `raw_balance_gwei`.
execution_optimistic	boolean	Whether the beacon state used for this snapshot was optimistic (not yet fully verified) at the time of the API call.
finalized	boolean	Whether the beacon state used for this snapshot was finalized at the time of the API call.

Queue status semantics

Processing mirrors the protocol’s process_pending_consolidations() loop, which walks the queue in order and stops at the first entry that isn’t yet withdrawable:

Status	Meaning
`processable`	Not slashed, no blocker ahead of it, and `source_withdrawable_epoch` has already passed — will process next epoch.
`waiting`	Not slashed but `source_withdrawable_epoch` is still in the future. This entry breaks the queue: everything behind it is frozen regardless of its own readiness.
`blocked`	Would otherwise be processable on its own, but sits behind a `waiting` entry and cannot be processed until that entry clears.
`skipped_slashed`	Source validator was slashed. Slashed entries are skipped (not blocking) — the queue advances past them.

Caveats

Snapshot, not a live feed — expect ~30 minute latency. This is the queue as of the most recent beacon state slot with a complete set of pending-consolidation rows ingested (validated by comparing ingested row count against the beacon node’s reported pending_consolidation_count for that slot), and the model itself is refreshed on an ~30 minute cadence. If ingestion lags further, the snapshot can be even further behind chain head — always check slot_timestamp before relying on absolute counts or timings, and don’t use this table for anything requiring sub-epoch or real-time accuracy.
request_slot/request_timestamp can be NULL. These come from a best-effort join to beacon.raw.consolidations (the execution-layer request event), matched on source/target pubkey with the earliest matching request preferred. If the originating request predates the indexed history window, or a match can’t be uniquely resolved, these fields are null — this does not affect queue position or processing estimates, which come from the queue itself.
Post-Pectra only. Consolidation didn’t exist before the Pectra upgrade — there is no historical backfill prior to it, and the queue is only ever non-empty from that point forward.
Once processed, an entry disappears from this table. This model only shows what is currently pending — it is not a historical log of consolidations.
All timing fields are approximate, not guarantees. est_exit_timestamp, est_processing_timestamp, and hours_until_processing assume no further slashing, no new consolidations displacing queue dynamics, and a constant ~12s slot time. Actual processing can shift if upstream entries get slashed (removed), if new epochs process faster/slower than assumed, or if the underlying snapshot itself is stale — treat these as directional estimates, not precise predictions, and re-query close to the time you need an answer rather than caching results.

Example Query

This query shows the estimated processing timestamp and queue status for a given source validator.

SELECT
  source_index,
  target_index,
  queue_status,
  est_processing_timestamp,
  datediff('hours', current_timestamp, est_processing_timestamp) as hours_until_processing
FROM beacon.validator.consolidation_queue_latest
WHERE source_index in ('') -- Insert source validator index here

Overview

Data Verticals

Solana

Hyperliquid

Lighter

Bitcoin Ecosystem

EVM

Cosmos Ecosystem

Move Ecosystem

Other Ecosystems

Schema

Queue status semantics

Caveats

Example Query

​Schema

​Queue status semantics

​Caveats

​Example Query

Schema

Queue status semantics

Caveats

Example Query