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, Dugong – still in development, and skipped – and Eagle Ray, enacted on 11 September 2026. 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 enacted by readiness signalling has used a 75% stake threshold; the one update enacted without it, Eagle Ray, is the subject of the paragraph below. 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.

Eagle Ray breaks that pattern, and the reason is mechanical. Readiness is counted in required_consecutive_completed_epochs_of_support, and a halted network completes no epochs, so an update whose purpose is to end a halt could never satisfy a readiness threshold. The mainnet configuration released in node v1.4.0.0-RC1 therefore gives Eagle Ray EnactAtStartOfEpochUnconditionally at epoch 339,898 – the trigger described above as reserved for genesis and test environments – and pairs it with a UserTransactionMoratorium, a mechanism new to the node, covering the single epoch 339,897. The node defines that record as an epoch range during which user transactions are refused. Stokenet’s copy of the same update keeps ordinary readiness signalling, under the signal 8ed71bbdf45861cb0000000eagle-ray at 80% of stake for ten consecutive epochs, so the departure is mainnet’s alone and is a response to the halt rather than a change of policy.

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.

Eagle Ray has no such window: it was configured as EnactAtStartOfEpochUnconditionally at epoch 339,898 and so was never open to a vote. What each update changed about the engine’s versioned system logic is set out at System Layer.

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 was the most recent one enacted until Eagle Ray in September 2026. 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.

Pull request #1076 against babylon-node, merged into main on 8 September 2026 and released as v1.4.0.0-RC1, removed the placeholder line that had held Dugong's slot in the mainnet and Stokenet configurations and put Eagle Ray there instead, so neither network now carries a trigger for Dugong.

Eagle Ray (Enacted, September 2026)

Eagle Ray is the sixth name in the sequence, the only one so far written while the network it targets was stopped, and the only one enacted on an epoch number rather than on a vote of the validator set. It went live on mainnet at epoch 339,898 on 11 September 2026, eleven days after the halt that produced it and four days after the Scrypto release that carried it. Its whole history runs from the halt of 31 August 2026 to the release of 7 September: pull request #2093, “0xOmarA/vault access”, was opened against radixdlt-scrypto’s develop branch on 2 September by 0xOmarA, sat unreviewed for five days, and was merged at 17:33 UTC on 7 September 2026. Scrypto v1.4.0 (Eagle Ray) was tagged from the merge commit and published ninety seconds later, the first Scrypto release since v1.3.1 in January 2026. Its release notes carry the repository’s licence text and nothing else, and docs.radixdlt.com/docs/eagle-ray still answers HTTP 404, so the code is the only published account of what the update does.

The update itself is small, and the diff is misleading about that. It touches 587 files and adds 58,244 lines, but 538 of those files are regenerated transaction-scenario receipts and manifests under radix-transaction-scenarios/generated-examples/eagle-ray/ – the expected output of every existing scenario, re-recorded under the new protocol version. The engine change is radix-engine/src/updates/eagle_ray.rs, 80 lines, plus 43 in the system callback. Nine new cost files under radix-engine-tests/assets/metering/eagle-ray/ re-measure the fee schedule for the same scenarios.

EagleRaySettings carries one setting, a system-version update, and its single batch flashes a replacement SystemBoot substate onto the boot-loader partition of the transaction tracker, advancing the system logic from SystemVersion::V4 to V5 while carrying the previous parameters across. No blueprint is published and no ledger state is migrated. ProtocolVersion::LATEST becomes EagleRay, ahead of Dugong.

V5 enables exactly one behaviour, should_check_method_receiver_access. Before an invocation proceeds, the system asks whether the calling frame can actually see the node whose method it is about to call: a Direct method – the type used for recall and other direct vault access – requires direct visibility of the receiver, ordinary Main and module methods require ordinary visibility, and roots, functions and blueprint hooks are exempt. A call that fails is rejected with a new error, SystemError::InvalidInvokeAccess. What that replaces is legible in the test suite: test_recall_on_internal_vault previously expected the attempt to die deep in the kernel’s frame construction, at PassMessageError::DirectRefNotFound, and now expects InvalidInvokeAccess instead. The same pull request narrows a Dugong behaviour that had been written as “V4 and later” to V4 alone, with the comment that Dugong’s V4-only behavior must not carry into later versions.

