Stokenet

Operational note, 29 August 2026: the full Stokenet reset is done. The network went down at 07:00 UTC on Saturday 29 August 2026 and was declared back online at 12:52 UTC, on a fresh genesis with four validators. Every balance, transaction and deployed package from before is gone; the network ID, the Gateway URL and your account addresses are unchanged. The ledger restarted at Babylon genesis, before any protocol update; Anemone, Bottlenose and Cuttlefish part 1 were all re-enacted by validator readiness signalling the same evening, and the AccountLocker native package exists again. The network runs the current node release with a patched genesis, so the published node instructions no longer work unmodified; the operator has since circulated a procedure for running a node against the new chain. The terms, the reset-day record and what a developer has to redo are in the “Full reset” section below.

Stokenet is the persistent public test network for Radix. Launched in July 2021, Stokenet serves as a sandboxed environment for Radix users and project builders to test applications and the latest versions of the Radix Node software.

History and Purpose

Stokenet was launched on July 7, 2021 to replace the Olympia Betanet. The name "Stokenet" is a nod to Stoke-on-Trent, England, the birthplace of Radix, paying homage to the project's roots and origins.

The primary purpose of Stokenet is to provide a parallel ledger version history to the Radix mainnet, allowing developers, node runners, and enthusiasts to interact with and validate the Radix network without the risk of impacting the actual mainnet operations. Stokenet features a faucet system that distributes free (test) $XRD tokens, enabling users to explore and test the network's capabilities without the need for real-world value transactions.

Technical Details

Connect to Stokenet

1. Download and install the Radix Wallet from https://wallet.radixdlt.com or by scanning the QR code below:

2. From the Settings ⚙️ menu, click on App Settings:

3. Switch on Developer Mode:

4. Then click on Network Gateways:

5. Click on Add New Gateway:

6. Add the following gateway URL: https://babylon-stokenet-gateway.radixdlt.com

Get Test $XRD

1. Click on your Stokenet account:

2. Click on the menu in the top-right corner:

3. Click on ‘Get XRD Test Tokens’ at the bottom of the page:

Features

Stokenet offers a range of features that facilitate comprehensive testing and experimentation for the Radix ecosystem:

• Parallel Ledger Version History: One of the core features of Stokenet is its ability to maintain a ledger version history that runs parallel to the Radix mainnet. This ensures that developers and node runners can accurately simulate and test various scenarios without impacting the live mainnet operations.

• Faucet for Test $XRD: To enable seamless testing and exploration, Stokenet provides a faucet system that distributes free (test) XRD tokens to users. These test tokens have no real-world value but allow users to interact with the network, deploy smart contracts, and test various functionalities without the need for real-world value transactions.

• Community Node Runner Participation: Stokenet is designed to be an open test environment for the Radix community. Node runners interested in testing and practicing the operation of validator nodes can join the official Radix Discord and request stake allocation. However, it's important to note that stake on Stokenet is not guaranteed, and the Radix team may adjust or reset it as needed during testing phases.

• Different Address Prefix: To prevent accidental transfers between the Stokenet and the Radix mainnet, all addresses and IDs on Stokenet have a distinct human-readable prefix. This ensures that the test network addresses are clearly differentiated from mainnet addresses, mitigating the risk of unintentionally sending real tokens to a test network address or vice versa.

Developer Tooling

Stokenet's hosted web tooling was retired during 2026. Verified 30 July 2026: stokenet-console.radixdlt.com and stokenet-sandbox.radixdlt.com return HTTP 530 from the Cloudflare edge with no origin behind them, and stokenet-dashboard.radixdlt.com issues a redirect to the mainnet dashboard homepage, discarding both the network and the requested path. No Stokenet instance exists under radixscan.io either.

Mainnet's equivalents still resolve, but no longer from Radix: dashboard.radixdlt.com and console.radixdlt.com redirect (paths preserved) to community deployments run by RadixScan.

To get a Stokenet Dashboard or Developer Console, run one from radixdlt/dapps-monorepo (Apache-2.0): set PUBLIC_NETWORK_NAME=stokenet plus a Stokenet dApp definition address, then build with npx turbo run build --filter=console and run node apps/console/build, or deploy apps/console on Vercel with the Vercel SvelteKit adapter. The repository's README carries the full deployment guide.

Stokenet's Gateway itself is unaffected and still answers at babylon-stokenet-gateway.radixdlt.com.

Full reset – 29 August 2026

