1. Running a Radix Node

Overview

A Radix node connects to the peer-to-peer network, syncs ledger state, and (if registered as a validator) participates in Cerberus consensus. You can run a node to power your own API endpoints, support the network, or earn staking emissions as a validator.

Hardware Requirements

Installation

Radix provides two installation methods:

Option A: CLI-Guided Install (Recommended)

The babylonnode CLI tool walks you through configuration interactively:

wget -O babylonnode https://github.com/radixdlt/babylon-nodecli/releases/latest/download/babylonnode-ubuntu-22.04
chmod +x babylonnode
sudo mv babylonnode /usr/local/bin/
 
# Run guided setup
babylonnode docker install

Option B: Docker Manual Setup

For more control, use docker-compose directly with the official images from radixdlt/babylon-node.

Option C: Systemd

Run the node process directly on the host, managed by systemd. Better for servers shared with other services.

All methods are documented at docs.radixdlt.com/docs/node-setup.

Which Node Version the CLI Installs

The latest/download URL above has not moved since babylonnode 2.2.4, published on 13 January 2025, and the only commit on the tool's main branch since is CI housekeeping in March that year. That tells you nothing about the node you will end up running, because the CLI does not carry a node version at all.

Instead it resolves the node, nginx and Gateway tags at run time from ghproxy.radixdlt.com, a Radix-operated mirror of the GitHub releases API, and installs whatever tag comes back. Asked on 21 August 2026, it returned babylon-node v1.3.0.5 – a release that shipped nearly seventeen months after the CLI binary did. A frozen installer and a current node are not in tension here; the indirection is the point. What that indirection returns during the halt is a different matter, and is covered below.

Two consequences are worth knowing before an unattended rebuild depends on it:

• It is a single external dependency. If that proxy does not answer, the CLI prints the failing URL and exits – there is no fallback to the GitHub API it mirrors.
• You can pin past it. Setting RADIXDLT_APP_VERSION_OVERRIDE – or RADIXDLT_NGINX_VERSION_OVERRIDE and RADIXDLT_GATEWAY_VERSION_OVERRIDE for the other two – makes the CLI use that exact tag without asking anyone, which is what a reproducible validator rebuild wants.

The published binaries cover Ubuntu 20.04 and 22.04 only, with no 24.04 build – which is why 22.04 is the operating system named in the table above rather than the newer LTS. Operators on a distribution the CLI does not ship for take the Docker or systemd path instead.

Operating Through the Network Halt (31 August – 11 September 2026)

This section and the one below it were written while mainnet was down. They are kept as an operator’s record of the outage; how it ended is at the foot of it.

Mainnet stopped committing rounds at 21:19:48.939 UTC on 31 August 2026, at epoch 339,897, round 4, state version 557,840,627, after the Hyperlane asset drain. The halt was not a mode the network was switched into and there is no lever to throw back: node runners stopped their own nodes, and liveness returns only when enough of them individually deploy a patched release and start again.

The Radix Accountability Council set out the sequence at 12:16 UTC on 1 September – "code fixes for the RE", "updates to the node software + protocol upgrade", "a coordinated deployment of those across nodes", and "a careful coordinated return to liveness of the network", with no timetable. Steps three and four are operator work, which makes the state of your node between now and then worth understanding.

The patched release, and what the CLI installs

The releases page is the cheapest signal an operator has for whether step two has produced anything, and it has now produced twice. Eagle Ray v1.4.0.0-RC1 was published at 15:35:42 UTC on 8 September from merge commit 7400951e, with Docker images pushed to the official repository between 16:06 and 16:23 UTC. The final release, v1.4.0.0, followed at 03:59:09 UTC on 10 September 2026, cut from the release/eagle-ray branch against a tag created at 15:28:10 UTC on 8 September, which is the same commit the candidate carried; its Docker images were pushed between 04:31 and 04:50 UTC. Neither release carries notes. Both bodies are the Radix licence boilerplate and nothing else: no changelog, no upgrade steps, no restart epoch.

The candidate was flagged a pre-release, and that flag had a consequence for the recommended install path. GitHub reports as latest the newest release that is neither a draft nor a pre-release. Three hours before Eagle Ray RC1, at 12:28:06 UTC on 8 September, the repository published v1.3.0.5-test.1, an empty-bodied tag cut by github-actions[bot] and not flagged pre-release, so that was the release GitHub called latest. Asked at 23:06 UTC on 8 September and again at 03:04 UTC on 9 September, ghproxy.radixdlt.com/radixdlt/babylon-node returned that tag_name rather than the candidate's. For those two days the CLI-guided path above resolved to a test build cut before the fix, Docker images existed for that tag as well, and the install therefore succeeded and left the operator on a node that is not the one the restart depends on.

The final release closes that gap. v1.4.0.0 carries no pre-release flag, so it is what GitHub now calls latest, and read at 07:06 UTC on 10 September ghproxy.radixdlt.com/radixdlt/babylon-node returns v1.4.0.0. From that point the CLI-guided path installs the patched node with no override needed. Three habits the gap taught are worth keeping anyway:

