RADIX WikiRADIX Wiki

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 three mainnet updates configured so far, with the node release each shipped in:

UpdateNodeReadiness signalEpoch windowRequirement
Anemonev1.1.0220e2a4a4e86e3e6000000000anemone[70019, 74051)75% of stake for ~4 days
Bottlenosev1.2.086894b9104afb73a000000bottlenose[104291, 112355)75% of stake for ~2 weeks
Cuttlefishv1.3.096e00440adafe5e2000000cuttlefish[158682, 161562)75% of stake for ~2 weeks

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. 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.

Status during the September 2026 halt

Mainnet has not committed a round since 31 August 2026 at 21:19:06.179 UTC, at epoch 339,896 and state version 557,840,622, following the Hyperlane asset drain. Read on 7 September 2026, this repository shows nothing that would end that: the newest release is still v1.3.0.5 of 1 June, there is no branch or tag naming a forthcoming protocol version, and the newest release therefore carries no rule change for a validator to signal readiness for.

The candidate fix is not in this repository at all. It is pull request #2093 against radixdlt-scrypto, the engine repository this one embeds, adding a receiver check to method invocation under a new protocol version. Nothing in that pull request reaches the network until an engine release carrying it is pulled into a node release, that node release is published, and enough of the validator set signals for it. The repository’s only activity on 6 September was continuous-integration housekeeping, in two open pull requests from the same author: #1074, "Test workflow", a single file against develop, and #1075, removing unused Phylum and Postman CI jobs across five files against main. The same pattern appeared in radixdlt-scrypto the same day. Repository activity during an outage is easy to mistake for progress on the outage; on both repositories, so far, it has not been.

See Also

HydrateLast updated 6h agov1.0.01 revision