MushCrypto
Node Docs
MushCrypto
Node Docs
No jargon left unexplained, no step skipped because it seemed obvious. This is the guide we wished existed when we set up our first node.
Celestia has three kinds of node, and they trade off resources for how much of the network they can independently verify. Pick based on what you're actually trying to do — running the heaviest one "to be safe" is usually wasted resources.
Downloads small random samples of each block to confirm data is available, without downloading the whole block. Runs on a laptop. This is what makes Celestia's data availability sampling work at all — the more of these running, the stronger the network's guarantee.
Sits between the consensus network (celestia-app) and the data availability network (celestia-node). Downloads full blocks from consensus, re-serves them as samples to light nodes. Needs a synced consensus node to point at.
Like a bridge node, but keeps historical block data around instead of only recent blocks — the long-term archival layer for the DA network.
All three run the same celestia-node binary — you choose the type with the subcommand:
celestia light start, celestia bridge start, or celestia full start.
Requirements scale with node type. This is a starting point, not a hard ceiling — mainnet storage needs grow over time as more data gets published.
2121) —
NAT'd home connections work for light nodes, but a bridge/full node behind strict NAT will struggle to
peer reliably.The fastest way to actually participate in the network. Ten minutes, most of which is the binary downloading.
The --core.ip flag points your light node at a consensus RPC to fetch headers from — you can
use a public one to get started, or your own if you're already running a validator.
Check the logs for sampling messages advancing block height, or query the node's own RPC
(see RPC & metrics below) for sync status.
Same binary, different subcommand and a heavier resource footprint — plan storage and RAM before you start, not after disk fills up.
Unlike a light node, a bridge node needs its own consensus node (celestia-app) fully synced
and reachable — it's re-serving real block data, not just sampling it. If you already run a
Celestia validator, point it at that node's gRPC endpoint.
A node that silently stops on a crash or reboot is worse than no node — you'll think you're contributing to network sampling when you're not. Wrap it in a real service.
Run it as a dedicated non-root user, not directly as root — same reasoning as any other
long-running network service.
A node with no observability is a node you find out is broken from someone else, days later.
The node exposes a JSON-RPC endpoint (default port 26658) you can query for sync state,
peer count, and header height — point your own monitoring at it rather than trusting the process is
healthy just because it's still running.
At minimum, alert on: process not running, RPC not responding, and header height not advancing for more than a few minutes — that last one catches a node that's "up" but silently stuck.
Check that your P2P port is actually reachable from outside your network, not just bound locally — a surprising number of "no peers" reports turn out to be router/firewall NAT issues, not the node itself.
For a light node, confirm the --core.ip target is itself synced and reachable — a light node
can only be as current as the consensus RPC it's pulling headers from.
Expected for full storage nodes — that's the archival tradeoff. For a bridge node, check you're not accidentally running it in full-storage mode; the pruning behavior differs between the two.
MsgPayForBlobs transaction.celestia-node software.