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.
Slot number of the beacon state snapshot the queue was read from.
slot_timestamp
TIMESTAMP_NTZ(9)
Timestamp of the slot the queue was read from.
epoch_number
NUMBER(38,0)
Epoch number derived from slot_number.
source_index
NUMBER(38,0)
Validator index of the source validator (the one being consolidated away).
target_index
NUMBER(38,0)
Validator index of the target validator (the one receiving the merged balance).
source_effective_balance
FLOAT
Effective balance (ETH) of the source validator at the snapshot.
target_effective_balance
FLOAT
Effective balance (ETH) of the target validator at the snapshot.
merged_effective_balance
FLOAT
Sum of source and target effective balances — the target’s approximate effective balance once the consolidation is processed.
source_exit_epoch
NUMBER(38,0)
Exit epoch assigned to the source validator when the consolidation was accepted into the queue.
est_exit_timestamp
TIMESTAMP_NTZ(0)
Estimated timestamp corresponding to source_exit_epoch.
source_withdrawable_epoch
NUMBER(38,0)
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
NUMBER(38,0)
source_withdrawable_epoch minus the current epoch, floored at 0.
est_processing_timestamp
TIMESTAMP_NTZ(0)
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
NUMBER(25,2)
Estimated hours from now until est_processing_timestamp, based on the current time at query time.
queue_status
VARCHAR(15)
One of processable, waiting, blocked, skipped_slashed. See Queue status semantics below.
cumulative_eth_in_queue
FLOAT
Running sum of source_effective_balance ordered by queue position, up to and including this entry.
source_address
VARCHAR(16777216)
Execution-layer address that submitted the consolidation request, from the matched beacon.raw.consolidations row.
request_slot
NUMBER(38,0)
(Nullable) Slot of the beacon block that dequeued this consolidation request from the EIP-7251 predeploy contract into execution_requests. Not the EL submission slot. For batched consolidations, this is typically later than the submission slot because the predeploy contract releases at most 2 requests per block — validators near the back of a large batch see a slot many blocks after the submission transaction.
request_timestamp
TIMESTAMP_NTZ(9)
(Nullable) Timestamp of the beacon block at request_slot. Not the timestamp of the original EL submission transaction.
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.
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.
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.
request_slot is the beacon dequeue slot, not the EL submission slot. If you need the slot of the original submission transaction, join to ethereum.raw.traces on to_address = '0x0000bbddc7ce488642fb579f8b00f3a590007251' and match on source/target pubkeys extracted from input.
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.
Was this page helpful?
Assistant
Responses are generated using AI and may contain mistakes.