• Pin the tag. RADIXDLT_APP_VERSION_OVERRIDE=v1.4.0.0 makes the CLI use that exact release without consulting the proxy at all.
• Name it yourself. The Docker and systemd paths take the tag from your own compose file or unit, so neither was ever affected.
• Check what you got. After any CLI install or update, read back the image tag actually running before assuming it is the patched one.

The Radix Accountability Council asked operators at 18:43 UTC on 9 September not to run the release candidates on their own nodes, and to wait for official final versions and instructions on when to deploy. v1.4.0.0 is that final version, and the instructions followed it. At 16:15 UTC on 10 September projectShift posted a status update from the council telling operators to upgrade now: You can upgrade and update your nodes now, using the latest software version available from official sources. Validator operators are told to check the dedicated validator chat for further detail, and to leave a node online and working once it is fully upgraded and running properly. That is the third of the four steps the council named on 1 September, the coordinated deployment across nodes. The restart itself had no published date. From 20:18 UTC on 10 September it had a published threshold instead.

None of this had moved the ledger. gateway-status at 07:07:53 UTC on 10 September still returned state version 557,840,622 at epoch 339,896, round 102 – the aggregator’s position rather than the ledger’s, five states short of the tip – unchanged for 225 hours and 48 minutes, and three hours after the final release an operator could install.

No epochs means no emissions

Staking emissions are minted per epoch, and the epoch counter did not move for the length of the halt. Nothing accrued to validators or their delegators while the network was stopped, and nothing was lost in arrears either – the ledger simply had no epochs to pay out for. The rule is general rather than particular to this outage: a stopped ledger pays nobody, and it owes nobody afterwards. This was answered directly in the main channel on 1 September: "The network progresses in epochs and stake rewards are given per epoch run. So no progress in epoch = no rewards given."

A start-up failure on the current release, still unanswered

One operator report against v1.3.0.5 has been open on the official forum since 17 August 2026 with no reply. On an Ubuntu 22.04.5 LTS host where v1.3.0.4 runs normally, swapping in the v1.3.0.5 binary and its libcorerust.so makes the node panic during initialisation and restart in a loop:

