Babylon Node

Overview

Babylon Node is the software that runs the Radix network. Its repository, radixdlt/babylon-node, describes itself as "the Radix node, updated for Babylon" and states that it embeds the Radix Engine, which lives in the separate radixdlt-scrypto repository. That separation is the single most useful thing to know about it: the rules a transaction is executed under are written elsewhere, and this repository is what carries them to the machines that run the ledger.

The node is where consensus, peer-to-peer networking, the Core API and the engine meet in one process. The Gateway API that most applications read the ledger through is not part of it; the Gateway is a separate service that reads from a node. A validator is a node whose operator has registered it on-ledger and attracted stake, and running one is documented in this wiki’s own infrastructure guide.

What is inside it

The repository’s README maps the tree, and the division it describes is a language boundary as much as a functional one. GitHub measures the checkout at roughly 16.7 MB of Java against 4.9 MB of Rust and 3.4 MB of TypeScript.

• core – the node itself: consensus and networking, in Java. The README describes it as including "a variant implementation of the HotStuff BFT-style consensus", which is the plainest statement in Radix’s own source of what secures Babylon mainnet. Cerberus running unsharded, as it does on mainnet, is equivalent to that original HotStuff protocol.
• core-rust – the Core API and the "State Manager" that wraps the Babylon engine, in Rust. This is the module that pulls the engine in from radixdlt-scrypto.
• core-rust-bridge – the Java side of the boundary between those two, which the README expects will eventually be folded into core.
• cli-tools, common, shell, docker and testnet-node – the operator surface: command-line helpers, shared Java utilities, the interactive Radix Shell, a local multi-node network, and a one-script development node for integrators.

The engine dependency is the reason a change to how transactions execute is not, by itself, a change to the node. It becomes one when a node release picks the new engine up.

How a protocol update reaches mainnet

Radix does not switch rules when nodes are updated. It switches when the validator set says it is ready. The node supports two triggers, described in Radix’s node documentation: unconditional enactment at the start of a named epoch, used for genesis and test environments, and validator readiness signalling, which is "the standard option for mainnet protocol updates".

Under the second, each validator has room for exactly one optional readiness signal at a time, and the signal is not the update’s name but a unique string derived from the protocol version and its trigger condition. Enactment is bounded by a lower_bound_epoch_inclusive and an upper_bound_epoch_exclusive, and gated on one or more readiness thresholds, each pairing a required_ratio_of_stake_supported with a required_consecutive_completed_epochs_of_support. A threshold is met when validators representing at least that share of the active set’s stake have been signalling continuously for that many epochs.

The mainnet updates configured so far, with the node release each shipped in:

Eagle Ray is the first mainnet entry that does not use readiness signalling, and the reason is that a halted network cannot produce one. A threshold is met only after a number of completed epochs of support, and mainnet completed none between 31 August and 11 September 2026, so an update whose purpose was to end that halt could never have cleared one. The mainnet protocol configuration released in v1.4.0.0 gives it EnactAtStartOfEpochUnconditionally at epoch 339,898 instead, and adds a second mechanism the node did not previously have: a UserTransactionMoratorium covering the single epoch 339,897, defined in the node source as an epoch range during which user transactions are refused, and commented in the configuration as belonging to the Mainnet incident of 1 September 2026. Consensus therefore restarts one epoch before the new rules do. Stokenet receives the same update through the ordinary route, signal 8ed71bbdf45861cb0000000eagle-ray at 80% of stake for ten consecutive epochs, which is what the mechanism looks like when the ledger is moving.

Cuttlefish enacted at epoch 160923, inside that window. Execution itself is handled by the node: the final consensus proof of the preceding epoch signs off on the enactment, so the epoch cannot end unless a quorum agrees it should proceed, and the update then commits zero or more batches of system "flash" transactions that rewrite engine substates directly. An operator can ask a running node what it has enacted and what is pending through its System Health endpoint, by default http://localhost:3334/system/health, which lists both with their readiness signal names.

The consequence for a reader watching for an upgrade is precise: until a node release exists that contains a protocol version, there is nothing for a validator to signal, and therefore no readiness figure to watch. For Eagle Ray there is no readiness figure to watch at all. See Protocol Updates for what each one changed.

