Radix Protocol Updates

Overview

A protocol update is a named, major change to the rules every Radix node runs. Radix Docs describes them as happening approximately two to three times a year and notes they "are sometimes known as ‘hard forks’ on other networks". Each update requires node and Gateway operators to upgrade, and requires the validator set to signal readiness before the new rules take effect.

The first protocol version was babylon, introduced with the v1.0.0 node and enacted immediately at the Babylon migration from Olympia. Subsequent updates follow an alphabetical sea-creature naming scheme: Anemone, Bottlenose, Cuttlefish, and – still in development – Dugong. Each ships as a node release that carries the new engine configuration but keeps it dormant until the network agrees to switch over.

This page collects what each update changed, when it was enacted, and which Scrypto version it corresponds to. For the network releases themselves – Olympia, Babylon, and the forthcoming Xi'an – see the sibling pages in this section.

How an Update Is Enacted

Nodes cannot simply adopt new rules the moment they are installed: if some nodes switched and others did not, the network would fail to agree on transaction outcomes. Radix therefore separates shipping a protocol version from enacting it. The node supports two triggers (Node Protocol Updates):

• Unconditional enactment at the start of a given epoch – used for genesis, test environments, and hard-coding upgrades after the fact.
• Validator readiness-signal enactment at the start of an epoch – the standard mechanism for mainnet.

Under the readiness mechanism, each validator owner calls their validator component with a readiness signal – a unique string derived from the protocol version and its trigger condition, not merely the update’s name. Each validator holds at most one such signal at a time. Enactment then requires three conditions to line up at an epoch boundary:

• lower_bound_epoch_inclusive – the earliest epoch at which the update may be enacted.
• upper_bound_epoch_exclusive – the epoch at which the update stops being enactable, closing the voting window.
• 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 are signalling, and have been for that many consecutive epochs.

Every mainnet update so far has used a 75% stake threshold. The final consensus proof before the switch signs off on the enactment itself, so the outgoing epoch cannot end unless a quorum agrees the update should proceed. The update then commits zero or more batches of system "flash" transactions, which write the new engine substates directly.

Enacted Updates

The enactment windows configured for mainnet were [70019; 74051) for Anemone, [104291; 112355) for Bottlenose and [158682; 161562) for Cuttlefish (Node Protocol Updates). Other networks, including Stokenet, carry their own configurations and receive each update ahead of mainnet.

Anemone (February 2024)

Anemone was the first update after Genesis, enacted at epoch 70575 on 7 February 2024 with a comparatively short four-day readiness requirement. It was a small, mostly corrective release (Radix Docs):

• Corrected the validator creation cost to 100 USD.
• Brought basic BLS signature support to Scrypto.
• Allowed TimePrecision::Second when requesting the current time from Scrypto, where previously only minute precision was available.
• Tweaked the native pool blueprints to improve precision and their behaviour with resources whose divisibility is not 18.

It corresponds to Scrypto v1.1.0.

Bottlenose (June 2024)

Bottlenose was enacted at epoch 105353 on 7 June 2024. Its headline addition was a native blueprint (Radix Docs):

• The new Account Locker native blueprint, which lets a dApp make resources available to an account without the recipient having to accept a deposit in advance.
• A new API for reading a component’s owner role from Scrypto.
• New substates exposing the current protocol-related parameters, so on-ledger code can observe which rules are in force.
• A recovery fee vault on the Access Controller, removing the need for third-party fee locking during a recovery.
• Various improvements to the Account and Transaction Processor native blueprints, and to the Radix Engine implementation.

It corresponds to Scrypto v1.2.0.

Cuttlefish (December 2024)

Cuttlefish is the largest post-Babylon update to date and the most recent one enacted. It shipped in two parts back to back – logical names cuttlefish and cuttlefish-part2 – and went live on mainnet at epoch 160923 on 18 December 2024 (Radix Docs). What it changed:

