- 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
| Profile | CPU | Memory | NVMe | Network |
|---|---|---|---|---|
| Non-archival bridge | 32 cores | 64 GB | 25 TiB | 1 Gbps |
| Archival bridge | 32 cores | 64 GB | 637 TiB | 1 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
2121on TCP and UDP. - Keep DA JSON-RPC
26658on 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.
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.
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
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
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:
- Official v0.34.2-mocha release, Fibre namespace and core v10 dependency
- Pinned celestia-node go.mod (Go 1.26.8)
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-requirementsoperate/data-availability/bridge-nodeoperate/data-availability/install-celestia-nodeoperate/networks/mocha-testnetoperate/maintenance/troubleshooting