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.

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