---
title: "Get the deposit status of a batch of validator pubkeys"
method: POST
path: "/v1/validators/{network}/deposit-status"
tags: ["Validators"]
---

# Get the deposit status of a batch of validator pubkeys

`POST /v1/validators/{network}/deposit-status`

## Request

- Base URL: `https://api.obol.tech`
- URL: `https://api.obol.tech/v1/validators/{network}/deposit-status`
- Auth: none declared

What our beacon node's head state holds for each pubkey: the validator registry entry (status, balances, activation and exit epochs), every deposit in the pending deposit queue (EIP-6110), each with its own withdrawal credentials, and the total queued in the pending partial withdrawal queue (EIP-7002). Returns one entry per distinct requested pubkey, in request order, including pubkeys with status `new`. Accepts up to 1000 pubkeys per request (96 hex characters, 0x prefix optional, case-insensitive). Amounts are wei decimal strings. Queued deposit signatures are verified in the background, each queue entry once; a queue-only pubkey whose deposits are not all verified yet has `signaturesPending: true` (retry for the complete answer). Any upstream failure fails the whole request so a partial answer can never read as `new`. Entries are cached per pubkey for one slot.

## Path parameters

- `network` string, required

## Request body

- DepositStatusRequestDto
  - `pubkeys` string[], required: Validator BLS pubkeys (96 hex chars, 0x prefix optional). Max 1000 per request.

## Response `200`

Deposit status per requested pubkey

- ValidatorDepositStatusResponse
  - `validators` ValidatorDepositStatusDto[], required: One entry per distinct requested pubkey (case-insensitive), in request order.
    - `pubkey` string, required: 0x-prefixed lowercase validator BLS pubkey
    - `status` 'new' | 'queued' | 'active' | 'exited', required: new: not in the validator registry and nothing queued. queued: only in the pending deposit queue, or registry status pending_initialized / pending_queued. active: registry status active_*. exited: registry status exited_* or withdrawal_*.
    - `beaconStatus` string, nullable, required: Raw beacon API status (pending_initialized, pending_queued, active_ongoing, active_exiting, active_slashed, exited_unslashed, exited_slashed, withdrawal_possible, withdrawal_done), or pending_deposit when the pubkey is only in the pending deposit queue (EIP-6110). Null for status new.
    - `index` string, nullable, required: Validator index. Null unless the pubkey is in the registry.
    - `balance` string, nullable, required: Balance in wei (decimal string). Null unless the pubkey is in the registry.
    - `effectiveBalance` string, nullable, required: Effective balance in wei (decimal string). Null unless the pubkey is in the registry.
    - `activationEpoch` string, nullable, required: Epoch at which the validator was (or will be) activated, as a decimal string. Null unless the pubkey is in the registry, and while no activation epoch is assigned yet (FAR_FUTURE_EPOCH, e.g. pending_initialized).
    - `exitEpoch` string, nullable, required: Epoch at which the validator exits (or exited), as a decimal string. Null unless the pubkey is in the registry, and while no exit is initiated (FAR_FUTURE_EPOCH).
    - `pendingPartialWithdrawals` string, required: Sum of the validator's entries in the beacon chain's pending partial withdrawal queue (EIP-7002), in wei (decimal string). "0" when none, and for a pubkey not in the registry.
    - `withdrawalCredentials` string, nullable, required: The registry entry's withdrawal credentials; for a pubkey only in the queue, those of its first queued deposit with a valid signature (the validator is created with them; queued deposits with an invalid signature are dropped). Null for status new, for a queue-only pubkey with no validly signed queued deposit, and while the deposits up to the first valid one are not verified yet (signaturesPending).
    - `credentialsConflict` boolean, nullable, required: True when the pubkey is only in the queue and its queued deposits with valid signatures carry different withdrawal credentials: someone able to sign for the key signed a deposit for other credentials. Only the first valid one applies. Always false for a pubkey in the registry (its credentials are fixed) or with nothing queued. Null while signaturesPending.
    - `signaturesPending` boolean, required: True when the pubkey is only in the queue and some of its queued deposit signatures have not been verified yet. Signatures are verified in the background, each queue entry once, usually within a slot; until then those deposits have signatureValid null, credentialsConflict is null, and withdrawalCredentials is null unless already decided by a verified first valid deposit. Retry for the complete answer. Always false for registered and new pubkeys.
    - `pendingDeposits` PendingDepositDto[], required: Every deposit queued for this pubkey (initial deposits and top-ups), in queue order, each with its own withdrawal credentials and signature check. Empty when nothing is queued.
      - `amount` string, required: Deposit amount in wei (decimal string)
      - `withdrawalCredentials` string, required: Withdrawal credentials of this deposit
      - `signatureValid` boolean, nullable, required: Whether the deposit's BLS signature (DepositMessage in the deposit domain, the network's genesis fork version) is valid. For a pubkey not yet in the registry, the beacon chain drops queued deposits with an invalid signature until the first valid one creates the validator. Null when not checked: the pubkey is already in the registry, so the deposit is a top-up and its signature does not matter; or the background check has not reached it yet (signaturesPending).

## Other responses

- `400`: Unsupported network or malformed pubkeys
- `429`: Rate limited (either this API or the upstream)
- `500`: Internal server error
- `502`: Beacon node request failed or returned a malformed answer

## Changes

- **2026-10-28** `c545dd14c211`: 4 info
  - added the media type `application/json` for the response with the status `400`
  - added the media type `application/json` for the response with the status `429`
  - added the media type `application/json` for the response with the status `500`
  - added the media type `application/json` for the response with the status `502`
- **2026-10-22** `ffbd09536a1a`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/obol/apis/obol-api/changes/v1/validators/:network/deposit-status/post.md)

---

[API](https://skmtc.dev/obol/apis/obol-api.md) - [All operations](https://skmtc.dev/obol/apis/obol-api/llms.txt) - [OpenAPI document](https://skmtc.dev/obol/apis/obol-api/revisions/74b8e410bd85?raw)