RADIX WikiRADIX Wiki

This page indexes every project page on this wiki under Ecosystem by whether the project is still running. It exists because the wiki already recorded the answer one page at a time, and nobody could read it as a list: on 3 August 2026 a Radix holder asked in the hyperscale-rs channel for "a list of which Radix dapps are still operational and which have been abandoned", so that the dApps that are still around could be part of the migration conversation, and a second member asked this wiki to curate it.

The question has a deadline attached. Xi’an replaces the Radix Engine with a purpose-built VM (t.me/hyperscale_rs/10334), and existing dApps are expected to migrate rather than carry over untouched (t.me/hyperscale_rs/10346). Which teams are still present to do that migration is a different question from which contracts are still deployed, and this index answers the first one.

The network halt of 31 August 2026

Radix mainnet stopped producing rounds at 21:19:48 UTC on 31 August 2026 and restarted at 11:35:28.96 UTC on 11 September 2026, 254 hours and 15 minutes later. User transactions resumed four minutes after that, at 11:39:25 UTC, when the Eagle Ray fork enacted at the start of epoch 339,898. The restart is recorded in full on the incident page; the running account below is kept as it was written, reading downwards from the first day. Validators holding more than two thirds of stake broke liveness deliberately, hours after every Hyperlane-bridged asset on the network was drained through a flaw in the Radix Engine. Read again at 23:09 UTC on 3 September, the Gateway status endpoint returns the same last committed ledger it returned two days earlier, state version 557,840,622, epoch 339,896, round 102, and a read of /state/entity/details answers HTTP 500 with the sentence “it is currently 3 days, 1 hour, 50 minutes, 21 seconds behind”: a sync delay of 265,821 seconds against the 720 the Gateway will tolerate.

What a restart requires, as the Radix Accountability Council put it on 3 September. In a status update at 16:02 UTC the RAC said the root cause is identified, verified and confirmed, and that a code fix is built but still under review and intensive testing. It named the hard part as enactment rather than the patch: closing the hole “safely, consistently and in a way that no attacker can inject any tx in the network before the corrected protocol is enacted”. Restarting then needs the node runners back, and they are not the council's to instruct. They “need to review, accept and be in accord with the implementation plan”, because “this is a permissionless network and node-runners are independent”. No date was given, and the update says so in terms: “Still no hard date to commit to.”

The council said it again at 11:02 UTC on 4 September, nineteen hours later and eighty-five hours into the halt. The testing “is still ongoing and still no date we can commit to”; the council thanked everyone who had sent in details, ideas and validations, asked that everyone “operate with a high degree of containment on all of this until it’s fixed and running proper”, and asked that the post-mortem wait until the end. On the other business it carries, it reported no relevant updates and repeated the call to join the discussion phase of the governance-framework ratification. The message is authorship-verified at its public embed as projectShift, the author of the 3 September update as well.

Nothing on the ledger moved in between. Read at 11:03 UTC on 4 September, the Gateway returns the same last committed ledger for an eighteenth consecutive check – state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC – and /state/validators/list answers HTTP 500 at a sync delay of 308,671 seconds against the 720 the Gateway tolerates.

An hour later, in the main channel, the same council member corrected a reader who had inferred from this wiki and the public repository that the fix was already in place. “Fix is not implemented, that's not true” came the reply, declining to say what the fix does and adding that review will be possible, though not necessarily as a diff published for node runners ahead of the restart, which is what the reader had asked for (t.me/radix_dlt/1001786). Both messages were authorship-verified at their public embeds. That held until 11 September: no status on this page could be confirmed against the ledger until the restart landed.

Day five, and the ledger has still not moved. Read at 23:03:46 UTC on 4 September, the Gateway returns the same last committed ledger for a twenty-first consecutive check — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — ninety-seven hours and forty-four minutes without a committed round, and /state/validators/list answers HTTP 500 at a sync delay of 351,880 seconds against the 720 the Gateway tolerates. The 11:02 UTC update above is still the council's latest word twelve hours later, and the developer channels have added nothing to it: the traffic there since has been about red-teaming and bug bounties rather than the restart.