The reset was announced on 16 August 2026 without a date, on the commitment that one would follow “no later than seven days in advance”. It followed on 18 August 2026 at 17:57 UTC, when Daffy – who has hosted most of the community-run Stokenet since the Radix Foundation handed the network over during 2026 – posted the schedule to the main Radix Telegram group. The Radix Accountability Council relayed it to its own channel 24 minutes later, addressed to “the dev side of the community and those involved in acceptance tests and/or beta testing”. Eleven days’ notice was given against the seven promised.

The stated reason for moving early is that the rehearsal succeeded: a reset was tested on separate hardware to a fresh genesis, with four validators reaching consensus, a Gateway in sync and a dashboard showing live activity.

Schedule

The network goes down at 07:00 UTC (09:00 CEST) on Saturday 29 August 2026. The reset itself is quick; the operator is taking the window to do server maintenance as well, so several hours of downtime are expected. A developer whose launch plan the date breaks is invited to say so in the Radix Developer Discussion group, and the date will be reconsidered.

What survives, and what does not

The distinction that matters is between what is derived and what is stored. Addresses are derived from keys, so they survive; everything the ledger recorded against them does not.

The operator plans to repeat the exercise, but has given two different intervals: the 16 August announcement said 9–12 months, while on 3 September 2026 Timan Rebel, answering for the operator, said the reset was “to be able to keep it running < 1TB needed storage. It was a cost issue.. By heart the plan is to do this every 6 months or so” (t.me/radix_dlt/1001768, embed-verified) – the later figure explicitly from memory. Either way it turns what reads as a one-off cleanup into a standing property of the test network: a Stokenet deployment is expected to be disposable on a cycle measured in months rather than years, and anything a project needs to keep should live in its own source control rather than on the test ledger.

Background and the pre-reset ledger

The cause given on 16 August was ledger growth: Stokenet is now growing by an estimated 320 GB a year against roughly 110 GB in previous years (the message writes “320 GG”), and the operator stated plainly that the reason for the change is not known.

The pre-reset ledger is the one being discarded. Read live from the Stokenet Gateway at 19:05 UTC on 18 August 2026, eleven days before the reset, the network stood at epoch 254,681 and state version 424,218,910, served by node release v1.10.6, 1,335 epochs further on than the 16 August read of epoch 253,346. A reset is not a protocol upgrade and carries no new protocol version; it discards the test network’s accumulated state and starts its ledger again from genesis.

Resets of this kind were always in Stokenet’s terms – the network has never guaranteed persistence of stake or state, as the Community Node Runner Participation note above records. What has changed is who decides and who pays: the operation is community-run and funded by the Stokenet proposal that closed on 4 August 2026, not by the Foundation.

Reset day, 29 August 2026

The reset went ahead on the announced date. Daffy reprised it in the developer channel the evening before, at 19:45 UTC on 28 August, as the first Stokenet reset “in 3 years”, with validators, full nodes and Gateways all stopped for some hours for server maintenance alongside the new genesis. The same message gives the reason the Gateway cannot simply be rebooted around it: blue-green deployment of the Gateway was dropped as a cost saving, so the Gateway service and its database host have to be stopped to be patched at all.

A status update followed at 10:00 UTC on 29 August. Maintenance patching of the VMs and hosts was done and the new genesis was “verified working. Liveness proven”. Two operational consequences came with it. The Java source had to be recompiled to remove the old hash, so a new image distribution is needed for new validators. And because the existing network ID is being reused, the old validators are being cleaned out, which the operator says “require a new set of keys and a new genesis generation”. That is a departure from the 18 August announcement, which had said the same four validators would return reusing their existing keys; the operator has not said which of the two the restarted network will run, and nothing published so far reconciles them. The Gateway then needs about thirty minutes to sync, and more hours of downtime were expected past 10:00 UTC.

Read directly at 11:06 UTC on 29 August, the outage is as described. babylon-stokenet-gateway.radixdlt.com answers HTTP 521 with a sixteen-byte error code: 521 body, and so does stokenet.radixdlt.com, which resolves to the same three addresses. The Radix mainnet Gateway answers normally in the same minute, at epoch 339,198 and state version 556,718,397 on node release v1.10.6. That separation is the point of a separate test network: a Stokenet reset stops nothing on mainnet.

The reset-day statements above are Telegram messages in the Radix Developer Discussion group, each attributed to Daffy by the message’s own embed markup.

Back online, 29 August 2026

