---
title: "Babylon Node"
url: "https://radix.wiki/contents/tech/core-protocols/babylon-node"
updated: 2026-09-07
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
version: "1.0.0"
---

# Babylon Node

| Software | The Radix node for the Babylon network and beyond |
| --- | --- |
| Repository | [radixdlt/babylon-node](https://github.com/radixdlt/babylon-node), created 25 April 2022 |
| Languages | Java (consensus, networking) and Rust (Core API, state manager); TypeScript for generated clients |
| Licence | [Radix License 1.0](https://www.radixfoundation.org/licenses/license-v1), July 2021 |
| Engine | Pulled in from [radixdlt-scrypto](https://github.com/radixdlt/radixdlt-scrypto), not vendored in this repository |
| Latest release | [v1.3.0.5](https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5), 1 June 2026 – an opt-in release carrying no protocol change |
| Protocol line | v1.0.0 Genesis · v1.1.0 Anemone · v1.2.0 Bottlenose · v1.3.0 Cuttlefish |
| Default branch | `develop` – last commit 12 March 2025, while releases are cut from `main` |
| Primary sources | [README](https://github.com/radixdlt/babylon-node/blob/main/README.md) · [Node Protocol Updates](https://docs.radixdlt.com/docs/node-protocol-updates) |

## Overview

**Babylon Node** is the software that runs the Radix network. Its repository, [radixdlt/babylon-node](https://github.com/radixdlt/babylon-node), describes itself as "the Radix node, updated for Babylon" and states that it _embeds_ the [Radix Engine](/contents/tech/core-protocols/radix-engine), which lives in the separate [radixdlt-scrypto](https://github.com/radixdlt/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](/contents/tech/core-protocols/cerberus-consensus-protocol), peer-to-peer networking, the [Core API](/contents/tech/core-protocols/radix-core-api) and the engine meet in one process. The [Gateway API](/contents/tech/core-protocols/radix-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](/contents/tech/core-concepts/validator-nodes) is a node whose operator has registered it on-ledger and attracted [stake](/contents/tech/core-concepts/staking), and running one is documented in this wiki’s own [infrastructure guide](/developers/infrastructure/01-running-a-node).

## What is inside it

The repository’s [README](https://github.com/radixdlt/babylon-node/blob/main/README.md) 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](https://arxiv.org/abs/1803.05069) 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](https://docs.radixdlt.com/docs/node-protocol-updates): 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:

| Update | Node | Readiness signal | Epoch window | Requirement |
| --- | --- | --- | --- | --- |
| Anemone | v1.1.0 | `220e2a4a4e86e3e6000000000anemone` | [70019, 74051) | 75% of stake for ~4 days |
| Bottlenose | v1.2.0 | `86894b9104afb73a000000bottlenose` | [104291, 112355) | 75% of stake for ~2 weeks |
| Cuttlefish | v1.3.0 | `96e00440adafe5e2000000cuttlefish` | [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](/contents/tech/releases/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](/contents/tech/releases/radix-mainnet-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](https://github.com/radixdlt/babylon-node/releases/tag/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](/contents/history/hyperlane-asset-drain-2026). 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](https://github.com/radixdlt/radixdlt-scrypto/pull/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](https://github.com/radixdlt/babylon-node/pull/1074), "Test workflow", a single file against `develop`, and [#1075](https://github.com/radixdlt/babylon-node/pull/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

- [Radix Engine](/contents/tech/core-protocols/radix-engine)
- [Cerberus (Consensus Protocol)](/contents/tech/core-protocols/cerberus-consensus-protocol)
- [Radix Core API](/contents/tech/core-protocols/radix-core-api)
- [Protocol Updates](/contents/tech/releases/protocol-updates)
- [Validator Nodes](/contents/tech/core-concepts/validator-nodes)
- [Stokenet](/contents/tech/releases/stokenet)
- [Running a Node](/developers/infrastructure/01-running-a-node)

## External Links

- [radixdlt/babylon-node](https://github.com/radixdlt/babylon-node) – the repository
- [Releases](https://github.com/radixdlt/babylon-node/releases) – the node release line
- [Node Protocol Updates](https://docs.radixdlt.com/docs/node-protocol-updates) – readiness signalling, thresholds and the mainnet table
- [Protocol Updates](https://docs.radixdlt.com/docs/protocol-updates) – Radix Docs
- [radixdlt-scrypto](https://github.com/radixdlt/radixdlt-scrypto) – the engine the node embeds
- [Radix License 1.0](https://www.radixfoundation.org/licenses/license-v1)