• The Transaction V2 format. A transaction becomes an intent tree – a root transaction intent plus child subintents – together with the pre-authorization flows a dApp uses to propose a subintent and have the wallet review and sign it. This is the mechanism behind Anthic Flash Liquidity.
• Balance getters on the native Account blueprint, so on-ledger code can read an account’s balances directly.
• CryptoUtils – blake256 hashing plus Secp256k1 and Ed25519 signature validation available to Scrypto.
• A consensus-manager tweak to the minimum rounds per epoch, making it substantially harder for the network to miss the five-minute epoch target.
• Various further improvements to the Radix Engine implementation.

Cuttlefish corresponds to Scrypto v1.3.0. The client libraries released alongside it:

A Note on Cuttlefish’s Enactment Epoch

The Cuttlefish docs page lists its enactment epoch as 105353. That figure belongs to Bottlenose, and appears to have been carried over in error; this page uses 160923, which two independent checks support.

• The mainnet Gateway API reports, for a POST /stream/transactions query anchored to that timestamp, epoch 160922, round 2115 at 2024-12-18T10:48:57.955Z – the moment immediately before the published enactment timestamp of 2024-12-18T10:48:58Z. Epoch 160923 opens seconds later, at 2024-12-18T10:49:01.607Z. Epoch 105353, by contrast, opened on 2024-06-07T10:32:48.388Z, matching Bottlenose.
• The configured Cuttlefish enactment window is [158682; 161562) (Node Protocol Updates). 160923 falls inside it; 105353 does not, and instead sits inside Bottlenose’s [104291; 112355).

Anyone querying historical ledger state around the update – or reasoning about which rules applied to a given transaction – should use 160923.

Node Releases Since Cuttlefish

A node release and a protocol update are not the same thing, and the two have diverged since December 2024. Cuttlefish shipped in node v1.3.0 and remains the enacted protocol version, but babylon-node has published four further releases since, every one of them described in its own notes as an opt-in minor release – meaning it changes how a node runs, not what the network agrees, and so requires no readiness signalling from validators and no action from anyone who does not want the change.

No v1.3.0.3 was ever published. The fifteen-month gap between v1.3.0.2 and v1.3.0.4 is the more visible feature of the sequence, and the last of these releases is dated a month after the Radix Foundation moved to maintenance mode on 28 April 2026 – see Radix Ecosystem Operational Status for what that shift covers.

The disk-space option in v1.3.0.5

The one release that changes anything a node operator has to decide about is the last. v1.3.0.5 adds the flag db.keep_previous_substate_values, bound to the Docker environment variable RADIXDLT_DB_KEEP_PREVIOUS_SUBSTATE_VALUES and defaulting to true. Set it to false and the node stops recording the previous value alongside the new one when it writes a substate change action, which is where the disk saving comes from. The cost is confined to the Core API: a request that sets the previous flag will get no previous value back for any change action persisted while the setting was off. Substate history already stored is unaffected, and the flag can be turned on and off freely.

Ledger growth is the reason that option matters now. On 16 August 2026 the operator of the community-run Stokenet reported that its ledger is growing by an estimated 320 GB a year against roughly 110 GB in previous years, and announced a full reset of the test network on that basis.

Dugong (In Development)

Dugong is the next update in the alphabetical sequence. As of this writing its docs page lists its status as In Development, with enactment epoch, timestamp, main changes and release notes all still marked "TBC" or "To follow". No readiness signal has been configured for mainnet.

Radix’s protocol work has since re-centred on Xi'an and the sharded architecture it introduces, so the scope Dugong eventually carries is not yet settled in public material. Nothing beyond the placeholder entry should be assumed about its contents.

See Also

• Subintents and Pre-authorizations
• Radix Mainnet (Babylon)
• Radix Mainnet (Xi’an)
• Stokenet
• Radix Engine
• Locker

External Links

• Protocol Updates – Radix Docs
• Node Protocol Updates (readiness signalling) – Radix Docs
• Anemone – Radix Docs
• Bottlenose – Radix Docs
• Cuttlefish – Radix Docs
• Dugong – Radix Docs