Release history and branch topology

The repository’s releases follow the protocol line rather than a calendar. The original protocol version, babylon, arrived with the v1.0.0 node and was enacted immediately at the Babylon migration; v1.1.0, v1.2.0 and v1.3.0 carried Anemone, Bottlenose and Cuttlefish. Everything since has been a patch on the Cuttlefish line: v1.3.0.1 and v1.3.0.2 in December 2024 and January 2025, then v1.3.0.4 on 2 April 2026 and v1.3.0.5 on 1 June 2026. All five are still named "Cuttlefish", and none carries a protocol change.

Where that work happens is not where the repository’s front page points. GitHub serves develop as the default branch, and develop’s tip is commit 12919a01, "Update development docs", of 12 March 2025. The release line is main, whose tip 959b081e of 1 June 2026 is the exact commit tagged v1.3.0.5. The two branches have diverged rather than drifted: GitHub’s comparison puts 28 commits on main that are not on develop, and 223 on develop that are not on main. A reader who opens the repository to judge whether the node is being worked on sees, by default, a branch that stopped eighteen months ago.

The September 2026 halt was resolved on main and nowhere else. Pull request #1076, which carries the Eagle Ray engine pin and the restart schedule, was opened against develop and retargeted to main minutes before it merged on 8 September 2026; main's tip is now 7400951e, tagged v1.4.0.0-RC1 on 8 September and v1.4.0.0 on 10 September, the first release since v1.3.0 to carry a protocol change, and the head of a third branch, release/eagle-ray. develop's tip is unmoved, and the comparison now reads 48 commits on main that are not on develop against 223 the other way.

Status during the September 2026 halt

Mainnet committed no round from 21:19:48 UTC on 31 August 2026, at epoch 339,897 and state version 557,840,627, until 11 September, following the Hyperlane asset drain. For the first eight days of that halt this repository showed nothing that would end it: its newest release was still v1.3.0.5 of 1 June, and no branch or tag named a forthcoming protocol version. The fix was in pull request #2093 against radixdlt-scrypto, the engine repository this one embeds, and nothing there reaches the network until an engine release carrying it is pulled into a node release and that node release is published.

Both halves are now done. Scrypto v1.4.0 (Eagle Ray) was tagged on 7 September, and on 8 September this repository merged pull request #1076 into main at 15:28:11 UTC — pinning the engine dependency to it and adding the enactment trigger for epoch 339,898 and a user transaction moratorium for epoch 339,897 — and published v1.4.0.0-RC1 seven minutes later, with container images by 16:23 UTC. The candidate was flagged a pre-release, so the repository's latest release resolved to v1.3.0.5-test.1, a rebuild of the halted version tagged that same lunchtime. The final release, v1.4.0.0, followed at 03:59:09 UTC on 10 September 2026, with container images pushed between 04:31 and 04:50 UTC. It tags commit 7400951e0eb76a725f39d04d57da293fb335bd0e, which is the commit the candidate already tagged, so the code an operator installs is the code they could have installed on 8 September; what the final release adds is the absence of the pre-release flag, and with it a latest release that resolves to Eagle Ray for GitHub and for the ghproxy.radixdlt.com mirror the node installer reads. Read at 07:07:53 UTC on 10 September the ledger had not moved, because two steps remained: operators had to install the release, and two thirds of stake had to come back online.

Both happened on 11 September. Rounds resumed at 11:35 UTC inside the moratorium epoch, and Eagle Ray enacted at the start of epoch 339,898 at 11:39 UTC, when user transactions were allowed again. The state version and timestamp of each step are on Protocol Updates.

See Also

• Radix Engine
• Cerberus (Consensus Protocol)
• Radix Core API
• Protocol Updates
• Validator Nodes
• Stokenet
• Running a Node

External Links

• radixdlt/babylon-node – the repository
• Releases – the node release line
• Node Protocol Updates – readiness signalling, thresholds and the mainnet table
• Protocol Updates – Radix Docs
• radixdlt-scrypto – the engine the node embeds
• Radix License 1.0 – the domain refuses every TLS handshake, read 9 September 2026; the text is in the Internet Archive capture of 2 April 2023