> For the complete documentation index, see [llms.txt](https://docs.hiero.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hiero.org/block-node-home/production-runbook/network-validation-go-live.md).

# Network Validation and Go-Live

> **Before starting:** The Block Node must be running and Alloy must be confirmed shipping (or telemetry opt-out recorded) before starting this page.

***

## Network validation **\[HASHGRAPH]**

Hashgraph runs an end-to-end validation against a Hashgraph-operated reference endpoint during the Day Zero session. No operator-side preparation is required beyond the prerequisites.

This step confirms:

* The Block Node is reachable on its public endpoints
* Block ingest is working correctly from a test Consensus Node
* Metrics and logs are landing in the configured remotes (if telemetry is enabled)

After validation, the Block Node is reset to a clean state before it enters production.

***

## Reset before go-live **\[OPERATOR]**

After network validation, reset the Block Node. This clears all state accumulated during testing so the production Block Node starts clean:

```bash
sudo solo-provisioner block node reset --profile=mainnet
```

This command:

1. Scales the StatefulSet to 0
2. Clears all data directories (`live`, `archive`, `application-state`, `log`)
3. Scales the StatefulSet back to 1

> **This reset is mandatory.** Without it, test data accumulated during validation pollutes the production Block Node. Do not skip this step.

Confirm the RSA bootstrap roster is in place at the expected path before the Block Node restarts. See [Install the Block Node - Step 4](/block-node-home/production-runbook/install-block-node.md#step-4--prepare-the-rsa-bootstrap-roster-coordinated).

***

## Network inclusion **\[COORDINATED]**

Network inclusion requires signing the Block Node registration transaction with the `admin_key` using the Hedera Transaction Tool. Hashgraph DevOps coordinates this step and provides the signing procedure at handoff.

On the Consensus Node side, inclusion is config-driven via `block-nodes.json`. Hashgraph manages this configuration and the node-management tooling that distributes it to the Consensus Nodes.

> **`admin_key` custody.** If the `admin_key` is lost, the Block Node registration cannot be updated. Treat it as a production signing key from day one and document the recovery path before go-live.

For details on the on-chain registration process, see [Block Node On-Chain Registration](/block-node-home/configuration/block-node-on-chain-registration.md).

***

## Handoff and close **\[COORDINATED]**

Hashgraph DevOps confirms:

* The Block Node is ingesting blocks from the configured Consensus Node
* The Block Node is reachable on its public endpoints
* Hashgraph adds the Block Node `/healthz` health endpoint to the central health monitor and standard dashboards

The operator is formally added to the upgrade pool after this step.

***

## Backfill expectations

After reset, the Block Node backfills block history from upstream Block Nodes. This is not instantaneous.

Full backfill of current history - approximately 20 TB and growing - may take **days to several weeks**, depending on:

* Network throughput to upstream Block Nodes
* Bulk disk write performance on this host
* Total history size at the time of deployment

Hashgraph will confirm the backfill approach before handoff:

| Approach                | How it works                                                                                                           |
| ----------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Live backfill**       | The Block Node comes up after reset and fills history over a multi-week window                                         |
| **Pre-loaded snapshot** | The operator restores an archive snapshot to the bulk volume after reset, then the Block Node catches up only the tail |

Track backfill progress:

* `serverStatus` - the `firstAvailableBlock` / `lastAvailableBlock` range widens as backfill proceeds
* Metrics: `backfill_pending_blocks`, `backfill_blocks_backfilled`, `backfill_fetch_errors`

***

## Next step

Proceed to [Steady State Operations](/block-node-home/production-runbook/steady-state-operations.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.hiero.org/block-node-home/production-runbook/network-validation-go-live.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.