A Bitcoin node isn’t immediately useful after starting. It goes through distinct phases before it’s ready to serve wallet data. blockd monitors every phase and exposes the state through its health API — giving your application the information it needs to respond intelligently at each stage.

Node lifecycle

From a fresh start, a node moves through these phases in sequence:

Initial Block Download (IBD) — bitcoind downloads and validates the entire blockchain from genesis. This can take hours to days depending on hardware and network conditions. Fulcrum begins indexing in parallel, but remains unreachable until IBD is complete.

Indexer catch-up — once IBD finishes, bitcoind is at chain tip but Fulcrum continues building its index. Fulcrum does not accept connections until indexing is complete — blockd continually attempts to connect throughout this phase. There is no progress signal from Fulcrum during this period; the only indicator is indexer.state remaining disconnected until Fulcrum finally allows connections and blockd completes initialization.

Ready — both bitcoind and Fulcrum are synced. blockd transitions to ready state and all API endpoints become available.

The server state field reflects this progression:

State	Meaning
ibd	bitcoind is in initial block download
syncing	bitcoind has finished IBD, indexer is catching up
ready	All services synced — primary operations available
degraded	Services reachable but experiencing errors

During IBD

blockd provides rich progress data during IBD through the ibd fields in the health response. These fields are sufficient to build a detailed onboarding experience — showing sync progress, speed, and estimated completion time directly to the user rather than leaving them with an unresponsive screen.

An IBD progress view can be built on blockd’s health data:

• Block Sync Progress — derived from blocks_synced / blocks_total
• Blocks Synced / Total / Remaining — directly from blocks_synced and blocks_total
• Speed (5min) — from per_sec_5min
• Speed (avg) — from per_sec_total
• ETA — computed from remaining blocks and current speed
• Verification Progress — from est_progress

See Health & IBD Reference for the full health response schema and IBD field reference.

Stall detection

blockd monitors IBD progress and emits a message on the ibd object when a stall condition is detected — no peers, network disabled, or validation falling behind. Surface these messages in your UI so users understand why progress has slowed or stopped. See IBD message for the full list.

After IBD — the indexer gap

When IBD completes, the ibd fields disappear from the health response and the rich progress data is no longer available. Fulcrum continues building its index but provides no progress signal — blockd cannot reach it until indexing is complete.

From your application’s perspective, this phase looks like a gap: no IBD progress to show, no indexer progress to show, just indexer.state: "disconnected" until Fulcrum finally comes online. This phase can take several hours on a full mainnet node.

Design your UI to handle this gracefully. A message like “Indexer is building — this may take several hours” is more informative than a blank or frozen screen.

Once Fulcrum connects and blockd completes initialization, indexer.state transitions to synced and the server transitions to ready.

Once ready

After ready is reached, IBD and indexer catch-up are no longer relevant and a server.health subscription continues to be useful for ongoing node status — block tip, bitcoind and indexer health, ZMQ stability, and degraded state detection.

Not every application needs to expose this. A wallet app might only care that the node is ready and show a simple connected/not-connected indicator. A dashboard or node management tool might surface the full detailed health view continuously.

blockd provides the data for both. Gate on state: "ready" before enabling wallet operations, and use the detailed health fields for as much or as little status UI as your application requires.

The detailed fields — core.state, indexer.state, zmq_outages, rpc_errors — are particularly useful for dashboards or server status views. See Health & IBD Reference for the complete field reference — available via WebSocket subscription or REST polling.