The front-end census, re-run at ninety-seven hours. The same probe run at thirty hours on 2 September is unchanged in almost every row. Eleven static shells still answer 200 through their own redirects — Ociswap, Astrolescent, app.weft.finance/market, Surge, DeFiPlaza, dex.reddicks.meme, RadQuest, RadixScan, RadixPlanet and the Radix Wallet site. The pages that have to resolve current state still do not: Astrolescent's per-token page returns HTTP 500, and app.caviarnine.com still refuses the connection, which is CaviarNine's own wind-down rather than the halt. The single change in four days is a failure changing shape rather than clearing: stats.defiplaza.net now returns HTTP 500 after twenty seconds where it previously timed out. A front end that keeps serving while nothing underneath it can settle is exactly the reading this page warns against treating as liveness.

The statuses below have deliberately not been changed for it. What each one records is whether a project is still being operated by the people behind it — which is the question this index exists to answer, and the question a migration conversation turns on. Whether a project can settle a transaction today is a different question with the same answer for all 147 of them: no, because the ledger has stopped. Re-bucketing the directory would replace 147 project-level judgements with one network-level fact and lose the first without adding the second.

Two of the three checks described above are unavailable while the halt lasts. Validator registration and on-ledger token supply are both read through the Gateway, and the Gateway refuses to serve state it believes is more than twelve minutes stale, so /state/validators/list and /state/entity/details answer NotSyncedUpError rather than an old figure. Those checks resume when the network does. The website probe still runs and still proves exactly as little as it did before — more so now, because a static front end keeps answering 200 with no ledger underneath it: on 1 September the Ociswap, Astrolescent, Weft, RSwap, Surge, RadQuest and Radix Dashboard front ends all served normally while every page among them that had to resolve current state returned an error.

Day six, and the ledger has still not moved. Read at 07:03:18 UTC on 5 September, the Gateway status endpoint returns the same last committed ledger for a twenty-third consecutive check — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — one hundred and five hours and forty-four minutes without a committed round, and /state/validators/list answers HTTP 500 at a sync delay of 380,683 seconds against the 720 the Gateway tolerates. Stokenet is unaffected and advancing normally, at epoch 2,247 and state version 5,580,586 in the same pass. The 11:02 UTC update of 4 September is still the council’s latest word, twenty hours later.

The lists below were rebuilt from the directory on 5 September rather than incremented. This page states above that it is generated from the status field on each project page, and between the 23 August rebuild and today it was kept up by hand instead: three pages added to the directory since — Hyperlane, RSwap and Run Fly — had never been indexed at all, and five entries were still listed as operational after their own pages had moved on (CrumbsUp, PokerXRD, Radix List and The Meme Studio to dormant, Academia Scrypto to closed). Re-reading every page’s own field moves the headline from 61 / 8 / 44 / 34 over 147 to 59 / 8 / 48 / 35 over 150. That Hyperlane in particular was missing is worth stating plainly: the bridge whose drain preceded the halt had no line in the network’s own operational index.

Day eight, and the protocol update that carries the fix has been released without the node software to run it. At 17:35 UTC on 7 September the Radix engine repository published Scrypto v1.4.0, "Eagle Ray". Three hours later the Radix Accountability Council told its own channel that the release is not the restart: developers had spotted "that the Eagle is landed", which it glossed as the code name for the protocol upgrade that will get the network fixed, but "that's not enough" – a lot of moving parts are not ready, the testing is not done, the reviews are not complete, and there is still no date it can commit to. The node software is the missing half: babylon-node's latest release is still v1.3.0.5 of 1 June 2026, and a validator operator installs a node release rather than an engine tag.

Read at 03:08 UTC on 8 September, the Gateway returns the same last committed ledger it has returned since the stop – state version 557,840,622, epoch 339,896, round 102 – one hundred and seventy-three hours and forty-nine minutes without a committed round, and /state/validators/list answers HTTP 500 at a sync delay of 625,745 seconds against the 720 the Gateway tolerates. Stokenet is unaffected and advancing normally, at epoch 3,063 in the same pass.

