← TXC Core

Node canary — did it work, and is it still working?

One paste, about thirty seconds, and you get a single verdict: ALL GREEN, PASS with warnings, or FAIL. Everything it does is a read — it never sends coins, signs anything, or changes node state. Run it right after the build, then any time you want to know the node is still healthy and still in agreement with the network.

01

Run it

On the node box (EC2 Instance Connect browser terminal, user ubuntu), paste this:

curl -fsSL "https://core.honest.money/install/node-canary.sh?v=$(date +%s)" | bash

The ?v= part just defeats caching, so you always get the newest version of the check. No sudo needed — it only reads.

02

Baseline before a change, check after

Before you restart, reconfigure, or rebuild anything, take a snapshot. Then the check afterwards can tell you whether the chain actually kept moving and whether the binary changed under you.

# before
curl -fsSL https://core.honest.money/install/node-canary.sh | bash -s BASELINE

# after
curl -fsSL https://core.honest.money/install/node-canary.sh | bash

During the first sync, watch mode prints a one-line progress report every minute so you can see the height climb:

curl -fsSL https://core.honest.money/install/node-canary.sh | bash -s WATCH 30
03

What it checks

1. Build identity

Binaries exist, when they were built, which branch and commit they came from, whether the tree is clean, and that all four Send To Many source markers are really in the code.

2. Daemon + RPC

texitcoind running, uptime, memory, RPC answering, peer count, reported subversion.

3. Chain sync + consensus

Blocks vs headers, height against the public network, and — the important one — the block hash at our own tip compared with the network's. Same height plus same hash means this build computes the same chain as everyone else.

4. Omni layer

omni_getinfo answers, which Omni version, and whether the Omni parser is level with the chain tip.

5. Send To Many

Both new RPCs registered, the payload encoder reproduces the upstream test vector byte-for-byte, feature 19 is still closed on mainnet, no surprise pending activations, and a bulk send is refused before activation.

6. Host health

Disk, memory, swap, load, out-of-memory kills, and fatal lines in the node's recent log.

7. Baseline

Compares against a snapshot you take before a change: did the chain actually advance, did the binary change under us.

04

Reading the verdict

ALL GREEN — patched node built, running, in consensus with the network, and the Send To Many gate is still closed. That is the state we want for now.

PASS with warnings — nothing is broken. During the first hours the usual warnings are "still catching up" and "only a few peers". Re-run in ten minutes and they clear themselves.

FAIL — something real. The three that matter most: source markers missing (the patch did not fully apply), encoder output not matching the test vector (wrong wire format — do not use this build), or a block hash that differs from the network at the same height (this node has forked off on its own chain).

If you get a FAIL, copy the whole output into the chat and we will fix it from there.

05

Why a canary and not a dashboard

A dashboard tells you what a node claims about itself. A canary asks the questions that catch the failures that look fine from the outside: a node that is perfectly healthy but quietly on its own fork, an encoder that produces bytes nobody else accepts, a feature gate that opened before the other operators upgraded. Every one of those reports "running, synced, no errors" right up until it costs somebody money.

Same approach we run on the mining side, where a stratum that looked perfectly healthy took four chains down for ninety minutes.