panicked at state-manager/src/jni/node_rust_environment.rs:173:72:
called `Result::unwrap()` on an `Err` value: JavaError("[ERROR] byte offset: 90-92,
value path: StateManagerConfig.[4|database_config]->DatabaseConfig,
cause: { expected_field_count: 4, found: 5 }")

The failure is not an operating-system incompatibility. It is a decode mismatch at the JNI boundary: the node's Java process hands the native state manager a DatabaseConfig carrying five fields where the Rust side expects four, which is the signature of a Java binary and a libcorerust.so that did not ship together. If you keep multiple releases side by side under /opt/radixdlt/babylon-node/ and select between them with LD_PRELOAD, check that both halves resolve to the same release before assuming the release itself is broken.

The report was raised again on 1 September, twenty-four hours into the halt and immediately before the node update the restart depends on – the kind of thing worth confirming on your own host before the coordinated deployment rather than during it.

The restart condition, and the gap it has to close

At 20:18 UTC on 10 September 2026, in the main Radix Telegram group, Bart Roozeboom of the validator operator StakeSafe announced that its free Radix Network Dashboard now tracks Eagle-Ray adoption live, and stated the condition in one line: Once more than 67% of active stake is on Eagle-Ray, network liveness resumes and the network forks to a patched version. The dashboard repeats it in a banner above its charts. The 67% is not a StakeSafe rule. It is the ordinary two-thirds quorum Radix's consensus needs to commit a round, which is why the same fraction of stake could stop the network in the first place.

Read from the dashboard's served page at 03:05 UTC on 11 September 2026, eleven hours after operators were cleared to upgrade:

Adoption was moving. Four hours earlier, at 23:08 UTC on 10 September, the same panel read 1,260,200,690 XRD and 27.03%, so roughly 160 million XRD came onto the patched release overnight. Thirty-six rows in the dashboard's validator table report v1.4.0.0 and their delegated stake sums to the adoption figure exactly.

Upgrades among operators who are already running cannot close the gap. Online stake is 1,642,251,851 XRD, 35.22% of the active set. Every online validator could be on Eagle Ray tomorrow and the total would still sit around half of the 67% the restart needs, because the other 3,020,769,489 XRD is behind nodes that are switched off. The council's instruction reflects that: it asks operators to leave a fully upgraded node online and working, not merely to install the release. If your node is one of the ones that stopped, starting it again on v1.4.0.0 is the step the threshold is actually waiting on.

One caveat on reading the dashboard. Its percentages are computed on the active validator set, the top 100 by stake, whose total it reports as 4,663,021,340 XRD – the online and offline figures added together. The panel heads with a different number, 4,877,281,907 XRD, which is every row in the explorer table including validators outside the active set. Quoted against that base the adoption reading is 29.11% rather than 30.45%, so say which base a figure came from. The dashboard refreshes every five minutes, and every reading here is a snapshot.

gateway-status at 03:04:56 UTC on 11 September still returned state version 557,840,622 at epoch 339,896, round 102, 245 hours and 45 minutes without a committed round. Eight and a half hours later it was over.

How the halt ended (11 September 2026)

Enough of the set came back. Radix mainnet certified a round at 11:35:28.96 UTC on 11 September 2026 – state version 557,840,628, epoch 339,897 round 5, its first in ten days, fourteen hours and sixteen minutes. Epoch 339,897 then ran to its end producing rounds and refusing user transactions under the moratorium v1.4.0.0 declares, and at 11:39:25.129 UTC epoch 339,898 opened at round 2 with the Eagle Ray fork enacted and the moratorium lifted in the same second. Read from the transaction stream, the outage is three consecutive entries: 557,840,627 at 21:19:48.939 UTC on 31 August, 557,840,628 at 11:35:28.96 UTC on 11 September, and sixty-five further round changes before the first user transaction at 557,840,694.

Two things in the sections above are worth carrying forward rather than filing. The fork enacted unconditionally at the start of epoch 339,898 rather than on a validator readiness signal, which is unique in Radix’s mainnet history and is why no restart date could be published: a halted network completes no epochs, so it can hold no readiness vote. And an operator still on v1.3 when the fork enacted was not merely late; the release the threshold counted is the one the network forked to. The adoption dashboard read 32.77% of active-set stake on Eagle Ray at 11:05 UTC and the fork enacted at 80.85%, so the last forty-eight points arrived in half an hour when the largest validators booted together. The full sequence is on Radix Ecosystem Operational Status.

Becoming a Validator

Once your node is synced, you can register it as a validator to participate in consensus and earn emissions.

1. Create and register – create the validator with CREATE_VALIDATOR, passing your node’s public key, your fee factor and a bucket of XRD, then call register with the owner badge it returns. The creation fee is set in US dollars, 100 since the Anemone update, and converted at the protocol’s fixed rate of 16.67 XRD to the dollar rather than the market price, so it comes to 1,666.67 XRD.
2. Configure – set your validator name, website URL, fee percentage, and delegation policy
3. Attract stake – the top 100 validators by total delegated stake are active each epoch
4. Maintain uptime – missed proposals reduce your emissions share

See the validator setup guide for detailed steps.

Monitoring

Use the standard Prometheus + Grafana stack for observability:

1. Install Node Exporter for system metrics (CPU, RAM, disk, network)
2. Configure Prometheus to scrape your node's metrics endpoint
3. Set up Grafana dashboards to visualize node health, sync status, and proposal statistics

The node also exposes a System API for diagnostics – connection status, health checks, and performance metrics. See Radix APIs for details.

Maintenance

• Protocol updates – update your node software when new protocol versions are released; validators must signal readiness
• Backups – the ledger can be rebuilt from the network, but backing up your validator key is critical
• Snapshots – daily ledger snapshots are available at snapshots.radix.live for faster initial sync

Running a Node on Stokenet

Stokenet, the public test network, was reset on 29 August 2026 onto a new genesis that kept network ID 2. A node derives the genesis for its network ID from its own binary, so until Eagle Ray a stock image joined the old, frozen chain and operators had to patch it. From babylon-node v1.4.0.0 the release compiles in the new chain’s genesis (Network.java), and the stock image joins it with no patch.

The Stokenet operator, Daffy, keeps a handout for community node operators; version 1.2, dated 13 September 2026, was posted in Radix Developer Discussion after a validator operator asked whether they could run a Stokenet node. It says the official node documentation still applies apart from three things:

• The image. Run radixdlt/babylon-node:v1.4.0.0 or later. The tag has four version components, so v1.4.0 does not pull.
• The genesis file. Download genesis.bin and point RADIXDLT_GENESIS_DATA_FILE at it through a volume mount. Check its SHA-256 before starting: 0006347310c9d155fe4d625f1317e86e43bd3a550d2be2b656a2968163f95108. The frozen chain’s genesis is also 669 bytes, so the size tells you nothing. The node compares the file with the genesis compiled into the release and the one stored in its database, and refuses to start with Inconsistent genesis configuration if they differ.
• Test XRD. The reset destroyed every balance and the faucet does not give enough to cover the validator creation fee, so the handout sends operators to a named contact on Telegram with an account address and a stake figure.

Anyone who ran a Stokenet node before 29 August has to wipe the ledger database, because an existing database belongs to the old chain. A validator created after genesis names itself with RADIXDLT_CONSENSUS_VALIDATOR_ADDRESS; the genesis-based validator flag finds nothing for it. The handout also warns that the container prints its whole environment at startup, keystore password included, so filter docker logs before sharing any of it.

On mainnet the Eagle Ray fork enacted unconditionally. On Stokenet it follows the usual readiness vote, and the handout gives the threshold as validators holding 80% of stake signalling for 10 consecutive epochs, so a newly registered validator should check its node’s pending protocol updates and signal if Eagle Ray is still listed. The reset, the patched image that preceded this release and the seed nodes are recorded on the Stokenet page.

Next Steps

• Radix APIs – what your node exposes, and when to use it instead of a public Gateway

External Links

• Node introduction
• Node setup guide
• Validator setup
• Maintenance guide
• babylon-node GitHub
• babylon-nodecli GitHub – the babylonnode tool