Read at 03:10 UTC on 9 September 2026, the Gateway returns the ledger it has returned since the stop, state version 557,840,622 at epoch 339,896, round 102, one hundred and ninety-seven hours and fifty-one minutes without a committed round; /state/validators/list answers HTTP 500 and now says so in words, reporting itself "8 days, 5 hours, 51 minutes behind" at a sync delay of 712,260 seconds against the 720 it tolerates. Stokenet is advancing normally at epoch 3,352.

The node software exists now, and it is flagged a pre-release. The paragraph above is superseded: at 15:35 UTC on 8 September babylon-node published v1.4.0.0-RC1, its first release since 1 June 2026 and the build that carries Eagle Ray. Because it is marked a pre-release, GitHub’s /releases/latest still resolves to v1.3.0.5-test.1, an empty tag cut by a bot three hours earlier, and so does ghproxy.radixdlt.com, which is what the babylonnode installer reads. Both were re-checked at 03:04 UTC on 9 September and both still return the test tag.

The front-end census, re-run at one hundred and ninety-eight hours. Every row is unchanged from the ninety-seven-hour reading except one, and the change is a recovery rather than a failure: stats.defiplaza.net/pools/radixplaza answers HTTP 200 in about a second, where it returned HTTP 500 after twenty seconds on 4 and 5 September and timed out on 2 September. What it serves is the reason this page exists. The dashboard prints $110K of total value locked in its header and $0.000 of total value locked "Today" in the chart below it, over a pairs table with no rows, and the two trackers covering those pools now disagree about them by 74%. Astrolescent’s per-token page still returns HTTP 500 and app.caviarnine.com still refuses the connection, which is CaviarNine’s own wind-down. The other ten shells still answer 200, and still resolve nothing.

Day ten, and the fix has cleared a test network and shipped as a final release. At 18:43 UTC on 9 September the Radix Accountability Council reported its first milestone: the new node software and the protocol update were deployed on Stokenet and the whole scenario validated end to end, with the next steps named as a final commit for the release, a date, and then a mainnet plan. It asked operators not to run release candidates on their own nodes and to wait for official final versions and instructions.

That final version arrived nine hours later. babylon-node v1.4.0.0 was published at 03:59:09 UTC on 10 September 2026, with container images pushed between 04:31 and 04:50 UTC. It tags commit 7400951e, which is the commit the 8 September candidate already tagged, so the code is the code operators could have installed two days earlier; what the final release changes is the pre-release flag. Removing it fixes something this page recorded as broken: GitHub reports as latest the newest release that is neither a draft nor a pre-release, and for two days that was v1.3.0.5-test.1, an empty tag cut before the fix. Read at 07:06 UTC on 10 September, both GitHub and the ghproxy.radixdlt.com mirror that the babylonnode installer reads return v1.4.0.0.

The first statement of when is not a date. At 05:52 UTC on 10 September, in the main Radix Telegram group, Timan Rebel said the Stokenet upgrade had gone smoothly and that mainnet is close to coming back: it needs coordination with the node runners, so it will not be today, but he hopes it can be done in the coming days. Rebel runs the DEX aggregator Astrolescent rather than speaking for the Radix Foundation or the council, and no dated restart has been published by either; nothing has appeared on the Foundation's announcement channel in the two days to this reading.

The ledger has not moved for any of it. Read at 07:07:53 UTC on 10 September, gateway-status returns the ledger it has returned since the stop, state version 557,840,622 at epoch 339,896, round 102, two hundred and twenty-five hours and forty-eight minutes without a committed round; /state/validators/list answers HTTP 500 at a sync delay of 812,927 seconds against the 720 the Gateway tolerates, and reports itself 9 days, 9 hours and 48 minutes behind. Stokenet is advancing normally at epoch 3,687.

Operators were cleared to upgrade at 16:15 UTC on 10 September. The Radix Accountability Council told node operators to upgrade to the latest software version from official sources, to check the dedicated validator chat for further detail, and to leave a node online and working once it is fully upgraded. That is the third of the four repair steps the council named on 1 September. The ledger is unchanged by it: read at 19:08 UTC, gateway-status still returns state version 557,840,622 at epoch 339,896, and the fourth step, a coordinated return to liveness, has no published date.