The network came back the same afternoon. A developer reported it reachable at 12:02 UTC, and fifty minutes later Daffy declared Stokenet back online – having waited for a fourth validator, run by Astrolescent’s Timan, to come up. He invited the channel to try deploying packages and noted that the genesis transactions are visible on the fresh ledger. Total downtime was a little under six hours against the “several hours” forecast.

Read directly from the Gateway at 15:05 UTC on 29 August 2026, babylon-stokenet-gateway.radixdlt.com answers HTTP 200 on node release v1.10.6 – the same release it served before the reset – at epoch 51 and state version 137,506. Set against the pre-reset read of epoch 254,681 and state version 424,218,910 eleven days earlier, that is the whole of the discarded history in two numbers.

The restarted validator set

Four validators are registered and no more, each carrying the placeholder metadata a fresh genesis writes – name Default validator 1 through 4, info_url pointing at radixdlt.com – and each holding about 1,000,035,860 test XRD at a fee factor of 1, which is 100%. Their addresses and secp256k1 keys, read at the same moment, are the record this page can offer against the next reset:

Whether these are the keys the 18 August announcement promised or the new ones the 10:00 UTC update described cannot be settled from the ledger, because the ledger that held the old set was discarded. The one pre-reset Stokenet validator address still recoverable anywhere – validator_tdx_2_1svff7mk…, from a dashboard page archived on 30 August 2025 – returns no entity on the reset ledger, and is not one of the four above. That is consistent with a new set of keys without proving it, since it cannot be shown to have been one of the four the announcement meant. Daffy said he would write up the details, and the write-up that followed on 30 August says the keys are new: a first attempt at the genesis reused the old ones, and he regenerated it with fresh node keys rather than leave the two chains sharing an identity. The section below has the document and what can be checked against it.

The ledger restarts before Bottlenose

The first thing developers found is the sharpest fact of the day. Publishing works: a package went on the reset ledger at epoch 33, 13:56 UTC, about an hour after the network came back, and the Digital Ownership Licence resource and component deployed from it are live and readable. But anything referencing the AccountLocker native package is rejected with ReferencedNodeDoesNotExist, as though it were not on the ledger.

It is not. Read at 15:09 UTC, package_tdx_2_1pkgxxxxxxxxxlckerxxxxxxxxxx000208064247xxxxxxxxx8jnpz0 returns no entity, while the account, pool and transaction-tracker native packages all return normally. AccountLocker arrived with Bottlenose, so the reset network has restarted at a protocol state that preceded it – at Babylon genesis, before Anemone, and the protocol updates have to be enacted again on the new ledger before the packages they introduced exist. The Gateway does not yet reflect this: its own /status/network-configuration still advertises locker_package at the address that answers with nothing. Until those updates land, a well-known address is not a guarantee that the entity behind it is there – which is a narrower version of the “all well-known addresses unchanged” promise in the terms above than the terms imply.

The protocol updates are re-enacted, 29 August 2026

They were re-enacted the same evening, and the ledger carries the whole sequence in three transactions. A Radix protocol update is adopted by validator readiness signalling rather than by a switch, so each update the discarded ledger had already taken had to be signalled again on the new one, in order. With all four validators of the restarted set under a single operator the 80% stake threshold was never a constraint: each transaction below signals readiness for all four at once. Read first-hand at the Stokenet Gateway:

The three transactions are txid_tdx_2_1rnx4wkep2x7pwth0ra5xtd37xlfs0dk563urxp845lhmjg5hfpzs973dnv, txid_tdx_2_1w9gs7wpcz2k74xgpp5y2n83zukxzyhafjkqw7v0y4gzjdrjeangsttvxsd and txid_tdx_2_1keas3c92lcf4kc582ze964s938lcuyk9ksgxvtk3hrt2qsx7zhkqghy8sr, each CommittedSuccess for about 0.42 test XRD in fees. Nothing else on the reset ledger has signalled readiness for anything: those three are the complete protocol history of the network as it stands.

Enactment followed the signalling within the hour in each case. Daffy reported Bottlenose active at 19:39 UTC – a minute after the Cuttlefish signal went in – and Cuttlefish “active within the next hour”. At 20:34 UTC a developer confirmed that packages referencing the AccountLocker blueprint deploy again, which is the failure recorded in the section above reversed by name. Read at the Gateway at 23:11 UTC, at epoch 181 and state version 530,719, package_tdx_2_1pkgxxxxxxxxxlckerxxxxxxxxxx000208064247xxxxxxxxx8jnpz0 returns an entity where eight hours earlier it returned none. The gap between the Gateway’s well-known address list and the ledger behind it, described above, has closed.

