Validator queues now

See the validator queues in TraceFast →

Ethereum's validator queues right now, as the Electra rules run them: the deposits waiting to enter, the exit and consolidation queues, the partial withdrawals waiting to be paid, each in entries and in capital, with the per-epoch churn that drains them and how long that takes. Beside them, the validator counts by status, with trailing averages, and the exit and deposit flow that recently landed in blocks. Only observed facts and arithmetic over them — no score, no verdict, no forecast.

The queues drain at a limited balance per epoch (about 6.4 minutes). The mechanics are explained in the Ethereum proof-of-stake docs.

GET https://tracefast.xyz/api/v1/chains/1/consensus/current

The method takes no parameters.

Access — an API key on the Intelligence plan or higher (plans), or no key at all: pay per call with x402 at the same path on https://mpp.tracefast.xyz/api/v1, at the price its 402 states. As a tool for AI agents: get_validator_queues on the MCP server. Stable — see stability.

chains/1 is a literal: the method serves Ethereum mainnet data. Other chain ids answer 404 chain_not_supported, and an unknown query parameter is refused rather than ignored.

What it covers, and what it does not

The queues are in queues; status counts are not queues. Since Electra a validator's status no longer says whether it waits: a deposit waits as a balance in the deposit queue, not as a pending validator, and the exiting status also holds consolidation sources. queues is read from the chain's own pending lists. status keeps the counts by status — useful, but read status.pendingActivation as a queue and you will miss nearly all of it.
Wait times are estimates of the queue as a whole: its balance divided by the per-epoch churn. They are not a promise to any one validator, ignore finality and deposit-inclusion delays, and move with the queue.
Validator-set mechanics only. No yield, no APR, no staking-pool or operator data.
Capital is in gwei, as decimal strings (1 ETH = 10^9 gwei). Counts are JSON integers.
Not yet sampled means null, never zero. A 30-day average is null until the sampled series spans 30 days; seriesStartTime and seriesSpanHours say how far it reaches.

Response

200 application/json:

{
  "data": {
    "chainId": 1,
    "asOfEpoch": 483380,
    "asOfTime": "2026-10-19T20:33:26Z",
    "queues": {
      "deposits": {
        "count": 16008,
        "gwei": "1182642016359495",
        "newValidators": { "count": 14861, "gwei": "941192166772238" },
        "topUps": { "count": 1147, "gwei": "241449849587257" }
      },
      "exitQueue": { "count": 3750, "gwei": "193204595956291" },
      "consolidations": { "count": 9017, "gwei": "694330896378892" },
      "partialWithdrawals": { "count": 230, "gwei": "11277248613950" },
      "exitedAwaitingWithdrawal": { "count": 1045, "gwei": "60988663443785" },
      "activeSet": { "count": 828537, "gwei": "43826023452914003" },
      "churn": {
        "activationExitGweiPerEpoch": "256000000000",
        "consolidationGweiPerEpoch": "412000000000"
      },
      "waitEstimates": {
        "entryEpochs": 4620,
        "exitEpochs": 755,
        "consolidationEpochs": 1686,
        "entryDays": 20.533333333333335,
        "exitDays": 3.3555555555555556,
        "consolidationDays": 7.493333333333333
      }
    },
    "totalActiveBalanceGwei": "43043853651991843",
    "flow": {
      "exits24h": 272,
      "exits7d": 4279,
      "exits30d": 35054,
      "deposits30d": 14881
    },
    "status": {
      "activeOngoing": 816835,
      "pendingActivation": 127,
      "pendingExit": 13812,
      "netQueue": -13685,
      "activationRate": 0.00015547815654324312,
      "exitRate": 0.01690916770216751,
      "pendingActivationGwei": "1858000000000",
      "pendingExitGwei": "948524155778968",
      "averages": {
        "pendingExit7d": 20207.41650793651,
        "pendingActivation7d": 231.88761904761904,
        "pendingExit30d": 18475.312148148147,
        "pendingActivation30d": 725.622962962963
      },
      "weighted": {
        "snapshotEpoch": 483292,
        "snapshotAgeEpochs": 88,
        "activation": {
          "validators": 98,
          "effectiveGwei": "1809000000000",
          "actualGwei": "1820820000000"
        },
        "exit": {
          "validators": 14375,
          "effectiveGwei": "934452000000000",
          "actualGwei": "934866685352429"
        }
      }
    },
    "seriesStartTime": "2026-08-11T20:21:01Z",
    "seriesSpanHours": 1656.2266666666667
  },
  "meta": {
    "chain": "ethereum",
    "timestamp": 1792442222348,
    "cached": true,
    "docs": "https://docs.tracefast.xyz/api/consensus-current"
  }
}

In this answer 127 validators are in the pending-activation status — yet 16,008 deposits worth about 1.18 million ETH wait in the deposit queue, about 20 days of churn. That gap is why the queues and the status counts are served apart.

