Run a node

Running your own node is how you take part in a market without trusting anyone's word for it: your node validates every block, every settlement and every Bitcoin fact carried into consensus, and it needs no permission from anyone to join. A market builder, a provider or a plain user who runs a node verifies every settlement themselves — nobody has to be asked, and nobody can be asked to look away.

The public testnet is live. A published seed node and a fixed genesis are available, and a fresh node can join with only the seed address — no RPC access and no operator address are needed. There is no mainnet. This is experimental software with a disposable-genesis testnet.

Join the public testnet

mkdir -p ~/.bathron
printf 'testnet=1\n[test]\naddnode=57.131.33.151\n' > ~/.bathron/bathron.conf
bathrond -testnet -daemon
bathron-cli -testnet getblockhash 0
# expected:
# 691b0a7e8cb0e7ee159ef7a4fa10d9c6ddb2d5282e5bac7447846459ff54c730
bathron-cli -testnet getblockcount   # syncs to the network tip

RPC is loopback-only by default. Operator addresses are deliberately not published; the seed above is the only endpoint needed to join.

Build from source

On Debian/Ubuntu:

sudo apt-get install -y build-essential libtool autotools-dev automake pkg-config \
    libssl-dev libevent-dev bsdmainutils python3 libboost-all-dev libsodium-dev libzmq3-dev

./autogen.sh
./configure --without-gui --disable-tests --disable-bench
make -j$(nproc)

This produces two binaries:

Run

bathrond -testnet -daemon

The node stores its data in ~/.bathron/. Configuration goes in ~/.bathron/bathron.conf (peers, RPC credentials). Pre-built binaries for tagged releases are published on the bathron-core releases page.

Verify

bathron-cli -testnet getblockcount        # chain height
bathron-cli -testnet getstate             # global settlement state + invariants
bathron-cli -testnet getfinalitystatus    # finality lag (healthy = 0)
bathron-cli -testnet getbtcheadersstatus  # in-consensus Bitcoin (testnet4) header chain

A healthy node produces a new block every 60 seconds network-wide, finalizes with lag 0, and tracks the Bitcoin testnet4 header chain inside consensus.

During the initial sync, a scary-looking finality status is normal. While the node is still downloading blocks, getfinalitystatus can report last_finalized_height: 0 and status: "critical". Finality certificates are received live: the node catches up on blocks first, then finalizes the current tip as soon as the first live certificate arrives. Nothing is wrong with the network — the node simply hasn't heard a certificate yet.

Consider the node healthy only once all of the following hold: the tip matches the network height, a new block has been received, a finality certificate has been observed, and finality_lag is back to 0.

See the network live

After your node has synchronized, you can compare its public chain height and finality status with the testnet explorer. The explorer is an observational service, not a bootstrap peer or an RPC endpoint.

See also: Run a wallet · Production and finality · Status & claims