posthuman - nodes
Celestia
Celestia websiteCelestia githubCelestia twitterCelestia discord

Celestia

type:
testnet
chain id:
mocha-5
rpc:
https://celestia-testnet-rpc.itrocket.net
rest:
https://celestia-testnet-api.itrocket.net
snapshots:
https://server-6.itrocket.net/testnet/celestia/
  • installation guide
  • bridge node setup
  • full node setup
  • operating boundaries
  • multiplexer
  • fibre
  • skill
  • light node setup
  • monitoring
  • keys
  • validator signaling
  • blobstream orchestrator
  • storage optimization
  • snapshots

Celestia Mocha-5 Bridge Node

A bridge node is the heavy data-availability (DA) role. It imports blocks from an archival consensus source, validates and erasure-codes them, and serves shares to the DA network. Current celestia-node DA roles are bridge and light only.

Operational scope and Fibre boundary

Informational guide: POSTHUMAN does not operate a Celestia Bridge or Light node. The templates below describe a separately approved deployment, not existing POSTHUMAN infrastructure. Updating this guide enables no service, port, firewall rule, key, escrow, or transaction.

v0.34.2-mocha adds a built-in Fibre client and the fibre JSON-RPC namespace on Bridge and Light nodes. The namespace includes Submit, Upload, Download, Deposit, Withdraw, QueryEscrowAccount, and PendingWithdrawals. Fibre needs a configured Mocha core endpoint running celestia-app v10 with x/fibre and x/valaddr; it is unavailable without a core endpoint. Installing a v10 wrapper before activation does not mean these v10 modules are active.

The Mocha-5 app target is v10.2.0-mocha, activation height 1082619; see App upgrade and rollback boundaries. This is not a mainnet version recommendation. Fibre/escrow activation requires a separate operator decision covering custody, funding, exposure and provider dependencies. Do not call Submit/Upload/Deposit/Withdraw, fund escrow, enable signer gRPC, or infer Fibre availability from DA health checks in this guide.

Network and software pins

  • Consensus chain ID: mocha-5
  • DA P2P network: mocha
  • celestia-node: v0.34.2-mocha
  • Source commit: cd6cd46f00a572a7010fecc7e0dacf8a456982d2
  • Go: 1.26.8
  • Store: $HOME/.celestia-bridge-mocha-5

Mocha-5 started from height 1 and is not an in-place upgrade from Mocha-4. Never reuse a Mocha-4 DA store, consensus data directory, or signer-state file. Do not install from an unpinned branch or pipe a remote script into a shell.

Capacity and CPU gate

ProfileCPUMemoryNVMeNetwork
Non-archival bridge32 cores64 GB25 TiB1 Gbps
Archival bridge32 cores64 GB637 TiB1 Gbps

These official planning profiles use a conservative 7-day window for non-archival operation and one year for archival operation, both at the 128 MB per 6 seconds maximum-throughput envelope. Actual use may be lower. Maintain at least one month of maximum-throughput capacity as free space.

Run the official celestia-app CPU benchmark before provisioning. Prefer at least 32 cores with GFNI and SHA-NI support; core count alone is not proof of sufficient throughput.

Network prerequisites

  • Initial bridge sync requires an archival Mocha-5 celestia-app consensus gRPC source with complete history from height 1. A pruned endpoint and any Mocha-4 endpoint are invalid.
  • Expose DA P2P port 2121 on TCP and UDP.
  • Keep DA JSON-RPC 26658 on loopback unless it is deliberately protected by authentication, TLS, and rate limits.
  • Verify the endpoint chain ID, archival retention, firewall policy, storage, and clock synchronization before initialization.

Build from the pinned source

Install Go 1.26.8 and build dependencies from trusted distribution channels, then verify the toolchain.

