Status and allocations

Use /v1/status to assess the hosted service and /v1/allocations to display recent namespace claims. Both include a cached observed ledger; it is not proof that every displayed record is current.

Status

GET /v1/status

Returns ledger and a components array. This example illustrates the shape rather than current service status:

{
  "ledger": 55123001,
  "components": [
    { "name": "Database", "state": "operational" },
    { "name": "Stellar RPC", "state": "operational" },
    {
      "name": "Indexer",
      "state": "operational",
      "ledger": 55122999,
      "lag": 2,
      "processedAt": "2026-09-07T10:15:04.000Z",
      "deadLetters": 0
    }
  ]
}

Component semantics

Component	How to interpret it
Database	`operational` if the database check succeeds; otherwise `down`
Stellar RPC	`operational` after a nonzero ledger observation exists; otherwise `down`
Indexer	Reports stored progress, freshness and lag against the cached ledger

The RPC flag can remain operational after refresh failures because the API keeps its last successful observation. It does not prove current RPC reachability. Indexer fields provide more detail:

ledger is the last processed ledger.
lag is the difference from the cached head, clamped to zero; it is null when the comparison is unavailable.
processedAt is the last progress write time, or null before progress exists.
deadLetters counts unresolved indexing failures.

The indexer is operational when it has nonzero progress less than 120 seconds old and its known lag is below 200 ledgers. If lag is unavailable, freshness and progress still determine that state. An operational result does not prove complete history. Inspect /v1/coverage for freshness and gaps.

Extra components, when enabled

When billing or the marketplace is enabled on a deployment, the response can include Billing watcher or Escrow watcher.

Field	Meaning
`cursorAgeSeconds`	Time since the last successful poll, including an empty poll; `null` before the first poll
`quarantined`	Billing payments that require operator action
`parkedPayouts`	Marketplace payouts awaiting operator action

A stale watcher reports lagging; one that has not run reports unknown. Any parked payout makes the escrow watcher degraded. Across all components, possible states are operational, lagging, degraded, down and unknown.

Allocation queue

GET /v1/allocations

Returns ledger and three arrays drawn from the most recent 200 indexed claims:

Array	Claims included
`pending`	Announced claims in the claim window
`objected`	Claims with an active objection
`awarded`	Completed awards

Withdrawn and rejected claims are not shown. This is a bounded queue, with no pagination cursor.

Claim fields

Each claim includes id, namespace, claimant, claimantAccount, state, announcedLedger, awardedAt and the following evidence fields:

Field	Shape
`basis`	Array of asserted basis kinds, such as `["trademark", "dns"]`
`claimantResponse`	Claimant response, or `null`
`evidence`	Array of `{ "label", "url" }` links
`objections`	Active objections with `objector`, `basis` and decimal-string `bondXlm`

Resolved objections are excluded from objections. Uploaded claims and evidence are assertions by their authors.

Countdown fields

deadline, remainingSeconds and elapsed are estimates computed from indexed announcement/window data and the server’s clock. remainingSeconds is rounded to the nearest second. Use them to display progress. Before signing an award or other claim action, check the current contract state: elapsed: true alone does not establish readiness because the contract uses ledger time and checks the claim state. The queue does not include fee settlement history. Use the claim fee API for the current quote, receipt and recoverable credit. Objection bonds are separate from namespace claim fees.

​Status

​Component semantics

​Extra components, when enabled

​Allocation queue

​Claim fields

​Countdown fields