`data`

Field	Meaning
`chainId`	`1`
`asOfEpoch`	the epoch the counters were sampled at
`asOfTime`	the start of that epoch, RFC 3339 UTC
`queues`	the queues by the Electra rules — see below. `null` when not sampled
`totalActiveBalanceGwei`	total effective balance of the active set, gwei. `queues.activeSet.gwei` is the actual balance of the same set, which the churn limits are computed from
`flow`	validator flow that landed in blocks — see below
`status`	validator counts by status, with averages and capital weights — see below
`seriesStartTime`	when sampling of the queues began, RFC 3339 UTC
`seriesSpanHours`	how long the sampled series spans now, in hours — whether a comparison with a 7-day or 30-day average can be made at all

`queues`

Each side is {count, gwei}: how many entries, and the actual balance (or amount) they carry, gwei. gwei is null when not sampled.

Field	Meaning
`deposits`	every pending deposit: `count` and total `gwei`, split into `newValidators` — the entry queue, deposits for a key not yet in the validator registry — and `topUps` of existing validators
`exitQueue`	validators waiting to exit
`consolidations`	pending consolidation requests — one validator's balance moving into another's
`partialWithdrawals`	pending partial-withdrawal requests
`exitedAwaitingWithdrawal`	validators already out of the active set whose balance is not yet withdrawn
`activeSet`	the active set: validators, and their actual balance
`churn`	the per-epoch limits, gwei, decimal strings: `activationExitGweiPerEpoch` — the budget deposits and exits each get; `consolidationGweiPerEpoch` — the budget consolidations get
`waitEstimates`	how long each queue takes to drain at the current churn — see below

`waitEstimates`

Queue balance divided by the per-epoch limit; the entry queue is also bounded by 16 deposits an epoch. Estimates of the queue as a whole, not a promise to any one validator: they ignore finality and deposit-inclusion delays and move with the queue. A value is null when it cannot be computed.

Field	Meaning
`entryEpochs`, `entryDays`	until every pending deposit is processed — what a deposit made now waits
`exitEpochs`, `exitDays`	until the exit queue drains
`consolidationEpochs`, `consolidationDays`	until the consolidation queue drains

`flow`

Flow, not queue depth: what actually landed in blocks. A value is null while its window has not been computed.

Field	Meaning
`exits24h`, `exits7d`, `exits30d`	validators that exited in the last 24 hours, 7 days, 30 days — voluntary and execution-layer requested exits summed
`deposits30d`	deposits that landed in the last 30 days

`status`

Validator counts by status. Before Electra these were the queues; since Electra they are not — read the queues in queues.

Field	Meaning
`activeOngoing`	validators in the active, ongoing status — exiting and slashed ones excluded. The whole active set is `queues.activeSet`
`pendingActivation`	validators in a pending-activation status
`pendingExit`	validators in an exiting status: the exit queue, consolidation sources and validators already out of the active set
`netQueue`	`pendingActivation - pendingExit`
`activationRate`, `exitRate`	`pendingActivation` and `pendingExit` as a fraction of `activeOngoing`
`pendingActivationGwei`, `pendingExitGwei`	actual balance of each status set, gwei. `null` when not sampled
`averages`	means over the epochs of each window, in validators: `pendingActivation7d`, `pendingActivation30d`, `pendingExit7d`, `pendingExit30d`. Each is `null` until the sampled series spans its window
`weighted`	the capital weight of both status sets at the registry snapshot — see below. Absent while the snapshot does not carry it

`status.weighted`

The registry is sampled daily, so the weights can be up to a day older than the counters beside them.

Field	Meaning
`snapshotEpoch`	the epoch of the registry snapshot the weights were summed at
`snapshotAgeEpochs`	how many epochs the snapshot trails `asOfEpoch`
`activation`, `exit`	one status set each: `validators` in it at the snapshot, `effectiveGwei` and `actualGwei`

effectiveGwei and actualGwei are two sums over the same validators and are not interchangeable: the effective balance is what the protocol weighs a validator by, the actual balance is comparable with other sources and runs slightly above it. For wait times, use queues.waitEstimates.

Errors

Status	`code`	When	`details`
503	`service_unavailable`	no queue state has been sampled yet; retry later	—

Malformed input, unknown parameters and the key check's 401/403/429 are the same for every method — see conventions and API keys.

Validator queues over time — the same queues as a daily series
Block-proposal leaderboard — who proposes blocks
Withdrawals of a validator — one validator's payouts
Validator withdrawals of one block — the withdrawals in a block
Validators — the same queues, read in the app

Last updated 22 Oct 2026, 08:06 UTC · verified against TraceFast v1.0.261 · Markdown

Validator queues now

What it covers, and what it does not

Response

data

queues

waitEstimates

flow

status

status.weighted