Only the first half of Cuttlefish is in scope. The channel recorded on the day that part 1 alone was needed, part 2 being a projected future update rather than something mainnet has taken, and the readiness signal on the ledger matches: it names cuttlefish, not a part 2 successor. So the reset network is now at the same protocol version as mainnet, reached in one evening from Babylon genesis rather than over the two and a half years mainnet took.

What the reset left in the wallet

The terms above said accounts survive and arrive empty. The first account holder to read them back asked whether that was a fault. At 23:16 UTC on 29 August, hours after the protocol updates went in, a developer reported every one of his Stokenet accounts present in the Radix Wallet and every one of them empty of tokens, NFTs, stake and pool units, with no historical transaction returned for any of them, and asked urgently whether the ledger data could be recovered. He confirmed three minutes later that the faucet mints for him, which places the loss in the history rather than in the network.

Daffy answered at 06:18 UTC on 30 August: “I can confirm that all the historical ledger data on Stokenet is wiped. That was the intention of the reset.” That is the operator stating after the fact what the 18 August announcement stated in advance, and it settles the one question the terms leave a user room to ask, which is whether an empty account is the reset working or the reset going wrong. It is the former, and nothing is recoverable from the network: a pre-reset Stokenet balance, package or transaction now exists only in whatever its owner kept off the ledger.

The node the network runs is not the node the instructions install, 30 August 2026

At 10:06 UTC on 30 August, a day after the reset, Daffy posted a status update: Stokenet “is running steady on V1.3.0.5 with an empty ledger and updated to cuttlefish through Validator signalling”. That version is the current official node release – Cuttlefish v1.3.0.5, published 1 June 2026 – so on version alone the reset network is exactly where it should be.

The binary is not the stock one, and the reason is a design detail of the node rather than anything about the reset. Keeping the name Stokenet meant keeping network ID 2, and the genesis for network 2 is compiled into the node binary with no flag to override it, so a fresh node built from the published image derives the discarded genesis for that ID and cannot join the ledger that replaced it. The operator’s fix was deliberately minimal: “a two-line overlay replacing one 538 KB jar, with everything else the unmodified official release, reversible by one image: line once an official build ships”. The consequence for everyone else is stated plainly in the same message – “the official instructions on radixdlt.com is not working any longer without doing some additional steps” – with those steps attached to the same message as a document, which the section below reads against the source and the ledger.

The documentation is further behind than one patched jar. Read on 30 August 2026, Docker Node Setup still publishes a Stokenet compose file that sets RADIXDLT_NETWORK_ID: 2, lists three seed hosts under radix.community (all three still resolve in DNS), and pins image: radixdlt/babylon-node:v1.2.1 – Bottlenose, May 2024, two protocol updates behind what the network now runs. A reader following the documented path today installs a two-year-old node for a network that needs a patched newer one, and the reset did not create that gap so much as make it impossible to ignore.

The same update notes that “more activity will normalize the epoch times back to 5 mins”, and the network is measurably running short of that. Read at the Gateway on 30 August, epoch 376 was at round 2,821 at 11:08:03 UTC and epoch 377 was at round 102 twenty seconds later, with rounds advancing at 14.05 per second over the preceding minute – an epoch of roughly 3 minutes 34 seconds. An epoch ends at whichever comes first: 3,000 rounds, or 300,000 ms once at least 500 rounds have happened (ConsensusManagerConfig::mainnet() in radixdlt-scrypto), and the measured boundary lands within a round or two of the 3,000 cap. On an idle network of four validators rounds complete far faster than the timer, so the cap binds and epochs come in short; traffic slows rounds until the five-minute target binds instead. The 5 minutes are not being restored by an operator, in other words, but by use.

What it now takes to run a Stokenet validator, 30 August 2026

The steps came with the status update itself. Attached to the same 10:06 UTC message is stokenet-new-validator-instructions.md, version 1.0, dated 30 August 2026 and addressed to community node operators. Its claim is that the official Radix documentation still applies and exactly three things differ: the node image has to be patched, the genesis has to be supplied as a file, and test XRD has to come from somewhere, because the reset destroyed every balance. Ahead of all three sits a warning about the chain that was replaced. It has not gone anywhere – it is frozen, nodes still gossip on it, and it will never advance – so an operator who ran Stokenet before 29 August has to wipe the ledger database, an existing one being the old chain by definition.

