> ## Documentation Index > Fetch the complete documentation index at: https://docs.allium.so/llms.txt > Use this file to discover all available pages before exploring further. # Consolidation Queue Latest > Latest state of Ethereum beacon chain validator consolidation queue 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. ```sql theme={null} 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 ```