The restart is now a number rather than a date. At 20:18 UTC on 10 September, four hours after operators were cleared to upgrade, StakeSafe's Bart Roozeboom announced in the main Radix Telegram group that the operator's free Radix Network Dashboard now tracks Eagle-Ray adoption live, and stated the condition: Once more than 67% of active stake is on Eagle-Ray, network liveness resumes and the network forks to a patched version. The threshold is the two-thirds quorum consensus needs to commit a round, which is the same fraction that stopped the network on 31 August. Read from the dashboard at 23:08 UTC on 10 September, 1,260,200,690 XRD is running v1.4.0.0 — 27.03% of the 4,663,021,341 XRD of stake in the active validator set, across 28 validators — while 32.58% of that stake has a node online at all. The remaining forty points are mostly behind nodes that are switched off rather than nodes on the wrong version, which is why the council's instruction is to leave an upgraded node online and working rather than merely to install the release. The ledger has not moved for any of it: read at 23:04:40 UTC on 10 September, gateway-status returns state version 557,840,622 at epoch 339,896, round 102, two hundred and forty-one hours and forty-five minutes without a committed round.

What the threshold triggers is already written into the node software, and it does not go to a vote. babylon-node v1.4.0.0 carries the switch in its mainnet protocol config: Eagle Ray is set to enact at the start of epoch 339,898 unconditionally, which makes it the only mainnet protocol update in Radix's history that does not wait for validators to signal readiness. Readiness is counted in completed epochs, and a halted network completes none, so a readiness vote could not have been used here. The same file declares a user transaction moratorium covering epoch 339,897 – an epoch range during which user transactions are refused. The two entries give the restart its order: once validators holding more than two thirds of active stake are online and running v1.4.0.0, consensus can certify rounds again and resumes inside epoch 339,897; that epoch produces rounds but accepts no user transactions; and at the start of epoch 339,898 the fork enacts and the moratorium ends together, so wallets, dApps and exchanges see transactions accepted again on the patched engine rather than at the moment liveness returns. Two node operators set out that sequence in the Radix Developers group on 11 September, one reading it from the code and Daffy confirming that the quorum for the fork is the same two thirds and that there will be no announcement before liveness returns, because the moment cannot be predicted. Read at 07:07 UTC on 11 September, gateway-status returns state version 557,840,622 at epoch 339,896, round 102, two hundred and forty-nine hours and forty-seven minutes without a committed round, and the adoption tracker reads 1,455,804,324 XRD on v1.4.0.0, 31.22% against the 67% the restart needs.

The restart is gated on a coordinated boot, not on a climb, and the largest validators are upgraded and deliberately offline. At 10:11:24 UTC on 11 September, answering a node runner asking in the main Radix Telegram group why the ten largest validators could not spare ten minutes to update, Faraz said the state is intentional: The largest nodes are upgraded and waiting to boot up together once we have a decent amount of stake online from the remaining nodes. The stated aim is to come back well clear of two thirds rather than barely over it, because crossing the threshold marginally risks a node falling over and triggering another liveness break, and a few large nodes are easier to coordinate than a long tail of small ones. Daffy had answered the same question sixteen minutes earlier: the update is planned this way, and any conclusion about a validator still on v1.3 should wait a week after the network is live. That changes how the adoption chart reads. Published adoption can sit well short of 67% right up to the moment it clears, because the stake that closes the gap sits behind nodes that are down on purpose, so the tracker measures the tail's progress rather than counting down.

The numbers behind that, read at 11:05 UTC on 11 September: the adoption tracker reads 1,528,203,682 XRD on v1.4.0.0, 32.77% of the active validator set, with 39.65% of that stake having a node online at all; adoption rose 72,399,358 XRD in the preceding four hours and every XRD of it came from outside the twelve largest validators, which still hold 2,073,397,318 XRD and still read a v1.3 version and offline. The shortfall to the 3,124,224,298 XRD that more than 67% comes to is 1,596,020,616 XRD. Eighteen validators holding 327,184,952 XRD, 7.02% of the set, read online on a v1.3 build, which is the one reading the version column gives unambiguously and the group the council's upgrade instruction is aimed at. Read at 11:05:08 UTC, gateway-status returns state version 557,840,622 at epoch 339,896, round 102: two hundred and fifty-three hours and forty-six minutes without a committed round.