go version test "$(go env GOVERSION)" = "go1.26.8" NODE_TAG="v0.34.2-mocha" NODE_COMMIT="cd6cd46f00a572a7010fecc7e0dacf8a456982d2" BUILD_ROOT="$(mktemp -d -p /tmp celestia-node-build.XXXXXX)" git clone --filter=blob:none --depth 1 --branch "$NODE_TAG" \ https://github.com/celestiaorg/celestia-node.git "$BUILD_ROOT/src" test "$(git -C "$BUILD_ROOT/src" rev-parse HEAD)" = "$NODE_COMMIT" make -C "$BUILD_ROOT/src" build cel-key install -d "$BUILD_ROOT/stage/bin" install -m 0755 "$BUILD_ROOT/src/build/celestia" \ "$BUILD_ROOT/stage/bin/celestia" install -m 0755 "$BUILD_ROOT/src/cel-key" \ "$BUILD_ROOT/stage/bin/cel-key" "$BUILD_ROOT/stage/bin/celestia" version

Keep staging until the reported version and commit are reviewed. For a new, non-running node, install the reviewed staged binaries at $HOME/.local/bin/. Binary activation and service restart are separate approval-controlled steps.

Initialize a new Mocha-5 store

First verify the proposed consensus source is on mocha-5 and retains every block required for initial sync.

celestia-appd status --node <consensus-rpc-url> | \ jq -e '.NodeInfo.network == "mocha-5"' "$HOME/.local/bin/celestia" bridge init \ --node.store "$HOME/.celestia-bridge-mocha-5" \ --core.ip <archival-mocha-5-consensus-grpc-host> \ --core.port <grpc-port> \ --core.tls \ --p2p.network mocha

Add --core.tls only for a TLS endpoint. Initialization creates the new DA store and local keyring. Do not copy any Mocha-4 directory into this store. Follow Keys and signer boundaries for custody rules.

Review the generated config and confirm mocha, the Mocha-5 upstream, and the loopback JSON-RPC bind before starting.

Service template

[Unit] Description=Celestia Mocha-5 bridge node After=network-online.target Wants=network-online.target [Service] Type=simple User=<service-user> ExecStart=%h/.local/bin/celestia bridge start --node.store %h/.celestia-bridge-mocha-5 --core.ip <archival-mocha-5-consensus-grpc-host> --core.port <grpc-port> --core.tls --p2p.network mocha Restart=on-failure RestartSec=5 LimitNOFILE=65535 [Install] WantedBy=multi-user.target

Do not add --archival until the 637 TiB profile, retention objective, and capacity alerting have been approved. Decide before the store's first start. The previously reviewed v0.32.1 behavior refused conversion from a previously pruned store back to archival mode. If archival retention is later required, provision and verify a separate new Mocha-5 store; do not reset or delete the working store.

Verify

systemctl is-active celestia-bridge-mocha-5.service "$HOME/.local/bin/celestia" header sync-state \ --node.store "$HOME/.celestia-bridge-mocha-5" "$HOME/.local/bin/celestia" p2p info \ --node.store "$HOME/.celestia-bridge-mocha-5" ss -lntup | grep -E '(:2121|:26658)' journalctl -u celestia-bridge-mocha-5.service \ --since "15 minutes ago" --no-pager

Healthy means the service is stable, headers advance toward an independent Mocha-5 reference, peers are present, 2121 is reachable on TCP and UDP, 26658 is not public, and disk has headroom. Any Mocha-4 chain identity is a hard failure.

Upgrade discipline

Verify the announced Mocha tag and commit, build in a new staging directory, retain rollback, and activate only after review. When crossing from a release before v0.31.3, run celestia bridge config-update --p2p.network mocha --node.store "$HOME/.celestia-bridge-mocha-5" while stopped, inspect the merged configuration, then restart and repeat all checks.

Sources

Release and toolchain reviewed 2026-09-23:

Capacity and general role guidance below retain their historical documentation provenance; they are not a new benchmark of Fibre workloads.

Evidence reviewed from the official Celestia docs repository at commit 8fbaa868a323c13d3edae2875d9b27765eb29c45:

  • operate/getting-started/hardware-requirements
  • operate/data-availability/bridge-node
  • operate/data-availability/install-celestia-node
  • operate/networks/mocha-testnet
  • operate/maintenance/troubleshooting