> This is part 1 of 2 of the full documentation (pages 1–100 of 112).
> The content is paginated: fetch every part to see all of it.
> Next part: https://service.block-pro.net/llms-full.txt/1
> Page index: https://service.block-pro.net/llms.txt

# About

BlockPro Team

The BlockPro team has been focused on blockchain security and verification since 2022, with experience in the crypto industry dating back to 2021. BlockPro is trusted by over 1,400 delegators who stake their tokens with us. We secure more than $1 million in staked tokens through delegations from both users and various projects. Our focus is on providing secure and reliable operations across blockchains like Cosmos, Solana, Polkadot, Ethereum, as well as several unique proprietary networks.

Our services emphasize security, low commissions, top-tier uptime, and 24/7 support. As an active participant in all validated networks, we also serve as an IBC repeater and network service provider since 2023.

Currently, we support over 20 networks, with 8 on mainnets.

## ***Contact us***

* **Discord -** [**https://discordapp.com/users/1270743736699064433**](https://discordapp.com/users/1270743736699064433)
* **Twitter -** [**https://x.com/BlockPro\_**](https://x.com/BlockPro_)
* **Telegram -** [**https://t.me/BLOCK\_PR0**](https://t.me/BLOCK_PR0)
* **Email - <admin@block-pro.net>**


# Celestia

Celestia Mainnet · Chain ID celestia

Run a Celestia node and connect to BlockPro infrastructure. Choose a guide, find an endpoint, or look up a command.

Start with [Requirements](/mainnet/celestia/requirements) and [Versions](/mainnet/celestia/versions).

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Validator Node</strong></td><td>Run consensus and manage your validator.</td><td><a href="/mainnet/celestia/validator-node">Validator Node</a></td></tr><tr><td><strong>Consensus Node</strong></td><td>Sync the chain and serve RPC or gRPC.</td><td><a href="/mainnet/celestia/consensus-node">Consensus Node</a></td></tr><tr><td><strong>Bridge Node</strong></td><td>Connect consensus to the DA network.</td><td><a href="/mainnet/celestia/bridge-node">Bridge Node</a></td></tr><tr><td><strong>Light Node</strong></td><td>Sample data availability with a small node.</td><td><a href="/mainnet/celestia/light-node">Light Node</a></td></tr><tr><td><strong>BlockPro Services</strong></td><td>Endpoints, peers, addrbook and snapshots.</td><td><a href="/mainnet/celestia/services">Services</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, key, token and validator operations.</td><td><a href="/mainnet/celestia/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Fibre on Mainnet

Use celestia-app and Fibre **v10.5.0**; follow the [Upgrade guide](/mainnet/celestia/validator-node/upgrade). App v10 is live. Active validators should promptly complete [Fibre setup](/mainnet/celestia/validator-node/fibre) and register a reachable server. The guide covers a separate Fibre host, private mTLS signing, health checks and optional HTTPS object storage.

## Before you start

Use the matching network throughout each guide. Commands are explained one step at a time.

[Full Storage Node compatibility](/mainnet/celestia/full-node) · [Troubleshooting](/mainnet/celestia/troubleshooting)

[BlockPro Explorer](https://mainnet.block-pro.net/celestia/staking) · [Celestia documentation](https://docs.celestia.org/) · [Support](https://t.me/BLOCK_PR0)

BlockPro is an independent infrastructure provider.


# Requirements

**Mainnet** · Chain ID `celestia`

Use Ubuntu 24.04 LTS on x86\_64 for these guides. Linux celestia-app multiplexer binaries require glibc 2.38 or newer.

## Hardware

These are current **Mainnet starting points**, not a guarantee of retention or future capacity.

| Node profile                      | CPU      | RAM    | Disk       | Network |
| --------------------------------- | -------- | ------ | ---------- | ------- |
| Light, pruned                     | 1 core   | 500 MB | 20 GB SSD  | 56 Kbps |
| Bridge, pruned                    | 32 cores | 64 GB  | 2 TB NVMe  | 1 Gbps  |
| Consensus, pruned                 | 32 cores | 32 GB  | 2 TB NVMe  | 1 Gbps  |
| Validator, base consensus process | 32 cores | 32 GB  | 2 TB NVMe  | 1 Gbps  |
| Bridge, archival                  | 32 cores | 64 GB  | 12 TB NVMe | 1 Gbps  |
| Consensus, archival               | 32 cores | 64 GB  | 16 TB NVMe | 1 Gbps  |

Storage depends on traffic, pruning and history. Leave working space for compaction and snapshot restoration. Size the consensus process separately when it shares a server with a bridge. Validators must pass Celestia's CPU benchmark. Fibre needs additional memory and a separate data disk; it is not included in the validator row.

Source: [Hardware requirements](https://docs.celestia.org/operate/getting-started/hardware-requirements/).

## Fibre capacity

Fibre runs alongside the validator role on a separate server. Allow at least **32 GB RAM** and pass the [official CPU benchmark](https://github.com/celestiaorg/celestia-app/blob/main/tools/cpu_requirements/README.md). With the default connection limits, receive buffers alone can approach **27 GiB**, so leave additional headroom for the service and OS.

Use the Mainnet tab in the [Fibre capacity calculator](https://docs.google.com/spreadsheets/d/1P3k-KQrZxbRjRwIxWkJBNwgAFlFMJUdT7OupA_WoKa0/edit?gid=971673838#gid=971673838) for disk and ingress sizing based on your current stake. Launch values and possible future throughput scenarios are separate. Add download capacity and local metadata storage. Keep Fibre data on a different disk from consensus data.

Place Fibre, the validator and any object-storage bucket in the same datacenter or region. Remote signing requires mTLS; an external KMS must support SignRawBytes and meet the signing-latency requirement. See [Fibre](/mainnet/celestia/validator-node/fibre) for the complete setup.

## Ports

| Port             | Purpose                | Exposure                                     |
| ---------------- | ---------------------- | -------------------------------------------- |
| 26656 TCP        | Consensus P2P          | Public when accepting peers                  |
| 2121 TCP and UDP | DA P2P                 | Public for bridge connectivity               |
| 26657 TCP        | Consensus HTTP RPC     | Local by default                             |
| 9090 TCP         | Application gRPC       | Local or private by default                  |
| 9098 TCP         | Core gRPC listener     | Local or private by default                  |
| 26669 TCP        | Validator signing gRPC | Fibre host only; mTLS for remote connections |
| 7980 TCP         | Fibre client traffic   | Public on the Fibre host                     |
| 26658 TCP        | DA node JSON-RPC       | Local and authenticated                      |

Your reverse proxy can expose public endpoints on a different port. Port 443 does not itself prove that a gRPC service supports TLS.

Source: [Consensus installation](https://docs.celestia.org/operate/consensus-validators/install-celestia-app/) and [bridge setup](https://docs.celestia.org/operate/data-availability/bridge-node/).


# Versions

**Mainnet** · Chain ID `celestia`

| Component     | Network-compatible release                                                   | Used by                                          |
| ------------- | ---------------------------------------------------------------------------- | ------------------------------------------------ |
| celestia-app  | [v10.5.0](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0)  | Consensus and validator nodes                    |
| Fibre         | [v10.5.0](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0)  | Bonded validators; matching celestia-app release |
| celestia-node | [v0.34.3](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3) | Light and bridge nodes                           |

The celestia-app and Fibre targets follow the [v10.5.0 release](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0). The celestia-node entry is separate from this app release. These are documentation targets, not a measurement of the versions running on BlockPro servers.

## What changes in v10.5.0

Upgrade celestia-app and Fibre together using the matching network tag. Fibre adds a `[health]` table and gRPC readiness checks. Configured object-storage endpoints must use HTTPS, and the bucket must be accessible with the service credentials at startup. See [Fibre](/mainnet/celestia/validator-node/fibre) for configuration and checks.

## Check your installation

Print the installed consensus binary version.

```bash
celestia-appd version
```

Print the installed Fibre version on the Fibre host.

```bash
fibre version
```

Print the installed DA binary version.

```bash
celestia version
```

Read the active application version from your running node.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

Mainnet app v10 is live. Confirm that your synchronized node reports active app version 10 or later before starting [Fibre](/mainnet/celestia/validator-node/fibre) and registering its host. The installed binary and active chain version are different checks. Retain the multiplexer for supported historical replay; do not use a standalone build or Cosmovisor for the v9-to-v10 transition.

Use the matching v10.5.0 Fibre binary for remote-signing mTLS and object-storage support. For local plaintext signing, use `127.0.0.1:26669` or `[::1]:26669`; `localhost` is not accepted as a loopback exemption.

The install guide and compatibility table can update at different times. Use the network compatibility table and the release notes together before changing a production node.

Source: [Network compatibility table](https://docs.celestia.org/operate/networks/overview/).

## Upgrade guides

[Validator Node](/mainnet/celestia/validator-node/upgrade) · [Bridge Node](/mainnet/celestia/bridge-node/upgrade) · [Light Node](/mainnet/celestia/light-node/upgrade)


# Consensus Node

**Mainnet** · Chain ID `celestia`

A consensus node follows the chain and can serve RPC and application gRPC. This guide creates a new node; do not run initialization over an existing validator home.

Complete [Server Setup](/mainnet/celestia/consensus-node/server-setup), excluding the optional Go section.

## Install celestia-app

Create a download directory.

```bash
mkdir -p "$HOME/celestia-downloads"
```

Open the directory.

```bash
cd "$HOME/celestia-downloads"
```

Download the network-specific multiplexer archive.

```bash
curl -fL --retry 3 -o celestia-app.tar.gz https://github.com/celestiaorg/celestia-app/releases/download/v10.5.0/celestia-app_Linux_x86_64.tar.gz
```

Download its checksum list.

```bash
curl -fL --retry 3 -o app-checksums.txt https://github.com/celestiaorg/celestia-app/releases/download/v10.5.0/checksums.txt
```

Select the checksum and match it to the local filename.

```bash
awk '$2 == "celestia-app_Linux_x86_64.tar.gz" {print $1 "  celestia-app.tar.gz"}' app-checksums.txt > app.sha256
```

Verify the download. Stop on a missing entry or failed checksum.

```bash
sha256sum --check app.sha256
```

Create an empty extraction directory; use a fresh directory if this already exists.

```bash
mkdir app-unpack
```

Extract the verified archive.

```bash
tar -xzf celestia-app.tar.gz -C app-unpack
```

Locate the binary in the release archive.

```bash
find app-unpack -type f -name celestia-appd
```

Install it. If the previous command showed a nested path, use that exact path here.

```bash
sudo install -m 0755 app-unpack/celestia-appd /usr/local/bin/celestia-appd
```

Check the installed version.

```bash
celestia-appd version
```

## Initialize the network

Create the node configuration and keys for this network.

```bash
celestia-appd init "YOUR_NODE_NAME" --chain-id celestia
```

Download genesis using the network-aware command.

```bash
celestia-appd download-genesis celestia
```

Confirm that the downloaded genesis matches the selected network.

```bash
jq -e '.chain_id == "celestia"' "$HOME/.celestia-app/config/genesis.json"
```

## Configure connectivity and storage

Save the initial consensus configuration.

```bash
cp -p "$HOME/.celestia-app/config/config.toml" "$HOME/.celestia-app/config/config.toml.before-setup"
```

Open the configuration. Set seeds from the network-specific [Peers and Seeds](/mainnet/celestia/services/peers-seeds) page in the existing `[p2p]` section.

```bash
nano "$HOME/.celestia-app/config/config.toml"
```

Keep the RPC listener local unless you are deliberately configuring a public service. In the existing `[rpc]` section, set:

```toml
grpc_laddr = "tcp://127.0.0.1:9098"
```

Choose pruning and enable application gRPC in the existing sections.

```bash
nano "$HOME/.celestia-app/config/app.toml"
```

For a pruned consensus node, start with `pruning = "default"`. Choose `min-retain-blocks` for your role: `3000` is the storage-planning baseline, `600000` is the validator recommendation, and `0` keeps all blocks. A bridge syncing from genesis needs an archival consensus source; use `pruning = "nothing"` and `min-retain-blocks = 0` for a fully archival source.

Edit the existing gRPC section, without duplicating it:

```toml
[grpc]
enable = true
address = "127.0.0.1:9090"
```

Set `minimum-gas-prices` to your operator policy. It controls which transactions your node accepts; it is separate from a transaction's fee flags.

## Run as a service

Create the service file. Replace YOUR\_LINUX\_USER and its home path below.

```bash
sudo nano /etc/systemd/system/celestia-appd.service
```

Paste this service configuration.

```ini
[Unit]
Description=Celestia consensus node
Wants=network-online.target
After=network-online.target

[Service]
User=YOUR_LINUX_USER
ExecStart=/usr/local/bin/celestia-appd start --home /home/YOUR_LINUX_USER/.celestia-app --rpc.grpc_laddr tcp://127.0.0.1:9098
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
```

Load the new service definition.

```bash
sudo systemctl daemon-reload
```

If using a [snapshot](/mainnet/celestia/services/snapshots), restore it before starting the new node. Otherwise, the node syncs from genesis, which can take a long time.

Enable startup at boot and start the node.

```bash
sudo systemctl enable --now celestia-appd
```

Inspect recent startup messages.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager
```

Confirm the network, increasing height and recent block time. Wait for catching\_up to become false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {network: .node_info.network, sync: .sync_info}'
```

Source: [Celestia documentation](https://docs.celestia.org/operate/consensus-validators/consensus-node/).


# Server Setup

**Mainnet** · Chain ID `celestia`

Run these commands on a new Ubuntu 24.04 x86\_64 host, using a regular account with sudo access. Mainnet and testnet guides assume separate hosts. Running both on one host needs distinct homes, services and ports.

Run each block separately and continue only after it succeeds. Names in `YOUR_...` are values you must replace.

## Prepare the host

Confirm that the architecture is x86\_64.

```bash
uname -m
```

Check that glibc is at least 2.38.

```bash
ldd --version
```

Refresh package information.

```bash
sudo apt update
```

Install the tools used in these guides.

```bash
sudo apt install -y curl ca-certificates tar lz4 jq git make nano build-essential clang pkg-config libssl-dev
```

## Install Go for DA source builds

Consensus installation uses a prebuilt release and can skip this section. The commands below use the Go version currently documented by Celestia.

Create a working directory for downloads.

```bash
mkdir -p "$HOME/celestia-downloads"
```

Work in the download directory.

```bash
cd "$HOME/celestia-downloads"
```

Download the pinned Go toolchain from its official site.

```bash
curl -fL --retry 3 -o go1.26.8.linux-amd64.tar.gz https://go.dev/dl/go1.26.8.linux-amd64.tar.gz
```

Download the official release metadata.

```bash
curl -fsS 'https://go.dev/dl/?mode=json&include=all' -o go-releases.json
```

Select the checksum for this exact archive.

```bash
jq -er '.[] | select(.version == "go1.26.8") | .files[] | select(.filename == "go1.26.8.linux-amd64.tar.gz") | "\(.sha256)  \(.filename)"' go-releases.json > go.sha256
```

Verify the archive. Continue only when it reports OK.

```bash
sha256sum --check go.sha256
```

Create a local toolchain parent directory.

```bash
mkdir -p "$HOME/.local/lib"
```

Create a new, empty versioned directory. Stop if it already exists and inspect the existing installation.

```bash
mkdir "$HOME/.local/lib/go1.26.8"
```

Extract Go without replacing a system installation.

```bash
tar -xzf go1.26.8.linux-amd64.tar.gz --strip-components=1 -C "$HOME/.local/lib/go1.26.8"
```

Make the toolchain and user binaries available in this shell.

```bash
export PATH="$HOME/.local/lib/go1.26.8/bin:$HOME/go/bin:$PATH"
```

Confirm the installed version.

```bash
go version
```

For later shell sessions, add the same PATH line to your shell profile. Systemd units below use absolute binary paths.

Source: [Environment setup](https://docs.celestia.org/operate/getting-started/environment-setup/).


# Validator Node

Already running a node? See [Upgrade](/mainnet/celestia/validator-node/upgrade).

**Mainnet** · Chain ID `celestia`

First complete [Consensus Node](/mainnet/celestia/consensus-node) and wait until it is synced. Check the CPU benchmark and [Requirements](/mainnet/celestia/requirements). App v10 is live on Mainnet. Bonded validators should run [Fibre](/mainnet/celestia/validator-node/fibre) on a separate nearby host, connect its signing service with mTLS, and register its reachable public address.

## Create or recover the operator account

Create a password-protected operator account. Keep the recovery phrase offline.

```bash
celestia-appd keys add validator --keyring-backend file
```

To use an existing account instead, choose the recovery command on [Key Management](/mainnet/celestia/useful-commands/key-management); do not create a second key with the same name.

Show the address to fund for self-delegation and transaction fees.

```bash
celestia-appd keys show validator -a --keyring-backend file
```

Show the consensus public key for this node. This is not the operator wallet public key.

```bash
celestia-appd tendermint show-validator
```

## Register the validator

Run `celestia-appd tx staking create-validator --help` on the installed release first. The command below follows Celestia's published flag-based example; if the binary requires a JSON file, use its release-specific format instead.

Choose commission settings deliberately: the maximum rate and maximum rate change constrain later updates. The amounts below are examples, not an active-set entry threshold.

Set a current fee price, including the denomination, for example 0.005utia only if accepted by your endpoint.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

Submit a validator registration with 1 TIA self-delegation. Review the interactive confirmation before broadcasting.

```bash
celestia-appd tx staking create-validator \
  --amount 1000000utia \
  --pubkey "$(celestia-appd tendermint show-validator)" \
  --moniker "YOUR_VALIDATOR_NAME" \
  --commission-rate 0.10 \
  --commission-max-rate 0.20 \
  --commission-max-change-rate 0.01 \
  --min-self-delegation 1000000 \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

Print your validator operator address.

```bash
celestia-appd keys show validator --bech val -a --keyring-backend file
```

Check registration, jailed state and bonding status. A successful transaction does not guarantee entry into the active set.

```bash
celestia-appd query staking validator YOUR_VALOPER_ADDRESS --node http://127.0.0.1:26657 -o json
```

## Protect signing state

Keep the consensus private key and latest signing state backed up securely. Never run the same consensus signing key on two active nodes. For snapshot recovery, preserve your stopped node's signing state; do not replace it with the snapshot provider's state.

Once bonded and fully synchronized, complete [Fibre setup and host registration](/mainnet/celestia/validator-node/fibre). Keep your operator wallet and consensus private key on their existing trusted hosts.

Source: [Celestia documentation](https://docs.celestia.org/operate/consensus-validators/validator-node/).


# Upgrade

Update celestia-app and its matching Fibre binary with the existing validator home.

**Mainnet** · Chain ID `celestia`

Mainnet app v10 is live. A healthy node already running the target release does not need to repeat this binary replacement. For a first Fibre installation, follow [Fibre setup](/mainnet/celestia/validator-node/fibre).

Target release: [v10.5.0](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0). Recheck [Versions](/mainnet/celestia/versions) and the release announcement before starting.

v10.5.0 is a minor update for nodes already running app version 10. Upgrade promptly using the existing home and database. This binary replacement does not schedule a new chain activation. The download section verifies both archives. If you do not run Fibre, skip its backup, installation, configuration and service commands.

This guide uses Ubuntu 24.04, Linux x86\_64 and the systemd paths from [Validator Node](/mainnet/celestia/validator-node). Run home-directory commands as the service's Linux user. Adapt service names and binary paths to your deployment.

{% hint style="warning" %}
The v9 → v10 transition uses the multiplexer. Mainnet has activated v10; keep this binary for the supported transition and historical replay path. Do not substitute a standalone build or use Cosmovisor to perform that transition.
{% endhint %}

## Deployment layout

**Run validator commands on the validator host and Fibre commands on the Fibre host.** For a separate Fibre server, perform the Fibre download, checksum, extraction, backup, install and restart steps there. The two download directories and shell variables are local to their respective hosts.

Back up the Fibre server's existing configuration, TLS files, persistent metadata and shard storage before replacing it. Keep its current service account and actual data path. If Fibre does not exist yet, skip its upgrade steps and use the first-installation guide instead.

## 1. Check paths and network

Inspect the running service and its home, user and executable.

```bash
sudo systemctl cat celestia-appd
```

Set the existing home. Change this value if ExecStart uses a different --home.

```bash
APP_HOME="$HOME/.celestia-app"
```

On the Fibre host, set its actual existing data home. This example matches the new Fibre guide; older deployments may use a different path. Do not initialize a new home during an upgrade.

```bash
FIBRE_HOME="/mnt/fibre/data"
```

Print the currently installed binary version.

```bash
/usr/local/bin/celestia-appd version
```

Check the live chain and synchronization state.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {network: .node_info.network, sync: .sync_info}'
```

Read the active app version; it can differ from the installed multiplexer version.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

Continue only on `celestia`. Review [Fibre](/mainnet/celestia/validator-node/fibre) and the release's major-version notes, including signer compatibility. Keep only one active instance of your consensus signer.

## 2. Download and verify

Select the release for this network.

```bash
APP_VERSION="v10.5.0"
```

Create a fresh download directory.

```bash
UPGRADE_DIR="$(mktemp -d "$HOME/celestia-app-upgrade.XXXXXX")"
```

Enter the download directory.

```bash
cd "$UPGRADE_DIR"
```

Download the multiplexer archive.

```bash
curl -fL --retry 3 -o celestia-app_Linux_x86_64.tar.gz "https://github.com/celestiaorg/celestia-app/releases/download/$APP_VERSION/celestia-app_Linux_x86_64.tar.gz"
```

Download Fibre from the same release.

```bash
curl -fL --retry 3 -o fibre_Linux_x86_64.tar.gz "https://github.com/celestiaorg/celestia-app/releases/download/$APP_VERSION/fibre_Linux_x86_64.tar.gz"
```

Download the checksum list.

```bash
curl -fL --retry 3 -o checksums.txt "https://github.com/celestiaorg/celestia-app/releases/download/$APP_VERSION/checksums.txt"
```

Select checksums for these two archives.

```bash
awk '$2 == "celestia-app_Linux_x86_64.tar.gz" || $2 == "fibre_Linux_x86_64.tar.gz" {print}' checksums.txt > upgrade.sha256
```

Require exactly two checksum entries. Stop if this fails.

```bash
test "$(wc -l < upgrade.sha256)" -eq 2
```

Verify both downloads. Continue only when both report OK.

```bash
sha256sum --check upgrade.sha256
```

Create separate extraction folders.

```bash
mkdir app-unpack fibre-unpack
```

Extract celestia-app.

```bash
tar -xzf celestia-app_Linux_x86_64.tar.gz -C app-unpack
```

Extract Fibre.

```bash
tar -xzf fibre_Linux_x86_64.tar.gz -C fibre-unpack
```

Locate the executables. Use the exact returned paths below if the archive layout differs.

```bash
find app-unpack fibre-unpack -type f \( -name celestia-appd -o -name fibre \)
```

## 3. Stop and back up

Stop Fibre first **if it is already installed**. Use its actual unit name.

Stop the existing Fibre service; skip this command for a first Fibre installation.

```bash
sudo systemctl stop fibre
```

Stop the consensus process.

```bash
sudo systemctl stop celestia-appd
```

Confirm that the consensus process has exited before copying signing state.

```bash
test "$(systemctl show celestia-appd --property=MainPID --value)" = "0"
```

Create this private backup directory on each host that is being upgraded.

```bash
mkdir -m 0700 "$UPGRADE_DIR/backup"
```

Save the validator configuration and its local keys.

```bash
cp -a "$APP_HOME/config" "$UPGRADE_DIR/backup/config"
```

Save the latest local signing state. For an external signer, use its own state backup procedure instead.

```bash
cp -p "$APP_HOME/data/priv_validator_state.json" "$UPGRADE_DIR/backup/priv_validator_state.json"
```

Keep the previous consensus executable.

```bash
cp -p /usr/local/bin/celestia-appd "$UPGRADE_DIR/backup/celestia-appd"
```

Save existing Fibre configuration; skip if Fibre has not been initialized.

```bash
sudo cp -a "$FIBRE_HOME/config" "$UPGRADE_DIR/backup/fibre-config"
```

On the Fibre host, also back up the TLS and credential directory securely; skip if your deployment stores these elsewhere.

```bash
sudo cp -a /etc/fibre "$UPGRADE_DIR/backup/fibre-secrets"
```

Keep the previous Fibre executable; skip for a first installation or adjust its path.

```bash
cp -p /usr/local/bin/fibre "$UPGRADE_DIR/backup/fibre"
```

Protect this backup: it may contain private keys. For migrations, also take a consistent database/filesystem snapshot while services are stopped. Keep existing Fibre shards and any object-storage namespace accessible.

## 4. Replace binaries and review configuration

Install the verified consensus binary at the service's existing path.

```bash
sudo install -m 0755 app-unpack/celestia-appd /usr/local/bin/celestia-appd
```

Install the matching Fibre executable.

```bash
sudo install -m 0755 fibre-unpack/fibre /usr/local/bin/fibre
```

Confirm the new consensus version.

```bash
/usr/local/bin/celestia-appd version
```

Confirm the matching Fibre version.

```bash
/usr/local/bin/fibre version
```

On the validator host, preview missing node settings. Include --fibre-home only when the Fibre configuration is present on this same machine.

```bash
/usr/local/bin/celestia-appd config sync --home "$APP_HOME" --dry-run
```

Apply the reviewed additions.

```bash
/usr/local/bin/celestia-appd config sync --home "$APP_HOME"
```

This preserves saved values and skips missing files; it does not update `app.toml`. On a separate Fibre host, review its `config/server_config.toml` against the [Fibre guide](/mainnet/celestia/validator-node/fibre); the validator's local config-sync command cannot update a remote file. Check application gRPC, the existing database backend and retention settings separately. Do not change the database backend as part of a binary replacement.

Set application `[grpc] enable = true` explicitly in `app.toml`; preserve the existing core RPC gRPC listener used by bridges. For local Fibre signing, use matching loopback IP addresses, such as `127.0.0.1:26669`, on both services. Replace `localhost` with an IP literal. For remote signing, configure mutual TLS according to the [official Fibre guide](https://docs.celestia.org/operate/consensus-validators/fibre/). Keep service flags and configuration files consistent.

### Fibre health configuration

On the Fibre host, edit the existing configuration after making the backup. Keep root-level settings above TOML tables; add this table once, or edit its existing keys.

```bash
sudo nano "$FIBRE_HOME/config/server_config.toml"
```

```toml
[health]
check_interval = "10s"
probe_timeout = "3s"
max_block_age = "2m"
```

These are the release defaults and apply even when the table is absent. Adding the table is recommended for an explicit, reviewable configuration; preserve intentional custom values. `check_interval` controls check frequency, `probe_timeout` bounds each probe, and `max_block_age` bounds the age of the app node’s latest block. Restart Fibre after editing.

### Object storage before restart

If object storage is configured, its `endpoint` must be an absolute `https://` URL with a valid TLS setup. Plain HTTP now fails startup validation. Check the bucket, region, service credentials and bucket-access permissions: Fibre performs a bucket check at startup and stops if it cannot access it.

Keep access to any retained object shards, including after switching new writes back to local storage. Changing an old HTTP endpoint to HTTPS can also change the recorded namespace; review any mismatch using the migration instructions in the Fibre guide before applying an override. Never use an override without verifying access to the same retained objects.

## 5. Restart and verify

Start the existing consensus service.

```bash
sudo systemctl start celestia-appd
```

Check startup errors and block processing.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager
```

Confirm the chain, recent block time, increasing height and catching\_up status.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {network: .node_info.network, sync: .sync_info}'
```

Check validator signing and missed-block metrics as well. Compare height over time; `catching_up: false` alone does not prove progress.

Check activation before starting Fibre.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

After confirming the live node reports app version **10 or later**, start the configured Fibre service on its own host. A first installation must complete the [Fibre setup and registration](/mainnet/celestia/validator-node/fibre) first.

Start the existing Fibre unit after the activation and configuration checks.

```bash
sudo systemctl start fibre
```

Check Fibre connectivity and storage initialization.

```bash
sudo journalctl -u fibre -n 100 --no-pager
```

After startup, run the [Fibre health and readiness checks](/mainnet/celestia/validator-node/fibre#health-and-readiness). Confirm readiness as well as liveness. A new installation may remain not ready until its bonded validator's public Fibre host is registered.

## If the upgrade fails

Stop the failing service and inspect its first error. Do not reset the validator, re-create keys, or restore old signing state after signing newer blocks. A binary downgrade may be incompatible with the migrated database or active chain version; use the release's recovery instructions.

Sources: [Release instructions](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0), [network upgrades](https://docs.celestia.org/operate/maintenance/network-upgrades/), [Fibre operations](https://docs.celestia.org/operate/consensus-validators/fibre/).


# Fibre

Set up Mainnet Fibre with private mTLS signing, storage and host registration.

**Mainnet Beta · Chain ID `celestia` · celestia-app / Fibre v10.5.0**

Mainnet app v10 is live. Active validators should set up Fibre and register a reachable server as soon as possible. Check the active version on your synchronized node before starting.

Use a **separate Fibre server** in the same datacenter or region as the validator. Keep object storage nearby too: a distant bucket can delay endorsements. This guide uses two Linux hosts connected by a trusted private network.

## Requirements

| Item                  | Requirement                                                                                                                                                              |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| CPU                   | Pass the [official CPU benchmark](https://github.com/celestiaorg/celestia-app/blob/main/tools/cpu_requirements/README.md)                                                |
| RAM                   | At least 32 GB, with headroom for the configured connection limits                                                                                                       |
| Disk and bandwidth    | Size for your stake with the [official calculator](https://docs.google.com/spreadsheets/d/1P3k-KQrZxbRjRwIxWkJBNwgAFlFMJUdT7OupA_WoKa0/edit?gid=971673838#gid=971673838) |
| OS in this guide      | Ubuntu 24.04, Linux x86-64                                                                                                                                               |
| Validator             | Synchronized, bonded, active app version 10 or later                                                                                                                     |
| External KMS, if used | SignRawBytes support and median signing latency at or below 10 ms                                                                                                        |

Use the calculator's Mainnet tab and your current stake. Launch sizing and a possible higher-throughput scenario are different; a forecast is not an activated requirement. Add capacity for downloads, persistent local metadata and OS overhead.

Default receive buffers can consume approximately `16 × 13 × 132 MiB ≈ 27 GiB`. Raising `max_connections` or `max_concurrent_streams` requires more memory. An upload can occupy all 16 default connection slots; increasing that limit leaves room for downloads but raises the RAM budget.

### Run the CPU benchmark

If Docker is installed, run the official test before placing production workload on this host.

```bash
docker run --rm ghcr.io/celestiaorg/128mb-6s-benchmark:v0.0.1
```

## Connection plan

Replace these **example private addresses** throughout the guide.

| Connection                 | Example           | Access                                     |
| -------------------------- | ----------------- | ------------------------------------------ |
| Validator application gRPC | `10.0.0.10:9090`  | Fibre host only, trusted private network   |
| Validator signing gRPC     | `10.0.0.10:26669` | Fibre host only, mutual TLS                |
| Fibre private IP           | `10.0.0.20`       | Source allowed by validator firewall rules |
| Fibre client listener      | `0.0.0.0:7980`    | Public TCP 7980                            |

Application gRPC is separate from core RPC gRPC. Preserve the bridge's existing core listener, commonly `9098`; Fibre uses the application listener in `app.toml`.

Fibre requests signatures through the validator node, which forwards them to a KMS if configured. Do not copy the consensus private key or operator wallet to Fibre.

## Validator host: readiness

### Check synchronization

Confirm celestia, a current block time and catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

### Check active app version

Require 10 or later. An installed v10 multiplexer alone does not prove activation.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

### Check the installed release

Use the matching Mainnet release; see the Validator Upgrade guide if needed.

```bash
celestia-appd version
```

### Back up configuration

Run as the validator service user. Use a fresh backup path if this one exists.

```bash
cp -a "$HOME/.celestia-app/config" "$HOME/.celestia-app/config.before-fibre"
```

### Enable application gRPC

Edit the existing section without duplicating it.

```bash
nano "$HOME/.celestia-app/config/app.toml"
```

```toml
[grpc]
enable = true
address = "10.0.0.10:9090"
```

Set enable=true explicitly. Embedded v9 behavior could hide a disabled value; v10 uses the saved setting. Restrict this plaintext listener to the Fibre host over the trusted private network.

## Certificates for private signing

Use a dedicated CA and separate server/client certificates. The server certificate SAN must match the private address Fibre dials. Run the following in a **new directory on a trusted administration machine**, with Bash and OpenSSL.

### Create the private workspace

Use another path if this directory already exists.

```bash
install -d -m 0700 "$HOME/fibre-pki"
```

### Open the workspace

Generate the certificate files here.

```bash
cd "$HOME/fibre-pki"
```

### Restrict new files

Limit access to newly created private keys.

```bash
umask 077
```

### Create the CA

Keep ca.key offline after issuing certificates.

```bash
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout ca.key -out ca.crt -days 3650 -subj "/CN=fibre-private-ca"
```

### Create the validator CSR

This TLS key is separate from the consensus signing key.

```bash
openssl req -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout validator.key -out validator.csr -subj "/CN=validator-privval"
```

### Sign the validator certificate

Replace 10.0.0.10 with the exact dialed address. For a hostname, use DNS:your-private-name instead of IP:10.0.0.10.

```bash
openssl x509 -req -in validator.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out validator.crt -days 365 \
  -extfile <(printf "subjectAltName=IP:10.0.0.10\nextendedKeyUsage=serverAuth\n")
```

### Create the Fibre CSR

Generate a separate client TLS key.

```bash
openssl req -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout fibre.key -out fibre.csr -subj "/CN=fibre-client"
```

### Sign the Fibre certificate

Issue a certificate for client authentication.

```bash
openssl x509 -req -in fibre.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out fibre.crt -days 365 \
  -extfile <(printf "extendedKeyUsage=clientAuth\n")
```

### Verify both certificates

Both must verify successfully.

```bash
openssl verify -CAfile ca.crt validator.crt fibre.crt
```

Transfer `ca.crt`, `validator.crt` and `validator.key` securely to the validator. Transfer `ca.crt`, `fibre.crt` and `fibre.key` securely to Fibre. Keep the CA private key off both production hosts.

## Validator host: configure mTLS

These steps assume the validator's three files were securely placed in `$HOME/fibre-tls-incoming` for the existing service user.

### Create the certificate directory

Run as the validator service user.

```bash
install -d -m 0700 "$HOME/.celestia-app/tls"
```

### Install the node certificates

Copy only the CA certificate and this host's certificate/key.

```bash
install -m 0600 "$HOME/fibre-tls-incoming/ca.crt" "$HOME/fibre-tls-incoming/validator.crt" "$HOME/fibre-tls-incoming/validator.key" "$HOME/.celestia-app/tls/"
```

### Edit signing settings

Update these top-level keys before the first section. Certificate paths are relative to the node home.

```bash
nano "$HOME/.celestia-app/config/config.toml"
```

```toml
priv_validator_grpc_laddr = "10.0.0.10:26669"
priv_validator_grpc_cert_file = "tls/validator.crt"
priv_validator_grpc_key_file = "tls/validator.key"
priv_validator_grpc_client_ca_file = "tls/ca.crt"
priv_validator_grpc_allow_insecure = false
```

All three TLS fields are required together. Restrict TCP 9090 and 26669 to the Fibre host at the host and provider firewalls. Use a trusted private route or VPN: signing mTLS does not encrypt the separate application-gRPC connection.

### Review service overrides

Check that flags do not replace the intended connection settings.

```bash
sudo systemctl cat celestia-appd
```

### Restart the validator

Apply configuration with the existing home and signing identity.

```bash
sudo systemctl restart celestia-appd
```

### Verify recovery

Confirm normal block processing and validator signing before proceeding.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager -o cat
```

## Fibre host: install

Use the same release as your validator. These commands target Linux x86-64; arm64 needs its matching official asset. Fibre requires glibc 2.34 or newer, while the consensus multiplexer requires glibc 2.38.

### Refresh packages

Load the package index.

```bash
sudo apt update
```

### Install utilities

Install download, configuration and connectivity tools.

```bash
sudo apt install -y ca-certificates curl jq nano openssl netcat-openbsd
```

### Create a download directory

Keep release files separate from service data.

```bash
FIBRE_DOWNLOAD=$(mktemp -d "$HOME/fibre-download.XXXXXX")
```

### Open the directory

Download and verify the archive here.

```bash
cd "$FIBRE_DOWNLOAD"
```

### Download Fibre

Select the Mainnet v10.5.0 archive.

```bash
curl -fL --retry 3 https://github.com/celestiaorg/celestia-app/releases/download/v10.5.0/fibre_Linux_x86_64.tar.gz -o fibre_Linux_x86_64.tar.gz
```

### Download checksums

Use the checksum list from the same release.

```bash
curl -fL --retry 3 https://github.com/celestiaorg/celestia-app/releases/download/v10.5.0/checksums.txt -o checksums.txt
```

### Select the checksum

Save the entry for this archive.

```bash
awk '$2 == "fibre_Linux_x86_64.tar.gz" {print}' checksums.txt > fibre.sha256
```

### Check the entry

Stop unless there is exactly one matching entry.

```bash
test "$(wc -l < fibre.sha256)" -eq 1
```

### Verify the download

Continue only when the result is OK.

```bash
sha256sum --check fibre.sha256
```

### Extract the binary

Extract inside the fresh download directory.

```bash
tar -xzf fibre_Linux_x86_64.tar.gz
```

### Install Fibre

Install the verified executable.

```bash
sudo install -m 0755 fibre /usr/local/bin/fibre
```

### Check the version

Confirm it matches the validator's release.

```bash
fibre version
```

## Fibre host: configure the service

This example uses a dedicated disk mounted at `/mnt/fibre` and a service user named `fibre`. Provision and persist the mount first. Do not format a disk containing node data. For an existing deployment, keep its current account and data home.

### Create the service account

Run once on a fresh host; skip if this account already exists.

```bash
sudo useradd --system --create-home --home-dir /var/lib/fibre --shell /usr/sbin/nologin fibre
```

### Verify the dedicated mount

Stop if this fails. Adapt the path if your mounted disk is elsewhere.

```bash
mountpoint -q /mnt/fibre
```

### Create service directories

Give Fibre access to its own data and TLS directories.

```bash
sudo install -d -o fibre -g fibre -m 0750 /mnt/fibre/data /mnt/fibre/data/config /etc/fibre /etc/fibre/tls
```

### Install client TLS files

Assumes the Fibre files were securely transferred to your login user's fibre-tls-incoming directory.

```bash
sudo install -o fibre -g fibre -m 0600 "$HOME/fibre-tls-incoming/ca.crt" "$HOME/fibre-tls-incoming/fibre.crt" "$HOME/fibre-tls-incoming/fibre.key" /etc/fibre/tls/
```

### Write server configuration

For an existing home, edit its current keys rather than replacing unrelated settings.

```bash
sudo nano /mnt/fibre/data/config/server_config.toml
```

```toml
app_grpc_address = "10.0.0.10:9090"
signer_grpc_address = "10.0.0.10:26669"
signer_grpc_ca_file = "/etc/fibre/tls/ca.crt"
signer_grpc_cert_file = "/etc/fibre/tls/fibre.crt"
signer_grpc_key_file = "/etc/fibre/tls/fibre.key"
server_listen_address = "0.0.0.0:7980"
max_connections = 16
max_concurrent_streams = 13
storage_backend = "local"

[health]
check_interval = "10s"
probe_timeout = "3s"
max_block_age = "2m"
```

The `[health]` values above are defaults. Existing files can keep intentional custom values; add missing settings manually or use the configuration-sync procedure in [Validator Upgrade](/mainnet/celestia/validator-node/upgrade). Do not duplicate the table.

### Create the systemd unit

Use the same data path in the unit. RequiresMountsFor makes the mount a service dependency.

```bash
sudo nano /etc/systemd/system/fibre.service
```

```ini
[Unit]
Description=Celestia Mainnet Fibre
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/mnt/fibre/data

[Service]
User=fibre
Group=fibre
ExecStart=/usr/local/bin/fibre start --home /mnt/fibre/data
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target
```

### Test the signing connection

Verify server identity and client authentication from the Fibre host. Use the private IP included in the validator certificate SAN.

```bash
sudo -u fibre openssl s_client -connect 10.0.0.10:26669 \
  -CAfile /etc/fibre/tls/ca.crt -cert /etc/fibre/tls/fibre.crt \
  -key /etc/fibre/tls/fibre.key -verify_ip 10.0.0.10 \
  -verify_return_error -alpn h2 </dev/null
```

For a DNS SAN, replace `-verify_ip` with `-verify_hostname your-private-name`. This handshake checks TLS; startup logs confirm the application connections.

### Reload systemd

Load the new unit.

```bash
sudo systemctl daemon-reload
```

### Start Fibre

Proceed after the validator and mTLS checks succeed.

```bash
sudo systemctl enable --now fibre
```

### Check startup

Confirm chain celestia, validator addresses and the selected storage backend.

```bash
sudo journalctl -u fibre -n 100 --no-pager -o cat
```

Allow public TCP 7980 on the Fibre host. Its client-facing TLS certificate is generated and endorsed automatically; no public web-server certificate is required.

## Register the public address

Run transaction commands on the trusted host containing your operator wallet. Register only after the Fibre service is reachable. Use a public IP or DNS name with a port, without `https://` or a path.

### Check external reachability

Run from outside the Fibre server's network. This tests TCP reachability, not a complete upload.

```bash
nc -vz YOUR_PUBLIC_FIBRE_HOST 7980
```

### Set the transaction gas price

Use a price accepted by your endpoint, including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Register Fibre

Use your bonded validator's operator account and review the confirmation.

```bash
celestia-appd tx valaddr set-host YOUR_PUBLIC_FIBRE_HOST:7980 \
  --from validator --keyring-backend file --home "$HOME/.celestia-app" \
  --chain-id celestia --node http://127.0.0.1:26657 \
  --gas auto --gas-adjustment 1.5 --gas-prices "$GAS_PRICE"
```

### Read the consensus address

Copy the celestiavalcons address for the registry query.

```bash
celestia-appd comet show-address --home "$HOME/.celestia-app"
```

### Verify registration

Replace YOUR\_VALCONS\_ADDRESS. Require found=true and the intended public host.

```bash
celestia-appd query valaddr provider YOUR_VALCONS_ADDRESS --node http://127.0.0.1:26657
```

Registration survives restarts. Repeat it only after an address change or removal of the registry entry. Monitor endorsements and validator signing; an open port alone does not prove correct operation.

## Health and readiness

Use `grpc_health_probe` from its [official releases](https://github.com/grpc-ecosystem/grpc-health-probe/releases). The following checks run locally **on the Fibre host** against its TLS listener; adjust the port if yours differs.

Check whether Fibre is ready.

```bash
grpc_health_probe -addr=127.0.0.1:7980 -tls -tls-no-verify
```

Check whether the Fibre process answers, even if a dependency is unavailable.

```bash
grpc_health_probe -addr=127.0.0.1:7980 -tls -tls-no-verify -service=fibre-liveness
```

Expect `SERVING` for both after setup and registration. Readiness may remain `NOT_SERVING` until the validator is bonded, the public host is registered, and the next health check succeeds. Liveness alone does not prove readiness.

These commands skip conventional certificate verification only for a local diagnostic: Fibre uses a validator-endorsed certificate. They do not authenticate a remote validator. Keep this check on loopback; use a Fibre-aware client for remote identity verification.

Readiness checks cover the app connection and recent blocks, signer identity, validator membership, host registration and the local metadata store. A failure is reported in the Fibre log; it does not itself disable uploads or downloads.

Read the failed check and its recovery advice.

```bash
sudo journalctl -u fibre -n 100 --no-pager -o cat
```

The gRPC health service shares port `7980`; no separate HTTP health port is required. An unexpected gRPC server exit now ends the process, so keep a supervisor such as systemd with `Restart=on-failure`.

The internal readiness check cannot prove public reachability or a successful upload. Continue checking the public address from outside the network and monitor real upload/endorsement success.

## Optional object storage

Fibre supports S3-compatible shard storage while keeping its metadata database on local persistent disk. Place the bucket in the same region as Fibre and grant bucket-scoped read, write, list and delete access.

**v10.5.0 requires HTTPS.** A configured `object_storage.endpoint` must be an absolute `https://` URL. HTTP fails validation. Startup also checks bucket accessibility using the service credentials and fails if the bucket check fails. Confirm bucket-level permissions as well as object read/write/delete permissions.

### Edit the backend

Edit the existing root-level `storage_backend` key **before any `[table]` headings**, then add or edit one `[object_storage]` table. Do not place `storage_backend` inside `[health]`. Use your actual provider values.

```bash
sudo nano /mnt/fibre/data/config/server_config.toml
```

```toml
storage_backend = "object"

[object_storage]
endpoint = "https://s3.YOUR_REGION.amazonaws.com"
region = "YOUR_REGION"
bucket = "YOUR_BUCKET"
prefix = "fibre"
```

For R2, use the account's S3 API endpoint and `region = "auto"`. Keep credentials out of this TOML file.

### Create a private credentials file

First setup only. For rotation, edit the existing file instead of replacing it with an empty one.

```bash
sudo install -m 0600 /dev/null /etc/fibre/s3.env
```

### Enter credentials

Enter secrets locally; never post them in shared documentation.

```bash
sudo nano /etc/fibre/s3.env
```

```ini
AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY=YOUR_SECRET_ACCESS_KEY
```

Add AWS\_SESSION\_TOKEN for temporary credentials. A suitable instance role may supply credentials instead of a file.

### Add the service environment

Add this systemd override.

```bash
sudo systemctl edit fibre
```

```ini
[Service]
EnvironmentFile=/etc/fibre/s3.env
```

### Reload the unit

Load the environment-file override.

```bash
sudo systemctl daemon-reload
```

### Restart Fibre

Apply storage settings and credentials.

```bash
sudo systemctl restart fibre
```

### Verify object storage

Check the effective backend and canonical bucket/prefix in startup logs.

```bash
sudo journalctl -u fibre -n 100 --no-pager -o cat
```

### Change backend or migrate a bucket

Switching between local and object storage changes where new shards go; existing shards stay in their original location. Keep their data available until pruned. After switching back to local, keep the previous object configuration and credentials while object-backed shards remain.

For a bucket move:

1. Stop Fibre and copy every object to the new bucket, preserving key layout.
2. Verify the copy is complete, then update the endpoint/bucket/prefix and credentials.
3. Start once with `--override-object-namespace` appended to the existing start command. This flag does not copy or verify objects.
4. Remove the flag and restart normally. Retain the original bucket until serving from the new one is verified.

When replacing an old HTTP endpoint with HTTPS, confirm it reaches the same bucket and retained objects. The endpoint is part of the recorded namespace, so an intentional scheme change may require the same reviewed namespace procedure; do not bypass a mismatch without verifying the objects.

Follow the [official migration procedure](https://docs.celestia.org/operate/consensus-validators/fibre/#migrate-to-another-bucket). Do not use the override to hide an unexplained namespace mismatch.

## Same-host signing and troubleshooting

For local plaintext signing, both services must use a loopback **IP literal**, such as `127.0.0.1:26669` or `[::1]:26669`. `localhost` no longer qualifies. Leave the TLS fields empty only for this local mode, and keep application gRPC at `127.0.0.1:9090`. A separate Fibre host with mTLS is the recommended production layout.

| Symptom                          | Check                                                                                  |
| -------------------------------- | -------------------------------------------------------------------------------------- |
| Missing Fibre or valaddr service | Active app version and application-gRPC endpoint                                       |
| Application gRPC refused         | enable=true, private bind address, route and firewall                                  |
| Signing connection fails         | Port, complete mTLS fields, and SAN matching the dialed address                        |
| Unknown configuration field      | Correct the exact field reported by the binary                                         |
| Health reports NOT\_SERVING      | Check the named failure in logs, app sync, signer, bonded status and host registration |
| Object endpoint rejected         | Replace HTTP with a valid HTTPS endpoint and verify namespace continuity               |
| Bucket check fails               | Check TLS, network reachability, bucket name and service credential permissions        |
| Object credential error          | Service environment, credential scope and file permissions                             |
| Object namespace mismatch        | Restore the original namespace or complete a verified migration                        |
| High endorsement latency         | Validator/Fibre/bucket placement, signer latency and memory pressure                   |

Rotate certificates before expiry and restart the validator and Fibre after replacing them. With a remote signer, monitor the validator's `cometbft_privval_signing_latency_*` metrics. Never enable the remote insecure-signing overrides in production.

[v10.5.0 release](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0) · [Health reference](https://github.com/celestiaorg/celestia-app/blob/v10.5.0/fibre/cmd/README.md#health) · [Validator Upgrade](/mainnet/celestia/validator-node/upgrade) · [Official Fibre guide](https://docs.celestia.org/operate/consensus-validators/fibre/) · [mTLS reference](https://github.com/celestiaorg/celestia-core/blob/main/docs/guides/privval-grpc-tls.md) · [Fibre server specification](https://github.com/celestiaorg/celestia-app/blob/v10.5.0/specs/src/fibre_server.md)


# Bridge Node

Already running a node? See [Upgrade](/mainnet/celestia/bridge-node/upgrade).

**Mainnet** · Chain ID `celestia`

A bridge imports consensus data and makes it available to the DA network. Initial sync from genesis needs an archival consensus source; a pruned public endpoint is not sufficient.

Complete [Install celestia-node](/mainnet/celestia/bridge-node/install-da) first.

## Choose a consensus connection

For the example below, run your own archival [Consensus Node](/mainnet/celestia/consensus-node) on the same host, enable application gRPC at `127.0.0.1:9090`, and let it sync first. Size its storage separately.

Initialize the bridge node store for Mainnet. Save any recovery phrase privately.

```bash
celestia bridge init --p2p.network celestia
```

Start the node in the foreground and inspect the connection. Use a bare hostname, without https\://. Add --core.tls only when the endpoint uses TLS.

```bash
celestia bridge start --p2p.network celestia --core.ip 127.0.0.1 --core.port 9090
```

After checking the foreground process, stop it with Ctrl+C before starting the same store under systemd.

## Run as a service

Create the service definition. Replace the Linux user, home and any endpoint placeholders.

```bash
sudo nano /etc/systemd/system/celestia-bridge.service
```

Paste this configuration; retain the same TLS choice used in your successful foreground test.

```ini
[Unit]
Description=Celestia bridge node (Mainnet)
Wants=network-online.target
After=network-online.target

[Service]
User=YOUR_LINUX_USER
Environment=HOME=/home/YOUR_LINUX_USER
ExecStart=/home/YOUR_LINUX_USER/go/bin/celestia bridge start --p2p.network celestia --core.ip 127.0.0.1 --core.port 9090
Restart=on-failure
RestartSec=5
LimitNOFILE=1400000

[Install]
WantedBy=multi-user.target
```

Load the new unit.

```bash
sudo systemctl daemon-reload
```

Enable and start the service.

```bash
sudo systemctl enable --now celestia-bridge
```

Check recent logs for successful connections and advancing headers.

```bash
sudo journalctl -u celestia-bridge -n 100 --no-pager
```

List addresses in the default DA key store. The test backend is unencrypted; do not keep a validator treasury in this store.

```bash
cel-key list --node.type bridge --p2p.network celestia --keyring-backend test
```

Open DA P2P port 2121 on both TCP and UDP. Leave pruning enabled unless archival retention is intentional and provisioned.

Source: [Celestia documentation](https://docs.celestia.org/operate/data-availability/bridge-node/).


# Upgrade

Update your Celestia bridge node while keeping its existing store.

**Mainnet** · Chain ID `celestia`

Target release: [v0.34.3](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3). Check [Versions](/mainnet/celestia/versions) and the release notes before each upgrade.

This procedure follows the native systemd installation in [Bridge Node](/mainnet/celestia/bridge-node). Run commands as the service's Linux user. Keep the same node type, network, keys and data store.

## 1. Check the running installation

Inspect the service user, binary path, network and any custom store flag. If your unit has a different name, use it throughout.

```bash
sudo systemctl cat celestia-bridge
```

Print the currently installed version. The path must match ExecStart; adapt it if your installation differs.

```bash
"$HOME/go/bin/celestia" version
```

Set the existing store path from your service configuration or startup logs. Replace this placeholder before continuing.

```bash
NODE_STORE="/absolute/path/to/your/existing/bridge-store"
```

Confirm that this is an initialized store. Stop if the check fails.

```bash
test -f "$NODE_STORE/config.toml"
```

Check Go. The selected release requires Go 1.26.8 or later; see Server Setup if you need to update it.

```bash
go version
```

## 2. Build the selected release

Build before stopping the node. This does not replace its running binary.

Choose the network-specific release.

```bash
NODE_VERSION="v0.34.3"
```

Create a fresh working directory.

```bash
UPGRADE_DIR="$(mktemp -d "$HOME/celestia-node-upgrade.XXXXXX")"
```

Download the source for the selected tag.

```bash
git clone --branch "$NODE_VERSION" --depth 1 https://github.com/celestiaorg/celestia-node.git "$UPGRADE_DIR/source"
```

Enter the source directory.

```bash
cd "$UPGRADE_DIR/source"
```

Compile the node binary.

```bash
make build
```

Compile the matching key utility.

```bash
make cel-key
```

## 3. Stop and back up

If multiple services use the same binary, coordinate their maintenance before replacing it. For a release that changes the datastore, take a consistent snapshot of the entire store while stopped. The small backup below covers keys, configuration and the old executable.

Stop this node.

```bash
sudo systemctl stop celestia-bridge
```

Confirm its process has exited. Continue only if this succeeds.

```bash
test "$(systemctl show celestia-bridge --property=MainPID --value)" = "0"
```

Create a private backup directory.

```bash
mkdir -m 0700 "$UPGRADE_DIR/backup"
```

Back up configuration.

```bash
cp -p "$NODE_STORE/config.toml" "$UPGRADE_DIR/backup/config.toml"
```

Back up DA keys. Keep this directory private.

```bash
cp -a "$NODE_STORE/keys" "$UPGRADE_DIR/backup/keys"
```

Keep the previous executable.

```bash
cp -p "$HOME/go/bin/celestia" "$UPGRADE_DIR/backup/celestia"
```

## 4. Install and update configuration

The installation below uses the `$HOME/go/bin` path from our node guide. If ExecStart uses another path, install the binary there instead.

Install the compiled node for this user.

```bash
GOBIN="$HOME/go/bin" make install
```

Install the matching key utility.

```bash
GOBIN="$HOME/go/bin" make install-key
```

Verify the installed release before restarting.

```bash
"$HOME/go/bin/celestia" version
```

Merge new configuration fields into the existing store. This is required when crossing from a version below v0.31.3; review it for every upgrade.

```bash
"$HOME/go/bin/celestia" bridge config-update --p2p.network celestia --node.store "$NODE_STORE"
```

Compare the old and updated configuration. A diff exit code of 1 means differences were found.

```bash
diff -u "$UPGRADE_DIR/backup/config.toml" "$NODE_STORE/config.toml"
```

Check your core endpoint, TLS mode, pruning, RPC authentication and listener addresses. Keep the existing store; do not run `init` or `unsafe-reset-store` as an upgrade step.

## 5. Start and verify

Start the existing unit with its saved flags.

```bash
sudo systemctl start celestia-bridge
```

Check the service state.

```bash
sudo systemctl status celestia-bridge --no-pager
```

Inspect startup and synchronization messages.

```bash
sudo journalctl -u celestia-bridge -n 100 --no-pager
```

Confirm that the core connection succeeds, headers advance, and shares are processed. A running service alone does not prove the node is healthy. Keep the consensus endpoint compatible and available; update a separately operated consensus process through its own maintenance procedure.

If startup fails, stop the service and read the first error. Do not overwrite the store or blindly downgrade after a datastore migration. Retain the backup and follow the release's recovery guidance.

Sources: [Official installation and upgrade instructions](https://docs.celestia.org/operate/data-availability/install-celestia-node/), [configuration update](https://docs.celestia.org/operate/maintenance/troubleshooting/), [release notes](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3).


# Install celestia-node

**Mainnet** · Chain ID `celestia`

Complete [Server Setup](/mainnet/celestia/consensus-node/server-setup), including Go. This installs the shared binary for light and bridge nodes.

## Build the selected release

Clone the exact network release into a new directory.

```bash
git clone --branch v0.34.3 --depth 1 https://github.com/celestiaorg/celestia-node.git "$HOME/celestia-node-v0.34.3"
```

Enter the source directory.

```bash
cd "$HOME/celestia-node-v0.34.3"
```

Build the celestia binary.

```bash
make build
```

Install the binary into your Go binary directory.

```bash
make install
```

Build the DA key utility.

```bash
make cel-key
```

Install the key utility.

```bash
make install-key
```

Confirm the selected version before initializing a node.

```bash
celestia version
```

Continue with [Light Node](/mainnet/celestia/light-node) or [Bridge Node](/mainnet/celestia/bridge-node).

Source: [Celestia documentation](https://docs.celestia.org/operate/data-availability/install-celestia-node/).


# Light Node

Already running a node? See [Upgrade](/mainnet/celestia/light-node/upgrade).

**Mainnet** · Chain ID `celestia`

A light node samples data availability. It does not become a validator or earn validator rewards by running.

Complete [Install celestia-node](/mainnet/celestia/bridge-node/install-da) first.

## Choose a consensus connection

Use an application gRPC endpoint for state queries and transactions. BlockPro publishes a [gRPC hostname](/mainnet/celestia/services/endpoints), but its port and TLS mode must be confirmed before using it in this command.

Initialize the light node store for Mainnet. Save any recovery phrase privately.

```bash
celestia light init --p2p.network celestia
```

Start the node in the foreground and inspect the connection. Use a bare hostname, without https\://. Add --core.tls only when the endpoint uses TLS.

```bash
celestia light start --p2p.network celestia --core.ip YOUR_CONFIRMED_GRPC_HOST --core.port YOUR_CONFIRMED_GRPC_PORT
```

After checking the foreground process, stop it with Ctrl+C before starting the same store under systemd.

## Run as a service

Create the service definition. Replace the Linux user, home and any endpoint placeholders.

```bash
sudo nano /etc/systemd/system/celestia-light.service
```

Paste this configuration; retain the same TLS choice used in your successful foreground test.

```ini
[Unit]
Description=Celestia light node (Mainnet)
Wants=network-online.target
After=network-online.target

[Service]
User=YOUR_LINUX_USER
Environment=HOME=/home/YOUR_LINUX_USER
ExecStart=/home/YOUR_LINUX_USER/go/bin/celestia light start --p2p.network celestia --core.ip YOUR_CONFIRMED_GRPC_HOST --core.port YOUR_CONFIRMED_GRPC_PORT
Restart=on-failure
RestartSec=5
LimitNOFILE=1400000

[Install]
WantedBy=multi-user.target
```

Load the new unit.

```bash
sudo systemctl daemon-reload
```

Enable and start the service.

```bash
sudo systemctl enable --now celestia-light
```

Check recent logs for successful connections and advancing headers.

```bash
sudo journalctl -u celestia-light -n 100 --no-pager
```

List addresses in the default DA key store. The test backend is unencrypted; do not keep a validator treasury in this store.

```bash
cel-key list --node.type light --p2p.network celestia --keyring-backend test
```

Source: [Celestia documentation](https://docs.celestia.org/operate/data-availability/light-node/quickstart/).


# Upgrade

Update your Celestia light node while keeping its existing store.

**Mainnet** · Chain ID `celestia`

Target release: [v0.34.3](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3). Check [Versions](/mainnet/celestia/versions) and the release notes before each upgrade.

This procedure follows the native systemd installation in [Light Node](/mainnet/celestia/light-node). Run commands as the service's Linux user. Keep the same node type, network, keys and data store.

## 1. Check the running installation

Inspect the service user, binary path, network and any custom store flag. If your unit has a different name, use it throughout.

```bash
sudo systemctl cat celestia-light
```

Print the currently installed version. The path must match ExecStart; adapt it if your installation differs.

```bash
"$HOME/go/bin/celestia" version
```

Set the existing store path from your service configuration or startup logs. Replace this placeholder before continuing.

```bash
NODE_STORE="/absolute/path/to/your/existing/light-store"
```

Confirm that this is an initialized store. Stop if the check fails.

```bash
test -f "$NODE_STORE/config.toml"
```

Check Go. The selected release requires Go 1.26.8 or later; see Server Setup if you need to update it.

```bash
go version
```

## 2. Build the selected release

Build before stopping the node. This does not replace its running binary.

Choose the network-specific release.

```bash
NODE_VERSION="v0.34.3"
```

Create a fresh working directory.

```bash
UPGRADE_DIR="$(mktemp -d "$HOME/celestia-node-upgrade.XXXXXX")"
```

Download the source for the selected tag.

```bash
git clone --branch "$NODE_VERSION" --depth 1 https://github.com/celestiaorg/celestia-node.git "$UPGRADE_DIR/source"
```

Enter the source directory.

```bash
cd "$UPGRADE_DIR/source"
```

Compile the node binary.

```bash
make build
```

Compile the matching key utility.

```bash
make cel-key
```

## 3. Stop and back up

If multiple services use the same binary, coordinate their maintenance before replacing it. For a release that changes the datastore, take a consistent snapshot of the entire store while stopped. The small backup below covers keys, configuration and the old executable.

Stop this node.

```bash
sudo systemctl stop celestia-light
```

Confirm its process has exited. Continue only if this succeeds.

```bash
test "$(systemctl show celestia-light --property=MainPID --value)" = "0"
```

Create a private backup directory.

```bash
mkdir -m 0700 "$UPGRADE_DIR/backup"
```

Back up configuration.

```bash
cp -p "$NODE_STORE/config.toml" "$UPGRADE_DIR/backup/config.toml"
```

Back up DA keys. Keep this directory private.

```bash
cp -a "$NODE_STORE/keys" "$UPGRADE_DIR/backup/keys"
```

Keep the previous executable.

```bash
cp -p "$HOME/go/bin/celestia" "$UPGRADE_DIR/backup/celestia"
```

## 4. Install and update configuration

The installation below uses the `$HOME/go/bin` path from our node guide. If ExecStart uses another path, install the binary there instead.

Install the compiled node for this user.

```bash
GOBIN="$HOME/go/bin" make install
```

Install the matching key utility.

```bash
GOBIN="$HOME/go/bin" make install-key
```

Verify the installed release before restarting.

```bash
"$HOME/go/bin/celestia" version
```

Merge new configuration fields into the existing store. This is required when crossing from a version below v0.31.3; review it for every upgrade.

```bash
"$HOME/go/bin/celestia" light config-update --p2p.network celestia --node.store "$NODE_STORE"
```

Compare the old and updated configuration. A diff exit code of 1 means differences were found.

```bash
diff -u "$UPGRADE_DIR/backup/config.toml" "$NODE_STORE/config.toml"
```

Check your core endpoint, TLS mode, pruning, RPC authentication and listener addresses. Keep the existing store; do not run `init` or `unsafe-reset-store` as an upgrade step.

## 5. Start and verify

Start the existing unit with its saved flags.

```bash
sudo systemctl start celestia-light
```

Check the service state.

```bash
sudo systemctl status celestia-light --no-pager
```

Inspect startup and synchronization messages.

```bash
sudo journalctl -u celestia-light -n 100 --no-pager
```

Confirm that peers connect, headers advance, and sampling resumes. A running service alone does not prove the node is healthy. Keep the same confirmed gRPC address and TLS settings.

If startup fails, stop the service and read the first error. Do not overwrite the store or blindly downgrade after a datastore migration. Retain the backup and follow the release's recovery guidance.

Sources: [Official installation and upgrade instructions](https://docs.celestia.org/operate/data-availability/install-celestia-node/), [configuration update](https://docs.celestia.org/operate/maintenance/troubleshooting/), [release notes](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3).


# Full Storage Node

**Mainnet** · Chain ID `celestia`

This page refers to a **DA full storage node** (`celestia full`), not a consensus full node (`celestia-appd`). For a new RPC node, use [Consensus Node](/mainnet/celestia/consensus-node).

The current Celestia operator overview lists Light and Bridge as its DA setup paths. Older BlockPro instructions use an earlier full-node release. Keep an existing full-node deployment on its documented upgrade path until its target release and storage migration are confirmed.

Identify the installed DA release.

```bash
celestia version
```

Check whether the installed release exposes the full-node command. An error means this guide must not be used as an installation path.

```bash
celestia full --help
```

Do not change `full` to `bridge` over the same data directory. Use a separate store and a release-specific migration procedure. Full-storage installation commands will be published here after that path has been validated.

Source: [Current node types](https://docs.celestia.org/operate/getting-started/overview/).


# Services

BlockPro infrastructure for this network.

| Service                                                   | What you will find                      |
| --------------------------------------------------------- | --------------------------------------- |
| [Public Endpoints](/mainnet/celestia/services/endpoints)  | RPC, REST API, gRPC and explorer        |
| [Peers and Seeds](/mainnet/celestia/services/peers-seeds) | Connection addresses and seed setup     |
| [Live Peers](/mainnet/celestia/services/live-peers)       | Peer discovery and availability notes   |
| [Addrbook](/mainnet/celestia/services/addrbook)           | Download and replacement steps          |
| [Snapshots](/mainnet/celestia/services/snapshots)         | Snapshot metadata and restore procedure |


# Public Endpoints

**Mainnet** · Chain ID `celestia`

## BlockPro endpoints

| Service   | Address                                                         | Use                                    |
| --------- | --------------------------------------------------------------- | -------------------------------------- |
| RPC       | <https://celestia-rpc-mainnet.block-pro.net/>                   | Chain status and consensus queries     |
| REST API  | <https://celestia-api-mainnet.block-pro.net/>                   | Cosmos SDK REST queries                |
| gRPC host | `celestia-grpc-mainnet.block-pro.net`                           | Application gRPC; transport to confirm |
| Explorer  | [Open explorer](https://mainnet.block-pro.net/celestia/staking) | Blocks, transactions and validators    |

Addresses are taken from the [existing BlockPro service page](https://service.block-pro.net/mainnet/celestia/validator-node/services-or-snapshot). A listing is not a live availability check. The existing page publishes this hostname as an HTTPS URL. Confirm the actual gRPC port and TLS settings before use.

## Check the network before use

Read the reported network, height and block time.

```bash
curl -fsS --max-time 15 https://celestia-rpc-mainnet.block-pro.net/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

The chain must be `celestia`. Check that block time is recent and height advances; `catching_up: false` alone does not prove the service is current.

## Usage

Use retry backoff for transient failures. Rate limits, archival coverage and availability commitments have not been published here. For production capacity or private infrastructure, [contact BlockPro](https://t.me/BLOCK_PR0).


# Peers and Seeds

**Mainnet** · Chain ID `celestia`

| Connection             | BlockPro value                                |
| ---------------------- | --------------------------------------------- |
| Consensus peer         | Not published yet; the existing page says TBD |
| Seed                   | Not published yet                             |
| DA bridge multiaddress | Not published yet                             |

Consensus peers use `node_id@host:port`. DA peers use libp2p multiaddresses. They are not interchangeable.

## Use the official seed list

Download the seed list for this network; stop if the URL does not return a valid list.

```bash
curl -fL --retry 3 -o "$HOME/celestia-seeds.txt" https://raw.githubusercontent.com/celestiaorg/networks/master/celestia/seeds.txt
```

Inspect the seed addresses.

```bash
cat "$HOME/celestia-seeds.txt"
```

Format the addresses as a comma-separated value.

```bash
tr '\n' ',' < "$HOME/celestia-seeds.txt" | sed 's/,$//'
```

Set seeds inside the existing \[p2p] section. Add persistent\_peers only for deliberately selected peers.

```bash
nano "$HOME/.celestia-app/config/config.toml"
```

Restart after saving a valid configuration.

```bash
sudo systemctl restart celestia-appd
```

Source: [Celestia documentation](https://docs.celestia.org/operate/consensus-validators/consensus-node/).


# Live Peers

**Mainnet** · Chain ID `celestia`

A BlockPro Live Peers feed is not published in the current documentation. Do not treat the example below as a hosted feed.

## Inspect connected peers locally

List the node ID, observed IP and advertised listener for peers connected to your own consensus node.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.peers[]? | [.node_info.id, .remote_ip, .node_info.listen_addr] | @tsv'
```

An advertised listener can be private or unreachable. Do not automatically turn this output into persistent peers. A public feed should include a network, a checked-at timestamp and a reachability check for each address.

Use [Peers and Seeds](/mainnet/celestia/services/peers-seeds) for initial connectivity.


# Addrbook

**Mainnet** · Chain ID `celestia`

An address book helps a consensus node discover peers. It does not contain blockchain state and cannot synchronize a node by itself.

Published URL: <https://server-2.block-pro.net/mainnet/celestia/addrbook.json>

The existing service page describes hourly updates; freshness has not been independently confirmed. An older snapshot command also uses files.block-pro.net/mainnet/celestia/addrbook.json. Confirm the canonical host before publication.

## Replace an address book

Download to a temporary file, leaving the current address book untouched.

```bash
curl -fL --retry 3 -o "$HOME/addrbook.download.json" https://server-2.block-pro.net/mainnet/celestia/addrbook.json
```

Check that the downloaded file has an address list. This does not prove reachability or network membership.

```bash
jq -e '.addrs | type == "array"' "$HOME/addrbook.download.json"
```

Stop the node before changing its address book.

```bash
sudo systemctl stop celestia-appd
```

Back up the existing file. Skip only if this is a new node with no addrbook yet.

```bash
cp -p "$HOME/.celestia-app/config/addrbook.json" "$HOME/.celestia-app/config/addrbook.json.backup"
```

Install the downloaded file as the node user.

```bash
install -m 600 "$HOME/addrbook.download.json" "$HOME/.celestia-app/config/addrbook.json"
```

Start the node and check peer connections in the logs.

```bash
sudo systemctl start celestia-appd
```

Source: [BlockPro services](https://service.block-pro.net/mainnet/celestia/validator-node/services-or-snapshot).


# Snapshots

**Mainnet** · Chain ID `celestia`

Restore a **consensus** node from a BlockPro snapshot. This archive is not a light-node or bridge-node snapshot.

| Field                                 | Published information                                             |
| ------------------------------------- | ----------------------------------------------------------------- |
| Download                              | <https://server-2.block-pro.net/mainnet/celestia/snapshot/latest> |
| Compression                           | Existing guide uses LZ4                                           |
| Update schedule                       | Existing guide says every 4 hours; freshness unverified           |
| Height and creation time              | Not published                                                     |
| Checksum                              | Not published                                                     |
| DB backend and compatible app version | Not published                                                     |
| Pruning and history coverage          | Not published                                                     |

**Before restoring:** obtain the missing metadata and SHA-256 checksum from BlockPro, confirm chain `celestia`, and match the app version and database backend. A snapshot from a different network or an incompatible backend cannot be used. Until this metadata is available, the procedure below is a preparation guide, not a verified restore path.

## Download and inspect

Create a unique staging directory on a disk with enough space for both the archive and extracted data.

```bash
RESTORE_DIR=$(mktemp -d "$HOME/celestia-restore.XXXXXXXX")
```

Download the complete archive. A failed download must not replace your node data.

```bash
curl -fL --retry 3 --output "$RESTORE_DIR/snapshot.tar.lz4" https://server-2.block-pro.net/mainnet/celestia/snapshot/latest
```

Compare this checksum with the independently obtained checksum for this exact snapshot. Stop if no matching checksum is available.

```bash
sha256sum "$RESTORE_DIR/snapshot.tar.lz4"
```

Check the compression stream.

```bash
lz4 --test "$RESTORE_DIR/snapshot.tar.lz4"
```

Inspect archive paths and types. Accept only the agreed data/ layout; stop on absolute paths, parent traversal, links, device files, config/ or key files.

```bash
tar --use-compress-program=lz4 -tvf "$RESTORE_DIR/snapshot.tar.lz4"
```

Create the isolated extraction directory.

```bash
mkdir "$RESTORE_DIR/staged"
```

Extract the inspected, verified archive as the node user, never as root.

```bash
tar --use-compress-program=lz4 --no-same-owner --no-same-permissions -xf "$RESTORE_DIR/snapshot.tar.lz4" -C "$RESTORE_DIR/staged"
```

Confirm the extracted directory is `staged/data/` and matches the published backend. A successful extraction alone does not validate snapshot integrity or provenance.

## Replace data while preserving signing state

For a validator, first ensure no other machine or remote signer is running the same consensus key. Keep the original configuration and keys. The backup below must be made after the node stops.

Stop the node.

```bash
sudo systemctl stop celestia-appd
```

Verify it reports inactive. Do not proceed while the node is running.

```bash
sudo systemctl is-active celestia-appd
```

Preserve your latest signing state. Stop if it is missing on an existing validator.

```bash
cp -p "$HOME/.celestia-app/data/priv_validator_state.json" "$RESTORE_DIR/priv_validator_state.json"
```

Put your own signing state into the staged data, replacing any provider state.

```bash
install -m 600 "$RESTORE_DIR/priv_validator_state.json" "$RESTORE_DIR/staged/data/priv_validator_state.json"
```

Keep the original data for recovery instead of deleting it.

```bash
mv "$HOME/.celestia-app/data" "$RESTORE_DIR/original-data"
```

Install the restored data directory.

```bash
mv "$RESTORE_DIR/staged/data" "$HOME/.celestia-app/data"
```

If this move fails, keep the service stopped and restore `original-data` before taking another action. Do not restart with an incomplete directory.

Start only after the data and signing-state checks pass.

```bash
sudo systemctl start celestia-appd
```

Inspect database, consensus and sync messages.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager
```

Check the chain, advancing block height, recent block time and catching\_up status.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, sync: .sync_info}'
```

Keep the backup until the restored node is healthy. For validators, never restore an older signing-state file after the restored node has signed new blocks.

Sources: [BlockPro snapshot listing](https://service.block-pro.net/mainnet/celestia/validator-node/services-or-snapshot) and [Celestia snapshots](https://docs.celestia.org/operate/maintenance/snapshots/).


# Useful Commands

**Mainnet · `celestia`**

Everyday service, key, token and validator operations on one page. Commands use the homes and service names in our installation guides.

Use the `validator` account name and `file` keyring from our setup. Replace address and fee placeholders before use. Transaction confirmation remains interactive. **1 TIA = 1,000,000 utia**; keep additional funds for fees.

## Service operations

### Select service

Choose celestia-appd for consensus, celestia-bridge for bridge, or celestia-light for light nodes.

```bash
SERVICE=celestia-appd
```

### Status

Check the selected systemd service.

```bash
sudo systemctl status "$SERVICE" --no-pager
```

### Start

Start the node.

```bash
sudo systemctl start "$SERVICE"
```

### Stop

Stop the node.

```bash
sudo systemctl stop "$SERVICE"
```

### Restart

Restart after a configuration change.

```bash
sudo systemctl restart "$SERVICE"
```

### Recent logs

Show the last 100 log lines.

```bash
sudo journalctl -u "$SERVICE" -n 100 --no-pager
```

### Follow logs

Follow logs; Ctrl+C leaves the log view.

```bash
sudo journalctl -u "$SERVICE" -f
```

### Sync status

Check consensus height, block time and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

### Peer count

Count consensus peers.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.n_peers'
```

### Free disk space

Check available space.

```bash
df -h "$HOME/.celestia-app"
```

### Data size

Measure consensus data usage.

```bash
du -sh "$HOME/.celestia-app/data"
```

## Key management

These are celestia-app operator accounts. DA keys use `cel-key`; consensus signing keys are separate.

### Create

Create an encrypted operator wallet; store its recovery phrase offline.

```bash
celestia-appd keys add validator --keyring-backend file
```

### Recover

Recover an existing wallet through the interactive prompt.

```bash
celestia-appd keys add validator --recover --keyring-backend file
```

### List

List local operator wallets.

```bash
celestia-appd keys list --keyring-backend file
```

### Account address

Show the account address.

```bash
celestia-appd keys show validator -a --keyring-backend file
```

### Validator address

Show the validator operator address.

```bash
celestia-appd keys show validator --bech val -a --keyring-backend file
```

### Rename

Rename the local key and use the new name in later commands.

```bash
celestia-appd keys rename validator validator-new --keyring-backend file
```

## Tokens

### Set gas price

Replace the placeholder with a gas price accepted by your network, including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Balance

Read an account balance.

```bash
celestia-appd query bank balances YOUR_ACCOUNT_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Send

Send 1 TIA and review the destination before confirming.

```bash
celestia-appd tx bank send validator YOUR_RECIPIENT_ADDRESS 1000000utia \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Delegate

Delegate 1 TIA to the chosen validator.

```bash
celestia-appd tx staking delegate YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Withdraw rewards

Withdraw rewards from the chosen validator.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_VALOPER_ADDRESS \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unbond

Begin undelegating 1 TIA; the network unbonding period applies.

```bash
celestia-appd tx staking unbond YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Transaction status

Check inclusion and execution code; use an indexed endpoint if needed.

```bash
celestia-appd query tx YOUR_TX_HASH --node http://127.0.0.1:26657 -o json
```

## Validator operations

### Details

Inspect status, stake, commission and jailed state.

```bash
celestia-appd query staking validator YOUR_VALOPER_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Consensus public key

Show the local consensus public key.

```bash
celestia-appd tendermint show-validator
```

### Set gas price

Set an accepted gas price including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Edit name

Update the public validator name.

```bash
celestia-appd tx staking edit-validator \
  --new-moniker "YOUR_NEW_NAME" \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Commission and rewards

Withdraw your validator commission and rewards.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_OWN_VALOPER_ADDRESS \
  --commission \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unjail

Use only after fixing the cause of jailing; tombstoned validators cannot unjail.

```bash
celestia-appd tx slashing unjail \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

For initial registration, follow [Validator Node](/mainnet/celestia/validator-node).

[CLI reference](https://docs.celestia.org/operate/consensus-validators/cli-reference/) · [Service management](https://docs.celestia.org/operate/maintenance/systemd/)


# Service Operations

**Mainnet · `celestia`**

The complete reference is now on [Useful Commands](/mainnet/celestia/useful-commands#service-operations).

## Service operations

### Select service

Choose celestia-appd for consensus, celestia-bridge for bridge, or celestia-light for light nodes.

```bash
SERVICE=celestia-appd
```

### Status

Check the selected systemd service.

```bash
sudo systemctl status "$SERVICE" --no-pager
```

### Start

Start the node.

```bash
sudo systemctl start "$SERVICE"
```

### Stop

Stop the node.

```bash
sudo systemctl stop "$SERVICE"
```

### Restart

Restart after a configuration change.

```bash
sudo systemctl restart "$SERVICE"
```

### Recent logs

Show the last 100 log lines.

```bash
sudo journalctl -u "$SERVICE" -n 100 --no-pager
```

### Follow logs

Follow logs; Ctrl+C leaves the log view.

```bash
sudo journalctl -u "$SERVICE" -f
```

### Sync status

Check consensus height, block time and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

### Peer count

Count consensus peers.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.n_peers'
```

### Free disk space

Check available space.

```bash
df -h "$HOME/.celestia-app"
```

### Data size

Measure consensus data usage.

```bash
du -sh "$HOME/.celestia-app/data"
```


# Key Management

**Mainnet · `celestia`**

The complete reference is now on [Useful Commands](/mainnet/celestia/useful-commands#key-management).

## Key management

These are celestia-app operator accounts. DA keys use `cel-key`; consensus signing keys are separate.

### Create

Create an encrypted operator wallet; store its recovery phrase offline.

```bash
celestia-appd keys add validator --keyring-backend file
```

### Recover

Recover an existing wallet through the interactive prompt.

```bash
celestia-appd keys add validator --recover --keyring-backend file
```

### List

List local operator wallets.

```bash
celestia-appd keys list --keyring-backend file
```

### Account address

Show the account address.

```bash
celestia-appd keys show validator -a --keyring-backend file
```

### Validator address

Show the validator operator address.

```bash
celestia-appd keys show validator --bech val -a --keyring-backend file
```

### Rename

Rename the local key and use the new name in later commands.

```bash
celestia-appd keys rename validator validator-new --keyring-backend file
```


# Tokens

**Mainnet · `celestia`**

The complete reference is now on [Useful Commands](/mainnet/celestia/useful-commands#tokens).

## Tokens

### Set gas price

Replace the placeholder with a gas price accepted by your network, including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Balance

Read an account balance.

```bash
celestia-appd query bank balances YOUR_ACCOUNT_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Send

Send 1 TIA and review the destination before confirming.

```bash
celestia-appd tx bank send validator YOUR_RECIPIENT_ADDRESS 1000000utia \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Delegate

Delegate 1 TIA to the chosen validator.

```bash
celestia-appd tx staking delegate YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Withdraw rewards

Withdraw rewards from the chosen validator.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_VALOPER_ADDRESS \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unbond

Begin undelegating 1 TIA; the network unbonding period applies.

```bash
celestia-appd tx staking unbond YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Transaction status

Check inclusion and execution code; use an indexed endpoint if needed.

```bash
celestia-appd query tx YOUR_TX_HASH --node http://127.0.0.1:26657 -o json
```


# Validator Operations

**Mainnet · `celestia`**

The complete reference is now on [Useful Commands](/mainnet/celestia/useful-commands#validator-operations).

## Validator operations

### Details

Inspect status, stake, commission and jailed state.

```bash
celestia-appd query staking validator YOUR_VALOPER_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Consensus public key

Show the local consensus public key.

```bash
celestia-appd tendermint show-validator
```

### Set gas price

Set an accepted gas price including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Edit name

Update the public validator name.

```bash
celestia-appd tx staking edit-validator \
  --new-moniker "YOUR_NEW_NAME" \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Commission and rewards

Withdraw your validator commission and rewards.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_OWN_VALOPER_ADDRESS \
  --commission \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unjail

Use only after fixing the cause of jailing; tombstoned validators cannot unjail.

```bash
celestia-appd tx slashing unjail \
  --from validator \
  --chain-id celestia \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```


# Troubleshooting

**Mainnet** · Chain ID `celestia`

| Symptom                               | First check                                                                       |
| ------------------------------------- | --------------------------------------------------------------------------------- |
| Wrong chain or genesis error          | Verify genesis chain\_id is celestia; do not reuse the other network's data.      |
| gRPC connection refused               | Confirm application gRPC is enabled and the host, port and TLS mode match.        |
| Bridge cannot find old blocks         | Use an archival consensus source with the required historical coverage.           |
| Service keeps restarting              | Read the first error in journalctl; check binary path, user and file permissions. |
| catching\_up is false but no progress | Compare block timestamps and height with an independent, current source.          |
| Snapshot database error               | Stop the node and check app version, backend and archive layout.                  |
| Insufficient fees                     | Recheck the endpoint's current fee policy and the gas-price denomination.         |
| Full command is unavailable           | Follow the release-specific migration path; do not reuse the store as a bridge.   |

## Ask for help

Include the network, node type, binary version and the relevant error lines. Remove recovery phrases, private keys and authentication tokens before sharing logs.

[Contact BlockPro](https://t.me/BLOCK_PR0) · [Celestia troubleshooting](https://docs.celestia.org/operate/maintenance/troubleshooting/)


# Dora

Dora Vota Mainnet: node guides, services and operations.

**Mainnet · `vota-ash` · dorad**

Run a Dora Vota full node and, optionally, register a validator.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Installation</strong></td><td>Prepare the server and synchronize the node.</td><td><a href="/mainnet/dora/installation">Installation</a></td></tr><tr><td><strong>Validator</strong></td><td>Create a wallet and register your validator.</td><td><a href="/mainnet/dora/validator">Validator</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Install an approved release and verify recovery.</td><td><a href="/mainnet/dora/upgrade">Upgrade</a></td></tr><tr><td><strong>Services</strong></td><td>Endpoints, peers and connection files.</td><td><a href="/mainnet/dora/services">Services</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Restore recent chain data step by step.</td><td><a href="/mainnet/dora/snapshots">Snapshots</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, keys, tokens and validator operations.</td><td><a href="/mainnet/dora/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Requirements

| Resource              | Network recommendation |
| --------------------- | ---------------------- |
| CPU                   | 16 cores, x86-64       |
| RAM                   | 32 GB                  |
| Storage               | 1 TB NVMe or larger    |
| OS used in this guide | Ubuntu 24.04 LTS       |

These are the [official network hardware recommendations](https://docs.dorafactory.org/docs/vota-devops/node). Keep extra disk space for snapshot extraction, backups and chain growth. Use separate servers or fully isolated homes, services and ports for Mainnet and Testnet.

Allow P2P traffic on TCP `26656`. Keep RPC `26657`, REST `1317`, gRPC `9090` and metrics private unless deliberately operating a protected public service.

## Versions

Reference release: **v1.0.0**, source commit `1a2b30927a7799d4cd6890a3fb3fa80d25613fa2`. The [official v1.0.0 release](https://github.com/DoraFactory/doravota/releases/tag/v1.0.0) includes a static Linux amd64 binary.

Read the application version and chain ID before installation or upgrade.

```bash
curl -fsS https://dora-mainnet-api.block-pro.net/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version, commit: .application_version.git_commit}'
```

A fresh v1.0.0 installation should use a recent **post-upgrade snapshot for vota-ash**. Historical genesis replay needs the historical binaries and upgrade sequence. Existing 0.5.0 nodes must follow the [Upgrade guide](/mainnet/dora/upgrade); a release tag alone is not permission to switch before the network's upgrade boundary.

## Network

| Setting           | Value                  |
| ----------------- | ---------------------- |
| Chain ID          | `vota-ash`             |
| Binary / service  | `dorad`                |
| Node home         | `$HOME/.dora`          |
| Base denomination | `peaka`                |
| Token precision   | `1 DORA = 10^18 peaka` |

[Official repository](https://github.com/DoraFactory/doravota) · [Explorer](https://vota-explorer.dorafactory.org) · [Services](/mainnet/dora/services)


# Installation

Install and synchronize Dora Mainnet, one command at a time.

**Mainnet · `vota-ash` · v1.0.0**

Use a fresh Ubuntu 24.04 x86-64 server and a regular user with sudo access. Run all commands as the same user; the service will use that user's `$HOME/.dora`. Check [requirements](/mainnet/dora#requirements) first.

For an existing node, use [Upgrade](/mainnet/dora/upgrade). Do not initialize over an existing validator home. A current post-v1.0.0 Mainnet snapshot is required for the bootstrap path below; confirm availability on [Snapshots](/mainnet/dora/snapshots) before beginning.

## Prepare the server

### Refresh packages

Load the Ubuntu package index.

```bash
sudo apt update
```

### Install utilities

Install tools for downloads, JSON, editing and compressed snapshots.

```bash
sudo apt install -y ca-certificates curl jq lz4 tar nano less
```

### Check architecture

Continue with this release asset only when the output is x86\_64.

```bash
uname -m
```

## Install the binary

### Download v1.0.0

Save the official static Linux amd64 binary.

```bash
curl -fL https://github.com/DoraFactory/doravota/releases/download/v1.0.0/dorad-v1.0.0-linux-amd64 -o "$HOME/dorad-v1.0.0"
```

### Verify SHA-256

Expect OK. Stop if the checksum fails.

```bash
echo "5c741ca406ee2ecb811dd62d83e9a446fee051e2947522525c2560a0a7ce968a  $HOME/dorad-v1.0.0" | sha256sum -c -
```

### Install dorad

Install the verified executable. No Go compiler or libwasmvm shared library is needed.

```bash
sudo install -m 0755 "$HOME/dorad-v1.0.0" /usr/local/bin/dorad
```

### Check the binary

Confirm v1.0.0 and the source commit shown on the project overview.

```bash
dorad version --long
```

## Initialize the node

### Set a moniker

Choose the public name of this node.

```bash
read -rp "Node moniker: " MONIKER
```

### Initialize a new home

Create fresh configuration and node identity. Run once on a new server.

```bash
dorad init "$MONIKER" --chain-id vota-ash --home "$HOME/.dora"
```

### Download genesis

Use the official network genesis pinned to the release tag.

```bash
curl -fL https://raw.githubusercontent.com/DoraFactory/doravota/v1.0.0/config/mainnet/genesis.json -o "$HOME/.dora/config/genesis.json"
```

### Verify genesis

Expect OK. Stop on a mismatch.

```bash
echo "bb1f3841ad636a8dc5320ca39266adc00f27c312d0e73eb35f8a4384306bcbd6  $HOME/.dora/config/genesis.json" | sha256sum -c -
```

### Confirm the chain ID

The result must be vota-ash.

```bash
jq -r .chain_id "$HOME/.dora/config/genesis.json"
```

### Set the minimum gas price

Set a local mempool fee floor in peaka; this is not a fixed transaction fee.

```bash
sed -i 's/^minimum-gas-prices *=.*/minimum-gas-prices = "100000000000peaka"/' "$HOME/.dora/config/app.toml"
```

### Set a discovery seed

Use the ITRocket seed for this network.

```bash
sed -i 's|^seeds *=.*|seeds = "4ec0eb59ae35418a9bfa3df3783bad4f372b49c0@doravota-mainnet-seed.itrocket.net:42656"|' "$HOME/.dora/config/config.toml"
```

### Set a persistent peer

Add the separately operated ITRocket peer.

```bash
sed -i 's|^persistent_peers *=.*|persistent_peers = "d6edfdb5eae3565a4af1ce35fd2c03084b8c3ef1@doravota-mainnet-peer.itrocket.net:42656"|' "$HOME/.dora/config/config.toml"
```

### Review network exposure

Keep RPC on 127.0.0.1:26657 and statesync disabled for snapshot restoration. In app.toml, keep API/gRPC disabled or bound to loopback.

```bash
nano "$HOME/.dora/config/config.toml" "$HOME/.dora/config/app.toml"
```

Allow inbound TCP 26656 in your host and provider firewalls. Preserve your actual SSH port and administrative access when changing firewall rules.

## Create the service

### Create the systemd unit

Run as the same non-root user used for initialization. The command records this user's actual name and home.

```bash
sudo tee /etc/systemd/system/dorad.service > /dev/null <<EOF
[Unit]
Description=Dora Vota Mainnet
Wants=network-online.target
After=network-online.target

[Service]
User=$(whoami)
WorkingDirectory=$HOME
ExecStart=/usr/local/bin/dorad start --home $HOME/.dora
Restart=on-failure
RestartSec=10
LimitNOFILE=65535
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
EOF
```

### Reload systemd

Load the new unit without starting it.

```bash
sudo systemctl daemon-reload
```

## Restore and start

Follow [Snapshots](/mainnet/dora/snapshots) to restore a recent **vota-ash snapshot created after the v1.0.0 migration**. Do not start v1.0.0 against an empty database and assume it can replay the entire historical chain. Keep the configuration and identity created above.

### Enable and start

Run only after the snapshot restore has completed successfully.

```bash
sudo systemctl enable --now dorad
```

### Follow logs

Check peers, successful block processing and any errors. Ctrl+C exits the log view without stopping the node.

```bash
sudo journalctl -u dorad -f -o cat
```

### Verify synchronization

Confirm the correct network, a current block time and catching\_up=false. Compare height with an independent public RPC.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

Continue to [Validator](/mainnet/dora/validator) only after the node is fully synchronized.

[Official node guide](https://docs.dorafactory.org/docs/vota-devops/node) · [v1.0.0 release](https://github.com/DoraFactory/doravota/releases/tag/v1.0.0) · [ITRocket network reference](https://itrocket.space/services/mainnet/doravota/installation/)


# Validator

Create and maintain a Dora Mainnet validator.

**Mainnet · `vota-ash` · v1.0.0**

Complete [Installation](/mainnet/dora/installation) and wait for full synchronization. These examples use a local key named `wallet` with the encrypted `file` keyring. Transactions ask for confirmation; review the destination, amount and fee before signing.

Never run the same consensus key on two nodes. Keep `config/priv_validator_key.json`, the latest `data/priv_validator_state.json` and wallet recovery words in secure backups.

## Prepare the wallet

### Create a wallet

Record the recovery words privately and offline. Do not share the output or store it in a public document.

```bash
dorad keys add wallet --keyring-backend file --home "$HOME/.dora"
```

Already have a wallet? Use [Key management](/mainnet/dora/useful-commands#key-management) to restore it instead of creating another key.

### Show the account address

Use this address to fund the wallet.

```bash
dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora"
```

Fund this address with enough DORA for self-delegation and transaction fees.

### Check the balance

Amounts are returned in base units. 1 DORA equals 1000000000000000000 peaka.

```bash
dorad query bank balances "$(dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

### Confirm synchronization

Require the correct network, a current block time and catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

## Register the validator

The v1.0.0 CLI uses a **JSON definition file** with `create-validator`. Old examples that pass every field directly as a flag are not the format used here.

### Choose a public moniker

Set your validator's display name.

```bash
read -rp "Validator moniker: " MONIKER
```

### Choose the self-delegation amount

Enter an amount with its base denomination, for example 1000000000000000000peaka for 1 DORA. Leave funds for fees; this example is not an active-set minimum.

```bash
read -rp "Self-delegation amount (integer followed by peaka): " SELF_DELEGATION
```

### Write the validator definition

Read your node's public consensus key and create the JSON file. Commission values below are examples: 10% initially, 20% maximum, 1 percentage point maximum change per day.

```bash
jq -n \
  --argjson pubkey "$(dorad comet show-validator --home "$HOME/.dora")" \
  --arg amount "$SELF_DELEGATION" --arg moniker "$MONIKER" \
  '{pubkey:$pubkey, amount:$amount, moniker:$moniker, identity:"", website:"", security:"", details:"", "commission-rate":"0.10", "commission-max-rate":"0.20", "commission-max-change-rate":"0.01", "min-self-delegation":"1"}' > "$HOME/validator.json"
```

### Review the definition

Edit identity, website, security contact and details as needed. Commission maximums cannot be freely changed later; min-self-delegation is expressed in peaka.

```bash
nano "$HOME/validator.json"
```

### Create the validator

Simulate gas and review the transaction before confirming. A successful broadcast is not yet proof of on-chain success.

```bash
dorad tx staking create-validator "$HOME/validator.json" --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Inspect the transaction

Replace TX\_HASH with the hash returned after broadcast. Wait for inclusion and confirm the transaction succeeded.

```bash
dorad query tx TX_HASH --node http://127.0.0.1:26657 --output json
```

### Read validator status

Check jailed status, self-delegation and whether the validator is bonded.

```bash
dorad query staking validator "$(dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

Joining the active set depends on the network's validator limit and stake ranking. Registration alone does not guarantee block-signing status. Use [Useful Commands](/mainnet/dora/useful-commands) for delegation, rewards and unjailing.

[Official validator guide](https://docs.dorafactory.org/docs/vota-devops/validator) · [v1.0.0 operator notes](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md)


# Upgrade

Upgrade Dora Mainnet at the approved boundary and verify recovery.

**Mainnet · `vota-ash` · v1.0.0**

This guide targets v1.0.0; confirm the live network version with the command below. An already healthy v1.0.0 node does not need to repeat the migration.

The official upgrade path is **0.5.0 → v1.0.0** at the approved governance boundary. A node still catching up on 0.5.0 must reach the recorded `UPGRADE "v1.0.0" NEEDED` boundary before a manual binary switch. Confirm the plan and height from the network announcement and on-chain record; this guide does not invent an upgrade height.

New nodes should follow [Installation](/mainnet/dora/installation) and restore a recent post-upgrade [snapshot](/mainnet/dora/snapshots).

## Before changing the binary

### Read your version

Check which binary is currently installed.

```bash
dorad version --long
```

### Read the network version

Verify the application version and chain ID reported by the public API.

```bash
curl -fsS https://dora-mainnet-api.block-pro.net/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

### Read a pending upgrade plan

A completed plan may no longer appear here. For an offline or halted node, use its upgrade record and the official network announcement.

```bash
dorad query upgrade plan --node http://127.0.0.1:26657 --output json
```

### Inspect the effective service

Identify the actual binary, home and any ExecStart overrides. Commands below target the manual service from our installation guide.

```bash
sudo systemctl cat dorad
```

### Inspect halt settings

Ensure app.toml uses halt-height=0 and no obsolete service flag forces a different halt.

```bash
grep -nE '^halt-height|^halt-time' "$HOME/.dora/config/app.toml"
```

Back up the current configuration, binary and a consistent database before migration. Retain the latest validator signing state and any external Wasm bytecode needed for historical research. Never run two copies of the consensus key.

## Prepare the verified binary

### Download the release

Stage the file without replacing the running executable.

```bash
curl -fL https://github.com/DoraFactory/doravota/releases/download/v1.0.0/dorad-v1.0.0-linux-amd64 -o "$HOME/dorad-v1.0.0"
```

### Verify SHA-256

Expect OK. Stop on a mismatch.

```bash
echo "5c741ca406ee2ecb811dd62d83e9a446fee051e2947522525c2560a0a7ce968a  $HOME/dorad-v1.0.0" | sha256sum -c -
```

### Make the staged file executable

Apply executable permissions to the verified file.

```bash
chmod 0755 "$HOME/dorad-v1.0.0"
```

### Check the staged version

Expect v1.0.0 and commit 1a2b30927a7799d4cd6890a3fb3fa80d25613fa2.

```bash
"$HOME/dorad-v1.0.0" version --long
```

## Manual service upgrade

Proceed only when your 0.5.0 node has reached the correct migration boundary. For other source versions, first follow the intervening official upgrade sequence. Run these commands as the same user that owns the node home.

### Stop the service

Stop the supervisor before replacing the binary or copying live database files.

```bash
sudo systemctl stop dorad
```

### Confirm shutdown

Expect inactive. Stop any other process using this same home.

```bash
sudo systemctl is-active dorad
```

### Name the backup directory

Keep this shell open for the following steps.

```bash
DORA_UPGRADE_BACKUP="$HOME/dora-upgrade-backup-$(date +%Y%m%d-%H%M%S)"
```

### Create private backup storage

Ensure sufficient free space for a complete copy of the node home.

```bash
install -d -m 0700 "$DORA_UPGRADE_BACKUP"
```

### Back up the stopped node

Preserve configuration, consistent data and latest signing state together.

```bash
cp -a "$HOME/.dora" "$DORA_UPGRADE_BACKUP/home"
```

### Preserve the old executable

Keep it for investigation; do not restart it against migrated state.

```bash
cp -a /usr/local/bin/dorad "$DORA_UPGRADE_BACKUP/dorad-previous"
```

### Install v1.0.0

Replace the executable only after all preceding checks and backups succeed.

```bash
sudo install -m 0755 "$HOME/dorad-v1.0.0" /usr/local/bin/dorad
```

### Start the node

Resume with the existing home and signing state.

```bash
sudo systemctl start dorad
```

### Check logs

Confirm migration completes and blocks advance beyond the upgrade boundary.

```bash
sudo journalctl -u dorad -f -o cat
```

## Cosmovisor installations

Use this branch only if you already operate Cosmovisor. The plan name and directory are **v1.0.0**, including the `v`. Do not also perform the manual executable replacement above.

### Set the daemon home

Use the exact home configured in your Cosmovisor service; this example matches our guides.

```bash
export DAEMON_HOME="$HOME/.dora"
```

### Create the upgrade directory

Prepare the exact directory name required by the approved plan.

```bash
mkdir -p "$DAEMON_HOME/cosmovisor/upgrades/v1.0.0/bin"
```

### Stage the verified executable

Place the previously verified binary in the upgrade directory.

```bash
install -m 0755 "$HOME/dorad-v1.0.0" "$DAEMON_HOME/cosmovisor/upgrades/v1.0.0/bin/dorad"
```

### Verify the staged checksum

Confirm the actual executable Cosmovisor will select.

```bash
echo "5c741ca406ee2ecb811dd62d83e9a446fee051e2947522525c2560a0a7ce968a  $DAEMON_HOME/cosmovisor/upgrades/v1.0.0/bin/dorad" | sha256sum -c -
```

Stage before the approved height and let Cosmovisor switch at the chain's upgrade event. If the switch fails, stop the supervisor and follow the [official recovery procedure](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md); do not delete data or reset signing state.

## Verify recovery

### Read the installed version

For a manual service, expect v1.0.0. For Cosmovisor, inspect its selected current binary too.

```bash
dorad version --long
```

### Check node progress

Confirm the correct chain, increasing height and eventually catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

Validators should verify they resume signing. Compare AppHash with an independent node at the **same height**. Never restart 0.5.0 against migrated v1.0.0 data or restore an old signing-state file after new blocks have been signed.

## v1.0.0 compatibility notes

* The binary is static; no libwasmvm shared library is needed.
* Live Wasm execution and smart queries are removed. Historical raw contract state is exposed through `wasm-archive` where the data is retained.
* Bank transfers, staking and ordinary IBC transfers remain supported; the release does not repair expired IBC clients.
* New accounts can use the full uint64 account-number range. Update wallet/indexer integrations accordingly, and look up a transaction hash before retrying after a client-side decoding error.

[Official v1.0.0 upgrade guide](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md) · [Release and checksums](https://github.com/DoraFactory/doravota/releases/tag/v1.0.0)


# Services

BlockPro endpoints and community connection resources for Dora Mainnet.

**Mainnet · `vota-ash`**

BlockPro public endpoints for Dora Vota Mainnet. Public endpoints are shared infrastructure; use your own node for workloads that require dedicated capacity.

## Public endpoints

| Service  | Provider | Address                                                                           |
| -------- | -------- | --------------------------------------------------------------------------------- |
| RPC      | BlockPro | [https://dora-mainnet-rpc.block-pro.net](https://dora-mainnet-rpc.block-pro.net/) |
| REST API | BlockPro | [https://dora-mainnet-api.block-pro.net](https://dora-mainnet-api.block-pro.net/) |

Use the checks below to confirm the network, application version and synchronization state before relying on an endpoint.

### Check RPC health

Read the chain, height, last block time and synchronization flag.

```bash
curl -fsS https://dora-mainnet-rpc.block-pro.net/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

### Check application version

The application version is different from the CometBFT version shown by RPC.

```bash
curl -fsS https://dora-mainnet-api.block-pro.net/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

## Peers and seeds

The following connection details are published by [ITRocket](https://itrocket.space/services/mainnet/doravota/). They are community services, not BlockPro endpoints.

**Seed**

```bash
4ec0eb59ae35418a9bfa3df3783bad4f372b49c0@doravota-mainnet-seed.itrocket.net:42656
```

**Persistent peer**

```bash
d6edfdb5eae3565a4af1ce35fd2c03084b8c3ef1@doravota-mainnet-peer.itrocket.net:42656
```

Add these to `seeds` and `persistent_peers` in `$HOME/.dora/config/config.toml`. See [Installation](/mainnet/dora/installation) for the exact commands.

## Live peers

Querying net\_info requires the RPC provider to expose that endpoint. Reachability and peer addresses can change.

### Inspect local peers

Read peer IDs and advertised listening addresses from your synchronized node.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.peers[] | [.node_info.id, .node_info.listen_addr, .remote_ip] | @tsv'
```

Use a peer's verified public P2P address. An HTTP RPC hostname, a loopback address or a private advertised address is not automatically a usable P2P endpoint.

## Addrbook

Optional community addrbook: [ITRocket download](https://server-1.itrocket.net/mainnet/doravota/addrbook.json). Use only the file for **vota-ash** and stop the service before replacing your local address book.

### Download a candidate

Save separately so a failed download cannot replace the current file.

```bash
curl -fL https://server-1.itrocket.net/mainnet/doravota/addrbook.json -o "$HOME/addrbook-dora.json"
```

### Validate JSON

Check the downloaded file before using it.

```bash
jq -e . "$HOME/addrbook-dora.json" > /dev/null
```

### Stop the node

Stop the process before replacing the address book.

```bash
sudo systemctl stop dorad
```

### Install the addrbook

Keep a numbered backup when an addrbook already exists.

```bash
cp --backup=numbered "$HOME/addrbook-dora.json" "$HOME/.dora/config/addrbook.json"
```

### Start the node

Restart and check peer connections.

```bash
sudo systemctl start dorad
```

## Snapshots

BlockPro directory: [server-2.block-pro.net/dora](https://server-2.block-pro.net/dora/). The configured publication interval is **every 4 hours**. At review, the directory contained no downloadable archive; use the availability note and alternatives on the snapshot page.

[Snapshot restore guide](/mainnet/dora/snapshots) · [Explorer](https://vota-explorer.dorafactory.org)


# Snapshots

Restore Dora Mainnet data while preserving your validator identity.

**Mainnet · `vota-ash` · v1.0.0**

Restore recent chain data while keeping your own node configuration and validator identity. First install the binary and create the service using [Installation](/mainnet/dora/installation).

## Availability

| Provider | Source                                                                           | Availability at review                                                          |
| -------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| BlockPro | [Snapshot directory](https://server-2.block-pro.net/dora/)                       | Publication interval: every 4 hours. Check the directory for a current archive. |
| ITRocket | [Mainnet snapshots](https://itrocket.space/services/mainnet/doravota/#snapshots) | Current snapshot metadata available.                                            |
| Polkachu | [Mainnet snapshots](https://polkachu.com/tendermint_snapshots/dora)              | A v1.0.0 snapshot was listed at review.                                         |

Use the BlockPro archive once it appears in the directory, or choose a current community snapshot. Do not construct a filename from an example date or height.

Choose a snapshot for **vota-ash**, taken after this network's **v1.0.0 migration**, with a database backend compatible with your node. Do not use the old 0.4.x examples in historical tutorials.

For ITRocket's alternative, the metadata below identifies its current archive.

```bash
curl -fsS https://server-1.itrocket.net/mainnet/doravota/.current_state.json | jq '{file: .snapshot_name, height: .snapshot_height, size: .snapshot_size, block_time: .snapshot_block_time, database: .db_backend}'
```

## Download and inspect

Use the same account and home directory as the node service. Ensure you have room for the compressed archive, extracted data and a copy of your current database. These steps expect a **tar.lz4 archive containing a top-level data directory**. If the provider uses another layout or compression format, adapt to its documented layout before continuing.

Do not restore a snapshot while another node is signing with the same validator key. Keep your latest local signing state; never use a provider's signing state in its place.

### Set the archive URL

Copy the actual current download URL from the selected provider.

```bash
read -rp "Current Dora Mainnet .tar.lz4 URL: " SNAPSHOT_URL
```

### Download the archive

Stop on download errors and do not continue with a partial file.

```bash
curl -fL --retry 3 "$SNAPSHOT_URL" -o "$HOME/dora-snapshot.tar.lz4"
```

### Test compression

Check the LZ4 stream before extraction. If the provider publishes a checksum, compare that too; this test alone does not authenticate a provider.

```bash
lz4 -t "$HOME/dora-snapshot.tar.lz4"
```

### Inspect archive paths

Confirm relative paths under data/. Reject absolute paths, parent-directory traversal and unexpected links. The procedure imports only data, not another operator's config or keys.

```bash
tar -I lz4 -tf "$HOME/dora-snapshot.tar.lz4" | less
```

### Create a staging directory

Extract outside the active node home.

```bash
DORA_RESTORE=$(mktemp -d "$HOME/dora-restore.XXXXXX")
```

### Extract the archive

Run as the node user, without sudo. Do not extract directly over the live home.

```bash
tar -I lz4 -xf "$HOME/dora-snapshot.tar.lz4" -C "$DORA_RESTORE" --no-same-owner --no-same-permissions
```

### Confirm the expected layout

Continue only if data/ exists at the staging root. If it does not, stop and follow the provider's documented archive layout.

```bash
test -d "$DORA_RESTORE/data"
```

## Preserve local identity and state

### Stop the service

Wait until the node has stopped before taking the final signing-state backup.

```bash
sudo systemctl stop dorad
```

### Check that the service is stopped

Expect inactive. Also stop any separate supervisor or manual process using this home.

```bash
sudo systemctl is-active dorad
```

### Create a private backup directory

Keep this shell open so the backup variable remains available.

```bash
DORA_BACKUP="$HOME/dora-backup-$(date +%Y%m%d-%H%M%S)"
```

### Restrict backup access

Create the directory with permissions limited to your user.

```bash
install -d -m 0700 "$DORA_BACKUP"
```

### Back up configuration

Preserve your own genesis, node key and validator key.

```bash
cp -a "$HOME/.dora/config" "$DORA_BACKUP/config"
```

### Back up the latest signing state

This must succeed. If the file is missing on a previously active validator, stop and recover its latest state before proceeding.

```bash
cp -a "$HOME/.dora/data/priv_validator_state.json" "$DORA_BACKUP/priv_validator_state.json"
```

### Preserve the current database

Move rather than delete the old data directory. The service must stay stopped.

```bash
mv "$HOME/.dora/data" "$DORA_BACKUP/data"
```

## Restore and verify

### Install the restored data

Move only the inspected data directory into the node home.

```bash
mv "$DORA_RESTORE/data" "$HOME/.dora/data"
```

### Restore your signing state

Overwrite the snapshot's signing state with your own latest local state before starting.

```bash
cp -a "$DORA_BACKUP/priv_validator_state.json" "$HOME/.dora/data/priv_validator_state.json"
```

Your config directory stays in place. Preserve any existing external `wasm/` bytecode for historical research; v1.0.0 no longer runs the Wasm runtime, so this guide does not replace that directory from a provider archive.

### Check snapshot settings

Keep statesync enable=false in config.toml when restoring an archive, and confirm the database backend matches the provider metadata. Do not change unrelated enable fields.

```bash
nano "$HOME/.dora/config/config.toml" "$HOME/.dora/config/app.toml"
```

### Start the service

Start only after successful restoration and ownership checks. The files should belong to the service account.

```bash
sudo systemctl start dorad
```

### Read startup logs

Check for database, version or network errors.

```bash
sudo journalctl -u dorad -n 100 --no-pager -o cat
```

### Check synchronization

Confirm chain vota-ash, a current block time and catching\_up=false after catch-up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

Compare the height and block hash at the same height with an independent [public RPC](/mainnet/dora/services). Keep backups until recovery is verified. Do not restore an older signing-state file after this node has signed new blocks.

[Official v1.0.0 state-preservation notes](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md)


# Useful Commands

Everyday Dora Mainnet service, wallet and validator commands.

**Mainnet · `vota-ash` · dorad**

Commands match the [Installation](/mainnet/dora/installation) guide: service `dorad`, home `$HOME/.dora`, key `wallet` and local RPC `http://127.0.0.1:26657`. Replace uppercase placeholders before running a command.

Amounts use `peaka`: **1 DORA = 1000000000000000000 peaka**. Transaction commands estimate gas and ask for confirmation.

## Service operations

### Start the node

Start the systemd service.

```bash
sudo systemctl start dorad
```

### Stop the node

Stop the service cleanly.

```bash
sudo systemctl stop dorad
```

### Restart the node

Restart after an approved configuration change.

```bash
sudo systemctl restart dorad
```

### Service status

Show whether the node is active.

```bash
sudo systemctl status dorad --no-pager -l
```

### Follow logs

Stream logs. Ctrl+C exits the view.

```bash
sudo journalctl -u dorad -f -o cat
```

### Check version

Read the installed application release and commit.

```bash
dorad version --long
```

### Check synchronization

Verify network, latest block and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

### Count connected peers

Show the local P2P peer count.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r .result.n_peers
```

### Show node ID

Read your public P2P identity.

```bash
dorad comet show-node-id --home "$HOME/.dora"
```

## Key management

Store wallet recovery words privately. Use the restore command only for a wallet you own, and enter the phrase interactively.

### Create a wallet

Create the encrypted wallet key.

```bash
dorad keys add wallet --keyring-backend file --home "$HOME/.dora"
```

### Restore a wallet

Recover an existing key from its mnemonic.

```bash
dorad keys add wallet --recover --keyring-backend file --home "$HOME/.dora"
```

### List keys

List locally stored public key information.

```bash
dorad keys list --keyring-backend file --home "$HOME/.dora"
```

### Show account address

Read the address used for balances and transfers.

```bash
dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora"
```

### Show validator address

Read the operator address used for staking queries.

```bash
dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora"
```

## Tokens

### Check balance

Query token balances in base units.

```bash
dorad query bank balances "$(dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

### Send tokens

Replace RECIPIENT and AMOUNTpeaka. Verify the recipient and amount before confirming.

```bash
dorad tx bank send wallet RECIPIENT AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Delegate

Replace VALIDATOR\_ADDRESS with a valoper address and set the amount.

```bash
dorad tx staking delegate VALIDATOR_ADDRESS AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Withdraw rewards

Withdraw delegation rewards from the selected validator.

```bash
dorad tx distribution withdraw-rewards VALIDATOR_ADDRESS --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Redelegate

Move a delegation between validators, subject to network redelegation rules.

```bash
dorad tx staking redelegate SOURCE_VALIDATOR DESTINATION_VALIDATOR AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Unbond tokens

Begin the unbonding period; tokens are not immediately spendable.

```bash
dorad tx staking unbond VALIDATOR_ADDRESS AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Check a transaction

Wait for inclusion, then inspect the result before repeating a transfer.

```bash
dorad query tx TX_HASH --node http://127.0.0.1:26657 --output json
```

## Validator operations

Use [Validator](/mainnet/dora/validator) for initial registration. Investigate the reason for jailing before attempting to unjail.

### Validator status

Read staking status and jailed state.

```bash
dorad query staking validator "$(dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

### Consensus public key

Read the public key; do not expose priv\_validator\_key.json.

```bash
dorad comet show-validator --home "$HOME/.dora"
```

### Signing information

List slashing/signing records and find your consensus address.

```bash
dorad query slashing signing-infos --node http://127.0.0.1:26657 --output json
```

### Withdraw commission and rewards

Withdraw for your own validator operator address.

```bash
dorad tx distribution withdraw-rewards "$(dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora")" --commission --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Edit validator details

Replace the example display name; change only the fields you intend.

```bash
dorad tx staking edit-validator --new-moniker "YOUR_MONIKER" --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Unjail

Run only after fixing downtime and meeting the chain's unjailing conditions. Tombstoned validators cannot be unjailed.

```bash
dorad tx slashing unjail --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-ash --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Check staking parameters

Read validator limits, denomination and the unbonding time.

```bash
dorad query staking params --node http://127.0.0.1:26657 --output json
```

### Check the upgrade plan

Read a scheduled plan before changing the binary.

```bash
dorad query upgrade plan --node http://127.0.0.1:26657 --output json
```

[Upgrade guide](/mainnet/dora/upgrade) · [Official repository](https://github.com/DoraFactory/doravota)


# Lava

Lava Mainnet: node guides, services and operations.

**Mainnet · `lava-mainnet-1` · lavad**

Run the Lava consensus node and, optionally, register a validator. RPC-provider operations use a different workflow.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Installation</strong></td><td>Prepare the server and start syncing.</td><td><a href="/mainnet/lava/installation">Installation</a></td></tr><tr><td><strong>Validator</strong></td><td>Create a wallet and register your validator.</td><td><a href="/mainnet/lava/validator">Validator</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Replace the binary and verify recovery.</td><td><a href="/mainnet/lava/upgrade">Upgrade</a></td></tr><tr><td><strong>Services</strong></td><td>BlockPro endpoints and connection files.</td><td><a href="/mainnet/lava/services">Services</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Restore recent chain data step by step.</td><td><a href="/mainnet/lava/snapshots">Snapshots</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, keys, tokens and validator operations.</td><td><a href="/mainnet/lava/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Requirements

| Resource | Minimum            | Recommended          |
| -------- | ------------------ | -------------------- |
| CPU      | 4 vCPU, x64, 2 GHz | 4+ vCPU              |
| RAM      | 8 GB               | 16 GB+               |
| Storage  | 100 GB SSD         | 512 GB SSD or larger |
| OS       | Ubuntu 20+         | Ubuntu 24.04 LTS     |

The official storage figures are starting points. Check the current snapshot size and keep room for extraction and chain growth. [Hardware source](https://docs.lavanet.xyz/reqs/).

Allow inbound P2P on TCP `26656`. Keep RPC `26657`, REST `1317` and gRPC `9090` private unless you are deliberately operating a protected public service. Use a separate server for each network.

## Versions

Reference release: [`v6.2.5`](https://github.com/lavanet/lava/releases/tag/v6.2.5). GitHub also lists newer prereleases; they are not a mainnet upgrade instruction. Lava’s installation tutorial still uses v5.2.0, so confirm the active chain version and any scheduled upgrade before choosing a binary.

Read the version reported by the network before installation or upgrade; this response is live and is not cached in this guide.

```bash
curl -fsS https://lava-api.block-pro.net/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

If the endpoint is unavailable, confirm the active release with the project’s official validator announcements. Do not guess from the highest GitHub tag.

[Official documentation](https://docs.lavanet.xyz/mainnet-manual-cosmovisor/) · [Source code](https://github.com/lavanet/lava)


# Installation

Install and synchronize Lava Mainnet, one command at a time.

**Mainnet · `lava-mainnet-1` · Ubuntu 24.04 / x86-64**

Use a normal Linux account with sudo access. Commands assume a new node and the same shell session. Existing operators should use [Upgrade](/mainnet/lava/upgrade).

### 1. Prepare packages

Refresh package metadata.

```bash
sudo apt update
```

### Install dependencies

Install download, build and snapshot tools.

```bash
sudo apt install -y ca-certificates curl jq git make build-essential golang-go lz4 tar
```

## Install the binary

### Select a release

Use the network-approved release. This pinned stable release is the reference, not an automatic upgrade decision.

```bash
LAVA_VERSION=v6.2.5
```

### Download lavad

Download the Linux amd64 release asset.

```bash
curl -fL "https://github.com/lavanet/lava/releases/download/$LAVA_VERSION/lavad-$LAVA_VERSION-linux-amd64" -o "$HOME/lavad.download"
```

### Check the download

For v6.2.5, this must print OK. A different release needs its own published checksum.

```bash
printf "%s  %s\n" e500f73102264a48818ab5ecc1350bf54d663d6d3a4bfb45d9a85833d2b1fded "$HOME/lavad.download" | sha256sum -c -
```

### Install

Place the verified executable in the system path.

```bash
sudo install -m 0755 "$HOME/lavad.download" /usr/local/bin/lavad
```

### Verify the binary

Confirm the selected version starts successfully.

```bash
lavad version --long
```

## Initialize and connect

### Initialize once

Replace MY\_NODE with your own moniker. Do not rerun this over an existing validator home.

```bash
lavad init "MY_NODE" --chain-id lava-mainnet-1
```

### Download genesis

Save network genesis to the node configuration.

```bash
curl -fL https://raw.githubusercontent.com/Shoni-O/files/main/mainnet-files/lava/genesis.json -o "$HOME/.lava/config/genesis.json"
```

### Verify the network

Continue only if the file is valid JSON and this check returns true.

```bash
jq -e '.chain_id == "lava-mainnet-1"' "$HOME/.lava/config/genesis.json"
```

### Download the address book

Load BlockPro’s published peer discovery file.

```bash
curl -fL https://raw.githubusercontent.com/Shoni-O/files/main/mainnet-files/lava/addrbook.json -o "$HOME/.lava/config/addrbook.json"
```

### Check the address book

Ensure the download contains peer records, not an HTML error page.

```bash
jq -e '.addrs | type == "array"' "$HOME/.lava/config/addrbook.json"
```

### Set minimum gas prices

Set this node’s local transaction admission policy.

```bash
sed -i 's/^minimum-gas-prices *=.*/minimum-gas-prices = "0.000000001ulava"/' "$HOME/.lava/config/app.toml"
```

### Set a persistent peer

Use the BlockPro peer published for this network.

```bash
sed -i 's|^persistent_peers *=.*|persistent_peers = "290d562781dd46eaa66eb88f87b60e888550ae44@lava-rpc.block-pro.net:61356"|' "$HOME/.lava/config/config.toml"
```

### Use bounded pruning

Keep the application’s standard pruning policy; archive operation needs more disk space.

```bash
sed -i 's/^pruning *=.*/pruning = "default"/' "$HOME/.lava/config/app.toml"
```

### Apply Lava consensus timing

Apply the timings from the official joining guide.

```bash
sed -i -e 's/^timeout_commit *=.*/timeout_commit = "30s"/' -e 's/^timeout_propose *=.*/timeout_propose = "1s"/' -e 's/^timeout_precommit *=.*/timeout_precommit = "1s"/' -e 's/^timeout_prevote *=.*/timeout_prevote = "1s"/' -e 's/^timeout_propose_delta *=.*/timeout_propose_delta = "500ms"/' -e 's/^timeout_precommit_delta *=.*/timeout_precommit_delta = "500ms"/' -e 's/^timeout_prevote_delta *=.*/timeout_prevote_delta = "500ms"/' -e 's/^skip_timeout_commit *=.*/skip_timeout_commit = false/' "$HOME/.lava/config/config.toml"
```

## Run with systemd

### Create the service

Run the node as the current non-root account, with automatic restart after a process failure.

```bash
sudo tee /etc/systemd/system/lavad.service > /dev/null <<EOF
[Unit]
Description=Lava Mainnet node
After=network-online.target
Wants=network-online.target

[Service]
User=$(id -un)
WorkingDirectory=$HOME/.lava
ExecStart=/usr/local/bin/lavad start --home $HOME/.lava
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF
```

### Load the unit

Tell systemd about the new service.

```bash
sudo systemctl daemon-reload
```

### Enable on boot

Enable the service without starting it yet.

```bash
sudo systemctl enable lavad
```

### Restore recent state

Follow [Snapshots](/mainnet/lava/snapshots) before starting. The current binary may not replay every historical upgrade from genesis. Choose a snapshot compatible with the installed release.

### Start

Start the node after restoration.

```bash
sudo systemctl start lavad
```

### Follow logs

Look for advancing blocks; Ctrl+C leaves the service running.

```bash
sudo journalctl -u lavad -f -o cat
```

### Check synchronization

Wait for catching\_up to become false and compare the height with the explorer.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

Next: [Validator](/mainnet/lava/validator) or [Useful Commands](/mainnet/lava/useful-commands).

[Upstream reference](https://docs.lavanet.xyz/mainnet-manual-cosmovisor/).


# Validator

Create and maintain a Lava validator on Mainnet.

**Mainnet · `lava-mainnet-1`**

Complete [Installation](/mainnet/lava/installation) and wait for full synchronization. The wallet key authorizes transactions; the consensus key signs blocks. Back up both securely, and never run two nodes with the same consensus key.

### Create a wallet

Save the recovery phrase offline. Use the recovery command instead if you already have a wallet.

```bash
lavad keys add wallet
```

### Recover an existing wallet — alternative

Enter the recovery phrase interactively.

```bash
lavad keys add wallet --recover
```

### Show the funding address

Fund this address on the correct network and leave a balance for fees.

```bash
lavad keys show wallet -a
```

### Check balance

Read the funded account balance.

```bash
lavad query bank balances "$(lavad keys show wallet -a)"
```

### Check synchronization

Continue only after catching\_up is false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info.catching_up'
```

### Back up the consensus key

Create a local protected backup, then copy it to secure offline storage.

```bash
install -D -m 0600 "$HOME/.lava/config/priv_validator_key.json" "$HOME/validator-backup/lava-mainnet-priv_validator_key.json"
```

### Check create-validator syntax

Inspect the release’s CLI before submitting. The formats below differ between older and newer Cosmos SDK releases.

```bash
lavad tx staking create-validator --help
```

### Register the validator

Choose the format shown by your binary’s help. Replace the moniker and amount, then review the transaction before confirming. The sample stake is not a promise of entry into the active set.

```bash
lavad tx staking create-validator \
  --amount 50000000ulava \
  --pubkey "$(lavad tendermint show-validator)" \
  --moniker "MY_VALIDATOR" \
  --commission-rate 0.10 --commission-max-rate 0.20 \
  --commission-max-change-rate 0.01 --min-self-delegation 10000 \
  --from wallet --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

### Verify registration

Query the validator record after the transaction is included in a block.

```bash
lavad query staking validator "$(lavad keys show wallet --bech val -a)"
```

Registration and active voting power are different states. Check bonded status and the active-set threshold in the explorer.

[Validator reference](https://docs.lavanet.xyz/validator-manual/).


# Upgrade

Upgrade Lava safely and confirm the node resumes syncing.

**Mainnet · `lava-mainnet-1`**

This procedure uses the direct `lavad.service` created by our installation guide. If your service uses Cosmovisor, stage the binary under the exact on-chain upgrade plan name instead of replacing its symlink.

{% hint style="warning" %}
For a scheduled chain upgrade, prepare the binary in advance and switch only at the announced height. For a compatible patch, follow the project’s release instructions. Do not skip database migrations or start an old binary against upgraded state.
{% endhint %}

### Check the service

Confirm its executable and home before changing anything.

```bash
systemctl cat lavad
```

### Check the upgrade plan

Read any scheduled on-chain upgrade.

```bash
lavad query upgrade plan -o json
```

### Prepare the new binary

Use the binary download/build steps in [Installation](/mainnet/lava/installation), but stage the result as `$HOME/lavad.next` and do not install it over the running executable yet. Select the release announced for `lava-mainnet-1`.

### Select the approved target

v6.2.5 is the reviewed stable reference; change it only to the release authorized for your network.

```bash
LAVA_VERSION=v6.2.5
```

### Download to a staging path

This leaves the current service binary intact.

```bash
curl -fL "https://github.com/lavanet/lava/releases/download/$LAVA_VERSION/lavad-$LAVA_VERSION-linux-amd64" -o "$HOME/lavad.next"
```

### Verify v6.2.5

Use the checksum belonging to the chosen release.

```bash
printf "%s  %s\n" e500f73102264a48818ab5ecc1350bf54d663d6d3a4bfb45d9a85833d2b1fded "$HOME/lavad.next" | sha256sum -c -
```

### Make executable

Allow checking the staged binary.

```bash
chmod 0755 "$HOME/lavad.next"
```

### Check the staged version

Resolve missing libraries or a wrong release before downtime.

```bash
"$HOME/lavad.next" version --long
```

### Stop at the correct time

Stop the one active signer before switching binaries.

```bash
sudo systemctl stop lavad
```

### Back up configuration and signing state

Keep the signing state from this stopped node. Store a full stopped database backup as well if the release requires one.

```bash
tar -czf "$HOME/lava-mainnet-upgrade-$(date +%Y%m%d-%H%M%S).tar.gz" -C "$HOME/.lava" config data/priv_validator_state.json
```

### Keep the previous binary

Retain a copy for diagnostics; database migrations may prevent a simple binary rollback.

```bash
cp /usr/local/bin/lavad "$HOME/lavad.previous"
```

### Replace the binary

Install the staged executable.

```bash
sudo install -m 0755 "$HOME/lavad.next" /usr/local/bin/lavad
```

### Start

Start the node with the upgraded binary.

```bash
sudo systemctl start lavad
```

### Inspect logs

Check for migration errors and advancing heights.

```bash
sudo journalctl -u lavad -n 100 -f -o cat
```

### Confirm sync

Check height and catching\_up after the node recovers.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

[Release history](https://github.com/lavanet/lava/releases).


# Services

BlockPro endpoints and peer discovery for Lava Mainnet.

**Mainnet · `lava-mainnet-1`**

## Public endpoints

| Service  | Address                                                |
| -------- | ------------------------------------------------------ |
| RPC      | <https://lava-rpc.block-pro.net>                       |
| REST API | <https://lava-api.block-pro.net>                       |
| Explorer | [Mainnet explorer](https://mainnet.block-pro.net/lava) |

These addresses are carried over from BlockPro’s existing service directory. Availability is not a live status indicator.

## Persistent peer

```
290d562781dd46eaa66eb88f87b60e888550ae44@lava-rpc.block-pro.net:61356
```

## Connection files

| File         | Download                                                                                               |
| ------------ | ------------------------------------------------------------------------------------------------------ |
| Genesis      | [genesis.json](https://raw.githubusercontent.com/Shoni-O/files/main/mainnet-files/lava/genesis.json)   |
| Address book | [addrbook.json](https://raw.githubusercontent.com/Shoni-O/files/main/mainnet-files/lava/addrbook.json) |

### Inspect the live RPC

Check the network ID, peer identity and sync status.

```bash
curl -fsS https://lava-rpc.block-pro.net/status | jq '.result | {node_info, sync_info}'
```

### Live peers

List peers reported by the public RPC, if net\_info is enabled. Verify reachability before using an address.

```bash
curl -fsS https://lava-rpc.block-pro.net/net_info | jq -r '.result.peers[]? | "\(.node_info.id)@\(.remote_ip):\(.node_info.listen_addr | split(":") | last)"'
```

Snapshot download and restore instructions: [Snapshots](/mainnet/lava/snapshots).


# Snapshots

Restore Lava Mainnet chain data without losing your validator identity.

**Mainnet · `lava-mainnet-1` · `.lava`**

Provider: BlockPro. This URL comes from the existing service directory; inspect the archive before restoring. No unverified update frequency or height is advertised.

[Download snapshot](https://m-lava-snapshot.block-pro.net/lavadata.tar.lz4). Allow space for the compressed file, extracted data and the previous database.

{% hint style="warning" %}
This procedure replaces chain data. Keep config, keyring and validator keys. For an existing validator, preserve its latest priv\_validator\_state.json while stopped; never restore another validator’s signing state. Do not start a second signer during recovery.
{% endhint %}

### Download first

Download before stopping the node to reduce downtime.

```bash
curl -fL --retry 3 https://m-lava-snapshot.block-pro.net/lavadata.tar.lz4 -o "$HOME/lava-snapshot.tar.lz4"
```

### Test compression

Stop if the compressed archive is corrupt.

```bash
lz4 -t "$HOME/lava-snapshot.tar.lz4"
```

### Inspect paths

Check that entries are chain data, with no absolute paths or .. components. Choose strip-components based on the actual archive layout.

```bash
tar -I lz4 -tf "$HOME/lava-snapshot.tar.lz4" | head -40
```

### Stop

Stop the service before changing its data.

```bash
sudo systemctl stop lavad
```

### Back up signing state

Keep the latest state from your own stopped node.

```bash
cp -p "$HOME/.lava/data/priv_validator_state.json" "$HOME/.lava/priv_validator_state.json.before-snapshot"
```

### Keep the previous database

Rename the data directory. Use a fresh backup name if this path already exists.

```bash
mv "$HOME/.lava/data" "$HOME/.lava/data.before-snapshot"
```

### Extract chain data

The previous BlockPro archive layout uses two leading directories before data/. Use this command only if the path listing confirms it.

```bash
tar -I lz4 -xf "$HOME/lava-snapshot.tar.lz4" -C "$HOME/.lava" --strip-components=2
```

### Restore your signing state

Overwrite the snapshot’s signing state with your own backup.

```bash
cp -p "$HOME/.lava/priv_validator_state.json.before-snapshot" "$HOME/.lava/data/priv_validator_state.json"
```

### Start

Start only after the data directory layout is correct.

```bash
sudo systemctl start lavad
```

### Verify recovery

Compare height and time with the explorer; wait for catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

Keep the previous database until the restored node is healthy. A snapshot is trusted input; a locally calculated checksum alone does not authenticate its provider.


# Useful Commands

Everyday Lava service, wallet and validator commands.

**Mainnet · `lava-mainnet-1`**

Commands use the `wallet` key name. Transaction examples ask for confirmation. Replace quoted address placeholders and review amounts before signing. `1 LAVA = 1,000,000 ulava`.

## Service operations

### Status

Check the systemd unit.

```bash
sudo systemctl status lavad --no-pager
```

### Logs

Follow recent logs.

```bash
sudo journalctl -u lavad -f -o cat
```

### Restart

Restart the node process.

```bash
sudo systemctl restart lavad
```

### Stop

Stop the node.

```bash
sudo systemctl stop lavad
```

### Start

Start the node.

```bash
sudo systemctl start lavad
```

### Sync status

Check height and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

### Version

Show the installed binary version.

```bash
lavad version --long
```

## Key management

### Create

Create a wallet and securely store its recovery phrase.

```bash
lavad keys add wallet
```

### Recover

Import a wallet interactively.

```bash
lavad keys add wallet --recover
```

### List

List local keys.

```bash
lavad keys list
```

### Address

Show the account address.

```bash
lavad keys show wallet -a
```

### Balance

Query token balances.

```bash
lavad query bank balances "$(lavad keys show wallet -a)"
```

## Tokens

### Send

Send 1 token to the chosen recipient.

```bash
lavad tx bank send wallet "RECIPIENT_ADDRESS" 1000000ulava --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

### Delegate

Delegate 1 token to a validator.

```bash
lavad tx staking delegate "VALIDATOR_ADDRESS" 1000000ulava --from wallet --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

### Withdraw rewards

Withdraw delegation rewards.

```bash
lavad tx distribution withdraw-all-rewards --from wallet --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

## Validator operations

### Details

Query your validator record.

```bash
lavad query staking validator "$(lavad keys show wallet --bech val -a)"
```

### Commission and rewards

Withdraw rewards and validator commission.

```bash
lavad tx distribution withdraw-rewards "$(lavad keys show wallet --bech val -a)" --commission --from wallet --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

### Unjail

Use only after correcting the cause of jailing and meeting unjail conditions.

```bash
lavad tx slashing unjail --from wallet --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

## Governance

### Proposals

List governance proposals.

```bash
lavad query gov proposals
```

### Vote

Replace 123 with the proposal you have reviewed.

```bash
lavad tx gov vote 123 yes --from wallet --chain-id lava-mainnet-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```


# Monad

Monad Mainnet node installation, upgrades and operations.

**Mainnet · Chain ID `143` · MON**

Run a Monad full node, then add validator registration if you plan to participate in consensus.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Full Node</strong></td><td>Prepare the machine and run Monad.</td><td><a href="/mainnet/monad/full-node">Full Node</a></td></tr><tr><td><strong>Validator</strong></td><td>Register the node and configure rewards.</td><td><a href="/mainnet/monad/validator">Validator</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Update the package and check storage migration.</td><td><a href="/mainnet/monad/upgrade">Upgrade</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Bootstrap or recover from a current snapshot.</td><td><a href="/mainnet/monad/snapshots">Snapshots</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service control, RPC checks and disk monitoring.</td><td><a href="/mainnet/monad/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Requirements

| Resource            | Official requirement                                      |
| ------------------- | --------------------------------------------------------- |
| Server              | Bare metal; cloud VMs are not officially supported        |
| CPU                 | 16 cores, 4.5 GHz+ base clock; disable SMT/HyperThreading |
| RAM                 | 32 GB+                                                    |
| TrieDB disk         | Dedicated 2 TB PCIe 4.0 x4 NVMe or better                 |
| OS / consensus disk | Separate 500 GB PCIe 4.0 x4 NVMe or better                |
| Bandwidth           | 100 Mbit/s full node; 300 Mbit/s validator                |
| OS                  | Ubuntu 24.04 or newer                                     |

[Hardware source](https://docs.monad.xyz/node-ops/hardware-requirements). The TrieDB disk is a raw database device; do not use the disk containing your operating system.

## Versions and services

The documented release is [`0.16.4`](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.4). Release availability does not replace the network deployment announcement. Pin the approved version and keep the APT package on hold.

| Component        | Service                  |
| ---------------- | ------------------------ |
| Consensus        | `monad-bft`              |
| Execution        | `monad-execution`        |
| JSON-RPC         | `monad-rpc`, port `8080` |
| Artifact cleanup | `monad-cruft.timer`      |

This guide uses official mainnet configuration and snapshot providers. No BlockPro Monad RPC or snapshot address has been supplied in the existing directory.

[Official node operations](https://docs.monad.xyz/node-ops) · [Network information](https://docs.monad.xyz/developer-essentials/network-information).


# Full Node

Install a Monad Mainnet full node on a dedicated server.

**Mainnet · Chain ID `143` · Ubuntu 24.04 / bare metal**

Use a fresh machine meeting the [requirements](/mainnet/monad). These commands run in a root shell. Set up SSH access and identify your dedicated TrieDB disk before continuing.

## Prepare the machine

### Open a root shell

Use administrator access for package, service and raw-device setup.

```bash
sudo -i
```

### Refresh packages

Refresh the package index.

```bash
apt update
```

### Install utilities

Install disk, download and configuration tools.

```bash
apt install -y ca-certificates curl gnupg nvme-cli parted aria2 jq openssl nano ufw
```

### Create the signing-key directory

Prepare APT’s keyring location.

```bash
install -m 0755 -d /etc/apt/keyrings
```

### Import the package key

Trust packages signed by the official Category Labs repository.

```bash
curl -fsSL https://pkg.category.xyz/keys/public-key.asc | gpg --dearmor --yes -o /etc/apt/keyrings/category-labs.gpg
```

### Configure the repository

Add the Ubuntu Noble package source.

```bash
cat > /etc/apt/sources.list.d/category-labs.sources <<EOF
Types: deb
URIs: https://pkg.category.xyz/
Suites: noble
Components: main
Signed-By: /etc/apt/keyrings/category-labs.gpg
EOF
```

### Refresh package versions

Load the available Monad package versions.

```bash
apt update
```

### Inspect available versions

Check that the release announced for Mainnet is available.

```bash
apt-cache madison monad
```

### Install the approved release

0.16.4 is the reviewed reference. Follow the Mainnet deployment announcement when choosing a version.

```bash
apt install monad=0.16.4
```

### Hold the package

Prevent unattended system upgrades from changing the consensus version.

```bash
apt-mark hold monad
```

### Create the service user

Skip only if the monad account already exists.

```bash
useradd -m -s /bin/bash monad
```

### Create node directories

Prepare configuration, ledger and runtime metadata paths.

```bash
mkdir -p /home/monad/monad-bft/config/forkpoint /home/monad/monad-bft/config/validators /home/monad/monad-bft/ledger
```

## Prepare the TrieDB disk

{% hint style="warning" %}
The following formatting steps erase the selected disk. Choose an unused dedicated NVMe device, with no mounted partitions, swap, LVM or RAID. Never select the OS disk. These steps are for initial setup, not upgrades.
{% endhint %}

### List NVMe devices

Identify the model and capacity of the dedicated disk.

```bash
nvme list
```

### Inspect mounts and filesystems

Check every partition and confirm the target disk is unused.

```bash
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL
```

### Choose the disk

Enter its exact path after inspection; no disk is selected by default.

```bash
read -rp "Unused dedicated TrieDB disk path: " TRIEDB_DRIVE
```

### Inspect LBA formats

Identify a 512-byte LBA format and its index.

```bash
nvme id-ns -H "$TRIEDB_DRIVE"
```

If 512-byte sectors are not active, select the index shown for the 512-byte format. Formatting destroys this disk’s contents.

### Select the format index — only if needed

Use the index reported by your device. Do not assume index 0 on every disk.

```bash
read -rp "512-byte LBA format index: " LBA_INDEX
```

### Apply 512-byte format — only if needed

Format the verified unused device.

```bash
nvme format --lbaf="$LBA_INDEX" "$TRIEDB_DRIVE"
```

### Create the partition table

Create a fresh GPT on the selected empty disk.

```bash
parted "$TRIEDB_DRIVE" mklabel gpt
```

### Create the TrieDB partition

Allocate the disk to one raw database partition.

```bash
parted "$TRIEDB_DRIVE" mkpart triedb 0% 100%
```

### Read the partition UUID

Use the only partition created above.

```bash
PARTUUID=$(lsblk -nr -o PARTUUID "$TRIEDB_DRIVE" | awk 'NF {print; exit}')
```

### Create a stable device name

Allow only root and the monad group to access the raw partition.

```bash
printf 'ENV{ID_PART_ENTRY_UUID}=="%s", GROUP="monad", MODE="0660", SYMLINK+="triedb"\n' "$PARTUUID" > /etc/udev/rules.d/99-triedb.rules
```

### Reload device rules

Load the new rule.

```bash
udevadm control --reload-rules
```

### Apply the rule

Apply permissions and the triedb symlink.

```bash
udevadm trigger
```

### Wait for device setup

Wait for udev to finish.

```bash
udevadm settle
```

### Verify the target

Confirm /dev/triedb points to the dedicated partition.

```bash
ls -l /dev/triedb
```

### Initialize TrieDB

Run the package’s one-time database initializer.

```bash
systemctl start monad-mpt
```

### Check initialization

Confirm the initializer completed successfully.

```bash
journalctl -u monad-mpt -n 30 --no-pager -o cat
```

## Configure Mainnet

### Download the environment template

Use the mainnet configuration supplied by Monad Foundation.

```bash
curl -fL https://bucket.monadinfra.com/config/mainnet/latest/.env.example -o /home/monad/.env
```

### Download the full-node template

Use the public full-node network configuration.

```bash
curl -fL https://bucket.monadinfra.com/config/mainnet/latest/full-node-node.toml -o /home/monad/monad-bft/config/node.toml
```

### Protect the environment

Restrict the file before adding the keystore password.

```bash
chmod 0600 /home/monad/.env
```

### Set the password

On this fresh setup, generate the password when the template contains an empty KEYSTORE\_PASSWORD entry.

```bash
sed -i "s|^KEYSTORE_PASSWORD=$|KEYSTORE_PASSWORD='$(openssl rand -base64 32)'|" /home/monad/.env
```

### Load service variables

Load the template after reviewing it.

```bash
source /home/monad/.env
```

### Confirm a password is set

Continue only if this command succeeds.

```bash
test -n "$KEYSTORE_PASSWORD"
```

### Prepare private backups

Create a restricted backup location.

```bash
install -m 0700 -d /opt/monad/backup
```

### Restrict new private files

Keep newly generated backup files private.

```bash
umask 077
```

### Create the SECP identity

Run only on a new node with no existing id-secp file.

```bash
monad-keystore create --key-type secp --keystore-path /home/monad/monad-bft/config/id-secp --password "$KEYSTORE_PASSWORD" > /opt/monad/backup/secp-backup
```

### Create the BLS identity

Run only on a new node with no existing id-bls file.

```bash
monad-keystore create --key-type bls --keystore-path /home/monad/monad-bft/config/id-bls --password "$KEYSTORE_PASSWORD" > /opt/monad/backup/bls-backup
```

Securely back up both keystores, their password and the recovery files outside the node. Do not post recovery-file contents.

### Edit node settings

Set a unique node\_name. For a full node, beneficiary may be the zero address. Keep enable\_client=true under fullnode\_raptorcast, expand\_to\_group=true under statesync, and the public full-node blocksync\_override list empty.

```bash
nano /home/monad/monad-bft/config/node.toml
```

### Inspect name-record options

Use the flags supported by the installed release.

```bash
monad-sign-name-record --help
```

### Set the public IP

Enter the routable address assigned to this server.

```bash
read -rp "Node public IPv4: " NODE_PUBLIC_IP
```

### Sign the discovery record

This is the Mainnet command from the official installation guide. Match its port flags to your approved release.

```bash
monad-sign-name-record --ip "$NODE_PUBLIC_IP" --tcp-port 8000 --udp-port 8000 \
  --authenticated-udp-port 8001 --keystore-path /home/monad/monad-bft/config/id-secp \
  --password "$KEYSTORE_PASSWORD" --self-record-seq-num 1
```

Copy the generated signature and sequence number into `[peer_discovery]` in `node.toml`. Use the field layout of the downloaded release template: older Mainnet templates combine IP and TCP port in `self_address`; newer templates expose separate address and port fields. Do not paste an example signature. If your version replaces `--udp-port` with `--direct-udp-port`, follow the installed help and matching release instructions.

### Check remote metadata URLs

Confirm both variables use /mainnet/, then save any missing values in .env.

```bash
nano /home/monad/.env
```

```ini
REMOTE_VALIDATORS_URL='https://bucket.monadinfra.com/validators/mainnet/validators.toml'
REMOTE_FORKPOINT_URL='https://bucket.monadinfra.com/forkpoint/mainnet/forkpoint.toml'
```

## Network access

Preserve your actual SSH port before enabling a firewall. Allow the consensus ports required by the selected template; keep RPC 8080 and metrics private.

### Allow SSH

Use this on hosts using standard SSH port 22; adapt it before proceeding if yours differs.

```bash
ufw allow 22/tcp
```

### Allow consensus traffic

Permit the ports used by the official node template.

```bash
ufw allow 8000:8002
```

### Enable the firewall

Review the rules and apply the firewall.

```bash
ufw enable
```

The upstream guide also recommends a UDP anti-spam rule on port 8000. Confirm your release’s networking requirements and persist the rule with your firewall tooling. See the [official networking section](https://docs.monad.xyz/node-ops/full-node-installation#configure-firewall-rules).

## Bootstrap and start

### Set file ownership

Give the service account access to its configuration and data.

```bash
chown -R monad:monad /home/monad
```

### Enable services

Enable startup on boot.

```bash
systemctl enable monad-bft monad-execution monad-rpc
```

Follow [Snapshots](/mainnet/monad/snapshots) to import current Mainnet state before starting. The recovery procedure handles the active TrieDB storage format.

### Start the node

Start consensus, execution and RPC after restoration.

```bash
systemctl start monad-bft monad-execution monad-rpc
```

### Check services

All three should be active.

```bash
systemctl status monad-bft monad-execution monad-rpc --no-pager -l
```

### Verify Mainnet

After statesync, RPC should return 0x8f (143).

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' | jq
```

### Verify progress

Repeat to confirm the block number advances.

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | jq
```

### Check cleanup

The package’s cleanup timer prevents old artifacts from accumulating.

```bash
systemctl status monad-cruft.timer --no-pager
```

Configure release-appropriate monitoring using the [metrics migration guide](https://docs.monad.xyz/node-ops/upgrade-instructions/prometheus-metrics-migration).

[Installation source](https://docs.monad.xyz/node-ops/full-node-installation).


# Snapshots

Bootstrap or recover Monad Mainnet state with the official snapshot procedure.

**Mainnet · state recovery**

Use this after fresh installation or when an explicit recovery requires rebuilding state. A hard reset replaces runtime chain data. It is not a routine upgrade step.

The upstream restoration utility selects the correct snapshot and TrieDB timeline format. This page keeps preparation, inspection, restoration and verification as separate commands.

{% hint style="warning" %}
Run in a root shell. Check /dev/triedb and back up node identities, the keystore password and configuration before resetting. Keep any needed history elsewhere; a recent snapshot does not restore an archive node’s full history.
{% endhint %}

### Verify the device

Confirm the raw database points to the intended partition.

```bash
ls -l /dev/triedb
```

### Back up configuration

Create a restricted backup directory.

```bash
install -m 0700 -d /opt/monad/backup
```

### Save identity and configuration

Keep the environment and config together. This archive contains secrets.

```bash
tar -czf "/opt/monad/backup/config-$(date +%Y%m%d-%H%M%S).tar.gz" -C /home/monad .env monad-bft/config
```

### Restrict backup permissions

Ensure only root can read the backup files.

```bash
chmod -R go-rwx /opt/monad/backup
```

### Stop the services

Stop database access before restoration.

```bash
systemctl stop monad-bft monad-execution monad-rpc
```

### Inspect the packaged reset utility

Review the installed utility and paths before it changes runtime data.

```bash
less /opt/monad/scripts/reset-workspace.sh
```

### Reset runtime state

Execute the official packaged reset step. It removes runtime chain data; verify its scope in the preceding step.

```bash
bash /opt/monad/scripts/reset-workspace.sh
```

### Download the Mainnet restore utility

Save the official utility for inspection.

```bash
curl -fL https://bucket.monadinfra.com/scripts/mainnet/restore-from-snapshot.sh -o /root/monad-restore-mainnet.sh
```

### Review restoration

Confirm the provider URLs, mainnet selection and database target.

```bash
less /root/monad-restore-mainnet.sh
```

### Restore the snapshot

Run the reviewed upstream recovery utility and wait for successful completion.

```bash
bash /root/monad-restore-mainnet.sh
```

Mainnet has activated MIP-8. Current recovery tooling builds a page timeline from a recent snapshot; do not apply an old slot-format restore command copied from a pre-fork guide.

### Check the database

Verify the imported state and timeline.

```bash
monad-mpt --storage /dev/triedb
```

### Inspect remote metadata settings

Check that both runtime metadata URLs point to Mainnet.

```bash
grep -E '^REMOTE_(VALIDATORS|FORKPOINT)_URL=' /home/monad/.env
```

### Start

Start after successful restoration; configured remote metadata is fetched on startup.

```bash
systemctl start monad-bft monad-execution monad-rpc
```

### Inspect synchronization

Look for statesync completion and new blocks.

```bash
journalctl -u monad-bft -n 100 -f -o cat
```

### Check RPC height

RPC becomes available after statesync completes.

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | jq
```

[Official recovery procedure](https://docs.monad.xyz/node-ops/node-recovery/hard-reset) · [Storage-format migration](https://docs.monad.xyz/node-ops/upgrade-instructions/page-storage-mip-8-migration).


# Upgrade

Update Monad Mainnet with version pinning and migration checks.

**Mainnet · package `monad`**

The reviewed rolling upgrade is **0.16.3 → 0.16.4**. Confirm Mainnet deployment approval before switching. Nodes on older versions must first complete the required intermediate configuration and MIP-8 migration steps in the [upstream upgrade index](https://docs.monad.xyz/node-ops/upgrade-instructions).

### Check version

Record the currently running release.

```bash
monad-rpc -V
```

### Check storage format

Inspect active TrieDB timelines before upgrading.

```bash
sudo monad-mpt --storage /dev/triedb
```

For MIP-8, follow the announced cohort and the [page-storage migration procedure](https://docs.monad.xyz/node-ops/upgrade-instructions/page-storage-mip-8-migration). State archive nodes have different requirements; do not blindly deactivate their slot timeline.

### Back up configuration

Store the backup in a restricted directory.

```bash
sudo tar -czf "/root/monad-config-$(date +%Y%m%d-%H%M%S).tar.gz" -C /home/monad .env monad-bft/config
```

### Refresh packages

Load the latest package metadata.

```bash
sudo apt update
```

### Stop services

Stop consensus, execution and RPC together.

```bash
sudo systemctl stop monad-bft monad-execution monad-rpc
```

### Install the approved package

Use the reviewed target after confirming the upgrade path.

```bash
sudo apt install --reinstall monad=0.16.4 --allow-change-held-packages
```

### Keep the hold

Prevent unattended consensus-version changes.

```bash
sudo apt-mark hold monad
```

### Start services

Start the updated node.

```bash
sudo systemctl start monad-bft monad-execution monad-rpc
```

### Check health

Verify all services are active.

```bash
sudo systemctl status monad-bft monad-execution monad-rpc --no-pager -l
```

### Confirm version

Expect the selected v0.16.4 tag.

```bash
monad-rpc -V
```

### Confirm advancing blocks

Repeat after a short interval.

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | jq
```

If the new release fails, keep services stopped while checking logs and the required migration path. Do not initialize TrieDB or perform a hard reset as a generic rollback.

[Release-specific instructions](https://docs.monad.xyz/node-ops/upgrade-instructions/v0.16.4).


# Validator

Register a synchronized Monad node as a Mainnet validator.

**Mainnet · validator onboarding**

First synchronize your [Full Node](/mainnet/monad/full-node). Registration requires at least **100,000 MON self-stake** plus fees. Active participation additionally requires at least **10,000,000 MON total stake** and a position in the top **200** validators, while retaining the minimum self-stake. Confirm the staking requirements in the [official validator guide](https://docs.monad.xyz/node-ops/validator-installation) before registration.

## Configure validator operation

### Save the current node configuration

Keep your existing identity and discovery record.

```bash
sudo cp -p /home/monad/monad-bft/config/node.toml /home/monad/monad-bft/config/node.toml.before-validator
```

### Download the validator template

Save a separate file so current settings are not overwritten.

```bash
curl -fL https://bucket.monadinfra.com/config/mainnet/latest/node.toml -o "$HOME/monad-validator-template.toml"
```

### Review and apply settings

Compare the template with your node. Set a real beneficiary rewards address and retain your keystores and signed discovery record.

```bash
sudo nano /home/monad/monad-bft/config/node.toml
```

Restart according to the configuration change and verify synchronization before registering. A full node’s zero beneficiary should not remain in a validator configuration.

## Install the staking CLI

Use a trusted operator workstation for staking. The official CLI supports Ledger hardware wallets.

### Install Python tooling

Prepare an isolated Python environment.

```bash
sudo apt install -y git python3 python3-venv
```

### Clone the CLI

Download the official staking utility.

```bash
git clone https://github.com/monad-developers/staking-sdk-cli.git
```

### Open the repository

Run the remaining CLI commands here.

```bash
cd staking-sdk-cli
```

### Create an environment

Keep dependencies separate from system Python.

```bash
python3 -m venv cli-venv
```

### Activate

Use the isolated environment.

```bash
source cli-venv/bin/activate
```

### Install dependencies

Install the checked-out CLI package.

```bash
pip install .
```

### Copy its configuration

Create your local configuration.

```bash
cp staking-cli/config.toml.example config.toml
```

### Restrict configuration permissions

Keep wallet configuration private.

```bash
chmod 0600 config.toml
```

### Configure Mainnet and the signing wallet

Set the mainnet RPC (chain 143), funded signer and wallet option. Prefer the documented Ledger setup for production.

```bash
nano config.toml
```

## Register and verify

Recover the current node SECP and BLS keys using `monad-keystore recover` in a private operator session, as described in the [upstream onboarding workflow](https://github.com/monad-developers/staking-sdk-cli/blob/main/docs/validator-onboarding.md). Compare the derived public keys to the running node. Old recovery files can use an outdated keystore representation.

### Open interactive onboarding

Choose Add Validator and enter your node identity, authorized address and stake. Review the public-key match and transaction before confirming.

```bash
python staking-cli/main.py tui
```

The authorized address controls validator operations; it must be an address you control. Wait for transaction status 1, record the returned validator ID, and check the validator record and execution set through the CLI’s Query menu. Registration alone does not imply active-set membership.

[CLI reference](https://github.com/monad-developers/staking-sdk-cli) · [Validator onboarding](https://docs.monad.xyz/node-ops/validator-installation).


# Useful Commands

Monad service, RPC and storage commands.

**Mainnet · systemd and JSON-RPC**

## Service operations

### Status

Inspect all node services.

```bash
sudo systemctl status monad-bft monad-execution monad-rpc --no-pager -l
```

### Consensus logs

Follow consensus activity.

```bash
sudo journalctl -u monad-bft -f -o cat
```

### Execution logs

Inspect state execution.

```bash
sudo journalctl -u monad-execution -f -o cat
```

### Stop

Stop the three node services.

```bash
sudo systemctl stop monad-bft monad-execution monad-rpc
```

### Start

Start the services.

```bash
sudo systemctl start monad-bft monad-execution monad-rpc
```

### Version

Show the RPC release tag.

```bash
monad-rpc -V
```

### Package hold

Confirm consensus version pinning.

```bash
apt-mark showhold
```

## RPC checks

### Chain ID

Expected result: 0x8f.

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' | jq
```

### Block height

Repeat to verify blocks advance.

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | jq
```

### Client version

Read the running RPC implementation version.

```bash
curl -fsS http://127.0.0.1:8080/ -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' | jq
```

## Storage and cleanup

### TrieDB usage

Inspect raw database utilization and timelines.

```bash
sudo monad-mpt --storage /dev/triedb
```

### Filesystem usage

Check the OS and ledger disk.

```bash
df -h /home/monad
```

### Cleanup timer

Check the package’s artifact cleanup schedule.

```bash
systemctl status monad-cruft.timer --no-pager
```

## Validator operations

Open the official staking CLI from its configured environment for delegation, commission, withdrawal and validator queries. Verify Mainnet and your validator ID before signing.

```bash
python staking-cli/main.py tui
```

[Operations reference](https://docs.monad.xyz/node-ops/general-operations).


# Nolus

Nolus Mainnet: node guides, services and operations.

**Mainnet · `pirin-1` · nolusd**

Run a Nolus consensus node on pirin-1, restore its state, and maintain a validator.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Installation</strong></td><td>Prepare the server and start syncing.</td><td><a href="/mainnet/nolus/installation">Installation</a></td></tr><tr><td><strong>Validator</strong></td><td>Create a wallet and register your validator.</td><td><a href="/mainnet/nolus/validator">Validator</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Replace the binary and verify recovery.</td><td><a href="/mainnet/nolus/upgrade">Upgrade</a></td></tr><tr><td><strong>Services</strong></td><td>BlockPro endpoints and connection files.</td><td><a href="/mainnet/nolus/services">Services</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Restore recent chain data step by step.</td><td><a href="/mainnet/nolus/snapshots">Snapshots</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, keys, tokens and validator operations.</td><td><a href="/mainnet/nolus/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Requirements

| Resource | BlockPro planning baseline                   |
| -------- | -------------------------------------------- |
| CPU      | 4+ cores                                     |
| RAM      | 16 GB+                                       |
| Storage  | 500 GB+ fast SSD; expand for archive history |
| OS       | Ubuntu 24.04 LTS, x86-64                     |

These are operational planning values, not an upstream guarantee. Measure snapshot size, free space and workload before provisioning. The source repository is the authority for build dependencies.

Allow inbound P2P on TCP `26656`. Keep RPC `26657`, REST `1317` and gRPC `9090` private unless you are deliberately operating a protected public service. Use a separate server for each network.

## Versions

Reference release: [`v0.8.4`](https://github.com/nolus-protocol/nolus-core/tree/v0.8.4). The tag includes the leading `v`. Build from the release tag, not the development branch.

Read the version reported by the network before installation or upgrade; this response is live and is not cached in this guide.

```bash
curl -fsS https://nolus-api.block-pro.net/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

If the endpoint is unavailable, confirm the active release with the project’s official validator announcements. Do not guess from the highest GitHub tag.

[Official documentation](https://github.com/nolus-protocol/nolus-core) · [Source code](https://github.com/nolus-protocol/nolus-core)


# Installation

Install and synchronize Nolus Mainnet, one command at a time.

**Mainnet · `pirin-1` · Ubuntu 24.04 / x86-64**

Use a normal Linux account with sudo access. Commands assume a new node and the same shell session. Existing operators should use [Upgrade](/mainnet/nolus/upgrade).

### 1. Prepare packages

Refresh package metadata.

```bash
sudo apt update
```

### Install dependencies

Install download, build and snapshot tools.

```bash
sudo apt install -y ca-certificates curl jq git make build-essential golang-go lz4 tar
```

## Install the binary

### Download the release source

Clone the tagged release into a new directory. Keep any existing checkout intact.

```bash
git clone --branch v0.8.4 --depth 1 https://github.com/nolus-protocol/nolus-core.git "$HOME/nolus-core-v0.8.4"
```

### Open the source tree

Run the following build commands from this directory.

```bash
cd "$HOME/nolus-core-v0.8.4"
```

### Check the required Go toolchain

Read the release’s own Go requirement. Go 1.21+ can obtain the requested toolchain automatically.

```bash
awk '/^go |^toolchain / {print}' go.mod
```

### Build and install

Build the selected release; the Go toolchain is selected from its go.mod.

```bash
GOTOOLCHAIN=auto make install
```

### Install in the service path

Copy the built executable to the path used by systemd.

```bash
sudo install -m 0755 "$(go env GOPATH)/bin/nolusd" /usr/local/bin/nolusd
```

### Locate the release’s Wasm library

Resolve the WasmVM module used by this exact checkout.

```bash
WASM_DIR=$(GOTOOLCHAIN=auto go list -m -f '{{.Path}} {{.Dir}}' all | awk '$1 ~ /^github.com\/CosmWasm\/wasmvm(\/v[0-9]+)?$/ {print $2}')
```

### Install its runtime library

Use the matching x86-64 library from the downloaded module.

```bash
find "$WASM_DIR" -name libwasmvm.x86_64.so -exec sudo install -m 0755 {} /usr/local/lib/ \;
```

### Refresh the linker cache

Make the shared library discoverable to the service.

```bash
sudo ldconfig
```

### Verify the binary

Confirm the selected version starts successfully.

```bash
nolusd version --long
```

## Initialize and connect

### Initialize once

Replace MY\_NODE with your own moniker. Do not rerun this over an existing validator home.

```bash
nolusd init "MY_NODE" --chain-id pirin-1
```

### Download genesis

Save network genesis to the node configuration.

```bash
curl -fL https://raw.githubusercontent.com/nolus-protocol/nolus-networks/main/mainnet/pirin-1/genesis.json -o "$HOME/.nolus/config/genesis.json"
```

### Verify the network

Continue only if the file is valid JSON and this check returns true.

```bash
jq -e '.chain_id == "pirin-1"' "$HOME/.nolus/config/genesis.json"
```

### Download the address book

Load BlockPro’s published peer discovery file.

```bash
curl -fL https://raw.githubusercontent.com/Shoni-O/files/main/mainnet-files/nolus/addrbook.json -o "$HOME/.nolus/config/addrbook.json"
```

### Check the address book

Ensure the download contains peer records, not an HTML error page.

```bash
jq -e '.addrs | type == "array"' "$HOME/.nolus/config/addrbook.json"
```

### Set minimum gas prices

Set this node’s local transaction admission policy.

```bash
sed -i 's/^minimum-gas-prices *=.*/minimum-gas-prices = "0.0025unls"/' "$HOME/.nolus/config/app.toml"
```

### Use bounded pruning

Keep the application’s standard pruning policy; archive operation needs more disk space.

```bash
sed -i 's/^pruning *=.*/pruning = "default"/' "$HOME/.nolus/config/app.toml"
```

## Run with systemd

### Create the service

Run the node as the current non-root account, with automatic restart after a process failure.

```bash
sudo tee /etc/systemd/system/nolusd.service > /dev/null <<EOF
[Unit]
Description=Nolus Mainnet node
After=network-online.target
Wants=network-online.target

[Service]
User=$(id -un)
WorkingDirectory=$HOME/.nolus
ExecStart=/usr/local/bin/nolusd start --home $HOME/.nolus
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF
```

### Load the unit

Tell systemd about the new service.

```bash
sudo systemctl daemon-reload
```

### Enable on boot

Enable the service without starting it yet.

```bash
sudo systemctl enable nolusd
```

### Restore recent state

Follow [Snapshots](/mainnet/nolus/snapshots) before starting. The current binary may not replay every historical upgrade from genesis. Choose a snapshot compatible with the installed release.

### Start

Start the node after restoration.

```bash
sudo systemctl start nolusd
```

### Follow logs

Look for advancing blocks; Ctrl+C leaves the service running.

```bash
sudo journalctl -u nolusd -f -o cat
```

### Check synchronization

Wait for catching\_up to become false and compare the height with the explorer.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

Next: [Validator](/mainnet/nolus/validator) or [Useful Commands](/mainnet/nolus/useful-commands).

[Upstream reference](https://github.com/nolus-protocol/nolus-core).


# Validator

Create and maintain a Nolus validator on Mainnet.

**Mainnet · `pirin-1`**

Complete [Installation](/mainnet/nolus/installation) and wait for full synchronization. The wallet key authorizes transactions; the consensus key signs blocks. Back up both securely, and never run two nodes with the same consensus key.

### Create a wallet

Save the recovery phrase offline. Use the recovery command instead if you already have a wallet.

```bash
nolusd keys add wallet
```

### Recover an existing wallet — alternative

Enter the recovery phrase interactively.

```bash
nolusd keys add wallet --recover
```

### Show the funding address

Fund this address on the correct network and leave a balance for fees.

```bash
nolusd keys show wallet -a
```

### Check balance

Read the funded account balance.

```bash
nolusd query bank balances "$(nolusd keys show wallet -a)"
```

### Check synchronization

Continue only after catching\_up is false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info.catching_up'
```

### Back up the consensus key

Create a local protected backup, then copy it to secure offline storage.

```bash
install -D -m 0600 "$HOME/.nolus/config/priv_validator_key.json" "$HOME/validator-backup/nolus-mainnet-priv_validator_key.json"
```

### Check create-validator syntax

Inspect the release’s CLI before submitting. The formats below differ between older and newer Cosmos SDK releases.

```bash
nolusd tx staking create-validator --help
```

### Register the validator

Choose the format shown by your binary’s help. Replace the moniker and amount, then review the transaction before confirming. The sample stake is not a promise of entry into the active set. For a CLI that accepts a validator JSON file, prepare the message.

```bash
jq -n --argjson pubkey "$(nolusd comet show-validator)" '{pubkey:$pubkey,amount:"1000000unls",moniker:"MY_VALIDATOR",identity:"",website:"",security:"",details:"","commission-rate":"0.05","commission-max-rate":"0.20","commission-max-change-rate":"0.01","min-self-delegation":"1"}' > "$HOME/validator.json"
```

### Submit the JSON message

Broadcast only after reviewing validator.json.

```bash
nolusd tx staking create-validator "$HOME/validator.json" --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

If your release exposes the legacy `--pubkey` form, use the following alternative instead; do not submit both.

```bash
nolusd tx staking create-validator --amount 1000000unls \
  --pubkey "$(nolusd tendermint show-validator)" --moniker "MY_VALIDATOR" \
  --commission-rate 0.05 --commission-max-rate 0.20 \
  --commission-max-change-rate 0.01 --min-self-delegation 1 \
  --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

### Verify registration

Query the validator record after the transaction is included in a block.

```bash
nolusd query staking validator "$(nolusd keys show wallet --bech val -a)"
```

Registration and active voting power are different states. Check bonded status and the active-set threshold in the explorer.

[Validator reference](https://github.com/nolus-protocol/nolus-core).


# Upgrade

Upgrade Nolus safely and confirm the node resumes syncing.

**Mainnet · `pirin-1`**

This procedure uses the direct `nolusd.service` created by our installation guide. If your service uses Cosmovisor, stage the binary under the exact on-chain upgrade plan name instead of replacing its symlink.

{% hint style="warning" %}
For a scheduled chain upgrade, prepare the binary in advance and switch only at the announced height. For a compatible patch, follow the project’s release instructions. Do not skip database migrations or start an old binary against upgraded state.
{% endhint %}

### Check the service

Confirm its executable and home before changing anything.

```bash
systemctl cat nolusd
```

### Check the upgrade plan

Read any scheduled on-chain upgrade.

```bash
nolusd query upgrade plan -o json
```

### Prepare the new binary

Use the binary download/build steps in [Installation](/mainnet/nolus/installation), but stage the result as `$HOME/nolusd.next` and do not install it over the running executable yet. Select the release announced for `pirin-1`.

### Create an upgrade checkout

Use a new directory and the intended release tag.

```bash
git clone --branch v0.8.4 --depth 1 https://github.com/nolus-protocol/nolus-core.git "$HOME/nolus-upgrade-v0.8.4"
```

### Open the checkout

Build from the release source.

```bash
cd "$HOME/nolus-upgrade-v0.8.4"
```

### Build into a staging directory

GOBIN keeps the service executable unchanged.

```bash
GOTOOLCHAIN=auto GOBIN="$HOME/nolus-upgrade-bin" make install
```

### Stage the result

Use a predictable path for the replacement.

```bash
cp "$HOME/nolus-upgrade-bin/nolusd" "$HOME/nolusd.next"
```

If the release changes WasmVM, install its matching runtime library using the module lookup in Installation and run `sudo ldconfig` before starting the new binary.

### Make executable

Allow checking the staged binary.

```bash
chmod 0755 "$HOME/nolusd.next"
```

### Check the staged version

Resolve missing libraries or a wrong release before downtime.

```bash
"$HOME/nolusd.next" version --long
```

### Stop at the correct time

Stop the one active signer before switching binaries.

```bash
sudo systemctl stop nolusd
```

### Back up configuration and signing state

Keep the signing state from this stopped node. Store a full stopped database backup as well if the release requires one.

```bash
tar -czf "$HOME/nolus-mainnet-upgrade-$(date +%Y%m%d-%H%M%S).tar.gz" -C "$HOME/.nolus" config data/priv_validator_state.json
```

### Keep the previous binary

Retain a copy for diagnostics; database migrations may prevent a simple binary rollback.

```bash
cp /usr/local/bin/nolusd "$HOME/nolusd.previous"
```

### Replace the binary

Install the staged executable.

```bash
sudo install -m 0755 "$HOME/nolusd.next" /usr/local/bin/nolusd
```

### Start

Start the node with the upgraded binary.

```bash
sudo systemctl start nolusd
```

### Inspect logs

Check for migration errors and advancing heights.

```bash
sudo journalctl -u nolusd -n 100 -f -o cat
```

### Confirm sync

Check height and catching\_up after the node recovers.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

[Release history](https://github.com/nolus-protocol/nolus-core/tags).


# Services

BlockPro endpoints and peer discovery for Nolus Mainnet.

**Mainnet · `pirin-1`**

## Public endpoints

| Service  | Address                                                 |
| -------- | ------------------------------------------------------- |
| RPC      | <https://nolus-rpc.block-pro.net>                       |
| REST API | <https://nolus-api.block-pro.net>                       |
| Explorer | [Mainnet explorer](https://mainnet.block-pro.net/nolus) |

These addresses are carried over from BlockPro’s existing service directory. Availability is not a live status indicator.

## Connection files

| File         | Download                                                                                                          |
| ------------ | ----------------------------------------------------------------------------------------------------------------- |
| Genesis      | [genesis.json](https://raw.githubusercontent.com/nolus-protocol/nolus-networks/main/mainnet/pirin-1/genesis.json) |
| Address book | [addrbook.json](https://raw.githubusercontent.com/Shoni-O/files/main/mainnet-files/nolus/addrbook.json)           |

### Inspect the live RPC

Check the network ID, peer identity and sync status.

```bash
curl -fsS https://nolus-rpc.block-pro.net/status | jq '.result | {node_info, sync_info}'
```

### Live peers

List peers reported by the public RPC, if net\_info is enabled. Verify reachability before using an address.

```bash
curl -fsS https://nolus-rpc.block-pro.net/net_info | jq -r '.result.peers[]? | "\(.node_info.id)@\(.remote_ip):\(.node_info.listen_addr | split(":") | last)"'
```

Snapshot download and restore instructions: [Snapshots](/mainnet/nolus/snapshots).


# Snapshots

Restore Nolus Mainnet chain data without losing your validator identity.

**Mainnet · `pirin-1` · `.nolus`**

Provider: BlockPro. This URL comes from the existing service directory; inspect the archive before restoring. No unverified update frequency or height is advertised.

[Download snapshot](https://nolus-snapshot.block-pro.net/nolusdata.tar.lz4). Allow space for the compressed file, extracted data and the previous database.

{% hint style="warning" %}
This procedure replaces chain data. Keep config, keyring and validator keys. For an existing validator, preserve its latest priv\_validator\_state.json while stopped; never restore another validator’s signing state. Do not start a second signer during recovery.
{% endhint %}

### Download first

Download before stopping the node to reduce downtime.

```bash
curl -fL --retry 3 https://nolus-snapshot.block-pro.net/nolusdata.tar.lz4 -o "$HOME/nolus-snapshot.tar.lz4"
```

### Test compression

Stop if the compressed archive is corrupt.

```bash
lz4 -t "$HOME/nolus-snapshot.tar.lz4"
```

### Inspect paths

Check that entries are chain data, with no absolute paths or .. components. Choose strip-components based on the actual archive layout.

```bash
tar -I lz4 -tf "$HOME/nolus-snapshot.tar.lz4" | head -40
```

### Stop

Stop the service before changing its data.

```bash
sudo systemctl stop nolusd
```

### Back up signing state

Keep the latest state from your own stopped node.

```bash
cp -p "$HOME/.nolus/data/priv_validator_state.json" "$HOME/.nolus/priv_validator_state.json.before-snapshot"
```

### Keep the previous database

Rename the data directory. Use a fresh backup name if this path already exists.

```bash
mv "$HOME/.nolus/data" "$HOME/.nolus/data.before-snapshot"
```

### Extract chain data

The previous BlockPro archive layout uses two leading directories before data/. Use this command only if the path listing confirms it.

```bash
tar -I lz4 -xf "$HOME/nolus-snapshot.tar.lz4" -C "$HOME/.nolus" --strip-components=2
```

### Restore your signing state

Overwrite the snapshot’s signing state with your own backup.

```bash
cp -p "$HOME/.nolus/priv_validator_state.json.before-snapshot" "$HOME/.nolus/data/priv_validator_state.json"
```

### Start

Start only after the data directory layout is correct.

```bash
sudo systemctl start nolusd
```

### Verify recovery

Compare height and time with the explorer; wait for catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

Keep the previous database until the restored node is healthy. A snapshot is trusted input; a locally calculated checksum alone does not authenticate its provider.


# Useful Commands

Everyday Nolus service, wallet and validator commands.

**Mainnet · `pirin-1`**

Commands use the `wallet` key name. Transaction examples ask for confirmation. Replace quoted address placeholders and review amounts before signing. `1 NLS = 1,000,000 unls`.

## Service operations

### Status

Check the systemd unit.

```bash
sudo systemctl status nolusd --no-pager
```

### Logs

Follow recent logs.

```bash
sudo journalctl -u nolusd -f -o cat
```

### Restart

Restart the node process.

```bash
sudo systemctl restart nolusd
```

### Stop

Stop the node.

```bash
sudo systemctl stop nolusd
```

### Start

Start the node.

```bash
sudo systemctl start nolusd
```

### Sync status

Check height and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

### Version

Show the installed binary version.

```bash
nolusd version --long
```

## Key management

### Create

Create a wallet and securely store its recovery phrase.

```bash
nolusd keys add wallet
```

### Recover

Import a wallet interactively.

```bash
nolusd keys add wallet --recover
```

### List

List local keys.

```bash
nolusd keys list
```

### Address

Show the account address.

```bash
nolusd keys show wallet -a
```

### Balance

Query token balances.

```bash
nolusd query bank balances "$(nolusd keys show wallet -a)"
```

## Tokens

### Send

Send 1 token to the chosen recipient.

```bash
nolusd tx bank send wallet "RECIPIENT_ADDRESS" 1000000unls --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

### Delegate

Delegate 1 token to a validator.

```bash
nolusd tx staking delegate "VALIDATOR_ADDRESS" 1000000unls --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

### Withdraw rewards

Withdraw delegation rewards.

```bash
nolusd tx distribution withdraw-all-rewards --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

## Validator operations

### Details

Query your validator record.

```bash
nolusd query staking validator "$(nolusd keys show wallet --bech val -a)"
```

### Commission and rewards

Withdraw rewards and validator commission.

```bash
nolusd tx distribution withdraw-rewards "$(nolusd keys show wallet --bech val -a)" --commission --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

### Unjail

Use only after correcting the cause of jailing and meeting unjail conditions.

```bash
nolusd tx slashing unjail --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```

## Governance

### Proposals

List governance proposals.

```bash
nolusd query gov proposals
```

### Vote

Replace 123 with the proposal you have reviewed.

```bash
nolusd tx gov vote 123 yes --from wallet --chain-id pirin-1 --gas auto --gas-adjustment 1.5 --gas-prices 0.0025unls
```


# Starknet

Starknet Mainnet guides powered by Pathfinder.

**Mainnet · `SN_MAIN` · Pathfinder**

Operate a Starknet full node with Pathfinder. To participate as a validator, add registration and the separate attestation service.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Pathfinder Node</strong></td><td>Install the full node with Docker.</td><td><a href="/mainnet/starknet/pathfinder-node">Pathfinder Node</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Update the image and preserve your database.</td><td><a href="/mainnet/starknet/upgrade">Upgrade</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Restore a Software Mansion database snapshot.</td><td><a href="/mainnet/starknet/snapshots">Snapshots</a></td></tr><tr><td><strong>Validator &#x26; Attestation</strong></td><td>Register and run the attestation service.</td><td><a href="/mainnet/starknet/validator">Validator &amp; Attestation</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Logs, service control and JSON-RPC checks.</td><td><a href="/mainnet/starknet/useful-commands">Useful Commands</a></td></tr><tr><td><strong>How to Stake</strong></td><td>Delegate STRK through a staking interface.</td><td><a href="/mainnet/starknet/how-to-stake">How to Stake</a></td></tr></tbody></table>

## Requirements

| Resource        | Starting recommendation                                |
| --------------- | ------------------------------------------------------ |
| CPU             | 4 cores                                                |
| RAM             | 16 GB                                                  |
| Storage         | 1 TB SSD; more for archive history or snapshot backups |
| OS              | Ubuntu 24.04 LTS, x86-64                               |
| Runtime         | Docker Engine and Compose plugin                       |
| Ethereum access | Ethereum Mainnet WebSocket RPC (`wss://`)              |

Plan extra CPU, memory and disk space for heavy public RPC traffic. See [Pathfinder hardware requirements](https://docs.swmansion.com/pathfinder/getting-started/hardware-requirements/).

## Network and versions

| Setting                      | Value                             |
| ---------------------------- | --------------------------------- |
| Pathfinder network           | `mainnet`                         |
| Node container               | `pathfinder-mainnet`              |
| Local RPC                    | `http://127.0.0.1:9545/rpc/v0_10` |
| Reviewed Pathfinder release  | `v0.24.2`                         |
| Reviewed attestation release | `v0.5.2`                          |

Sources: [Pathfinder releases](https://github.com/software-mansion/pathfinder/releases/tag/v0.24.2) and [attestation releases](https://github.com/software-mansion/starknet-validator-attestation/releases). Check release notes before future upgrades.

RPC is bound to localhost in this guide. The node needs outbound access to its Ethereum provider and Starknet data sources.

[Pathfinder documentation](https://docs.swmansion.com/pathfinder/) · [Starknet operator overview](https://docs.starknet.io/secure/quickstart/overview).


# Pathfinder Node

Install and synchronize Pathfinder on Starknet Mainnet.

**Mainnet · `SN_MAIN` · Pathfinder v0.24.2**

Run each command separately in the same shell. The configuration below uses a persistent data directory and a private local RPC endpoint.

## Install Docker

On a fresh Ubuntu 24.04 server, use the following package installation. For a server with an existing container runtime, check [Docker’s compatibility instructions](https://docs.docker.com/engine/install/ubuntu/) first.

### Refresh packages

Refresh APT metadata.

```bash
sudo apt update
```

### Install basic tools

Install download and JSON tools.

```bash
sudo apt install -y ca-certificates curl jq
```

### Create the key directory

Prepare Docker’s signing-key location.

```bash
sudo install -m 0755 -d /etc/apt/keyrings
```

### Download the signing key

Get the Docker repository key.

```bash
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
```

### Set key permissions

Allow APT to read the public key.

```bash
sudo chmod a+r /etc/apt/keyrings/docker.asc
```

### Add the package repository

Configure the official stable Ubuntu repository.

```bash
sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
```

### Refresh the new repository

Load Docker’s package list.

```bash
sudo apt update
```

### Install Docker

Install Engine and Compose from the configured repository.

```bash
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
```

### Enable Docker

Start the runtime and enable it on boot.

```bash
sudo systemctl enable --now docker
```

## Configure Pathfinder

### Create the project directory

Keep configuration and persistent data together.

```bash
mkdir -p "$HOME/pathfinder-mainnet/data"
```

### Open the directory

Run Compose commands from this directory.

```bash
cd "$HOME/pathfinder-mainnet"
```

### Store your Ethereum WebSocket URL

Enter your private Mainnet wss\:// endpoint at the prompt; it will not be echoed.

```bash
read -rsp "Ethereum WebSocket URL: " ETHEREUM_URL; printf "\n"
```

### Write the private environment file

Store the endpoint with permissions restricted to your Linux account.

```bash
(umask 077; printf 'PATHFINDER_ETHEREUM_API_URL=%s\n' "$ETHEREUM_URL" > pathfinder.env)
```

### Clear the shell variable

Remove the temporary copy from the shell.

```bash
unset ETHEREUM_URL
```

### Write the Compose configuration

Pin the image and keep the database outside the container.

```bash
cat > compose.yaml <<EOF
services:
  pathfinder:
    image: swmansion/pathfinder:v0.24.2
    container_name: pathfinder-mainnet
    user: "$(id -u):$(id -g)"
    restart: unless-stopped
    stop_grace_period: 2m
    env_file:
      - pathfinder.env
    environment:
      RUST_LOG: info
    ports:
      - "127.0.0.1:9545:9545"
    volumes:
      - ./data:/usr/share/pathfinder/data
    command:
      - --network=mainnet
      - --http-rpc=0.0.0.0:9545
      - --storage.state-tries=100
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "5"
EOF
```

This configuration retains recent state tries while keeping block history. For historical storage proofs, choose `--storage.state-tries=archive` before creating the database and provision extra storage. Use a snapshot with a matching mode.

### Download the image

Fetch the pinned release.

```bash
sudo docker compose pull pathfinder
```

### Optional: start from a snapshot

Follow [Snapshots](/mainnet/starknet/snapshots) before first startup. Otherwise Pathfinder synchronizes from the network.

### Start the node

Create the container and begin synchronization.

```bash
sudo docker compose up -d pathfinder
```

### Follow logs

Check network selection and progressing blocks.

```bash
sudo docker compose logs --tail 100 -f pathfinder
```

### Verify chain ID

Expected result: `0x534e5f4d41494e` (SN\_MAIN).

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_chainId","params":[],"id":1}' | jq
```

### Check sync

An object reports progress; false means the node has caught up. Confirm block height also advances.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_syncing","params":[],"id":1}' | jq
```

### Check block height

Repeat after a short interval to confirm new blocks arrive.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_blockNumber","params":[],"id":1}' | jq
```

[Setup reference](https://docs.swmansion.com/pathfinder/getting-started/running-pathfinder/) · [Configuration reference](https://docs.swmansion.com/pathfinder/getting-started/configuration/).


# Upgrade

Update Pathfinder on Mainnet while preserving its database.

**Mainnet · Pathfinder / Docker Compose**

Use the project directory from [Pathfinder Node](/mainnet/starknet/pathfinder-node). Review [release notes](https://github.com/software-mansion/pathfinder/releases) for migration requirements.

### Open the project

Use the correct network’s configuration.

```bash
cd "$HOME/pathfinder-mainnet"
```

### Record the current image

Keep the image reference for diagnosis.

```bash
sudo docker compose images
```

### Select the reviewed release

Update only the image line; preserve all network, port and volume settings.

```bash
sed -i 's|image: swmansion/pathfinder:.*|image: swmansion/pathfinder:v0.24.2|' compose.yaml
```

### Pull before downtime

Fetch the selected image.

```bash
sudo docker compose pull pathfinder
```

### Stop cleanly

Wait for the database to close.

```bash
sudo docker compose stop pathfinder
```

### Back up the stopped database

Use a new backup path and ensure there is enough free space.

```bash
cp -a data "data.backup-$(date +%Y%m%d-%H%M%S)"
```

### Recreate the container

Compose uses the new image with the existing data directory.

```bash
sudo docker compose up -d pathfinder
```

### Watch migration and startup

Wait for migration to finish; avoid interrupting it.

```bash
sudo docker compose logs --tail 100 -f pathfinder
```

### Verify sync

Confirm the node returns to the network tip.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_syncing","params":[],"id":1}' | jq
```

Keep the backup until the upgrade is healthy. A database migration may make downgrading the image alone unsafe.

## Attestation service

If installed, upgrade the attestation container separately. Stop it, pull the selected release, and recreate it with the same operational account and network settings from [Validator & Attestation](/mainnet/starknet/validator). Check confirmed attestations after restart.

[Pathfinder upgrade reference](https://docs.swmansion.com/pathfinder/getting-started/updating-pathfinder/).


# Snapshots

Restore a Pathfinder database snapshot for Mainnet.

**Mainnet · Software Mansion snapshots**

Open the [official snapshot list](https://rpc.pathfinder.swmansion.com/snapshots/latest). Select **mainnet**, verify the minimum Pathfinder version and note the SHA-256 checksum. These snapshots are supplied by Software Mansion.

### Install extraction tools

Install Zstandard and the download client.

```bash
sudo apt install -y wget zstd
```

### Open the project

Use the same directory as the node guide.

```bash
cd "$HOME/pathfinder-mainnet"
```

### Download

Download the snapshot for this network.

```bash
wget --continue https://rpc.pathfinder.swmansion.com/snapshots/latest/mainnet.sqlite.zst -O snapshot.sqlite.zst
```

### Check the checksum

Compare the output with the value on the official list. Stop on a mismatch.

```bash
sha256sum snapshot.sqlite.zst
```

### Stop the node

Skip this command only if the container has never been created.

```bash
sudo docker compose stop pathfinder
```

### Keep the old database directory

Moving the whole directory also preserves any SQLite WAL files. Use a fresh backup path.

```bash
mv data "data.before-snapshot-$(date +%Y%m%d-%H%M%S)"
```

### Create a clean data directory

Prepare the mounted directory.

```bash
mkdir data
```

### Extract

Write the database using the filename expected for this network.

```bash
zstd -T0 -d snapshot.sqlite.zst -o data/mainnet.sqlite
```

Match the snapshot’s state-trie mode in `compose.yaml`. If its mode differs from `--storage.state-tries=100`, use the mode supplied by the snapshot or choose a matching snapshot; changing archive/pruned mode requires a new database.

### Start

Start Pathfinder against the restored file.

```bash
sudo docker compose up -d pathfinder
```

### Verify recovery

The node should catch up from the snapshot height.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_syncing","params":[],"id":1}' | jq
```

[Snapshot reference](https://docs.swmansion.com/pathfinder/database-snapshots/).


# Validator & Attestation

Register a Starknet Mainnet validator and run attestations.

**Mainnet · staking and block attestations**

A synchronized Pathfinder node is the prerequisite. Validator onboarding also needs three deployed accounts: staker, rewards and operational. Install [Starknet Foundry sncast](https://foundry-rs.github.io/starknet-foundry/getting-started/installation.html), configure the staker account, and fund the operational account for attestation fees. Keep the staker key offline when possible.

The official tutorial demonstrates Sepolia. The commands below explicitly target **Mainnet**. Verify contract addresses against [Starknet chain information](https://docs.starknet.io/learn/cheatsheets/chain-info) before signing. The reviewed minimum is **20,000 STRK**, plus transaction fees. Recheck the current minimum stake in [staking specifications](https://docs.starknet.io/learn/protocol/staking) rather than assuming the tutorial’s sample amount is sufficient.

### Set contract addresses

Use the contracts for this network.

```bash
STAKING_CONTRACT=0x00ca1702e64c81d9a07b86bd2c540188d92a2c73cf5cc0e508d949015e7e84a7
STRK_CONTRACT=0x04718f5a0fc34cc1af16a1cdee98ffb20c31f5cd61d6ab07201858f4287c938d
```

### Set your accounts

Replace each value with a deployed account address on this network.

```bash
STAKING_ADDRESS="YOUR_STAKER_ADDRESS"
REWARDS_ADDRESS="YOUR_REWARDS_ADDRESS"
OPERATIONAL_ADDRESS="YOUR_OPERATIONAL_ADDRESS"
```

### Choose the stake

Set the amount in base units: 1 STRK is 10^18 units. Enter an amount meeting the current minimum.

```bash
read -rp "Stake amount in STRK base units: " STAKE_AMOUNT
```

### Approve the transfer

Authorize only the chosen amount for the staking contract.

```bash
sncast --account staker invoke --network mainnet \
  --contract-address "$STRK_CONTRACT" --function approve \
  --arguments "$STAKING_CONTRACT,$STAKE_AMOUNT"
```

### Stake

Wait for approval to succeed, then lock the selected amount.

```bash
sncast --account staker invoke --network mainnet \
  --contract-address "$STAKING_CONTRACT" --function stake \
  --arguments "$REWARDS_ADDRESS,$OPERATIONAL_ADDRESS,$STAKE_AMOUNT"
```

### Set commission

This example sets 1% (100 of 10,000). Choose your rate before submitting.

```bash
sncast --account staker invoke --network mainnet --contract-address "$STAKING_CONTRACT" --function set_commission --arguments 100
```

### Open STRK delegation

Allow delegators to use your STRK pool.

```bash
sncast --account staker invoke --network mainnet --contract-address "$STAKING_CONTRACT" --function set_open_for_delegation --arguments "$STRK_CONTRACT"
```

### Verify registration

Check the returned account, stake and pool information.

```bash
sncast call --network mainnet --contract-address "$STAKING_CONTRACT" --function get_staker_info_v1 --arguments "$STAKING_ADDRESS"
```

The local signer requires a compatible deployed operational account without additional guardian or hardware-signing requirements. Use a dedicated operational account; keep your staker account’s custody setup intact.

## Run the attestation service

The attestation tool signs with the operational account and talks to your own synchronized Pathfinder RPC. Its current source requires JSON-RPC 0.10; use the versioned endpoint below.

### Open the node directory

Keep the attestation environment next to the node configuration.

```bash
cd "$HOME/pathfinder-mainnet"
```

### Enter the operational private key

Enter only the operational key; the prompt hides input.

```bash
read -rsp "Operational private key: " OPERATIONAL_PRIVATE_KEY; printf "\n"
```

### Store it privately

Create a restricted environment file. Do not share this file.

```bash
(umask 077; printf 'VALIDATOR_ATTESTATION_OPERATIONAL_PRIVATE_KEY=%s\n' "$OPERATIONAL_PRIVATE_KEY" > attestation.env)
```

### Clear the temporary key

Remove the key from the current shell variable.

```bash
unset OPERATIONAL_PRIVATE_KEY
```

### Pull the attestation image

Download the reviewed release.

```bash
sudo docker pull ghcr.io/software-mansion/starknet-validator-attestation:v0.5.2
```

### Check supported options

Check release options and RPC requirements before starting.

```bash
sudo docker run --rm ghcr.io/software-mansion/starknet-validator-attestation:v0.5.2 --help
```

### Start attestations

The host network lets the service reach your localhost Pathfinder endpoint.

```bash
sudo docker run -d --name attest-mainnet --restart unless-stopped \
  --network host --env-file "$HOME/pathfinder-mainnet/attestation.env" \
  --log-opt max-size=20m --log-opt max-file=5 \
  ghcr.io/software-mansion/starknet-validator-attestation:v0.5.2 \
  --staking-contract-address 0x00ca1702e64c81d9a07b86bd2c540188d92a2c73cf5cc0e508d949015e7e84a7 \
  --attestation-contract-address 0x10398fe631af9ab2311840432d507bf7ef4b959ae967f1507928f5afe888a99 \
  --staker-operational-address "$OPERATIONAL_ADDRESS" \
  --node-url http://127.0.0.1:9545/rpc/v0_10 \
  --metrics-address 127.0.0.1:9090 \
  --local-signer
```

### Verify confirmed attestations

Look for confirmed transactions, not just a running container.

```bash
sudo docker logs --tail 100 -f attest-mainnet
```

Monitor the operational STRK balance, node lag and missed epochs. Docker administrators can read container environment variables; use the tool’s remote signer option if your custody design requires it.

[Validator onboarding](https://docs.starknet.io/secure/quickstart/becoming-a-validator) · [Attestation quickstart](https://docs.starknet.io/secure/quickstart/attesting-to-blocks) · [Attestation tool](https://github.com/software-mansion/starknet-validator-attestation).


# Useful Commands

Pathfinder and attestation operations for Starknet Mainnet.

**Mainnet · `pathfinder-mainnet`**

## Service operations

### Container status

Show the node container.

```bash
sudo docker ps -a --filter name=pathfinder-mainnet
```

### Logs

Follow node logs.

```bash
sudo docker logs --tail 100 -f pathfinder-mainnet
```

### Restart

Restart the same container and configuration.

```bash
sudo docker restart pathfinder-mainnet
```

### Stop

Stop the node cleanly.

```bash
sudo docker stop -t 120 pathfinder-mainnet
```

### Start

Start an existing stopped container.

```bash
sudo docker start pathfinder-mainnet
```

### Resource usage

Inspect CPU and memory use.

```bash
sudo docker stats --no-stream pathfinder-mainnet
```

## JSON-RPC checks

### Network

Query the local versioned endpoint.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_chainId","params":[],"id":1}' | jq
```

### Sync status

Query the local versioned endpoint.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_syncing","params":[],"id":1}' | jq
```

### Block height

Query the local versioned endpoint.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_blockNumber","params":[],"id":1}' | jq
```

### RPC specification

Query the local versioned endpoint.

```bash
curl -fsS http://127.0.0.1:9545/rpc/v0_10 -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"starknet_specVersion","params":[],"id":1}' | jq
```

## Attestation operations

### Attestation logs

Check confirmed attestations and funding errors.

```bash
sudo docker logs --tail 100 -f attest-mainnet
```

### Restart attestations

Restart the existing service.

```bash
sudo docker restart attest-mainnet
```

### Metrics

Read local Prometheus metrics.

```bash
curl -fsS http://127.0.0.1:9090/metrics
```

## Storage

### Database size

Measure the mounted database.

```bash
du -sh "$HOME/pathfinder-mainnet/data"
```

### Free space

Check available filesystem space.

```bash
df -h "$HOME/pathfinder-mainnet/data"
```


# How to Stake

Delegate STRK on Starknet Mainnet.

**Mainnet · STRK delegation**

Delegation does not require you to run Pathfinder or operate a validator.

## 1. Prepare a wallet

Use a Starknet wallet such as [Ready](https://www.ready.co/ready-wallet) or [Braavos](https://braavos.app/). Select Mainnet and keep a balance for transaction fees.

## 2. Choose a staking interface

Open [Endur’s dashboard](https://dashboard.endur.fi/). Endur is a third-party interface. Connect the intended wallet and review the current staking options.

## 3. Review the validator

Open the validator list and check the validator’s identity, commission, performance and delegation conditions. Select the intended validator and choose STRK staking.

## 4. Review and sign

Enter the amount. Confirm the network, recipient contract, amount and fee in your wallet before approving. Returns vary; a displayed estimate is not a guaranteed yield.

## 5. Verify your position

Wait for transaction confirmation, then check the position and rewards in the dashboard. Review the current exit delay before starting an unstake request.

## Video walkthrough

[Watch BlockPro’s staking walkthrough](https://youtu.be/I6h5cqBHZKQ?si=i7t-Eketmgs17Sus). Interface labels may have changed since recording.

[Starknet staking documentation](https://docs.starknet.io/secure/quickstart/overview).


# Celestia

Celestia Mocha testnet · Chain ID mocha-5

Run a Celestia node and connect to BlockPro infrastructure. Choose a guide, find an endpoint, or look up a command.

Start with [Requirements](/testnet/celestia/requirements) and [Versions](/testnet/celestia/versions).

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Validator Node</strong></td><td>Run consensus and manage your validator.</td><td><a href="/testnet/celestia/validator-node">Validator Node</a></td></tr><tr><td><strong>Consensus Node</strong></td><td>Sync the chain and serve RPC or gRPC.</td><td><a href="/testnet/celestia/consensus-node">Consensus Node</a></td></tr><tr><td><strong>Bridge Node</strong></td><td>Connect consensus to the DA network.</td><td><a href="/testnet/celestia/bridge-node">Bridge Node</a></td></tr><tr><td><strong>Light Node</strong></td><td>Sample data availability with a small node.</td><td><a href="/testnet/celestia/light-node">Light Node</a></td></tr><tr><td><strong>BlockPro Services</strong></td><td>Endpoints, peers, addrbook and snapshots.</td><td><a href="/testnet/celestia/services">Services</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, key, token and validator operations.</td><td><a href="/testnet/celestia/useful-commands">Useful Commands</a></td></tr></tbody></table>

## App and Fibre upgrade

Use celestia-app and Fibre **v10.5.0-mocha** for `mocha-5`. Follow the [Upgrade guide](/testnet/celestia/validator-node/upgrade) and review [Fibre health checks and HTTPS object storage](/testnet/celestia/validator-node/fibre).

## Before you start

Use the matching network throughout each guide. Commands are explained one step at a time.

[Full Storage Node compatibility](/testnet/celestia/full-node) · [Troubleshooting](/testnet/celestia/troubleshooting)

[BlockPro Explorer](https://testnet.block-pro.net/celestia/staking) · [Celestia documentation](https://docs.celestia.org/) · [Support](https://t.me/BLOCK_PR0)

BlockPro is an independent infrastructure provider.


# Requirements

**Mocha testnet** · Chain ID `mocha-5`

Use Ubuntu 24.04 LTS on x86\_64 for these guides. Linux celestia-app multiplexer binaries require glibc 2.38 or newer.

## Hardware

The following are current **Mainnet starting points**, not a guarantee of retention or future capacity. Mocha needs its own sizing based on retained history and usage.

| Node profile                      | CPU      | RAM    | Disk       | Network |
| --------------------------------- | -------- | ------ | ---------- | ------- |
| Light, pruned                     | 1 core   | 500 MB | 20 GB SSD  | 56 Kbps |
| Bridge, pruned                    | 32 cores | 64 GB  | 2 TB NVMe  | 1 Gbps  |
| Consensus, pruned                 | 32 cores | 32 GB  | 2 TB NVMe  | 1 Gbps  |
| Validator, base consensus process | 32 cores | 32 GB  | 2 TB NVMe  | 1 Gbps  |
| Bridge, archival                  | 32 cores | 64 GB  | 12 TB NVMe | 1 Gbps  |
| Consensus, archival               | 32 cores | 64 GB  | 16 TB NVMe | 1 Gbps  |

Storage depends on traffic, pruning and history. Leave working space for compaction and snapshot restoration. Size the consensus process separately when it shares a server with a bridge. Validators must pass Celestia's CPU benchmark. Fibre needs additional memory and a separate data disk; it is not included in the validator row.

Source: [Hardware requirements](https://docs.celestia.org/operate/getting-started/hardware-requirements/).

## Ports

| Port             | Purpose            | Exposure                       |
| ---------------- | ------------------ | ------------------------------ |
| 26656 TCP        | Consensus P2P      | Public when accepting peers    |
| 2121 TCP and UDP | DA P2P             | Public for bridge connectivity |
| 26657 TCP        | Consensus HTTP RPC | Local by default               |
| 9090 TCP         | Application gRPC   | Local or private by default    |
| 9098 TCP         | Core gRPC listener | Local or private by default    |
| 26658 TCP        | DA node JSON-RPC   | Local and authenticated        |

Your reverse proxy can expose public endpoints on a different port. Port 443 does not itself prove that a gRPC service supports TLS.

Source: [Consensus installation](https://docs.celestia.org/operate/consensus-validators/install-celestia-app/) and [bridge setup](https://docs.celestia.org/operate/data-availability/bridge-node/).


# Versions

**Mocha testnet** · Chain ID `mocha-5`

| Component     | Network-compatible release                                                               | Used by                                          |
| ------------- | ---------------------------------------------------------------------------------------- | ------------------------------------------------ |
| celestia-app  | [v10.5.0-mocha](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0-mocha)  | Consensus and validator nodes                    |
| Fibre         | [v10.5.0-mocha](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0-mocha)  | Bonded validators; matching celestia-app release |
| celestia-node | [v0.34.3-mocha](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3-mocha) | Light and bridge nodes                           |

The celestia-app and Fibre targets follow the [v10.5.0-mocha release](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0-mocha). The celestia-node entry is separate from this app release. These are documentation targets, not a measurement of the versions running on BlockPro servers.

## What changes in v10.5.0-mocha

Upgrade celestia-app and Fibre together using the matching network tag. Fibre adds a `[health]` table and gRPC readiness checks. Configured object-storage endpoints must use HTTPS, and the bucket must be accessible with the service credentials at startup. See [Fibre](/testnet/celestia/validator-node/fibre) for configuration and checks.

## Check your installation

Print the installed consensus binary version.

```bash
celestia-appd version
```

Print the installed Fibre version on the Fibre host.

```bash
fibre version
```

Print the installed DA binary version.

```bash
celestia version
```

Read the active application version from your running node.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

A v10 multiplexer can still run app version 9 until the network activates its upgrade. Installation alone does not activate v10. Follow the release instructions for timing, migration, and Fibre requirements; do not replace the multiplexer with a standalone build during the v9-to-v10 transition.

The install guide and compatibility table can update at different times. Use the network compatibility table and the release notes together before changing a production node.

Source: [Network compatibility table](https://docs.celestia.org/operate/networks/overview/).

## Upgrade guides

[Validator Node](/testnet/celestia/validator-node/upgrade) · [Bridge Node](/testnet/celestia/bridge-node/upgrade) · [Light Node](/testnet/celestia/light-node/upgrade)


# Consensus Node

**Mocha testnet** · Chain ID `mocha-5`

A consensus node follows the chain and can serve RPC and application gRPC. This guide creates a new node; do not run initialization over an existing validator home.

Complete [Server Setup](/testnet/celestia/consensus-node/server-setup), excluding the optional Go section.

## Install celestia-app

Create a download directory.

```bash
mkdir -p "$HOME/celestia-downloads"
```

Open the directory.

```bash
cd "$HOME/celestia-downloads"
```

Download the network-specific multiplexer archive.

```bash
curl -fL --retry 3 -o celestia-app.tar.gz https://github.com/celestiaorg/celestia-app/releases/download/v10.5.0-mocha/celestia-app_Linux_x86_64.tar.gz
```

Download its checksum list.

```bash
curl -fL --retry 3 -o app-checksums.txt https://github.com/celestiaorg/celestia-app/releases/download/v10.5.0-mocha/checksums.txt
```

Select the checksum and match it to the local filename.

```bash
awk '$2 == "celestia-app_Linux_x86_64.tar.gz" {print $1 "  celestia-app.tar.gz"}' app-checksums.txt > app.sha256
```

Verify the download. Stop on a missing entry or failed checksum.

```bash
sha256sum --check app.sha256
```

Create an empty extraction directory; use a fresh directory if this already exists.

```bash
mkdir app-unpack
```

Extract the verified archive.

```bash
tar -xzf celestia-app.tar.gz -C app-unpack
```

Locate the binary in the release archive.

```bash
find app-unpack -type f -name celestia-appd
```

Install it. If the previous command showed a nested path, use that exact path here.

```bash
sudo install -m 0755 app-unpack/celestia-appd /usr/local/bin/celestia-appd
```

Check the installed version.

```bash
celestia-appd version
```

## Initialize the network

Create the node configuration and keys for this network.

```bash
celestia-appd init "YOUR_NODE_NAME" --chain-id mocha-5
```

Download genesis using the network-aware command.

```bash
celestia-appd download-genesis mocha-5
```

Confirm that the downloaded genesis matches the selected network.

```bash
jq -e '.chain_id == "mocha-5"' "$HOME/.celestia-app/config/genesis.json"
```

## Configure connectivity and storage

Save the initial consensus configuration.

```bash
cp -p "$HOME/.celestia-app/config/config.toml" "$HOME/.celestia-app/config/config.toml.before-setup"
```

Open the configuration. Set seeds from the network-specific [Peers and Seeds](/testnet/celestia/services/peers-seeds) page in the existing `[p2p]` section.

```bash
nano "$HOME/.celestia-app/config/config.toml"
```

Keep the RPC listener local unless you are deliberately configuring a public service. In the existing `[rpc]` section, set:

```toml
grpc_laddr = "tcp://127.0.0.1:9098"
```

Choose pruning and enable application gRPC in the existing sections.

```bash
nano "$HOME/.celestia-app/config/app.toml"
```

For a pruned consensus node, start with `pruning = "default"`. Choose `min-retain-blocks` for your role: `3000` is the storage-planning baseline, `600000` is the validator recommendation, and `0` keeps all blocks. A bridge syncing from genesis needs an archival consensus source; use `pruning = "nothing"` and `min-retain-blocks = 0` for a fully archival source.

Edit the existing gRPC section, without duplicating it:

```toml
[grpc]
enable = true
address = "127.0.0.1:9090"
```

Set `minimum-gas-prices` to your operator policy. It controls which transactions your node accepts; it is separate from a transaction's fee flags.

## Run as a service

Create the service file. Replace YOUR\_LINUX\_USER and its home path below.

```bash
sudo nano /etc/systemd/system/celestia-appd.service
```

Paste this service configuration.

```ini
[Unit]
Description=Celestia consensus node
Wants=network-online.target
After=network-online.target

[Service]
User=YOUR_LINUX_USER
ExecStart=/usr/local/bin/celestia-appd start --home /home/YOUR_LINUX_USER/.celestia-app --rpc.grpc_laddr tcp://127.0.0.1:9098
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
```

Load the new service definition.

```bash
sudo systemctl daemon-reload
```

If using a [snapshot](/testnet/celestia/services/snapshots), restore it before starting the new node. Otherwise, the node syncs from genesis, which can take a long time.

Enable startup at boot and start the node.

```bash
sudo systemctl enable --now celestia-appd
```

Inspect recent startup messages.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager
```

Confirm the network, increasing height and recent block time. Wait for catching\_up to become false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {network: .node_info.network, sync: .sync_info}'
```

Source: [Celestia documentation](https://docs.celestia.org/operate/consensus-validators/consensus-node/).


# Server Setup

**Mocha testnet** · Chain ID `mocha-5`

Run these commands on a new Ubuntu 24.04 x86\_64 host, using a regular account with sudo access. Mainnet and testnet guides assume separate hosts. Running both on one host needs distinct homes, services and ports.

Run each block separately and continue only after it succeeds. Names in `YOUR_...` are values you must replace.

## Prepare the host

Confirm that the architecture is x86\_64.

```bash
uname -m
```

Check that glibc is at least 2.38.

```bash
ldd --version
```

Refresh package information.

```bash
sudo apt update
```

Install the tools used in these guides.

```bash
sudo apt install -y curl ca-certificates tar lz4 jq git make nano build-essential clang pkg-config libssl-dev
```

## Install Go for DA source builds

Consensus installation uses a prebuilt release and can skip this section. The commands below use the Go version currently documented by Celestia.

Create a working directory for downloads.

```bash
mkdir -p "$HOME/celestia-downloads"
```

Work in the download directory.

```bash
cd "$HOME/celestia-downloads"
```

Download the pinned Go toolchain from its official site.

```bash
curl -fL --retry 3 -o go1.26.8.linux-amd64.tar.gz https://go.dev/dl/go1.26.8.linux-amd64.tar.gz
```

Download the official release metadata.

```bash
curl -fsS 'https://go.dev/dl/?mode=json&include=all' -o go-releases.json
```

Select the checksum for this exact archive.

```bash
jq -er '.[] | select(.version == "go1.26.8") | .files[] | select(.filename == "go1.26.8.linux-amd64.tar.gz") | "\(.sha256)  \(.filename)"' go-releases.json > go.sha256
```

Verify the archive. Continue only when it reports OK.

```bash
sha256sum --check go.sha256
```

Create a local toolchain parent directory.

```bash
mkdir -p "$HOME/.local/lib"
```

Create a new, empty versioned directory. Stop if it already exists and inspect the existing installation.

```bash
mkdir "$HOME/.local/lib/go1.26.8"
```

Extract Go without replacing a system installation.

```bash
tar -xzf go1.26.8.linux-amd64.tar.gz --strip-components=1 -C "$HOME/.local/lib/go1.26.8"
```

Make the toolchain and user binaries available in this shell.

```bash
export PATH="$HOME/.local/lib/go1.26.8/bin:$HOME/go/bin:$PATH"
```

Confirm the installed version.

```bash
go version
```

For later shell sessions, add the same PATH line to your shell profile. Systemd units below use absolute binary paths.

Source: [Environment setup](https://docs.celestia.org/operate/getting-started/environment-setup/).


# Validator Node

Already running a node? See [Upgrade](/testnet/celestia/validator-node/upgrade).

**Mocha testnet** · Chain ID `mocha-5`

First complete [Consensus Node](/testnet/celestia/consensus-node) and wait until it is synced. Check the CPU benchmark and [Requirements](/testnet/celestia/requirements). From app version 10, bonded validators are expected to run [Fibre](/testnet/celestia/validator-node/fibre) as well.

## Create or recover the operator account

Create a password-protected operator account. Keep the recovery phrase offline.

```bash
celestia-appd keys add validator --keyring-backend file
```

To use an existing account instead, choose the recovery command on [Key Management](/testnet/celestia/useful-commands/key-management); do not create a second key with the same name.

Show the address to fund for self-delegation and transaction fees.

```bash
celestia-appd keys show validator -a --keyring-backend file
```

Show the consensus public key for this node. This is not the operator wallet public key.

```bash
celestia-appd tendermint show-validator
```

## Register the validator

Run `celestia-appd tx staking create-validator --help` on the installed release first. The command below follows Celestia's published flag-based example; if the binary requires a JSON file, use its release-specific format instead.

Choose commission settings deliberately: the maximum rate and maximum rate change constrain later updates. The amounts below are examples, not an active-set entry threshold.

Set a current fee price, including the denomination, for example 0.005utia only if accepted by your endpoint.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

Submit a validator registration with 1 TIA self-delegation. Review the interactive confirmation before broadcasting.

```bash
celestia-appd tx staking create-validator \
  --amount 1000000utia \
  --pubkey "$(celestia-appd tendermint show-validator)" \
  --moniker "YOUR_VALIDATOR_NAME" \
  --commission-rate 0.10 \
  --commission-max-rate 0.20 \
  --commission-max-change-rate 0.01 \
  --min-self-delegation 1000000 \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

Print your validator operator address.

```bash
celestia-appd keys show validator --bech val -a --keyring-backend file
```

Check registration, jailed state and bonding status. A successful transaction does not guarantee entry into the active set.

```bash
celestia-appd query staking validator YOUR_VALOPER_ADDRESS --node http://127.0.0.1:26657 -o json
```

## Protect signing state

Keep the consensus private key and latest signing state backed up securely. Never run the same consensus signing key on two active nodes. For snapshot recovery, preserve your stopped node's signing state; do not replace it with the snapshot provider's state.

Continue with [Fibre](/testnet/celestia/validator-node/fibre) when the active chain version requires it.

Source: [Celestia documentation](https://docs.celestia.org/operate/consensus-validators/validator-node/).


# Upgrade

Update celestia-app and its matching Fibre binary with the existing validator home.

**Mocha testnet** · Chain ID `mocha-5`

Target release: [v10.5.0-mocha](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0-mocha). Recheck [Versions](/testnet/celestia/versions) and the release announcement before starting.

v10.5.0-mocha is a minor update for nodes already running app version 10. Upgrade promptly using the existing home and database. This binary replacement does not schedule a new chain activation. The download section verifies both archives. If you do not run Fibre, skip its backup, installation, configuration and service commands.

This guide uses Ubuntu 24.04, Linux x86\_64 and the systemd paths from [Validator Node](/testnet/celestia/validator-node). Run home-directory commands as the service's Linux user. Adapt service names and binary paths to your deployment.

{% hint style="warning" %}
These commands are for mocha-5. A mocha-4 store cannot be converted to mocha-5 by replacing its binary. For releases older than v10, follow the major-version migration notes first.
{% endhint %}

## Deployment layout

Run node steps on the validator host and Fibre steps on the Fibre host, using the existing service account, home and binary path. On separate hosts, create the download and backup directories on each machine; shell variables do not carry between hosts. Skip Fibre upgrade steps if it has not yet been installed, and follow the [Fibre setup guide](/testnet/celestia/validator-node/fibre).

## 1. Check paths and network

Inspect the running service and its home, user and executable.

```bash
sudo systemctl cat celestia-appd
```

Set the existing home. Change this value if ExecStart uses a different --home.

```bash
APP_HOME="$HOME/.celestia-app"
```

Set the actual Fibre data home on its existing disk. This default must match your Fibre service.

```bash
FIBRE_HOME="$HOME/.celestia-fibre"
```

Print the currently installed binary version.

```bash
/usr/local/bin/celestia-appd version
```

Check the live chain and synchronization state.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {network: .node_info.network, sync: .sync_info}'
```

Read the active app version; it can differ from the installed multiplexer version.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

Continue only on `mocha-5`. Review [Fibre](/testnet/celestia/validator-node/fibre) and the release's major-version notes, including signer compatibility. Keep only one active instance of your consensus signer.

## 2. Download and verify

Select the release for this network.

```bash
APP_VERSION="v10.5.0-mocha"
```

Create a fresh download directory.

```bash
UPGRADE_DIR="$(mktemp -d "$HOME/celestia-app-upgrade.XXXXXX")"
```

Enter the download directory.

```bash
cd "$UPGRADE_DIR"
```

Download the multiplexer archive.

```bash
curl -fL --retry 3 -o celestia-app_Linux_x86_64.tar.gz "https://github.com/celestiaorg/celestia-app/releases/download/$APP_VERSION/celestia-app_Linux_x86_64.tar.gz"
```

Download Fibre from the same release.

```bash
curl -fL --retry 3 -o fibre_Linux_x86_64.tar.gz "https://github.com/celestiaorg/celestia-app/releases/download/$APP_VERSION/fibre_Linux_x86_64.tar.gz"
```

Download the checksum list.

```bash
curl -fL --retry 3 -o checksums.txt "https://github.com/celestiaorg/celestia-app/releases/download/$APP_VERSION/checksums.txt"
```

Select checksums for these two archives.

```bash
awk '$2 == "celestia-app_Linux_x86_64.tar.gz" || $2 == "fibre_Linux_x86_64.tar.gz" {print}' checksums.txt > upgrade.sha256
```

Require exactly two checksum entries. Stop if this fails.

```bash
test "$(wc -l < upgrade.sha256)" -eq 2
```

Verify both downloads. Continue only when both report OK.

```bash
sha256sum --check upgrade.sha256
```

Create separate extraction folders.

```bash
mkdir app-unpack fibre-unpack
```

Extract celestia-app.

```bash
tar -xzf celestia-app_Linux_x86_64.tar.gz -C app-unpack
```

Extract Fibre.

```bash
tar -xzf fibre_Linux_x86_64.tar.gz -C fibre-unpack
```

Locate the executables. Use the exact returned paths below if the archive layout differs.

```bash
find app-unpack fibre-unpack -type f \( -name celestia-appd -o -name fibre \)
```

## 3. Stop and back up

Stop Fibre first **if it is already installed**. Use its actual unit name.

Stop the existing Fibre service; skip this command for a first Fibre installation.

```bash
sudo systemctl stop fibre
```

Stop the consensus process.

```bash
sudo systemctl stop celestia-appd
```

Confirm that the consensus process has exited before copying signing state.

```bash
test "$(systemctl show celestia-appd --property=MainPID --value)" = "0"
```

Create this private backup directory on each host that is being upgraded.

```bash
mkdir -m 0700 "$UPGRADE_DIR/backup"
```

Save the validator configuration and its local keys.

```bash
cp -a "$APP_HOME/config" "$UPGRADE_DIR/backup/config"
```

Save the latest local signing state. For an external signer, use its own state backup procedure instead.

```bash
cp -p "$APP_HOME/data/priv_validator_state.json" "$UPGRADE_DIR/backup/priv_validator_state.json"
```

Keep the previous consensus executable.

```bash
cp -p /usr/local/bin/celestia-appd "$UPGRADE_DIR/backup/celestia-appd"
```

Save existing Fibre configuration; skip if Fibre has not been initialized.

```bash
sudo cp -a "$FIBRE_HOME/config" "$UPGRADE_DIR/backup/fibre-config"
```

Securely back up the existing Fibre TLS certificates and credential files at their configured locations too.

Keep the previous Fibre executable; skip for a first installation or adjust its path.

```bash
cp -p /usr/local/bin/fibre "$UPGRADE_DIR/backup/fibre"
```

Protect this backup: it may contain private keys. For migrations, also take a consistent database/filesystem snapshot while services are stopped. Keep existing Fibre shards and any object-storage namespace accessible.

## 4. Replace binaries and review configuration

Install the verified consensus binary at the service's existing path.

```bash
sudo install -m 0755 app-unpack/celestia-appd /usr/local/bin/celestia-appd
```

Install the matching Fibre executable.

```bash
sudo install -m 0755 fibre-unpack/fibre /usr/local/bin/fibre
```

Confirm the new consensus version.

```bash
/usr/local/bin/celestia-appd version
```

Confirm the matching Fibre version.

```bash
/usr/local/bin/fibre version
```

Preview missing configuration fields. The `--fibre-home` path must exist on this same machine; omit that flag when Fibre runs on another host, and edit its health table on that host using the instructions below.

```bash
/usr/local/bin/celestia-appd config sync --home "$APP_HOME" --fibre-home "$FIBRE_HOME" --dry-run
```

Apply the reviewed additions.

```bash
/usr/local/bin/celestia-appd config sync --home "$APP_HOME" --fibre-home "$FIBRE_HOME"
```

This preserves saved values and skips missing files; it does not update `app.toml` or remote Fibre configuration. Check application gRPC, the existing database backend and retention settings separately. Do not change the database backend as part of a binary replacement.

Set application `[grpc] enable = true` explicitly in `app.toml`. Keep the core gRPC listener used by bridges unchanged. For local Fibre signing, use matching loopback IP addresses, such as `127.0.0.1:26669`, on both services; replace `localhost` with an IP literal. For remote signing, configure mutual TLS according to the [official Fibre guide](https://docs.celestia.org/operate/consensus-validators/fibre/). Keep service flags and configuration files consistent.

### Fibre health configuration

On the Fibre host, edit the existing configuration after making the backup. Keep root-level settings above TOML tables; add this table once, or edit its existing keys.

```bash
sudo nano "$FIBRE_HOME/config/server_config.toml"
```

```toml
[health]
check_interval = "10s"
probe_timeout = "3s"
max_block_age = "2m"
```

These are the release defaults and apply even when the table is absent. Adding the table is recommended for an explicit, reviewable configuration; preserve intentional custom values. `check_interval` controls check frequency, `probe_timeout` bounds each probe, and `max_block_age` bounds the age of the app node’s latest block. Restart Fibre after editing.

### Object storage before restart

If object storage is configured, its `endpoint` must be an absolute `https://` URL with a valid TLS setup. Plain HTTP now fails startup validation. Check the bucket, region, service credentials and bucket-access permissions: Fibre performs a bucket check at startup and stops if it cannot access it.

Keep access to any retained object shards, including after switching new writes back to local storage. Changing an old HTTP endpoint to HTTPS can also change the recorded namespace; review any mismatch using the migration instructions in the Fibre guide before applying an override. Never use an override without verifying access to the same retained objects.

## 5. Restart and verify

Start the existing consensus service.

```bash
sudo systemctl start celestia-appd
```

Check startup errors and block processing.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager
```

Confirm the chain, recent block time, increasing height and catching\_up status.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {network: .node_info.network, sync: .sync_info}'
```

Check validator signing and missed-block metrics as well. Compare height over time; `catching_up: false` alone does not prove progress.

Check activation before starting Fibre.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

Only after the chain reports app version **10 or later**, start an already configured Fibre service. A first installation must complete the [Fibre setup and registration](/testnet/celestia/validator-node/fibre) first.

Start the existing Fibre unit after the activation and configuration checks.

```bash
sudo systemctl start fibre
```

Check Fibre connectivity and storage initialization.

```bash
sudo journalctl -u fibre -n 100 --no-pager
```

After startup, run the [Fibre health and readiness checks](/testnet/celestia/validator-node/fibre#health-and-readiness). Confirm readiness as well as liveness. A new installation may remain not ready until its bonded validator's public Fibre host is registered.

## If the upgrade fails

Stop the failing service and inspect its first error. Do not reset the validator, re-create keys, or restore old signing state after signing newer blocks. A binary downgrade may be incompatible with the migrated database or active chain version; use the release's recovery instructions.

Sources: [Release instructions](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0-mocha), [network upgrades](https://docs.celestia.org/operate/maintenance/network-upgrades/), [Fibre operations](https://docs.celestia.org/operate/consensus-validators/fibre/).


# Fibre

**Mocha testnet · Chain ID `mocha-5` · celestia-app / Fibre v10.5.0-mocha**

Use matching Mocha binaries for your bonded validator and Fibre service. For an existing installation, follow [Validator Upgrade](/testnet/celestia/validator-node/upgrade), preserving the current data home, signing identity, TLS files and stored shards.

For a first installation, follow the [official Fibre setup guide](https://docs.celestia.org/operate/consensus-validators/fibre/) with the **Mocha** network selected and tag `v10.5.0-mocha`. Use a separate Fibre host near the validator, keep its data on separate storage, and size memory and disk for your stake. Keep object storage in the same region.

## Check the validator and release

On the validator host, confirm the chain is mocha-5 and blocks are current.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, sync: .sync_info}'
```

Require active application version 10 or later before starting Fibre.

```bash
curl -fsS http://127.0.0.1:26657/abci_info | jq -r '.result.response.app_version'
```

Check the installed node release.

```bash
celestia-appd version
```

On the Fibre host, require the matching v10.5.0-mocha binary.

```bash
fibre version
```

Fibre connects to application gRPC, normally port `9090`, and the private signing service, normally port `26669`. Explicitly enable application gRPC in `app.toml`. Keep both ports private. A remote signing connection requires mTLS; for same-host plaintext signing, use `127.0.0.1`, not `localhost`. Only the client listener, normally TCP `7980`, needs public reachability.

## Configure health checks

Inspect the existing service to find its data home and flag overrides.

```bash
sudo systemctl cat fibre
```

Set the actual home from ExecStart. Keep the existing path; this example is the default home.

```bash
FIBRE_HOME="$HOME/.celestia-fibre"
```

Before editing, back up the existing configuration. Use a fresh destination if this backup exists.

```bash
sudo cp -a "$FIBRE_HOME/config" "$FIBRE_HOME/config.before-v10.5.0-mocha"
```

Edit the existing file on the Fibre host.

```bash
sudo nano "$FIBRE_HOME/config/server_config.toml"
```

Add this table once, or edit its existing keys. Keep unrelated settings and deliberate custom values.

```toml
[health]
check_interval = "10s"
probe_timeout = "3s"
max_block_age = "2m"
```

These defaults also apply if the table is absent. `check_interval` controls the check frequency, `probe_timeout` bounds each check, and `max_block_age` limits how old the app node’s latest block may be. The [Upgrade guide](/testnet/celestia/validator-node/upgrade) also covers adding missing fields with `celestia-appd config sync`; it can only update files on the host where it runs.

## HTTPS object storage

This is optional when all shards are local. If an object backend is configured, v10.5.0-mocha requires an absolute HTTPS endpoint and checks bucket access at startup. Review the URL, TLS trust, region, bucket and the credentials received by the service before restarting.

Edit the existing `storage_backend` key at the root of the file, before all table headings. Add or edit a single `[object_storage]` table; do not place the root key inside `[health]`.

```toml
storage_backend = "object"

[object_storage]
endpoint = "https://s3.YOUR_REGION.amazonaws.com"
region = "YOUR_REGION"
bucket = "YOUR_BUCKET"
prefix = "fibre"
```

Keep AWS credentials in the service environment, not in this TOML file. Ensure the service can check the bucket and read, write, list and delete its objects. A plaintext HTTP endpoint or failed bucket check prevents Fibre from starting.

Retained object shards still need their original bucket and credentials after switching new writes to local storage. An HTTP-to-HTTPS change can change the recorded namespace: verify the same retained objects remain accessible and follow the [official namespace migration procedure](https://docs.celestia.org/operate/consensus-validators/fibre/#migrate-to-another-bucket) if a mismatch occurs. Do not remove shards or apply an unexplained namespace override.

## Restart and register

After the node is healthy and the configuration is ready, restart the existing Fibre service.

```bash
sudo systemctl restart fibre
```

Check startup, connection and storage errors.

```bash
sudo journalctl -u fibre -n 100 --no-pager -o cat
```

For a first registration, check public reachability from another host.

```bash
nc -vz YOUR_PUBLIC_FIBRE_HOST 7980
```

On the trusted host containing your bonded validator’s operator wallet, select a gas price accepted by your node, including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

Register the reachable public host. Replace the host and wallet name; review the transaction before confirming.

```bash
celestia-appd tx valaddr set-host YOUR_PUBLIC_FIBRE_HOST:7980 \
  --from validator --keyring-backend file --home "$HOME/.celestia-app" \
  --chain-id mocha-5 --node http://127.0.0.1:26657 \
  --gas auto --gas-adjustment 1.5 --gas-prices "$GAS_PRICE"
```

Read the validator’s consensus address.

```bash
celestia-appd comet show-address --home "$HOME/.celestia-app"
```

Use that address to check the registered host.

```bash
celestia-appd query valaddr provider YOUR_VALCONS_ADDRESS --node http://127.0.0.1:26657
```

Require `found: true` and the intended host. An existing correct registration survives upgrades; do not repeat the transaction unless the address changed or the entry was removed.

## Health and readiness

Use `grpc_health_probe` from its [official releases](https://github.com/grpc-ecosystem/grpc-health-probe/releases). The following checks run locally **on the Fibre host** against its TLS listener; adjust the port if yours differs.

Check whether Fibre is ready.

```bash
grpc_health_probe -addr=127.0.0.1:7980 -tls -tls-no-verify
```

Check whether the Fibre process answers, even if a dependency is unavailable.

```bash
grpc_health_probe -addr=127.0.0.1:7980 -tls -tls-no-verify -service=fibre-liveness
```

Expect `SERVING` for both after setup and registration. Readiness may remain `NOT_SERVING` until the validator is bonded, the public host is registered, and the next health check succeeds. Liveness alone does not prove readiness.

These commands skip conventional certificate verification only for a local diagnostic: Fibre uses a validator-endorsed certificate. They do not authenticate a remote validator. Keep this check on loopback; use a Fibre-aware client for remote identity verification.

Readiness checks cover the app connection and recent blocks, signer identity, validator membership, host registration and the local metadata store. A failure is reported in the Fibre log; it does not itself disable uploads or downloads.

Read the failed check and its recovery advice.

```bash
sudo journalctl -u fibre -n 100 --no-pager -o cat
```

The gRPC health service shares port `7980`; no separate HTTP health port is required. An unexpected gRPC server exit now ends the process, so keep a supervisor such as systemd with `Restart=on-failure`.

Readiness does not test external reachability or complete an upload. Continue monitoring the public route and successful endorsements separately.

Sources: [Mocha release](https://github.com/celestiaorg/celestia-app/releases/tag/v10.5.0-mocha) · [Fibre health reference](https://github.com/celestiaorg/celestia-app/blob/v10.5.0-mocha/fibre/cmd/README.md#health) · [Official Fibre guide](https://docs.celestia.org/operate/consensus-validators/fibre/).


# Bridge Node

Already running a node? See [Upgrade](/testnet/celestia/bridge-node/upgrade).

**Mocha testnet** · Chain ID `mocha-5`

A bridge imports consensus data and makes it available to the DA network. Initial sync from genesis needs an archival consensus source; a pruned public endpoint is not sufficient.

Complete [Install celestia-node](/testnet/celestia/bridge-node/install-da) first.

## Choose a consensus connection

For the example below, run your own archival [Consensus Node](/testnet/celestia/consensus-node) on the same host, enable application gRPC at `127.0.0.1:9090`, and let it sync first. Size its storage separately.

Initialize the bridge node store for Mocha testnet. Save any recovery phrase privately.

```bash
celestia bridge init --p2p.network mocha
```

Start the node in the foreground and inspect the connection. Use a bare hostname, without https\://. Add --core.tls only when the endpoint uses TLS.

```bash
celestia bridge start --p2p.network mocha --core.ip 127.0.0.1 --core.port 9090
```

After checking the foreground process, stop it with Ctrl+C before starting the same store under systemd.

## Run as a service

Create the service definition. Replace the Linux user, home and any endpoint placeholders.

```bash
sudo nano /etc/systemd/system/celestia-bridge.service
```

Paste this configuration; retain the same TLS choice used in your successful foreground test.

```ini
[Unit]
Description=Celestia bridge node (Mocha testnet)
Wants=network-online.target
After=network-online.target

[Service]
User=YOUR_LINUX_USER
Environment=HOME=/home/YOUR_LINUX_USER
ExecStart=/home/YOUR_LINUX_USER/go/bin/celestia bridge start --p2p.network mocha --core.ip 127.0.0.1 --core.port 9090
Restart=on-failure
RestartSec=5
LimitNOFILE=1400000

[Install]
WantedBy=multi-user.target
```

Load the new unit.

```bash
sudo systemctl daemon-reload
```

Enable and start the service.

```bash
sudo systemctl enable --now celestia-bridge
```

Check recent logs for successful connections and advancing headers.

```bash
sudo journalctl -u celestia-bridge -n 100 --no-pager
```

List addresses in the default DA key store. The test backend is unencrypted; do not keep a validator treasury in this store.

```bash
cel-key list --node.type bridge --p2p.network mocha --keyring-backend test
```

Open DA P2P port 2121 on both TCP and UDP. Leave pruning enabled unless archival retention is intentional and provisioned.

Source: [Celestia documentation](https://docs.celestia.org/operate/data-availability/bridge-node/).


# Upgrade

Update your Celestia bridge node while keeping its existing store.

**Mocha testnet** · Chain ID `mocha-5`

Target release: [v0.34.3-mocha](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3-mocha). Check [Versions](/testnet/celestia/versions) and the release notes before each upgrade.

This procedure follows the native systemd installation in [Bridge Node](/testnet/celestia/bridge-node). Run commands as the service's Linux user. Keep the same node type, network, keys and data store.

## 1. Check the running installation

Inspect the service user, binary path, network and any custom store flag. If your unit has a different name, use it throughout.

```bash
sudo systemctl cat celestia-bridge
```

Print the currently installed version. The path must match ExecStart; adapt it if your installation differs.

```bash
"$HOME/go/bin/celestia" version
```

Set the existing store path from your service configuration or startup logs. Replace this placeholder before continuing.

```bash
NODE_STORE="/absolute/path/to/your/existing/bridge-store"
```

Confirm that this is an initialized store. Stop if the check fails.

```bash
test -f "$NODE_STORE/config.toml"
```

Check Go. The selected release requires Go 1.26.8 or later; see Server Setup if you need to update it.

```bash
go version
```

## 2. Build the selected release

Build before stopping the node. This does not replace its running binary.

Choose the network-specific release.

```bash
NODE_VERSION="v0.34.3-mocha"
```

Create a fresh working directory.

```bash
UPGRADE_DIR="$(mktemp -d "$HOME/celestia-node-upgrade.XXXXXX")"
```

Download the source for the selected tag.

```bash
git clone --branch "$NODE_VERSION" --depth 1 https://github.com/celestiaorg/celestia-node.git "$UPGRADE_DIR/source"
```

Enter the source directory.

```bash
cd "$UPGRADE_DIR/source"
```

Compile the node binary.

```bash
make build
```

Compile the matching key utility.

```bash
make cel-key
```

## 3. Stop and back up

If multiple services use the same binary, coordinate their maintenance before replacing it. For a release that changes the datastore, take a consistent snapshot of the entire store while stopped. The small backup below covers keys, configuration and the old executable.

Stop this node.

```bash
sudo systemctl stop celestia-bridge
```

Confirm its process has exited. Continue only if this succeeds.

```bash
test "$(systemctl show celestia-bridge --property=MainPID --value)" = "0"
```

Create a private backup directory.

```bash
mkdir -m 0700 "$UPGRADE_DIR/backup"
```

Back up configuration.

```bash
cp -p "$NODE_STORE/config.toml" "$UPGRADE_DIR/backup/config.toml"
```

Back up DA keys. Keep this directory private.

```bash
cp -a "$NODE_STORE/keys" "$UPGRADE_DIR/backup/keys"
```

Keep the previous executable.

```bash
cp -p "$HOME/go/bin/celestia" "$UPGRADE_DIR/backup/celestia"
```

## 4. Install and update configuration

The installation below uses the `$HOME/go/bin` path from our node guide. If ExecStart uses another path, install the binary there instead.

Install the compiled node for this user.

```bash
GOBIN="$HOME/go/bin" make install
```

Install the matching key utility.

```bash
GOBIN="$HOME/go/bin" make install-key
```

Verify the installed release before restarting.

```bash
"$HOME/go/bin/celestia" version
```

Merge new configuration fields into the existing store. This is required when crossing from a version below v0.31.3; review it for every upgrade.

```bash
"$HOME/go/bin/celestia" bridge config-update --p2p.network mocha --node.store "$NODE_STORE"
```

Compare the old and updated configuration. A diff exit code of 1 means differences were found.

```bash
diff -u "$UPGRADE_DIR/backup/config.toml" "$NODE_STORE/config.toml"
```

Check your core endpoint, TLS mode, pruning, RPC authentication and listener addresses. Keep the existing store; do not run `init` or `unsafe-reset-store` as an upgrade step.

## 5. Start and verify

Start the existing unit with its saved flags.

```bash
sudo systemctl start celestia-bridge
```

Check the service state.

```bash
sudo systemctl status celestia-bridge --no-pager
```

Inspect startup and synchronization messages.

```bash
sudo journalctl -u celestia-bridge -n 100 --no-pager
```

Confirm that the core connection succeeds, headers advance, and shares are processed. A running service alone does not prove the node is healthy. Keep the consensus endpoint compatible and available; update a separately operated consensus process through its own maintenance procedure.

If startup fails, stop the service and read the first error. Do not overwrite the store or blindly downgrade after a datastore migration. Retain the backup and follow the release's recovery guidance.

Sources: [Official installation and upgrade instructions](https://docs.celestia.org/operate/data-availability/install-celestia-node/), [configuration update](https://docs.celestia.org/operate/maintenance/troubleshooting/), [release notes](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3-mocha).


# Install celestia-node

**Mocha testnet** · Chain ID `mocha-5`

Complete [Server Setup](/testnet/celestia/consensus-node/server-setup), including Go. This installs the shared binary for light and bridge nodes.

## Build the selected release

Clone the exact network release into a new directory.

```bash
git clone --branch v0.34.3-mocha --depth 1 https://github.com/celestiaorg/celestia-node.git "$HOME/celestia-node-v0.34.3-mocha"
```

Enter the source directory.

```bash
cd "$HOME/celestia-node-v0.34.3-mocha"
```

Build the celestia binary.

```bash
make build
```

Install the binary into your Go binary directory.

```bash
make install
```

Build the DA key utility.

```bash
make cel-key
```

Install the key utility.

```bash
make install-key
```

Confirm the selected version before initializing a node.

```bash
celestia version
```

Continue with [Light Node](/testnet/celestia/light-node) or [Bridge Node](/testnet/celestia/bridge-node).

Source: [Celestia documentation](https://docs.celestia.org/operate/data-availability/install-celestia-node/).


# Light Node

Already running a node? See [Upgrade](/testnet/celestia/light-node/upgrade).

**Mocha testnet** · Chain ID `mocha-5`

A light node samples data availability. It does not become a validator or earn validator rewards by running.

Complete [Install celestia-node](/testnet/celestia/bridge-node/install-da) first.

## Choose a consensus connection

Use an application gRPC endpoint for state queries and transactions. BlockPro publishes a [gRPC hostname](/testnet/celestia/services/endpoints), but its port and TLS mode must be confirmed before using it in this command.

Initialize the light node store for Mocha testnet. Save any recovery phrase privately.

```bash
celestia light init --p2p.network mocha
```

Start the node in the foreground and inspect the connection. Use a bare hostname, without https\://. Add --core.tls only when the endpoint uses TLS.

```bash
celestia light start --p2p.network mocha --core.ip YOUR_CONFIRMED_GRPC_HOST --core.port YOUR_CONFIRMED_GRPC_PORT
```

After checking the foreground process, stop it with Ctrl+C before starting the same store under systemd.

## Run as a service

Create the service definition. Replace the Linux user, home and any endpoint placeholders.

```bash
sudo nano /etc/systemd/system/celestia-light.service
```

Paste this configuration; retain the same TLS choice used in your successful foreground test.

```ini
[Unit]
Description=Celestia light node (Mocha testnet)
Wants=network-online.target
After=network-online.target

[Service]
User=YOUR_LINUX_USER
Environment=HOME=/home/YOUR_LINUX_USER
ExecStart=/home/YOUR_LINUX_USER/go/bin/celestia light start --p2p.network mocha --core.ip YOUR_CONFIRMED_GRPC_HOST --core.port YOUR_CONFIRMED_GRPC_PORT
Restart=on-failure
RestartSec=5
LimitNOFILE=1400000

[Install]
WantedBy=multi-user.target
```

Load the new unit.

```bash
sudo systemctl daemon-reload
```

Enable and start the service.

```bash
sudo systemctl enable --now celestia-light
```

Check recent logs for successful connections and advancing headers.

```bash
sudo journalctl -u celestia-light -n 100 --no-pager
```

List addresses in the default DA key store. The test backend is unencrypted; do not keep a validator treasury in this store.

```bash
cel-key list --node.type light --p2p.network mocha --keyring-backend test
```

Source: [Celestia documentation](https://docs.celestia.org/operate/data-availability/light-node/quickstart/).


# Upgrade

Update your Celestia light node while keeping its existing store.

**Mocha testnet** · Chain ID `mocha-5`

Target release: [v0.34.3-mocha](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3-mocha). Check [Versions](/testnet/celestia/versions) and the release notes before each upgrade.

This procedure follows the native systemd installation in [Light Node](/testnet/celestia/light-node). Run commands as the service's Linux user. Keep the same node type, network, keys and data store.

## 1. Check the running installation

Inspect the service user, binary path, network and any custom store flag. If your unit has a different name, use it throughout.

```bash
sudo systemctl cat celestia-light
```

Print the currently installed version. The path must match ExecStart; adapt it if your installation differs.

```bash
"$HOME/go/bin/celestia" version
```

Set the existing store path from your service configuration or startup logs. Replace this placeholder before continuing.

```bash
NODE_STORE="/absolute/path/to/your/existing/light-store"
```

Confirm that this is an initialized store. Stop if the check fails.

```bash
test -f "$NODE_STORE/config.toml"
```

Check Go. The selected release requires Go 1.26.8 or later; see Server Setup if you need to update it.

```bash
go version
```

## 2. Build the selected release

Build before stopping the node. This does not replace its running binary.

Choose the network-specific release.

```bash
NODE_VERSION="v0.34.3-mocha"
```

Create a fresh working directory.

```bash
UPGRADE_DIR="$(mktemp -d "$HOME/celestia-node-upgrade.XXXXXX")"
```

Download the source for the selected tag.

```bash
git clone --branch "$NODE_VERSION" --depth 1 https://github.com/celestiaorg/celestia-node.git "$UPGRADE_DIR/source"
```

Enter the source directory.

```bash
cd "$UPGRADE_DIR/source"
```

Compile the node binary.

```bash
make build
```

Compile the matching key utility.

```bash
make cel-key
```

## 3. Stop and back up

If multiple services use the same binary, coordinate their maintenance before replacing it. For a release that changes the datastore, take a consistent snapshot of the entire store while stopped. The small backup below covers keys, configuration and the old executable.

Stop this node.

```bash
sudo systemctl stop celestia-light
```

Confirm its process has exited. Continue only if this succeeds.

```bash
test "$(systemctl show celestia-light --property=MainPID --value)" = "0"
```

Create a private backup directory.

```bash
mkdir -m 0700 "$UPGRADE_DIR/backup"
```

Back up configuration.

```bash
cp -p "$NODE_STORE/config.toml" "$UPGRADE_DIR/backup/config.toml"
```

Back up DA keys. Keep this directory private.

```bash
cp -a "$NODE_STORE/keys" "$UPGRADE_DIR/backup/keys"
```

Keep the previous executable.

```bash
cp -p "$HOME/go/bin/celestia" "$UPGRADE_DIR/backup/celestia"
```

## 4. Install and update configuration

The installation below uses the `$HOME/go/bin` path from our node guide. If ExecStart uses another path, install the binary there instead.

Install the compiled node for this user.

```bash
GOBIN="$HOME/go/bin" make install
```

Install the matching key utility.

```bash
GOBIN="$HOME/go/bin" make install-key
```

Verify the installed release before restarting.

```bash
"$HOME/go/bin/celestia" version
```

Merge new configuration fields into the existing store. This is required when crossing from a version below v0.31.3; review it for every upgrade.

```bash
"$HOME/go/bin/celestia" light config-update --p2p.network mocha --node.store "$NODE_STORE"
```

Compare the old and updated configuration. A diff exit code of 1 means differences were found.

```bash
diff -u "$UPGRADE_DIR/backup/config.toml" "$NODE_STORE/config.toml"
```

Check your core endpoint, TLS mode, pruning, RPC authentication and listener addresses. Keep the existing store; do not run `init` or `unsafe-reset-store` as an upgrade step.

## 5. Start and verify

Start the existing unit with its saved flags.

```bash
sudo systemctl start celestia-light
```

Check the service state.

```bash
sudo systemctl status celestia-light --no-pager
```

Inspect startup and synchronization messages.

```bash
sudo journalctl -u celestia-light -n 100 --no-pager
```

Confirm that peers connect, headers advance, and sampling resumes. A running service alone does not prove the node is healthy. Keep the same confirmed gRPC address and TLS settings.

If startup fails, stop the service and read the first error. Do not overwrite the store or blindly downgrade after a datastore migration. Retain the backup and follow the release's recovery guidance.

Sources: [Official installation and upgrade instructions](https://docs.celestia.org/operate/data-availability/install-celestia-node/), [configuration update](https://docs.celestia.org/operate/maintenance/troubleshooting/), [release notes](https://github.com/celestiaorg/celestia-node/releases/tag/v0.34.3-mocha).


# Full Storage Node

**Mocha testnet** · Chain ID `mocha-5`

This page refers to a **DA full storage node** (`celestia full`), not a consensus full node (`celestia-appd`). For a new RPC node, use [Consensus Node](/testnet/celestia/consensus-node).

The current Celestia operator overview lists Light and Bridge as its DA setup paths. Older BlockPro instructions use an earlier full-node release. Keep an existing full-node deployment on its documented upgrade path until its target release and storage migration are confirmed.

Identify the installed DA release.

```bash
celestia version
```

Check whether the installed release exposes the full-node command. An error means this guide must not be used as an installation path.

```bash
celestia full --help
```

Do not change `full` to `bridge` over the same data directory. Use a separate store and a release-specific migration procedure. Full-storage installation commands will be published here after that path has been validated.

Source: [Current node types](https://docs.celestia.org/operate/getting-started/overview/).


# Services

BlockPro infrastructure for this network.

| Service                                                   | What you will find                      |
| --------------------------------------------------------- | --------------------------------------- |
| [Public Endpoints](/testnet/celestia/services/endpoints)  | RPC, REST API, gRPC and explorer        |
| [Peers and Seeds](/testnet/celestia/services/peers-seeds) | Connection addresses and seed setup     |
| [Live Peers](/testnet/celestia/services/live-peers)       | Peer discovery and availability notes   |
| [Addrbook](/testnet/celestia/services/addrbook)           | Download and replacement steps          |
| [Snapshots](/testnet/celestia/services/snapshots)         | Snapshot metadata and restore procedure |


# Public Endpoints

**Mocha testnet** · Chain ID `mocha-5`

## BlockPro endpoints

| Service   | Address                                                         | Use                                    |
| --------- | --------------------------------------------------------------- | -------------------------------------- |
| RPC       | <https://celestia-rpc-testnet.block-pro.net/>                   | Chain status and consensus queries     |
| REST API  | <https://celestia-api-testnet.block-pro.net/>                   | Cosmos SDK REST queries                |
| gRPC host | `celestia-grpc-testnet.block-pro.net`                           | Application gRPC; transport to confirm |
| Explorer  | [Open explorer](https://testnet.block-pro.net/celestia/staking) | Blocks, transactions and validators    |

Addresses are taken from the [existing BlockPro service page](https://service.block-pro.net/testnet/celestia/validator-node/services-or-snapshot). A listing is not a live availability check. The existing page lists `http://celestia-grpc-testnet.block-pro.net:443/`. This mixes a plaintext scheme with port 443; confirm the actual transport before using it. Do not assume TLS or plaintext from this listing alone.

WebSocket: `wss://celestia-rpc-testnet.block-pro.net/websocket`, as listed in the source page.

## Check the network before use

Read the reported network, height and block time.

```bash
curl -fsS --max-time 15 https://celestia-rpc-testnet.block-pro.net/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

The chain must be `mocha-5`. Check that block time is recent and height advances; `catching_up: false` alone does not prove the service is current.

## Usage

Use retry backoff for transient failures. Rate limits, archival coverage and availability commitments have not been published here. For production capacity or private infrastructure, [contact BlockPro](https://t.me/BLOCK_PR0).


# Peers and Seeds

**Mocha testnet** · Chain ID `mocha-5`

| Connection             | BlockPro value                                |
| ---------------------- | --------------------------------------------- |
| Consensus peer         | Not published yet; the existing page says TBD |
| Seed                   | Not published yet                             |
| DA bridge multiaddress | Not published yet                             |

Consensus peers use `node_id@host:port`. DA peers use libp2p multiaddresses. They are not interchangeable.

## Use the official seed list

Download the seed list for this network; stop if the URL does not return a valid list.

```bash
curl -fL --retry 3 -o "$HOME/celestia-seeds.txt" https://raw.githubusercontent.com/celestiaorg/networks/main/mocha-5/seeds.txt
```

Inspect the seed addresses.

```bash
cat "$HOME/celestia-seeds.txt"
```

Format the addresses as a comma-separated value.

```bash
tr '\n' ',' < "$HOME/celestia-seeds.txt" | sed 's/,$//'
```

Set seeds inside the existing \[p2p] section. Add persistent\_peers only for deliberately selected peers.

```bash
nano "$HOME/.celestia-app/config/config.toml"
```

Restart after saving a valid configuration.

```bash
sudo systemctl restart celestia-appd
```

Source: [Celestia documentation](https://docs.celestia.org/operate/consensus-validators/consensus-node/).


# Live Peers

**Mocha testnet** · Chain ID `mocha-5`

A BlockPro Live Peers feed is not published in the current documentation. Do not treat the example below as a hosted feed.

## Inspect connected peers locally

List the node ID, observed IP and advertised listener for peers connected to your own consensus node.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.peers[]? | [.node_info.id, .remote_ip, .node_info.listen_addr] | @tsv'
```

An advertised listener can be private or unreachable. Do not automatically turn this output into persistent peers. A public feed should include a network, a checked-at timestamp and a reachability check for each address.

Use [Peers and Seeds](/testnet/celestia/services/peers-seeds) for initial connectivity.


# Addrbook

**Mocha testnet** · Chain ID `mocha-5`

An address book helps a consensus node discover peers. It does not contain blockchain state and cannot synchronize a node by itself.

Published URL: <https://files.block-pro.net/testnet/celestia/addrbook.json>

The existing service page describes hourly updates; freshness has not been independently confirmed. The original listing contains a double slash before addrbook.json; the address above is normalized and still requires a live check.

## Replace an address book

Download to a temporary file, leaving the current address book untouched.

```bash
curl -fL --retry 3 -o "$HOME/addrbook.download.json" https://files.block-pro.net/testnet/celestia/addrbook.json
```

Check that the downloaded file has an address list. This does not prove reachability or network membership.

```bash
jq -e '.addrs | type == "array"' "$HOME/addrbook.download.json"
```

Stop the node before changing its address book.

```bash
sudo systemctl stop celestia-appd
```

Back up the existing file. Skip only if this is a new node with no addrbook yet.

```bash
cp -p "$HOME/.celestia-app/config/addrbook.json" "$HOME/.celestia-app/config/addrbook.json.backup"
```

Install the downloaded file as the node user.

```bash
install -m 600 "$HOME/addrbook.download.json" "$HOME/.celestia-app/config/addrbook.json"
```

Start the node and check peer connections in the logs.

```bash
sudo systemctl start celestia-appd
```

Source: [BlockPro services](https://service.block-pro.net/testnet/celestia/validator-node/services-or-snapshot).


# Snapshots

**Mocha testnet** · Chain ID `mocha-5`

Restore a **consensus** node from a BlockPro snapshot. This archive is not a light-node or bridge-node snapshot.

| Field                                 | Published information                                          |
| ------------------------------------- | -------------------------------------------------------------- |
| Download                              | <https://files.block-pro.net/testnet/celestia/snapshot/latest> |
| Compression                           | Existing guide uses LZ4                                        |
| Update schedule                       | Existing guide says every 4 hours; freshness unverified        |
| Height and creation time              | Not published                                                  |
| Checksum                              | Not published                                                  |
| DB backend and compatible app version | Not published                                                  |
| Pruning and history coverage          | Not published                                                  |

**Before restoring:** obtain the missing metadata and SHA-256 checksum from BlockPro, confirm chain `mocha-5`, and match the app version and database backend. A snapshot from a different network or an incompatible backend cannot be used. Until this metadata is available, the procedure below is a preparation guide, not a verified restore path.

## Download and inspect

Create a unique staging directory on a disk with enough space for both the archive and extracted data.

```bash
RESTORE_DIR=$(mktemp -d "$HOME/celestia-restore.XXXXXXXX")
```

Download the complete archive. A failed download must not replace your node data.

```bash
curl -fL --retry 3 --output "$RESTORE_DIR/snapshot.tar.lz4" https://files.block-pro.net/testnet/celestia/snapshot/latest
```

Compare this checksum with the independently obtained checksum for this exact snapshot. Stop if no matching checksum is available.

```bash
sha256sum "$RESTORE_DIR/snapshot.tar.lz4"
```

Check the compression stream.

```bash
lz4 --test "$RESTORE_DIR/snapshot.tar.lz4"
```

Inspect archive paths and types. Accept only the agreed data/ layout; stop on absolute paths, parent traversal, links, device files, config/ or key files.

```bash
tar --use-compress-program=lz4 -tvf "$RESTORE_DIR/snapshot.tar.lz4"
```

Create the isolated extraction directory.

```bash
mkdir "$RESTORE_DIR/staged"
```

Extract the inspected, verified archive as the node user, never as root.

```bash
tar --use-compress-program=lz4 --no-same-owner --no-same-permissions -xf "$RESTORE_DIR/snapshot.tar.lz4" -C "$RESTORE_DIR/staged"
```

Confirm the extracted directory is `staged/data/` and matches the published backend. A successful extraction alone does not validate snapshot integrity or provenance.

## Replace data while preserving signing state

For a validator, first ensure no other machine or remote signer is running the same consensus key. Keep the original configuration and keys. The backup below must be made after the node stops.

Stop the node.

```bash
sudo systemctl stop celestia-appd
```

Verify it reports inactive. Do not proceed while the node is running.

```bash
sudo systemctl is-active celestia-appd
```

Preserve your latest signing state. Stop if it is missing on an existing validator.

```bash
cp -p "$HOME/.celestia-app/data/priv_validator_state.json" "$RESTORE_DIR/priv_validator_state.json"
```

Put your own signing state into the staged data, replacing any provider state.

```bash
install -m 600 "$RESTORE_DIR/priv_validator_state.json" "$RESTORE_DIR/staged/data/priv_validator_state.json"
```

Keep the original data for recovery instead of deleting it.

```bash
mv "$HOME/.celestia-app/data" "$RESTORE_DIR/original-data"
```

Install the restored data directory.

```bash
mv "$RESTORE_DIR/staged/data" "$HOME/.celestia-app/data"
```

If this move fails, keep the service stopped and restore `original-data` before taking another action. Do not restart with an incomplete directory.

Start only after the data and signing-state checks pass.

```bash
sudo systemctl start celestia-appd
```

Inspect database, consensus and sync messages.

```bash
sudo journalctl -u celestia-appd -n 100 --no-pager
```

Check the chain, advancing block height, recent block time and catching\_up status.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, sync: .sync_info}'
```

Keep the backup until the restored node is healthy. For validators, never restore an older signing-state file after the restored node has signed new blocks.

Sources: [BlockPro snapshot listing](https://service.block-pro.net/testnet/celestia/validator-node/services-or-snapshot) and [Celestia snapshots](https://docs.celestia.org/operate/maintenance/snapshots/).


# Useful Commands

**Mocha Testnet · `mocha-5`**

Everyday service, key, token and validator operations on one page. Commands use the homes and service names in our installation guides.

Use the `validator` account name and `file` keyring from our setup. Replace address and fee placeholders before use. Transaction confirmation remains interactive. **1 TIA = 1,000,000 utia**; keep additional funds for fees.

## Service operations

### Select service

Choose celestia-appd for consensus, celestia-bridge for bridge, or celestia-light for light nodes.

```bash
SERVICE=celestia-appd
```

### Status

Check the selected systemd service.

```bash
sudo systemctl status "$SERVICE" --no-pager
```

### Start

Start the node.

```bash
sudo systemctl start "$SERVICE"
```

### Stop

Stop the node.

```bash
sudo systemctl stop "$SERVICE"
```

### Restart

Restart after a configuration change.

```bash
sudo systemctl restart "$SERVICE"
```

### Recent logs

Show the last 100 log lines.

```bash
sudo journalctl -u "$SERVICE" -n 100 --no-pager
```

### Follow logs

Follow logs; Ctrl+C leaves the log view.

```bash
sudo journalctl -u "$SERVICE" -f
```

### Sync status

Check consensus height, block time and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

### Peer count

Count consensus peers.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.n_peers'
```

### Free disk space

Check available space.

```bash
df -h "$HOME/.celestia-app"
```

### Data size

Measure consensus data usage.

```bash
du -sh "$HOME/.celestia-app/data"
```

## Key management

These are celestia-app operator accounts. DA keys use `cel-key`; consensus signing keys are separate.

### Create

Create an encrypted operator wallet; store its recovery phrase offline.

```bash
celestia-appd keys add validator --keyring-backend file
```

### Recover

Recover an existing wallet through the interactive prompt.

```bash
celestia-appd keys add validator --recover --keyring-backend file
```

### List

List local operator wallets.

```bash
celestia-appd keys list --keyring-backend file
```

### Account address

Show the account address.

```bash
celestia-appd keys show validator -a --keyring-backend file
```

### Validator address

Show the validator operator address.

```bash
celestia-appd keys show validator --bech val -a --keyring-backend file
```

### Rename

Rename the local key and use the new name in later commands.

```bash
celestia-appd keys rename validator validator-new --keyring-backend file
```

## Tokens

### Set gas price

Replace the placeholder with a gas price accepted by your network, including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Balance

Read an account balance.

```bash
celestia-appd query bank balances YOUR_ACCOUNT_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Send

Send 1 TIA and review the destination before confirming.

```bash
celestia-appd tx bank send validator YOUR_RECIPIENT_ADDRESS 1000000utia \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Delegate

Delegate 1 TIA to the chosen validator.

```bash
celestia-appd tx staking delegate YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Withdraw rewards

Withdraw rewards from the chosen validator.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_VALOPER_ADDRESS \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unbond

Begin undelegating 1 TIA; the network unbonding period applies.

```bash
celestia-appd tx staking unbond YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Transaction status

Check inclusion and execution code; use an indexed endpoint if needed.

```bash
celestia-appd query tx YOUR_TX_HASH --node http://127.0.0.1:26657 -o json
```

## Validator operations

### Details

Inspect status, stake, commission and jailed state.

```bash
celestia-appd query staking validator YOUR_VALOPER_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Consensus public key

Show the local consensus public key.

```bash
celestia-appd tendermint show-validator
```

### Set gas price

Set an accepted gas price including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Edit name

Update the public validator name.

```bash
celestia-appd tx staking edit-validator \
  --new-moniker "YOUR_NEW_NAME" \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Commission and rewards

Withdraw your validator commission and rewards.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_OWN_VALOPER_ADDRESS \
  --commission \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unjail

Use only after fixing the cause of jailing; tombstoned validators cannot unjail.

```bash
celestia-appd tx slashing unjail \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

For initial registration, follow [Validator Node](/testnet/celestia/validator-node).

[CLI reference](https://docs.celestia.org/operate/consensus-validators/cli-reference/) · [Service management](https://docs.celestia.org/operate/maintenance/systemd/)


# Service Operations

**Mocha Testnet · `mocha-5`**

The complete reference is now on [Useful Commands](/testnet/celestia/useful-commands#service-operations).

## Service operations

### Select service

Choose celestia-appd for consensus, celestia-bridge for bridge, or celestia-light for light nodes.

```bash
SERVICE=celestia-appd
```

### Status

Check the selected systemd service.

```bash
sudo systemctl status "$SERVICE" --no-pager
```

### Start

Start the node.

```bash
sudo systemctl start "$SERVICE"
```

### Stop

Stop the node.

```bash
sudo systemctl stop "$SERVICE"
```

### Restart

Restart after a configuration change.

```bash
sudo systemctl restart "$SERVICE"
```

### Recent logs

Show the last 100 log lines.

```bash
sudo journalctl -u "$SERVICE" -n 100 --no-pager
```

### Follow logs

Follow logs; Ctrl+C leaves the log view.

```bash
sudo journalctl -u "$SERVICE" -f
```

### Sync status

Check consensus height, block time and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

### Peer count

Count consensus peers.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.n_peers'
```

### Free disk space

Check available space.

```bash
df -h "$HOME/.celestia-app"
```

### Data size

Measure consensus data usage.

```bash
du -sh "$HOME/.celestia-app/data"
```


# Key Management

**Mocha Testnet · `mocha-5`**

The complete reference is now on [Useful Commands](/testnet/celestia/useful-commands#key-management).

## Key management

These are celestia-app operator accounts. DA keys use `cel-key`; consensus signing keys are separate.

### Create

Create an encrypted operator wallet; store its recovery phrase offline.

```bash
celestia-appd keys add validator --keyring-backend file
```

### Recover

Recover an existing wallet through the interactive prompt.

```bash
celestia-appd keys add validator --recover --keyring-backend file
```

### List

List local operator wallets.

```bash
celestia-appd keys list --keyring-backend file
```

### Account address

Show the account address.

```bash
celestia-appd keys show validator -a --keyring-backend file
```

### Validator address

Show the validator operator address.

```bash
celestia-appd keys show validator --bech val -a --keyring-backend file
```

### Rename

Rename the local key and use the new name in later commands.

```bash
celestia-appd keys rename validator validator-new --keyring-backend file
```


# Tokens

**Mocha Testnet · `mocha-5`**

The complete reference is now on [Useful Commands](/testnet/celestia/useful-commands#tokens).

## Tokens

### Set gas price

Replace the placeholder with a gas price accepted by your network, including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Balance

Read an account balance.

```bash
celestia-appd query bank balances YOUR_ACCOUNT_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Send

Send 1 TIA and review the destination before confirming.

```bash
celestia-appd tx bank send validator YOUR_RECIPIENT_ADDRESS 1000000utia \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Delegate

Delegate 1 TIA to the chosen validator.

```bash
celestia-appd tx staking delegate YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Withdraw rewards

Withdraw rewards from the chosen validator.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_VALOPER_ADDRESS \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unbond

Begin undelegating 1 TIA; the network unbonding period applies.

```bash
celestia-appd tx staking unbond YOUR_VALOPER_ADDRESS 1000000utia \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Transaction status

Check inclusion and execution code; use an indexed endpoint if needed.

```bash
celestia-appd query tx YOUR_TX_HASH --node http://127.0.0.1:26657 -o json
```


# Validator Operations

**Mocha Testnet · `mocha-5`**

The complete reference is now on [Useful Commands](/testnet/celestia/useful-commands#validator-operations).

## Validator operations

### Details

Inspect status, stake, commission and jailed state.

```bash
celestia-appd query staking validator YOUR_VALOPER_ADDRESS --node http://127.0.0.1:26657 -o json
```

### Consensus public key

Show the local consensus public key.

```bash
celestia-appd tendermint show-validator
```

### Set gas price

Set an accepted gas price including the utia denomination.

```bash
GAS_PRICE="YOUR_GAS_PRICE_IN_UTIA"
```

### Edit name

Update the public validator name.

```bash
celestia-appd tx staking edit-validator \
  --new-moniker "YOUR_NEW_NAME" \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Commission and rewards

Withdraw your validator commission and rewards.

```bash
celestia-appd tx distribution withdraw-rewards YOUR_OWN_VALOPER_ADDRESS \
  --commission \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```

### Unjail

Use only after fixing the cause of jailing; tombstoned validators cannot unjail.

```bash
celestia-appd tx slashing unjail \
  --from validator \
  --chain-id mocha-5 \
  --node http://127.0.0.1:26657 \
  --keyring-backend file \
  --gas auto \
  --gas-adjustment 1.5 \
  --gas-prices "$GAS_PRICE"
```


# Troubleshooting

**Mocha testnet** · Chain ID `mocha-5`

| Symptom                               | First check                                                                       |
| ------------------------------------- | --------------------------------------------------------------------------------- |
| Wrong chain or genesis error          | Verify genesis chain\_id is mocha-5; do not reuse the other network's data.       |
| gRPC connection refused               | Confirm application gRPC is enabled and the host, port and TLS mode match.        |
| Bridge cannot find old blocks         | Use an archival consensus source with the required historical coverage.           |
| Service keeps restarting              | Read the first error in journalctl; check binary path, user and file permissions. |
| catching\_up is false but no progress | Compare block timestamps and height with an independent, current source.          |
| Snapshot database error               | Stop the node and check app version, backend and archive layout.                  |
| Insufficient fees                     | Recheck the endpoint's current fee policy and the gas-price denomination.         |
| Full command is unavailable           | Follow the release-specific migration path; do not reuse the store as a bridge.   |

## Ask for help

Include the network, node type, binary version and the relevant error lines. Remove recovery phrases, private keys and authentication tokens before sharing logs.

[Contact BlockPro](https://t.me/BLOCK_PR0) · [Celestia troubleshooting](https://docs.celestia.org/operate/maintenance/troubleshooting/)


# Dora

Dora Vota Testnet: node guides, services and operations.

**Testnet · `vota-testnet` · dorad**

Run a Dora Vota full node and, optionally, register a validator. This guide covers the long-term `vota-testnet` network; do not use it for a different incentivized testnet.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Installation</strong></td><td>Prepare the server and synchronize the node.</td><td><a href="/testnet/dora/installation">Installation</a></td></tr><tr><td><strong>Validator</strong></td><td>Create a wallet and register your validator.</td><td><a href="/testnet/dora/validator">Validator</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Install an approved release and verify recovery.</td><td><a href="/testnet/dora/upgrade">Upgrade</a></td></tr><tr><td><strong>Services</strong></td><td>Endpoints, peers and connection files.</td><td><a href="/testnet/dora/services">Services</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Restore recent chain data step by step.</td><td><a href="/testnet/dora/snapshots">Snapshots</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, keys, tokens and validator operations.</td><td><a href="/testnet/dora/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Requirements

| Resource              | Network recommendation |
| --------------------- | ---------------------- |
| CPU                   | 4 cores, x86-64        |
| RAM                   | 16 GB                  |
| Storage               | 500 GB NVMe or larger  |
| OS used in this guide | Ubuntu 24.04 LTS       |

These are the [official network hardware recommendations](https://docs.dorafactory.org/docs/vota-devops/node). Keep extra disk space for snapshot extraction, backups and chain growth. Use separate servers or fully isolated homes, services and ports for Mainnet and Testnet.

Allow P2P traffic on TCP `26656`. Keep RPC `26657`, REST `1317`, gRPC `9090` and metrics private unless deliberately operating a protected public service.

## Versions

Reference release: **v1.0.0**, source commit `1a2b30927a7799d4cd6890a3fb3fa80d25613fa2`. The [official v1.0.0 release](https://github.com/DoraFactory/doravota/releases/tag/v1.0.0) includes a static Linux amd64 binary.

Read the application version and chain ID before installation or upgrade.

```bash
curl -fsS https://vota-testnet-rest.dorafactory.org/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version, commit: .application_version.git_commit}'
```

A fresh v1.0.0 installation should use a recent **post-upgrade snapshot for vota-testnet**. Historical genesis replay needs the historical binaries and upgrade sequence. Existing 0.5.0 nodes must follow the [Upgrade guide](/testnet/dora/upgrade); a release tag alone is not permission to switch before the network's upgrade boundary.

## Network

| Setting           | Value                  |
| ----------------- | ---------------------- |
| Chain ID          | `vota-testnet`         |
| Binary / service  | `dorad`                |
| Node home         | `$HOME/.dora`          |
| Base denomination | `peaka`                |
| Token precision   | `1 DORA = 10^18 peaka` |

[Official repository](https://github.com/DoraFactory/doravota) · [Explorer](https://vota-testnet-explorer.dorafactory.org) · [Services](/testnet/dora/services)


# Installation

Install and synchronize Dora Testnet, one command at a time.

**Testnet · `vota-testnet` · v1.0.0**

Use a fresh Ubuntu 24.04 x86-64 server and a regular user with sudo access. Run all commands as the same user; the service will use that user's `$HOME/.dora`. Check [requirements](/testnet/dora#requirements) first.

For an existing node, use [Upgrade](/testnet/dora/upgrade). Do not initialize over an existing validator home. A current post-v1.0.0 Testnet snapshot is required for the bootstrap path below; confirm availability on [Snapshots](/testnet/dora/snapshots) before beginning.

## Prepare the server

### Refresh packages

Load the Ubuntu package index.

```bash
sudo apt update
```

### Install utilities

Install tools for downloads, JSON, editing and compressed snapshots.

```bash
sudo apt install -y ca-certificates curl jq lz4 tar nano less
```

### Check architecture

Continue with this release asset only when the output is x86\_64.

```bash
uname -m
```

## Install the binary

### Download v1.0.0

Save the official static Linux amd64 binary.

```bash
curl -fL https://github.com/DoraFactory/doravota/releases/download/v1.0.0/dorad-v1.0.0-linux-amd64 -o "$HOME/dorad-v1.0.0"
```

### Verify SHA-256

Expect OK. Stop if the checksum fails.

```bash
echo "5c741ca406ee2ecb811dd62d83e9a446fee051e2947522525c2560a0a7ce968a  $HOME/dorad-v1.0.0" | sha256sum -c -
```

### Install dorad

Install the verified executable. No Go compiler or libwasmvm shared library is needed.

```bash
sudo install -m 0755 "$HOME/dorad-v1.0.0" /usr/local/bin/dorad
```

### Check the binary

Confirm v1.0.0 and the source commit shown on the project overview.

```bash
dorad version --long
```

## Initialize the node

### Set a moniker

Choose the public name of this node.

```bash
read -rp "Node moniker: " MONIKER
```

### Initialize a new home

Create fresh configuration and node identity. Run once on a new server.

```bash
dorad init "$MONIKER" --chain-id vota-testnet --home "$HOME/.dora"
```

### Download genesis

Use the official network genesis pinned to the release tag.

```bash
curl -fL https://raw.githubusercontent.com/DoraFactory/doravota/v1.0.0/config/testnet/genesis.json -o "$HOME/.dora/config/genesis.json"
```

### Verify genesis

Expect OK. Stop on a mismatch.

```bash
echo "0ef9f538bd642ef6f23dccba4a98e3fb455542a7cde96f77c003c6bc53a08b5d  $HOME/.dora/config/genesis.json" | sha256sum -c -
```

### Confirm the chain ID

The result must be vota-testnet.

```bash
jq -r .chain_id "$HOME/.dora/config/genesis.json"
```

### Set the minimum gas price

Set a local mempool fee floor in peaka; this is not a fixed transaction fee.

```bash
sed -i 's/^minimum-gas-prices *=.*/minimum-gas-prices = "100000000000peaka"/' "$HOME/.dora/config/app.toml"
```

### Set a discovery seed

Use the ITRocket seed for this network.

```bash
sed -i 's|^seeds *=.*|seeds = "dcf2d8132162293de52ca474eee308a03689ef75@dora-testnet-seed.itrocket.net:39656"|' "$HOME/.dora/config/config.toml"
```

### Set a persistent peer

Add the separately operated ITRocket peer.

```bash
sed -i 's|^persistent_peers *=.*|persistent_peers = "7aee4cf9104234dfb41d138e40cd499160b68772@dora-testnet-peer.itrocket.net:45656"|' "$HOME/.dora/config/config.toml"
```

### Review network exposure

Keep RPC on 127.0.0.1:26657 and statesync disabled for snapshot restoration. In app.toml, keep API/gRPC disabled or bound to loopback.

```bash
nano "$HOME/.dora/config/config.toml" "$HOME/.dora/config/app.toml"
```

Allow inbound TCP 26656 in your host and provider firewalls. Preserve your actual SSH port and administrative access when changing firewall rules.

## Create the service

### Create the systemd unit

Run as the same non-root user used for initialization. The command records this user's actual name and home.

```bash
sudo tee /etc/systemd/system/dorad.service > /dev/null <<EOF
[Unit]
Description=Dora Vota Testnet
Wants=network-online.target
After=network-online.target

[Service]
User=$(whoami)
WorkingDirectory=$HOME
ExecStart=/usr/local/bin/dorad start --home $HOME/.dora
Restart=on-failure
RestartSec=10
LimitNOFILE=65535
TimeoutStopSec=300

[Install]
WantedBy=multi-user.target
EOF
```

### Reload systemd

Load the new unit without starting it.

```bash
sudo systemctl daemon-reload
```

## Restore and start

Follow [Snapshots](/testnet/dora/snapshots) to restore a recent **vota-testnet snapshot created after the v1.0.0 migration**. Do not start v1.0.0 against an empty database and assume it can replay the entire historical chain. Keep the configuration and identity created above.

### Enable and start

Run only after the snapshot restore has completed successfully.

```bash
sudo systemctl enable --now dorad
```

### Follow logs

Check peers, successful block processing and any errors. Ctrl+C exits the log view without stopping the node.

```bash
sudo journalctl -u dorad -f -o cat
```

### Verify synchronization

Confirm the correct network, a current block time and catching\_up=false. Compare height with an independent public RPC.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

Continue to [Validator](/testnet/dora/validator) only after the node is fully synchronized.

[Official node guide](https://docs.dorafactory.org/docs/vota-devops/node) · [v1.0.0 release](https://github.com/DoraFactory/doravota/releases/tag/v1.0.0) · [ITRocket network reference](https://itrocket.space/services/testnet/dora/installation/)


# Validator

Create and maintain a Dora Testnet validator.

**Testnet · `vota-testnet` · v1.0.0**

Complete [Installation](/testnet/dora/installation) and wait for full synchronization. These examples use a local key named `wallet` with the encrypted `file` keyring. Transactions ask for confirmation; review the destination, amount and fee before signing.

Never run the same consensus key on two nodes. Keep `config/priv_validator_key.json`, the latest `data/priv_validator_state.json` and wallet recovery words in secure backups.

## Prepare the wallet

### Create a wallet

Record the recovery words privately and offline. Do not share the output or store it in a public document.

```bash
dorad keys add wallet --keyring-backend file --home "$HOME/.dora"
```

Already have a wallet? Use [Key management](/testnet/dora/useful-commands#key-management) to restore it instead of creating another key.

### Show the account address

Use this address to fund the wallet.

```bash
dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora"
```

Request Testnet tokens from the [official faucet](https://vota-testnet-faucet.dorafactory.org). Testnet tokens have no Mainnet value.

### Check the balance

Amounts are returned in base units. 1 DORA equals 1000000000000000000 peaka.

```bash
dorad query bank balances "$(dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

### Confirm synchronization

Require the correct network, a current block time and catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

## Register the validator

The v1.0.0 CLI uses a **JSON definition file** with `create-validator`. Old examples that pass every field directly as a flag are not the format used here.

### Choose a public moniker

Set your validator's display name.

```bash
read -rp "Validator moniker: " MONIKER
```

### Choose the self-delegation amount

Enter an amount with its base denomination, for example 1000000000000000000peaka for 1 DORA. Leave funds for fees; this example is not an active-set minimum.

```bash
read -rp "Self-delegation amount (integer followed by peaka): " SELF_DELEGATION
```

### Write the validator definition

Read your node's public consensus key and create the JSON file. Commission values below are examples: 10% initially, 20% maximum, 1 percentage point maximum change per day.

```bash
jq -n \
  --argjson pubkey "$(dorad comet show-validator --home "$HOME/.dora")" \
  --arg amount "$SELF_DELEGATION" --arg moniker "$MONIKER" \
  '{pubkey:$pubkey, amount:$amount, moniker:$moniker, identity:"", website:"", security:"", details:"", "commission-rate":"0.10", "commission-max-rate":"0.20", "commission-max-change-rate":"0.01", "min-self-delegation":"1"}' > "$HOME/validator.json"
```

### Review the definition

Edit identity, website, security contact and details as needed. Commission maximums cannot be freely changed later; min-self-delegation is expressed in peaka.

```bash
nano "$HOME/validator.json"
```

### Create the validator

Simulate gas and review the transaction before confirming. A successful broadcast is not yet proof of on-chain success.

```bash
dorad tx staking create-validator "$HOME/validator.json" --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Inspect the transaction

Replace TX\_HASH with the hash returned after broadcast. Wait for inclusion and confirm the transaction succeeded.

```bash
dorad query tx TX_HASH --node http://127.0.0.1:26657 --output json
```

### Read validator status

Check jailed status, self-delegation and whether the validator is bonded.

```bash
dorad query staking validator "$(dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

Joining the active set depends on the network's validator limit and stake ranking. Registration alone does not guarantee block-signing status. Use [Useful Commands](/testnet/dora/useful-commands) for delegation, rewards and unjailing.

[Official validator guide](https://docs.dorafactory.org/docs/vota-devops/validator) · [v1.0.0 operator notes](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md)


# Upgrade

Upgrade Dora Testnet at the approved boundary and verify recovery.

**Testnet · `vota-testnet` · v1.0.0**

This guide targets v1.0.0; confirm the live network version with the command below. An already healthy v1.0.0 node does not need to repeat the migration.

The official upgrade path is **0.5.0 → v1.0.0** at the approved governance boundary. A node still catching up on 0.5.0 must reach the recorded `UPGRADE "v1.0.0" NEEDED` boundary before a manual binary switch. Confirm the plan and height from the network announcement and on-chain record; this guide does not invent an upgrade height.

New nodes should follow [Installation](/testnet/dora/installation) and restore a recent post-upgrade [snapshot](/testnet/dora/snapshots).

## Before changing the binary

### Read your version

Check which binary is currently installed.

```bash
dorad version --long
```

### Read the network version

Verify the application version and chain ID reported by the public API.

```bash
curl -fsS https://vota-testnet-rest.dorafactory.org/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

### Read a pending upgrade plan

A completed plan may no longer appear here. For an offline or halted node, use its upgrade record and the official network announcement.

```bash
dorad query upgrade plan --node http://127.0.0.1:26657 --output json
```

### Inspect the effective service

Identify the actual binary, home and any ExecStart overrides. Commands below target the manual service from our installation guide.

```bash
sudo systemctl cat dorad
```

### Inspect halt settings

Ensure app.toml uses halt-height=0 and no obsolete service flag forces a different halt.

```bash
grep -nE '^halt-height|^halt-time' "$HOME/.dora/config/app.toml"
```

Back up the current configuration, binary and a consistent database before migration. Retain the latest validator signing state and any external Wasm bytecode needed for historical research. Never run two copies of the consensus key.

## Prepare the verified binary

### Download the release

Stage the file without replacing the running executable.

```bash
curl -fL https://github.com/DoraFactory/doravota/releases/download/v1.0.0/dorad-v1.0.0-linux-amd64 -o "$HOME/dorad-v1.0.0"
```

### Verify SHA-256

Expect OK. Stop on a mismatch.

```bash
echo "5c741ca406ee2ecb811dd62d83e9a446fee051e2947522525c2560a0a7ce968a  $HOME/dorad-v1.0.0" | sha256sum -c -
```

### Make the staged file executable

Apply executable permissions to the verified file.

```bash
chmod 0755 "$HOME/dorad-v1.0.0"
```

### Check the staged version

Expect v1.0.0 and commit 1a2b30927a7799d4cd6890a3fb3fa80d25613fa2.

```bash
"$HOME/dorad-v1.0.0" version --long
```

## Manual service upgrade

Proceed only when your 0.5.0 node has reached the correct migration boundary. For other source versions, first follow the intervening official upgrade sequence. Run these commands as the same user that owns the node home.

### Stop the service

Stop the supervisor before replacing the binary or copying live database files.

```bash
sudo systemctl stop dorad
```

### Confirm shutdown

Expect inactive. Stop any other process using this same home.

```bash
sudo systemctl is-active dorad
```

### Name the backup directory

Keep this shell open for the following steps.

```bash
DORA_UPGRADE_BACKUP="$HOME/dora-upgrade-backup-$(date +%Y%m%d-%H%M%S)"
```

### Create private backup storage

Ensure sufficient free space for a complete copy of the node home.

```bash
install -d -m 0700 "$DORA_UPGRADE_BACKUP"
```

### Back up the stopped node

Preserve configuration, consistent data and latest signing state together.

```bash
cp -a "$HOME/.dora" "$DORA_UPGRADE_BACKUP/home"
```

### Preserve the old executable

Keep it for investigation; do not restart it against migrated state.

```bash
cp -a /usr/local/bin/dorad "$DORA_UPGRADE_BACKUP/dorad-previous"
```

### Install v1.0.0

Replace the executable only after all preceding checks and backups succeed.

```bash
sudo install -m 0755 "$HOME/dorad-v1.0.0" /usr/local/bin/dorad
```

### Start the node

Resume with the existing home and signing state.

```bash
sudo systemctl start dorad
```

### Check logs

Confirm migration completes and blocks advance beyond the upgrade boundary.

```bash
sudo journalctl -u dorad -f -o cat
```

## Cosmovisor installations

Use this branch only if you already operate Cosmovisor. The plan name and directory are **v1.0.0**, including the `v`. Do not also perform the manual executable replacement above.

### Set the daemon home

Use the exact home configured in your Cosmovisor service; this example matches our guides.

```bash
export DAEMON_HOME="$HOME/.dora"
```

### Create the upgrade directory

Prepare the exact directory name required by the approved plan.

```bash
mkdir -p "$DAEMON_HOME/cosmovisor/upgrades/v1.0.0/bin"
```

### Stage the verified executable

Place the previously verified binary in the upgrade directory.

```bash
install -m 0755 "$HOME/dorad-v1.0.0" "$DAEMON_HOME/cosmovisor/upgrades/v1.0.0/bin/dorad"
```

### Verify the staged checksum

Confirm the actual executable Cosmovisor will select.

```bash
echo "5c741ca406ee2ecb811dd62d83e9a446fee051e2947522525c2560a0a7ce968a  $DAEMON_HOME/cosmovisor/upgrades/v1.0.0/bin/dorad" | sha256sum -c -
```

Stage before the approved height and let Cosmovisor switch at the chain's upgrade event. If the switch fails, stop the supervisor and follow the [official recovery procedure](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md); do not delete data or reset signing state.

## Verify recovery

### Read the installed version

For a manual service, expect v1.0.0. For Cosmovisor, inspect its selected current binary too.

```bash
dorad version --long
```

### Check node progress

Confirm the correct chain, increasing height and eventually catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

Validators should verify they resume signing. Compare AppHash with an independent node at the **same height**. Never restart 0.5.0 against migrated v1.0.0 data or restore an old signing-state file after new blocks have been signed.

## v1.0.0 compatibility notes

* The binary is static; no libwasmvm shared library is needed.
* Live Wasm execution and smart queries are removed. Historical raw contract state is exposed through `wasm-archive` where the data is retained.
* Bank transfers, staking and ordinary IBC transfers remain supported; the release does not repair expired IBC clients.
* New accounts can use the full uint64 account-number range. Update wallet/indexer integrations accordingly, and look up a transaction hash before retrying after a client-side decoding error.

[Official v1.0.0 upgrade guide](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md) · [Release and checksums](https://github.com/DoraFactory/doravota/releases/tag/v1.0.0)


# Services

Official endpoints and community connection resources for Dora Testnet.

**Testnet · `vota-testnet`**

Official public endpoints for Dora Vota Testnet. BlockPro Testnet endpoints have not been listed. Public endpoints are shared infrastructure; use your own node for workloads that require dedicated capacity.

## Public endpoints

| Service  | Provider     | Address                                                                                 |
| -------- | ------------ | --------------------------------------------------------------------------------------- |
| RPC      | Dora Factory | [https://vota-testnet-rpc.dorafactory.org](https://vota-testnet-rpc.dorafactory.org/)   |
| REST API | Dora Factory | [https://vota-testnet-rest.dorafactory.org](https://vota-testnet-rest.dorafactory.org/) |

Use the checks below to confirm the network, application version and synchronization state before relying on an endpoint.

### Check RPC health

Read the chain, height, last block time and synchronization flag.

```bash
curl -fsS https://vota-testnet-rpc.dorafactory.org/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

### Check application version

The application version is different from the CometBFT version shown by RPC.

```bash
curl -fsS https://vota-testnet-rest.dorafactory.org/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

## Peers and seeds

The following connection details are published by [ITRocket](https://itrocket.space/services/testnet/dora/). They are community services, not BlockPro endpoints.

**Seed**

```bash
dcf2d8132162293de52ca474eee308a03689ef75@dora-testnet-seed.itrocket.net:39656
```

**Persistent peer**

```bash
7aee4cf9104234dfb41d138e40cd499160b68772@dora-testnet-peer.itrocket.net:45656
```

Add these to `seeds` and `persistent_peers` in `$HOME/.dora/config/config.toml`. See [Installation](/testnet/dora/installation) for the exact commands.

## Live peers

Querying net\_info requires the RPC provider to expose that endpoint. Reachability and peer addresses can change.

### Inspect local peers

Read peer IDs and advertised listening addresses from your synchronized node.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r '.result.peers[] | [.node_info.id, .node_info.listen_addr, .remote_ip] | @tsv'
```

Use a peer's verified public P2P address. An HTTP RPC hostname, a loopback address or a private advertised address is not automatically a usable P2P endpoint.

## Addrbook

Optional community addrbook: [ITRocket download](https://server-2.itrocket.net/testnet/dora/addrbook.json). Use only the file for **vota-testnet** and stop the service before replacing your local address book.

### Download a candidate

Save separately so a failed download cannot replace the current file.

```bash
curl -fL https://server-2.itrocket.net/testnet/dora/addrbook.json -o "$HOME/addrbook-dora.json"
```

### Validate JSON

Check the downloaded file before using it.

```bash
jq -e . "$HOME/addrbook-dora.json" > /dev/null
```

### Stop the node

Stop the process before replacing the address book.

```bash
sudo systemctl stop dorad
```

### Install the addrbook

Keep a numbered backup when an addrbook already exists.

```bash
cp --backup=numbered "$HOME/addrbook-dora.json" "$HOME/.dora/config/addrbook.json"
```

### Start the node

Restart and check peer connections.

```bash
sudo systemctl start dorad
```

## Snapshots

Use the ITRocket Testnet snapshot service. A BlockPro Testnet snapshot has not been listed.

[Snapshot restore guide](/testnet/dora/snapshots) · [Explorer](https://vota-testnet-explorer.dorafactory.org) · [Official faucet](https://vota-testnet-faucet.dorafactory.org)


# Snapshots

Restore Dora Testnet data while preserving your validator identity.

**Testnet · `vota-testnet` · v1.0.0**

Restore recent chain data while keeping your own node configuration and validator identity. First install the binary and create the service using [Installation](/testnet/dora/installation).

## Availability

[ITRocket Testnet snapshots](https://itrocket.space/services/testnet/dora/#snapshots) publishes a pruned snapshot. Its published interval is four hours. Read the current metadata for the archive height, size and block time before downloading.

BlockPro Testnet snapshots have not been listed.

Choose a snapshot for **vota-testnet**, taken after this network's **v1.0.0 migration**, with a database backend compatible with your node. Do not use the old 0.4.x examples in historical tutorials.

The metadata below identifies ITRocket's current archive; use the matching filename on its service page.

```bash
curl -fsS https://server-2.itrocket.net/testnet/dora/.current_state.json | jq '{file: .snapshot_name, height: .snapshot_height, size: .snapshot_size, block_time: .snapshot_block_time, database: .db_backend}'
```

## Download and inspect

Use the same account and home directory as the node service. Ensure you have room for the compressed archive, extracted data and a copy of your current database. These steps expect a **tar.lz4 archive containing a top-level data directory**. If the provider uses another layout or compression format, adapt to its documented layout before continuing.

Do not restore a snapshot while another node is signing with the same validator key. Keep your latest local signing state; never use a provider's signing state in its place.

### Set the archive URL

Copy the actual current download URL from the selected provider.

```bash
read -rp "Current Dora Testnet .tar.lz4 URL: " SNAPSHOT_URL
```

### Download the archive

Stop on download errors and do not continue with a partial file.

```bash
curl -fL --retry 3 "$SNAPSHOT_URL" -o "$HOME/dora-snapshot.tar.lz4"
```

### Test compression

Check the LZ4 stream before extraction. If the provider publishes a checksum, compare that too; this test alone does not authenticate a provider.

```bash
lz4 -t "$HOME/dora-snapshot.tar.lz4"
```

### Inspect archive paths

Confirm relative paths under data/. Reject absolute paths, parent-directory traversal and unexpected links. The procedure imports only data, not another operator's config or keys.

```bash
tar -I lz4 -tf "$HOME/dora-snapshot.tar.lz4" | less
```

### Create a staging directory

Extract outside the active node home.

```bash
DORA_RESTORE=$(mktemp -d "$HOME/dora-restore.XXXXXX")
```

### Extract the archive

Run as the node user, without sudo. Do not extract directly over the live home.

```bash
tar -I lz4 -xf "$HOME/dora-snapshot.tar.lz4" -C "$DORA_RESTORE" --no-same-owner --no-same-permissions
```

### Confirm the expected layout

Continue only if data/ exists at the staging root. If it does not, stop and follow the provider's documented archive layout.

```bash
test -d "$DORA_RESTORE/data"
```

## Preserve local identity and state

### Stop the service

Wait until the node has stopped before taking the final signing-state backup.

```bash
sudo systemctl stop dorad
```

### Check that the service is stopped

Expect inactive. Also stop any separate supervisor or manual process using this home.

```bash
sudo systemctl is-active dorad
```

### Create a private backup directory

Keep this shell open so the backup variable remains available.

```bash
DORA_BACKUP="$HOME/dora-backup-$(date +%Y%m%d-%H%M%S)"
```

### Restrict backup access

Create the directory with permissions limited to your user.

```bash
install -d -m 0700 "$DORA_BACKUP"
```

### Back up configuration

Preserve your own genesis, node key and validator key.

```bash
cp -a "$HOME/.dora/config" "$DORA_BACKUP/config"
```

### Back up the latest signing state

This must succeed. If the file is missing on a previously active validator, stop and recover its latest state before proceeding.

```bash
cp -a "$HOME/.dora/data/priv_validator_state.json" "$DORA_BACKUP/priv_validator_state.json"
```

### Preserve the current database

Move rather than delete the old data directory. The service must stay stopped.

```bash
mv "$HOME/.dora/data" "$DORA_BACKUP/data"
```

## Restore and verify

### Install the restored data

Move only the inspected data directory into the node home.

```bash
mv "$DORA_RESTORE/data" "$HOME/.dora/data"
```

### Restore your signing state

Overwrite the snapshot's signing state with your own latest local state before starting.

```bash
cp -a "$DORA_BACKUP/priv_validator_state.json" "$HOME/.dora/data/priv_validator_state.json"
```

Your config directory stays in place. Preserve any existing external `wasm/` bytecode for historical research; v1.0.0 no longer runs the Wasm runtime, so this guide does not replace that directory from a provider archive.

### Check snapshot settings

Keep statesync enable=false in config.toml when restoring an archive, and confirm the database backend matches the provider metadata. Do not change unrelated enable fields.

```bash
nano "$HOME/.dora/config/config.toml" "$HOME/.dora/config/app.toml"
```

### Start the service

Start only after successful restoration and ownership checks. The files should belong to the service account.

```bash
sudo systemctl start dorad
```

### Read startup logs

Check for database, version or network errors.

```bash
sudo journalctl -u dorad -n 100 --no-pager -o cat
```

### Check synchronization

Confirm chain vota-testnet, a current block time and catching\_up=false after catch-up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

Compare the height and block hash at the same height with an independent [public RPC](/testnet/dora/services). Keep backups until recovery is verified. Do not restore an older signing-state file after this node has signed new blocks.

[Official v1.0.0 state-preservation notes](https://github.com/DoraFactory/doravota/blob/v1.0.0/docs/VALIDATOR-1.0.0.md)


# Useful Commands

Everyday Dora Testnet service, wallet and validator commands.

**Testnet · `vota-testnet` · dorad**

Commands match the [Installation](/testnet/dora/installation) guide: service `dorad`, home `$HOME/.dora`, key `wallet` and local RPC `http://127.0.0.1:26657`. Replace uppercase placeholders before running a command.

Amounts use `peaka`: **1 DORA = 1000000000000000000 peaka**. Transaction commands estimate gas and ask for confirmation.

## Service operations

### Start the node

Start the systemd service.

```bash
sudo systemctl start dorad
```

### Stop the node

Stop the service cleanly.

```bash
sudo systemctl stop dorad
```

### Restart the node

Restart after an approved configuration change.

```bash
sudo systemctl restart dorad
```

### Service status

Show whether the node is active.

```bash
sudo systemctl status dorad --no-pager -l
```

### Follow logs

Stream logs. Ctrl+C exits the view.

```bash
sudo journalctl -u dorad -f -o cat
```

### Check version

Read the installed application release and commit.

```bash
dorad version --long
```

### Check synchronization

Verify network, latest block and catching\_up.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result | {chain: .node_info.network, height: .sync_info.latest_block_height, time: .sync_info.latest_block_time, catching_up: .sync_info.catching_up}'
```

### Count connected peers

Show the local P2P peer count.

```bash
curl -fsS http://127.0.0.1:26657/net_info | jq -r .result.n_peers
```

### Show node ID

Read your public P2P identity.

```bash
dorad comet show-node-id --home "$HOME/.dora"
```

## Key management

Store wallet recovery words privately. Use the restore command only for a wallet you own, and enter the phrase interactively.

### Create a wallet

Create the encrypted wallet key.

```bash
dorad keys add wallet --keyring-backend file --home "$HOME/.dora"
```

### Restore a wallet

Recover an existing key from its mnemonic.

```bash
dorad keys add wallet --recover --keyring-backend file --home "$HOME/.dora"
```

### List keys

List locally stored public key information.

```bash
dorad keys list --keyring-backend file --home "$HOME/.dora"
```

### Show account address

Read the address used for balances and transfers.

```bash
dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora"
```

### Show validator address

Read the operator address used for staking queries.

```bash
dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora"
```

## Tokens

### Check balance

Query token balances in base units.

```bash
dorad query bank balances "$(dorad keys show wallet -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

### Send tokens

Replace RECIPIENT and AMOUNTpeaka. Verify the recipient and amount before confirming.

```bash
dorad tx bank send wallet RECIPIENT AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Delegate

Replace VALIDATOR\_ADDRESS with a valoper address and set the amount.

```bash
dorad tx staking delegate VALIDATOR_ADDRESS AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Withdraw rewards

Withdraw delegation rewards from the selected validator.

```bash
dorad tx distribution withdraw-rewards VALIDATOR_ADDRESS --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Redelegate

Move a delegation between validators, subject to network redelegation rules.

```bash
dorad tx staking redelegate SOURCE_VALIDATOR DESTINATION_VALIDATOR AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Unbond tokens

Begin the unbonding period; tokens are not immediately spendable.

```bash
dorad tx staking unbond VALIDATOR_ADDRESS AMOUNTpeaka --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Check a transaction

Wait for inclusion, then inspect the result before repeating a transfer.

```bash
dorad query tx TX_HASH --node http://127.0.0.1:26657 --output json
```

## Validator operations

Use [Validator](/testnet/dora/validator) for initial registration. Investigate the reason for jailing before attempting to unjail.

### Validator status

Read staking status and jailed state.

```bash
dorad query staking validator "$(dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora")" --node http://127.0.0.1:26657 --output json
```

### Consensus public key

Read the public key; do not expose priv\_validator\_key.json.

```bash
dorad comet show-validator --home "$HOME/.dora"
```

### Signing information

List slashing/signing records and find your consensus address.

```bash
dorad query slashing signing-infos --node http://127.0.0.1:26657 --output json
```

### Withdraw commission and rewards

Withdraw for your own validator operator address.

```bash
dorad tx distribution withdraw-rewards "$(dorad keys show wallet --bech val -a --keyring-backend file --home "$HOME/.dora")" --commission --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Edit validator details

Replace the example display name; change only the fields you intend.

```bash
dorad tx staking edit-validator --new-moniker "YOUR_MONIKER" --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Unjail

Run only after fixing downtime and meeting the chain's unjailing conditions. Tombstoned validators cannot be unjailed.

```bash
dorad tx slashing unjail --from wallet --keyring-backend file --home "$HOME/.dora" --chain-id vota-testnet --node http://127.0.0.1:26657 --gas auto --gas-adjustment 1.5 --gas-prices 100000000000peaka
```

### Check staking parameters

Read validator limits, denomination and the unbonding time.

```bash
dorad query staking params --node http://127.0.0.1:26657 --output json
```

### Check the upgrade plan

Read a scheduled plan before changing the binary.

```bash
dorad query upgrade plan --node http://127.0.0.1:26657 --output json
```

[Upgrade guide](/testnet/dora/upgrade) · [Official repository](https://github.com/DoraFactory/doravota)


# Lava

Lava Testnet: node guides, services and operations.

**Testnet · `lava-testnet-2` · lavad**

Run the Lava consensus node and, optionally, register a validator. RPC-provider operations use a different workflow.

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Installation</strong></td><td>Prepare the server and start syncing.</td><td><a href="/testnet/lava/installation">Installation</a></td></tr><tr><td><strong>Validator</strong></td><td>Create a wallet and register your validator.</td><td><a href="/testnet/lava/validator">Validator</a></td></tr><tr><td><strong>Upgrade</strong></td><td>Replace the binary and verify recovery.</td><td><a href="/testnet/lava/upgrade">Upgrade</a></td></tr><tr><td><strong>Services</strong></td><td>BlockPro endpoints and connection files.</td><td><a href="/testnet/lava/services">Services</a></td></tr><tr><td><strong>Snapshots</strong></td><td>Restore recent chain data step by step.</td><td><a href="/testnet/lava/snapshots">Snapshots</a></td></tr><tr><td><strong>Useful Commands</strong></td><td>Service, keys, tokens and validator operations.</td><td><a href="/testnet/lava/useful-commands">Useful Commands</a></td></tr></tbody></table>

## Requirements

| Resource | Minimum            | Recommended          |
| -------- | ------------------ | -------------------- |
| CPU      | 4 vCPU, x64, 2 GHz | 4+ vCPU              |
| RAM      | 8 GB               | 16 GB+               |
| Storage  | 100 GB SSD         | 512 GB SSD or larger |
| OS       | Ubuntu 20+         | Ubuntu 24.04 LTS     |

The official storage figures are starting points. Check the current snapshot size and keep room for extraction and chain growth. [Hardware source](https://docs.lavanet.xyz/reqs/).

Allow inbound P2P on TCP `26656`. Keep RPC `26657`, REST `1317` and gRPC `9090` private unless you are deliberately operating a protected public service. Use a separate server for each network.

## Versions

Reference release: [`v6.2.5`](https://github.com/lavanet/lava/releases/tag/v6.2.5). GitHub also lists newer prereleases; they are not a mainnet upgrade instruction. Lava’s installation tutorial still uses v5.2.0, so confirm the active chain version and any scheduled upgrade before choosing a binary.

Read the version reported by the network before installation or upgrade; this response is live and is not cached in this guide.

```bash
curl -fsS https://lava-api-testnet.block-pro.net/cosmos/base/tendermint/v1beta1/node_info | jq '{chain: .default_node_info.network, version: .application_version.version}'
```

If the endpoint is unavailable, confirm the active release with the project’s official validator announcements. Do not guess from the highest GitHub tag.

[Official documentation](https://docs.lavanet.xyz/testnet-manual-cosmovisor/) · [Source code](https://github.com/lavanet/lava)


# Installation

Install and synchronize Lava Testnet, one command at a time.

**Testnet · `lava-testnet-2` · Ubuntu 24.04 / x86-64**

Use a normal Linux account with sudo access. Commands assume a new node and the same shell session. Existing operators should use [Upgrade](/testnet/lava/upgrade).

### 1. Prepare packages

Refresh package metadata.

```bash
sudo apt update
```

### Install dependencies

Install download, build and snapshot tools.

```bash
sudo apt install -y ca-certificates curl jq git make build-essential golang-go lz4 tar
```

## Install the binary

### Select a release

Use the network-approved release. This pinned stable release is the reference, not an automatic upgrade decision.

```bash
LAVA_VERSION=v6.2.5
```

### Download lavad

Download the Linux amd64 release asset.

```bash
curl -fL "https://github.com/lavanet/lava/releases/download/$LAVA_VERSION/lavad-$LAVA_VERSION-linux-amd64" -o "$HOME/lavad.download"
```

### Check the download

For v6.2.5, this must print OK. A different release needs its own published checksum.

```bash
printf "%s  %s\n" e500f73102264a48818ab5ecc1350bf54d663d6d3a4bfb45d9a85833d2b1fded "$HOME/lavad.download" | sha256sum -c -
```

### Install

Place the verified executable in the system path.

```bash
sudo install -m 0755 "$HOME/lavad.download" /usr/local/bin/lavad
```

### Verify the binary

Confirm the selected version starts successfully.

```bash
lavad version --long
```

## Initialize and connect

### Initialize once

Replace MY\_NODE with your own moniker. Do not rerun this over an existing validator home.

```bash
lavad init "MY_NODE" --chain-id lava-testnet-2
```

### Download genesis

Save network genesis to the node configuration.

```bash
curl -fL https://raw.githubusercontent.com/Shoni-O/files/main/testnet-files/lava/genesis.json -o "$HOME/.lava/config/genesis.json"
```

### Verify the network

Continue only if the file is valid JSON and this check returns true.

```bash
jq -e '.chain_id == "lava-testnet-2"' "$HOME/.lava/config/genesis.json"
```

### Download the address book

Load BlockPro’s published peer discovery file.

```bash
curl -fL https://raw.githubusercontent.com/Shoni-O/files/main/testnet-files/lava/addrbook.json -o "$HOME/.lava/config/addrbook.json"
```

### Check the address book

Ensure the download contains peer records, not an HTML error page.

```bash
jq -e '.addrs | type == "array"' "$HOME/.lava/config/addrbook.json"
```

### Set minimum gas prices

Set this node’s local transaction admission policy.

```bash
sed -i 's/^minimum-gas-prices *=.*/minimum-gas-prices = "0ulava"/' "$HOME/.lava/config/app.toml"
```

### Set a persistent peer

Use the BlockPro peer published for this network.

```bash
sed -i 's|^persistent_peers *=.*|persistent_peers = "3690cf931dd6b2c49e49f781e5163e3acf7f4767@lava-rpc-testnet.block-pro.net:61156"|' "$HOME/.lava/config/config.toml"
```

### Use bounded pruning

Keep the application’s standard pruning policy; archive operation needs more disk space.

```bash
sed -i 's/^pruning *=.*/pruning = "default"/' "$HOME/.lava/config/app.toml"
```

### Apply Lava consensus timing

Apply the timings from the official joining guide.

```bash
sed -i -e 's/^timeout_commit *=.*/timeout_commit = "30s"/' -e 's/^timeout_propose *=.*/timeout_propose = "1s"/' -e 's/^timeout_precommit *=.*/timeout_precommit = "1s"/' -e 's/^timeout_prevote *=.*/timeout_prevote = "1s"/' -e 's/^timeout_propose_delta *=.*/timeout_propose_delta = "500ms"/' -e 's/^timeout_precommit_delta *=.*/timeout_precommit_delta = "500ms"/' -e 's/^timeout_prevote_delta *=.*/timeout_prevote_delta = "500ms"/' -e 's/^skip_timeout_commit *=.*/skip_timeout_commit = false/' "$HOME/.lava/config/config.toml"
```

## Run with systemd

### Create the service

Run the node as the current non-root account, with automatic restart after a process failure.

```bash
sudo tee /etc/systemd/system/lavad.service > /dev/null <<EOF
[Unit]
Description=Lava Testnet node
After=network-online.target
Wants=network-online.target

[Service]
User=$(id -un)
WorkingDirectory=$HOME/.lava
ExecStart=/usr/local/bin/lavad start --home $HOME/.lava
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target
EOF
```

### Load the unit

Tell systemd about the new service.

```bash
sudo systemctl daemon-reload
```

### Enable on boot

Enable the service without starting it yet.

```bash
sudo systemctl enable lavad
```

### Restore recent state

Follow [Snapshots](/testnet/lava/snapshots) before starting. The current binary may not replay every historical upgrade from genesis. Choose a snapshot compatible with the installed release.

### Start

Start the node after restoration.

```bash
sudo systemctl start lavad
```

### Follow logs

Look for advancing blocks; Ctrl+C leaves the service running.

```bash
sudo journalctl -u lavad -f -o cat
```

### Check synchronization

Wait for catching\_up to become false and compare the height with the explorer.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

Next: [Validator](/testnet/lava/validator) or [Useful Commands](/testnet/lava/useful-commands).

[Upstream reference](https://docs.lavanet.xyz/testnet-manual-cosmovisor/).


# Validator

Create and maintain a Lava validator on Testnet.

**Testnet · `lava-testnet-2`**

Complete [Installation](/testnet/lava/installation) and wait for full synchronization. The wallet key authorizes transactions; the consensus key signs blocks. Back up both securely, and never run two nodes with the same consensus key.

### Create a wallet

Save the recovery phrase offline. Use the recovery command instead if you already have a wallet.

```bash
lavad keys add wallet
```

### Recover an existing wallet — alternative

Enter the recovery phrase interactively.

```bash
lavad keys add wallet --recover
```

### Show the funding address

Fund this address on the correct network and leave a balance for fees.

```bash
lavad keys show wallet -a
```

### Check balance

Read the funded account balance.

```bash
lavad query bank balances "$(lavad keys show wallet -a)"
```

### Check synchronization

Continue only after catching\_up is false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info.catching_up'
```

### Back up the consensus key

Create a local protected backup, then copy it to secure offline storage.

```bash
install -D -m 0600 "$HOME/.lava/config/priv_validator_key.json" "$HOME/validator-backup/lava-testnet-priv_validator_key.json"
```

### Check create-validator syntax

Inspect the release’s CLI before submitting. The formats below differ between older and newer Cosmos SDK releases.

```bash
lavad tx staking create-validator --help
```

### Register the validator

Choose the format shown by your binary’s help. Replace the moniker and amount, then review the transaction before confirming. The sample stake is not a promise of entry into the active set.

```bash
lavad tx staking create-validator \
  --amount 50000000ulava \
  --pubkey "$(lavad tendermint show-validator)" \
  --moniker "MY_VALIDATOR" \
  --commission-rate 0.10 --commission-max-rate 0.20 \
  --commission-max-change-rate 0.01 --min-self-delegation 10000 \
  --from wallet --chain-id lava-testnet-2 --gas auto --gas-adjustment 1.5 --gas-prices 0.05ulava
```

### Verify registration

Query the validator record after the transaction is included in a block.

```bash
lavad query staking validator "$(lavad keys show wallet --bech val -a)"
```

Registration and active voting power are different states. Check bonded status and the active-set threshold in the explorer.

[Validator reference](https://docs.lavanet.xyz/validator-manual/).


# Upgrade

Upgrade Lava safely and confirm the node resumes syncing.

**Testnet · `lava-testnet-2`**

This procedure uses the direct `lavad.service` created by our installation guide. If your service uses Cosmovisor, stage the binary under the exact on-chain upgrade plan name instead of replacing its symlink.

{% hint style="warning" %}
For a scheduled chain upgrade, prepare the binary in advance and switch only at the announced height. For a compatible patch, follow the project’s release instructions. Do not skip database migrations or start an old binary against upgraded state.
{% endhint %}

### Check the service

Confirm its executable and home before changing anything.

```bash
systemctl cat lavad
```

### Check the upgrade plan

Read any scheduled on-chain upgrade.

```bash
lavad query upgrade plan -o json
```

### Prepare the new binary

Use the binary download/build steps in [Installation](/testnet/lava/installation), but stage the result as `$HOME/lavad.next` and do not install it over the running executable yet. Select the release announced for `lava-testnet-2`.

### Select the approved target

v6.2.5 is the reviewed stable reference; change it only to the release authorized for your network.

```bash
LAVA_VERSION=v6.2.5
```

### Download to a staging path

This leaves the current service binary intact.

```bash
curl -fL "https://github.com/lavanet/lava/releases/download/$LAVA_VERSION/lavad-$LAVA_VERSION-linux-amd64" -o "$HOME/lavad.next"
```

### Verify v6.2.5

Use the checksum belonging to the chosen release.

```bash
printf "%s  %s\n" e500f73102264a48818ab5ecc1350bf54d663d6d3a4bfb45d9a85833d2b1fded "$HOME/lavad.next" | sha256sum -c -
```

### Make executable

Allow checking the staged binary.

```bash
chmod 0755 "$HOME/lavad.next"
```

### Check the staged version

Resolve missing libraries or a wrong release before downtime.

```bash
"$HOME/lavad.next" version --long
```

### Stop at the correct time

Stop the one active signer before switching binaries.

```bash
sudo systemctl stop lavad
```

### Back up configuration and signing state

Keep the signing state from this stopped node. Store a full stopped database backup as well if the release requires one.

```bash
tar -czf "$HOME/lava-testnet-upgrade-$(date +%Y%m%d-%H%M%S).tar.gz" -C "$HOME/.lava" config data/priv_validator_state.json
```

### Keep the previous binary

Retain a copy for diagnostics; database migrations may prevent a simple binary rollback.

```bash
cp /usr/local/bin/lavad "$HOME/lavad.previous"
```

### Replace the binary

Install the staged executable.

```bash
sudo install -m 0755 "$HOME/lavad.next" /usr/local/bin/lavad
```

### Start

Start the node with the upgraded binary.

```bash
sudo systemctl start lavad
```

### Inspect logs

Check for migration errors and advancing heights.

```bash
sudo journalctl -u lavad -n 100 -f -o cat
```

### Confirm sync

Check height and catching\_up after the node recovers.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

[Release history](https://github.com/lavanet/lava/releases).


# Services

BlockPro endpoints and peer discovery for Lava Testnet.

**Testnet · `lava-testnet-2`**

## Public endpoints

| Service  | Address                                                |
| -------- | ------------------------------------------------------ |
| RPC      | <https://lava-rpc-testnet.block-pro.net>               |
| REST API | <https://lava-api-testnet.block-pro.net>               |
| Explorer | [Testnet explorer](https://testnet.block-pro.net/lava) |

These addresses are carried over from BlockPro’s existing service directory. Availability is not a live status indicator.

## Persistent peer

```
3690cf931dd6b2c49e49f781e5163e3acf7f4767@lava-rpc-testnet.block-pro.net:61156
```

## Connection files

| File         | Download                                                                                               |
| ------------ | ------------------------------------------------------------------------------------------------------ |
| Genesis      | [genesis.json](https://raw.githubusercontent.com/Shoni-O/files/main/testnet-files/lava/genesis.json)   |
| Address book | [addrbook.json](https://raw.githubusercontent.com/Shoni-O/files/main/testnet-files/lava/addrbook.json) |

### Inspect the live RPC

Check the network ID, peer identity and sync status.

```bash
curl -fsS https://lava-rpc-testnet.block-pro.net/status | jq '.result | {node_info, sync_info}'
```

### Live peers

List peers reported by the public RPC, if net\_info is enabled. Verify reachability before using an address.

```bash
curl -fsS https://lava-rpc-testnet.block-pro.net/net_info | jq -r '.result.peers[]? | "\(.node_info.id)@\(.remote_ip):\(.node_info.listen_addr | split(":") | last)"'
```

Snapshot download and restore instructions: [Snapshots](/testnet/lava/snapshots).


# Snapshots

Restore Lava Testnet chain data without losing your validator identity.

**Testnet · `lava-testnet-2` · `.lava`**

Provider: KJ Nodes, linked by Lava’s official testnet guide. This is a third-party snapshot, not a BlockPro-hosted file.

[Download snapshot](https://snapshots.kjnodes.com/lava-testnet/snapshot_latest.tar.lz4). Allow space for the compressed file, extracted data and the previous database.

{% hint style="warning" %}
This procedure replaces chain data. Keep config, keyring and validator keys. For an existing validator, preserve its latest priv\_validator\_state.json while stopped; never restore another validator’s signing state. Do not start a second signer during recovery.
{% endhint %}

### Download first

Download before stopping the node to reduce downtime.

```bash
curl -fL --retry 3 https://snapshots.kjnodes.com/lava-testnet/snapshot_latest.tar.lz4 -o "$HOME/lava-snapshot.tar.lz4"
```

### Test compression

Stop if the compressed archive is corrupt.

```bash
lz4 -t "$HOME/lava-snapshot.tar.lz4"
```

### Inspect paths

Check that entries are chain data, with no absolute paths or .. components. Choose strip-components based on the actual archive layout.

```bash
tar -I lz4 -tf "$HOME/lava-snapshot.tar.lz4" | head -40
```

### Stop

Stop the service before changing its data.

```bash
sudo systemctl stop lavad
```

### Back up signing state

Keep the latest state from your own stopped node.

```bash
cp -p "$HOME/.lava/data/priv_validator_state.json" "$HOME/.lava/priv_validator_state.json.before-snapshot"
```

### Keep the previous database

Rename the data directory. Use a fresh backup name if this path already exists.

```bash
mv "$HOME/.lava/data" "$HOME/.lava/data.before-snapshot"
```

### Extract chain data

Use this layout only when the archive lists data/... directly. Adapt the strip count if the provider changes the structure.

```bash
tar -I lz4 -xf "$HOME/lava-snapshot.tar.lz4" -C "$HOME/.lava" --strip-components=0
```

### Restore your signing state

Overwrite the snapshot’s signing state with your own backup.

```bash
cp -p "$HOME/.lava/priv_validator_state.json.before-snapshot" "$HOME/.lava/data/priv_validator_state.json"
```

### Start

Start only after the data directory layout is correct.

```bash
sudo systemctl start lavad
```

### Verify recovery

Compare height and time with the explorer; wait for catching\_up=false.

```bash
curl -fsS http://127.0.0.1:26657/status | jq '.result.sync_info'
```

Keep the previous database until the restored node is healthy. A snapshot is trusted input; a locally calculated checksum alone does not authenticate its provider.




---

[Next Page](https://service.block-pro.net/llms-full.txt/1)