A Scrypto release is not a protocol update reaching a network, and the second half followed a day later. Pull request #1076 against babylon-node, the implementation every validator runs, opened at 06:00:59 UTC on 8 September 2026 and pins the node's engine dependency to Eagle Ray v1.4.0. It was opened against develop, retargeted to main at 15:24:57 UTC and merged there at 15:28:11 by its own author, with no reviews and no comments recorded: 15 commits, 79 files, +4,275/−247. Seven minutes later babylon-node published Eagle Ray v1.4.0.0-RC1, its first release carrying a protocol change since v1.3.0 and the first build of the fix an operator can install; container images reached Docker Hub by 16:23 UTC. It is flagged a pre-release, so the repository's latest release still resolves to v1.3.0.5-test.1. Mainnet was still stopped at that point: read at 19:06 UTC on 8 September 2026 the Gateway status endpoint returned state version 557,840,622 at epoch 339,896. That figure is the Gateway's own read position, not the ledger's – the chain had in fact committed five more states, ending at 557,840,627 in epoch 339,897 at 21:19:48.939 UTC on 31 August. See Verifiability.

That pull request is where Eagle Ray's enactment is written down. On mainnet the trigger is EnactAtStartOfEpochUnconditionally at epoch 339,898, two past the halt, which makes it the only entry in the mainnet configuration that enacts on an epoch number rather than on validator readiness. It arrives with a mechanism new to the node, a user transaction moratorium, set for the single epoch 339,897: consensus runs, and user transactions are refused in the mempool and in the pacemaker's vote alike. On Stokenet the trigger is the usual readiness signal, 80% of stake sustained for ten consecutive epochs. Both figures are unchanged between the open branch and the released commit. The halt page follows the sequence day by day.

The council that has been running the response read the release the same evening and told the network not to read a restart into it. In a status update posted at 20:45:41 UTC on 7 September, the Radix Accountability Council confirmed its developers had seen Eagle Ray land and said that’s not enough: a build ready for general deployment has moving parts that are not ready, the testing has advanced but is not finished, and the reviews under way are incomplete. It named no date.

Enactment, read from the ledger

The switch is legible in mainnet's own transaction stream, and it is worth reading there rather than from a status page, because the moratorium makes "the network is back" two separate events four minutes apart.

Consensus returned first and carried no user traffic: epoch 339,897 completed under the moratorium, and the fork enacted at the boundary into 339,898 exactly as EnactAtStartOfEpochUnconditionally specifies. The gap between the two reads as sixty-six states and three minutes fifty-six seconds. A node that had not upgraded had nothing to signal and nothing to vote on; the epoch number did the work.

The only published confirmation that V5 took is a rejected transaction. docs.radixdlt.com/docs/eagle-ray still answers HTTP 404, re-checked 12 September 2026, and no release announcement followed. What is on the record instead is a test run in the open: on 11 September a node runner published a Vault Drainer blueprint to mainnet (announced in the Radix Developer Discussion group; the publishing transaction committed at state version 557,842,200, epoch 339,909) and submitted a draining transaction against it. The Gateway records that transaction as PermanentlyRejected and names the reason:

ErrorBeforeLoanAndDeferredCostsRepaid(SystemError(InvalidInvokeAccess))

InvalidInvokeAccess is the error SystemVersion::V5 introduces and nothing before it can return. Mainnet returning it is the receiver check running. See Authorization and Access Rules for what the check tests, and Hyperlane asset drain and network halt for the sequence that produced it.

Read at 11:07 UTC on 12 September 2026 the network stood at epoch 340,179, state version 557,923,055, and /state/validators/list answered HTTP 200 after returning 500 for the length of the halt.

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
• radixdlt-scrypto pull request #2093 – the Eagle Ray protocol update and the receiver check