Three files carry the change, published to a DigitalOcean Spaces bucket rather than to any Radix domain. Fetched on 30 August 2026, common-v1.3.0.5.jar is 551,287 bytes (the 538 KB the operator quotes), genesis.bin is 669 bytes and the Dockerfile is 99, and each of the three matches the SHA-256 the document publishes for it. The Dockerfile is the whole patch surface and reads in full: FROM radixdlt/babylon-node:v1.3.0.5, then COPY common-v1.3.0.5.jar /opt/radixdlt/lib/common-v1.3.0.5.jar. Anyone unwilling to take the jar on trust is given the source route instead, and told in advance that a self-built jar will not match the hash, because Gradle stamps build times into it.

The reason a stock node cannot start is in the source, and it checks out at the tagged release. In Network.java at v1.3.0.5, Stokenet is the one network in the file whose genesis is written into the enum as data – FixedNetworkGenesis.constant(...), the payload base64-encoded inline. Mainnet and the dedicated genesis-test network pin a hash and a bundled file; the other twenty-odd networks pin nothing. RadixNodeBootstrapper then reads three genesis sources at startup – the one you configure, the one implied by network.id, and the one stored from previous runs – and throws Inconsistent genesis configuration if more than one distinct hash survives. Deleting that third argument from the one enum entry removes the second source and lets the file stand alone. The same three-source check is why the database wipe is not optional: a retained database supplies a hash of its own.

The document warns that the frozen chain’s genesis is a different genesis of exactly the same size, and it is. Decode the base64 constant out of Network.java at v1.3.0.5 and it comes to 669 bytes; genesis.bin for the reset chain is also 669 bytes, with different content. A file listing distinguishes nothing here. The published hash is the only thing that tells an operator which of the two chains they are about to join, which is why the instructions stop the reader at that check twice.

The compose fragment gives the three seed nodes as bare IP addresses, and resolving them settles a question this page has carried since reset day. 193.200.238.146, .147 and .148 are node1-, node2- and node3-stokenet.radix.community, the same three seed hosts the official Docker page still publishes, and all three accepted TCP on port 30000 when tested on 30 August. Same three machines, all-new identities: the node keys in the documented seed URIs (node_tdx_2_1qwz237kq…, 1qv89yg0la…, 1qv2g5srsn…) share nothing with the ones the operator now hands out (1q2237aq4h…, 1qfhupcz3w…, 1qfaxgqj0n…). The document gives the reason: the first attempt at a genesis reused the old keys and left the new chain sharing an identity with the frozen one – same network id, same node keys, same P2P port – so a stock node could rejoin the dead chain without saying so, and old-chain peers kept dialling the new one. Rotating the keys leaves the two chains nothing in common but the network id.

Most of the rest is configuration, and two items in it are worth reading even by someone who will never run a node. There is no protocol-update configuration at all: the network was carried from Babylon to Cuttlefish by on-ledger readiness signalling, so a syncing node re-derives those enactments from the ledger, and RADIXDLT_PROTOCOL_CUSTOM_CONFIG is to be left unset. And because every database on this chain starts empty, the document offers a lean validator profile – previous substate values, historical substate values, the local transaction execution index, the account change index and the entity listing indices all switched off – on the condition that the choice is made before the first sync. Turning them off later shrinks nothing already written; turning them on later leaves gaps, because the data was never written for the blocks already processed. A node that will back a Gateway keeps the defaults. The standard node setup covers everything else unchanged.

The last step is a person. The faucet mints, but not enough to create a validator, so the document ends by sending operators to Daffy on Telegram with an account address and a stake figure. A newly created validator is not in genesis either, so its address has to be named in RADIXDLT_CONSENSUS_VALIDATOR_ADDRESS and the genesis-derived flag left alone; the node joins the active set at the next epoch boundary if its stake places it in the top 100. On the chain as it runs today that boundary is the roughly three-and-a-half minutes measured above rather than the five the document rounds it to.

One date in the reference table cannot be checked against the thing it describes. The document puts the chain start at 11:22 UTC on 29 August 2026, and the ledger cannot confirm it: the genesis transactions are stamped at the Unix epoch, and the first wall-clock timestamp anywhere on the chain is 11:47:06.823 UTC, at epoch 3, round 444, state version 1,028. The document is clearer about its own expiry than about its start. A fork was refused deliberately, on the grounds that it would be a maintenance commitment and a far larger trust surface than one jar a reader can diff, and the overlay is meant not to outlive the need for it: when an official image ships for this chain, one image: line changes back and the genesis file, the seed list, the operator’s keys and the validator registration all stay valid.