Run an XRO node

Quick start

What you need

• Any machine that stays on — a mini PC, an old laptop or a small VPS is plenty.
• Docker. If you do not have it: curl -fsSL https://get.docker.com | sh
• Roughly 2 GB of disk for the ledger, plus room to grow.
• Port 8075 reachable from the internet, if you want other nodes to connect to you. It will still sync without this.

1. Start the node

   This is the exact configuration the primary node runs. Paste it as one command — the copy button gives you a single line.

   bashCopy

   docker run -d \
     --name xro \
     --restart unless-stopped \
     --network host \
     -e prefix="xro_" \
     -e name="RaiblocksOne" \
     -e account="xro_3oh6tp9b8y65w1fzp3aaxgebptkdhnrziiqaairqfhzkcntiwn1r97cgzikp" \
     -e source="D5E4D58E937883E01BFB0508EB989B6A4B7D31F842E8443176BFF255350E5018" \
     -e work="9da7e03b2a2ec54b" \
     -e signature="FBB7588466EAA76196181C3CDF249178BAC70929E28AABBD5DE284362A34899AB4C972A232824067F439E89F2672B792105D3A55763B852FD21967EC7957260D" \
     -e peering="peering.raione.cc" \
     -e peering_port=8075 \
     -e RPC_PORT=8076 \
     -e WS_PORT=8078 \
     -v /data/nodes/xro:/root \
     caltru1sm/xro-node:2.0.0-R2

   Every -e value is required. Leave one out and the node either refuses to start or derives a different genesis and gets rejected by the network.

2. Watch it sync

   Check progress whenever you like. The number should climb toward the height shown on the explorer.

   bashCopy

   curl -s -d '{"action":"block_count"}' http://127.0.0.1:8076

   It will appear to stall around 155,000 blocks. Leave it alone.

   From roughly minute 8 to minute 28 progress crawls — a few hundred blocks a minute, sometimes none. This is the node untangling a dependency chain, and it is the single most common reason people give up and restart. Restarting costs you the progress. Both verified runs sat in this patch for about twenty minutes and then jumped straight to the full chain.

3. Confirm it finished

   You are done when count matches the explorer and unchecked is 0. Expect roughly 626,000 blocks across 8,455 accounts, with 8 or so peers.

   bashCopy

   curl -s -d '{"action":"block_count"}' http://127.0.0.1:8076
   curl -s -d '{"action":"peers"}' http://127.0.0.1:8076

   That is a full node, validating every block for itself. To also vote on consensus, see becoming a representative.

Optional — start from a snapshot instead

If you would rather not wait 45 minutes, seed the ledger from a published snapshot and the node picks up from there. Do this before starting the container. Never skip the checksum.

wget https://github.com/Caltru1sm/xro-node/releases/download/xro-node-2.0.0/xro-ledger-625082-2026-08-04.data.ldb.gz
wget https://github.com/Caltru1sm/xro-node/releases/download/xro-node-2.0.0/xro-ledger-625082-2026-08-04.sha256
sha256sum -c xro-ledger-625082-2026-08-04.sha256

mkdir -p /data/nodes/xro/RaiblocksOne
gunzip -c xro-ledger-625082-2026-08-04.data.ldb.gz \
  > /data/nodes/xro/RaiblocksOne/data.ldb

Expect xro-ledger-625082-2026-08-04.data.ldb.gz: OK. The snapshot is data.ldb only — no wallet, no node identity. Your node generates its own node_id_private.key on first start; never copy someone else's, or you will both be running the same identity on the network.

Direct links: release page · ledger · sha256

What was wrong, and what got fixed

Three separate bugs kept new nodes off this network for over a year. They are written up here rather than quietly patched.

1. The chain failed Nano's work thresholds

XRO's blocks were produced with proof-of-work below what Nano expects — 403,985 of 592,298 blocks (68%) under epoch_1, and 454,888 (77%) under epoch_2. A node that already held the blocks never noticed, because Nano does not re-check what it has stored. Any node fetching history rejected them as insufficient_work. Lowering the thresholds to match the chain fixed it; it only ever accepts blocks the network already has, so it cannot split the chain.

2. The peering setting was never read

Every image passed peering=peering.raione.cc and no version of the startup script ever used it. Nodes silently fell back to peering.nano.org — Nano's mainnet seed — and found no XRO peers at all. Long-running nodes were immune because they had a cached peer database, so this only ever hit newcomers, which is exactly why it went unnoticed for so long.

3. Bootstrap deadlocked on its own dependencies

Fresh nodes wedged at about 156,000 blocks indefinitely. The cause was a blocked-on-blocked deadlock: accounts waiting on a missing source block were skipped for prioritisation because they were waiting, so the chain never unwound. Fixing the dependency walker to raise those accounts instead of skipping them cleared it — first full unattended sync from genesis, twice over.

Upgrading an existing node

Your ledger is fine — only the software was wrong. Same data directory, same ports, no migration.

docker pull caltru1sm/xro-node:2.0.0-R2\ndocker stop xro && docker rm xro\n\n# then the run command above, unchanged

Afterwards, confirm the block count is your old height and climbing, not 1.

From the original 2024 node

Only if you are still on raiblocksone/raione:R1_V.02.2. Two things will bite you, both verified by running the images:

• Your ledger is in Nano/, not RaiblocksOne/. Mount the directory as-is and the new node will not find it — it creates an empty ledger alongside and starts over. Rename it first:
  bashCopy

  mv /root/raiblocksone/Nano /root/raiblocksone/RaiblocksOne\nrm -f /root/raiblocksone/RaiblocksOne/config-*.toml

• The database upgrade from v22 to v24 cannot be reversed. The old node refuses the migrated ledger with The version of the ledger (24) is too high for this node. Restarting the old container is not a rollback — back up first, and that backup is your only way back.

Ports also moved: 7075 → 8075, 7076 → 8076, 7078 → 8078.