The restart, read at 13:10 UTC on 11 September. gateway-status returns a moving ledger for the first time since 31 August, and the transaction stream puts the boundary at two consecutive entries: state version 557,840,627 at epoch 339,897 round 4, timestamped 21:19:48.939 UTC on 31 August, then state version 557,840,628 at epoch 339,897 round 5, timestamped 11:35:28.96 UTC on 11 September. The five state versions between 557,840,622 and 557,840,627 are the ones the Gateway's status reading never showed, which is why the halt time cited on this page through the outage was forty-three seconds early. Epoch 339,897 then ran rounds 5 to 106 as empty blocks under the user transaction moratorium, and epoch 339,898 round 2 committed 17 user transactions at 11:39:25.129 UTC, five of them failing as the waiting queue cleared. The adoption tracker reads 3,737,284,159 XRD on babylon-node v1.4.0.0, 80.85% of a 4,873,528,908 XRD active set, against 32.77% two hours earlier: the tail did close in a rush, as the operators said it would. The Radix Accountability Council announced the restart at 14:37 UTC, three hours later, in a message that also reports its own attempts to run the exploit against mainnet, all of which failed. On the exchanges it says only that the Foundation is working with them and with the market makers, and that when deposits and withdrawals return is each exchange's own decision, so the table below reports what each exchange currently does rather than when it will change.

What each status means

  • 🟢 Active — the project is running and reachable. For an organization rather than a dApp this means the entity still operates, which is not the same as operating at full strength: the Radix Foundation is listed as active and has been in maintenance mode since May 2026.
  • 🟡 Testnet · 🟠 In development · 🟡 Pre-launch — being built, not yet live on mainnet for general use.
  • 🟠 Dormant — the project has not shut down and has not been withdrawn, but shows no current development or operation. Contracts already deployed may still respond; nobody is answering for them.
  • 🔴 Closed — wound down, shut off, or abandoned outright. 🔴 Departed means the project still exists but has moved off Radix.

The status on each project page is the authority; this index only groups it. Where a page's status is wrong, correcting that page and rebuilding this one is the fix — the index is generated from those fields rather than maintained by hand.

How this is checked, and what it does not prove

When this page is rebuilt, every project that publishes its own website is probed — the ones listed as running and the ones listed as dead. On 2026-08-20, 62 of 63 live-claimed projects resolved (a further 6 publish no website to probe), and 34 of 41 dormant or closed projects also resolved. Any live-claimed project that failed is flagged inline in the lists below rather than quietly listed as operational.

Those two numbers are the reason this index is built from curated status rather than from uptime. A domain outlives the project on it: a closed project's site keeps answering until someone stops renewing, and answering proves only that. Ploughshare is the clean illustration — ploughshare.nz returned HTTP 200 on 2026-08-20, and the page it returned reads "Ploughshare is under maintenance". A crawler counts that as alive. Two stronger checks have been run on parts of the directory and are worth knowing about:

  • Validator registration is read from the ledger. Staking entries here are validators, and a validator can be delisted while its website stays up. Reading the registration flag for every validator address on this wiki in August 2026 found four holding roughly 47 million XRD of delegated stake while unregistered — earning no emissions for their delegators. See the individual pages for Topradixnode, Juicy Stake, Phoenix and RadixUID.
  • Token pages carry on-ledger supply. For entries in the Token category, the resource address in the page's infobox can be read directly on the Radix Dashboard — current supply and holder count are a better liveness signal than a landing page.

Per-dApp on-ledger activity — last transaction against each project's components — is not part of this index yet. It is the check that would answer the migration question properly, and it is the obvious next thing to add.

Testnet, pre-launch and in development (8)

DAO Platform

Finance

Infrastructure

Oracle

HydrateLast updated 1d agov1.20.024 revisionsVerified Sep 11, 2026