# RADIX Wiki — Full Content Export > This is the full-text version of llms.txt for https://radix.wiki > 371 pages, last generated 2026-09-12 > License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) > Attribution: "Source: RADIX.wiki (https://radix.wiki), CC BY 4.0" > Full license text: https://creativecommons.org/licenses/by/4.0/legalcode ## Stokenet URL: https://radix.wiki/contents/tech/releases/stokenet Updated: 2026-09-12 Summary: 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 bac… DEVELOPMENT Launch Date July 07, 2021 (https://www.radixdlt.com/blog/stokenet-is-live) Antecedent RCNet (/contents/tech/releases/rcnet) License Radix License, v1 (https://github.com/radixdlt/babylon-node/blob/main/LICENSE) LEDGER State Model Sharded (/contents/tech/core-concepts/sharding) Shard Groups 1 (/contents/tech/core-concepts/shard-groups) Sybil Protection Delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) Consensus Protocol Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Execution Environment Radix Engine (/contents/tech/core-protocols/radix-engine) v2 Programming Language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Networking Babylon node (https://github.com/radixdlt/babylon-node) 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 (https://learn.radixdlt.com/article/what-is-stokenet) for Radix. Launched (https://www.radixdlt.com/blog/stokenet-is-live) 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 (https://learn.radixdlt.com/article/what-is-stokenet) on July 7, 2021 to replace the Olympia (/contents/tech/releases/radix-mainnet-olympia) Betanet. The name "Stokenet" is a nod to Stoke-on-Trent (https://www.radixdlt.com/blog/stokenet-is-live) , England, the birthplace of Radix, paying homage to the project's roots and origins. The primary purpose (https://learn.radixdlt.com/article/what-is-stokenet) 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 (https://www.radixdlt.com) without the risk of impacting the actual mainnet operations. Stokenet features a faucet system (https://www.radixdlt.com/blog/stokenet-is-live) that distributes free (test) $ XRD (/contents/tech/core-protocols/xrd-token) tokens, enabling users to explore and test the network's capabilities without the need for real-world value transactions. Technical Details Connect to Stokenet - Download and install the Radix Wallet (/contents/tech/core-protocols/radix-wallet) from https://wallet.radixdlt.com (https://wallet.radixdlt.com) or by scanning the QR code below: - From the Settings ⚙️ menu, click on App Settings: - Switch on Developer Mode: - Then click on Network Gateways: - Click on Add New Gateway: - Add the following gateway URL: https://babylon-stokenet-gateway.radixdlt.com (https://babylon-stokenet-gateway.radixdlt.com) Get Test $XRD - Click on your Stokenet account: - Click on the menu in the top-right corner: - Click on ‘Get XRD Test Tokens’ at the bottom of the page: Features Stokenet offers a range of features (https://www.radixdlt.com/blog/stokenet-is-live) 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 (/ecosystem/radixscan) . To get a Stokenet Dashboard or Developer Console, run one from radixdlt/dapps-monorepo (https://github.com/radixdlt/dapps-monorepo) (Apache-2.0): set PUBLIC_NETWORK_NAME=stokenet plus a Stokenet dApp definition address (https://docs.radixdlt.com/docs/dapp-definition-setup) , 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 (/contents/tech/core-protocols/radix-gateway-api) itself is unaffected and still answers at babylon-stokenet-gateway.radixdlt.com (https://babylon-stokenet-gateway.radixdlt.com) . Who runs it, and who pays Stokenet has been community-run since the Radix Foundation (/ecosystem/radix-foundation) handed the validators, the stake and the Gateway over during 2026. For several months afterwards it ran on one operator’s own account, uncompensated, while the entity meant to contract for it was still being formed – which is why the arrangement was put to a vote rather than left as a favour. The proposal that went on-ledger in July 2026 asks the Foundation for a fixed $4,000 in XRD covering May to December 2026: one Gateway, two supporting full nodes, three validators, redundant ledger and database backups and a monitoring node, all hosted in the EU/EEA, run on a best-effort basis at a stated 98–99.5% uptime with monthly reporting. The XRD would be staked rather than sold, the operator wrote, since selling was never the point – “had my intention been to sell, I would have requested stablecoins”. It is a revision of a 28 March 2026 proposal, repriced downward after two months of actually operating the network removed the unknowns. Without it, the proposal said, the Stokenet Gateway would be decommissioned in mid-August to limit further losses, leaving developers to stand up their own at an estimated $350–400 per month each. That deadline passed with the Gateway still answering, and it is still answering now. The vote closed on 4 August 2026 with 55 ballots and not one against, clearing its quorum comfortably; no funding decision has appeared in the Radix Accountability Council (/ecosystem/radix-accountability-council) ’s public updates since. The tally and the arithmetic behind it are on Radix Governance (/contents/tech/core-concepts/radix-governance) . A test network paid for this way is a test network that stops when one person stops, which is the standing condition the sections below are written under. Full reset – 29 August 2026 The reset was announced on 16 August 2026 (https://t.me/RadixDevelopers/65974) 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 (/ecosystem/radix-foundation) handed the network over during 2026 – posted the schedule (https://t.me/radix_dlt/998662) to the main Radix Telegram group. The Radix Accountability Council (/ecosystem/radix-accountability-council) relayed it (https://t.me/RadixAccountabilityCouncil/915) 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 (https://t.me/RadixDevelopers) 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. Unchanged The network ID (2), the Gateway (/contents/tech/core-protocols/radix-gateway-api) URL babylon-stokenet-gateway.radixdlt.com, and all well-known addresses – test XRD, the faucet, the native packages. No client reconfiguration is needed. Account addresses are derived from your keys and are unchanged. The same four validators return, reusing their existing keys. Destroyed All balances and transaction history; every resource (/contents/tech/core-concepts/resources) , package, component (/contents/tech/core-concepts/components) and dApp definition (/developers/frontend/04-dapp-definition-and-verification) ; and all on-ledger persona (/contents/tech/core-protocols/personas) data. Accounts still exist at the same addresses – they are simply empty. To redo Recreate personas in the Radix Wallet (/contents/tech/core-protocols/radix-wallet) , re-fund from the faucet, redeploy (/developers/getting-started/03-deploying) packages and components, and re-populate dApp definition metadata so the dApp verifies in the wallet again. 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 (https://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 (/contents/tech/releases/protocol-updates) ; 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 (https://t.me/RadixDevelopers/66061) , 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 (https://t.me/RadixDevelopers/66075) 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 (/contents/tech/core-protocols/radix-gateway-api) 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 (https://t.me/RadixDevelopers/66078) , and fifty minutes later Daffy declared Stokenet back online (https://t.me/RadixDevelopers/66079) – having waited for a fourth validator, run by Astrolescent (/ecosystem/astrolescent) ’s Timan, to come up. He invited the channel to try deploying packages (https://t.me/RadixDevelopers/66084) and noted that the genesis transactions are visible (https://t.me/RadixDevelopers/66083) 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 (/contents/tech/core-concepts/validator-nodes) 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: Default validator 1 validator_tdx_2_1sdtnujyn3720ymg8lakydkvc5tw4q3zecdj95akdwt9de362mvtd94 Default validator 2 validator_tdx_2_1sdvlm4e2x0mjr7mxkpfejz8m0tfwk0j937lxsw74t9lw3evhj5tlwk Default validator 3 validator_tdx_2_1svr6rmtd9ts5zx8d3euwmmp6mmjdtcj2q7zlmd8xjrn4qx7q5snkas Default validator 4 validator_tdx_2_1sdlkptcwjpajqawnuya8r2mgl3eqt89hw27ww6du8kxmx3thmyu8l4 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 (https://web.archive.org/web/20250830104810/https://stokenet-dashboard.radixdlt.com/network-staking/validator_tdx_2_1svff7mkddhm9dy325f3ckx72cxqsl49ewy74667pchqfkxl7wxpa8r/stake) – 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 (https://t.me/RadixDevelopers/66080) , 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 (https://t.me/RadixDevelopers/66088) , 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 (/contents/tech/releases/protocol-updates) , 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 (/contents/tech/core-concepts/validator-nodes) 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 (/contents/tech/core-protocols/radix-gateway-api) : Update Readiness signal Committed (UTC) Epoch / state version Anemone (/contents/tech/releases/protocol-updates) 811c31d2bc6a2631000000000anemone 17:46:25 95 / 268,868 Bottlenose (/contents/tech/releases/protocol-updates) 35701a6147bfd870000000bottlenose 18:29:38 107 / 304,255 Cuttlefish (/contents/tech/releases/protocol-updates) 034d3327f58995c6000000cuttlefish 19:38:20 125 / 359,543 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 (https://t.me/RadixDevelopers/66108) – a minute after the Cuttlefish signal went in – and Cuttlefish “active within the next hour”. At 20:34 UTC a developer confirmed (https://t.me/RadixDevelopers/66111) that packages referencing the AccountLocker blueprint (/contents/tech/core-concepts/blueprints-and-packages) 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 (https://t.me/RadixDevelopers/66106) , 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 (/contents/tech/releases/radix-mainnet-babylon) , reached in one evening from Babylon genesis rather than over the two and a half years mainnet took. Why one evening was enough Mainnet takes years over a protocol update because enactment requires validators holding 80% of stake to signal readiness, and that threshold has to be assembled from independent operators. On the reset network it does not have to be assembled at all. Asked in the developer channel on 29 August whether his own validators had to vote for the new versions, the operator answered that the last badge was never sent (https://t.me/RadixDevelopers/66105) : he holds 100% of the Stokenet validator badges against an 80% requirement, and was “pushing it through, with or without your approval”. Three readiness transactions in an evening is what a unanimous validator set looks like. The one line he did not cross he drew himself. He stopped at Cuttlefish part 1 on the ground that part 2 needs more information and “is not really me to decide” – a limit of judgement rather than of authority, which is the distinction worth recording. The same concentration that makes the test network quick to upgrade makes it a network whose protocol version one person sets. On mainnet (/contents/tech/releases/radix-mainnet-babylon) the same signalling mechanism answers to a stake distribution no single operator holds. 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 (https://t.me/RadixDevelopers/66122) , hours after the protocol updates went in, a developer reported every one of his Stokenet accounts present in the Radix Wallet (/contents/tech/core-protocols/radix-wallet) and every one of them empty of tokens, NFTs (/contents/tech/core-protocols/nfts-on-radix) , 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 (https://t.me/RadixDevelopers/66123) , which places the loss in the history rather than in the network. Daffy answered at 06:18 UTC on 30 August (https://t.me/RadixDevelopers/66135) : “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 (https://t.me/RadixDevelopers/66138) , 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 was then the current official node release – Cuttlefish v1.3.0.5 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5) , published 1 June 2026 and since superseded by Eagle Ray v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) on 10 September – so on version alone the reset network was where it should have been. 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 (https://docs.radixdlt.com/docs/node-setup-docker) 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 (https://github.com/radixdlt/babylon-node/releases/tag/v1.2.1) , 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 (/contents/tech/core-protocols/radix-gateway-api) 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 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) ), 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 (https://t.me/RadixDevelopers/66138) 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 (https://github.com/radixdlt/babylon-node/blob/v1.3.0.5/common/src/main/java/com/radixdlt/networks/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 (https://github.com/radixdlt/babylon-node/blob/v1.3.0.5/core/src/main/java/com/radixdlt/bootstrap/RadixNodeBootstrapper.java) 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 (https://docs.radixdlt.com/docs/node-setup-docker) 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 (/contents/tech/core-protocols/radix-gateway-api) keeps the defaults. The standard node setup (/developers/infrastructure/01-running-a-node) covers everything else unchanged. The last step is a person. The faucet mints, but not enough to create a validator (/contents/tech/core-concepts/validator-nodes) , 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. ## Scrypto URL: https://radix.wiki/contents/tech/core-protocols/scrypto-programming-language Updated: 2026-09-12 Summary: Scrypto is the Rust toolkit for writing Radix smart contracts. A blueprint is an ordinary Rust crate that depends on the scrypto crate, published on c… Type Rust SDK and build toolchain Written In Rust Distributed As the scrypto (https://crates.io/crates/scrypto) crate Compiles To WASM (https://webassembly.org) , by cargo build --target wasm32-unknown-unknown Runs On Radix Engine (/contents/tech/core-protocols/radix-engine) Latest Scrypto 1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) (Eagle Ray), 7 September 2026; Rust 1.92.0 Overview Scrypto is the Rust toolkit for writing Radix smart contracts. A blueprint is an ordinary Rust crate that depends on the scrypto (https://crates.io/crates/scrypto) crate, published on crates.io as The Scrypto standard library. The scrypto build command hands that crate to cargo build --target wasm32-unknown-unknown, and the WebAssembly (https://webassembly.org) module which comes out is what gets deployed to the ledger as a package. Radix's own documentation describes the central #[blueprint] macro as a way to define a blueprint using items defined in Rust grammar (https://docs.radixdlt.com/docs/scrypto) . The grammar is Rust's, and so is the compiler. What the toolkit adds is a vocabulary for assets. Tokens and NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) are resources (/contents/tech/core-concepts/resources) the developer moves between buckets and vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) rather than balances written into a mapping, the approach this wiki covers under asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) . Key Differences from Solidity (https://soliditylang.org) - No reentrancy – Scrypto's execution model makes reentrancy structurally impossible. Assets are in call-frame-local buckets (/contents/tech/core-concepts/buckets-proofs-and-vaults) that can't be accessed from nested calls. - No approval pattern – Assets move directly via buckets (https://docs.radixdlt.com/docs/resources) . No approve() + transferFrom(). - Authorization via badges (https://docs.radixdlt.com/docs/auth) – Instead of msg.sender checks, Scrypto uses badge-based authorization (/contents/tech/core-concepts/access-rules-and-auth-zones) . Present a proof of holding a badge (/contents/tech/core-concepts/badges) to access protected methods. - Blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) → Components (/contents/tech/core-concepts/components) – Scrypto code is organized into blueprints (/contents/tech/core-concepts/blueprints-and-packages) (like classes) that are instantiated into components (like objects) on-ledger. Modern Rust Support Scrypto 1.3.1 unlocked modern Rust (1.92.0+) support with a new WASM (https://webassembly.org) build pipeline, ending the previous Rust 1.81.0 lockdown. Scrypto 1.4.0, the release that fixed the engine flaw behind the August 2026 asset drain (/contents/history/hyperlane-asset-drain-2026) , keeps that toolchain: its rust-toolchain.toml (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/rust-toolchain.toml) names channel 1.92.0, as 1.3.1’s does. Radix’s install guide (https://docs.radixdlt.com/docs/getting-rust-scrypto) still told readers to install Rust 1.81.0 and radix-clis 1.3.0 when checked on 12 September 2026; Getting Started with Scrypto (/developers/getting-started/01-install-scrypto) covers which version a fresh install gets. Language or SDK Radix's materials call Scrypto a language. The radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) README opens on the Scrypto language, the language for building DeFi apps on Radix; the address of this page says the same; and most of the ecosystem writes it that way. The mechanism is narrower. Rust's compiler compiles the code, Cargo builds it, and the ledger stores a WebAssembly module. Scrypto is the crate, the procedural macros and the CLI that make such a module easy to produce from Rust. Asked on 2 September 2026 whether the authoring layer for the hyperscale-rs (/contents/tech/research/hyperscale-rs) virtual machine amounts to a new language, its lead developer declined the word for both projects at once: let's not call it a language. it's a rust sdk. Scrypto is also not a language (https://t.me/hyperscale_rs/11575) . Other toolchains can reach the same interface. 0xOmarA, the leading contributor to the Radix Engine Toolkit (https://github.com/radixdlt/radix-engine-toolkit) and one of the main authors of radixdlt-scrypto, replied in the same thread that you can write it in C or AssemblyScript today (https://t.me/hyperscale_rs/11584) , with the caveat that working in any language without an SDK is always going to be hard. What the SDK carries is the macro layer, which generates the metadata and the interface the Radix Engine (/contents/tech/core-protocols/radix-engine) expects, and writing that by hand is the work nobody wants. The distinction changes how a portability claim should be read. A contract written in Scrypto is tied to a Rust library and a WASM target rather than to a syntax, so moving it to another authoring layer is an SDK migration. That is the shape the Xi'an transition (#scrypto-and-xian) is taking. Deterministic Arithmetic Every Radix Engine (/contents/tech/core-protocols/radix-engine) transaction must produce an identical result on every validator, so Scrypto does not allow IEEE floating-point (https://en.wikipedia.org/wiki/IEEE_754) math on-ledger. Floating-point rounding differs across hardware and compilers, which means two nodes could compute the same swap and disagree in the final digits. That disagreement would stall consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) . All on-ledger values use fixed-point integer types instead. - Decimal (https://docs.radixdlt.com/docs/data-types) is a 192-bit signed fixed-point number with 18 decimal places (values of the form m / 1018). It is the default type for token amounts and account balances. - PreciseDecimal is a 256-bit signed fixed-point number with 36 decimal places, used for intermediate calculations where the extra precision limits rounding loss. Both types panic on overflow or underflow rather than wrapping around, so an out-of-range result reverts the whole transaction instead of leaving a corrupted balance. The tradeoff is that precision is fixed and rounding is the developer's responsibility to manage. Scrypto and Xi'an Scrypto compiles to WebAssembly and runs on the Radix Engine (/contents/tech/core-protocols/radix-engine) , which is the execution environment of Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet. The sharded successor network, Xi'an (/contents/tech/releases/radix-mainnet-xian) , is not expected to use the Radix Engine: on 1 August 2026 the lead developer of the production candidate (/contents/tech/research/hyperscale-rs) confirmed a purpose-built VM is underway (https://t.me/hyperscale_rs/10334) , and that the options which would have left existing dApps untouched have dissolved (https://t.me/hyperscale_rs/10340) . The replacement authoring layer became legible in the first days of September 2026, and it belongs to the same family: They're both just rust sdks, with vaults, resources, proofs, etc. (https://t.me/hyperscale_rs/11430) The constant-product pool (https://github.com/hyperscalers/hyperscale-vm/blob/main/guests/amm/src/lib.rs) in the hyperscale-vm repository is a #[blueprint] macro over a Rust module holding vaults, buckets and a minted share resource, which a Scrypto developer can read on sight. The visible difference is that a component's data splits in two, mutable state on one side and a creation-fixed #[config] on the other, so the transaction graph can be computed from cached values at admission across shards. The VM itself is bound to no language at all: it takes WASM Component Model guests (https://t.me/hyperscale_rs/11579) , with the Rust SDK as the intended path. Three migration costs are on the record. Compiled packages do not carry over, so every contract needs rebuilding from source. Two capabilities go with sharding (/contents/tech/core-concepts/sharding) : locking a fee from a component during execution, and branching cross-component calls on mutable state. For the rest, the developer expects a transition to be trivial for 99% of builders (https://t.me/hyperscale_rs/11573) even if the process cannot be entirely shimmed or run through a transpiler, and says the authoring ergonomics are still in flux, with an everything you need to know guide a month or two out. That is a forecast about work not yet done. None of it affects Scrypto on Babylon, which is unchanged. External Links - Getting Started with Scrypto (/developers/getting-started/01-install-scrypto) - Scrypto Fundamentals (/developers/scrypto/01-fundamentals) - Official Documentation (https://docs.radixdlt.com/) - GitHub Repository (https://github.com/radixdlt/radixdlt-scrypto) - The scrypto crate on crates.io (https://crates.io/crates/scrypto) ## Radix Engine URL: https://radix.wiki/contents/tech/core-protocols/radix-engine Updated: 2026-09-12 Summary: The Radix Engine is the execution environment that runs all Scrypto smart contracts on Radix. Unlike the EVM (which is a general-purpose virtual machi… Type Deterministic Execution Environment Language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) (Rust-based) Key Innovation System-level enforcement of asset rules VM WASM ( Scrypto (/contents/tech/core-protocols/scrypto-programming-language) compiles to WebAssembly (https://webassembly.org) ) Overview The Radix Engine (/contents/tech/core-protocols/radix-engine) is the execution environment that runs all Scrypto (/contents/tech/core-protocols/scrypto-programming-language) smart contracts on Radix. Unlike the EVM (which is a general-purpose virtual machine), the Radix Engine (/contents/tech/core-protocols/radix-engine) is purpose-built for DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) with asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) enforced at the system level. System-Level Enforcement The Radix Engine enforces asset conservation, access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) , and resource (/contents/tech/core-concepts/resources) behaviors (mint, burn, freeze) at the engine level – not in application code. This means an entire class of bugs (reentrancy, overflow, approval exploits) is structurally impossible. Deterministic Execution Every transaction produces the same result regardless of execution timing or node. Combined with transaction manifests (/contents/tech/core-protocols/transaction-manifests) , users can predict exactly what a transaction will do before signing. The Radix Engine The Radix Engine executes every Scrypto smart contract across four layers, resting on Cerberus consensus. Unlike a general-purpose VM, it is asset-oriented – tokens and NFTs are native primitives rather than balances in a mapping. RADIX WIKIThe Radix EngineEXECUTION STACKThe Radix Engine is the execution environment for every Scrypto smart contract –purpose-built for DeFi, where tokens and NFTs are native assets rather than balances in amapping.FOUR LAYERS, TOP TO BOTTOM1ApplicationYour Scrypto blueprints, packages, and components execute here.topmost2SystemObjects, the resource model, and modules – Metadata · Royalty · Role Assignment.3VMRuns blueprint code in two VMs: Scrypto (WebAssembly) and Native.4KernelSubstates, actors, ownership transfer, and execution costing.lowestruns onCerberus consensusBraided BFT – reaches agreement across only the shards each transaction touches.Written in Scrypto (Rust) · asset-oriented · Scrypto VM + Native VM.radix.wiki The Radix Engine stack – four layers on Cerberus consensus. The August 2026 vault reference vulnerability On 31 August 2026 a single transaction took resources out of sixty vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) belonging to other people, and the Radix Engine permitted it. Between 16:02 and 16:57 UTC twenty-six such transactions emptied every Hyperlane-bridged asset on the network (/contents/history/hyperlane-asset-drain-2026) . At 22:02 UTC the cause was stated publicly (https://t.me/radix_dlt/1000779) as the engine rather than the bridge — "any assets, token or nft, could have been withdrawn and moved without permission" — and by then its node runners had halted mainnet to stop further use of it; the last state the ledger committed was version 557,840,627, at 21:19:48 UTC. The defect sits in the reference check every transaction passes through before any WASM runs. In verify_boot_ref_value (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/system/system_callback.rs#L1147) , a non-global node named in a manifest is accepted as a DirectAccess reference, and handed to the caller's frame, on one test: that its blueprint (/contents/tech/core-concepts/blueprints-and-packages) is FungibleVault or NonFungibleVault. Ownership is not checked, and is not an input to the function. Direct access exists so that recall can work, and recall is gated behind the resource's recaller role — but the same vault blueprint (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/blueprints/resource/fungible/fungible_vault.rs#L268) gates take, take_advanced and lock_fee behind the resource's withdrawer role, which on any freely transferable token is open. An account's balance is protected by the account component (/contents/tech/core-concepts/components) 's own access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) on withdraw; a call made straight to the vault never reaches them. The failure is worth stating precisely, because it is not the class of bug the section above says the engine removes. There was no reentrancy, no overflow and no approval to abuse. The engine's rules were not evaded — they were applied to a caller the engine had already decided was entitled to hold the reference. System-level enforcement moves the guarantee from application code into the engine, and this is the cost of that trade: application authors could not have written their way out of it, and one function in the boot path decided the outcome for every account on the network. The version this was read at is v1.3.1, the Cuttlefish release (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.3.1) , and the same function on main was byte-identical to it at the time. The fix left that function alone. verify_boot_ref_value is byte-identical in Scrypto v1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/radix-engine/src/system/system_callback.rs#L1158) , the Eagle Ray release of 7 September 2026, so a vault reference still passes the boot check. The change is in before_invoke (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/radix-engine/src/system/system_callback.rs) , which runs before every method call and now asks whether the calling frame is allowed to invoke the object it names. For a Direct method, the kind recall uses, the object must be visible to the frame for a direct call; for any other method it must be visible for a normal one. A call that fails returns SystemError::InvalidInvokeAccess, an error v1.3.1 does not have. The check is gated on a system-logic version flag, should_check_method_receiver_access. Eagle Ray enacted on mainnet at the start of epoch 339,898 on 11 September, and after the restart a blueprint written to repeat the drain was published there; its call was rejected with that error (https://t.me/RadixDevelopers/66392) . The Radix Engine and Xi'an The Radix Engine is the execution environment of Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet, and everything above describes what runs there today. Its role in the sharded successor network is changing. On 1 August 2026 the lead developer of the Xi'an production candidate (/contents/tech/research/hyperscale-rs) confirmed that a purpose-built virtual machine is underway (https://t.me/hyperscale_rs/10334) to replace the Radix Engine in Xi'an (/contents/tech/releases/radix-mainnet-xian) , having assessed the engine as "not in the ballpark" (https://t.me/hyperscale_rs/10332) for sharded operation. The candidate integrates the real engine today, so this is a stated direction rather than a completed change. The technical objection is narrow and specific. Cross-shard atomic commitment requires every transaction to declare in advance exactly which state it will read and write, because that declaration fixes which shards participate and lets conflicts be analysed before anything executes. The Radix Engine's state access is, on the developer's assessment, "too loose" (https://t.me/hyperscale_rs/6018) to resolve those dependencies deterministically ahead of execution for a Turing-complete contract language – which leaves only unattractive routes to transaction preview, such as an ingress node holding state from every shard, or discovering each dependency part-way through execution. For developers, the expected migration cost was given on 2 August 2026 as "best case scenario - contracts will just need a recompile. worst case scenario - there'll be some automatic transpiler devs can use to upgrade source code" (https://t.me/hyperscale_rs/10346) . How much the new VM borrows from the Radix Engine has not been stated beyond an April 2026 remark that it "might borrow some ideas from RE". ## Radix vs Ethereum URL: https://radix.wiki/contents/tech/comparisons/radix-vs-ethereum Updated: 2026-09-12 Summary: Ethereum uses Casper PoS with a single execution layer processing all transactions sequentially. Scalability relies on L2 rollups (Optimism, Arbitrum,… Type Technical Comparison Radix Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , native assets (https://learn.radixdlt.com/article/what-are-native-assets) Ethereum (https://ethereum.org) Casper PoS, Solidity (https://soliditylang.org) , ERC-20 (https://eips.ethereum.org/EIPS/eip-20) Consensus Ethereum (https://ethereum.org) uses Casper PoS with a single execution layer processing all transactions sequentially. Scalability relies on L2 rollups (Optimism, Arbitrum, zkSync) which introduce sequencer centralization and cross-rollup composability challenges. Radix uses Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , which as specified parallelises consensus across shards so that throughput scales with shard count. As deployed on the live Babylon (/contents/tech/releases/radix-mainnet-babylon) network, Cerberus runs unsharded (/contents/tech/core-protocols/cerberus-consensus-protocol) — one shard group over the whole ledger, with the braiding machinery inactive — so today it too commits one ledger, and the linear-scaling property is a claim about the specification and about Hyperscale / Xi'an (/contents/tech/research/hyperscale-rs) . The 500,000+ TPS test (/contents/tech/research/hyperscale-500k-tps) measured the Radix Foundation's Hyperscale implementation on a test network; it is not Cerberus and has never been a property of mainnet. For what each live network is actually doing, see Radix vs Solana (/contents/tech/comparisons/radix-vs-solana) . Programming Model Ethereum ( Solidity (https://soliditylang.org) ): Account-based model where tokens are mappings inside contracts. Requires approve() + transferFrom() pattern. Susceptible to reentrancy, approval exploits, and front-running. Radix ( Scrypto (/contents/tech/core-protocols/scrypto-programming-language) ): Asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) model where tokens are native resources (/contents/tech/core-concepts/resources) . No approval pattern. Reentrancy structurally impossible. Assets move in buckets (/contents/tech/core-concepts/buckets-proofs-and-vaults) . Transactions Ethereum: Opaque calldata – users blind sign (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) hex data they can't read. Radix: Transaction manifests (/contents/tech/core-protocols/transaction-manifests) – readable, composable, verifiable before signing. Scalability Property Ethereum (https://ethereum.org) Radix L1 throughput, live ~15-30 TPS One unsharded ledger ( measured 21 August 2026 (/contents/tech/comparisons/radix-vs-solana) ); halted from 31 August to 11 September 2026 Demonstrated in testing — 500,000+ TPS, but on the Foundation's Hyperscale test network (/contents/tech/research/hyperscale-500k-tps) rather than Cerberus or mainnet Scaling approach L2 rollups (live) L1 sharding (/contents/tech/core-concepts/sharding) (specified; in development as Xi'an (/contents/tech/research/hyperscale-rs) ) Cross-shard composability Async bridges Atomic in the same transaction, as specified Hardware requirements Moderate (L1), centralized (L2 sequencers) Commodity Strengths of Each Ethereum's strengths: Largest ecosystem, most liquidity, widest tooling support, strongest brand recognition, battle-tested over 10+ years. Radix's strengths: Superior asset model ( native assets (https://learn.radixdlt.com/article/what-are-native-assets) , no approvals), readable transactions, a scaling design that adds shards rather than layers, developer-friendly Rust-based language, and an execution model with no reentrancy and no approve() pattern to abuse. Where the comparison stands, September 2026 The throughput row and the strengths above both need a date. On 31 August 2026 a single transaction took resources out of sixty vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) belonging to other people, and the Radix Engine permitted it (/contents/tech/core-protocols/radix-engine) . Twenty-six such transactions emptied every Hyperlane-bridged asset on the network (/contents/history/hyperlane-asset-drain-2026) between 16:02 and 16:57 UTC, and at 22:02 UTC the cause was stated publicly (https://t.me/radix_dlt/1000779) as the engine rather than the bridge. The defect sat in the reference check every transaction passes before any contract code runs, which accepted a vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) reference on the test that its blueprint (/contents/tech/core-concepts/blueprints-and-packages) was a vault, without asking who owned it. So the two comparisons this page draws against Solidity still hold – reentrancy and the approval pattern are absent from Radix – and the broader claim they were carrying does not. The engine removes a class of bug; it did not remove this one. Its node runners halted mainnet that evening to stop further use of the defect. The last state the ledger committed was version 557,840,627, at 21:19:48 UTC on 31 August, and nothing more committed for ten and a half days. The fix shipped as the Eagle Ray protocol update (/contents/tech/releases/protocol-updates#eagle-ray-enacted) , which enacted at the start of epoch 339,898 at 11:39 UTC on 11 September 2026. It adds a check, before every method call, that the calling frame is allowed to invoke the object it names; the Radix Engine (/contents/tech/core-protocols/radix-engine#eagle-ray-fix) page covers the change at source. After the restart a blueprint written to repeat the drain was published on mainnet, and its call was rejected with InvalidInvokeAccess (https://t.me/RadixDevelopers/66392) . ## Babylon Node URL: https://radix.wiki/contents/tech/core-protocols/babylon-node Updated: 2026-09-12 Summary: Babylon Node is the software that runs the Radix network. Its repository, radixdlt/babylon-node , describes itself as "the Radix node, updated for Bab… Software The Radix node for the Babylon network and beyond Repository radixdlt/babylon-node (https://github.com/radixdlt/babylon-node) , created 25 April 2022 Languages Java (consensus, networking) and Rust (Core API, state manager); TypeScript for generated clients Licence Radix License 1.0 (https://www.radixfoundation.org/licenses/license-v1) , July 2021; radixfoundation.org does not answer over HTTPS, so the text is readable only in the 2 April 2023 archive capture (https://web.archive.org/web/20230402033642/https://www.radixfoundation.org/licenses/license-v1) Engine Pulled in from radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) , not vendored in this repository Latest release v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , 10 September 2026, the final Eagle Ray release; it tags commit 7400951e, the same commit as the v1.4.0.0-RC1 candidate of 8 September, and carries no pre-release flag Protocol line v1.0.0 Genesis · v1.1.0 Anemone · v1.2.0 Bottlenose · v1.3.0 Cuttlefish · v1.4.0 Eagle Ray (enacted 11 September 2026) Default branch develop – last commit 12 March 2025, while releases are cut from main Primary sources README (https://github.com/radixdlt/babylon-node/blob/main/README.md) · Node Protocol Updates (https://docs.radixdlt.com/docs/node-protocol-updates) Overview Babylon Node is the software that runs the Radix network. Its repository, radixdlt/babylon-node (https://github.com/radixdlt/babylon-node) , describes itself as "the Radix node, updated for Babylon" and states that it embeds the Radix Engine (/contents/tech/core-protocols/radix-engine) , which lives in the separate radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) repository. That separation is the single most useful thing to know about it: the rules a transaction is executed under are written elsewhere, and this repository is what carries them to the machines that run the ledger. The node is where consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) , peer-to-peer networking, the Core API (/contents/tech/core-protocols/radix-core-api) and the engine meet in one process. The Gateway API (/contents/tech/core-protocols/radix-gateway-api) that most applications read the ledger through is not part of it; the Gateway is a separate service that reads from a node. A validator (/contents/tech/core-concepts/validator-nodes) is a node whose operator has registered it on-ledger and attracted stake (/contents/tech/core-concepts/staking) , and running one is documented in this wiki’s own infrastructure guide (/developers/infrastructure/01-running-a-node) . What is inside it The repository’s README (https://github.com/radixdlt/babylon-node/blob/main/README.md) maps the tree, and the division it describes is a language boundary as much as a functional one. GitHub measures the checkout at roughly 16.7 MB of Java against 4.9 MB of Rust and 3.4 MB of TypeScript. - core – the node itself: consensus and networking, in Java. The README describes it as including "a variant implementation of the HotStuff (https://arxiv.org/abs/1803.05069) BFT-style consensus", which is the plainest statement in Radix’s own source of what secures Babylon mainnet. Cerberus running unsharded, as it does on mainnet, is equivalent to that original HotStuff protocol. - core-rust – the Core API and the "State Manager" that wraps the Babylon engine, in Rust. This is the module that pulls the engine in from radixdlt-scrypto. - core-rust-bridge – the Java side of the boundary between those two, which the README expects will eventually be folded into core. - cli-tools, common, shell, docker and testnet-node – the operator surface: command-line helpers, shared Java utilities, the interactive Radix Shell, a local multi-node network, and a one-script development node for integrators. The engine dependency is the reason a change to how transactions execute is not, by itself, a change to the node. It becomes one when a node release picks the new engine up. How a protocol update reaches mainnet Radix does not switch rules when nodes are updated. It switches when the validator set says it is ready. The node supports two triggers, described in Radix’s node documentation (https://docs.radixdlt.com/docs/node-protocol-updates) : unconditional enactment at the start of a named epoch, used for genesis and test environments, and validator readiness signalling, which is "the standard option for mainnet protocol updates". Under the second, each validator has room for exactly one optional readiness signal at a time, and the signal is not the update’s name but a unique string derived from the protocol version and its trigger condition. Enactment is bounded by a lower_bound_epoch_inclusive and an upper_bound_epoch_exclusive, and gated on 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 have been signalling continuously for that many epochs. The mainnet updates configured so far, with the node release each shipped in: Update Node Readiness signal Epoch window Requirement Anemone v1.1.0 220e2a4a4e86e3e6000000000anemone [70019, 74051) 75% of stake for ~4 days Bottlenose v1.2.0 86894b9104afb73a000000bottlenose [104291, 112355) 75% of stake for ~2 weeks Cuttlefish v1.3.0 96e00440adafe5e2000000cuttlefish [158682, 161562) 75% of stake for ~2 weeks Cuttlefish part 2 v1.3.0 None – EnactImmediatelyAfterEndOfProtocolUpdate Follows Cuttlefish None Eagle Ray v1.4.0.0 None – EnactAtStartOfEpochUnconditionally 339898 None Eagle Ray is the first mainnet entry that does not use readiness signalling, and the reason is that a halted network cannot produce one. A threshold is met only after a number of completed epochs of support, and mainnet completed none between 31 August and 11 September 2026, so an update whose purpose was to end that halt could never have cleared one. The mainnet protocol configuration (https://github.com/radixdlt/babylon-node/blob/main/core-rust/state-manager/src/protocol/protocol_configs/mainnet_protocol_config.rs) released in v1.4.0.0 gives it EnactAtStartOfEpochUnconditionally at epoch 339,898 instead, and adds a second mechanism the node did not previously have: a UserTransactionMoratorium covering the single epoch 339,897, defined in the node source (https://github.com/radixdlt/babylon-node/blob/main/core-rust-bridge/src/main/java/com/radixdlt/protocol/UserTransactionMoratorium.java) as an epoch range during which user transactions are refused, and commented in the configuration as belonging to the Mainnet incident of 1 September 2026. Consensus therefore restarts one epoch before the new rules do. Stokenet (https://github.com/radixdlt/babylon-node/blob/main/core-rust/state-manager/src/protocol/protocol_configs/stokenet_protocol_config.rs) receives the same update through the ordinary route, signal 8ed71bbdf45861cb0000000eagle-ray at 80% of stake for ten consecutive epochs, which is what the mechanism looks like when the ledger is moving. Cuttlefish enacted at epoch 160923, inside that window. Execution itself is handled by the node: the final consensus proof of the preceding epoch signs off on the enactment, so the epoch cannot end unless a quorum agrees it should proceed, and the update then commits zero or more batches of system "flash" transactions that rewrite engine substates directly. An operator can ask a running node what it has enacted and what is pending through its System Health endpoint, by default http://localhost:3334/system/health, which lists both with their readiness signal names. The consequence for a reader watching for an upgrade is precise: until a node release exists that contains a protocol version, there is nothing for a validator to signal, and therefore no readiness figure to watch. For Eagle Ray there is no readiness figure to watch at all. See Protocol Updates (/contents/tech/releases/protocol-updates) for what each one changed. Release history and branch topology The repository’s releases follow the protocol line rather than a calendar. The original protocol version, babylon, arrived with the v1.0.0 node and was enacted immediately at the Babylon (/contents/tech/releases/radix-mainnet-babylon) migration; v1.1.0, v1.2.0 and v1.3.0 carried Anemone, Bottlenose and Cuttlefish. Everything since has been a patch on the Cuttlefish line: v1.3.0.1 and v1.3.0.2 in December 2024 and January 2025, then v1.3.0.4 on 2 April 2026 and v1.3.0.5 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5) on 1 June 2026. All five are still named "Cuttlefish", and none carries a protocol change. Where that work happens is not where the repository’s front page points. GitHub serves develop as the default branch, and develop’s tip is commit 12919a01, "Update development docs", of 12 March 2025. The release line is main, whose tip 959b081e of 1 June 2026 is the exact commit tagged v1.3.0.5. The two branches have diverged rather than drifted: GitHub’s comparison puts 28 commits on main that are not on develop, and 223 on develop that are not on main. A reader who opens the repository to judge whether the node is being worked on sees, by default, a branch that stopped eighteen months ago. The September 2026 halt was resolved on main and nowhere else. Pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) , which carries the Eagle Ray engine pin and the restart schedule, was opened against develop and retargeted to main minutes before it merged on 8 September 2026; main's tip is now 7400951e, tagged v1.4.0.0-RC1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0-RC1) on 8 September and v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) on 10 September, the first release since v1.3.0 to carry a protocol change, and the head of a third branch, release/eagle-ray. develop's tip is unmoved, and the comparison now reads 48 commits on main that are not on develop against 223 the other way. Status during the September 2026 halt Mainnet committed no round from 21:19:48 UTC on 31 August 2026, at epoch 339,897 and state version 557,840,627, until 11 September, following the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) . For the first eight days of that halt this repository showed nothing that would end it: its newest release was still v1.3.0.5 of 1 June, and no branch or tag named a forthcoming protocol version. The fix was in pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) against radixdlt-scrypto, the engine repository this one embeds, and nothing there reaches the network until an engine release carrying it is pulled into a node release and that node release is published. Both halves are now done. Scrypto v1.4.0 ( Eagle Ray (/contents/tech/releases/protocol-updates) ) was tagged on 7 September, and on 8 September this repository merged pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) into main at 15:28:11 UTC — pinning the engine dependency to it and adding the enactment trigger for epoch 339,898 and a user transaction moratorium for epoch 339,897 — and published v1.4.0.0-RC1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0-RC1) seven minutes later, with container images by 16:23 UTC. The candidate was flagged a pre-release, so the repository's latest release resolved to v1.3.0.5-test.1, a rebuild of the halted version tagged that same lunchtime. The final release, v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , followed at 03:59:09 UTC on 10 September 2026, with container images pushed between 04:31 and 04:50 UTC. It tags commit 7400951e0eb76a725f39d04d57da293fb335bd0e, which is the commit the candidate already tagged, so the code an operator installs is the code they could have installed on 8 September; what the final release adds is the absence of the pre-release flag, and with it a latest release (https://api.github.com/repos/radixdlt/babylon-node/releases/latest) that resolves to Eagle Ray for GitHub and for the ghproxy.radixdlt.com mirror the node installer reads (/developers/infrastructure/01-running-a-node) . Read at 07:07:53 UTC on 10 September the ledger had not moved, because two steps remained: operators had to install the release, and two thirds of stake had to come back online. Both happened on 11 September. Rounds resumed at 11:35 UTC inside the moratorium epoch, and Eagle Ray enacted at the start of epoch 339,898 at 11:39 UTC, when user transactions were allowed again. The state version and timestamp of each step are on Protocol Updates (/contents/tech/releases/protocol-updates#eagle-ray-enactment) . See Also - Radix Engine (/contents/tech/core-protocols/radix-engine) - Cerberus (Consensus Protocol) (/contents/tech/core-protocols/cerberus-consensus-protocol) - Radix Core API (/contents/tech/core-protocols/radix-core-api) - Protocol Updates (/contents/tech/releases/protocol-updates) - Validator Nodes (/contents/tech/core-concepts/validator-nodes) - Stokenet (/contents/tech/releases/stokenet) - Running a Node (/developers/infrastructure/01-running-a-node) External Links - radixdlt/babylon-node (https://github.com/radixdlt/babylon-node) – the repository - Releases (https://github.com/radixdlt/babylon-node/releases) – the node release line - Node Protocol Updates (https://docs.radixdlt.com/docs/node-protocol-updates) – readiness signalling, thresholds and the mainnet table - Protocol Updates (https://docs.radixdlt.com/docs/protocol-updates) – Radix Docs - radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) – the engine the node embeds - Radix License 1.0 (https://www.radixfoundation.org/licenses/license-v1) – the domain refuses every TLS handshake, read 9 September 2026; the text is in the Internet Archive capture of 2 April 2023 (https://web.archive.org/web/20230402033642/https://www.radixfoundation.org/licenses/license-v1) ## Radix Gateway API URL: https://radix.wiki/contents/tech/core-protocols/radix-gateway-api Updated: 2026-09-12 Summary: The Radix Gateway API is the primary developer interface for building dApps on Radix. It indexes the ledger and provides REST endpoints for querying a… Type Developer-Facing API Database ~2TB, growing ~60GB/month Transition Community RFP (Feb 2026) Target SLA 99.9% uptime, Staleness guard HTTP 500 NotSyncedUpError beyond 720s of ledger lag (mainnet) Overview The Radix Gateway API (https://docs.radixdlt.com/docs/network-gateway) is the primary developer interface for building dApps on Radix. It indexes the ledger and provides REST endpoints for querying account states, token balances, transaction history, and resource (/contents/tech/core-concepts/resources) metadata. Decentralization Currently operated by the Radix Foundation (/ecosystem/radix-foundation) , the Gateway API (https://docs.radixdlt.com/docs/gateway-sdk) is undergoing community transition via RFP (opened February 2026). The database is approximately 2TB with ~60GB monthly growth. Successful operators must guarantee 99.9% uptime and sub-second query latency for the Radix Wallet (/contents/tech/core-protocols/radix-wallet) and Dashboard (https://dashboard.radixdlt.com) . What the Gateway does when it falls behind The Gateway answers from its own index rather than from a node’s live state, so it can fall behind the network. Rather than serve a stale answer it refuses to answer at all. LedgerStateQuerier (https://github.com/radixdlt/babylon-gateway/blob/main/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/LedgerStateQuerier.cs) compares the timestamp of its own head against the clock and throws NotSyncedUpException (https://github.com/radixdlt/babylon-gateway/blob/main/src/RadixDlt.NetworkGateway.GatewayApi/Exceptions/NotSyncedUpException.cs) when the gap is too wide. The caller gets HTTP 500 with a NotSyncedUpError body naming current_sync_delay_seconds and max_allowed_sync_delay_seconds. The guard has two halves, separately configurable, both on by default at 30 seconds ( Gateway configuration reference (https://github.com/radixdlt/babylon-gateway/blob/main/docs/configuration.md) ). PreventReadRequestsIfDbLedgerIsBehind covers the state and stream endpoints. PreventConstructionRequestsIfDbLedgerIsBehind covers /transaction/construction, and the source gives its reason: a construction request built against a stale index would use historic stake records, which gets an unstake calculation wrong. The Radix Foundation’s public mainnet Gateway runs both thresholds at 720 seconds. What that looks like from a dApp The mainnet halt of 31 August to 11 September 2026 (/contents/resources/radix-ecosystem-operational-status#network-halt) held the guard open long enough to read it. Every endpoint below was called once at 03:10 UTC on 5 September 2026: Endpoint Response /status/gateway-status 200, returning the frozen head: state version 557,840,622, epoch 339,896, round 102 /status/network-configuration 200 /state/entity/details 500, request_type Read /state/validators/list 500, request_type Read /stream/transactions 500, request_type Read /transaction/construction 500, request_type Construction All four failures reported current_sync_delay_seconds 366,663 against max_allowed_sync_delay_seconds 720. A wallet or dApp on this Gateway therefore connects, resolves the network, and then fails on every balance, history and submission call, with nothing wrong with the account or the key: the index will not answer for a ledger whose top it cannot see. The two status endpoints stay up throughout, which makes /status/gateway-status the place to check whether the network is moving. It is the wrong place to read where the ledger stopped. The head it reported for the whole halt, state version 557,840,622, is the last state the Gateway’s own index took in; /stream/transactions (https://mainnet.radixdlt.com/stream/transactions) shows the ledger committed five more, ending at state version 557,840,627 (epoch 339,897, round 4) at 21:19:48 UTC on 31 August. Verifiability (/policy/verifiability) lists this as a failure mode. Reading around the guard The refusal covers questions about the present, and only those. GetValidLedgerStateForReadRequest resolves the ledger state the caller asked for before it does anything else, and the lag comparison sits behind an early return: if (!ledgerStateReport.TopOfLedgerResolved) return ledgerState;. TopOfLedgerResolved is set true on one branch only, the one taken when the request named no ledger state and the Gateway had to read its own head. A request that pins a state version, an epoch, an epoch and round, or a timestamp never reaches the threshold and cannot throw NotSyncedUpException (https://github.com/radixdlt/babylon-gateway/blob/main/src/RadixDlt.NetworkGateway.GatewayApi/Exceptions/NotSyncedUpException.cs) . The halt makes that visible. Each endpoint below was called twice within two seconds at 07:07:56 UTC on 6 September 2026, at a reported current_sync_delay_seconds of 467,332 against 720 — once as an ordinary request, once with "at_ledger_state": {"state_version": 557,840,622}, the head the status endpoint was reporting: Endpoint Unpinned Pinned /state/entity/details 500 200 /state/validators/list 500 200, 287 validators with stake vaults /stream/transactions 500 200 /transaction/construction 500 500 Construction is the exception and the source says why it is not an inconsistency: GetValidLedgerStateForConstructionRequest carries the identical early return, but the /transaction/construction request has no at_ledger_state field to fill, so the value is ignored, the Gateway resolves its own head, and the Construction guard fires as before. Nothing here lets a stopped network be transacted on; it lets a stopped network be read. So the practical division during a halt is not between working and broken endpoints but between two questions. What is true now has no answer and the Gateway declines to invent one. What was true at a named state version has an answer: the same public Gateway serves balances, resource holdings and transaction history for any state the ledger committed. For this halt the last such state is 557,840,627, and a read pinned there on 12 September returns it, stamped 21:19:48 UTC on 31 August. A dApp fails during a halt because it asks the first question; a caller willing to name a ledger state gets the second. After the restart Mainnet committed rounds again from 11:35 UTC on 11 September 2026, and the Eagle Ray protocol update enacted four minutes later ( enactment, read from the ledger (/contents/tech/releases/protocol-updates#eagle-ray-enactment) ). Nobody switched the guard off. It stopped firing once the Gateway’s index was back within the 720-second threshold of the ledger’s tip: at 19:07 UTC on 12 September, unpinned calls to /state/entity/details and /state/validators/list both answered 200, and /status/gateway-status reported epoch 340,275. ## 1. Running a Radix Node URL: https://radix.wiki/developers/infrastructure/01-running-a-node Updated: 2026-09-12 Summary: A Radix node connects to the peer-to-peer network, syncs ledger state, and (if registered as a validator) participates in Cerberus consensus . You can… Overview A Radix node connects to the peer-to-peer network, syncs ledger state, and (if registered as a validator) participates in Cerberus consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) . You can run a node to power your own API endpoints (/developers/infrastructure/02-radix-apis) , support the network, or earn staking emissions (/contents/tech/core-concepts/network-emissions) as a validator. Hardware Requirements Resource Minimum Recommended (Validators) CPU 4 vCPU 8 vCPU (e.g., AWS c5.2xlarge) RAM 16 GB 32 GB+ Storage 500 GB SSD 1 TB+ NVMe OS Ubuntu 22.04 LTS (Jammy Jellyfish) Network Port 30000/tcp open for gossip Validators need reliability Validators should run on dedicated hardware or high-availability cloud instances. Downtime reduces your share of emissions (/contents/tech/core-concepts/network-emissions) and may cause delegators to move their stake. Installation Radix provides two installation methods: Option A: CLI-Guided Install (Recommended) The babylonnode CLI tool walks you through configuration interactively: wget -O babylonnode https://github.com/radixdlt/babylon-nodecli/releases/latest/download/babylonnode-ubuntu-22.04 chmod +x babylonnode sudo mv babylonnode /usr/local/bin/ # Run guided setup babylonnode docker installOption B: Docker Manual Setup For more control, use docker-compose directly with the official images from radixdlt/babylon-node (https://github.com/radixdlt/babylon-node) . Option C: Systemd Run the node process directly on the host, managed by systemd. Better for servers shared with other services. All methods are documented at docs.radixdlt.com/docs/node-setup (https://docs.radixdlt.com/docs/node-setup) . Which Node Version the CLI Installs The latest/download URL above has not moved since babylonnode 2.2.4, published on 13 January 2025 (https://github.com/radixdlt/babylon-nodecli/releases/tag/2.2.4) , and the only commit on the tool's main branch since is CI housekeeping in March that year (https://github.com/radixdlt/babylon-nodecli/commits/main) . That tells you nothing about the node you will end up running, because the CLI does not carry a node version at all. Instead it resolves the node, nginx and Gateway tags at run time (https://github.com/radixdlt/babylon-nodecli/blob/main/node-runner-cli/github/github.py) from ghproxy.radixdlt.com, a Radix-operated mirror of the GitHub releases API, and installs whatever tag comes back. Asked on 21 August 2026, it returned babylon-node v1.3.0.5 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5) – a release that shipped nearly seventeen months after the CLI binary did. A frozen installer and a current node are not in tension here; the indirection is the point. What that indirection returns during the halt is a different matter, and is covered below. Two consequences are worth knowing before an unattended rebuild depends on it: - It is a single external dependency. If that proxy does not answer, the CLI prints the failing URL and exits – there is no fallback to the GitHub API it mirrors. - You can pin past it. Setting RADIXDLT_APP_VERSION_OVERRIDE – or RADIXDLT_NGINX_VERSION_OVERRIDE and RADIXDLT_GATEWAY_VERSION_OVERRIDE for the other two – makes the CLI use that exact tag without asking anyone, which is what a reproducible validator rebuild wants. The published binaries cover Ubuntu 20.04 and 22.04 only, with no 24.04 build – which is why 22.04 is the operating system named in the table above rather than the newer LTS (https://ubuntu.com/about/release-cycle) . Operators on a distribution the CLI does not ship for take the Docker or systemd path instead. Operating Through the Network Halt (31 August – 11 September 2026) This section and the one below it were written while mainnet was down. They are kept as an operator’s record of the outage; how it ended (#sweep418-how-the-halt-ended) is at the foot of it. Mainnet stopped committing rounds at 21:19:48.939 UTC on 31 August 2026, at epoch 339,897, round 4, state version 557,840,627, after the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) . The halt was not a mode the network was switched into and there is no lever to throw back: node runners stopped their own nodes, and liveness returns only when enough of them individually deploy a patched release and start again. The Radix Accountability Council set out the sequence (https://t.me/RadixAccountabilityCouncil/936) at 12:16 UTC on 1 September – "code fixes for the RE", "updates to the node software + protocol upgrade", "a coordinated deployment of those across nodes", and "a careful coordinated return to liveness of the network", with no timetable. Steps three and four are operator work, which makes the state of your node between now and then worth understanding. The patched release, and what the CLI installs The releases page is the cheapest signal an operator has for whether step two has produced anything, and it has now produced twice. Eagle Ray v1.4.0.0-RC1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0-RC1) was published at 15:35:42 UTC on 8 September from merge commit 7400951e, with Docker images pushed to the official repository (https://hub.docker.com/r/radixdlt/babylon-node/tags) between 16:06 and 16:23 UTC. The final release, v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , followed at 03:59:09 UTC on 10 September 2026, cut from the release/eagle-ray branch against a tag created at 15:28:10 UTC on 8 September, which is the same commit the candidate carried; its Docker images were pushed between 04:31 and 04:50 UTC. Neither release carries notes. Both bodies are the Radix licence boilerplate and nothing else: no changelog, no upgrade steps, no restart epoch. The candidate was flagged a pre-release, and that flag had a consequence for the recommended install path. GitHub reports as latest the newest release that is neither a draft nor a pre-release. Three hours before Eagle Ray RC1, at 12:28:06 UTC on 8 September, the repository published v1.3.0.5-test.1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5-test.1) , an empty-bodied tag cut by github-actions[bot] and not flagged pre-release, so that was the release GitHub called latest. Asked at 23:06 UTC on 8 September and again at 03:04 UTC on 9 September, ghproxy.radixdlt.com/radixdlt/babylon-node returned that tag_name rather than the candidate's. For those two days the CLI-guided path above resolved to a test build cut before the fix, Docker images existed for that tag as well, and the install therefore succeeded and left the operator on a node that is not the one the restart depends on. The final release closes that gap. v1.4.0.0 carries no pre-release flag, so it is what GitHub now calls latest, and read at 07:06 UTC on 10 September ghproxy.radixdlt.com/radixdlt/babylon-node returns v1.4.0.0. From that point the CLI-guided path installs the patched node with no override needed. Three habits the gap taught are worth keeping anyway: - Pin the tag. RADIXDLT_APP_VERSION_OVERRIDE=v1.4.0.0 makes the CLI use that exact release without consulting the proxy at all. - Name it yourself. The Docker and systemd paths take the tag from your own compose file or unit, so neither was ever affected. - Check what you got. After any CLI install or update, read back the image tag actually running before assuming it is the patched one. The Radix Accountability Council (/contents/tech/core-concepts/radix-governance) asked operators at 18:43 UTC on 9 September not to run the release candidates (https://t.me/RadixAccountabilityCouncil/1012) on their own nodes, and to wait for official final versions and instructions on when to deploy. v1.4.0.0 is that final version, and the instructions followed it. At 16:15 UTC on 10 September projectShift posted a status update from the council telling operators to upgrade now (https://t.me/RadixAccountabilityCouncil/1019) : You can upgrade and update your nodes now, using the latest software version available from official sources. Validator operators are told to check the dedicated validator chat for further detail, and to leave a node online and working once it is fully upgraded and running properly. That is the third of the four steps the council named on 1 September, the coordinated deployment across nodes. The restart itself had no published date. From 20:18 UTC on 10 September it had a published threshold instead. None of this had moved the ledger. gateway-status (https://mainnet.radixdlt.com/status/gateway-status) at 07:07:53 UTC on 10 September still returned state version 557,840,622 at epoch 339,896, round 102 – the aggregator’s position rather than the ledger’s, five states short of the tip – unchanged for 225 hours and 48 minutes, and three hours after the final release an operator could install. No epochs means no emissions Staking emissions (/contents/tech/core-concepts/network-emissions) are minted per epoch, and the epoch counter did not move for the length of the halt. Nothing accrued to validators or their delegators while the network was stopped, and nothing was lost in arrears either – the ledger simply had no epochs to pay out for. The rule is general rather than particular to this outage: a stopped ledger pays nobody, and it owes nobody afterwards. This was answered directly in the main channel (https://t.me/radix_dlt/1001243) on 1 September: "The network progresses in epochs and stake rewards are given per epoch run. So no progress in epoch = no rewards given." A start-up failure on the current release, still unanswered One operator report against v1.3.0.5 has been open on the official forum since 17 August 2026 (https://radixtalk.com/t/v1-3-0-5-not-working/2327) with no reply. On an Ubuntu 22.04.5 LTS host where v1.3.0.4 runs normally, swapping in the v1.3.0.5 binary and its libcorerust.so makes the node panic during initialisation and restart in a loop: panicked at state-manager/src/jni/node_rust_environment.rs:173:72: called `Result::unwrap()` on an `Err` value: JavaError("[ERROR] byte offset: 90-92, value path: StateManagerConfig.[4|database_config]->DatabaseConfig, cause: { expected_field_count: 4, found: 5 }") The failure is not an operating-system incompatibility. It is a decode mismatch at the JNI boundary: the node's Java process hands the native state manager a DatabaseConfig carrying five fields where the Rust side expects four, which is the signature of a Java binary and a libcorerust.so that did not ship together. If you keep multiple releases side by side under /opt/radixdlt/babylon-node/ and select between them with LD_PRELOAD, check that both halves resolve to the same release before assuming the release itself is broken. The report was raised again on 1 September (https://t.me/radix_dlt/1001249) , twenty-four hours into the halt and immediately before the node update the restart depends on – the kind of thing worth confirming on your own host before the coordinated deployment rather than during it. The restart condition, and the gap it has to close At 20:18 UTC on 10 September 2026, in the main Radix Telegram group, Bart Roozeboom of the validator operator StakeSafe (/ecosystem/stakesafe) announced that its free Radix Network Dashboard (https://validators.stakesafe.net) now tracks Eagle-Ray adoption live (https://t.me/radix_dlt/1002910) , and stated the condition in one line: Once more than 67% of active stake is on Eagle-Ray, network liveness resumes and the network forks to a patched version. The dashboard repeats it in a banner above its charts. The 67% is not a StakeSafe rule. It is the ordinary two-thirds quorum Radix's consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) needs to commit a round, which is why the same fraction of stake could stop the network in the first place. Read from the dashboard's served page at 03:05 UTC on 11 September 2026, eleven hours after operators were cleared to upgrade: Reading XRD Share of the active set Stake running Eagle-Ray (v1.4.0.0) 1,419,724,715 30.45% Stake not running Eagle-Ray 3,243,296,625 69.55% Stake whose node is online 1,642,251,851 35.22% Stake whose node is offline 3,020,769,489 64.78% Threshold for liveness to resume more than 3,124,224,298 more than 67% Adoption was moving. Four hours earlier, at 23:08 UTC on 10 September, the same panel read 1,260,200,690 XRD and 27.03%, so roughly 160 million XRD came onto the patched release overnight. Thirty-six rows in the dashboard's validator table report v1.4.0.0 and their delegated stake sums to the adoption figure exactly. Upgrades among operators who are already running cannot close the gap. Online stake is 1,642,251,851 XRD, 35.22% of the active set. Every online validator could be on Eagle Ray tomorrow and the total would still sit around half of the 67% the restart needs, because the other 3,020,769,489 XRD is behind nodes that are switched off. The council's instruction reflects that: it asks operators to leave a fully upgraded node online and working, not merely to install the release. If your node is one of the ones that stopped, starting it again on v1.4.0.0 is the step the threshold is actually waiting on. One caveat on reading the dashboard. Its percentages are computed on the active validator set, the top 100 by stake, whose total it reports as 4,663,021,340 XRD – the online and offline figures added together. The panel heads with a different number, 4,877,281,907 XRD, which is every row in the explorer table including validators outside the active set. Quoted against that base the adoption reading is 29.11% rather than 30.45%, so say which base a figure came from. The dashboard refreshes every five minutes, and every reading here is a snapshot. gateway-status (https://mainnet.radixdlt.com/status/gateway-status) at 03:04:56 UTC on 11 September still returned state version 557,840,622 at epoch 339,896, round 102, 245 hours and 45 minutes without a committed round. Eight and a half hours later it was over. How the halt ended (11 September 2026) Enough of the set came back. Radix mainnet certified a round at 11:35:28.96 UTC on 11 September 2026 – state version 557,840,628, epoch 339,897 round 5, its first in ten days, fourteen hours and sixteen minutes. Epoch 339,897 then ran to its end producing rounds and refusing user transactions under the moratorium v1.4.0.0 declares, and at 11:39:25.129 UTC epoch 339,898 opened at round 2 with the Eagle Ray (/contents/tech/releases/protocol-updates) fork enacted and the moratorium lifted in the same second. Read from the transaction stream (https://mainnet.radixdlt.com/stream/transactions) , the outage is three consecutive entries: 557,840,627 at 21:19:48.939 UTC on 31 August, 557,840,628 at 11:35:28.96 UTC on 11 September, and sixty-five further round changes before the first user transaction at 557,840,694. Two things in the sections above are worth carrying forward rather than filing. The fork enacted unconditionally at the start of epoch 339,898 rather than on a validator readiness signal, which is unique in Radix’s mainnet history and is why no restart date could be published: a halted network completes no epochs, so it can hold no readiness vote. And an operator still on v1.3 when the fork enacted was not merely late; the release the threshold counted is the one the network forked to. The adoption dashboard (https://validators.stakesafe.net) read 32.77% of active-set stake on Eagle Ray at 11:05 UTC and the fork enacted at 80.85%, so the last forty-eight points arrived in half an hour when the largest validators booted together. The full sequence is on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status#sweep408-status-restored) . Becoming a Validator Once your node is synced, you can register it as a validator to participate in consensus and earn emissions. - Register – submit a validator registration transaction (costs 5-30 XRD (/contents/tech/core-protocols/xrd-token) in fees) - Configure – set your validator name, website URL, fee percentage, and delegation policy - Attract stake – the top 100 validators by total delegated stake are active each epoch - Maintain uptime – missed proposals reduce your emissions share See the validator setup guide (https://docs.radixdlt.com/docs/node-setup) for detailed steps. Monitoring Use the standard Prometheus + Grafana stack for observability: - Install Node Exporter for system metrics (CPU, RAM, disk, network) - Configure Prometheus to scrape your node's metrics endpoint - Set up Grafana dashboards to visualize node health, sync status, and proposal statistics The node also exposes a System API for diagnostics – connection status, health checks, and performance metrics. See Radix APIs (/developers/infrastructure/02-radix-apis) for details. Maintenance - Protocol updates – update your node software when new protocol versions are released; validators must signal readiness - Backups – the ledger can be rebuilt from the network, but backing up your validator key is critical - Snapshots – daily ledger snapshots are available at snapshots.radix.live (https://snapshots.radix.live) for faster initial sync Next Steps - Radix APIs (/developers/infrastructure/02-radix-apis) – what your node exposes, and when to use it instead of a public Gateway External Links - Node introduction (https://docs.radixdlt.com/docs/node) - Node setup guide (https://docs.radixdlt.com/docs/node-setup) - Validator setup (https://docs.radixdlt.com/docs/node-setup) - Maintenance guide (https://docs.radixdlt.com/docs/running-infrastructure) - babylon-node GitHub (https://github.com/radixdlt/babylon-node) - babylon-nodecli GitHub – the babylonnode tool (https://github.com/radixdlt/babylon-nodecli) ## XSEED URL: https://radix.wiki/ecosystem/xseed Updated: 2026-09-12 Summary: XSEED (ticker $XSE ) is the reward token of XSEED STAKING , a Swiss-operated validator node on the Radix mainnet that has run under the name "XSEED ST… Type Validator node and reward token Symbol XSE Validator XSEED STAKING 🇨🇭 (https://dashboard.radixdlt.com/validator/validator_rdx1svm98ppmxzft82lykaeudwp3z562dlqk692ws5us5a8lr78ux3v8kr) Total Stake 98.70M XRD (12 Sep 2026) Rank by Stake 13 of 186 registered Uptime 100% (trailing month) Validator Fee 9.8% Token Supply 10,000,000 (fixed) Jurisdiction Switzerland XSEED (ticker $XSE) is the reward token of XSEED STAKING, a Swiss-operated validator node (/contents/tech/core-concepts/staking) on the Radix (/contents/tech/releases/radix-mainnet-babylon) mainnet that has run under the name "XSEED STAKING 🇨🇭 - fully committed since 2021" (https://dashboard.radixdlt.com/validator/validator_rdx1svm98ppmxzft82lykaeudwp3z562dlqk692ws5us5a8lr78ux3v8kr) since the Olympia (/contents/tech/releases/radix-mainnet-olympia) era. The token rewards long-term delegators to the node and funds projects across the Radix ecosystem — its on-ledger resource metadata (https://dashboard.radixdlt.com/resource/resource_rdx1tkkzy2zg4na22kskk00q50v0kghw89akeh84u60xczxsr0ynes80d5) describes it simply as “Supporting and funding various Radix projects.” Not to be confused with MetaXSeed Games ($MXS), an unrelated gaming token on Ethereum/Avalanche. Despite the similar name, the Radix $XSE token described here has no connection to that project. Status The node is active. Read directly from the ledger on 6 August 2026 at epoch 332574, XSEED STAKING (https://dashboard.radixdlt.com/validator/validator_rdx1svm98ppmxzft82lykaeudwp3z562dlqk692ws5us5a8lr78ux3v8kr) is registered, accepts delegated stake, holds 100,236,442.14 XRD — rank 13 of the 188 registered validators by stake — and has recorded 100% uptime over both the trailing week and the trailing month. It charges a 9.8% validator fee. Its stake units are resource_rdx1tka…ygjr9dp and its unstake claim NFTs resource_rdx1n2v…9a65phv. This page previously described the project as dormant, on the strength of the figures shown by its own website. That was an error worth naming, because the failure is instructive: xseedstaking.com (https://www.xseedstaking.com/) renders a live-stats panel reporting “0 M+” total staked and “1%” uptime for a node that has not missed a proposal in a month. The site's own dashboard is broken, not the node. A project's website — whether it loads, and whatever numbers it prints — is not evidence about a validator's operational state; the consensus manager is. That rule cuts in both directions, and here it cut against a page that had trusted the presentation layer. What is genuinely stale is the site's editorial content, which has not been substantively revised since 2024, and the radixdltstaking.com (https://www.radixdltstaking.com/) domain the operation used to run under — still the host of the $XSE icon recorded in the token's on-ledger metadata, and now redirecting to the current domain. The halt, and the node's position in it Radix mainnet produced no rounds between 21:19:48.939 UTC on 31 August 2026, when validators holding more than two thirds of stake broke liveness deliberately (/contents/history/hyperlane-asset-drain-2026) , and 11:35:28.96 UTC on 11 September, when enough of the set was back online running babylon-node v1.4.0.0, “Eagle Ray” (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) for consensus to certify a round. The reading below was taken twenty-nine minutes before that. Read from StakeSafe (/ecosystem/stakesafe) 's Radix Network Dashboard (https://validators.stakesafe.net) at 11:05 UTC on 11 September 2026, XSEED STAKING reads v1.4.0.0 and reads online, at a 9.80% fee and 100.00% recent uptime. Of the forty-one validators carrying Eagle Ray at that reading it is the largest, and because the twelve validators above it all read offline it is also the highest-ranked node on the dashboard that is both upgraded and up. That position is a consequence of how the restart is being run rather than a distinction the operator claimed. The twelve larger validators are upgraded and deliberately offline (/ecosystem/stakesafe#sweep407-offline-by-design) , waiting to boot together once enough of the tail is back, so XSEED heads the upgraded-and-online list by being in the part of the set that is coming back first. Its stake read 98,684,205 XRD, rank 13 of the hundred validators in the active set, 1.55 million XRD below the 100,236,442.14 XRD this page read from the ledger on 6 August; that movement happened before the stop, because no stake moved during it. Those figures could not be confirmed at the time the way the rest of this page was, and the reason is worth stating: with the network halted the Gateway (https://mainnet.radixdlt.com/status/gateway-status) refuses state queries outright, answering HTTP 500 at a sync delay of more than ten days, so there is no consensus manager to ask. This page's own rule, that a validator's operational state is evidenced by the ledger and not by a website, has a corollary it did not need until now: while the ledger is stopped, the only live evidence is a third party probing the nodes directly. Confirmed from the ledger (12 September 2026) The dashboard reading above can now be checked against the thing it was standing in for. Read from /state/validators/list (https://mainnet.radixdlt.com/state/validators/list) at 15:08 UTC on 12 September 2026, epoch 340,227, XSEED STAKING is registered, accepts delegated stake, and holds 98,704,580.39 XRD in its stake vault – rank 13 of the 186 registered validators, and 20,375 XRD above the figure StakeSafe’s dashboard showed during the halt. The vault’s last_changed_at_state_version is 557,940,249, a state committed the same day, so stake is moving again. The substitution held, in other words, and it is worth saying which way. A third party probing the nodes directly is evidence about a validator when the ledger cannot be asked; it is not better evidence than the ledger, and here it was 0.02% low. The rule this page states above survives unchanged: the consensus manager is what settles a validator’s operational state, and everything else is a stand-in for it. Token $XSE is a native Radix fungible resource (resource_rdx1tkk…es80d5) with 18 decimal places and a fixed total supply of 10,000,000. Verified on-ledger on 6 August 2026: its mint, burn, freeze and recall authorities are every one set to deny_all and the rule set is locked, so no further tokens can ever be created, none can be destroyed, and no authority can later be granted — the supply is immutable in the strong sense rather than merely unused. Withdraw and deposit are allow_all, so the token transfers freely. Distribution follows a schedule published by the operator and weighted toward staking rewards, with smaller allocations reserved for long-term delegator bonuses, marketing, team and future projects. Staking and Distribution Delegators earn $XSE by staking XRD to the XSEED STAKING validator through the Radix Wallet (/contents/tech/core-protocols/radix-wallet) . Per the operator's published terms, roughly 1 $XSE is distributed for every 20 XRD staked, subject to a minimum staking period of one month, and the distribution is capped at 5,000,000 $XSE — half the fixed supply. XRD rewards accrue from validator emissions in the ordinary way; the $XSE distribution is an additional incentive layered on top by the node operator and is not a protocol feature. External Links - XSEED Staking – Official Website (https://www.xseedstaking.com/) - XSEED STAKING – Radix Dashboard (validator) (https://dashboard.radixdlt.com/validator/validator_rdx1svm98ppmxzft82lykaeudwp3z562dlqk692ws5us5a8lr78ux3v8kr) - $XSE – Radix Dashboard (resource) (https://dashboard.radixdlt.com/resource/resource_rdx1tkkzy2zg4na22kskk00q50v0kghw89akeh84u60xczxsr0ynes80d5) - XSEED Society – Telegram (https://t.me/XSEED_SOCIETY) - XSEED on X (https://x.com/xseed_radix) ## StakeSafe URL: https://radix.wiki/ecosystem/stakesafe Updated: 2026-09-12 Summary: Radix mainnet had produced no rounds since 21:19:48.939 UTC on 31 August 2026 , when validators holding more than two thirds of stake broke liveness d… StakeSafe Type Radix validator-node operator Status 🟢 Active – three production validators registered and accepting delegations Validators StakeSafe Amsterdam, StakeSafe Rotterdam and the acquired Avaunt Staking (/ecosystem/avaunt-staking) node (+ a seed node) Rotterdam 81,182,620 XRD staked, rank #21 (https://dashboard.radixdlt.com/network-staking/validator_rdx1s048k34ctk3m57gumema2e5jmhfxhdryyr5hq42xa9q59pvn8lezg8) Amsterdam 75,944,786 XRD staked, rank #23 (https://dashboard.radixdlt.com/network-staking/validator_rdx1s066xuq885l0mttgmx4ptflte6fepkt0c06mqnqtdgajj4mcwh70q4) Combined stake 299,581,425 XRD across four nodes, 6.08% of all staked XRD (epoch 339,152, 29 August 2026) Validator fee Every node queued to 25% – Amsterdam and Rotterdam from 15% at epochs 339,608 / 339,609, the acquired Avaunt node from 2% at epoch 342,482 (seed node to 100%) Acquired Avaunt Staking (/ecosystem/avaunt-staking) 's validator – owner badge held by the same account as Amsterdam's, confirmed at epoch 339,152 Free network tooling Radix Network Dashboard (https://validators.stakesafe.net) , StakeSafe Alert, a seed node and an outgoing node Social @StakeAmsterdam (https://x.com/StakeAmsterdam) · Telegram (https://t.me/stakesafenet) The Eagle-Ray adoption tracker (10 September 2026) Radix mainnet had produced no rounds since 21:19:48.939 UTC on 31 August 2026, when validators holding more than two thirds of stake broke liveness deliberately (/contents/history/hyperlane-asset-drain-2026) after every Hyperlane-bridged asset on the network was drained. It restarted on 11 September (#sweep418-how-it-resolved) ; the three sections that follow were written while it was down, and each is a dated reading. The fix shipped as babylon-node v1.4.0.0, “Eagle Ray” (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) on 10 September, and at 16:15 UTC that day (https://t.me/RadixAccountabilityCouncil/1019) the Radix Accountability Council told node operators to install it. No restart date has been published. What has been published is a threshold. At 20:18 UTC on 10 September 2026, in the main Radix Telegram group, StakeSafe's Bart Roozeboom announced that the operator's free Radix Network Dashboard (https://validators.stakesafe.net) now tracks Eagle-Ray adoption live (https://t.me/radix_dlt/1002910) : the share of active validator-set stake already running v1.4.0.0 against the share still on older versions, as a chart and a breakdown table. The announcement states the condition in one line – Once more than 67% of active stake is on Eagle-Ray, network liveness resumes and the network forks to a patched version – and the dashboard repeats it in a banner above the charts. The message is authorship-verified as Bart Roozeboom at its public embed (https://t.me/radix_dlt/1002910?embed=1&mode=tme) . The 67% is not a StakeSafe rule: it is the ordinary two-thirds quorum Radix's consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) needs to commit a round, which is the same reason the network could be stopped by the same fraction of stake in the first place. Read from the dashboard's served page at 23:08 UTC on 10 September 2026, seven hours after operators were cleared to upgrade: Reading XRD Share of the active set Stake running Eagle-Ray (v1.4.0.0) 1,260,200,690 27.03% Stake not running Eagle-Ray 3,402,820,650 72.97% Stake whose node is online 1,519,267,322 32.58% Stake whose node is offline 3,143,754,018 67.42% Threshold for liveness to resume – more than 67% Two details in that table are worth stating precisely, because the dashboard does not. The percentages are computed on 4,663,021,341 XRD – the active validator set, the top 100 by stake, which is the dashboard's own online and offline figures added together – and not on the 4,877,281,907 XRD the same panel heads with as total delegated stake; the two differ by 214,260,566 XRD, so a figure quoted against the wrong base runs about 4.4% high. And the upgraded stake is concentrated: 28 rows in the explorer table read v1.4.0.0, and their delegated stake sums to the 1,260,200,692 XRD the panel rounds to 1,260,200,690. The gap is forty percentage points, and most of it sits behind nodes that are switched off rather than behind nodes running the wrong version: two thirds of the active set's stake is offline. Restarting therefore asks operators to come back and to come back upgraded, which is why the council's instruction is to leave a fully upgraded node online and working rather than merely to install the release. The dashboard refreshes itself every five minutes, so any reading of it – including this one – is a snapshot rather than a settled figure. Where the gap sits (11 September 2026) Read from the dashboard at 07:12 UTC on 11 September 2026, eight hours after the reading above, both panel figures had risen: 1,455,804,324 XRD is running v1.4.0.0, 31.22% of the active set, against 1,260,200,690 and 27.03% the previous evening; stake with a node online rose further over the same hours, from 1,519,267,322 and 32.58% to 1,746,449,780 and 37.45%. The two lines are separating rather than converging, because operators are coming back online faster than they are coming back upgraded: the stake that is online but not on Eagle Ray widened from 5.6 points of the active set to 6.2. The explorer table below the panel says where the rest of it sits. Thirty-nine rows read v1.4.0.0 and their delegated stake sums to 1,455,804,327 XRD, reproducing the panel's adoption figure; thirty-eight of those thirty-nine have a node online. None of the twelve largest validators is among them. Ranked by delegated stake those twelve are SRWA (/ecosystem/srwa) , Astrolescent (/ecosystem/astrolescent) , Reddicks (/ecosystem/reddicks) , Weft (/ecosystem/weft-finance) , Jazzer9F, Ocinode, DeFiPlaza (/ecosystem/defiplaza) 's investment node, Radical Staking (/ecosystem/radical-staking) , Avaunt Staking (/ecosystem/avaunt-staking) , both CaviarNine (/ecosystem/caviarnine) validators and RadixStake; every one reads a v1.3 version and every one reads offline. Together they hold 2,073,397,316 XRD. The shortfall between current adoption and the 3,124,224,299 XRD that more than 67% of the active set comes to is 1,668,419,975 XRD, so those twelve operators hold between them more than enough to end the halt, and the largest validator that has reached Eagle Ray, XSEED Staking (/ecosystem/xseed) at 98,684,205 XRD, ranks thirteenth. One caveat on the version column, because it changes what the table proves. The explorer reports the version a node last advertised, so an offline validator shows the version it was running when it stopped. A v1.3 reading against an offline node means the explorer has not seen that node on Eagle Ray, not that its operator has not installed the release; the council's instruction (https://t.me/RadixAccountabilityCouncil/1019) is to install it and leave the node online, and only the second half of that is visible here. What the table establishes is where the stake is, and that the threshold cannot be reached by the operators already running. What it does not establish is why those twelve are down, and the answer was published the same morning: it is deliberate (#sweep407-offline-by-design) . What happens once it is reached is fixed in the node software rather than announced: the fork enacts at the start of epoch 339,898 without a readiness vote, after an epoch in which rounds are produced but user transactions are refused. The sequence, and the reading of the halt that goes with it, are on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status#halt-restart-sequence) . Offline by design (11 September 2026) Read from the dashboard at 11:05 UTC on 11 September 2026, three hours and fifty-three minutes after the reading above, 1,528,203,682 XRD is running v1.4.0.0, 32.77% of the active set, and 1,848,850,528 XRD, 39.65%, has a node online. Adoption rose by 72,399,358 XRD and 1.55 points over those four hours and none of it came from the top of the table: the same twelve rows, in the same order, still read a v1.3 version, still read offline, and still hold 2,073,397,318 XRD between them. Forty-one rows now read v1.4.0.0 against thirty-nine at 07:12, and the shortfall to the 3,124,224,298 XRD that more than 67% of the active set comes to has narrowed to 1,596,020,616 XRD. The whole of the movement is in the tail. The reason the twelve have not moved was stated in the main Radix Telegram group two hours before that reading, and it inverts what the table appears to show. Asked why the ten largest validators could not spare ten minutes to update, Faraz replied at 10:11:24 UTC (https://t.me/radix_dlt/1003000) that 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 aim is to be well clear of 67% rather than barely over it, because crossing the threshold marginally risks a node developing a problem and falling over, triggering another liveness break, and a handful of large nodes is easier to coordinate than a long tail of small ones. Daffy had answered the same complaint (https://t.me/radix_dlt/1002990) sixteen minutes earlier in fewer words: the update is planned this way, and any conclusion about a validator still on v1.3 should wait until a week after the network is live. Both messages are authorship-verified at their public embeds ( Faraz (https://t.me/radix_dlt/1003000?embed=1&mode=tme) , Daffy (https://t.me/radix_dlt/1002990?embed=1&mode=tme) ). Two things follow for anyone watching the chart. The caveat recorded here at 07:12 UTC was the operative one rather than a hedge: a v1.3 reading against an offline node says only that the explorer has not seen that node on Eagle Ray, and for the twelve largest it is now sourced that the release is installed. And the restart will arrive as a step rather than a climb. The stake that closes the gap is held by nodes that are down on purpose, so adoption can sit well short of 67% until the moment it clears, and the chart measures the tail's progress rather than counting down to a restart. One class of row is not covered by that explanation, and it is the class the version column reads without ambiguity, because the staleness the caveat describes applies only where the node is down. Eighteen validators read online and read a v1.3 version, holding 327,184,952 XRD, 7.02% of the active set: nodes that are up and advertising a build the threshold does not count. The two largest are Cadwynbloc at 64,436,221 XRD and Supreme Stake (/ecosystem/supreme-stake) at 51,025,921 XRD, and the set also holds the Community Council Node, HUG (/ecosystem/hug) , Blockshard (/ecosystem/blockshard) , Allnodes (/ecosystem/allnodes) and DeXter (/ecosystem/dexter) . These are the operators the council's instruction (https://t.me/RadixAccountabilityCouncil/1019) is aimed at, and they are also why the two panels cannot be read as one: the 6.88-point spread between online stake and Eagle-Ray stake is this class, less the single mirror row, Atlas-Staking.com, which reads v1.4.0.0 and offline at 6,538,106 XRD. The ledger was unchanged by any of it. Read at 11:05:08 UTC on 11 September, gateway-status (https://mainnet.radixdlt.com/status/gateway-status) returned state version 557,840,622 at epoch 339,896, round 102, and reported itself the same interval behind the ledger. That is the aggregator’s position rather than the ledger’s: the last state committed before the stop was 557,840,627, epoch 339,897 round 4, five states and forty-two seconds further on, and the status endpoint never showed the difference. Thirty minutes after this reading the network was running again. How it resolved (11 September 2026) The tracker above stops half an hour short of the thing it was tracking. Radix mainnet certified its first round in ten days at 11:35:28.96 UTC on 11 September 2026 – state version 557,840,628, epoch 339,897 round 5 – thirty minutes after the reading above. Epoch 339,897 then ran to its end producing rounds and refusing user transactions, and at 11:39:25.129 UTC epoch 339,898 opened at round 2 with the Eagle Ray (/contents/tech/releases/protocol-updates) fork enacted and the moratorium lifted together. Read from the transaction stream (https://mainnet.radixdlt.com/stream/transactions) , the boundary is three entries: 557,840,627 at 21:19:48.939 UTC on 31 August, 557,840,628 at 11:35:28.96 UTC on 11 September, and sixty-five further round changes before the first user transaction at 557,840,694. The ledger produced no round for ten days, fourteen hours and sixteen minutes. The reading this page took from the sequence held. Adoption did arrive as a step rather than a climb: it stood at 32.77% of the active set at 11:05 UTC, and the fork enacted with 80.85% of active-set stake on the release (/contents/history/hyperlane-asset-drain-2026#the-fix-and-the-restart) , so the twelve largest validators booted together as Faraz had said they would and the chart never counted down to anything. The dashboard's value was in showing where the stake sat rather than in predicting the hour, and on that it was accurate throughout. The full sequence and its ledger record are on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status#sweep408-status-restored) . The fleet after the Avaunt handover (29 August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) validator list at epoch 339,152 (29 August 2026, 07:13 UTC), the handover announced for 28 August has completed, and the evidence is custody rather than announcement. The Avaunt Staking (/ecosystem/avaunt-staking) validator's owner is now the account account_rdx16xrp5e8…kpkdl84f – the same account that holds StakeSafe Amsterdam's owner badge. Rotterdam and the seed node sit in two further accounts, so the operator does not run its fleet from one key, but the acquired node and Amsterdam share one. The second change answers the question this page could not answer on 21 August. The incoming validator's fee has now been stated, and it was stated on ledger: a validator_fee_change_request raising its fee factor from 0.02 to 0.25, effective at epoch 342,482. With that request the whole fleet converges on the same number. Validator Rank Staked XRD Fee now Queued Effective epoch ⏩ Avaunt Staking ⏩ ShardSpace.app (/ecosystem/avaunt-staking) 9 142,170,038 2% 25% 342,482 (about 9 September 2026) StakeSafe Rotterdam 22 81,158,617 15% 25% 339,609 (about 30 August 2026) StakeSafe Amsterdam 24 76,042,330 15% 25% 339,608 (about 30 August 2026) StakeSafe Seed Node 126 210,440 15% 100% 339,609 (about 30 August 2026) That is 299,581,425 XRD across four validators, or 6.08% of the 4,928,844,882 XRD staked to the network's 287 registered validators at the same reading – up from the 157.1 million XRD across two nodes this page recorded eight days earlier. The dates are estimates derived from the five-minute target epoch length; the epoch numbers are the commitment. Two of those repricings land within about a day and a half of this reading. None of them is visible on the validators themselves: all four still display the fee they charge today, because a queued change lives in the fee-change request rather than in the fee the validator reports, and a delegator reading the name, the fee and the website sees nothing at all. It is the same shape as the handover itself, where the sale was invisible in every field the validator published and legible only in where the owner badge sat (/ecosystem/avaunt-staking) . Ledger position and the queued fee increase (August 2026) Read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 336,990 (21 August 2026, 19:05 UTC), both validators (/contents/tech/core-concepts/validator-nodes) are registered and accepting delegated stake. StakeSafe Rotterdam (https://dashboard.radixdlt.com/network-staking/validator_rdx1s048k34ctk3m57gumema2e5jmhfxhdryyr5hq42xa9q59pvn8lezg8) holds 81,182,620 XRD at rank 21 and StakeSafe Amsterdam (https://dashboard.radixdlt.com/network-staking/validator_rdx1s066xuq885l0mttgmx4ptflte6fepkt0c06mqnqtdgajj4mcwh70q4) 75,944,786 XRD at rank 23, of 188 registered validators and 4.69 billion XRD staked to them — 157.1 million XRD combined, about 3.4% of all staked XRD. The two nodes have swapped places since this page was last written: Amsterdam was the larger of the pair in July 2026. Both validators carry a pending fee change already recorded on ledger. The validator_fee_change_request on each raises the fee factor from the current 0.15 to 0.25 — from a 15% to a 25% validator fee — effective at epoch 339,608 for Amsterdam and epoch 339,609 for Rotterdam. Radix's mainnet genesis config targets 300,000 ms — five minutes — per epoch (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) , which puts those roughly nine days after the reading above, or approximately 30 August 2026; the epoch is the exact commitment and the date is an estimate derived from it. The delay is not the operator's choice but the protocol's. The same config sets num_fee_increase_delay_epochs to 4,032 epochs — about two weeks — and the Radix Engine's validator blueprint applies it only when the new fee factor is higher than the current one (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs) ; a fee cut takes effect immediately. Working backwards from the effective epochs, the two requests were signed at about epoch 335,576, on or around 16 August 2026 — before the Avaunt announcement, not in response to it. A pending request is not final either: a further update_fee call replaces it, so the owner can still lower or cancel the increase before it lands, and delegators have the two-week window to move if they would rather not pay it. There is a third request, on a third validator, and it is a different kind of number. StakeSafe Seed Node (https://dashboard.radixdlt.com/network-staking/validator_rdx1svlvyezsxp467pznd2kfnhqpenmw7hpdgnxjgu3s8mzxtruz77d3q3) — registered, accepting delegations and holding a token 210,099.38 XRD — carries a validator_fee_change_request with a new fee factor of 1: a 100% validator fee, also at epoch 339,609. A fee that takes every emission is not a price, it is a way of asking delegators to leave, and it is the same move Leaf Node (/ecosystem/leafnode) made on 10 August 2026 eleven minutes before it deregistered. StakeSafe has announced nothing about the seed node's future, so this is recorded as what the ledger shows rather than as a stated plan; the two production validators are unaffected, and this page's other numbers were read in the same pass over the full mainnet validator list at epoch 336,991. Why the fee matters this month The rise is scheduled to take effect within days of StakeSafe taking on Avaunt Staking (/ecosystem/avaunt-staking) 's node, announced on 21 August 2026 for 28 August. Avaunt has been running its validator at a 2% fee; delegators who follow the operator's advice and leave their stake in place will be staking under a materially different arrangement. The two facts are independent — the fee requests were signed around 16 August, before the Avaunt announcement, and apply to StakeSafe's own two nodes rather than to the incoming one — but they land in the same week, and the incoming validator's fee after the handover has not been stated. Free tooling run for the network Alongside the validators, StakeSafe publishes infrastructure it does not charge for: the Radix Network Dashboard (https://validators.stakesafe.net) (live, serving a full validator-set view), StakeSafe Alert for node runners and delegators, and a seed node and an outgoing node for the peer-to-peer network. The operator states it has run Radix nodes on its own hardware since the Olympia (/contents/tech/releases/radix-mainnet-olympia) betanet days, across multiple regions and fully non-custodial. StakeSafe is a product that is designed to provide high-performance nodes, secure staking, and professional support for the decentralized Radix ecosystem. The product's focus is on ensuring the efficient and secure operation of the Radix network through the provision of reliable nodes that enable secure staking and provide a dedicated support team that can help users with any issues that they might encounter. By using StakeSafe, users on the Radix network can benefit from reliable and high-performance nodes that provide them with fast transaction processing speeds and low latency. Additionally, the product also enables users to securely stake their tokens while maintaining control over their assets, providing them with greater security and peace of mind. Overall, StakeSafe is a product that aims to empower users and contribute to the growth and success of the Radix ecosystem by providing cutting-edge infrastructure and support that enables users to transact on the network with confidence and ease. Mission The mission of StakeSafe is to empower and contribute to the decentralized Radix ecosystem by providing high-quality infrastructure, secure staking services, and professional support. Benefits Delegators can benefit from staking with StakeSafe for several reasons: Enhanced Security StakeSafe prioritizes secure staking, ensuring that delegators' assets are protected. By utilizing secure staking mechanisms, delegators can have peace of mind knowing that their tokens are being staked in a safe and reliable manner. Reliable Infrastructure StakeSafe provides high-performance node, which are essential for efficient and effective staking. Delegators can rely on StakeSafe's robust infrastructure to ensure smooth and uninterrupted staking operations. Dedicated Professional Support StakeSafe offers dedicated support from a team of professionals. This support can be invaluable for delegators who may have questions, need assistance, or encounter any issues during the staking process. The responsive and knowledgeable support team can provide timely help and ensure a positive staking experience. Active Participation in the Radix Ecosystem By staking with StakeSafe, delegators actively contribute to the decentralized Radix ecosystem. Their participation and stake help secure the network while potentially earning rewards in the form of incentives or staking rewards. Source: StakeSafe (https://www.stakesafe.net) – the operator runs its two production validators (Amsterdam & Rotterdam) plus a seed node on the Radix mainnet. Impact StakeSafe can have several impacts on users and the wider ecosystem. Here are a few potential impacts of using StakeSafe: Staking Incentives StakeSafe allows users to stake their tokens and participate in the network's consensus protocol. By doing so, users can potentially earn rewards or incentives for contributing to the network's security and operation. This can be a significant incentive for users to actively participate in the ecosystem. Network Security Staking services like StakeSafe play a crucial role in maintaining the security and integrity of the network. By staking their tokens, users contribute to the network's decentralization and consensus process, making it more resilient to attacks or malicious activities. Ecosystem Growth Delegators using StakeSafe contribute to the health and growth of the ecosystem. By actively participating in the network, users help ensure its stability and attract more participants, developers, and businesses to the ecosystem. This increased activity and engagement could lead to a flourishing Radix network. User Convenience StakeSafe aims to provide a user-friendly staking experience, simplifying the process for users who may not have the technical expertise or infrastructure to stake directly. This convenience can encourage more users to participate and stake their tokens, boosting overall network participation and security. ## Hyperlane Asset Drain and Network Halt (August 2026) URL: https://radix.wiki/contents/history/hyperlane-asset-drain-2026 Updated: 2026-09-12 Summary: On 31 August 2026, between 16:02 and 16:58 UTC, twenty-six transactions on Radix mainnet emptied every Hyperlane -bridged asset held on the network an… Window 16:02:20 – 16:57:41 UTC Network Radix mainnet Transactions 26, all committed successfully Assets taken hUSDC, hUSDT, hETH, hWBTC, hSOL, hBNB – the whole Hyperlane-bridged set Face value of the stablecoins 458,914.89 hUSDC + 72,420.38 hUSDT Exit Hyperlane warp routes, destination domain 1 Recall or freeze used No. Every asset had recaller and freezer set to deny_all and locked Root cause A Radix Engine flaw in how vault references are granted – stated by the Foundation and the Radix Accountability Council on 31 August, read at the source below Network status Halted after epoch 339,897 round 4 at 21:19:48 UTC, 31 August 2026. Restarted at epoch 339,897 round 5, 11:35:28 UTC on 11 September 2026; user transactions resumed at epoch 339,898 round 2, 11:39:25 UTC. Down for 254 hours, 15 minutes and 40 seconds Fix The Eagle Ray (/contents/tech/releases/protocol-updates) protocol update, merged into radixdlt-scrypto at 17:33 UTC on 7 September and released as Scrypto v1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) . Carried on the node side by babylon-node v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , released final at 03:59 UTC on 10 September. Enacted unconditionally at the start of epoch 339,898, 11:39 UTC on 11 September 2026, with 80.85% of active validator-set stake on the release Ledger record Collecting account (https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29) · Largest transaction (https://dashboard.radixscan.io/transaction/txid_rdx19lzunu3relu436dm9r4mnmvyjx3yzr2723gk7d7kv0tce8g9h4kqd60u5v/summary) On 31 August 2026, between 16:02 and 16:58 UTC, twenty-six transactions on Radix mainnet emptied every Hyperlane (/ecosystem/hyperlane) -bridged asset held on the network and sent the proceeds out over Hyperlane's own warp routes. The assets came out of user accounts and out of the liquidity pools of Radix dApps alike, in one pass, without a single owner signing anything. Six hours later the remaining supply of hUSDC (https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) on Radix was 1,092.79 tokens, and the other five wrapped assets stood at fractions of one unit. The incident followed by less than a day the exploit of Weft Finance (/ecosystem/weft-finance) , whose attacker also left through a Hyperlane warp route. The two are different in kind, and that difference is most of what a reader needs: the Weft attacker manipulated the price of a listed collateral inside one application’s own contracts, which that application could change and has changed; this one needed no application, no oracle and no price feed, because the authorization it defeated belonged to the engine. Five hours later the cause was stated publicly as a flaw in the Radix Engine (/contents/tech/core-protocols/radix-engine) itself, placing every token and NFT on the network within reach of the same method rather than only the bridged six. At 21:19 UTC Radix mainnet was halted by its node runners, and it produced no round for the next ten days; the Eagle Ray (/contents/tech/releases/protocol-updates) protocol update enacted and transactions resumed at 11:39 UTC on 11 September 2026. What the ledger shows The largest of the twenty-six is txid_rdx19lzunu3…qd60u5v (https://dashboard.radixscan.io/transaction/txid_rdx19lzunu3relu436dm9r4mnmvyjx3yzr2723gk7d7kv0tce8g9h4kqd60u5v/summary) , committed at 16:33:28.554 UTC for a network fee of 8.39 XRD. It is a single manifest and it does three things in order. First it publishes a package. The blueprint is named LiquidityTool and it exposes sixty-one functions called run_0 through run_60, which is the shape of code written for one transaction rather than for reuse. Then it calls all sixty-one, and each call takes one argument: an internal_vault_ address. Sixty distinct vaults appear across the calls. An internal vault is the container an account or component holds a resource in, and its address is public. After the calls the worktop holds 442,985.632108 hUSDC drawn from fifty-nine separate accounts and components. Last it takes that balance and 380.037752172 XRD into buckets and calls transfer_remote on the hUSDC warp route (https://dashboard.radixdlt.com/component/component_rdx1crvhu42czzpvkh556228sc5xk7uz69yvwcsqn23u5yy65pea0w02l0) , passing destination domain 1 and a twenty-byte recipient address in EVM format. The change goes to account_rdx168lx…3973f29 (https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29) , which is the only account the manifest names anywhere. Two absences in that manifest carry as much as the instructions do. There is no proof, no badge and no owner authorisation of any kind in front of the vault calls. And there is no LOCK_FEE instruction at all: the fee was locked from inside the published blueprint, against a vault the transaction passed to it by address. The XRD for fees came out of account_rdx1283x6…0ucx9j (https://dashboard.radixdlt.com/account/account_rdx1283x6gv9sxx75q4aypdpra5u0v3e7hh4hk7paskd4egx2nev0ucx9j) , which lost 500 XRD on each of the twenty-six and received nothing back. Whether that account belongs to the attacker or to a third party whose XRD vault was used the same way as the sixty others is not settled by the ledger. What was taken Summed across all twenty-six transactions, and set against what the same resources report on the ledger at epoch 339,871 (19:09:50 UTC, 31 August 2026): Asset Taken Supply remaining on Radix hUSDC (https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) 458,914.885741 1,092.793964 hUSDT (https://dashboard.radixdlt.com/resource/resource_rdx1th4v03gezwgzkuma6p38lnum8ww8t4ds9nvcrkr2p9ft6kxx3kxvhe) 72,420.384476 0.036292 hETH (https://dashboard.radixdlt.com/resource/resource_rdx1th09yvv7tgsrv708ffsgqjjf2mhy84mscmj5jwu4g670fh3e5zgef0) 61.078006 0.010278 hWBTC (https://dashboard.radixdlt.com/resource/resource_rdx1t58kkcqdz0mavfz98m98qh9m4jexyl9tacsvlhns6yxs4r6hrm5re5) 6.348243 0.005600 hSOL (https://dashboard.radixdlt.com/resource/resource_rdx1t5ljlq97xfcewcdjxsqld89443fchqg96xv8a8k8gdftdycy9haxpx) 536.159806 0.136338 hBNB (https://dashboard.radixdlt.com/resource/resource_rdx1t4et4jddp2fdupr00k83ct9jpnkgewply42l5098ztjkfvjfedvjva) 32.910105 0.002105 XRD 13,000 (fees, 500 per transaction) – The two stablecoins alone carry a face value of 531,335.27 US dollars. The rest depends on market prices, and the wiki states no total for it. The supply column is the plainer measure of what happened: bridging an asset out of Radix burns it here, so the drain is visible in the supply of each resource, and what is left of five of the six is dust. The hour The sequence reads as a test followed by a sweep. - 16:02:20 to 16:22:37. Six transactions, one per asset, each moving a token amount: 0.005 hETH, 0.00035324 hSOL, 0.015 hBNB, 0.00084948 hWBTC, 482.99 hUSDT, 384.81 hUSDC. Each still paid the full 500 XRD bridge fee. - 16:30:08 to 16:57:41. Twenty transactions carrying the rest. The hUSDC sweep at 16:33 is the largest single one; hUSDT, hWBTC, hETH and hSOL follow in blocks. - 17:17 UTC. The first public report reaches the main Radix Telegram group, twenty minutes after the last transaction committed. - 18:18 UTC. A message in that group (https://t.me/radix_dlt/1000557) states that Hyperlane, the security firm Zellic and others have been contacted, and that parties on the receiving chain are being approached to contain the assets. The collecting account has committed no further transaction since 16:57:41, read at ledger state version 557,804,842. Why the usual controls did not apply A Radix resource can carry authorities that let a named badge holder claw tokens back or halt movement in them. Neither existed here. Read live at 19:08 UTC on 31 August, hUSDC (https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) reports recaller and freezer both set to deny_all, with rules_locked true, so those settings cannot be changed by anyone. The token can be minted and burned only by the badge the bridge holds, which is what a warp route needs in order to work at all. The consequence runs both ways. Nobody could have recalled these assets out of user accounts, which is the property holders were told they had. And nobody can recall them back, which is why containment moved to the receiving chain within the hour. The drain was not a recall and not a freeze; on the ledger it is an ordinary withdrawal that no owner authorised. XRD itself was not swept by the twenty-six transactions. The 13,000 XRD that moved in them was fee payment, and it came from one vault rather than from the network at large. The scope of the drain is what the attacker could bridge, which is not the same statement as the scope of what the method could reach, and not the same statement as the scope of the loss either: the pools the drain emptied paid out the rest of their $XRD to whoever asked next (#empty-pools) . Who the sweep took from The 16:33 transaction is the one to read for this, because it is the largest and because its receipt lists every balance it changed. Sixty-two entities lost hUSDC in it, and they are not all people. Thirty-six are user accounts. Thirteen are native two-resource pools, the component type that holds a trading pair and issues a pool unit to whoever deposited into it. Thirteen are dApp components: the largest is XHSWAP (https://dashboard.radixdlt.com/component/component_rdx1cpk2tvwyg2pkzft9ysdwqffwsm6gcca2p3jd6at0p4h0ayty30shcl) , which exists to swap Radix-native assets into Hyperlane ones, and the second is an order book for the $XRD/hUSDC pair. Held by Entities hUSDC taken User accounts 36 182,508.03 Native two-resource pools 13 155,391.82 dApp components 13 105,085.79 Two resources moved in the whole transaction, hUSDC and $XRD, and the only $XRD row is a 380.04 credit to one component plus the 8.39 fee. No non-fungible balance changed at all, and the collecting account (https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29) holds no NFT at the last committed state version. That is the answer to the question the main Radix chat has been asking since the halt: staked $XRD, stake units and NFTs were not taken. A liquidity position was, if the pair had a bridged asset on one side, and its holder never touched a bridged asset directly. What the empty pools paid out An automated market maker prices one asset against the other by what it holds of each. Empty one side and the price of the remaining side collapses towards nothing, and the pool will still trade at it, because a pool has no way to know why its balance changed. Thirteen pools were left in that state at 16:33 UTC, and the first was arbitraged forty-one minutes later. The largest of them, pool_rdx1chxzajmur7p67h0uvk7etgnm9m67ptzfv7ysfdvq35ck2zz6zuttqq, issues the pool unit named Defiplaza hUSDC Base and held 2,687,281.65 $XRD alongside its 105,038.34 hUSDC at the state version immediately before the sweep. At 17:14:40 UTC one account withdrew 0.000001 hUSDC from its own balance (https://dashboard.radixscan.io/transaction/txid_rdx10v6taj9w9dg4343zx2mn7wuuqqs8shhwvq3e7qr6cu8jm76qmvkqqmkget/summary) , swapped it through DefiPlaza, and took the entire $XRD side. It is a different account from the one that ran the drain, and it signed an ordinary transaction: no flaw was needed, only a price. It kept going for an hour, through the $XRD/hSOL pools as well: Time, 31 August In Out 17:14:40 0.000001 hUSDC 106,076 ASTRL 17:16:01 106,076 ASTRL 2,420,151 $XRD 17:32:58 0.0001 hSOL 1,700,015 $XRD 17:33:15 0.0001 hSOL 1,574,116 $XRD 17:43:19 0.0000001 hSOL 102,266 ASTRL 17:56:59 10 $XRD 10,181 ASTRL 18:13:46 0.01 hUSDC 72,556 ASTRL That is 5,694,282 $XRD out of the pools between 17:16 and 17:33, and 185,003 ASTRL kept after the round trips. Two million of the $XRD left Radix at 17:18 and 17:26, in two calls to transfer_remote (https://dashboard.radixscan.io/transaction/txid_rdx1urfcwcwpspmyu2y945pu9k8felfjxz0hut4mwtftt35wr0d6js8qy0ue56/summary) on the $XRD warp route, a million each, destination domain 8453, which is Base. The drain used domain 1, which is Ethereum, and a different recipient address, so this is a second party rather than the same one twice. The account still holds 3,920,351 $XRD and 185,003 ASTRL, frozen where the ledger stopped. The loss lands on the liquidity providers, and it is still outstanding. The Defiplaza hUSDC Base pool unit had 91,710.25 tokens in supply before the sweep and the same 91,710.25 at the last committed state version, so nobody redeemed and nobody was diluted; the pool behind those 91,710.25 units reads zero $XRD and zero hUSDC. Every figure in this section is read from the Gateway pinned to state version 557,840,622, the position its status endpoint reported throughout the outage and five states short of 557,840,627, the last one the ledger reached; a pinned read (/contents/tech/core-protocols/radix-gateway-api#pinned-reads) was the only way to ask it anything while the network was halted. The cause At 22:02 UTC, five hours after the last transaction committed, the question this page had left open was answered in the main Radix Telegram group (https://t.me/radix_dlt/1000779) : "the issue was in the Radix Engine. Which means any assets, token or nft, could have been withdrawn and moved without permission." The Radix Accountability Council (https://t.me/RadixAccountabilityCouncil/925) had said the same eight minutes earlier — an outstanding issue in the execution layer, "the root cause that allowed the more recent hack on hAssets", with several sources converging on it. Neither statement described the flaw. The code does. Every reference a transaction names is checked before any WASM runs. In system_callback.rs::verify_boot_ref_value (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/system/system_callback.rs#L1147) , a node that is not global is accepted as a StableReferenceType::DirectAccess reference — and injected into the caller's frame — when its blueprint is FungibleVault or NonFungibleVault from the resource package. That is the whole test. The function does not ask who owns the vault, and it has no way to: ownership is not one of its inputs. Direct access to a vault exists in the Engine so that recall can work, and the vault blueprint gates recall behind the resource's RECALLER_ROLE (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/blueprints/resource/fungible/fungible_vault.rs#L271) . The second half is which other methods that reference reaches. In the same auth template, take, take_advanced and lock_fee are gated by the WITHDRAWER_ROLE of the resource — not by anything belonging to the account or component that holds the vault. On a freely transferable token that role is open, which is what makes the token transferable at all; what normally protects a balance is the account component's own access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) on its withdraw method, and a call made straight to the vault never passes through them. So the attacker did not need to defeat an authority. Holding a reference the Engine should never have granted, take was open to them on sixty vaults, and so was lock_fee — which is why the transactions carry no LOCK_FEE instruction and still paid their fees from a stranger's XRD vault. Both absences this page recorded before the cause was known follow from the same defect. Two consequences of that reading. The recall and freeze authorities were never in play: nothing was recalled, so deny_all on those roles was irrelevant to the outcome. And the reach is the reach of the Engine, not of the bridge — the Foundation's own statement puts every token and NFT on the network inside it, and the limit the attacker actually hit (https://t.me/radix_dlt/1000799) was transaction size, one vault named per call. The version this was read at is v1.3.1, the Cuttlefish release of 20 January 2026 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.3.1) ; the same function on the repository's main branch is byte-identical to it. The halt Radix mainnet committed its last round before the stop at 21:19:48.939 UTC on 31 August 2026 – state version 557,840,627, epoch 339,897, round 4. The Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) reported a different ledger for the whole of the outage, state version 557,840,622 at epoch 339,896 round 102, timestamped 21:19:06.179 UTC: its aggregator stopped five state versions short of the tip, and the gap was invisible for as long as neither number moved. Every endpoint that reads state refused with NotSyncedUpError for the next ten days, a sync delay that grew by a second every second because the ledger no longer moved. That is why wallets, the dashboard and the explorers went dark within minutes of the halt: they were all reading the same stalled Gateway. The stop was deliberate. Radix consensus requires more than two thirds of staked XRD to be validating; below that threshold the network cannot form rounds and simply stops, which is the liveness half of a BFT trade-off it makes in favour of safety. Node runners took enough stake offline to cross that line. The announcement (https://t.me/radix_dlt/1000764) at 21:17:30 UTC read: "Since epoch 339897, round 2, the Radix network has been halted by Radix's Node Runner Community. A fix for a security vulnerability is currently being developed and will be rolled out shortly, after which the network will resume." By 22:36 the StakeSafe validator dashboard (https://validators.stakesafe.net/) had shipped a stake-up/stake-down view and put 48.32% of delegated stake offline. The order of the evening matters, because the exploit was public knowledge before the network was stopped and the fix was not yet written. The Foundation said it had held the diagnosis back until the halt was in place (https://t.me/radix_dlt/1000779) , and separately that it was in contact with bridges, exchanges and security partners (https://t.me/radix_dlt/1000765) , reaching out to authorities, and might be limited in what it could say next. No resumption time was given that night, or for the ten days after it. The Council's notice put it plainly: the network's inoperative status "does not have a predictable comeback time as of yet". 16:02:20 – 16:57:41 The twenty-six transactions 17:17 First public report in the main Telegram group 21:17:30 Halt announced by the node-runner community 21:19:48.939 Last round on the ledger — epoch 339,897, round 4, state version 557,840,627 21:54:11 Radix Accountability Council notice: execution-layer issue, no comeback time 22:02:14 Cause stated publicly as the Radix Engine, any token or NFT in scope The outage The network did not come back overnight. Re-read at 03:09 UTC on 1 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the identical ledger it returned at the halt — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — which puts Radix mainnet close to six hours without a committed transaction. The Gateway itself is answering normally; network-configuration returns 200. It simply has nothing new to report, which is the distinction between an outage of the infrastructure and an outage of the ledger underneath it. The fix is not public. babylon-node (https://github.com/radixdlt/babylon-node/releases) , the node implementation every validator runs, has published nothing since v1.3.0.5 on 1 June 2026, and the default branch of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) , which carries the Engine itself, last moved on 27 March 2026. No post has appeared on the Foundation's blog (https://www.radixdlt.com/blog) , and the DAO's notice feed (https://radixdao.org/notices.json) carries nothing after 29 August. Six hours in, the only public account of the path forward is a Telegram message: Timan (https://t.me/radix_dlt/1000805) — the DeFiPlaza contributor and Astrolescent (/ecosystem/astrolescent) founder the Foundation appointed Interim Hyperscale Lead (https://www.radixdlt.com/blog/continuing-the-vision-timan-appointed-interim-hyperscale-lead) on 10 November 2025 — wrote at 22:14 UTC that he had been "in emergency mode with a few others for the past 6 hours", that the group was "talking to (former) core node devs", and that "we'll get back online". A restart therefore depends on people who no longer work on the codebase, which is a consequence of the Foundation having moved to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) and is the first operational cost of that decision to be visible from outside. Two questions were raised in the main group and answered there. Rolling the ledger back to before 16:02 was proposed by a validator (https://t.me/radix_dlt/1000729) at 20:12 UTC and refused within eight minutes on a point of arithmetic rather than of policy: the wrapped tokens were burned on Radix and the assets backing them released on Ethereum, so as one reply put it, "roll back not possible. it's already on ethereum" (https://t.me/radix_dlt/1000737) . Restoring the Radix balances would restore the claims without restoring what backs them. And the exploit's payload drew a forensic note from 0xOmarA (https://github.com/0xOmarA) — the fifth-largest contributor to radixdlt-scrypto with 1,318 commits, and the author of most of the Radix Engine Toolkit (https://github.com/radixdlt/radix-engine-toolkit) — who observed at 00:54 UTC that the attacker's WebAssembly carries no build-host string and no panic paths (https://t.me/radix_dlt/1000874) , the two artefacts Rust compilation leaves behind by default, and read that as code hand-written in WAT rather than compiled. That is an inference about method, not identity, and nothing in the ledger names anyone. The clearest measure of how the halt was read from inside the ecosystem came from Hyperscale. At 18:55 UTC, before the cause was public and before the network stopped, flightofthefox, who leads the Rust Hyperscale (/contents/tech/research/hyperscale-rs) effort, told his own channel he had begun liquidating all exposure to the Radix blockchain (https://t.me/hyperscale_rs/11265) , saying he could not risk Hyperscale's runway "to this many unknowns" and that he was stating it publicly only because of the circumstances. The two Hyperscale efforts are separate — the Foundation’s programme, which Timan leads, and the independent Rust reimplementation, which flightofthefox leads — and on the night of 31 August the people running them took opposite positions: one coordinating the restart, the other selling out of the asset it would restart. What the halt does off the chain Re-read at 07:02:30 UTC on 1 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) still returns the ledger it returned at the halt — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — nine hours and forty-three minutes after the last committed round. Four minutes later a read of /state/entity/details for XRD itself answered HTTP 500, and the error names the threshold: current_sync_delay_seconds 35,084 against max_allowed_sync_delay_seconds 720. The Gateway refuses to serve state it believes is more than twelve minutes stale, and it is nine hours and forty-four minutes behind, so every application that asks it a question about the present gets an error rather than an old answer. That is a deliberate design choice showing its value on the one day it matters. The exchanges The clearest external measure is at the venues, where the halt has been translated into a switch. Read at 07:09 UTC on 1 September from each exchange's own public API, native XRD cannot move on or off the chain at the three live venues that answer without a key: Venue Endpoint read Native XRD chain Gate.io spot/currencies/XRD (https://api.gateio.ws/api/v4/spot/currencies/XRD) deposit_disabled: true, withdraw_disabled: true KuCoin v3/currencies/XRD (https://api.kucoin.com/api/v3/currencies/XRD) isDepositEnabled: false, isWithdrawEnabled: false CoinEx deposit-withdraw-config (https://api.coinex.com/v2/assets/deposit-withdraw-config?ccy=XRD) deposit_enabled: false, withdraw_enabled: false The markets themselves stay open. Gate.io reports trade_disabled: false at the currency level and its XRD/USDT ticker (https://api.gateio.ws/api/v4/spot/tickers?currency_pair=XRD_USDT) was quoting 0.0006697 USDT on 98,929,511 XRD of 24-hour volume, down 17.3% over the day; KuCoin's XRD-USDT book was live at 0.000666. So XRD keeps a price, and a falling one, at venues from which it cannot be withdrawn to a wallet or deposited from one. What a holder can still do is sell the balance an exchange already custodies; what nobody can do is move the token itself, because the ledger that records the move has stopped. CoinEx makes the shape explicit in one field, leaving inter_transfer_enabled: true while both external legs are off: transfers inside the exchange, nothing across its edge. One row is worth reading carefully. Gate.io lists XRD on two chains, and the second is eXRD (https://etherscan.io/token/0x6468e79a80c0eab0f9a2b574c8d5bc374af59414) , the ERC-20 that carried Radix on Ethereum before the Babylon network existed. Its withdrawals read withdraw_disabled: false while the native chain's are off — the predecessor still moves, because it settles on a chain that has not stopped. No exchange has published a dated notice that this page can cite tying any of these switches to the halt; the values above are the exchanges' own APIs, recorded with the hour they were read. The applications On Radix itself the outage divides applications by where their content comes from rather than by who runs them. Front ends built as static bundles keep serving: Ociswap (/ecosystem/ociswap) , Astrolescent (/ecosystem/astrolescent) , Weft (/ecosystem/weft-finance) , RSwap (/ecosystem/rswap) , Surge, RadQuest and the Radix Dashboard (https://dashboard.radixdlt.com) all answered 200 on the same pass. Pages that have to resolve current state do not: Astrolescent's per-token page returned HTTP 500 through its own error boundary, and stats.defiplaza.net (https://stats.defiplaza.net) returned a bare Application Error. In between sit the cached read APIs, which answer normally and answer with the pre-halt ledger — Ociswap's token endpoint (https://api.ociswap.com/tokens) and Astrolescent's price feed (https://api.astrolescent.com/prices) both served full payloads. Neither payload says how old the ledger under it is, so a reader cannot tell from either that nothing has settled since 21:19 the previous evening. The Gateway, which does carry that information, is the only one of the three that declines to answer. The fix, and the restart Radix mainnet was down for 254 hours, 15 minutes and 40 seconds, and for most of them the only public account of the repair was a Telegram channel. What follows is the summary. The day-by-day record, with the ledger and repository readings each statement was checked against at the hour it was made, is on a separate page (/contents/history/hyperlane-asset-drain-2026-timeline) . The four steps At 12:16 UTC on 1 September the Radix Accountability Council (/ecosystem/radix-accountability-council) published the shape of the repair, and it did not change: code fixes to the Radix Engine; updates to the node software carrying a protocol upgrade; a coordinated deployment of those across nodes; and a coordinated return to liveness. It attached no dates, and none of the four acquired one until the third. The Foundation's announcement channel spoke twice in the whole outage, on 31 August and at 08:58 UTC on 2 September, and the second post pointed readers to the council for anything further. Its blog carried nothing at all. The first two steps were written by one contributor and were readable in public before anyone said so. The last two needed the few dozen node operators who had agreed the halt among themselves, and they are what the ten days were spent on. Eagle Ray: the Engine half The fix was written on the night of the drain. Pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) against radixdlt-scrypto was opened at 12:26 UTC on 2 September by 0xOmarA, the contributor whose forensic notes this page records from the first night, and its earliest commit is dated 22:41 UTC on 31 August – one hour and twenty-two minutes after the last round. The commit that adds the receiver check is dated 00:12 UTC on 1 September, hours before the first official update said anything in public. Its content is a flash protocol update named Eagle Ray (/contents/tech/releases/protocol-updates) , which advances the system logic from SystemVersion::V4 to V5, and V5 turns on a single check. Before an invocation runs, the system asks whether the calling frame can actually see the node whose method it is calling – direct methods, the type used for recall and other direct vault access, requiring direct visibility of the receiver – and rejects the call otherwise with a new SystemError::InvalidInvokeAccess. That is the handle nobody tried, given a lock. The test it rewrites is test_recall_on_internal_vault, which used to fail obscurely inside the kernel's frame construction and now fails cleanly at the system layer. It then sat unreviewed for five days. A seventh commit landed at 16:50 UTC on 7 September and the branch merged forty-three minutes later, at 17:33:31; ninety seconds after that Scrypto v1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) was published, the first Scrypto release since January 2026, with the repository's licence text as its release notes and no description of the flaw, the fix or the update. The merge touches 587 files, but 538 of those are transaction-scenario receipts regenerated under the new protocol version; the engine change is 80 lines, plus 43 in the system callback that runs the check. The node half, and the epoch it named Pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) against babylon-node (/contents/tech/core-protocols/babylon-node) , the software every validator runs, opened at 06:00 UTC on 8 September from the same author with no description, and it carried the first public answer to what a restart would look like. EAGLE_RAY_ENACTMENT_EPOCH is set to 339,898 with the trigger EnactAtStartOfEpochUnconditionally, which makes it the only protocol update in Radix's mainnet history that does not wait for the validator set to signal readiness. Anemone, Bottlenose and Cuttlefish each required validators holding 75% of stake to signal over days or weeks; this one enacts on an epoch number alone. The same pull request added a subsystem the node did not have, a user transaction moratorium: a range of epochs in which consensus continues and user transactions are refused. Mainnet got exactly one range, epoch 339,897 inclusive to 339,898 exclusive, commented for the incident. Three places enforce it – the mempool, the consensus pacemaker's vote, and a verifier on proposals arriving from other nodes – so a node that skipped the update could still propose a user transaction and the rest would decline to vote for it. It merged at 15:28 UTC on 8 September, with no reviews and no comments, after being force-pushed and retargeted from develop, whose tip had not moved since March 2025, onto main, the line the releases actually come from. A release candidate followed seven minutes later. The final release, v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) at 03:59 UTC on 10 September, resolves to the same commit as that candidate: byte for byte identical, with the pre-release flag as the only difference. The flag is not cosmetic. GitHub reports as latest the newest release that is neither a draft nor a pre-release, so from 8 to 10 September the answer was v1.3.0.5-test.1 – a rebuild of the exact version mainnet halted on – and that is what the babylonnode installer fetched. An operator running a standard install on 10 September got the fix. The day before, they got the flaw. Deployment, and then liveness The update was rehearsed before it was run. The council reported at 18:43 UTC on 9 September that Stokenet, the public test network, had taken the new software and protocol end to end, and Stokenet's own ledger corroborates it in the way that matters to someone waiting on mainnet: sampled hourly it never dropped a beat, committing exactly twelve epochs in each of the twenty-eight hours around the deployment. That is what a protocol update is meant to look like from outside, which is also why an unbroken ledger is not by itself proof that one enacted. Operators were told to wait three times: on 7 September because a library release is not a node build, on 8 September because a candidate is not a release, and again at 09:13 UTC on 10 September when a final build existed and the coordination did not. The instruction changed at 16:15 UTC that day – upgrade now, from official sources, and leave a healthy node online – and nothing published after it named a time. That was deliberate. Asked on the morning of 11 September whether an announcement would precede the fork, Daffy answered that there would be none, because the moment could not be predicted, and gave the order plainly as secure liveness first, announce after. At 07:12 UTC on 11 September StakeSafe (/ecosystem/stakesafe) 's adoption dashboard (https://validators.stakesafe.net) read 31.22% of active validator-set stake on v1.4.0.0, and the twelve largest validators all read a v1.3 version and all read offline. That was not a stalled upgrade. Faraz said so in the main Radix group at 10:11 UTC: the largest nodes were upgraded and waiting to boot together, so that the network would come back well clear of two thirds rather than marginally above it. The dashboard reports the version a node last advertised, so an offline validator shows whatever it was running when it stopped. 11 September Radix mainnet committed a round at 11:35:28.96 UTC on 11 September 2026, its first in ten days, at epoch 339,897 round 5. That epoch then ran to round 106 under the moratorium and every ledger entry in the window is a system transaction, which is the moratorium working: consensus certifying rounds and refusing user payloads. At the start of epoch 339,898 the fork enacted and the moratorium lifted together, and at 11:39:25.129 UTC round 2 of that epoch committed 17 user transactions at once, five of them failing, as a queue ten days old cleared. Just under four minutes of empty blocks separate the network coming back from the network being usable. Read at 13:10 UTC, 80.85% of a 4,873,528,908 XRD active set was on the release. The first published test of the fix is on the ledger, and it is the exploit. At 12:35:05.915 UTC a transaction (https://dashboard.radixscan.io/transaction/txid_rdx1n23szuw226jqjhqt2v8zeguwh545xlyarmwfg0g3dgcsfy4dnceqf4a269/summary) published a package to mainnet whose blueprint is named VaultDrainer, with methods drain and drain_victim_pays. It committed successfully for a fee of 14.14 XRD, which is a package publish succeeding rather than a drain succeeding. The operator who submitted it said so in the developer group at 13:03 UTC: it is the drainer that had been run against the unpatched network throughout testing, put on mainnet to verify the fix is operative against live vaults. The drain itself was refused. The transaction (https://dashboard.radixscan.io/transaction/txid_rdx15cnw85zja5jdm5l0uus2vul8cp49u06yvjxvu3eyk4judtcrwgdsytta86/summary) that calls the blueprint is permanently rejected on mainnet, and the reason the Gateway gives for it is SystemError::InvalidInvokeAccess, the check Eagle Ray turned on that morning, firing on a live attempt. It failed before repaying its fee loan, so it was rejected rather than committed as a failure and left no entry on the ledger. The operator reported the result in the developer group at 14:12 UTC. The council announced the restart at 14:37 UTC, three hours after it happened, in a message (https://t.me/RadixAccountabilityCouncil/1026) that credits the node runners and says the restart arrived earlier than it had expected. It adds that the council had itself attempted the exploit against mainnet, and that every attempt failed. It asks for a few days before it publishes a report, says the Foundation is working with the exchanges and market makers but that when deposits and withdrawals return is each exchange's own decision, and says the Governance Framework ratification stays in its discussion phase, which the incident had pushed aside. The Foundation's own blog still carries nothing about any of it, and the documentation page for Eagle Ray (https://docs.radixdlt.com/docs/eagle-ray) still answered HTTP 404 at 15:24 UTC. Where the assets went Bridging out of Radix burns the wrapped token here and releases the real asset on the destination chain, so the second half of this incident is on Ethereum and is still readable there. The recipient named in the warp-route calls is 0x626d…7cD2 (https://eth.blockscout.com/address/0x626d7Be5c2F2b6E9bAa542e25b6313Ac91d47cD2) , an ordinary externally-owned account. Its inbound transfers come from three Hyperlane collateral contracts, one per asset, and they line up with the Radix side to the last digit: the three probe amounts this page records — 0.00084948 hWBTC at 16:17, 482.994855 hUSDT at 16:21, 384.810629 hUSDC at 16:22 — arrive as WBTC, USDT and USDC within the same minute of each other. The USDT total received, 72,420.384476, is exactly the hUSDT burned on Radix, and the WBTC received sums to the 6.348 hWBTC burned. The USDC does not match, and the gap is informative rather than mysterious: 15,929.25 USDC reached this address against 458,914.89 hUSDC burned on Radix, so the largest sweep of the afternoon was directed at a different recipient. From 16:44 the balances were forwarded to a contract at 0x225a…DC17 (https://eth.blockscout.com/address/0x225a38bc71102999Dd13478BFaBD7c4d53f2DC17) and converted; read at 23:15 UTC on 31 August the account holds 330.207 ETH and 53.93 USDT. Radix cannot reverse any of that — the ledger it would have to do it on is not the one the assets are sitting on, and it is halted besides. What is unresolved The cause is no longer one of them, and since 11 September neither is the restart. Three questions stand, and the ledger can be asked about them again. The first is whether the fix holds, and what the twelve days cost. The Engine half was published on 2 September as pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , which introduces the Eagle Ray (/contents/tech/releases/protocol-updates) protocol update and the receiver check it exists to carry; it merged on 7 September and released the same evening as Scrypto v1.4.0. The node half was published on 8 September as pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) , which sets the enactment epoch at 339,898 and refuses user transactions for the epoch before it, and it shipped final as babylon-node v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) at 03:59 UTC on 10 September. Both halves are now running: the fork enacted at 11:39 UTC on 11 September with 80.85% of active stake on the release, and the first exploit aimed at them was rejected the same afternoon. What has not been published is any account of the flaw. Announcing the restart, the council asked for a few days to prepare one. Nor has the validator set finished arriving, with 19.15% of active stake still on a version that predates the fork. The second is recovery. The assets left the network within the hour, and what is left of them sits on Ethereum in an account nobody on Radix can reach. Containment moved to the receiving chain and to the exchanges, which is where it stays. The third is who responds. The incident landed in the week the Radix DAO (https://radixdao.org/) was taking over from the Foundation, with the Governance Framework in its ratification discussion period and no permanent council elected. Radix governance (/contents/tech/core-concepts/radix-governance) describes the bodies that exist and what each of them can decide. What actually stopped the network on 31 August was none of them: it was the node runners, acting together, using the only lever a validator set has. External links - Collecting account on the Radix Dashboard (https://dashboard.radixdlt.com/account/account_rdx168lx67kgw2fsd9awudqhmwlhc9gwjw79d84mrx5cayul7gg3973f29) – the twenty-six transactions, newest first - The 16:33 hUSDC transaction on RadixScan (https://dashboard.radixscan.io/transaction/txid_rdx19lzunu3relu436dm9r4mnmvyjx3yzr2723gk7d7kv0tce8g9h4kqd60u5v/summary) – manifest, balance changes and affected entities - hUSDC resource (https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) – authorities and current supply - Hyperlane (https://hyperlane.xyz) – the interchain messaging protocol whose warp routes issue the six assets - verify_boot_ref_value in radixdlt-scrypto v1.3.1 (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/system/system_callback.rs#L1147) – the reference check the drain went through - Radix Accountability Council notice, 21:54 UTC 31 August (https://t.me/RadixAccountabilityCouncil/925) – the halt and the execution-layer issue - The receiving account on Ethereum (https://eth.blockscout.com/address/0x626d7Be5c2F2b6E9bAa542e25b6313Ac91d47cD2) – inbound warp-route transfers and what remains - Day-by-day record of the halt (/contents/history/hyperlane-asset-drain-2026-timeline) – every reading this page summarises, in the order it was taken ## DELAY URL: https://radix.wiki/ecosystem/delay Updated: 2026-09-12 Summary: DELAY (ledger name “DELAY - THE token”) is a satirical community meme coin on Radix , its name a wink at the community’s long wait for the network to… DELAY Type Satirical community meme coin Symbol DELAY Ledger name “DELAY - THE token” Status 🔴 Abandoned – market effectively dead (read 5 September 2026) Network Radix (/contents/tech/core-protocols/radix-engine) mainnet Supply ≈ 661,000,000 DELAY and falling – minting denied, token burnable Token authorities Minting, freezing & recall denied; anyone may burn Notable holder Ecosystem Asset Fund (/contents/history/radix-ecosystem-funding) (≈ 12.5M, held unsold) Token DELAY on Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4dsaa07eaytq0asfe774maqzhrakfjkpxyng2ud4j6y2tdm5l7a76) Overview DELAY (ledger name “DELAY - THE token”) is a satirical community meme coin (/ecosystem) on Radix (/contents/tech/core-protocols/radix-engine) , its name a wink at the community’s long wait for the network to ship its scalability roadmap – a companion in spirit to DELIVER (/ecosystem/deliver) . Its on-ledger description reads: “$DELAY: Community-owned, highly burnable, and free from third-party payouts — no unnecessary sell pressure here. Selling usually comes from members chasing profits… only to wish they’d DELAYed that decision a bit longer.” On-chain, minting is permanently disabled while burning is open to anyone, so the DELAY token (https://dashboard.radixdlt.com/resource/resource_rdx1t4dsaa07eaytq0asfe774maqzhrakfjkpxyng2ud4j6y2tdm5l7a76) ’s total supply – around 661 million – declines over time rather than growing. Ecosystem Asset Fund holding DELAY is most widely known as a holding of the Radix Foundation’s Ecosystem Asset Fund (/contents/history/radix-ecosystem-funding) , a $25,000-per-month treasury program that bought and held the highest-market-cap ecosystem tokens. Because the fund allocated by market capitalisation, its purchases swept in speculative meme coins: between December 2024 and May 2025 it repeatedly bought DELAY, accumulating roughly 12.5 million tokens for about 143,000 XRD. Those tokens remain in the fund’s public wallet (https://dashboard.radixdlt.com/account/account_rdx1297vs7up584rkwensy0jwzxq6g0xua67ca9trxdyr45cjnmzdak5x3) , unsold. Abandonment DELAY’s market ranking fell away after the fund stopped buying, and the token now trades at close to nothing. Read at the Ociswap (https://ociswap.com/delay) API on 5 September 2026, its pool held 281,840,197 DELAY against 344,029 XRD (/contents/tech/core-protocols/xrd-token) , about $226 in all, on seven-day volume of $2.90 and a price of $0.00000044. It ranked 66th by market capitalisation on that venue. The same record dates the token’s listing there to 17 December 2024, the month the Ecosystem Asset Fund (/contents/history/radix-ecosystem-funding) began buying it. The only project link the token carries on-ledger is rly.fun (https://rly.fun) , the meme coin launchpad it was minted through, which answered on the same read. A launchpad is not a site the project controls, so it settles nothing about who is still behind DELAY. The same read returns one channel that is the token’s own: the resource’s social_urls metadata names x.com/delayonradix (https://x.com/delayonradix) . That field records what was written to the ledger, not whether anyone still posts there, and the ledger cannot be asked the second question. The web can. Requested at 19:12 UTC on 6 September 2026, x.com/delayonradix (https://x.com/delayonradix) answered HTTP 404 on X’s “User Profile Not Found” page, while x.com/radixdlt answered 200 to the same request in the same minute — so the profile is genuinely absent rather than a bot wall. X’s own body says such an account “may be private, deleted, or only available on the app”, which is as far as this goes: the one channel the ledger names for DELAY cannot be read on the web, and the ledger has no way to update the pointer. The supply figure above was read at the Radix Gateway on 18 July 2026, and it can be re-read during the halt after all. A Gateway read pinned to a ledger state (/contents/tech/core-protocols/radix-gateway-api#pinned-reads) skips the guard that refuses ordinary reads, so at 07:09:58 UTC on 6 September 2026 — with the network stopped for a hundred and twenty-nine hours (/contents/history/hyperlane-asset-drain-2026) — /state/entity/details returned the resource at state version 557,840,622 with a total supply of 661,195,247.825631037429292673 DELAY and the ledger name “DELAY - THE token”, confirming both figures this page carries. That is the supply as it stood at 21:19:06 UTC on 31 August 2026. Nothing could burn while the ledger was stopped; it restarted on 11 September 2026 (/contents/history/hyperlane-asset-drain-2026) , so burning is open to anyone again and the figure is no longer fixed. The token continues to exist on-ledger and is community-owned. The episode is cited as an illustration of the abandonment risk in allocating public money to high-volatility meme coins by market capitalisation alone; see the Ecosystem Asset Fund (/contents/history/radix-ecosystem-funding) page for the fuller account. External Links - DELAY – Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4dsaa07eaytq0asfe774maqzhrakfjkpxyng2ud4j6y2tdm5l7a76) - Ecosystem Asset Fund – RADIX Wiki (/contents/history/radix-ecosystem-funding) - Ecosystem Asset Fund wallet (holds DELAY) – Radix Dashboard (https://dashboard.radixdlt.com/account/account_rdx1297vs7up584rkwensy0jwzxq6g0xua67ca9trxdyr45cjnmzdak5x3) ## DeFiPlaza URL: https://radix.wiki/ecosystem/defiplaza Updated: 2026-09-12 Summary: DeFiPlaza is an open-source, decentralized exchange operating on both Ethereum and Radix . Its Radix deployment is a next-generation automated market… Type Multi-token AMM DEX Networks Ethereum & Radix Token DFP2 Launched 2021 (Ethereum) · 2023 (Radix) GitHub OmegaSyndicate (https://github.com/OmegaSyndicate) X @defiplaza (https://x.com/defiplaza) DeFiPlaza is an open-source, decentralized exchange operating on both Ethereum (https://en.wikipedia.org/wiki/Ethereum) and Radix (/contents/tech/core-protocols/radix-engine) . Its Radix deployment (https://defiplaza.net) is a next-generation automated market maker (https://en.wikipedia.org/wiki/Automated_market_maker) built to reduce impermanent loss (https://en.wikipedia.org/wiki/Automated_market_maker) and deliver higher, more consistent returns for liquidity providers, prioritising sustainable LP income over raw trade volume. History DeFiPlaza launched on Ethereum in October 2021, where it became one of the network's more capital-efficient DEXs with up to 124 trading pairs. Following a unanimous community vote, the project expanded to the Radix L1 after the Babylon (/contents/tech/releases/radix-mainnet-babylon) upgrade, bridging its DFP2 token to Radix and launching its Radix DEX in October 2023. The team cited Radix's asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) design and more favourable transaction-cost dynamics as reasons for the move to a more secure environment for complex DeFi. Core Features - Multi-token trading: direct swaps between many token pairs from a shared pool, reducing intermediary hops. - Single-sided liquidity: LPs gain exposure only to the token they provide plus DFP2, the platform's internal base token. - Concentrated liquidity & dynamic fees: liquidity concentration and trading fees adjust to market conditions to improve capital efficiency and sustainability. - Annualised LP Returns (ALR): each pair surfaces an ALR metric so liquidity providers can compare pool performance directly. DFP2 Token DFP2 is DeFiPlaza's operational base token, paired against listed assets (for example ASTRL (/ecosystem/astrolescent) /DFP2, XRD/DFP2, and WEFT/DFP2) and used to route multi-token swaps. It bridges between the Ethereum and Radix deployments, giving the two-chain platform a shared unit of account. Status & Metrics DeFiPlaza’s Radix deployment was live and operational (https://defiplaza.net) when it was last measured against a moving ledger. Its public pairs endpoint (https://defiplaza.net/api/pairs) listed 156 pairs on 27 August 2026 holding $183,419 in total value locked. That liquidity is concentrated: 50 of those pairs held more than $100 and 17 held more than $1,000. DefiLlama (https://api.llama.fi/protocol/defiplaza) measured the same deployment at $180,367 on the same morning. The two deployments are no longer peers. Ethereum produced almost all of DeFiPlaza's lifetime trading, roughly $846 million of the $855.5 million the protocol has settled across both chains, against about $9.5 million on Radix. It now produces almost none of it. In the thirty days to 26 August 2026 the Ethereum DEX traded $801 and collected $12 in fees, while the Radix DEX traded $119,685 and collected $1,095 ( volume (https://api.llama.fi/summary/dexs/defiplaza) and fee (https://api.llama.fi/summary/fees/defiplaza) series, per-chain breakdown). Radix holds 95.9% of the protocol's total value locked. The Ethereum swap app (https://app.defiplaza.net/swap) is still live and still quotes its 0.1% fee. The trading moved. Reported value during the network halt Radix mainnet stopped committing transactions on 31 August 2026 at 21:19:48 UTC, at state version 557,840,627, and did not restart until 11 September 2026 (/contents/history/hyperlane-asset-drain-2026) . Nothing in DeFiPlaza’s Radix pools has moved in that time. The dollar figures published for those pools have, and by 9 September the two sources this page cites disagreed about them by 74%. Read at 03:05 UTC on 9 September 2026, DeFiPlaza’s own pairs endpoint (https://defiplaza.net/api/pairs) still listed 156 pairs, now holding $110,466, with 41 pairs above $100 and 14 above $1,000, and a volume of zero on every one of them. The token balances behind that figure are the ones frozen on 31 August. The endpoint reports 7,530,679.117206777 $XRD in the base pool of its $XRD/DFP2 pair, and the Radix Gateway (https://mainnet.radixdlt.com/state/entity/details) , asked for that pool pinned to state version 557,840,622, returns 7,530,679.117206777387126939. The balances are the same, so the $72,953 the endpoint has shed since 27 August is a change in the price it marks them at and nothing else. DefiLlama (https://api.llama.fi/protocol/defiplaza) handles the same problem the opposite way and does not say so. Its record for DeFiPlaza reports a current Radix value of $191,915 and a current Ethereum value of $7,673, and both are the last points of series that end on 31 August 2026. The tracker stopped updating the whole protocol when the Radix ledger stopped, including the Ethereum deployment, which never stopped: DefiLlama’s records for Uniswap (https://api.llama.fi/protocol/uniswap) and Aave both carried points timestamped 01:1x UTC on 9 September. On 27 August the two sources were 1.7% apart on the same pools. They are 74% apart now, one publishing a nine-day-old number as current and the other re-marking frozen balances at a $XRD price that no longer has one value across exchanges (/contents/resources/how-to-buy-xrd) . DeFiPlaza’s analytics dashboard (https://stats.defiplaza.net/pools/radixplaza) came back on 9 September after a week of failing, having timed out on 2 September and returned HTTP 500 on 4 and 5 September. It answers in about a second and prints two different answers on one page: $110K of total value locked in its header, $0.000 of total value locked “Today” in the chart below it, and a pairs table with no rows. Team DeFiPlaza was created by three co-founders: Jazzer9F, the project's originator, an electrical engineer and long-standing Radix community member; UI_guy, responsible for front-end development; and djtrebel, who brought startup and community-engagement experience and is also associated with Astrolescent (/ecosystem/astrolescent) , a Radix DEX aggregator. External Links - Official exchange (Radix) – defiplaza.net (https://defiplaza.net) - Swap app (Ethereum) – app.defiplaza.net (https://app.defiplaza.net/swap) - Documentation – docs.defiplaza.net (https://docs.defiplaza.net) - Analytics – stats.defiplaza.net (https://stats.defiplaza.net/pools/radixplaza) - Radix bridge – bridge.defiplaza.net (https://bridge.defiplaza.net) - GitHub – OmegaSyndicate (https://github.com/OmegaSyndicate) - X – @defiplaza (https://x.com/defiplaza) ## EasyMoon URL: https://radix.wiki/ecosystem/easymoon Updated: 2026-09-12 Summary: EasyMoon is a cryptocurrency project that launched via 42 weekly airdrops to engaged followers. The project is built on the Radix network and has a to… EasyMoon Type Community airdrop token ($EMOON) on Radix (/contents/tech/releases/radix-mainnet-babylon) Status 🟠 Legacy (Olympia-era airdrop project) Token $EMOON – 42,000,000,000 minted, 41,975,881,332.04 in supply ( two resources carry the name (#two-resources-carry-this-name) ) Distribution 42 weekly airdrops to stakers, running until the Babylon (/contents/tech/releases/radix-mainnet-babylon) launch Trades on Ociswap (/ecosystem/ociswap) EasyMoon is a cryptocurrency project that launched via 42 weekly airdrops to engaged followers. The project is built on the Radix network and has a total supply of 42 billion $EMOON tokens. The tokens were distributed for free in a weekly giveaway that lasted for 42 weeks until the launch of Babylon (/contents/tech/releases/radix-mainnet-babylon) . Weekly Giveaway To participate in the giveaway, users had to install the Radix Desktop wallet and stake a minimum of 1000 $XRD. Wallets that did not meet this requirement were not eligible for the giveaway. Every Monday (UTC), participants had to send 1 $XRD to the specified airdrop address. Free tokens were sent out within the next day. Tokenomics EasyMoon has a total supply of 42,000,000,000 tokens. 60% of the tokens were distributed for free in the weekly giveaway. 15% of the tokens were used for marketing and giveaways, 15% went to liquidity pools like OCISWAP and other DEXes and exchanges, and 10% went go to the founders of the project for further development. $EMOON tokens can be purchased on Ociswap (/ecosystem/ociswap) . Criticisms EasyMoon has been criticized for relying on hype and FOMO to drive demand for the tokens. Others have questioned the sustainability of the project, as it relies heavily on the popularity of the Radix network. Additionally, the fact that the tokens are distributed for free has led to concerns about the fairness of the giveaway and the potential for manipulation. Despite these criticisms, EasyMoon remains a popular project among cryptocurrency enthusiasts, particularly those who believe in its potential for growth. Website (30 July 2026): easymoon.io has no DNS record at all. An unregistered domain can be bought by anyone – four defunct Radix projects' domains have already been re-registered as unrelated landing pages – so the link has been removed from this page's facts table. Two resources carry this name Anyone buying $EMOON has to choose between two tokens. The Radix ledger holds two distinct fungible resources both named EasyMoon, both giving easymoon.io as their info_url, and Ociswap (/ecosystem/ociswap) lists both. Read pinned at state version 557,840,622, a position recorded during the network halt of 31 August 2026 (/contents/history/hyperlane-asset-drain-2026) and five states short of the ledger’s own last pre-halt state, 557,840,627: Resource Symbol Minted Burned Supply Ociswap listing resource_rdx1t5y9qggzzsrxj05veq3uy2er3wtctp8hwqw0dvgaxkve2elpqk290u EMOON 42,000,000,000 24,118,667.96 41,975,881,332.04 emoon1 (https://api.ociswap.com/tokens/resource_rdx1t5y9qggzzsrxj05veq3uy2er3wtctp8hwqw0dvgaxkve2elpqk290u) , 12 January 2024 resource_rdx1t5jt96k2ywxq36qt6sdsjfsrq8nchgruhtzq35p8haxte8xwmw2c4r emoon 42,000,000,000 0 42,000,000,000 emoon (https://api.ociswap.com/tokens/resource_rdx1t5jt96k2ywxq36qt6sdsjfsrq8nchgruhtzq35p8haxte8xwmw2c4r) , 3 October 2023 Both were minted at exactly forty-two billion, which is the figure this page has always quoted, and the two have diverged since. The first is the resource this page identifies in its facts table. Its minter role is set to DenyAll and its burner role to AllowAll, so no more can be created and anyone holding the token can destroy their own: 24,118,667.96 have been burned that way. The second has DenyAll on minter and burner alike and no owner rule at all, so its forty-two billion is frozen exactly where it was issued and nothing about the resource can be changed again. The ledger records what each resource is, not which one the project intended people to hold, and nothing published by EasyMoon settles that: easymoon.io, named by both resources and by the icon each one points at, has had no DNS record since at least 30 July 2026, so neither icon renders and the info_url on both leads nowhere. A reader who wants the token this page describes should match the resource address rather than the symbol, which is not unique. ## $DAN URL: https://radix.wiki/ecosystem/dan Updated: 2026-09-12 Summary: $DAN is a cryptocurrency token created on the Radix blockchain . It was initially launched as a memecoin to pay homage to Dan Hughes, the creator of R… $DAN (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) is a cryptocurrency token created on the Radix blockchain (https://www.radixdlt.com/) . It was initially launched as a memecoin (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) to pay homage to Dan Hughes, the creator of Radix. Despite starting with zero utility (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) , $DAN quickly gained attention within the Radix ecosystem due to its record-breaking token launch. Overview The project has since evolved from its memecoin origins to become what it claims is the first true passive income project on the Radix network (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . $DAN's primary feature is a staking mechanism that allows token holders to earn $XRD (the native cryptocurrency of the Radix blockchain) as rewards. $DAN's stated mission (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) is twofold: to reward its token holders and to bring attention to the Radix blockchain. The project emphasizes transparency, community engagement, and a "stake and earn" model as its core principles. As of the information provided, $DAN has reported distributing 1 billion tokens (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) through airdrops and payouts to its community members, although the exact timeframe for these distributions is not specified in the source material. History Origin and Creation $DAN was created as a memecoin (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) on the Radix blockchain, with the initial concept centered around paying homage to Dan Hughes, the creator of Radix. The project's founders made no promises (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) beyond a fair launch, creating "bad-ass DAN memes," and implementing what they termed "kick-ass tokenomics." This approach aligns with the typical characteristics of memecoins, which often rely on community engagement and humor rather than technical utility at launch. Record-breaking Token Launch The launch of $DAN marked a significant milestone in the Radix ecosystem. According to the project's website, $DAN broke every token launch record on RADIX (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . Specifically, the project conducted a 24-hour Initial Coin Offering (ICO) (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) that raised over 1.3 million $XRD. This successful fundraising event also resulted in $DAN achieving the highest liquidity to market cap ratio on the Radix blockchain (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) at the time. Following the successful launch, the $DAN team, with the community's consent (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) , made a strategic decision to withdraw half of the project's liquidity. This capital was repurposed as an investment fund, intended to generate passive income for token holders. In a move towards transparency, the project claims that all investments, transactions, and cross-chain wallet addresses related to this fund are made available to token holders through their Discord server. As the project evolved, it transitioned from a pure memecoin to what it describes as the "FIRST true passive income project on $XRD" (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) ($XRD being the ticker for Radix's native token). This shift in focus towards providing tangible benefits to token holders marked a significant development in $DAN's history, setting it apart from its initial memecoin status. Features and Utility Staking Mechanism The primary feature of $DAN is its staking mechanism (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) , which allows token holders to earn rewards in $XRD, the native cryptocurrency of the Radix blockchain. The project emphasizes the simplicity of this process with their tagline "Stake, Earn, and Degen with $DAN" (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . According to the project's website, users can stake their $DAN tokens through a dedicated staking portal, though the exact launch date of this platform is not specified in the provided information. $XRD Rewards System $DAN implements a rewards system (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) where staked tokens generate $XRD returns for holders. The project states that these rewards are distributed on a quarterly basis (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . To be eligible for a payout, users must stake their tokens for a minimum period of 30 days (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) prior to a scheduled distribution. However, the overall minimum staking period is set at 3 months (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) , suggesting a mechanism to encourage longer-term holding. Investment Strategy A unique aspect of $DAN's utility is its investment strategy. The project claims to invest in passive income opportunities across multiple blockchain networks (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . According to their stated model, 80% of the investment profits are distributed to staked token holders (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) , while the remaining 20% is reinvested into the fund to potentially generate more returns for users. To maintain transparency, the project states that all transactions related to these investments are recorded and made available to token holders through their Discord server (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . This approach aims to provide a level of accountability and allow community members to track the performance of the investment fund. Additionally, the project mentions plans to integrate an automated trading bot called Kumodroid (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) , which would be offered through the $DAN portal. This feature is intended to provide users with advanced trading capabilities without requiring extensive trading knowledge, though details on its implementation and availability are not specified in the provided information. Tokenomics Token Distribution The $DAN project has implemented a token distribution strategy that includes airdrops and payouts to community members. According to the project's website, the total amount of $DAN distributed through airdrops and payouts to date is 1 billion tokens (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . However, the provided information does not specify the total supply of $DAN tokens or provide a detailed breakdown of the token allocation. The project emphasizes a community-centric approach (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) in its token distribution, with a focus on rewarding holders through various mechanisms. This includes the staking rewards system, where holders can earn $XRD by staking their $DAN tokens. Liquidity Management $DAN's approach to liquidity management involves several key strategies: - Initial Liquidity Provision: During its launch, $DAN claims to have achieved the highest liquidity to market cap ratio on the Radix blockchain (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . This suggests a significant portion of the funds raised during the initial coin offering (ICO) was allocated to provide liquidity for trading. - Strategic Liquidity Reallocation: After the launch, the project team, with community consent, withdrew half of the provided liquidity (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . This capital was repurposed to create an investment fund aimed at generating passive income for token holders. - Liquidity Locking: In a move to build trust and ensure long-term stability, $DAN claims to be the first project to lock its liquidity using RADLOCK (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) when the feature became available. The liquidity pool (LP) tokens are reportedly locked until April 20, 6900 - an extremely distant future date likely chosen for humorous effect. - Transparency Measures: The project states that all investments, transactions, and cross-chain wallet addresses related to the investment fund are made available to token holders (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) through their Discord server, promoting transparency in liquidity management. - Reinvestment Strategy: Of the profits generated from investments, 80% is reportedly distributed to staked token holders, while 20% is reinvested into the fund (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . This approach aims to balance immediate rewards for holders with sustainable growth of the liquidity pool. Team The $DAN project is led by a team of individuals described as "dedicated crypto enthusiasts and seasoned investors" (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . According to the project's website, the team works to ensure that their decisions benefit both the $DAN community and the broader Radix community. The key team members mentioned are: Key Team Members - The machinist (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) : Described as the Founder and an award-winning web3 podcast producer. No additional details about their background or specific role in the project are provided in the source material. - Yatz (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) : Listed as a $DAN Founder and "Degen Extraordinaire". The term "Degen" likely refers to "DeFi Degen", a colloquial term in the cryptocurrency space for someone deeply involved in decentralized finance projects, often taking high risks. - Mcgillz (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) : Serves as the Community Manager. No further details about their background or specific responsibilities are provided in the source material. - MedRare (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) : Described as a Moderator and Founder of Elite Ballerz NFT. This suggests involvement in other blockchain projects, particularly in the Non-Fungible Token (NFT) space, though no additional information is provided about this project or MedRare's specific role in $DAN. Roles and Responsibilities While specific roles and responsibilities for each team member are not detailed in the provided information, the team's overall mission is described as working hard to ensure that every decision benefits not only the $DAN community but the Radix community as a whole (https://web.archive.org/web/20260514014957/https://www.danxrd.xyz/) . This suggests a collaborative approach to project management and a focus on the broader ecosystem in which $DAN operates. The presence of a dedicated Community Manager (Mcgillz) and a Moderator (MedRare) indicates a focus on community engagement and management, which aligns with the project's emphasis on community-centric approaches. It's important to note that while these team members are listed on the project's website, the provided information does not include detailed backgrounds, professional histories, or specific contributions of each member to the project. As with any cryptocurrency project, potential investors or community members would be advised to seek additional verification and up-to-date information about the team's credentials and ongoing involvement in the project. What the ledger says Everything above is drawn from an archived copy of the project’s own website and describes what $DAN said about itself. The token is a separate matter, and it is still on the ledger. Read at state version 557,840,622 – a pinned read (/contents/tech/core-protocols/radix-gateway-api#pinned-reads) taken while the network was halted (/contents/history/hyperlane-asset-drain-2026) , so these are the figures as they stood on 31 August 2026 rather than a live reading; mainnet restarted on 11 September and the ledger’s own last pre-halt state was 557,840,627, five states further on – the resource resource_rdx1tk4y4ct50fzgyjygm7j3y6r3cw5rgsatyfnwdz64yp5t388v0atw8w holds a total supply of 100,000,000,000 $DAN at 18 decimal places, all of it minted and none of it burned. Three of its authorities are closed. The minter, burner and freezer roles are each set to DenyAll, which means no further $DAN can be created, no existing $DAN can be destroyed, and no holder’s balance can be frozen. The supply is fixed at what was minted, whatever happens to the people who minted it. Ownership of the resource sits behind a badge, resource_rdx1t4atxnakqgccg34ql22r2hpmnyfrjy9lqa57n8flxxj7nerr2yym6p, so the metadata can still be changed by whoever holds it. That metadata is where the project’s absence shows. The info_url the resource publishes, the pointer a wallet or explorer follows to find out what a token is, reads https://danxrd.xyz, and that domain has no DNS record of any kind: no address record and no name servers, re-checked on 7 September 2026 and unchanged since the reading of 30 July. An unregistered domain can be bought by anyone, and four defunct Radix projects’ domains have already been re-registered as unrelated landing pages, so the link is not reproduced in this page’s facts table. The token points at a website that no longer exists, and only the badge holder can change that. What is left of the project is the chat. The Telegram group @dancoinxrd (https://t.me/dancoinxrd) answers with 350 members. A search of X for posts from the handle the resource pages carry, @dancoinxrd, returns none. The status recorded here is dormant rather than closed on that basis: the token exists, its supply cannot be altered, its holders keep it, and nobody is publishing anything about it. ## Radix Protocol Updates URL: https://radix.wiki/contents/tech/releases/protocol-updates Updated: 2026-09-12 Summary: 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… Term Protocol update – a named, network-wide rule change, called a "hard fork" on other networks ( Radix Docs (https://docs.radixdlt.com/docs/protocol-updates) ) Cadence Approximately two to three per year Naming Alphabetical sea-creature scheme, following the initial babylon-genesis update Enactment Validator readiness signalling – 75% of active-set stake, sustained for a required number of consecutive epochs, inside a fixed epoch window. Eagle Ray is the first mainnet exception: it enacted unconditionally at epoch 339,898 Enacted so far Genesis → Anemone → Bottlenose → Cuttlefish → Eagle Ray Latest enacted Eagle Ray, 11 September 2026, epoch 339,898 Latest node release v1.4.0.0 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , 10 September 2026, the final Eagle Ray release; it tags the same commit as the v1.4.0.0-RC1 candidate of 8 September and carries no pre-release flag, so the repository’s latest release (https://api.github.com/repos/radixdlt/babylon-node/releases/latest) now resolves to it Released, not enacted None. Dugong carries no trigger on any network Primary sources Protocol Updates (https://docs.radixdlt.com/docs/protocol-updates) · Node Protocol Updates (https://docs.radixdlt.com/docs/node-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 (https://docs.radixdlt.com/docs/protocol-updates) 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 (/contents/tech/releases/radix-mainnet-babylon) migration from Olympia (/contents/tech/releases/radix-mainnet-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 (/contents/tech/core-protocols/scrypto-programming-language) 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 (https://docs.radixdlt.com/docs/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 (/contents/tech/core-concepts/components) with a readiness signal – a unique string derived from the protocol version and its trigger condition, not merely the update’s name. Each validator (/contents/tech/core-concepts/consensus-manager) 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 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. 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 (https://github.com/radixdlt/babylon-node/blob/main/core-rust/state-manager/src/protocol/protocol_configs/mainnet_protocol_config.rs) 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 (https://github.com/radixdlt/babylon-node/blob/main/core-rust/state-manager/src/protocol/protocol_configs/stokenet_protocol_config.rs) 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 Update Node Scrypto Enacted (mainnet) Epoch Voting requirement Genesis (babylon) v1.0.0 – 28 September 2023 32717 Unconditional Anemone v1.1.0 1.1.0 7 February 2024 70575 75% stake for ~4 days Bottlenose v1.2.0 1.2.0 7 June 2024 105353 75% stake for ~2 weeks Cuttlefish v1.3.0 1.3.0 18 December 2024 160923 75% stake for ~2 weeks The enactment windows configured for mainnet were [70019; 74051) for Anemone, [104291; 112355) for Bottlenose and [158682; 161562) for Cuttlefish ( Node Protocol Updates (https://docs.radixdlt.com/docs/node-protocol-updates) ). Other networks, including Stokenet (/contents/tech/releases/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 (https://docs.radixdlt.com/docs/anemone) ): - 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 (/contents/tech/core-concepts/blueprints-and-packages) to improve precision and their behaviour with resources (/contents/tech/core-concepts/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 (https://docs.radixdlt.com/docs/bottlenose) ): - The new Account Locker (/contents/tech/core-concepts/locker-blueprint) 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 (/contents/tech/core-concepts/buckets-proofs-and-vaults) on the Access Controller (/contents/tech/core-concepts/access-controller) , removing the need for third-party fee locking during a recovery. - Various improvements to the Account and Transaction Processor (/contents/tech/core-concepts/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 (#eagle-ray-enacted) 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 (https://docs.radixdlt.com/docs/cuttlefish) ). What it changed: - The Transaction V2 format. A transaction becomes an intent tree – a root transaction intent plus child subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) – 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 (/ecosystem/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: Library Version at Cuttlefish Engine Rust crates (scrypto, scrypto-test, radix-transactions) 1.3.0 @radixdlt/babylon-gateway-api-sdk 1.9.2 Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) 2.2.0 Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) (C, Kotlin, Swift, Python, Go) 2.2.0 Radix Engine Toolkit (TypeScript) No Transaction V2 support at launch A Note on Cuttlefish’s Enactment Epoch The Cuttlefish docs page (https://docs.radixdlt.com/docs/cuttlefish) 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 (https://docs.radixdlt.com/docs/network-apis) 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 (https://docs.radixdlt.com/docs/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 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0) and remains the enacted protocol version, but babylon-node (https://github.com/radixdlt/babylon-node/releases) 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. Release Date What it changes v1.3.0.1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.1) 28 December 2024 Fixes in the mempool’s handling of transaction recalculation. Carries a warning against its own use: the native library was inadvertently built requiring GLIBC_2.38. v1.3.0.2 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.2) 3 January 2025 The same fixes, recompiled against a GLIBC compatible with Ubuntu 22.0. v1.3.0.4 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.4) 2 April 2026 Stops the node needlessly reprocessing its entity-listing indices at boot, shortening startup time. v1.3.0.5 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5) 1 June 2026 Adds a database option that lets a node stop storing the previous value of each substate it changes, to save disk. 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 (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) on 28 April 2026 – see Radix Ecosystem Operational Status (/contents/resources/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 (https://github.com/radixdlt/babylon-node/releases/tag/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 (https://docs.radixdlt.com/docs/network-apis) : 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 (/contents/tech/releases/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 (https://docs.radixdlt.com/docs/dugong) 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 (/contents/tech/releases/radix-mainnet-xian) 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 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , “0xOmarA/vault access”, was opened against radixdlt-scrypto’s develop branch on 2 September by 0xOmarA (https://github.com/0xOmarA) , sat unreviewed for five days, and was merged at 17:33 UTC on 7 September 2026. Scrypto v1.4.0 (Eagle Ray) (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) 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 (https://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 (https://github.com/radixdlt/babylon-node/pull/1076) against babylon-node (https://github.com/radixdlt/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 (https://github.com/radixdlt/babylon-node/releases/tag/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 (https://api.github.com/repos/radixdlt/babylon-node/releases/latest) 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 (/policy/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 (/contents/history/hyperlane-asset-drain-2026) 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 (https://t.me/RadixAccountabilityCouncil/1000) 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. State version Epoch / round Timestamp (UTC) What it is 557,840,627 339,897 r4 2026-08-31 21:19:48.939 Last round committed before the halt 557,840,628 339,897 r5 2026-09-11 11:35:28.960 Rounds resume – inside the user-transaction moratorium 557,840,694 339,898 r2 2026-09-11 11:39:25.129 First user transaction, on the far side of the fork 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 (https://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 (https://t.me/RadixDevelopers/66391) ; the publishing transaction committed at state version 557,842,200, epoch 339,909) and submitted a draining transaction against it (https://t.me/RadixDevelopers/66392) . 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 (/developers/scrypto/03-authorization-and-badges#receiver-check) for what the check tests, and Hyperlane asset drain and network halt (/contents/history/hyperlane-asset-drain-2026) 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 (/contents/tech/core-concepts/subintents-and-pre-authorizations) - Radix Mainnet (Babylon) (/contents/tech/releases/radix-mainnet-babylon) - Radix Mainnet (Xi’an) (/contents/tech/releases/radix-mainnet-xian) - Stokenet (/contents/tech/releases/stokenet) - Radix Engine (/contents/tech/core-protocols/radix-engine) - Locker (/contents/tech/core-concepts/locker-blueprint) External Links - Protocol Updates – Radix Docs (https://docs.radixdlt.com/docs/protocol-updates) - Node Protocol Updates (readiness signalling) – Radix Docs (https://docs.radixdlt.com/docs/node-protocol-updates) - Anemone – Radix Docs (https://docs.radixdlt.com/docs/anemone) - Bottlenose – Radix Docs (https://docs.radixdlt.com/docs/bottlenose) - Cuttlefish – Radix Docs (https://docs.radixdlt.com/docs/cuttlefish) - Dugong – Radix Docs (https://docs.radixdlt.com/docs/dugong) - radixdlt-scrypto pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) – the Eagle Ray protocol update and the receiver check ## 3. Authorization and Access Rules URL: https://radix.wiki/developers/scrypto/03-authorization-and-badges Updated: 2026-09-12 Summary: In most smart contract platforms, access control is based on the caller's address – a pattern that leads to fragile permission systems and common expl… Introduction In most smart contract platforms, access control is based on the caller's address – a pattern that leads to fragile permission systems and common exploits like reentrancy. Radix takes a fundamentally different approach: access is gated by badges (https://docs.radixdlt.com/docs/authorization-approach) , which are standard resources (/contents/tech/core-concepts/asset-oriented-programming) (fungible or non-fungible) that serve as unforgeable credentials. A caller is authorised not because of who they are but because of what they hold. This pattern is central to Scrypto (/developers/scrypto/01-fundamentals) development and appears in virtually every non-trivial dApp on Radix. How It Works Access Rules (https://docs.radixdlt.com/docs/authorization-approach) When a component (/contents/tech/core-concepts/components) is instantiated, its methods can be protected with access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) that specify which badge(s) must be present for a call to succeed. The Radix Engine (/contents/tech/core-protocols/radix-engine) checks these rules automatically before executing any method – there is no manual require(msg.sender == owner) logic. That is the whole of the check the Engine has historically made on a method call; a second one, on whether the caller may reach the receiver at all, is being added – see The check below the access rule (#receiver-check) . enable_method_auth! { roles { admin => updatable_by: []; minter => updatable_by: [admin]; }, methods { mint_tokens => restrict_to: [minter, admin]; update_price => restrict_to: [admin]; buy => PUBLIC; } } Proofs (https://docs.radixdlt.com/docs/auth) and the Auth Zone When a method requires a badge, the caller provides a Proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) – a cryptographic attestation that a resource (/contents/tech/core-concepts/resources) exists in the caller's possession without transferring it. Proofs can be placed on the Auth Zone (a transaction-scoped container) so that multiple method calls within the same transaction can share the same authorisation context. # Transaction manifest (https://docs.radixdlt.com/docs/learning-to-create-and-use-transaction-manifests) : create proof and call restricted method CREATE_PROOF_FROM_ACCOUNT_OF_AMOUNT Address("account_rdx...") Address("resource_rdx...admin_badge...") Decimal("1") ; CALL_METHOD Address("component_rdx...") "update_price" Decimal("1.50") ; The check below the access rule An access rule answers one question: does the caller hold the badge this method demands. It does not answer a second one – may the caller reach the object it is calling a method on at all. Until September 2026 the Radix Engine (/contents/tech/core-protocols/radix-engine) did not ask that question of every invocation, and a pull request opened while Mainnet was halted (/contents/history/hyperlane-asset-drain-2026) adds it. radixdlt-scrypto #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , opened on 2 September 2026 from a branch in Radix’s own repository, introduces a protocol update named Eagle Ray (logical_name: "eagle-ray"). Its entire content is one flash batch that advances the SystemBoot substate to SystemVersion::V5. V5 enables one behaviour, should_check_method_receiver_access: before an invocation runs, the kernel tests its visibility of the method’s receiver. A Direct method – the type used by recall and direct vault access – needs direct visibility; an ordinary Main or module method needs some visibility; functions and blueprint hooks are unaffected. Anything else fails with a new error, SystemError::InvalidInvokeAccess. What makes this a badge story rather than a kernel footnote is the test coverage the same pull request adds to radix-engine-tests/tests/system/reference.rs. Passing a typed internal reference to somebody else’s vault into a blueprint function was already legal and still is – the pre-existing test_internal_typed_reference does exactly that and expects a successful commit, because it recalls a recallable resource under the owner’s signature. The new tests take the same reference and call ordinary vault methods on it through ScryptoVmV1Api::object_call, which demand no recaller badge and no signature: - take_via_normal_call and take_non_fungibles_via_normal_call – withdraw from a vault the caller does not own; - lock_fee_via_normal_call – pay the transaction fee out of somebody else’s XRD vault; - forge_proof_via_normal_call – mint a Proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) from a vault the caller does not own; - forge_nft_proof_and_call_gated – the same, then LocalAuthZone::push the forged proof and call a component whose method runs Runtime::assert_access_rule(rule!(require(resource))). Every one of them now fails with InvalidInvokeAccess. The last is the one that matters here: it satisfies a badge-gated access rule with a proof drawn from a badge held in another account. The rule itself never misbehaves – it is handed a genuine proof of a genuine resource and does what it is told. “Authorised by what you hold” depends on the engine below establishing that the vault a proof came from is one you may reach, and that is the check being added, not an access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) you write. Nothing on this page changes as a result. Eagle Ray adds no Scrypto API: badges, proofs, enable_method_auth! and the auth zone are untouched, and a blueprint written against them needs no edit. What has changed since this section was first written is that it is now enforcing on Mainnet. From pull request to enacted, in eleven days An earlier reading of this page, at 19:00 UTC on 4 September 2026, found the pull request open with no reviews, develop unchanged at 858c70f1 of 27 March 2026, and babylon-node (https://github.com/radixdlt/babylon-node/releases) ’s newest release still v1.3.0.5 of 1 June 2026 with no Eagle Ray branch – so no validator yet had a node version to signal readiness for. All four of those facts have since been overtaken: - #2093 merged into develop at 17:33:31 UTC on 7 September 2026, and Scrypto v1.4.0, named Eagle Ray (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) , was published 98 seconds later. The tag carries mod eagle_ray in radix-engine/src/updates/mod.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/radix-engine/src/updates/mod.rs) . - babylon-node v1.4.0.0 (Eagle Ray) shipped on 10 September 2026 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , after an RC1 on 8 September. - The fork enacted at an epoch boundary, not on a readiness signal. Mainnet resumed rounds at state version 557,840,628 at 11:35:28.960 UTC on 11 September under an upgrade moratorium – consensus running, no user transaction committed. The first user transaction is state version 557,840,694 at 11:39:25.129 UTC, in epoch 339,898: three minutes fifty-six seconds later, and one epoch on. The moratorium is legible in the ledger as the 66-state gap between the two. - docs.radixdlt.com/docs/eagle-ray still answers HTTP 404, re-checked 12 September 2026. So does /docs/scrypto-v1-4-0. The protocol update reached Mainnet before it reached the documentation. The error, on Mainnet, against a real attempt On 11 September a node runner tested the deployed fix in the open, publishing a Vault Drainer blueprint to Mainnet ( announced in the Radix Developer Discussion group (https://t.me/RadixDevelopers/66391) ; the publishing transaction committed at state version 557,842,200, epoch 339,909, 12:35:05.915 UTC) and then submitting a draining transaction against it (https://t.me/RadixDevelopers/66392) . The Gateway's verdict on that transaction is PermanentlyRejected, and it names the reason: ErrorBeforeLoanAndDeferredCostsRepaid(SystemError(InvalidInvokeAccess))That is the error described above, returned by Mainnet against a live attempt to call a vault method through a reference the caller was not entitled to reach. The check is not a proposal on this page any more; it is the thing standing between a typed internal reference and somebody else's vault. The chronology of its authorship remains on the record and its causation remains unstated: the branch’s earliest commit is dated 31 August 2026 at 22:41 UTC, 82 minutes after the last round Mainnet committed before the halt, and the receiver check itself 1 September at 00:12 UTC. See Radix Protocol Updates (/contents/tech/releases/protocol-updates) and Installing Scrypto (/developers/getting-started/01-install-scrypto) , whose pins the release moved. Moving Badge-Gated and Restricted Resources Because authorisation on Radix depends on presenting a Proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) , a resource whose withdrawal is gated by a badge cannot be moved with the Radix Wallet (/contents/tech/core-protocols/radix-wallet) 's built-in transfer screen – that flow builds a plain withdraw-and-deposit transaction manifest (https://docs.radixdlt.com/docs/learning-to-create-and-use-transaction-manifests) and never creates the proof the access rule (https://docs.radixdlt.com/docs/auth) demands. Moving it requires a manifest (/contents/tech/core-protocols/transaction-manifests) – typically supplied by a dApp – that creates the required proof first (the CREATE_PROOF_FROM_ACCOUNT_OF_AMOUNT pattern shown above) and then performs the withdrawal within the same transaction. For dApp builders this means: if your users hold badge-gated assets, give them an in-app action that sends the wallet a correctly-authorised manifest, rather than expecting a manual wallet transfer to succeed. It is also why soulbound badges stay put – their Withdraw action is locked outright, so no proof can unlock it. Wallet support for this may be coming. Two pull requests opened on 23 July 2026 by community developer genkipool (/ecosystem/genkipool) would have the wallet attach the required badge itself: sargon #452 (https://github.com/radixdlt/sargon/pull/452) injects badge ResourceSpecifiers into the PerAssetTransfers manifest builder via create_proof_of_amount and create_proof_of_non_fungibles, and babylon-wallet-android #1446 (https://github.com/radixdlt/babylon-wallet-android/pull/1446) builds the transfer feature on top. Both were still open as of 29 July 2026. For the full picture of movement rules on a resource – including freeze, recall, and why a deposit rule cannot check what the recipient holds – see Permissioned and Regulated Assets (/developers/scrypto/09-permissioned-and-regulated-assets) . Common Badge Patterns Admin Badge The most basic pattern: mint a single non-fungible badge at instantiation and return it to the deployer. Methods like withdraw_fees, update_config, or pause are gated behind this badge. User Badge The User Badge Pattern (/contents/tech/core-concepts/badges) issues a non-fungible badge to each user when they register. The badge's non-fungible data stores user-specific state (balances, permissions, membership tier). Methods read the caller's badge data to personalise behaviour without maintaining a separate user registry. Multi-Signature Access rules (https://docs.radixdlt.com/docs/authorization-approach) support boolean logic: require_n_of(2, [badge_a, badge_b, badge_c]) creates a 2-of-3 multi-sig gate. This is useful for treasury management, protocol upgrades, or any high-stakes operation. Soulbound Badges By creating a non-transferable resource (restrict Deposit and Withdraw actions), a badge becomes soulbound to the original recipient's account. This is ideal for identity credentials, certificates, or membership tokens that should not change hands. Next Steps - Events, Metadata, and Royalties (/developers/scrypto/04-events-metadata-royalties) – make your component legible to wallets, indexers, and the Gateway External Links - Authorization – Proofs – Official Docs (https://docs.radixdlt.com/docs/auth) - User Badge Pattern – Official Docs (https://docs.radixdlt.com/docs/user-badge-pattern) - Account Deposit Patterns – Official Docs (https://docs.radixdlt.com/docs/account-deposit-patterns) - radixdlt-scrypto #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) – the Eagle Ray receiver-access check, in the repository Example User Badge Pattern (/contents/tech/core-concepts/badges) ## 3. Deploying to Stokenet and Mainnet URL: https://radix.wiki/developers/getting-started/03-deploying Updated: 2026-09-12 Summary: Mainnet is accepting transactions again Step 3 below deploys to Mainnet , which was halted for ten days and is not any more. The ledger dates its own… Deploying a Scrypto (/contents/tech/core-protocols/scrypto-programming-language) package Hosted console console.radixscan.io (https://console.radixscan.io) – console.radixdlt.com redirects here Operated by RadixScan (/ecosystem/radixscan) , a community team – not Radix Networks Mainnet only; no hosted Stokenet (/contents/tech/releases/stokenet) console exists You upload the .wasm and .rpd from target/wasm32-unknown-unknown/release/ Signed by the Radix Wallet (/contents/tech/core-protocols/radix-wallet) , which also pays the fee Mainnet status live – transactions resumed 11 September 2026 after a ten-day halt Stokenet status live; ledger reset 29 August 2026 Checked 12 September 2026 Overview Mainnet is accepting transactions again Step 3 below deploys to Mainnet, which was halted for ten days and is not any more. The ledger dates its own restart more precisely than any status page does. Mainnet's last pre-halt round is state version 557,840,627, epoch 339,897 round 4, at 21:19:48.939 UTC on 31 August 2026. Rounds resume at 557,840,628 at 11:35:28.960 UTC on 11 September – but under an upgrade moratorium that committed no user transaction, so a package upload would still not have gone through. The first user transaction is 557,840,694, epoch 339,898 round 2, at 11:39:25.129 UTC: three minutes fifty-six seconds later, on the far side of the Eagle Ray (/developers/scrypto/03-authorization-and-badges#receiver-check) fork. Read at 11:07 UTC on 12 September the network stands at epoch 340,179, state version 557,923,055, and /state/validators/list answers HTTP 200 after five hundred-ing throughout the halt. Background: Hyperlane asset drain and network halt (/contents/history/hyperlane-asset-drain-2026) ; live status on Radix ecosystem operational status (/contents/resources/radix-ecosystem-operational-status) . Read the ledger, not the status endpoint An earlier version of this page quoted the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) , which during the halt returned state version 557,840,622 at epoch 339,896 round 102. That is five states short of what the ledger actually committed. The endpoint reports how far the Gateway's own database has read, and a Gateway that has fallen behind reports its own position, not the network's. Pin a read to a state version through at_ledger_state when the answer matters. See Verifiability (/policy/verifiability) . Stokenet was reset on 29 August 2026 Anything you had put on Stokenet before that date – the package, the component (/contents/tech/core-concepts/components) instantiated from it, the test XRD that paid for both – is gone. The tutorial still works; what you build on Stokenet is disposable by design. See After the reset (#stokenet-reset) below. Once you have tested locally with resim, the next step is putting the package on a live network. Deployment is a transaction: you upload the compiled package to a web console, it builds a transaction manifest (/developers/transactions/01-manifest-language) for you, and your wallet signs it and pays the fee. Which network you can do that on has changed. The hosted console covers Mainnet; the Stokenet (/contents/tech/releases/stokenet) console was retired during 2026 and nothing replaced it, so deploying to the testnet now means running a console yourself. Both paths are below. Stokenet vs Mainnet Stokenet XRD is free and has no value. Never send Mainnet XRD to Stokenet addresses. 1. Get Test XRD Skip this if you are deploying straight to Mainnet, where you pay fees in real XRD (/contents/tech/core-protocols/xrd-token) . Stokenet has a faucet (https://www.radixdlt.com/blog/stokenet-is-live) that hands out free test XRD, reached from the wallet itself. Add the Stokenet gateway first (Settings > App Settings > Gateways; the URL and the developer-mode step are on the Stokenet (/contents/tech/releases/stokenet) page), create an account on it, then per the official example walkthrough (https://github.com/radixdlt/official-examples/tree/main/step-by-step/08-ledger-ready-gumball-machine#creating-a-radix-wallet-stokenet-account) : tap the account name, the three dots, Dev Preferences, then Get XRD Test Tokens. 2. Build Your Package scrypto (/developers/scrypto/01-fundamentals) buildYour compiled WASM (https://webassembly.org) file is at: target/wasm32-unknown-unknown/release/.wasmThe build also generates an RPD (Radix Package Definition) file at the same location, which describes your blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) and their interfaces. Where the Developer Console lives now The Developer Console is no longer served by Radix. Checked with a browser user agent on 14 August 2026, console.radixdlt.com answers HTTP 302 to console.radixscan.io (https://console.radixscan.io) and preserves the path, so /deploy-package and /transaction-manifest both arrive at the same route on the new host. The page that loads is titled RadixScan Developer Console. dashboard.radixdlt.com redirects the same way. That is deliberate rather than a lapsed domain: the redirects are issued from Radix's own edge, and the Foundation's operational-stack post (https://www.radixdlt.com/blog/the-foundation-operational-stack-mapping-the-2026-transition) of 26 January 2026 lists the Developer Console, Dashboard and Sandbox as P3 items – the tier it described as "prime opportunities for community teams" to take over. RadixScan (/ecosystem/radixscan) , the team now hosting them, runs deployments of the same open-source dApps monorepo (https://github.com/radixdlt/dapps-monorepo) the originals were built from. Nothing you click is broken, but the tool you are handing a package to is a community deployment. Nothing about the flow below changes; the hostname in your address bar does. 3. Deploy via the Developer Console This deploys to Mainnet. The hosted console has no network selector – the network is fixed when the instance is built (see Deploying to Stokenet below). - Open console.radixscan.io/deploy-package (https://console.radixscan.io/deploy-package) . - Click Connect and connect your Radix Wallet (/contents/tech/core-protocols/radix-wallet) , sharing the account that will pay the fee. - Upload both files: the .wasm and the .rpd. - Set Owner role and Owner role updatable. These decide who may later change package metadata and royalties (/developers/scrypto/04-events-metadata-royalties) ; the official example (https://github.com/radixdlt/official-examples/tree/main/step-by-step/08-ledger-ready-gumball-machine#deploy-the-package-to-stokenet) selects None for both, which is the right choice only if the package needs no owner-gated behaviour. This is the owner of the package, not of the components instantiated from it. - Review the generated manifest (/contents/tech/core-protocols/transaction-manifests) , click Send to the Radix Wallet, and approve in the wallet. Once the transaction commits, the console displays your package address. Save it – you need it to instantiate components. Deploying to Stokenet: no hosted console There is no hosted Stokenet Developer Console. Checked 14 August 2026: stokenet-console.radixdlt.com returns HTTP 530 from the Cloudflare edge with no origin behind it, on /deploy-package and /transaction-manifest alike, and no stokenet- hostname resolves under radixscan.io. Radix's own documentation has not caught up. The step-by-step learning path hands its Stokenet section (https://docs.radixdlt.com/docs/learning-to-use-the-gumball-machine-on-stokenet/) off to the official-examples repository (https://github.com/radixdlt/official-examples/tree/main/step-by-step/08-ledger-ready-gumball-machine#deploy-the-package-to-stokenet) , whose instructions still open with "Go to the Stokenet Developer Console Website" pointing at that 530 host. A developer following the documentation as written cannot complete the first deployment to a real network. The working substitute is to run the console yourself from radixdlt/dapps-monorepo (https://github.com/radixdlt/dapps-monorepo) (Apache-2.0). The network is read from PUBLIC_NETWORK_NAME at build time, which is why one deployment serves one network: git clone https://github.com/radixdlt/dapps-monorepo.git cd dapps-monorepo # .env: PUBLIC_NETWORK_NAME=stokenet # PUBLIC_DAPP_DEFINITION_ADDRESS= npx turbo run build --filter=console node apps/console/buildIt serves on port 3000, with the Gateway (/contents/tech/core-protocols/radix-gateway-api) endpoints already carried in the repository, so you do not need a node of your own. The dApp definition address is yours to create first – see dApp Definition and Wallet Verification (/developers/frontend/04-dapp-definition-and-verification) . Leaving it empty falls back to Radix's addresses, which the README warns will cause errors. apps/console can also go on Vercel by swapping @sveltejs/adapter-node for the Vercel adapter. Stokenet was unaffected throughout, and for the ten days of the Mainnet halt that made it the load-bearing half of this page: the testnet kept committing rounds while Mainnet did not, and its Gateway answers at babylon-stokenet-gateway.radixdlt.com (https://babylon-stokenet-gateway.radixdlt.com) – epoch 4,311 at state version 8,365,764, read 11:08 UTC on 12 September 2026. Both networks take deployments again; it is the hosted Stokenet web tooling that is gone, and that has nothing to do with the halt. After the reset – what you re-run Stokenet was wiped on Saturday 29 August 2026, and the wipe is visible in the ledger itself. Eight hours after the window opened, the Stokenet Gateway returned epoch 51 at state version 137,506 – against epoch 254,946 and state version 425,013,339 ten days earlier – on the same node release, v1.10.6. The date had been set on 18 August 2026 (https://t.me/radix_dlt/998662) by the network’s community operator and relayed to the Radix Developer Discussion group (https://t.me/RadixDevelopers/65991) ; the network went down at 07:00 UTC (09:00 CEST) and several hours of downtime followed, because the operator took the window for server maintenance as well. The ledger it replaced was not small. The replacement ledger has been running since: read at 19:05 UTC on 4 September 2026 it stood at epoch 2,103, state version 5,384,258, advancing about a hundred state versions every twenty seconds – so a Stokenet deployment made today behaves normally. What survives is what is derived rather than stored. Network ID 2, the Gateway URL (https://babylon-stokenet-gateway.radixdlt.com) , the well-known addresses (test XRD, the faucet, the native packages) and your own account addresses are all unchanged, so nothing in a client config or in a console instance built as above needs editing. What it points at is an empty ledger. Taking the steps on this page in order, that means: - Step 1, test XRD – balances are gone; re-fund the same account from the faucet. - Step 2, build – unaffected. The .wasm and .rpd are local artefacts. - Step 3, publish – every package is destroyed; re-publish, and expect a new package address. Anything that hard-codes the old one (a front end, a manifest, a test fixture) has to be updated. - Step 4, instantiate – components go with their packages; re-instantiate and record the new component address. Two things outside this page’s steps also go: on-ledger persona (/contents/tech/core-protocols/personas) data, so wallet personas are recreated, and dApp Definition (/developers/frontend/04-dapp-definition-and-verification) metadata, so a verified dApp stops verifying until its metadata is re-populated. How often this recurs has been stated twice, differently, by the same side. The 16 August announcement gave 9–12 months. Asked on 3 September 2026 why the reset happened at all, Timan Rebel answered for the operator – “we simply did a reset” – that it 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 (https://t.me/radix_dlt/1001768) , embed-verified), and, asked whether that was a problem for developers, “you will have to redeploy your packages and resources, but that is about it” ( 1001787 (https://t.me/radix_dlt/1001787) ). The later figure is offered from memory, so take the cadence as somewhere between the two and the principle as settled: a Stokenet deployment is disposable by default, and the constraint driving it is the cost of storing the ledger. Full terms: Stokenet (/contents/tech/releases/stokenet) . 4. Instantiate a Component Go to the Send Raw Transaction (https://console.radixscan.io/transaction-manifest) section of the console and submit a manifest that calls your instantiation function: CALL_FUNCTION Address("") "GumballMachine" "instantiate" Decimal("5") ; CALL_METHOD Address("") "deposit_batch" Expression("ENTIRE_WORKTOP") ;The resulting component address is your live dApp on Stokenet. Next Steps - Scrypto Fundamentals (/developers/scrypto/01-fundamentals) – understand the asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) programming model - Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) – build a frontend that connects to your component - Transaction Manifest Language (/developers/transactions/01-manifest-language) – learn to write manifests directly External Links - RadixScan Developer Console (https://console.radixscan.io) – where console.radixdlt.com now lands - Official example: publishing a package (https://github.com/radixdlt/official-examples/tree/main/step-by-step/08-ledger-ready-gumball-machine#publishing-the-gumball-machine) - radixdlt/dapps-monorepo (https://github.com/radixdlt/dapps-monorepo) – source of the Console, Dashboard and Sandbox - The Foundation Operational Stack: Mapping the 2026 Transition (https://www.radixdlt.com/blog/the-foundation-operational-stack-mapping-the-2026-transition) - Official deployment guide (https://docs.radixdlt.com/docs/learning-to-run-your-first-scrypto-project/) - What is Stokenet? (https://learn.radixdlt.com/article/what-is-stokenet) ## 1. Installing Scrypto URL: https://radix.wiki/developers/getting-started/01-install-scrypto Updated: 2026-09-12 Summary: Scrypto is Radix's smart-contract SDK for Rust: a crate, a set of macros and a CLI that build a blueprint crate into WebAssembly. You need three thing… Overview Scrypto (/contents/tech/core-protocols/scrypto-programming-language) is Radix's smart-contract SDK for Rust: a crate, a set of macros and a CLI that build a blueprint (/contents/tech/core-concepts/blueprints-and-packages) crate into WebAssembly. You need three things: the Rust toolchain, the WebAssembly (https://webassembly.org) compilation target, and the Radix CLI tools. Fastest Path: VS Code Dev Container If you would rather not install a Rust toolchain at all, the official Scrypto Starter (https://github.com/radixdlt/scrypto-starter) repository ships a pre-configured VS Code Dev Container with everything below already in place. This is the fastest way to a working environment; the manual steps that follow give you the same result with full control over versions. - Download and install VS Code (https://code.visualstudio.com/) . - Install the Dev Containers extension from the Extensions sidebar, then follow its prompts to install Docker Desktop. - Clone the starter repository:git clone https://github.com/radixdlt/scrypto-starter.git - Open the folder in VS Code (File > Open Folder). When prompted, choose Reopen in Container – or run Dev Containers: Reopen in Container from the Command Palette (View > Command Palette). - Once the container finishes building, confirm the Radix Engine Simulator is ready:resim --help If that works, you can skip straight to Your First Blueprint (/developers/getting-started/02-first-blueprint) . Quick Install (Automated) The Scrypto repository (https://github.com/radixdlt/radixdlt-scrypto) ships official install scripts (https://github.com/radixdlt/radixdlt-scrypto/tree/main/scrypto-install-scripts) for macOS, Debian/Ubuntu, and Windows that install a known-good, pinned toolchain in one step – WASM (https://webassembly.org) target included. They pin Rust (https://rustup.rs) 1.92.0, LLVM (https://llvm.org) 21, and radix-clis 1.3.0 – a CLI pin two releases behind the current Scrypto v1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) of 7 September 2026. This is the fastest path to a working setup, but it does not give you the same toolchain as the manual steps below; see Version Pins at the end of this page before you choose. 1. Install Rust Install Rust via rustup (https://rustup.rs) . Scrypto declares no minimum Rust version in its manifest; what it pins is a toolchain, and 1.4.0's rust-toolchain.toml (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/rust-toolchain.toml) names 1.92.0, as 1.3.1's did. Older releases built on 1.81.0, and that number is still what you will meet in the places listed under Version Pins below. [macOS / Linux] curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh source "$HOME/.cargo/env" [Windows] # Download and run the installer from https://rustup.rs # Choose "Proceed with standard installation" 2. Add the WASM (https://webassembly.org) Target Scrypto compiles blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) to WebAssembly (https://webassembly.org/) for deterministic execution on the Radix Engine (/contents/tech/core-protocols/radix-engine) . rustup target add wasm32-unknown-unknownThe Other WASM Target Rust is not the only compiler in the chain. Scrypto's cryptography pulls in blst (https://github.com/supranational/blst) , a C library. Cargo builds it with the system C compiler. Apple's clang carries no wasm32 backend, so scrypto build stops on a fresh macOS install: error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'The automated script above sidesteps this by pinning LLVM (https://llvm.org) 21. The manual path does not. Install LLVM and point Cargo at it: brew install llvmexport CC_wasm32_unknown_unknown="$(brew --prefix llvm)/bin/clang" export AR_wasm32_unknown_unknown="$(brew --prefix llvm)/bin/llvm-ar"Add both exports to your shell profile. brew --prefix resolves the location on Apple Silicon and Intel alike. 3. Install Radix CLI Tools The radix-clis crate provides scrypto (compiler), resim (local simulator), and rtmc ( manifest (/contents/tech/core-protocols/transaction-manifests) compiler). cargo install --force radix-clis@1.4.0Unpinned, cargo install radix-clis resolves to the same 1.4.0, published 9 September 2026 alongside Scrypto v1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) ; the version is written out here because the official install scripts pin an older one. See Version Pins below. Build time First install compiles from source and may take several minutes. Subsequent installs are faster. 4. Verify rustc --version scrypto --version resim --versionAll three commands should print version numbers without errors. IDE Setup For the best experience, install VS Code (https://code.visualstudio.com/) with the rust-analyzer (https://marketplace.visualstudio.com/items?itemName=rust-lang.rust-analyzer) extension. This gives you inline type hints, autocompletion, and error checking for Scrypto code. Troubleshooting Missing WASM (https://webassembly.org) target If Rust reports wasm32-unknown-unknown target not found, re-run: rustup target add wasm32-unknown-unknownblst fails to build One error names the same triple and takes a different fix: No available targets are compatible with triple "wasm32-unknown-unknown"The C compiler raises this one, not Rust, so rustup target add will not clear it. Set the two compiler variables from The Other WASM Target above. Outdated toolchain If builds fail on a fresh install, update Rust: rustup update Version Pins: Which radix-clis You Actually Get The automated scripts and the manual steps do not install the same command-line tools, and the difference is silent. Re-checked at source on 12 September 2026, five days after Scrypto v1.4.0 (Eagle Ray) (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) : - radix-clis (https://crates.io/crates/radix-clis) published 1.4.0 on 9 September 2026, two days after the GitHub release. An unpinned cargo install radix-clis resolves to it. The previous release, 1.3.1, is of 20 January 2026. - The install scripts (https://github.com/radixdlt/radixdlt-scrypto/blob/main/scrypto-install-scripts/install-scrypto-macos.sh) still set RADIX_CLI_VERSION=1.3.0, while setting RUST_VERSION=1.92.0. Not only on main and develop: the copy tagged v1.4.0 (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/scrypto-install-scripts/install-scrypto-macos.sh) carries the same line, so the release ships the lag inside itself. Their last commit (https://github.com/radixdlt/radixdlt-scrypto/commits/main/scrypto-install-scripts) is 7 January 2026 – before either of the two releases that have followed – although the repository's own rust-toolchain.toml carries a checklist of every place a version bump must land and names those script variables explicitly. - The divergence surfaces at scrypto new-package, which writes a rust-toolchain.toml into your project from a bundled template. Under 1.3.0 that template pins channel = "1.81.0" with no extra components (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.0/radix-clis/assets/template/rust-toolchain.toml_template) ; under 1.4.0 it pins channel = "1.92.0" with rustfmt and rust-src (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.4.0/radix-clis/assets/template/rust-toolchain.toml_template) , exactly as 1.3.1 did – rust-src being what the modern build pipeline needs in order to rebuild the Rust standard library with an MVP WebAssembly feature set (https://www.radixdlt.com/blog/scrypto-1-3-1-unlocking-modern-rust-support) . The template has not changed across the two releases, so the gap the automated installer opens is the same one, a release older. - rustup honours that file over the default toolchain (https://rust-lang.github.io/rustup/overrides.html) and installs the pinned channel on demand. So the automated installer sets Rust 1.92.0 as your default, and then your first package quietly builds on 1.81.0 – the exact pin that Scrypto 1.3.1 was released to lift (https://www.radixdlt.com/blog/scrypto-1-3-1-unlocking-modern-rust-support) . Pin the CLI explicitly if you want the modern toolchain: cargo install --force radix-clis@1.4.0The official documentation carries the same lag, and 1.4.0 is documented less than 1.3.1 was. The install and compatibility page (https://docs.radixdlt.com/docs/getting-rust-scrypto) still documents Rust 1.81.0 and radix-clis@1.3.0, three CLI releases back. docs.radixdlt.com/docs/scrypto-v1-4-0 answers HTTP 404, where the v1.3.1 page (https://docs.radixdlt.com/docs/scrypto-v1-3-1) at least exists and reads "Content to be added." The GitHub release body (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) is licence boilerplate with no notes, and the Radix blog (https://www.radixdlt.com/blog) names neither the release nor Eagle Ray. What 1.4.0 contains is legible only from the diff: 18 commits over 300 files (https://github.com/radixdlt/radixdlt-scrypto/compare/v1.3.1...v1.4.0) , among them the Eagle Ray receiver-access check (/developers/scrypto/03-authorization-and-badges#receiver-check) now enforcing on Mainnet. Downloads still follow the scripts rather than the release: on 12 September 2026 crates.io recorded 15 pulls of 1.4.0, three days after publication, against 325 of 1.3.1 and 4,885 of 1.3.0. Next Steps - Your First Blueprint (/developers/getting-started/02-first-blueprint) – write, build, and run a component (/contents/tech/core-concepts/components) on the local simulator External Links - Official install guide (https://docs.radixdlt.com/docs/getting-rust-scrypto) - Scrypto GitHub repository (https://github.com/radixdlt/radixdlt-scrypto) - Scrypto v1.4.0 (Eagle Ray) release (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) – the current release - Scrypto 1.3.1 release blog (https://www.radixdlt.com/blog/scrypto-1-3-1-unlocking-modern-rust-support) – the last release that got one - Official install scripts (version pins in the header of each) (https://github.com/radixdlt/radixdlt-scrypto/tree/main/scrypto-install-scripts) - radix-clis on crates.io (https://crates.io/crates/radix-clis) ## RSwap URL: https://radix.wiki/ecosystem/rswap Updated: 2026-09-12 Summary: RSwap is a decentralised exchange on Radix, run by the Reddicks meme-coin project and reached at dex.reddicks.meme . It is not a protocol of its own s… Type Automated market maker (DEX) on Radix Operator The Reddicks (/ecosystem/reddicks) project (DCKS) Interface dex.reddicks.meme (https://dex.reddicks.meme) Built on DefiPlaza (/ecosystem/defiplaza) 's CALM pair contracts; swap routing with Astrolescent (/ecosystem/astrolescent) Pairs 65 across 7 exchange components, created 4 September 2025 to 25 July 2026 Quote assets DCKS (37 pairs), XRD (12), LSULP (8), hUSDC (4), hETH (2), hSOL (2) Largest pair LSULP/DCKS (https://dashboard.radixdlt.com/pool/pool_rdx1ch7xn38jgrfzmpk6392z3twh9zhh7w8hqgz8s9cvmcj0yhv3xzck8e) , holding 17,533,687.62 LSULP Listed on DeFiLlama 28 April 2026 (https://defillama.com/protocol/rswap) Position, 1 September 2026 Every Hyperlane leg in every pool reads empty after the drain of 31 August (/contents/history/hyperlane-asset-drain-2026) , and 24-hour volume is zero on all 65 pairs while Radix mainnet is halted Position, 12 September 2026 Most liquidity withdrawn after the restart; the deepest pool holds 999,984.71 LSULP, down from 17,533,687.62 RSwap is a decentralised exchange on Radix, run by the Reddicks (/ecosystem/reddicks) meme-coin project and reached at dex.reddicks.meme (https://dex.reddicks.meme) . It is not a protocol of its own so much as a venue assembled from other people's parts: the pair contracts are DefiPlaza (/ecosystem/defiplaza) 's, the swap routing is worked on with Astrolescent (/ecosystem/astrolescent) , and the deepest pool on it is denominated in CaviarNine (/ecosystem/caviarnine) 's liquid-staking unit. For most of its life RSwap was a minor venue. It became a notable one in the second half of August 2026, when CaviarNine announced it was leaving Radix and RSwap said within hours that it was staying. Liquidity moved: an independent measure has its total value locked more than quadrupling between 15 and 30 August. Then, on 31 August, the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) emptied every bridged asset on the network, including the ones sitting in twenty-seven of RSwap's pools, and the network halted five hours later. How it works RSwap is built on DefiPlaza (/ecosystem/defiplaza) 's Radix exchange contracts, and its structure shows it. Each trading pair is a component holding two pools rather than one, a base pool and a quote pool, which is how DefiPlaza's CALM algorithm (https://docs.defiplaza.net/radix/overview) works: CALM keeps a record of each pair's impermanent loss and prices trades that increase it differently from trades that reduce it, using two distinct pricing functions rather than a single curve. DefiPlaza's own documentation is explicit that this is a deliberate alternative to liquidity concentration, not an instance of it. Read from the venue's public pair API (https://dex.reddicks.meme/api/pairs) on 1 September 2026, RSwap listed 65 pairs spread across seven exchange components, the largest of which carries 37 of them. Pools were created between 4 September 2025 and 25 July 2026. The quote side is dominated by the operator's own token: DCKS quotes 37 pairs, XRD 12, CaviarNine's LSULP (https://dashboard.radixdlt.com/resource/resource_rdx1thksg5ng70g9mmy9ne7wz0sc7auzrrwy7fmgcxzel2gvp8pj0xxfmf) eight, and the Hyperlane (/ecosystem/hyperlane) -bridged assets the remaining eight. The largest single pair is LSULP/DCKS, holding 17,533,687.62 LSULP when last read, up from 17,293,134.15 on 19 August. That one position made RSwap the second-largest holder of LSULP on Radix after Weft Finance (/ecosystem/weft-finance) , which is an unusual thing for a meme-coin DEX to be, and it is a dependency on a project that has announced it is leaving. Two measures of the same liquidity RSwap publishes its own liquidity figures in the main Radix Telegram group, and DeFiLlama (https://defillama.com/protocol/rswap) publishes an independent one. They agree on the direction and differ on the size by a factor that has stayed remarkably steady. Date (2026) Announced by RSwap DeFiLlama TVL Ratio 22 August $300,000 (https://t.me/radix_dlt/999057) $99,564 3.01 29 August $500,000 (https://t.me/radix_dlt/999912) $172,940 2.89 A gap that holds within four per cent across two independent announcements a week apart is more likely to be a difference of method than an error in either figure. An adapter values only the assets it recognises and prices; a venue counting "total liquidity" over pairs held in two pools each may be counting something else. This wiki records both with their dates and treats neither as wrong. The DeFiLlama series itself dates the inflection precisely. Radix TVL sat in the low forty-thousands through mid-August, turned upward on 19 August — the day CaviarNine announced its departure and Gary posted RSwap's "RSwap is here to stay" (https://t.me/radix_dlt/998767) reply hours later — and rose almost without interruption to $188,796 on 30 August. Timan of Astrolescent answered that post (https://t.me/radix_dlt/998770) twenty minutes on with "Proudly powered by @DefiPlaza and @Astrolescent_Official", confirming both of those were staying too. Date (2026) DeFiLlama TVL 15 August $40,535 19 August $63,732 22 August $99,564 26 August $170,721 30 August $188,796 31 August, 14:54 UTC $179,614 What the drain took The last figure in that table is the last one there is. DeFiLlama's adapter reads RSwap's pool balances through the Radix Gateway, and its final data point is timestamped 14:54:23 UTC on 31 August 2026 — sixty-eight minutes before the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) began, and six hours before the network halted. Nothing has been recorded since, because there is nothing to read. Anyone looking at RSwap's public TVL today is looking at a pre-drain number. That number was $179,614, and its composition was published alongside it: LSULP $66,372, DCKS $49,438, hWBTC $33,876, hETH $22,281, ASTRL $3,338, DFP2 $2,495 and DELIVER $1,814. The two Hyperlane assets are 31 per cent of the total, and between 16:02 and 16:58 UTC they left. RSwap's own pair API, which kept serving after the drain and before the halt, records the outcome without comment. Of the 65 pairs, 27 carry at least one Hyperlane leg, 33 legs in all. Read on 1 September, 32 of those 33 hold less than a single unit. The one exception is 10.397862 hUSDC in the hETH/hUSDC pair. The DCKS and LSULP sides of the same pools are untouched and sit where they were, which is what a one-sided drain looks like: the pools still exist, they are simply no longer pairs. Every one of the 65 pairs also reports zero volume over the preceding 24 hours. That is not a judgement about RSwap. Radix mainnet stopped producing rounds at 21:19 UTC on 31 August, and for the ten days that followed no transaction settled anywhere on the network. RSwap said nothing publicly in the main Radix Telegram group in the ten hours after the halt. After the restart: most of the liquidity is gone Radix mainnet resumed committing user transactions at 11:39 UTC on 11 September 2026 (/contents/history/hyperlane-asset-drain-2026) . Four hours later, at 15:45 UTC, Gary posted on RSwap's behalf (https://t.me/radix_dlt/1003095) in the main Radix Telegram group: “Most liquidity has been pulled from RSwap. We are waiting a week or two for everything to stabilize a little more before we commit to adding liquidity back. We aren't going anywhere. We just have to ensure prices make sense before putting large liquidity back on the DEX.” The ledger agrees with the first sentence and puts a size on it. The LSULP/DCKS base pool – the deepest position on the venue, and the one that made RSwap the second-largest holder of LSULP on Radix – held 17,533,687.62 LSULP when this page read it on 1 September. Read from the Radix Gateway (https://mainnet.radixdlt.com/state/entity/details) at state version 557,909,523 on 12 September 2026, the same pool (https://dashboard.radixdlt.com/pool/pool_rdx1ch7xn38jgrfzmpk6392z3twh9zhh7w8hqgz8s9cvmcj0yhv3xzck8e) holds 999,984.712991754875569675. That is 94.3 per cent of the position withdrawn in the first day the network could carry a withdrawal, and the venue's own pair API (https://dex.reddicks.meme/api/pairs) returns the identical figure to the last decimal, so on this number the two independent readings do not disagree. This page does not read the statement as a departure notice, because it says the opposite in its own words. It is a stated intention to return, and it dates itself: “a week or two” from 11 September is checkable from about 25 September 2026. Relationship to Reddicks RSwap is the trading layer of Reddicks (/ecosystem/reddicks) rather than a separate business, and the two are financially joined: Reddicks runs a protocol-owned treasury that takes a 1% fee on RSwap buys and sells and recycles it into protocol-owned liquidity. DeFiLlama files the venue under the DCKS ecosystem and describes it as "a meme-driven DEX built for the DCKS ecosystem", which is also why DCKS quotes 37 of the 65 pairs. The relationship runs the other way too. When Reddicks acquired DELIVER (/ecosystem/deliver) in mid-2026, taking roughly 60 million tokens and the project's Ociswap (/ecosystem/ociswap) pool badge into the DCKS treasury, the stated purpose was to pair the holding against DCKS and deepen liquidity here. DELIVER duly appears in RSwap's pool composition, at $1,814 of the 31 August total. Announcements are posted to the main Radix Telegram group by Gary (https://t.me/GarySky1) under the Reddicks banner; the project's X account is @REDDICKS_XRD (https://x.com/REDDICKS_XRD) . RSwap has no token of its own. External Links - dex.reddicks.meme (https://dex.reddicks.meme) – the exchange - RSwap pair API (https://dex.reddicks.meme/api/pairs) – every pair, its two pools, balances and creation date - RSwap on DeFiLlama (https://api.llama.fi/protocol/rswap) – the independent TVL series, frozen at 31 August (the JSON; the human page is behind a Cloudflare challenge) - The DeFiLlama adapter (https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/rswap/index.js) – what that series actually counts - DefiPlaza's CALM algorithm (https://docs.defiplaza.net/radix/overview) – the pair design RSwap runs on - The main exchange component (https://dashboard.radixdlt.com/component/component_rdx1czlszr76d2wrc28uslyqddp6cgelx6y4rf2a80056wwd4grx9u09xy/summary) – on the Radix Dashboard - DCKS resource (https://dashboard.radixdlt.com/resource/resource_rdx1t42hpqvsk4t42l6aw09hwphd2axvetp6gvas9ztue0p30f4hzdwxrp) – the token quoting most of the book ## Radix Accountability Council URL: https://radix.wiki/ecosystem/radix-accountability-council Updated: 2026-09-12 Summary: The Radix Accountability Council ( RAC ) is a five-member community-elected body tasked with guiding the transition from the Radix Foundation to the R… Radix Accountability Council Type Governance Body Status 🟢 Active – Transition RAC (DAO formation) DAO Entity Radix DAO LLC – Marshall Islands DAO LLC (MIDAO), agreement signed and fee paid 5 Sep 2026, registry filing from 7 Sep 2026 Formed February 2026 Members Tadkis (replaced Faraz), Jazzer_9F (82.92%), Avaunt (58.44%), projectShift (57.22%), Alfred | ALFRED_DULAiRE (replaced Peachy) Council Size 5 (elected via approval voting (https://radixtalk.com/c/governance) ) Election Turnout 1.34B XRD / 1,151 accounts Telegram t.me/RadixAccountabilityCouncil (https://t.me/RadixAccountabilityCouncil) (351 members) Official Venue radixdao.org (https://radixdao.org/) (from 29 Aug 2026) Consultations RadixTalk (/ecosystem/radixtalk) · Radix Consultation dApp (https://consultation.mountain-top.live/) Introduction The Radix Accountability Council ( RAC (/ecosystem/radix-accountability-council) ) is a five-member community-elected body (https://radixtalk.com/c/governance) tasked with guiding the transition from the Radix Foundation (/ecosystem/radix-foundation) to the Radix DLT DAO (RDD). Established in February 2026 following a series of community consultations, the council serves as the primary interface between the Radix community and the Foundation during the decentralisation of governance. It is one stage in Radix's broader governance (/contents/tech/core-concepts/radix-governance) and will be succeeded by a permanent, elected council. The RAC's charter defines three core responsibilities (https://t.me/RadixAccountabilityCouncil) : establishing the structures and processes needed to achieve the transition, executing community will as a multi-signer on RDD-associated structures, and representing RDD interests on matters of the Foundation transition. The council operates through an open Telegram channel (https://t.me/RadixAccountabilityCouncil) with 351 members, where RAC members post as admins and the broader community can observe proceedings. 2026 Strategy: The Next Chapter of Radix In February 2026, the Radix Foundation (/ecosystem/radix-foundation) published its 2026 Strategy (https://www.radixdlt.com/blog/2026-strategy-the-next-chapter-of-radix) outlining the transition from Foundation-led operations to community-driven governance. The strategy represents a fundamental shift in how Radix is managed and funded. Three-Phase Decentralisation The Foundation is implementing a phased approach to handing over control: - Phase 1 – Expanding the consultation dApp for community signalling on funding allocation, and requesting RFPs for critical services (gateway operations, code maintenance). - Phase 2 – Community-initiated RFPs for marketing, partnerships, and incentive programmes. - Phase 3 – Full on-chain governance control via DAO or multi-sig structures. Key Commitments The strategy FAQ (https://www.radixdlt.com/blog/2026-strategy-faq) clarifies several important points: the Foundation does not plan to sell XRD to cover operational costs, relying instead on existing fiat reserves. Critical infrastructure will not be discontinued without reliable alternatives in place. Radix trademarks and intellectual property will transfer to community-controlled entities (potentially DAOs or trusts) to prevent capture while preserving ecosystem access. Rather than repeating previous leadership's approach of traditional marketing with substantial funding, Radix is transitioning to community-determined priorities where members can submit their own proposals for marketing, code, or business development. Background: Foundation to DAO Transition Since its inception, the Radix Foundation (/ecosystem/radix-foundation) has served as the custodial entity overseeing the development and operational infrastructure of the Radix network (https://www.radixdlt.com) . As the network matured, a community consultation process (https://radixtalk.com/c/governance) was initiated to transition governance authority from the Foundation to a community-run decentralised autonomous organisation – the Radix DLT DAO. The consultation to establish the RAC (https://radixtalk.com/c/governance) recognised that a structured transition body was needed to bridge the gap between Foundation-led and community-led governance. Rather than an abrupt handover, the council model provides continuity through elected representatives who can negotiate with the Foundation, manage multi-signature authority over DAO structures, and ensure community interests are represented throughout the process. Election & Consultation Results RAC (/ecosystem/radix-accountability-council) members were elected through an approval voting mechanism (https://radixtalk.com/c/governance) where XRD holders could vote for up to five candidates from the pool of nominees. The consultation drew participation from 1,151 unique accounts representing approximately 1.34 billion XRD in voting weight. Council Size A separate consultation on council size resulted in five members winning with 56.91% of 1.30B XRD, over alternatives of three (18.94%), seven (16.23%), or nine (7.93%) members. Elected Members Member Approval % Peachy 92.76% Faraz | Radstakes 83.87% Jazzer_9F 82.92% Avaunt 58.44% projectShift 57.22% Note: The council's membership has changed twice since the election. Faraz stepped down from the RAC in February 2026, and Tadkis (https://t.me/RadixAccountabilityCouncil) joined as the replacement member on 18 February 2026. Peachy – the highest-polling candidate in the election – stopped participating in the transition work from 4 March 2026 and subsequently confirmed he would not return to the council; the RAC recorded his departure in a public note on 26 May 2026 (https://t.me/RadixAccountabilityCouncil/867) , with Alfred (ALFRED_DULAiRE) serving as the fifth member. The RAC has operated as a five-person council throughout the handover. Adam, CSO of the Radix Foundation (/ecosystem/radix-foundation) , participates in the RAC Telegram channel (https://t.me/RadixAccountabilityCouncil) as a Foundation representative but is not a council member. The formation consultation ran from January 30 to February 6, 2026 (https://www.radixdlt.com/blog/consultation-results-radix-accountability-council) – one of the highest-participation governance events in Radix history. The race for fifth place was decided by a razor-thin margin (769.9M vs 768.2M XRD), confirming a genuinely competitive election. Responsibilities The RAC (/ecosystem/radix-accountability-council) 's pinned charter (https://t.me/RadixAccountabilityCouncil) defines three core areas of responsibility: - Establish transition structures – Create and refine the legal, organisational, and governance structures needed for the Radix Foundation (/ecosystem/radix-foundation) to hand over operational control to the Radix DLT DAO. - Execute community will – Act as multi-signers on RDD-associated structures, ensuring that decisions made through community consultations are faithfully executed on-chain and off-chain. - Represent RDD interests – Serve as the community's voice in negotiations with the Radix Foundation on matters relating to the transition, including asset transfers, intellectual property, and operational handovers. Separately, the community has drafted a Radix Network DAO Charter (/ideas/radix-network-dao-charter) – a discussion-stage governance framework adapted from the Aragon Network DAO Charter (https://github.com/aragon/network-dao-charter) – as a reference for the transition structures the RAC is tasked with establishing. The RAC also oversees the wind-down of the Validator Subsidy (/contents/history/validator-subsidy-sunset) , with administration transferring from the Foundation to community entities in April 2026. Foundation Operational Stack As part of the transition planning, the Radix Foundation (/ecosystem/radix-foundation) published its Operational Stack (https://www.radixdlt.com/blog/the-foundation-operational-stack-mapping-the-2026-transition) – a prioritised inventory of all services and infrastructure currently maintained by the Foundation that will need to be transferred to or replicated by the DAO. Priority 1 – Core Network Access & Resilience High-availability services essential for network interaction, requiring immediate continuity planning via an RFP process: - Babylon (/contents/tech/releases/radix-mainnet-babylon) Gateway Endpoint – primary API for ledger indexing and transaction submission - Radix Connect (/contents/tech/core-protocols/radix-connect) Relay – signalling service enabling secure wallet-to-dApp connections - Signaling Server – enables P2P connections between wallet and desktop extension Priority 2 – High-Use & Product Maintenance Stable tools requiring active maintenance but not vital for network survival: - Core software: Node Software, Core Code Repos, Wallet (iOS/Android) - Infrastructure: Radix Connector Extension, Turn Server, Ledger App - Web properties: radixdlt.com, social channels Priority 3 – Non-Critical but Maintained Experience-improving services offering commercialisation opportunities: asset service, image service, price feeds, Dashboard, RadQuest (/ecosystem/radquest) , Gumball Club, dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) , Dev Console, documentation sites. As of February 2026, the community is being asked to provide input (https://radixtalk.com/t/action-on-p3-foundation-services/2238) on the desired handover, open-sourcing, or shutdown of each P3 service. Active Handover Phase As of mid-February 2026, Adam (CSO Radix Foundation (/ecosystem/radix-foundation) ) announced (https://t.me/RadixAccountabilityCouncil/405) that the RAC (/ecosystem/radix-accountability-council) has entered the active handover phase. Key activities include: - Entity formation – Standing up the DAO's legal entity is identified as the main blocker, as many assets and services require a legal entity to transfer to. The community subsequently settled on a Marshall Islands DAO LLC – see DAO Formation Progress below. - P3 service assessment – The Foundation initiated community input on P3 services via RadixTalk discussion (https://radixtalk.com/t/action-on-p3-foundation-services/2238) , with the RAC expected to coordinate the process going forward. - Custody questions – RAC members are discussing how to serve as custodians-under-trust for assets (social accounts, GitHub, Telegram channels) until a formal entity exists. - Consultation V2 – projectShift is working on running the consultation dApp autonomously, independent of Foundation infrastructure. DAO Formation Progress Through 2026 the RAC (/ecosystem/radix-accountability-council) has moved from planning into standing up the community DAO as a Marshall Islands DAO LLC, formed through the MIDAO framework. The Marshall Islands wrapper gives the Radix Foundation (/ecosystem/radix-foundation) a compliant counterparty to receive the treasury, intellectual property, and operational assets of the network. The direction was mandated by a community vote, choosing the Marshall Islands over earlier options such as a Wyoming DUNA, a Cayman Islands foundation, or an Abu Dhabi entity. Legal counsel and setup grant The RAC retained legal counsel – a UK barrister with blockchain experience – and held a kickoff meeting in March 2026 (https://t.me/RadixAccountabilityCouncil/805) to scope entity formation, the asset and IP handover, and the DAO's governance structure. To fund the work it requested a setup grant (https://t.me/RadixAccountabilityCouncil/818) from the Foundation, which the Foundation board approved (https://t.me/RadixAccountabilityCouncil/820) : USD 67,000 plus 10 million XRD, paid in two tranches. Tranche one (USD 27,000 and 5 million XRD, covering legal and incorporation work) was delivered to the RAC in May 2026 (https://t.me/RadixAccountabilityCouncil/840) ; tranche two, needed to pay the Marshall Islands submission fees, was gated on the DAO documentation being ready for the Foundation to confirm the asset transfer could proceed; the council reported receiving it on 13 August 2026 (https://t.me/RadixAccountabilityCouncil/911) . The RAC capped legal costs at roughly £18,000. Separately, the Foundation pre-funded Gateway infrastructure through December 2026 and centralized-exchange market making through September 2026 to give the DAO runway during setup. Operating Agreement and Charter Working weekly with counsel – and with community contributor "Daffy" bridging the open governance repository (https://github.com/RadixDAO/governance-framework) – the RAC drafted the DAO's two founding documents: an Operating Agreement, the legally binding document required to form the company in the Marshall Islands, and a Charter, the constitutional document capturing the community's governance principles. As of July 2026 (https://t.me/RadixAccountabilityCouncil/894) both are finished, the Operating Agreement has been sent to the Foundation for its lawyers to review, and the pair will then be presented to the community for discussion and voting. Both documents were written to require community approval before adoption. This community-run framework builds on the discussion-stage Radix Network DAO Charter (/ideas/radix-network-dao-charter) . Transition RAC and Permanent RAC The agreed model (https://t.me/RadixAccountabilityCouncil/882) distinguishes a Transition RAC – the present, pre-DAO council, mandated to complete company formation and the Foundation's handover of assets – from a Permanent RAC that the community will elect afterwards to steward the DAO's ongoing governance. Once the company exists, the Transition RAC initiates a custody contract with PrimeVault, the arrangement that finally enables the Foundation to transfer the granted assets to the DAO. Stokenet handover In parallel, control of Stokenet (/contents/tech/releases/stokenet) , Radix's test network, transitioned to the community (https://t.me/RadixAccountabilityCouncil/876) in June 2026, with community members running its validators and Gateway – an early, practical proof of the handover the DAO is being built to complete. Consultations and Proposals Through the first half of 2026 the RAC (/ecosystem/radix-accountability-council) facilitated consultations as forum threads on RadixTalk (/ecosystem/radixtalk) . The process has since moved onto a purpose-built Radix Consultation (https://consultation.mountain-top.live/) dApp, where a proposal is first posted as a Temperature Check for discussion and, once validated, opened as a numbered proposal for XRD-weighted voting. The app and the governance process behind it are tracked at DAO Governance App – Consultation v2 (/ideas/dao-governance-app-consultation-v2) . Proposals opened for voting, July 2026 The RAC opened two Temperature Checks on 25 July 2026 (https://t.me/RadixAccountabilityCouncil/904) and announced on 28 July (https://t.me/RadixAccountabilityCouncil/906) that both had been validated and moved to the voting stage: - Stokenet operation (https://consultation.mountain-top.live/proposal/1) – community contributor Daffy had carried the cost of running Stokenet (/contents/tech/releases/stokenet) himself for several months on the expectation that the DAO would become the contracting entity. With formation still incomplete, the proposal asks the Radix Foundation (/ecosystem/radix-foundation) to enable the arrangement in the interim. - Migrate the Radix website from Webflow to Cloudflare (https://consultation.mountain-top.live/proposal/2) – a proposal from Timan Rebel for a cheaper way to safeguard the radixdlt.com content while the community decides what to keep and how to run the network's web presence. See DAO Website Redesign (/ideas/dao-website-redesign) . How they closed Both proposals ran the component's seven-day window and closed on 4 August 2026. Read from the Governance component (https://dashboard.radixdlt.com/component/component_rdx1czn9hrgd30x742k6jw2e6psj9jlkqvu2cj4hcry60p7f38hxd3k3xt) on 11 August, the Stokenet proposal carries 55 ballots and the website proposal 56, every one of them in favour – no account voted against either – and the weight behind the voting accounts clears the 671,470,000 XRD quorum set for each by roughly 40% (the recomputation is on Radix Governance (/contents/tech/core-concepts/radix-governance) ). The council has announced no result for either, and posted nothing further to its channel until 13 August 2026, sixteen days after the elevation – see August 2026: the council reports below. A further consultation, Temperature Check 6 (https://consultation.mountain-top.live/tc/6) on registering Radix in the CAIP namespaces registry and the x402 payment standard, closed on 6 August with 58 votes and has not yet been lifted to a numbered proposal. Permanent RAC candidates On 15 July 2026 (https://t.me/RadixAccountabilityCouncil/900) the council published a running list of community members who had signalled a willingness to stand for the Permanent RAC – Giles Morris, Timan Rebel, Markus, LINUXX.XRD, JW, a137x and Leonardo – ahead of the election described under Transition RAC and Permanent RAC above. The mechanics of that election are tracked at Elect a Permanent RAC (/ideas/dao-elect-permanent-rac) . Earlier consultations The consultation on the DAO's legal jurisdiction and entity type concluded in favour of a Marshall Islands DAO LLC (MIDAO), chosen over a Wyoming DUNA, a Cayman Islands foundation, an Abu Dhabi entity, and other jurisdictions – see DAO Formation Progress above. A draft consultation on Season 2 of Radix Rewards, the programme that incentivises network participation and ecosystem development, was raised on RadixTalk earlier in 2026, as was a question about the terms of the Foundation's acquisition of intellectual property from Instabridge and its relevance to the DAO transition. August 2026: the council reports On 13 August 2026 the council ended a sixteen-day silence with a status update (https://t.me/RadixAccountabilityCouncil/911) posted to its channel and relayed to the main Radix group (https://t.me/radix_dlt/998093) – its first communication since the 28 July elevation of the two proposals. It moves three of the workstreams described above, and sets no date for any of them. Legal formation The Radix Foundation (/ecosystem/radix-foundation) has reviewed the proposed Operating Agreement and validated it as a fit for handing the assets it holds to the DAO company, and the council reports no outstanding actions or dependencies on the Foundation's side. Tranche two of the setup grant has been received, which is what puts the council in a position to pay the Marshall Islands formation expenses. No date is fixed for the MIDAO submission; counsel is expected to file the formal application within a few working days. Charter ratification The Charter is described as close to its final text, and the council is arranging for the community to ratify it by vote at what it calls a significant high threshold for acceptance. Ratification is to run in parallel with the company's constitution rather than after it, and the stated dependency is not the lawyers but the Radix Consultation (https://consultation.mountain-top.live/) dApp. The council asks the community to read the document in advance – pointing at the guides in Daffy's open governance repository (https://github.com/RadixDAO/governance-framework) – and states that no governance will happen except by following it. The Permanent RAC election At least seven people have now declared a willingness to stand for the Permanent RAC, which will seat seven members. There is no cap on candidates and the council encourages more to stand, since a contested field is the point; declarations are made in public, as in Giles Morris's RFP thread on RadixTalk (https://radixtalk.com/t/rfp-volunteer-delegate-candidate-on-the-permanent-rac-of-the-radix-midao/2312) . The election cannot open until the Charter is ratified, because the Charter sets the process and its conditions. The ballot will use Majority Judgment (https://en.wikipedia.org/wiki/Majority_judgment) – a method in which every voter grades every candidate on a shared scale and the winner is the one with the best median grade, rather than the one named on the most ballots – which is being implemented in the Consultation dApp for this election. The update closes on the council's own framing of its role: the Transition RAC is not a second foundation, and the community is expected to build and decide rather than wait to be shepherded. 29 August 2026: the Official Venue opens The council posted twice in one day, and between them the three workstreams above each moved by a measurable step. Formation The first update (https://t.me/RadixAccountabilityCouncil/918) reports that the council and its counsel evaluated MIDAO's Service Agreement, proposed amendments to improve the DAO's position under its terms, and that MIDAO accepted them. The council will sign the amended agreement, pay, and submit the incorporation of Radix DAO LLC through MIDAO's onboarding platform, with the next actions on the council's own side and the submission rolling out "from Monday onwards" – 31 August 2026 at the earliest. Once filed, the council puts the Marshall Islands registry at four to six weeks to grant and issue the Certificate of Formation, and says it will report on advancements rather than on each of the process's many steps. The repository leaves a personal account The second update (https://t.me/RadixAccountabilityCouncil/920) completes a move the council had trailed hours earlier: the community's governance repository is now hosted under the DAO's own GitHub organisation, github.com/RadixDAO (https://github.com/RadixDAO) , as RadixDAO/governance-framework (https://github.com/RadixDAO/governance-framework) , having been transferred over from Daffy's personal account. The council asked the community to adjust all links to it and to treat those two URLs as the sources. The framework itself is now signed: every document in the ratification manifest carries a SHA-256 and the certificate that signed them is published in its own right – the detail is on the Radix DAO Charter (/ideas/radix-network-dao-charter) page. An official venue, and what it is for radixdao.org (https://radixdao.org/) went live the same day as the DAO's Official Venue, the term the Operating Agreement uses for the place a ratified document must be published to. Daffy and Timan (/ecosystem/astrolescent) built it and automated its deployment from GitHub. Its Notices & Records section opened with two entries, both dated 29 August 2026 and both linking a signed PDF: the technical details of the certificate the Transition RAC signs with (https://radixdao.org/notices/2026-08-29-transition-rac-certificate-technical-information-and-details/) , published at 15:07 UTC so that any signature can be checked against it, and the full minute of the council's 25 August meeting (https://radixdao.org/notices/2026-08-29-transition-rac-s-decisions-to-enable-and-support-the-ratification-process/) at 16:41 UTC, recording the decisions that enable the ratification process. The site's footer draws the line the transition depends on: Radix DAO LLC is a separate legal entity from Radix Publishing Ltd (/ecosystem/radix-foundation) , which operates radixdlt.com. Ratification, still undated The council says it will formally initiate ratification of the Charter and the policies "as soon as possible", with only a few details left to clear, and that this will get a post of its own. The process begins with a discussion period supported by a new topic on RadixTalk (/ecosystem/radixtalk) . No date is attached to any of it, and the venue's own banner states the position plainly: pre-formation, ratification vote pending, community decisions advisory until activation. 5 September 2026: signed, paid, and filed from Monday Six days after the submission was due to roll out from Monday onwards, the council reported it done. At 13:17:43 UTC on 5 September 2026 the RAC member Tadkis posted to the council’s channel (https://t.me/RadixAccountabilityCouncil/988) that the agreement with MIDAO has been signed and the registration fee has been paid, and that the formal registration process is scheduled to begin on Monday 7 September 2026. An hour and six minutes later projectShift relayed it to the main Radix group (https://t.me/radix_dlt/1002055) as Step one of the DAO is actually done now. That completes the sequence tranche two of the setup grant was released for: amend MIDAO’s Service Agreement, sign it, pay, and file. The four to six weeks the council put on the Marshall Islands registry to grant and issue the Certificate of Formation runs from the filing rather than from the signature, so on the council’s own figures the certificate falls between mid-October and mid-November 2026. Nothing in the announcement changes the entity, the registered agent, or the documents: the wrapper is still a non-profit DAO LLC with MIDAO Directory Services (https://midao.org) of Majuro as registered agent, and the formation documents remain the drafts tracked at Incorporate the Marshall Islands DAO LLC (/ideas/dao-incorporate-duna-llc) . The step is also the only part of the transition that has moved since Radix mainnet halted (/contents/history/hyperlane-asset-drain-2026) on 31 August. Ratification of the Governance Framework is Activation Condition 6 of the Operating Agreement and needs a vote, which is why the council removed the seven-day limit on the Discussion phase and left it open-ended while the ledger was stopped. The ledger stopped being the obstacle at 11:39 UTC on 11 September 2026. In a status update (https://t.me/RadixAccountabilityCouncil/1026) posted three hours later the council said it is "keeping the Discussion phase open for now" and gave a different reason, that "we have all been too focused on the incident and mainnet and there is still time and need to have it refocused on the ratification process". The phase is therefore open by choice rather than by necessity; the Permanent RAC election (/ideas/dao-elect-permanent-rac) sits behind that. Incorporation runs through a registry that does not depend on the network, which is why it is the leg still advancing. External Links - Telegram – Radix Accountability Council (https://t.me/RadixAccountabilityCouncil) - Consultation Results: Radix Accountability Council – Radix Blog (https://www.radixdlt.com/blog/consultation-results-radix-accountability-council) - 2026 Strategy – The Next Chapter of Radix (https://www.radixdlt.com/blog/2026-strategy-the-next-chapter-of-radix) - 2026 Strategy FAQ – Radix Blog (https://www.radixdlt.com/blog/2026-strategy-faq) - The Foundation Operational Stack: Mapping the 2026 Transition (https://www.radixdlt.com/blog/the-foundation-operational-stack-mapping-the-2026-transition) - Radix Foundation – RADIX.wiki (/ecosystem/radix-foundation) - RadixTalk – Governance & DAO Transition Consultations (https://radixtalk.com/c/governance) - RadixDAO/governance-framework – the operative governance documents (https://github.com/RadixDAO/governance-framework) - radixdao.org – the DAO's Official Venue (https://radixdao.org/) ## Miow URL: https://radix.wiki/ecosystem/miow Updated: 2026-09-12 Summary: Miow is a Web3 website builder on the Radix network, positioned by its authors as "Squarespace for Radix". Users connect their Radix wallet , assemble… Overview Miow is a Web3 website builder on the Radix (/contents/tech/core-protocols/radix-engine) network, positioned by its authors as "Squarespace for Radix". Users connect their Radix wallet (/contents/tech/core-protocols/radix-wallet) , assemble pages from a drag-and-drop block editor, and pay 100,000 XRD (/contents/tech/research/radix-economic-model) once to publish. The platform's published briefing states the price is a one-time payment per site with no subscription. A published site is served from a path on the platform domain rather than from its own subdomain: the public sitemap lists every live site as miow.me/s/, and miow.me/s/blockspace-capital serves one such site. The same payment also releases the site as a downloadable Next.js project; the deployment guide covers self-hosting it on Supabase and Vercel behind a custom domain, which is the route to a domain of one's own. - Platform: miow.me - Published sites: miow.me/s/ - Price: 100,000 XRD per site, one-time - Payment: native XRD wallet transaction (Radix Wallet required) Status and Adoption The platform is offline. Read at 03:11 UTC and again at 23:09 UTC on 4 September 2026, miow.me resolves to Vercel and answers HTTP 404 at every path with the header x-vercel-error: DEPLOYMENT_NOT_FOUND and a 107-byte text/plain body reading “The deployment could not be found on Vercel.” The same answer comes back for the root, the sitemap, the deployment guide, the published briefing and the one published site this page cited by name. A deployment that has been deleted or unassigned from its domain answers this way; a bot wall does not, and neither does a server under load. The Internet Archive (https://web.archive.org/web/20260610*/miow.me*) holds 35 captures of the domain, every one of them taken on 10 June 2026, so none of the pages cited below can be read in an archive either. This is a hosting outage rather than a shutdown announcement: nobody has said the project has ended. The network halt of 31 August 2026 (/contents/history/hyperlane-asset-drain-2026) was offered here as context while it lasted, and it no longer serves as one: Radix mainnet resumed committing transactions at 11:39 UTC on 11 September 2026, and re-probed at 07:52 UTC on 12 September 2026, miow.me returned the same HTTP 404 and x-vercel-error: DEPLOYMENT_NOT_FOUND it returned on 4 September. What can be measured is that the platform is not operable, which is what the status field on this page records. What was verified while it was up. Everything described on this page was read from the platform's own surfaces on 15 August 2026. Sign-in was Radix ROLA (/contents/tech/core-protocols/radix-connect) wallet-signature authentication; the builder placed the block types listed below on a twelve-column grid with per-block style controls; publishing served the result at miow.me/s/; and store blocks priced products in XRD, with Stripe available for fiat checkout. Adoption was small and publicly measurable. On 15 August 2026 the sitemap listed eleven published sites, and most carried builder-default names — several untitled-site-*, a test-site-*, and repeated variants of the same project name — so the figure read as development and demonstration work rather than as third-party production deployments. It was the honest measure available from outside: the platform published no user or revenue figures, and a site published under a custom domain via the export route would not have appeared in that sitemap at all. The Archive's 10 June 2026 crawl is consistent with it, listing nine site slugs of the same shape. Formant Design System Miow's distinguishing feature is Formant, a parametric design system. Thirteen continuous parameters — hue, chroma, lightness curve, radius, spacing, weight contrast, line height, shadow depth, animation speed, glass effect, noise texture, grain size and border width — are fed to a deriveTheme() function that computes roughly fifty CSS custom properties, so a site's whole visual identity follows from a handful of sliders rather than from hand-written CSS. Colour is computed in OKLCH (https://oklch.com/) rather than sRGB, which is what makes the parameters behave predictably: in a perceptually uniform space the same chroma value reads as equally vivid across every hue, so moving the hue slider does not silently change how saturated the palette looks. The system ships with presets as starting points. Block Types Miow builds pages from the same typed-JSON block model this wiki uses, so a block is a small object with a type discriminator rather than a stored fragment of markup. The platform's published briefing lists twelve types: Block Description content Rich text HTML columns Multi-column container infobox Nested block container store Product grid with XRD checkout stats Metric cards testimonial Quote with attribution gallery Image gallery rssFeed RSS/JSON feed display codeTabs Tabbed code display assetPrice Radix asset price widget recentPages Dynamic page list pageList Static page references Each block additionally carries grid position and style, which is what the drag-and-drop canvas edits — the same block objects rendered on a linear wiki page here become positioned cards on a Miow canvas. External Links Every URL this page cited is on miow.me, and the domain has served DEPLOYMENT_NOT_FOUND at every path since at least 4 September 2026. The list is kept as a record of what was cited and where it was read, without live links to pages that no longer answer. - miow.me – the platform - miow.me/guide – installation and deployment guide, self-hosting an exported site - miow.me/sitemap.xml – the index of published sites - miow.me/llms.txt – the platform's own briefing (features, pricing, stack) - miow.me/AGENTS.md - Internet Archive – miow.me (https://web.archive.org/web/20260610*/miow.me*) , 35 captures, all from 10 June 2026 - Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) – how this wiki reads a project website, and what a probe does not prove ## OTER URL: https://radix.wiki/ecosystem/oter Updated: 2026-09-12 Summary: OTER (Optimistic Truth Engine, tagline "The truth will out.") is an optimistic oracle built on Radix DLT . Any dApp or person can post a verifiable qu… OTER – Optimistic Truth Engine Type Optimistic oracle Category Ecosystem (/ecosystem) (Oracle) Network Radix (/contents/tech/core-protocols/radix-engine) Status 🟡 Pre-launch (beacon live in production) Tagline "The truth will out." Dispute resolution Staked jury, timelock-sealed ballots, single round Voting power √stake (square root of staked amount) Challenge window 4 hours default, configurable per question Vote cycle 48 hours (24 h commit · 12 h reveal · 12 h re-propose) Settlement Pull-based, atomic – consumers read in their own transaction Randomness OTER Beacon (https://random.oter.io/) – BLS12-381, 3-second period Governance Staker DAO – same sealed √stake vote as a dispute Founding integration Tāhuna (/ecosystem/tahuna) (prediction markets) Governance platform OTER XRD Governance (https://blog.oter.io/posts/xrd-governance-design-disclosure) – announced 8 Aug 2026, recast 28 Aug as a mirror tally, unreleased Radix DAO posture Second, independent count of the official vote (https://vote.radixdao.org) – no OTER vote moves DAO money OTER (Optimistic Truth Engine, tagline "The truth will out.") is an optimistic oracle built on Radix DLT (https://oter.io) . Any dApp or person can post a verifiable question – an election result, a price level, a real-world event – with a reward for resolving it. A proposer answers and locks a bond behind the answer; if nobody disputes it before a challenge window closes, the answer stands and settles on-chain. Only contested answers go to a vote, decided by staked jurors casting timelock-sealed ballots (https://oter.io) . The design combines sealed-ballot juries, bonded answers, and atomic settlement. OTER is one of two oracle projects recorded on this wiki alongside Religant (/ecosystem/religant) , and is the resolution layer behind Tāhuna (/ecosystem/tahuna) , a prediction-market protocol also building on Radix. For the general pattern of consuming an oracle from a Radix blueprint, see Oracle Integration (/developers/scrypto/08-oracle-integration) in the Scrypto tutorials. How a question settles The protocol documents a five-stage lifecycle, of which most questions only ever traverse the first three. A question is asked with a reward attached; a proposer proposes an answer and locks a bond behind it; a public challenge window opens, during which disputing the answer costs a counter-bond. Where nobody disputes – the design's expected path, and the reason it is called optimistic – the window closes untouched and the answer stands with no vote and no jury. Only a disputed answer reaches the remaining two stages. Staked participants vote using timelock-encrypted ballots, so no ballot can be read while voting is open and no losing vote can be quietly buried after the fact. The verdict then settles on-chain, and the losing bond is slashed in full. Per the project's published specification the slash is split 80% to the winner, 15% to the correct voters, and 5% to the protocol, with voter rewards paid in rUSDC rather than a platform token (https://oter.io) . If a round fails to reach quorum instead, bonds refund and no committed vote is rewarded or slashed. The jury draw and the OTER Beacon The jury for each dispute is drawn from a public randomness beacon rather than chosen by the protocol operator. The project runs the OTER Beacon (https://random.oter.io/) , a drand (https://drand.love) -aligned min-pk BLS12-381 randomness beacon whose output is verifiable natively on Radix. Reading its public info endpoint (https://random.oter.io/info) on 29 July 2026 returns the scheme oter-min-pk-g2-pop – unchained, public keys in G1 and signatures in G2, domain-separated under oter-jury-beacon:v1 – on a 3-second period, with the health endpoint (https://random.oter.io/health) reporting the chain live and current (round 30,835,175, two seconds behind head). The draw itself binds the jury to a beacon round that does not yet exist when ballots lock. Jurors commit timelock-encrypted votes while the round that will seat the jury is already named but unpublished; at reveal time that round's BLS signature is published as one canonical value, the contract verifies the signature on-chain, and the seed is derived as keccak256(signature). Seats are then allocated by keccak256(seed ‖ voter), which the specification says seats roughly 97 of every 100 revealed votes (https://oter.io) . Because the signature cannot be served before its round time, no participant can predict or grind the seed in advance, and none can buy a guaranteed seat. OTER states that it upstreamed the beacon verification into the Radix engine itself (https://oter.io) and describes the beacon as an open public good available to any Radix project, not only to OTER. Protocol parameters The following defaults are published in OTER's own protocol specification (marked rev. 2026-07) and are subject to change by staker governance. They are recorded here as documented, not as independently verified on-ledger behaviour – the oracle is not yet on mainnet. Challenge window 4 hours default, configurable per question Vote cycle 48 hours – 24 h sealed commit, 12 h reveal, 12 h to re-propose and dispute Re-vote latency Next cycle – an escalated question re-enters immediately rather than waiting a full extra round Consensus threshold 70% supermajority of revealed voting power Quorum Exponential moving average, easing in at 5% for the cold start then tracking real participation Voting power √stake – doubling a position buys about 41% more vote, not twice as much Jury seating ~97% of revealed votes seated, drawn from the beacon seed Losing bond Slashed in full – 80% winner / 15% correct voters / 5% protocol, paid in rUSDC Batch size 25 questions per vote cycle Failed round 3 attempts – bonds refund and nobody is slashed, then a time-boxed close as invalid Unstake cooldown 7 days Outcome types Yes / No / Draw, plus DAO governance votes; further types plug in as adapters The square-root curve is the parameter the project argues hardest for. Simulated against a live oracle's real staker distribution, it reduces the top holder's share of voting weight from 24.1% under linear weighting to 3.6% (https://oter.io) , and the top ten holders' combined share from 59.5% to 15.8%. Capital still counts; the claim is that domination does not scale with it. Governance OTER's parameters, question types and even its jury beacon are changed by the same machinery that settles a dispute, rather than by a team key. Any stake-ticket holder can bond a rule change, but the target must already sit on the DAO's allowlist and the exact action is bound into the proposal at creation – it cannot be swapped afterwards. Unlike a question, a proposal gets no optimistic pass-through: every rule change is forced to a vote immediately (https://oter.io) , on the same sealed ballots, the same √stake weighting and the same supermajority. Execution is fail-closed. Only a settled Approve dispatches, replaying exactly the action that was voted on against the bound target, and the proposer's bond returns with a reward. A rejected proposal executes nothing and forfeits the proposer's bond to the voters who turned it down, which is the protocol's answer to rulebook spam. There is no separate governance token and no second electorate – whoever can judge a dispute judges the rules on identical terms – and an administrator can bootstrap the allowlist but never decide a vote. For how Radix approaches on-ledger governance more broadly, see Radix Governance (/contents/tech/core-concepts/radix-governance) . Consumers and use cases Settlement is pull-based: a Radix contract reads the settled outcome inside its own transaction, rather than waiting for an oracle callback or a keeper bot to push it. The project argues this removes a class of failure common to push oracles – there is no queue to stall or front-run, and one settled answer can drive any number of dApps at once. This is the same atomic-composability property that Radix Engine (/contents/tech/core-protocols/radix-engine) provides to asset movements. The documented target applications are prediction markets, parametric cover (releasing a payout once a claim survives the challenge window, with no manual adjuster), cross-dApp settlement of facts including facts about other networks, and price-settled products. For the last of these OTER points at a companion resolver built in the Tāhuna stack that verifies Pyth signed price updates entirely on-chain (https://oter.io) – signer quorum, emitter check and Merkle inclusion proof – settling up/down candle markets deterministically with no dispute round, on the reasoning that a price feed and a dispute game answer different kinds of question. The project also operates OTER PoP (https://idos.oter.io) , a proof-of-personhood component. XRD Governance On 8 August 2026 the project published a design disclosure for OTER XRD Governance (https://blog.oter.io/posts/xrd-governance-design-disclosure) , a voting platform for the Radix Network DAO (/ideas/radix-network-dao-charter) transition built as a client of the oracle rather than as a separate system, and announced it the same day (https://t.me/radix_dlt/997470) in the Radix DLT Telegram. The proposing and voting surface is deliberately unchanged from the Consultation v2 (/ideas/dao-governance-app-consultation-v2) app the DAO already uses: one signature, no deposit and no token lock, voting power counted as XRD held, staked and pooled at the snapshot taken when voting opens, and the same Temperature Check → elevation → Governance Proposal workflow, with elections run under Majority Judgment as the Proposal & Voting Framework (/ideas/dao-proposal-voting-framework) specifies. What the platform changes is what happens once voting closes. The design starts from a constraint the disclosure states plainly and that applies to every platform on the network: the tally cannot be computed on-chain. Voting power depends on balances at a historical snapshot, and a Radix component cannot read historical state – XRD does not report a total supply on-ledger at all – so every governance app, including the one in use today, counts the ballots off-chain and publishes the total. A published result is therefore a statement by whoever ran the count. OTER's answer is to make that statement an oracle question: the tally is emitted as a canonical, hash-pinned document carrying its weight rule, source register, snapshot and counting rule, then posted on-chain as a bonded assertion with a public challenge window. An unchallenged assertion settles; a challenged one costs a matching bond and goes to the same staked jury, sealed timelock ballots and loser-pays slashing that settle any other OTER question. Three components support the claim that the result is checkable rather than merely published. An independent verifier – described as a second implementation in a different language sharing no code with the tally engine – recomputes any published result down to the exact bytes of the document, so a disagreement between the two is mechanical rather than a matter of argument. A keeper that anyone can run recomputes every live assertion and publishes its verdict through a public API; its detection half is stated to need no keys, no funds and no permission, which is the project's answer to the honest-challenger assumption every optimistic system rests on. And a settled Approve on a binding proposal executes its own bound action – a treasury payout, a payment stream, a parameter change – through the governance components after a pre-execution hold fixed into the contract at deployment, with no setter to shorten or disable it. The disclosure also says the security-carrying parameters (the floor on the challenge window, the jury's timing windows, the bounds on the bond-to-value ratio) carry no setter for anyone, and that the operator's remaining powers are enumerated and renounceable. The post is explicit about what it does not claim. The snapshot weighting stays off-chain because the ledger permits nothing else; the optimistic model still assumes one honest challenger per window; and the governance framework itself is pre-ratification and moving, which the platform accommodates by hardcoding none of its numbers. It credits the current DAO app for "the pioneering work of getting DAO governance this far" and names that framework as the standard it measures itself against. None of this is verifiable on-ledger yet: as of 8 August 2026 the platform, the verifier and the full technical disclosure are stated as releasing "within the week", and the material recorded here is the project's own design disclosure rather than observed behaviour. Reception The disclosure closed by inviting “feedback, scepticism, and challenge”, and drew all three the same evening in the channel it was announced in. Matus asked (https://t.me/radix_dlt/997473) who runs the first keepers, what the source of snapshot truth is and how the bonds are calibrated, then followed up (https://t.me/radix_dlt/997477) on the full adversarial model, jury behaviour in failure modes and the upgrade path; Nicolai of Sentura asked (https://t.me/radix_dlt/997475) whether on-chain settlement is confined to a predefined call set or can execute any transaction on the ledger. None of those questions had a published answer by the end of 8 August 2026. The substantive objection came from Daffy, who maintains the DAO governance framework (https://github.com/Shadaffy/radix-dao) , in a point-by-point reply (https://t.me/radix_dlt/997479) the same evening. He accepted what he called the good half – the hash-pinned tally document, the independent verifier and the permissionless keeper – as a genuine improvement that could have been contributed to the existing Consultation app (/ideas/dao-governance-app-consultation-v2) as a pull request rather than rebased onto a new protocol, and said parts of it overlap almost point-for-point with an unpublished result-verification requirements document written for a Majority Judgment election newly added to that app. His objection is to the settlement layer. OTER, he argued, models the risk as the operator lying about the tally; but the mandate is non-discretionary and a tally is a total function of a public record, so the verifier on its own is already the complete answer to that risk. The DAO's controls, on his account, are ex ante and legal rather than ex post and economic, and they sit on the treasury side: a verified invoice, a KYC-verified recipient, multi-signature thresholds written into the Operating Agreement, and signers carrying a duty to refuse an unlawful execution. A correctly tallied but unlawful proposal would still settle Approve and execute itself, because the jury is only ever asked whether the arithmetic was right – and treasury outflows triggered by the verdict of an anonymous, self-selected, bonded jury would place influence over company assets outside the signer structure, outside the compliance gate and outside the arbitration agreement. The provisions that objection rests on are published, and most of them check out. The Asset Lock is real and entrenched: Charter (https://github.com/Shadaffy/radix-dao/blob/master/Charter/charter.md) §10–§11 bar any distribution to members and require remaining assets to pass to a qualifying successor entity on dissolution, and §12.1 places both beyond amendment by any governance proposal at any approval level. The annual BOIR filing is Operating Agreement (https://github.com/Shadaffy/radix-dao/blob/master/Legal/Formation/Operating-Agreement.md) §8.1, under Marshall Islands DAO Act §712; the 25% test is §4.6, which classifies any member above a quarter of eligible voting power as an Ultimate Beneficial Owner and gives them 14 days to complete KYC once they cross it (§8.2); and the multi-signature thresholds are §7.1 – 3-of-5 treasury signers for a standard transaction, 4-of-5 for one classified high-risk. Two details in the reply do not match the published text. Statutory KYC is Article VIII, not Article X, which covers amendments. And the arbitration clause is not an LCIA clause seated in London: §11.1 and the Legal Wrapper (https://github.com/Shadaffy/radix-dao/blob/master/Legal/Policy/Legal-Wrapper-and-Representation.md) both specify the International Arbitration Rules of the ICDR, seated in the Republic of the Marshall Islands, in English, before a sole arbitrator, with Marshall Islands governing law (§11.2). One caveat sits under the whole exchange, and it cuts against both sides of it. The wrapper those gates live in is not operative yet. The Operating Agreement carries a status header reading “Pre-adoption draft – not yet operative” and requires a Governance Process proposal at ≥60% approval and ≥7% quorum to be adopted; the Certificate of Formation (https://github.com/Shadaffy/radix-dao/blob/master/Legal/Formation/Certificate-of-Formation.md) is a working draft awaiting filing with the Marshall Islands Registrar. Both remain open transition work (/ideas/dao-incorporate-duna-llc) . The compliance gates are therefore proposed rather than in force, and so is the platform they are being weighed against – OTER's own release was stated as within the week of 8 August 2026. One further detail is worth recording for whoever revisits this: §6.5 of the same agreement assigns formal determination of a vote's outcome to the RAC (/ecosystem/radix-accountability-council) rather than to the Governance Operator, treats the on-chain record as authoritative for raw vote data and the RAC's published result as authoritative for the outcome, and already provides a veto-challenge window for results said to violate the Charter. Complement, not substitute OTER cut the replacement. On 28 August 2026 the project stopped building a drop-in alternative to the DAO's own voting app, and on 6 September it published the reasoning and a worked example (https://blog.oter.io/posts/complement-not-substitute) : “a vote that self-executes a payout is the thing the Treasury Signers design exists to prevent.” That is the disposition of the objection recorded above. Votes stay on the Consultation App (https://vote.radixdao.org) , money still moves through the five Treasury Signers (/ideas/dao-governance-app-consultation-v2) under caps and a compliance window, and the project states plainly that no OTER vote moves Radix DAO money or stands in for a Radix DAO decision. What is left is a mirror tally: OTER's own count of an official vote's ballots, read from the governance component and its on-ledger voter lists through the public Gateway (/contents/tech/core-protocols/radix-gateway-api) , published as a hash-pinned document. It counts twice. The first leg reproduces the app's own stated weight rule – the one adopted by consultation in February 2026 (/ideas/dao-proposal-voting-framework) : XRD held directly, validator stake units and LSULP at the XRD behind them, and a static allowlist of 68 liquidity positions on Ociswap (/ecosystem/ociswap) , CaviarNine (/ecosystem/caviarnine) and DefiPlaza (/ecosystem/defiplaza) , of which only the XRD side counts – from a copy of the list identified by a version and a hash of its bytes. The second applies the same four weight families under an on-ledger register that moves by a Binding XRD vote rather than an operator edit. The project reports both sets identical today, entry for entry, so on mainnet the two legs reach the same number and the second adds no weight to anyone; agreement on the first leg is the point, since reproducing the official number is what shows OTER read the same ballots. The mainnet poller's target is the one part of this a reader can check without the project's cooperation, and it checks out. The component the post names, component_rdx1czn9hrgd30x742k6jw2e6psj9jlkqvu2cj4hcry60p7f38hxd3k3xt, returns from a pinned Gateway read (/contents/tech/core-protocols/radix-gateway-api#pinned-reads) at state version 557,840,622 as Radix Consultation V2, a component of the Governance blueprint whose own on-ledger description reads “Component that manages voting for Consultation V2”. OTER says it read ten vote entries there on 28 August 2026 – seven Temperature Checks and three Governance Proposals. The worked example is not one of them. Stokenet (/contents/tech/releases/stokenet) has carried no Radix DAO vote since its 29 August 2026 reset and mainnet was halted from 31 August to 11 September 2026 (/contents/history/hyperlane-asset-drain-2026) , so the three ballots the post counts end to end come from a test vote OTER created on its own private Stokenet deployment. Both rules there return 13,728.99 Against and 9,286.73 For – 23,015.72 in total, every source differing by zero, rejected at 40.3% against a 50% bar – in a document naming the state versions it weighed balances at and read ballots at, and hashing to a84efb5c…. The independent verifier (https://github.com/OTER-Labs/radix-tally-verify) , pushed the same day, re-reads the ballots and checks both legs against that hash. Bonding a tally stays optional and is off by default for Temperature Checks; a bonded one carries a floor of 10 units of its bond asset and a challenge window that can be lengthened but never shortened, and a governance request buys itself a window at least as long as the framework's 48-hour pre-execution hold. The post is unusually direct about the limit of that: a bond bounds the cost of lying, not the value of the question, and “a question worth more to an attacker than the total honest stake that turns out to defend it is outside what this mechanism protects” – bond sizing can be revisited, the boundary cannot. The same machinery is offered to any project rather than only to the DAO: a space picks its weight rule once and immutably – XRD, its own fungible, or a membership NFT for an electorate with no token – and each winner of a settled election claims a soulbound seat NFT that expires with the term and can be recalled by the same electorate. The independent verifier The disclosure rests its case on reproducibility: a result is published as a canonical document whose bytes hash to a value posted on-ledger, and the post argues that "you can recompute it" is only worth as much as the tools to do it. It says a verifier — "a complete second implementation, written in a different language, sharing no code with our engine" — was built and open-sourced, and separately lists the verifier among the things releasing "within the week". The artifact is public and predates the post: OTER-Labs/radix-tally-verify (https://github.com/OTER-Labs/radix-tally-verify) , Apache-2.0, created on 4 August 2026 and last pushed on 7 August, the day before the disclosure appeared. The post carries no link to it; the repository's own README describes exactly the design the post claims, on the reasoning that "a verifier that shares an implementation with the thing it verifies agrees with it by construction, including where both are wrong." Being a second implementation by the same organisation, it is independent of the code, not of the party. What it recomputes, from the TypeScript in the repository rather than from the announcement: each voter's weight from Gateway (/contents/tech/core-protocols/radix-gateway-api) historical state at the snapshot the document pins — XRD plus validator stake units at their redemption rate plus round-trip-verified native pool units — then the verdict, by applying the document's own stated quorum, thresholds and seat rule to those weights, and only then the canonical re-serialization and the blake2b-256 hash. The README is explicit that the hash check is "the cheap one" and the first two steps are the point. Arithmetic is a 192-bit fixed-point Decimal with 18 decimal places and truncating division, with no floating point anywhere: an IEEE-754 double carries about 15 to 16 significant decimal digits, and these values carry 18 after the point alone. The part that distinguishes it from a checksum tool is that it grades its own disagreements. Its four exit codes separate a figure difference (the real signal — someone's arithmetic, weights or ballot set is not what they published) from a serialization difference (figures agree, bytes do not — a spec departure, most often a Decimal parsed as a float or keys left in insertion order), and both from unknown, which is what an unreachable Gateway or a pruned state version returns. The stated reason for the third is operational rather than cryptographic: "a verifier that reports infrastructure trouble as a discrepancy trains people to ignore it." One rule in it is checkable against the DAO's own text. The verifier settles a Majority Judgment candidate's grade at the Grade Quantile the document publishes, and records that the quantile "was the median until 2026-08-05". The Radix DAO's Proposal & Voting Framework (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/proposal-and-voting-framework.md) §6.2.4 defines the Grade Quantile as three-fifths, set deliberately to equal the Election Stage 2 approval threshold "so that both mechanisms put the same share-of-turnout test to a candidate", and notes that at one half it would be the median of the literature. Both documents also resolve an exact landing upward, and for the same reason — the comparison at_or_above × denominator ≥ cast × numerator is one a challenger must reproduce without ever dividing, which is why the quantile is carried as a fraction and a decimal is refused as malformed. The verifier recomputes each document under the fraction that document carries rather than under today's, so that a result settled under the older rule does not report as a lie. Status As of July 2026 OTER is pre-launch: oter.io describes the protocol as "Pre-launch · Built on Radix DLT" and offers a mailing list for "mainnet milestones, testnet access, and protocol deep-dives" (https://oter.io/#signup) . The published specification is dated rev. 2026-07. The randomness beacon, by contrast, is already running in production and served a healthy response when checked on 29 July 2026. Tāhuna (/ecosystem/tahuna) is listed as the founding integration and is itself pre-launch, with a testnet targeted for Q3 2026. The project surfaced in the Radix Developer Discussion Telegram in July 2026. On 8 August 2026 the project announced OTER XRD Governance (https://blog.oter.io/posts/xrd-governance-design-disclosure) , a Radix DAO voting platform built on the oracle, with the platform, its independent verifier and a full technical disclosure said to be releasing within the week. That platform was recast on 28 August 2026 (https://blog.oter.io/posts/complement-not-substitute) as a second count of the official DAO vote rather than a replacement for it. As of 6 September 2026 the whole of it runs on one private Stokenet deployment and none of it is on mainnet; the project states that a public Stokenet deployment follows the halt (/contents/history/hyperlane-asset-drain-2026) fix, and a mainnet deploy after that. External Links - oter.io – official site and protocol specification (https://oter.io) - OTER XRD Governance – design disclosure (8 Aug 2026) (https://blog.oter.io/posts/xrd-governance-design-disclosure) - Complement, not substitute – the mirror tally and one vote counted end to end (6 Sep 2026) (https://blog.oter.io/posts/complement-not-substitute) - vote.radixdao.org – the Radix DAO Consultation App the tally mirrors (https://vote.radixdao.org) - random.oter.io – OTER Beacon (live randomness) (https://random.oter.io/) - Beacon info endpoint – public key, scheme, period (https://random.oter.io/info) - Beacon health endpoint – latest round and lag (https://random.oter.io/health) - OTER PoP – proof of personhood (https://idos.oter.io) - drand – the distributed-randomness scheme the beacon aligns with (https://drand.love) - OTER-Labs/radix-tally-verify – the open-source tally verifier (Apache-2.0) (https://github.com/OTER-Labs/radix-tally-verify) Related pages - Tāhuna (/ecosystem/tahuna) – prediction-market protocol resolving on OTER - Religant (/ecosystem/religant) – the earlier oracle effort on Radix - Oracle Integration (/developers/scrypto/08-oracle-integration) – consuming an oracle from a Scrypto blueprint - Radix Governance (/contents/tech/core-concepts/radix-governance) – on-ledger governance across the network ## Leafnode URL: https://radix.wiki/ecosystem/leafnode Updated: 2026-09-12 Summary: Status note, 23 August 2026: Leaf Node deregistered on 10 August 2026 and re-registered on 16 August; it is validating again, ranked 45th of the 100 v… Type XRD staking validator node Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Active — deregistered 10 August 2026, re-registered 16 August 2026 (https://dashboard.radixdlt.com/transaction/txid_rdx1x80208v5xezsyuvh0jydrplt8uwgmsmlpexv634fu3236qr8nfjslysr0y/summary) Founded 2023 Location Alblasserdam, Netherlands (backup in Germany) Validator validator_rdx1swz…n2lv86t (https://dashboard.radixdlt.com/validator/validator_rdx1swzn5hvtut6yq0zxqqsa0wk4rnkfd8wewvnphzrckau22pun2lv86t) Registered Yes — register (https://dashboard.radixdlt.com/transaction/txid_rdx1x80208v5xezsyuvh0jydrplt8uwgmsmlpexv634fu3236qr8nfjslysr0y/summary) at epoch 335461, 16 August 2026 (after an unregister (https://dashboard.radixdlt.com/transaction/txid_rdx16wjjnct0ugaeppqxu40vya4srw7wpjv678832sw5g6gmpwepsqqsqnu97q/summary) at epoch 333697, 10 August 2026) Stake 25,719,752.92 XRD active, rank 45 of 100; a further 8,550,966.92 XRD unstaking (epoch 337470, 23 Aug 2026) Fee 1%, with a 100% fee (https://dashboard.radixdlt.com/transaction/txid_rdx1mh3d3fkltk8fzp3zlumkqewejfhsngvqd7z5eggl6u8srspw9cqs9qq6va/summary) queued for epoch 341223, which the halted ledger has not reached Website leafnode.info (https://www.leafnode.info) (offline, HTTP 503, 10 Aug 2026) Status note, 23 August 2026: Leaf Node deregistered on 10 August 2026 and re-registered on 16 August; it is validating again, ranked 45th of the 100 validators in the active set, with a 100% fee queued for early September and its website still offline. What follows describes the service as it operated; the ledger record is in the two sections below. Leafnode is a Radix validator based in the Netherlands. Radix is a decentralized and secure protocol that enables developers to create scalable decentralized applications (dApps). Validators are nodes that verify transactions and propose new blocks in the Radix network. Stakers, on the other hand, are users who delegate their tokens to validators to help secure the network and receive rewards in return. Leafnode is one of the validators in the Radix network that users can delegate their tokens to. By staking their tokens with Leafnode, users can help secure the Radix network and earn a share of the validator's rewards. The amount of rewards a user can earn depends on various factors, such as the amount of tokens they stake, the duration of the staking period, and the validator's performance. Founder Daan is an enthusiastic Dutch computer science student and a member of the Ociswap (/ecosystem/ociswap) team. He expresses a strong passion for distributed ledger technology, with Radix being his favorite project in the space. Daan runs a world-class Radix validator node for users to safely stake their tokens. Daan highlights some advantages of staking with him, including being an active community member, offering a minimal fee percentage, and allowing users to earn interest on their staked XRD tokens. He actively maintains and monitors the node and has even developed his own solutions, such as a Raspberry Pi-powered dashboard. Benefits Here are some potential benefits of staking with Leafnode: High Performance Leafnode emphasizes the use of high-quality Linux servers that meet or exceed the recommended system specifications by RDX (presumably referring to Radix) works. This indicates that their nodes are designed for optimal performance and reliability. High Uptime Leafnode ensures high uptime by having a secondary Linux server ready to take over if the primary node encounters any issues. Additionally, they use automation tools like Ansible to quickly deploy a new node in case of failure. Monitoring Leafnode uses Grafana for monitoring the performance and uptime of their nodes. They have also designed a Raspberry Pi-powered monitoring dashboard that provides real-time information and will be active 24/7. This commitment to monitoring ensures that the node's status and performance are consistently tracked, allowing for proactive maintenance and issue resolution. Decentralization The website mentions that too much $XRD has been staked to nodes running in American data centers. By running their node in the Dutch city of Alblasserdam and having a backup node in Germany, Leafnode aims to contribute to the decentralization of the network. Security Leafnode places importance on network security and protecting stakers' rewards. They have taken measures such as employing firewalls, implementing 2FA (two-factor authentication), and utilizing DDoS (Distributed Denial of Service) protection to safeguard the validator against potential attacks. Deregistered from the validator set (10 August 2026) Superseded on 16 August 2026 — see the section that follows. The readings below stood on 10 August and are kept as the record of that day. Leaf Node stopped validating on 10 August 2026. Two transactions signed with the validator's owner badge, eleven minutes apart, ended its run: at 08:31:55 UTC (epoch 333695) the owner called update_fee (https://dashboard.radixdlt.com/transaction/txid_rdx19lqdc8m787s2sg4njl3jwcpd9nwqgxxkhx7uhc0j0txztcy5j80sxdxqap/summary) with a new fee factor of 1 — a 100% validator fee — and at 08:43:03 UTC (epoch 333697) called unregister (https://dashboard.radixdlt.com/transaction/txid_rdx16wjjnct0ugaeppqxu40vya4srw7wpjv678832sw5g6gmpwepsqqsqnu97q/summary) . Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 333822 (10 August 2026, 19:05 UTC), the Leaf Node validator (https://dashboard.radixdlt.com/validator/validator_rdx1swzn5hvtut6yq0zxqqsa0wk4rnkfd8wewvnphzrckau22pun2lv86t) 's is_registered flag is false, and the number of registered validators on mainnet has fallen from 188 to 187. The stake did not leave with it. 34,202,706.78 XRD is still delegated to the validator and it still accepts new delegations (accepts_delegated_stake is true), but only registered validators are eligible for the active validator set (/contents/tech/core-concepts/validator-nodes) , so that stake is no longer securing the network or earning staking (/contents/tech/core-concepts/staking) emissions. Holders of the stake units (resource_rdx1th6…aa28jsnr) have to unstake to move it, and the claim NFTs are resource_rdx1nf5…zmuz3j9w. The queued fee change is recorded on-ledger as effective from epoch 337727 — 3,905 epochs after the reading above. The network kept 1,152 epochs between 6 and 10 August 2026, about five minutes each, which puts the 100% fee roughly two weeks out, around 24 August 2026. It is a pending request, not the charged rate: the stored validator_fee_factor is still 0.01, and this page's earlier 1% figure remains the fee until that epoch. The website went the same day: leafnode.info (https://www.leafnode.info) answers HTTP 503 with a DEPLOYMENT_PAUSED body, while the validator's on-ledger info_url and icon_url metadata still point at it. No statement from the operator has been found; the account above is the ledger's. As recently as 6 August 2026 (epoch 332670) the node was registered, held 34,181,988.28 XRD, ranked 38 of 188 registered validators by stake, charged 1% and had recorded 99.95% uptime over the trailing month. This page carried 🟢 Active on that measurement, which was correct when it was taken. Back in the validator set (16 August 2026) Leaf Node returned to the active validator set (/contents/tech/core-concepts/validator-nodes) six days after leaving it. At 11:41:48 UTC on 16 August 2026 (epoch 335,461) the owner badge signed register (https://dashboard.radixdlt.com/transaction/txid_rdx1x80208v5xezsyuvh0jydrplt8uwgmsmlpexv634fu3236qr8nfjslysr0y/summary) , and 83 seconds later it signed update_fee with a fee factor of 0.01 (https://dashboard.radixdlt.com/transaction/txid_rdx1ng4w8mazxqga76e7f4ctv36crfr40tdj9phe7vhmgendj585982sv66jqr/summary) — cancelling the 100% fee the same badge had queued on 10 August. Neither transaction was announced, and leafnode.info (https://www.leafnode.info) has answered HTTP 503 throughout. Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 337,470 (23 August 2026, 11:05 UTC), the Leaf Node validator (https://dashboard.radixdlt.com/validator/validator_rdx1swzn5hvtut6yq0zxqqsa0wk4rnkfd8wewvnphzrckau22pun2lv86t) is registered, is one of the 100 validators in the active set, and ranks 45th by active stake with 25,719,752.92 XRD — 0.5501% of the stake securing the network. Mainnet is back to 188 registered validators. It is validating and earning emissions (/contents/tech/core-concepts/staking) again. Some of the stake did not wait. A further 8,550,966.92 XRD sits in the validator's pending-withdrawal vault, unstaked across three transactions on 11, 14 and 21 August and now serving out the unbonding delay. Active stake plus pending withdrawals still comes to roughly the 34.2 million XRD the validator held on 10 August, so the exit is a quarter of the delegation rather than a run on it — but it is the measurable answer stakers gave to a deregistration notice, and the coins leaving are the ones that read it. The 100% fee, re-armed On 22 August 2026 at 11:52:59 UTC (epoch 337,191) the owner badge queued the 100% fee again (https://dashboard.radixdlt.com/transaction/txid_rdx1mh3d3fkltk8fzp3zlumkqewejfhsngvqd7z5eggl6u8srspw9cqs9qq6va/summary) . The stored validator_fee_factor is still 0.01, so 1% remains the charged rate; the pending request now names epoch 341,223, which at the network's recent pace of roughly five minutes an epoch falls in the first week of September 2026 — about a fortnight later than the epoch 337,727 the 10 August request had named, and which passed without effect once the request was replaced. A 100% validator fee takes the whole of the emission a delegation earns, so it is the standard way an operator closes a validator down without touching anyone's principal: stakers keep their XRD and must unstake to keep earning on it. Queued, cancelled and queued again inside twelve days, it reads as a wind-down that has not settled on a date. The practical consequence for anyone still delegated is unchanged by the reversal — the fee switch is armed, the website is down, and the operator has published nothing. This page's account is the ledger's; no statement from the operator has been found. One detail is worth recording without reading anything into it. The same owner badge — the non-fungible [83853a5d…0793] of the validator owner badge (https://dashboard.radixdlt.com/resource/resource_rdx1nfxxxxxxxxxxvdrwnrxxxxxxxxx004365253834xxxxxxxxxvdrwnr) resource — was proved from account_rdx1697zj… for the August 10 and August 16 transactions and from account_rdx12ykjn… for the one on 22 August, and it is held by the second account today. The badge moved between accounts in that window. Accounts are not people, and an operator moving their own badge to a different account of their own looks exactly like this, so the movement is recorded here as a fact and not as a change of hands. The 100% fee switch, and the window to leave it (12 September 2026) The 100% fee described above is queued for epoch 341,223, and it is still queued. Read from the Radix Gateway (https://mainnet.radixdlt.com/state/entity/details) at 07:49 UTC on 12 September 2026, the validator's validator_fee_change_request carries new_fee_factor 1 with epoch_effective 341,223, its live validator_fee_factor is 0.01, and it is still registered and still accepting delegated stake. For ten days that queue could not move. An epoch ends when rounds are produced, none were being produced, and the counter sat at 339,896 – so an earlier reading of this page recorded the fee change as 1,327 epochs beyond a stopped clock, arriving whenever the network restarted rather than in the first week of September. The clock restarted. The first user transaction after the upgrade moratorium was committed at 11:39:25 UTC on 11 September 2026 (/contents/history/hyperlane-asset-drain-2026) , and epochs have since advanced at the protocol's ordinary cadence: 242 of them in the twenty hours and ten minutes to 07:49 UTC on 12 September, an average of 300.0 seconds each. At that rate epoch 341,223 arrives around 16 September 2026. The interval before a queued fee applies is the window in which a delegator who does not want the new rate unstakes, and unstaking is a transaction the ledger will now accept. The window that was shut for ten days is open, and on current epoch timing it is about four days wide. Every queued fee change on Radix works this way; this one is dated, on the record, and takes the whole reward. ## Hyperlane URL: https://radix.wiki/ecosystem/hyperlane Updated: 2026-09-12 Summary: Hyperlane is a permissionless interoperability protocol that carries messages and token transfers between blockchains, built by Abacus Works . Its dis… Type Permissionless interchain messaging protocol and token bridge Developer Abacus Works, Inc. (https://www.hyperlane.xyz) Radix integration announced 11 August 2025 (https://www.radixdlt.com/blog/hyperlane-integrates-radix-permissionless-bridge-to-150-chains-coming-soon) Live on Radix mainnet 5 September 2025 (https://www.radixdlt.com/blog/hyperlane-is-live) Radix Hyperlane domain 1633970780 Bridged assets hUSDC, hUSDT, hETH, hWBTC, hSOL, hBNB Audit Zellic (https://github.com/Zellic/publications/blob/6b0207586e075d5d1937d5cad23ac5ef79f75805/Hyperlane%20-%20Radix%20-%20Zellic%20Audit%20Report.pdf) , 15–22 August 2025 Source hyperlane-radix (https://github.com/hyperlane-xyz/hyperlane-radix) , Apache-2.0 Position on Radix All six routes were emptied in the drain of 31 August 2026 (/contents/history/hyperlane-asset-drain-2026) , and none has minted or burned since; Radix mainnet was halted from 21:19 UTC that day until 11 September 2026 Hyperlane is a permissionless interoperability protocol that carries messages and token transfers between blockchains, built by Abacus Works (https://www.hyperlane.xyz) . Its distinguishing property is that it needs nobody's approval: any chain can deploy it, and any developer can open a route on top of it. It went live on Radix mainnet on 5 September 2025 (https://www.radixdlt.com/blog/hyperlane-is-live) , and until August 2026 it was the route by which USDC, USDT, ETH, WBTC, SOL and BNB reached the network. Radix is not an EVM chain, so the integration was not a configuration exercise. Hyperlane's node software carries a separate implementation per chain family, and the eight that exist (https://github.com/hyperlane-xyz/hyperlane-monorepo/tree/main/rust/main/chains) are Ethereum, Cosmos, Sealevel, Starknet, Aleo, Fuel, Tron and Radix. The on-ledger half is a Scrypto codebase of its own, hyperlane-radix (https://github.com/hyperlane-xyz/hyperlane-radix) , published under Apache-2.0 and audited by Zellic (https://www.zellic.io/) before deployment. On 31 August 2026 every asset Hyperlane had issued on Radix was drained in under an hour and bridged out. The flaw was not in Hyperlane. It was in the Radix Engine (/contents/tech/core-protocols/radix-engine) beneath it, and the warp routes were the exit rather than the opening. That incident has its own page (/contents/history/hyperlane-asset-drain-2026) . How it works Hyperlane's core is a mailbox: a contract on each chain that accepts an outgoing message and delivers incoming ones. Off-chain relayers and validators (https://docs.hyperlane.xyz/docs/intro) carry the message between mailboxes, and what decides whether a delivered message is believed is an Interchain Security Module, an ISM. The ISM is the part Hyperlane treats as configurable: an application picks the validator set and the quorum it wants rather than inheriting a single bridge's trust assumptions. Each chain is addressed by a numeric domain. Radix's is 1633970780, which the registry derives, and comments in place, from the ASCII of the word "radix" reduced modulo 231−1. Token bridging is an application built on that base, called a warp route. A route names one contract per chain and gives each a type. On the chain the asset is native to, the contract is collateral: it holds the real token. On every other chain it is synthetic: it mints a local token when a message arrives and burns it when one is sent. Radix always holds the synthetic side, which is why the bridged assets appear on the ledger as ordinary Radix resources with an h prefix and why their supply on Radix falls to zero when everything is bridged out. Nothing is held in escrow on Radix; the backing sits on Ethereum, Arbitrum, Base, BNB Chain and Solana. The Hyperlane registry (https://github.com/hyperlane-xyz/hyperlane-registry/tree/main/chains/radix) publishes the deployed Radix components in the open: the mailbox at component_rdx1cpcq2wcs8zmpjanjf5ek76y4wttdxswnyfcuhynz4zmhjfjxqfsg9z, an interchain gas paymaster, a default ISM, a merkle-tree hook and a validator-announce component, all deployed by Abacus Works. The Radix integration The Foundation announced the integration on 11 August 2025 (https://www.radixdlt.com/blog/hyperlane-integrates-radix-permissionless-bridge-to-150-chains-coming-soon) , describing Hyperlane as having processed "over $8 billion of asset transfers and 10m+ crosschain messages" and promising bridging to more than 150 chains. The repository had been opened on 10 July 2025. Zellic assessed the code from 15 to 22 August 2025 and the report (https://github.com/Zellic/publications/blob/6b0207586e075d5d1937d5cad23ac5ef79f75805/Hyperlane%20-%20Radix%20-%20Zellic%20Audit%20Report.pdf) is published. Mainnet launch followed on 5 September 2025 with four assets (USDC, USDT, wBTC, ETH) reachable from Ethereum, Arbitrum, Base and BNB Chain; SOL and BNB routes came later. Two things about the deployment are unusually legible for a bridge. The blueprints are built deterministically (https://docs.radixdlt.com/docs/scrypto-builder) inside a GitHub Action, so the package on the ledger can be reproduced from the tagged source rather than taken on trust; the README names package_rdx1pk3ldj3ktxuw6sv5txspjt2a8s42c7xxcn6wnf5yuytdrcqhpflfkc for the mailbox, ISMs and gas paymaster at v1.0.0 and package_rdx1pkzmcj4mtal34ddx9jrt8um6u3yqheqpfvcj4s0ulmgyt094fw0jzh for the warp tokens at v1.1.0. And every route's configuration lives in the public registry rather than in a company's private deployment notes. Two front ends served the same routes: Astrolescent (/ecosystem/astrolescent) , the Radix-native one, and Hyperlane Nexus (https://nexus.hyperlane.xyz/) , the protocol's own reference application. Being permissionless cuts both ways for the front end: Hyperlane did not share its fees with the front ends (https://t.me/radix_dlt/1001809) that carried its routes, which Astrolescent's operator gave on 3 September 2026 as one reason the bridge never earned what he had hoped. The last commit to hyperlane-radix landed on 1 October 2025, which is what a bridge integration looks like when it is finished rather than abandoned. The bridged assets Six resources were issued by Hyperlane warp routes on Radix. Each is the synthetic side of a route whose collateral sits elsewhere, and each supply figure below was read at epoch 339,871 on 31 August 2026, after the drain. Asset Backed by Decimals Supply after 31 August 2026 hUSDC (https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) USDC on Ethereum, Arbitrum, Base and Solana 6 1,092.793964 hUSDT (https://dashboard.radixdlt.com/resource/resource_rdx1th4v03gezwgzkuma6p38lnum8ww8t4ds9nvcrkr2p9ft6kxx3kxvhe) USDT on Ethereum 6 0.036292 hETH (https://dashboard.radixdlt.com/resource/resource_rdx1th09yvv7tgsrv708ffsgqjjf2mhy84mscmj5jwu4g670fh3e5zgef0) ETH on Ethereum 18 0.010278 hWBTC (https://dashboard.radixdlt.com/resource/resource_rdx1t58kkcqdz0mavfz98m98qh9m4jexyl9tacsvlhns6yxs4r6hrm5re5) WBTC on Ethereum 8 0.005600 hSOL (https://dashboard.radixdlt.com/resource/resource_rdx1t5ljlq97xfcewcdjxsqld89443fchqg96xv8a8k8gdftdycy9haxpx) SOL on Solana 9 0.136338 hBNB (https://dashboard.radixdlt.com/resource/resource_rdx1t4et4jddp2fdupr00k83ct9jpnkgewply42l5098ztjkfvjfedvjva) BNB on BNB Chain 18 0.002105 None of the six carries a recall or freeze authority. Read on the ledger, hUSDC (https://dashboard.radixdlt.com/resource/resource_rdx1thxj9m87sn5cc9ehgp9qxp6vzeqxtce90xm5cp33373tclyp4et4gv) reports recaller and freezer both deny_all with rules_locked true, so no party can claw the token back or immobilise it and no party can grant themselves that power later. This is deliberate and it follows from what a warp route is. The bridge's badge must be able to mint and burn, because that is how the route tracks its collateral; anything beyond that would let the issuer seize a user's balance. The trade is symmetric, and August 2026 collected the other half of it: the assets could not be recalled out of anyone's account, and they could not be recalled back either. The August 2026 drain Between 16:02 and 16:58 UTC on 31 August 2026, twenty-six transactions emptied all six resources out of user accounts and dApp liquidity pools and bridged the proceeds out over Hyperlane's own warp routes to a single Ethereum account. 458,914.89 hUSDC and 72,420.38 hUSDT left, alongside the four non-stable assets, and each transaction paid the ordinary 500 XRD bridge fee. The full ledger account is on Hyperlane Asset Drain and Network Halt (August 2026) (/contents/history/hyperlane-asset-drain-2026) . The distinction that matters for this page is where the flaw was. The transactions did not exploit a warp route, forge a Hyperlane message or defeat an ISM; the bridging half of each transaction was a legitimate burn-and-release that the route was built to perform. What let the attacker reach other people's vaults in the first place was a reference check in the Radix Engine (/contents/tech/core-protocols/radix-engine) , stated as the root cause that evening by the Foundation and the Radix Accountability Council (https://t.me/RadixAccountabilityCouncil/925) . Any resource on Radix was in scope, wrapped or native. The bridged assets went first because they were the ones with somewhere to go. Node runners halted Radix mainnet at 21:19 UTC the same evening, and it stayed down for ten days. The first user transaction after the restart was committed at 11:39:25 UTC on 11 September 2026, at epoch 339,898. Hyperlane's routes are intact and the protocol continues to operate on its other chains; on Radix they have nothing to move. Read from the Radix Gateway (https://mainnet.radixdlt.com/state/entity/details) at state version 557,909,564 on 12 September 2026, twenty hours after transactions resumed, every one of the six supplies stands exactly where the drain left it: 1,092.793964 hUSDC, 0.036292 hUSDT, 0.010278271499053527 hETH, 0.00559963 hWBTC, 0.13633755 hSOL and 0.002104956585023754 hBNB. Nothing has been minted or burned through a Radix warp route since the network came back. External Links - hyperlane.xyz (https://www.hyperlane.xyz) – the protocol's site - Hyperlane documentation (https://docs.hyperlane.xyz/docs/intro) – mailboxes, ISMs, hooks and warp routes - hyperlane-radix (https://github.com/hyperlane-xyz/hyperlane-radix) – the Scrypto implementation, deployed packages and audit - Radix in the Hyperlane registry (https://github.com/hyperlane-xyz/hyperlane-registry/tree/main/chains/radix) – domain id, deployed components, gateway and explorer entries - Zellic audit report (https://github.com/Zellic/publications/blob/6b0207586e075d5d1937d5cad23ac5ef79f75805/Hyperlane%20-%20Radix%20-%20Zellic%20Audit%20Report.pdf) – Hyperlane on Radix, August 2025 - Hyperlane Explorer (https://explorer.hyperlane.xyz/) – interchain messages by origin and destination domain - Hyperlane Nexus (https://nexus.hyperlane.xyz/) – the protocol's own bridging front end ## Conflict of Interest URL: https://radix.wiki/policy/conflict-of-interest Updated: 2026-09-12 Summary: A conflict of interest (COI) exists when a contributor has an external relationship to a subject – employment, founding, funding, token holdings, or a… Policy Conflict of interest (COI) Type Conduct policy Derived from Neutral point of view (/policy/neutral-point-of-view) Applies to All articles; most often Ecosystem (/ecosystem) project pages Enforcement Conflict of interest notice banner; attribution; sourcing Adopted 31 July 2026 A conflict of interest (COI) exists when a contributor has an external relationship to a subject – employment, founding, funding, token holdings, or an official role – that could reasonably be expected to influence how they write about it. [1] (#ref-1) A conflict is a fact about a contributor's position, not an accusation of bad faith: most COI editing on a wiki is done by people who simply know the subject best. RADIX Wiki is open to wallet-authenticated editors and documents a live ecosystem, so COI editing is expected rather than exceptional. This policy sets out where conflicts arise, what a conflicted editor should do, and how an article that has drifted is marked. Where conflicts arise here The Ecosystem (/ecosystem) section is the main exposure: it documents live projects, and the people best placed to keep a project page accurate are usually building that project. Neutral point of view (/policy/neutral-point-of-view) already names this as a structural conflict. The same applies to: - Project and token pages – written or corrected by a founder, contributor, or paid contractor. - Validator and node-runner pages – where the subject competes for delegated stake. - Pages about a contributor’s own work – where the editor is the author, maintainer or operator of the thing the page documents. This wiki no longer keeps standalone biographies of living contributors, but their work has pages, and the conflict travels with the work. - Financial position – holding, or having sold, an asset a page discusses. Disclosure matters most where a page touches supply, distribution, or treasury. Coverage of a project is decided by notability (/policy/notability) , not by who is willing to write it. A conflicted editor cannot create notability for a subject by writing about it at length. What a conflicted editor should do - Disclose. State the relationship in the edit's revision message, and on the article's discussion thread for anything more than a typo fix. [2] (#ref-2) The full revision history of every page is public. - Contribute facts, not framing. Corrections of dates, addresses, versions, and broken links are the most valuable COI edits and are welcome without ceremony. - Cite independently. A claim about traction, adoption, or performance needs a source that is not the subject's own marketing – see verifiability (/policy/verifiability) . The project's repository, on-chain state, and public filings are primary sources and are fine; a press release describing itself as a milestone is not. - Do not remove sourced criticism or unfavourable but verifiable facts – a dormant status, a closed product, a failed audit – from a page about yourself or your project. - Propose, don't rewrite. For a contested change to a page about your own project, open a discussion thread and let an unconflicted editor make the call. Undisclosed promotional editing is the failure mode this policy exists to catch. Disclosed COI editing that sticks to sourced fact is normal and useful. Marking an affected article When an article appears to have been shaped by an undisclosed connection to its subject, add a Conflict of interest notice banner to the top of the page rather than blanking it. The banner reads: "A major contributor to this article may have a close connection with its subject. It may need additional review for a neutral point of view." Where the problem is the writing rather than the authorship, the Written like an advertisement banner is the better fit. The full set of maintenance banners is catalogued in verifiability (/policy/verifiability) . Banners are a request for review, not a verdict. Remove one once the article has been rewritten to neutral, sourced prose. How this has worked here This policy was adopted on 31 July 2026 into a wiki whose largest section had already been written by a conflicted contributor, and the record is public enough to state plainly. Of the 151 pages under Ecosystem (/ecosystem) , 111 arrived in a single import inside six seconds on 6 February 2026 from the account ShardSpace Admin, each carrying the same revision message: Imported from Notion export. ShardSpace is an asset-management dApp the directory itself lists, so one of the 111 pages is its own (/ecosystem/shardspace) and another is Avaunt (/ecosystem/avaunt-staking) , the staking business its founder also runs. That is the structural conflict described above, at the scale of three quarters of a section, and the account name and the import message are the disclosure. The three things this policy asks of a conflicted editor have a thinner record. All four counts below were re-measured on 12 September 2026; two of them have moved and two have not. - Nobody has disclosed in a revision message. Across 3,553 revisions on 376 pages, written by the ten accounts that have ever saved one, no message states the writer's relationship to the subject. The only disclosures on record describe someone else's: a project's own governance disclosure, a validator's fee change. - The conflict-of-interest banner has never been placed. Five notice banners exist on the entire wiki. Three are Written like an advertisement and all three sit on imported ecosystem pages; the other two are Stub. The COI variant is offered in the editor and has been used zero times, on any page, by anyone. - The discussion route is unused. Propose, don't rewrite sends a contested change to an article's discussion thread. The wiki holds four comments in its lifetime, three of them on the DAO Charter (/ideas/radix-network-dao-charter) card, and the most recent was posted in April 2026. The cause is arithmetic rather than reluctance. Of the 2,340 revisions saved in the last 90 days, 2,319 come from the maintenance account – 99.1 per cent, a share that has risen in every re-count – so a banner is a request for review addressed to the same pass coming round again, and that pass fixes in place instead. A policy written for many editors is being enforced by one. Which leaves the cheapest instruction on the list as the one that works today. A contributor who wants their project's page to be right can correct the facts, cite something that is not their own site, and name the relationship in the revision message. The history is public and permanent, so that disclosure costs nothing to make and settles the question for every reader who comes after. See also - Verifiability (/policy/verifiability) - Neutral point of view (/policy/neutral-point-of-view) - No original research (/policy/no-original-research) - Notability (/policy/notability) - Freshness (/policy/freshness) - Editorial notices (/policy/editorial-notices) References: 1. Wikipedia – Wikipedia:Conflict of interest (https://en.wikipedia.org/wiki/Wikipedia:Conflict_of_interest) 2. Wikipedia – Wikipedia:Paid-contribution disclosure (https://en.wikipedia.org/wiki/Wikipedia:Paid-contribution_disclosure) ## hyperscale-rs URL: https://radix.wiki/contents/tech/research/hyperscale-rs Updated: 2026-09-12 Summary: hyperscale-rs is a community-built Rust implementation of the Hyperscale consensus protocol for the Radix DLT ecosystem, and the leading candidate to… hyperscale-rs Type Consensus Protocol Implementation Language Rust Status Milestone 1 (validator lifecycle and dynamic topology) reported "done and dusted" (https://t.me/hyperscale_rs/10474) on 7 August 2026. Milestone 2 opened the same week; the project's Weekly #13 (https://t.me/hyperscale_rs/10531) (3–9 August) reports 246 commits and heads them "one engine, no Radix leftovers", "cross-shard settlement finds its final shape" and "fees and gas budgeting arrive". Remaining stack work is the gateway and desktop validator (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) Execution layer The purpose-built hyperscalers/hyperscale-vm (https://github.com/hyperscalers/hyperscale-vm) (created 30 July 2026; 133 commits, all by the lead developer), consumed as the vm/ git submodule. The Radix Engine (/contents/tech/core-protocols/radix-engine) is no longer in the workspace — the Cargo manifest (https://github.com/hyperscalers/hyperscale-rs/blob/main/Cargo.toml) declares seven hyperscale-vm-* path crates and no Radix dependency of any kind Crates 33 (Cargo workspace), plus the seven VM crates in the vm/ submodule Commits 2,835 on main, of which 2,752 are the lead developer's; six contributors in total (read 10 August 2026) Lead flightofthefox ( GitHub (https://github.com/flightofthefox) , proven.network (https://proven.network) ) GitHub hyperscalers/hyperscale-rs (https://github.com/hyperscalers/hyperscale-rs) Docs hyperscale.rs (https://hyperscale.rs) Telegram t.me/hyperscale_rs (https://t.me/hyperscale_rs) (451 members) Stars / Forks 28 / 14 Contributors 6 Formal models 9 Quint (https://quint-lang.org/) specs checked with Apalache, against a 75-property invariant register Licence Dual MIT (https://github.com/hyperscalers/hyperscale-rs/blob/main/LICENSE-MIT) or Apache-2.0 (https://github.com/hyperscalers/hyperscale-rs/blob/main/LICENSE-APACHE) , at the user's option, added 7 August 2026 (https://github.com/hyperscalers/hyperscale-rs/commit/91db7add4a917d8bf382b6b2a250577983e57cff) . Unlicensed before that date Platforms Linux (x86_64), macOS (ARM64) Introduction hyperscale-rs is a community-built Rust implementation (https://github.com/hyperscalers/hyperscale-rs) of the Hyperscale consensus protocol for the Radix DLT ecosystem, and the leading candidate to deliver Xi'an (/contents/tech/releases/radix-mainnet-xian) – the sharded consensus layer intended to make Radix linearly scalable. It is led by flightofthefox of proven.network (https://proven.network) and was opened for public review in late 2025. A formal RFC for delivering Xi'an (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) went to the Radix governance forum on 20 April 2026 with an 18-month mainnet target; a community consultation approved Milestone 1 funding in May, which the Radix Foundation agreed to pay directly rather than wait for the community DAO to be constituted. Milestone 1 – dynamic topology ran from mid-May 2026 and was reported complete on 7 August 2026 (https://t.me/hyperscale_rs/10474) , at which point development moved wholesale onto the purpose-built execution layer. The project diverges sharply from both the original Cerberus design and the Foundation's Hyperscale reference implementation. As the lead developer put it: "It's very different and throws out almost all designs from both Cerberus and the original Hyperscale repo... which is probably surprising to people if they think this is only a rust port." In a May 2026 discussion he was blunter, stating that "Hyperscale never really used Cerberus" and characterising Cerberus itself as "never a fully thought through design... more like a vague beginnings of an idea." Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) remains the consensus securing the current Babylon mainnet as a single, unsharded instance, and its sharded form was peer-reviewed (https://www.radixdlt.com/blog/cerberus-consensus-peer-reviewed) (Journal of Systems Research, 2023). Xi'an, however, does not implement Cerberus at all – its per-shard consensus is a HotStuff-2–derived two-chain commit and its control plane is a leaderless prefix-consensus beacon chain. Community members have accordingly argued that Radix's public materials should stop framing the network's scalability around Cerberus. Background: Hyperscale & Xi'an Radix's long-term roadmap centres on linear scalability – increasing throughput proportionally by adding shards. The Hyperscale Alpha consensus mechanism (https://radixecosystem.com/news/hyperscale-alpha-part-i-the-inception-of-a-hybrid-consensus-mechanism-the-radix-blog-radix-dlt) (formerly Cassandra) was Radix's approach to that problem, combining principles from Nakamoto consensus and classical Byzantine fault-tolerant protocols. In public testing, the Foundation's reference implementation sustained over 500,000 transactions per second (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) with peaks above 700,000 TPS across more than 590 participating nodes, and private tests scaled linearly from roughly 250,000 TPS on 64 shards to 500,000 on 128. Those tests used very small per-shard committees, on the lead developer's assessment; hyperscale-rs targets meaningful committee sizes of around 100 validators per shard, which changes the design space fundamentally – at that size the older design's inter-shard messaging would saturate the bandwidth of a single data centre at a fraction of the throughput. The Xi'an production track (https://www.radixdlt.com/blog/radix-labs-roadmap---to-hyperscale-and-beyond) carries this into a production network candidate. After the interim Hyperscale phase closed (https://www.radixdlt.com/blog/interim-hyperscale-closing-the-chapter) in February 2026, hyperscale-rs emerged as the leading community-led candidate. Architecture hyperscale-rs is a pure consensus layer (https://github.com/hyperscalers/hyperscale-rs) , with no I/O, no locks and no async code in the consensus core, which makes deterministic simulation testing a first-class design principle. The codebase systematically pairs production and simulation backends behind common traits – network-libp2p with network-memory, storage-rocksdb with storage-memory, dispatch-pooled with dispatch-sync, crypto-bls with crypto-mock – so the same consensus code runs against real infrastructure or inside a harness that injects faults, partitions and adversarial timing. Three Layers and One Clock What is loosely called "the consensus" is three separate mechanisms (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/01-consensus-layers.md) . Shard consensus decides in what order transactions run: one independent HotStuff-2 chain per shard, running concurrently and asynchronously with every other shard, which is where the linear scaling comes from. Execution consensus decides what those transactions did: after a block commits, its transactions execute and the committee votes on the outcome, 2f+1 matching votes forming an execution certificate. Separating the two is what makes cross-shard atomicity tractable – a shard can commit to running a transaction whose inputs live on four other shards without stalling its own consensus on their progress. Beacon consensus decides who governs which shard and when; it never sees a transaction. Holding the three together is a clock. Every shard quorum certificate carries a weighted timestamp: each voter's clock reading, clamped no earlier than the parent certificate's timestamp, averaged across the quorum. Byzantine voters cannot drag it backwards at all, forward skew is capped, and a timestamp implausibly far ahead of a replica's own clock is rejected wherever an untrusted certificate enters chain state. Every committee lookup in the system is then the same query against this ownerless clock – schedule.at(weighted_timestamp) – and a block's committee keys on its parent's anchor, which is what makes the committee resolvable before the block exists, from a header every replica already holds and reads identically. Schedules freeze one epoch ahead with no grace interval in which two committees are simultaneously acceptable. Dozens of shard chains running at their own speeds and one slow beacon chain therefore agree on who is in charge of what, when, without synchronised clocks. Consensus Mechanism Per-shard consensus is a two-chain commit derived from HotStuff-2, with: - Optimistic pipelining – proposers can submit new blocks immediately after quorum certificate (QC) formation, without waiting for the previous block to be fully committed - Round-contiguous commit – a block commits only when a QC forms for a child at exactly round + 1; a QC on its own certifies availability, not commitment, and sibling QCs at one height may exist where sibling commits cannot - Decoupled execution and consensus – transactions can start at block height N and finalise at N+1 or later, so execution need not occur before voting on a block. Durable persistence is batched into a single fsync per block and execution moved off the consensus dispatch pool Cross-Shard Commitment Without a Coordinator Hyperscale gives a transaction touching several shards the same terminal outcome everywhere, or aborts it everywhere. The mechanism is often described as two-phase commit, and the project's own atomic-commitment document (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/04-atomic-commitment.md) opens by rejecting the comparison: all three defining features of 2PC are absent. There is no coordinator – the protocol is symmetric across shards, so the coordinator-failure blocking problem has no analogue. There are no votes on the outcome – the result is a deterministic function of committed chain content, and certificates attest an outcome every honest replica has already computed rather than choosing one. And a participant is not a node that can fail but a BFT-replicated committee. The stated lineage is deterministic databases (https://www.cs.umd.edu/~abadi/papers/calvin-sigmod12.pdf) , where determinism replaces commit-time agreement. The pipeline runs in three stages. Every transaction declares up front the global objects it reads and writes, which fixes the participating shards, bounds what execution may write, and allows conflicts to be analysed without executing anything. A source shard commits the transaction and its proposer broadcasts provisions – the substate values each destination needs, under a merkle multiproof against the source block's quorum-attested state root. A provision is therefore a proof about a committed remote block rather than a message from a node: the destination trusts only the source quorum, which removes the single point of failure on the proposer and replaces N-to-M provisioning with one bundle per source block per destination shard. Destinations group provisioned transactions into waves, execute each once over merged local and provisioned state, and 2f+1 matching votes on the wave's receipt root form an execution certificate carrying a per-transaction outcome vector. A transaction succeeds only with success from every participating shard: abort is dominant, success unanimous. Liveness rests on a deadline rather than on any participant recovering. Each wave carries a timeout anchored on BFT-attested time, and a wave not fully provisioned when it expires aborts in its entirety on every participant, so a permanently lost provision terminates the transaction instead of stalling it. The design set documents its own interim weakness plainly: substate values are proven into the attested state root, but the ownership map accompanying them is attested only at transaction-hash granularity, leaving a bounded window for a Byzantine source committee member to push bogus ownership claims. Because both shards apply identical merge rules to identical bytes the result is a deterministic abort rather than divergent state – a liveness cost, not a safety one – and committing ownership into the attested provision leaves is the planned hardening. How much of Cerberus's emergent consensus survives was put to the project's Telegram channel on 31 July 2026. The answer given there – that a validator independently derives which shards and nodes are involved by folding the beacon chain, after which “no voting happens between the shards, all shards execute and exchange proof of their execution” (https://t.me/hyperscale_rs/10312) – drew the lead developer's agreement and his reason: “braiding is a terrible idea. makes shards co-dependent on each other for liveness” (https://t.me/hyperscale_rs/10314) . Two days later he added that dropping it had never been his call: the original Java Hyperscale did not braid either, since “dan replaced it with having an execution process which is async to consensus, and hs-rs continues this” (https://t.me/hyperscale_rs/10351) – a posture he notes almost every sharded chain has adopted, because it makes consensus liveness failures non-contagious. A down counterparty shard times out the transactions that touch it without impairing any other shard's ability to keep building blocks. One State Tree Underneath all of this is one global, versioned binary Jellyfish Merkle Tree (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/03-state-and-sync.md) over a 256-bit keyspace, hashed with Blake3 (https://github.com/BLAKE3-team/BLAKE3) , in which a shard simply is a prefix subtree. Engine-internal objects such as vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) are keyed under their owning account's prefix, so an account's assets never scatter across shards, resharding reduces to a tree operation, and the same tree supplies the per-block commitment that provisioning proofs are checked against. Which shard a substate key belongs to therefore falls out of the beacon's shard trie rather than being fixed in advance. The lead developer rejects the framing that state is "pre-sharded" – an idea he calls incoherent (https://t.me/hyperscale_rs/10358) , and blames the Cerberus paper for encouraging it by using "shards" for what are really keys. Given agreement on which splits and merges have occurred, mapping a key to its shard is arithmetic on the trie – unsplit, every key sits on the root shard; after one split the low half of the keyspace sits on one shard and the high half on the other – which he calls "trivial to the point of not being noteworthy at all." The hard problem is the one above it, knowing in advance which keys a transaction will touch, and that is a question about the execution layer. Fault Model and Committees Each shard runs a committee on the n = 3f+1 model with a strict two-thirds quorum – around 100 validators in the project's own discussion, 128 seats at the operating point the security analysis (https://github.com/hyperscalers/hyperscale-rs/blob/main/specs/committee_security.md) prices. Voting is one seat, one vote: stake is an admission gate deciding who may hold a seat, never a weight on the vote. The threat model (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/05-byzantine-safety.md) is candid about what sharding (/contents/tech/core-concepts/sharding) costs. A single chain's safety is a hard threshold – intact below a third of stake, gone above – whereas sharded safety is a probability curve rising smoothly with pool corruption, because an adversary attacks not the average committee but the worst one, and one lucky shard suffices. The goal is stated as security competitive with an unsharded BFT chain while scaling far beyond one, explicitly "not safer than one", and converts into a pool-hygiene requirement: at 128-seat committees the pool must stay under roughly 13% corrupt seats to sit in the guaranteed tier, with roughly 40% the bound an unsteered draw tolerates before a single committee reaching unilateral control stops being improbable. Corruption is treated as three tiers. Below f+1 corrupt seats agreement is unconditional – the classical BFT regime, and the only band the word "safe" is applied to. From f+1 to 2f the arguments lapse: withholding halts the shard, which the beacon detects and undoes with a full re-draw of every seat, and a fork becomes possible although every route to one runs through self-proving double-signatures. At 2f+1 the committee has unilateral control, nothing self-proving ever exists, and the documentation states outright that there is no recovery and the design does not pretend one exists. Cross-shard trust rests only on attested artifacts – headers by that shard's certificates under the time-resolved committee, provisions by merkle proof against those headers, results by execution certificates: never a node, only a quorum, and never a bare certificate but a commit proof. Design Documentation and Machine-Checked Models In early July 2026 the project published a structured design-documentation set (https://github.com/hyperscalers/hyperscale-rs/tree/main/docs) – nine numbered documents, mirrored as named essays on hyperscale.rs (https://hyperscale.rs) , running from a system overview through the consensus layers, dynamic sharding, state and sync, atomic commitment, Byzantine safety, resource (/contents/tech/core-concepts/resources) economics and determinism. It closes with an invariant register (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/08-invariants.md) consolidating the protocol's safety and liveness properties under stable INV-* identifiers – 75 entries across eight families, ordered dependency-first as a verification programme. The register is not decorative. A parallel specs/ tree (https://github.com/hyperscalers/hyperscale-rs/tree/main/specs) carries nine models written in Quint (https://quint-lang.org/) and checked with Apalache, each citing the INV-* identifiers it verifies: the weighted-time clock, shard consensus, atomic commitment, straddler settlement, beacon consensus, the reshape lifecycle, shard recovery, the witness fold and the reshape handoff. They compose by abstraction – each takes the earlier models' verified properties as axioms, and no model contains the whole system. Two rules make it more than a badge. Every model ships a deliberately broken twin whose counterexample must be reachable, on the reasoning that a checker which has never produced a counterexample proves nothing; and transitions are transcribed from the code, not the documents, every modelled rule naming its implementing crate and function, because a model written from prose would only verify the prose. The models find real defects and the project publishes them. The most consequential open one is finding G-1: in the f+1-to-2f recovery band the certified re-bind's one-window tolerance is calibrated for an adversarial minority, but a retained committee in that band is beyond f – so its corrupt majority can drag the quorum's weighted-time average low enough to escape the re-bind, letting a replica admit an orphan commit past the halted tip. It is published as an adjudicated finding with its counterexample, not as a footnote. Dynamic Topology and the Beacon Chain Milestone 1 of the Xi'an RFC (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) is the validator lifecycle and dynamic-topology layer – the parts of the design earlier reference implementations left untested, and described by the lead developer as "far and away the most sophisticated sharded L1 design ever implemented." The Beacon Chain A dedicated beacon crate implements a global beacon chain – a slow-ticking control-plane chain, run by all validators, that roots trust for every shard. It tracks which shards exist, which committee is responsible for each, and which portion of the state space each owns, so any node can validate whether a cross-shard message represents a genuine quorum. It carries no user transactions and grows very slowly (estimated under 100 MB per year); a new validator can verify roughly three years of beacon history in about five minutes, and node software ships with embedded checkpoints so joiners sync from a recent point rather than genesis. Consensus on it uses Strong Prefix Consensus, a leaderless BFT design ( Prefix Consensus for Censorship-Resistant BFT (https://arxiv.org/abs/2602.02892) ) scaled to thousands of participants with VRF sortition sampling a small committee per epoch. Each member proposes its own view of the shard headers at the epoch boundary with a verifiable reveal, all proposals merge into a vector, and a few voting rounds converge on their common prefix – divergent inputs cannot produce conflicting decisions, only a shorter prefix. Because headers are self-authenticating via their quorum certificates, a Byzantine majority can neither forge headers nor drop an honest member's proposal, so a single honest member keeps the chain fair. The state machine was prototyped in a separate repository, POLARIS, then integrated. What that committee produces is only a proposal. Every non-genesis beacon block commits through pool ratification – a two-phase prevote-and-precommit vote over block hashes by the whole serving validator pool, not the sampled committee. That separation is the safety argument: a committee draw landing entirely Byzantine can certify content but never commit it, and a wedged committee is skipped by the pool without assistance. The price is stated as plainly as the benefit – commits need a pool quorum, so a partitioned minority stalls rather than forks, converging by adopting the majority's block on healing. One structural choice explains why the beacon can be this slow and still be authoritative: beacon state is never stored or attested on-chain. It is a pure fold over the committed block sequence, so every honest replica folding the same blocks holds a byte-identical state, and a light client verifies the validator registry, the committee assignments and even the historical activation price by replaying the fold rather than trusting a snapshot. Lifting and Lowering Shards and the beacon communicate through "lifting and lowering". Topological signals originating on a shard – staking and unstaking, validator registration and deregistration, jailing and unjailing, missed proposals – are committed into that shard's block headers via a merkle root and "lifted" to the next beacon block, which applies any topology changes and "lowers" updated committee assignments back. Jailing, the most time-sensitive operation, took roughly a day to implement here, having been written off as impractical to retrofit onto Babylon. Stake Pool and Market-Driven Parameters A stake pool model governs how many nodes an operator may run: at most one active validator per unit of the current minimum stake. The price of a seat is set by the protocol (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/06-resource-economics.md) rather than governance, recomputed every epoch inside the beacon fold. Each pool implicitly offers seats at descending prices – stake S supports one validator at S, two at S/2, and so on – and the fold sorts every pool's offerings and takes the one supplying exactly the population the topology needs, read from the lookahead committees so a split raises demand an epoch before its children seat. Because the price is the marginal offering rather than a threshold, it adjusts continuously instead of oscillating. Two clamps bound it, both invariants. The price never rises past the tightest pool's per-validator budget, so repricing alone can never deactivate a sitting validator – only an actual withdrawal can. And it never falls below a hard sybil floor however short of validators the network runs, so corrupting a third of a committee always costs real stake. Between them sits a closed loop with no external inputs: topology decides demand, demand and pooled stake decide the price, the price gates activation, activation replenishes the pool. Shuffling Committee membership churns as a trickle rather than a reshuffle: once per shuffle interval each shard draws a single replacement from the pool, seated make before break – the entrant joins alongside the member it will replace, which keeps its seat and vote until the entrant has synced and signalled ready. A committee mid-rotation therefore carries a syncing extra seat on top of a full consensus set instead of running a seat short. Wholesale re-assignment would resist adaptive corruption better but would force whole committees to re-sync continuously; the trickle is the deliberate trade. The member rotated out is the longest-tenured – a fixed clock, not a random draw, precisely because a seeded victim would let an adversary grinding the randomness steer eviction away from its own corrupt seats. The entrant stays a seeded draw, so no shard's next placement is predictable. What the churn buys is stated more narrowly than it is usually repeated. Against a static adversary the trickle is a minor statistical improvement over wholesale redraws and the sampling guarantees do not depend on it; its real value is operational (at most one syncing seat per committee) and adaptive. Rotation converts slow, cheap corruption into fast, expensive corruption; the analysis (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/05-byzantine-safety.md) is explicit that it does not stop fast corruption, and that no plausible rotation speed flushes an adversary who can compromise a seated validator within hours. One benefit does hold cleanly: because a validator churns out within a bounded time regardless, there is no lasting incentive to misrepresent a shard's utilisation to game split and merge decisions. Accountability Without Slashing There is no slashing anywhere in the protocol, by design, with accountability in two tiers matched to the quality of the evidence. Inference-based faults – missed proposals, beacon absence – jail the seat: temporary by construction, lifting after a cooldown, and derived only from missed-proposal leaves a proposer cannot selectively omit, because verifiers recompute the expected witness root and reject a header that drops one. Unforgeable signature evidence – a double-sign, which no correct node with a secure key can produce – convicts the operator's entire stake pool: every validator it runs is permanently revoked, the pool never registers again, and its withdrawals are impounded, frozen for a governed span then released whole. Impounding rather than burning is reasoned from delegation: pools may hold third-party stake, and delegators cannot foresee an operator's first equivocation, so slashing would burn innocent capital while barely touching an operator running mostly delegated stake. Conviction instead falls on the operator's franchise and on the capital's time. The documentation is candid that this prices a floor under bribery rather than a burn – an adversary structured as one seat per pool pays that rental cost per conviction and re-registers fresh capital – so the defence is stated as structural first, economic second. Dynamic Sharding and Live Resharding The topology adjusts itself to load, and a shard proposes its own resharding rather than being told to. When a shard's committed substate byte total crosses the configured split threshold, its proposer asserts a split trigger in the block manifest – a claim about committed state every replica validates against its own byte accounting before voting, so a Byzantine proposer cannot conjure a split. Merges work identically against a much lower derived threshold, the wide gap preventing oscillation, and governance moves the thresholds by on-chain parameter vote. Because state lives as a prefix subtree of one global merkle trie, a split hands each child one of the parent root's two children and a merge composes them back under a single hash: resharding moves subtree roots, not leaves, and nothing is ever re-keyed or re-indexed. Live resharding lets a shard split without halting, again make before break. On admitting the trigger the beacon draws an observer cohort and assigns half to each child; while the parent keeps producing blocks each observer snap-syncs its assigned subtree then tails the parent, applying the child's writes as they land. Only when both children can seat 2f+1 ready members does the beacon schedule the cut – one window ahead, so proposers know it before it arrives, and once published it cannot be withdrawn. The parent runs to its terminal block and coasts, its header carrying the two child subtree roots every replica checks compose back to the parent's state root. Each child's genesis is derived independently by every seated member from frozen chain content alone, and adoption fails closed unless the store holds exactly the subtree the genesis names. What the parent does not do is hand its in-flight work to its children. Inheritance was considered and rejected outright: whether an execution certificate "exists" is a gossip-time fact – a leader holding vote shares can materialise one arbitrarily late – so any rule keyed on it turns atomicity into a race. Instead the terminating shard's final block fixes exactly which cross-shard waves it settled; that set's root is attested into the beacon, and surviving shards enforce a fence, valid if and only if a wave naming a terminating or terminated shard has its id in that settled set. The fence engages from the moment a reshape is admitted, not once the shard is gone. The guarantee is that a cross-shard transaction commits on the survivor if and only if its half applied on the terminated shard's chain at or before the terminal block – both verdicts functions of frozen content, so they cannot disagree. With enshrined checkpoints attested on the beacon and snap-sync, a validator shuffled into a new shard downloads a recent checkpoint and replays only the blocks since. The lead developer contrasts this with peers: MultiversX has discussed adaptive state sharding for years without shipping it, and NEAR's dynamic sharding requires rewriting storage at a split and can only split, not merge back. Virtual Nodes Operators can run virtual nodes (vnodes) – multiple logical validators inside a single process. When several of an operator's nodes are shuffled into the same shard they share execution, storage and networking work rather than duplicating it, amortising hardware cost. The lead developer routinely runs eight nodes on a single sixteen-core machine while spamming far more than current Radix throughput. Batch Sequencing on Contended State Batch sequencing addresses what the lead developer calls "the largest design issue with Hyperscale in general": even at millions of transactions per second network-wide, a single hot spot such as a popular DEX pool would be throttled to under one transaction per second by state locks. Two mechanisms lift the ceiling. Fine-grained per-substate locking exploits the fact that a manifest plus the on-chain blueprint (/contents/tech/core-concepts/blueprints-and-packages) metadata of the components (/contents/tech/core-concepts/components) it calls can often be analysed ahead of execution to determine exactly which substates a transaction touches, so non-overlapping transactions against the same component lock individual substates rather than the whole component and run concurrently. That helps where contention is over separable state, and not at all for genuinely indivisible state – the single price value of a DEX pool, which every swap must read and write. Hot-state flagging targets that case: a contended piece of state can be flagged so one shard sequences whole batches against it under a single amortised lock rather than paying cross-shard locking costs transaction by transaction, with the beacon forming network-wide agreement on the flag. Its throughput can then approach the aggregate throughput of the shard it lives on. The trade-offs are that batching under one sequencer raises that shard's compute and bandwidth cost, reopens a bounded window for maximal extractable value (https://ethereum.org/en/developers/docs/mev/) within each batch, and – because flags apply at topology boundaries – takes effect only from the next roughly five-minute epoch. Both mechanisms were designed against a mempool that arbitrated conflicts before execution. That premise was removed in August 2026 – see Contention: locking leaves the mempool below. Seating, Shuffling and the Single-Shard Threshold (August 2026) Milestone 1 shipped node shuffling, and on 28 August 2026 a long exchange in the project's channel put the mechanism itself on the record. Getting into a shard is a lottery; getting out is first-in, first-out. "it's a lottery. once you're seated in a shard then it's a queue" (https://t.me/hyperscale_rs/11089) – validators seated ahead of a new arrival are shuffled out ahead of it – and the two halves are deliberately different: "getting seated is random. getting shuffled out is fifo" (https://t.me/hyperscale_rs/11091) . The exit used to be random too. It was changed to blunt randomness grinding by a large-stake adversary, which under a fully random scheme gets two bites at every draw: "if both seating and shuffling is random - the most successful grind will seat a malicious, and shuffle an honest" (https://t.me/hyperscale_rs/11093) . Making the exit predetermined removes the second. The seed has since moved as well – randomness was drawn from the beacon committee when that change was made, and is now supplied by the shards themselves (https://t.me/hyperscale_rs/11094) , "which makes it orders of magnitude harder to grind" – but the FIFO exit is kept regardless, "because it's a good hardening anyway". Why one shard is the whole network Seating carries that much design weight because capturing a single shard is terminal rather than partial. No other shard can check its work: they do not hold its state, and "if they did - it would not be a sharded system" (https://t.me/hyperscale_rs/11105) . With a quorum inside one shard, "state is whatever you say it is" (https://t.me/hyperscale_rs/11107) , with lesser interference available on a gradient from f+1 upward. Because Radix is asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) , XRD (/contents/tech/core-protocols/xrd-token) lives in every shard rather than in one contract, so the consequence is not confined to that shard's users: "you could mint a trillion XRD, stake it, and now you control the network" (https://t.me/hyperscale_rs/11099) . The threshold is not monolithic security divided by shard count. On the developer's figure, taking two-thirds of a single shard on fair draws over a thousand-year horizon needs roughly 44% of all stake (https://t.me/hyperscale_rs/11108) , against the 66% an unsharded proof-of-stake network requires – "which is still a very high bar", and materially more than the arithmetic a reader might expect. The caveat attached to it is economic rather than cryptographic: percentages resolve to money, and "the actual price of the asset has to do the heavy lifting at some point" (https://t.me/hyperscale_rs/11110) . The liveness threshold, and the answer that is still unpublished The 44% figure prices capture. Asked in the same exchange what it costs to attack liveness instead, the developer separated the two: “same same. you can impact liveness with 1/3” (https://t.me/hyperscale_rs/11118) . The liveness threshold is the monolithic one, a third of a committee, and it is far below the share that capture needs; what differs is the consequence. Halting a committee is not a durable position, because the beacon takes the seats away: sustained liveness failure, in the developer’s words, is where “the beacon says fuck your committee - firing squad”. That is the channel’s statement of the mechanism the threat model (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/05-byzantine-safety.md) documents in the f+1 to 2f band, where withholding halts a shard and the beacon undoes it with a full re-draw of every seat. The question that prompted it asked specifically for the sharded liveness threshold, and for a time horizon at 20% Byzantine stake. Neither number was given. The sharded equivalent of the 44% capture figure, for liveness rather than safety, has not been published, and this page does not have one to record. What shuffling costs, and what asset orientation saves Sharding bounds the state any one node must hold, because a shard can always be split again – but the developer is explicit that this is a purchase rather than a saving: "it doesn't make it free - as you have more validators to pay" (https://t.me/hyperscale_rs/11075) . State growth is also not the same thing as usage. Balances are integers whose size does not change when they move, so a transfer costs no state at all, and an AMM (/ecosystem/ociswap) holding two integers stays two integers under a million transactions; an account's state grows with the number of distinct assets it holds and shrinks when one hits zero (https://t.me/hyperscale_rs/11082) , "as then we can forget the balance". The asset-oriented model helps rather than hinders contention here, for the same reason. A balance lives in the holder's own account or in a component's vault instead of under one ERC-20-style ledger contract, so the balances are scattered across the state space (https://t.me/hyperscale_rs/11081) and two accounts changing at once do not contend (https://t.me/hyperscale_rs/11084) . The VM (/contents/tech/core-protocols/vm-layer) takes it further with locking semantics named delta, credit and reserve, so that commutative operations stay independent: "if 5 people all pay Bob at once - those also don't contend" (https://t.me/hyperscale_rs/11086) . Three positions stated the same day Stateless validation is rejected, not deferred. Asked directly whether Hyperscale would adopt it, the answer was no, and the objection is structural: "stateless validation means validators can't do their job unless someone else does theirs" (https://t.me/hyperscale_rs/11059) – the failure point moves onto whoever supplies the state witnesses, which the developer places in the same category as ZK "verify, don't execute" designs moving it onto the proving clusters. The megabyte-scale transaction bound is a choice. Sizing "gossip, serde, block space, data availability, etc to big ass edge-case transactions" (https://t.me/hyperscale_rs/11033) is described as solving a non-issue at the cost of making the system objectively worse; transactions of about 1 MB remain available, and the ceiling is not treated as something to lift. State bloat is expected to be the expensive act. Fee tables are unwritten, but the direction follows from shuffling: a security model that rotates validators between shards implies continuous state sync, so "bloating the size of state will probably comparatively be one of the most expensive things a person can do" (https://t.me/hyperscale_rs/11052) . That is the pricing counterpart to the fee design above, where every fee burns and none is paid to anyone. The statements in this section are Telegram messages in the project's public channel, each attributed to the lead developer by the message's own embed markup. Contention: locking leaves the mempool (August 2026) Through its first year the project treated contention as an admission problem: a transaction took a claim on the state it declared, and the mempool kept conflicting transactions apart until the first released its locks. That is what made a hot component the design's sharpest edge, and what the two mechanisms above – fine-grained per-substate locking and beacon-flagged batch sequencing – were built to blunt. On 8 August 2026 the arrangement was inverted. PR #142, "Schedule execution as a chain of ticks, bounded by work" (https://github.com/hyperscalers/hyperscale-rs/pull/142) , merged 138 files (+6,612 / −4,017) and moved sequencing out of the mempool and into execution. The repository states the new rule directly: admission does not arbitrate conflicts (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/04-atomic-commitment.md) . Selection is hash-ordered iteration over the eligible pool up to the block budget, so two transactions touching one cell are both selectable. What sequences them is execution: a committed block's work is one batch, partitioned into conflict groups and run against a single overlay, and each batch's output is the next batch's baseline. Contenders therefore see each other's writes instead of being held apart, and – in the documentation's own phrase – a hot cell no longer costs a commit cycle per transaction. A work budget (MAX_DRAIN_WORK), carried on the block header so every replica reads the same number, bounds how much committed-but-unsettled work a shard may still owe. The change is recorded as a retired invariant (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/08-invariants.md) rather than a tuning pass, which is what makes it legible. INV-EXEC-3 ("Partial coupling") held that no two transactions simultaneously in flight or ready shared any declared key, with locks persisting from commit to finalization. It is struck, and the note says why it could not have held: a transaction took its claim when its block committed, while a proposer selects over blocks that have not committed, so two conflicting transactions were both selectable and both executed against a baseline excluding the other. Admission had been made responsible for a property it was not positioned to hold. With execution deciding what runs together, the note concludes, the property "is not narrowed but dissolved". The companion INV-EXEC-4, a cross-shard conflict detector, is retired in the same pass; a genuine cross-shard cycle is now broken by the payer's deadline abort rather than by a hash-order tiebreak, which the documentation is candid about costing a floor – "the tiebreak settled one side of a cycle, the deadline settles neither". Deadlock is instead excluded by construction: local transactions cannot deadlock because nothing holds them apart (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/00-overview.md) . Asked the hotspot question on 9 August 2026 – whether a popular token launch or NFT (/contents/tech/core-protocols/nfts-on-radix) mint would simply queue at the mempool, and whether there was a roadmap to mitigate it – the lead developer answered that the premise no longer applied, and attributed the result to the co-design of the execution environment with consensus – the purpose-built VM described below: it is, he wrote, "the massive benefit of building out a VM that's perfectly adapted to the consensus", making the system "orders of magnitude more efficient in the face of contention". His one empirical remark is worth keeping at its stated weight – the interactive demo runs eight accounts, so submissions collide often, and where repeated submissions previously "trickled in serially" they now commit together. That is an observation about a demo, not a benchmark; the project's published contention figure remains the 300-node simulation reported above. Multi-stage routes, and the redundancy the design still carries (August 2026) The rework above attacks contention inside a shard. On 30 August 2026, in a channel argument about whether Hyperscale's lighter nodes amount to an energy story, the lead developer stated the cost that sits on the other axis, and it is a concession the project's own documentation does not make: "cross-shard atomic commitment via only partial execution sharding means you're actually replicating the same execution more times than you would in a monolithic system" (https://t.me/hyperscale_rs/11207) . That follows from the pipeline described under Architecture. Because every shard owning declared state runs the transaction, a transaction spanning several shards is executed once per shard, where a single-ledger chain executes it once. Sharding buys parallelism between transactions and pays for it in duplicated work within one, and the bill grows with how many shards a transaction reaches. The same message describes the mitigation, in the first person and as work in progress: "i'm working through breaking transactions into multi-stage routes with a pattern of escrow->atomic core->total settlement stages" (https://t.me/hyperscale_rs/11207) . The stated motive is not the duplicated compute. It is contention: "not particularly for the purpose only reducing redundant compute... but mostly because if the common pattern is that the atomic core can touch only one shard - that's much better for contended throughput" (https://t.me/hyperscale_rs/11207) , and the case he names for it is the obvious one, "the classic pattern of many users from many shards just hitting a single swap pool" (https://t.me/hyperscale_rs/11207) . The shape of the answer is to shrink the atomically committed part of a cross-shard transaction down to a single shard and push the rest into stages either side of it, so that the swap pool's shard is the only one that has to agree with anybody. It is a design in conversation, not a specification. As of 31 August 2026 neither repository carries it. The ten architecture documents in hyperscale-rs/docs (https://github.com/hyperscalers/hyperscale-rs/tree/main/docs) describe cross-shard commitment only as the single provision, execute, certify (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/04-atomic-commitment.md) pipeline, and contain no occurrence of "escrow" or of a multi-stage route; the sole "escrow" anywhere in hyperscale-vm/docs (https://github.com/hyperscalers/hyperscale-vm/tree/main/docs) is an unrelated reference to call and escrow boundary values in the canonical ABI. This page records the design at the weight it currently has, which is a statement by the person writing the code. “Leg local execution”: the route acquires a name (4 September 2026) Five days later the sketch above was named and specified, still in the channel and still ahead of either repository. At 12:44 UTC on 4 September 2026, with mainnet in its ninetieth hour of halt (/contents/history/hyperlane-asset-drain-2026) , the lead developer described what he is “for lack of a better name… calling ‘leg local execution’” (https://t.me/hyperscale_rs/11969) , and placed it at “where the rubber meets the road in terms of getting the state contention payoffs of a redesigned VM”. The message is authorship-verified through its public embed (https://t.me/hyperscale_rs/11969?embed=1&mode=tme) . The failure mode, stated concretely. Twelve users on twelve different shards want to swap against one XYZ/USDC pool. Under the naive atomic commitment described under Architecture above, the taker’s shard and the pool’s shard trade state and both run the whole transaction, which blocks the next one and so on down the queue, so “the taker who was unluckiest in the ordering might be waiting over a minute for his swap”. His conclusion about that outcome is the sharpest statement of the stakes the project has published: in practice “any hyperscale network would end up being dogshit for defi”. Three stages. A transaction is decomposed into inbound legs, which “must be pure reservations of value and treated as escrow” to the stage below; an atomic core, “the part of the transaction that truly needs to either succeed or fail together”; and outbound legs, which “must be total and infallible, and can just be treated as an ‘if core succeeds, then these things will happen’”. The enabling condition is named, and unlike the staging itself it is checkable in writing: the decomposition is possible “now manifests are DAGs”. What it buys. In the twelve-taker case the atomic core is single-sharded — just the swap venue — so that shard “can rip through all the transactions in one execution tick” without blocking coordination with the other eleven. The certificate exchange with those shards still happens; it stops being on the critical path. The second gain is compute, and it answers the concession recorded immediately above: under naive atomic commitment all twelve shards execute the AMM swap logic for their own transaction, whereas here “compute is only replicated across the atomic core shards (which probably in the vast majority will just be 1 shard)”. What it costs, and how that cost is met. A transaction whose atomic core genuinely spans shards — one touching two pools in different shards — still runs on atomic commitment and is “relatively slower and also slow everyone else doing the more typical fan-in”. The mitigation he names is pricing rather than mechanism: “not really any way to solve that except to price fees for transactions as multiples of however many shards the atomic core touches”, which “also makes sense given the compute is replicated”. That is a fee schedule the successor engine is positioned to express and the current one is not — the VM’s manifest format (https://github.com/hyperscalers/hyperscale-vm/blob/main/docs/02-manifests-and-intents.md) puts the payer and max_fee in the envelope and carries “no fee instruction of any kind”, so what a transaction costs is settled against its declared shape rather than by whatever a component chooses to lock mid-execution. Still in conversation, but half of it is now written down. Read on 4 September 2026, none of the ten architecture documents in hyperscale-rs/docs (https://github.com/hyperscalers/hyperscale-rs/tree/main/docs) contains “leg local”, “inbound leg”, “outbound leg” or “escrow”; cross-shard commitment is still documented only as the single provision, execute, certify (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/04-atomic-commitment.md) pipeline. The premise it rests on has moved the other way. hyperscale-vm’s manifest document (https://github.com/hyperscalers/hyperscale-vm/blob/main/docs/02-manifests-and-intents.md) is titled “Manifests and intents: the typed dataflow DAG” and states the property the staging needs: “Sequencing is dataflow-only. Execution order is the DAG’s topological order; independent legs are visibly independent. Acyclicity is subsumed by the format: a manifest is acyclic or it does not parse.” The word this design turns on is already the repository’s word for the independent parts of a transaction; what is not yet written anywhere is the machinery that executes them in three stages. Leg local execution merges (9 September 2026) The machinery arrived five days after it was named, in one merge rather than day by day. Pull request #156, “Initial leg local execution impl.” (https://github.com/hyperscalers/hyperscale-rs/pull/156) , opened from the branch new-local-leg at 03:37 UTC on 9 September 2026 and merged into main at 15:15 UTC the same day by its author, carries 300 commits across 313 files, +42,964 and −14,112 lines, with no review and no comment recorded on it. A second pull request, #157, “LLE streamline + refactor.” (https://github.com/hyperscalers/hyperscale-rs/pull/157) , merged at 19:03 UTC the same evening: 17 commits over 45 files, +2,514 and −3,698. The lead developer had explained the delay in the channel while the branch was open, twice. At 23:26 UTC on 7 September (https://t.me/hyperscale_rs/12134) he wrote that “kitwatcher only tracks main branch. work is happening on a feature branch for leg local execution. it’s on github but won’t be merged until i think it’s robust, safety critical”, and at 16:37 UTC on 8 September (https://t.me/hyperscale_rs/12141) that leg local execution “is an almost complete rewrite of how execution works” and that he is “not merging them before they’re done in order to appease any silly conception anyone might have around a kitwatcher score”. Kitwatcher is a community tracker that scores Radix repositories on commits to the default branch, so a branch held back reads there as an idle project. Both messages are authorship-verified through their public embeds. The design is now written down, where this section recorded on 4 September that it was not. hyperscale-rs/docs/08-invariants.md (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/08-invariants.md) carries a section headed “Leg-local execution” holding nine invariants, INV-LL-1 to INV-LL-9, that state the terms the three-stage division holds to: a transaction has exactly one core and it commits as a single atomic unit across its core set (INV-LL-2); the only writes committed before the core’s verdict are inbound escrow movements, kernel cells keyed by the transaction, and the payer’s fee burn (INV-LL-3); and an outbound delivery never gates a verdict and never holds a reservation (INV-LL-7). Each names the file and function that enforces it. The pipeline document the section points at, 04-atomic-commitment.md (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/04-atomic-commitment.md) , still describes cross-shard commitment as provision, execute, certify, and has not been rewritten around the stages. Execution Layer: from the Radix Engine to a Purpose-Built VM hyperscale-rs is a consensus layer, and which execution environment runs on top of it stayed open through the project's first year. For most of that year the repository integrated the real Radix Engine (/contents/tech/core-protocols/radix-engine) through an engine crate, executing it once per transaction over merged local and provisioned state — an early differentiator from the Foundation's reference implementation, which simulated execution rather than running the real thing, and the reason the simulation results below are worth anything. That arrangement ended in August 2026; the section below records the decision, and the subsection "The switch lands" records the cut-over. On 11 April 2026 the lead developer framed the choice as "a decision point rather than anything proscribed by technical limitations" (https://t.me/hyperscale_rs/6018) , with three options: (a) a low-friction change under which existing dApps keep working as they are, (b) a higher-friction change that may require dApp adaptation but produces a better system, or (c) supporting both, at maximum complexity for client builders and maintainers. The argument turns on data dependencies. Cross-shard commitment requires every transaction to declare up front which objects it reads and writes; that declaration is what fixes the participating shards and lets conflicts be analysed without executing anything. The ideal VM for a sharded network is therefore one where a transaction's full data requirements resolve deterministically in advance, from the transaction manifest (/contents/tech/core-protocols/transaction-manifests) plus the metadata of any blueprints it references. The Radix Engine, on the developer's assessment, is "too loose" (https://t.me/hyperscale_rs/6018) for that – its state access is not self-describing enough – leaving only two unattractive routes to transaction preview: an ingress node holding state from every shard, which does not scale past a point, or any node pulling state on demand light-client style, discovering each dependency part-way through execution. The second is slow, and because preview happens before submission there is no clean way to compensate the nodes performing it. On 1 August 2026 the direction was confirmed. Asked whether the Radix Engine was simply not built for sharding, the lead developer answered that "it's not in the ballpark. it's not in the same zip code as the ballpark" (https://t.me/hyperscale_rs/10332) . Asked whether a new VM made more sense than modifying it, the reply was "yeah, it's underway" (https://t.me/hyperscale_rs/10334) , reasoning that "the sharding adjustments are so many that it'd require touching everything. at some point it becomes easier to start with intention than to retrofit" (https://t.me/hyperscale_rs/10336) . That is option (b), and he confirmed the mapping in as many words: "yeah option B. options A and C have dissolved" (https://t.me/hyperscale_rs/10340) . He has also put the cost of the alternative plainly: leaving state contention untackled would leave “hs-rs being a good consensus, and RE being a good [single-shard] VM... but hs-rs + RE being a kinda mediocre system (particularly for defi) purely because of waiting around for state locks” (https://t.me/hyperscale_rs/10349) . A day later he stated the motivation directly. Mapping substate keys to shards is trivial arithmetic on the beacon's trie; the difficult part is "to be able to look at a given transaction - and deterministically know which substate keys it will touch when considering a turing complete contract language. this is part of the motivation for a new VM" (https://t.me/hyperscale_rs/10358) . The new execution layer exists, in other words, to make static declaration of a transaction's footprint a property of the language rather than an approximation recovered by analysis. The dissolution of (a) and (c) removes both routes that would have spared existing dApps: no low-friction path on which today's blueprints keep working unchanged, and no dual modality running a legacy environment beside the new one. On 2 August the developer gave the first indication of the friction involved: "best case scenario - contracts will just need a recompile. worst case scenario - there'll be some automatic transpiler devs can use to upgrade source code" (https://t.me/hyperscale_rs/10346) . Both ends of that range describe migrating source rather than rewriting it. On 3 August 2026 that question was answered. Pressed on the cost to teams that would have to build again – one developer arguing that "operational dapps can be part of the VM conversation as it will be considerable expense to them to build again" (https://t.me/hyperscale_rs/10403) , and then doubting (https://t.me/hyperscale_rs/10407) a second member's recollection that migrating would be easy – the lead developer replied that "Scrypto is literally just a couple of Rust macros. Not particularly hard to hit parity" (https://t.me/hyperscale_rs/10414) , and that the "Goal is not to change developer-facing features for the sake of it. Things like manifest, resources, subintents, badges, etc. are genuinely good ideas. It's the lower layers like state, locks, parallelism, which needs changing" (https://t.me/hyperscale_rs/10414) . That draws the line the earlier messages had left implicit. The surface a Scrypto (/developers/scrypto) developer writes against – the transaction manifest (/contents/tech/core-protocols/transaction-manifests) , the resource model (/contents/tech/core-concepts/asset-oriented-programming) , subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) and badges (/contents/tech/core-concepts/badges) – is intended to carry over, and reaching parity with the language is characterised as a matter of reimplementing macros rather than redesigning a programming model. What is being replaced sits underneath it: state representation, locking and parallelism, which is precisely where the Radix Engine (/contents/tech/core-protocols/radix-engine) was judged "too loose" for a transaction's footprint to be known before execution. It remains a claim by the person doing the work rather than a demonstrated migration, and how much the new VM borrows from the Radix Engine internally has still not been said; the April message allowed only that it "might borrow some ideas from RE". The VM becomes its own repository (July–August 2026) On 30 July 2026 the new execution layer stopped being a plan and became a codebase. hyperscalers/hyperscale-vm (https://github.com/hyperscalers/hyperscale-vm) was created that day as a public Rust repository, and hyperscale-rs opened a vm branch the same evening whose first commit adds "the effects bridge and pin the vm-effects dependency". By 7 August 2026 the VM repository held 124 commits, all by the lead developer, and the vm branch stood 150 commits ahead of main across roughly 300 files, while main itself had not moved since 30 July. On 7 August the VM was rewired in as a git submodule rather than a git dependency and its documentation was split out of the consensus repo, so the two projects now version independently. The repository opens with a "work in progress, do not use" warning and describes its safety story as determinism-by-declaration: routing, locking, provisioning, conflict verdicts and fee assurance are all computed before execution, from committed content, identically on every replica. One pure function, route(), folds over a transaction's manifest (/contents/tech/core-protocols/transaction-manifests) and returns the participating shards, the per-shard key-and-mode sets and the static call graph with no execution and no state read — precisely the property the April 2026 discussion had identified as the thing the Radix Engine (/contents/tech/core-protocols/radix-engine) could not supply. Undeclared access is not filtered but unreachable: the kernel materialises state handles only for the declared effect set, so an access outside it has no handle to call and traps deterministically. Exclusive whole-object locks are replaced by five access modes with a compatibility relation, under which reads share with reads and increments and reservations commute — so, in the repository's own example, a thousand deposits to one vault form a single parallel group. The deterministic profile is then executed twice, by a version-pinned wasmtime (https://wasmtime.dev) embedding and by an independently written reference interpreter, differentially tested against each other, with divergence treated as a release blocker whichever side is wrong. Twelve crates carry that design, among them effects (the access DSL and route()), kernel (object model and mode semantics), hbor (a canonical, natively merkleized encoding), runtime and ref (the two engines), sdk (the guest authoring surface) and stdlib (resources, principals and badges as system-tier components). Guest fixtures cover an account, a constant-product pool, an order book, staking and a transfer. Eight numbered architecture documents sit beside a consolidated invariant register of INV-VM-* properties, described as the intended starting point for formal verification, and a separate upgrades.md governs how the engine pin, the deterministic profile and admitted guest toolchains are allowed to move. What the repository says about Scrypto that the channel did not The architecture overview lists its non-goals explicitly, and one of them is " Scrypto (/contents/tech/core-protocols/scrypto-programming-language) or EVM compatibility — the effect-typed ABI is not expressible under either; no shim layer". That is the first place the project has written down that existing Scrypto (/developers/scrypto) blueprints will not run on the new engine and that no compatibility layer will be provided to make them run. It does not contradict the 3 August statement that "Scrypto is literally just a couple of Rust macros. Not particularly hard to hit parity" (https://t.me/hyperscale_rs/10414) — parity of developer-facing concepts is not ABI compatibility, and the VM does ship its own blueprint-and-state authoring macros and its own resource, badge and principal types. But it sets the two claims side by side for the first time: the concepts are meant to carry over, the compiled artefacts are not, and the migration path remains the recompile-or-transpile range given on 2 August rather than anything specified. None of this affects Radix mainnet as deployed, which continues to run the Radix Engine under Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) -derived Babylon consensus; the new VM belongs to the Hyperscale programme, and no migration has been scheduled. The switch lands (August 2026) Between 4 and 9 August 2026 the two-engine arrangement was removed rather than deprecated. PR #141, "Initial VM switch spike" (https://github.com/hyperscalers/hyperscale-rs/pull/141) , merged on 7 August; commit 523c7dbf, "Retire the two-engine material from the system docs" (https://github.com/hyperscalers/hyperscale-rs/commit/523c7dbf) , had landed two days earlier. The project's own Weekly #13 (https://t.me/hyperscale_rs/10531) , published 10 August, opens Milestone 2 with the line "the codebase now runs on one engine with zero external Radix dependencies". The workspace manifest bears that out exactly. Cargo.toml (https://github.com/hyperscalers/hyperscale-rs/blob/main/Cargo.toml) declares seven path dependencies — hyperscale-hbor, -vm-effects, -vm-kernel, -vm-ref, -vm-runtime, -vm-stdlib and -vm-types — all resolving into the vm/ submodule, and no Radix (/contents/tech/core-protocols/radix-engine) crate of any kind. A code search across the repository for radix-engine returns nothing. The engine crate still exists but is now a different crate: its own manifest describes it as "engine integration: the tick-batch execution seam, the executor behind it, and genesis seeding", it depends on the VM's effects, kernel, stdlib, runtime and reference crates, and the README's crate table calls it a "batch executor over the VM kernel". Two details of the pin are worth recording because the project treats them as protocol rather than housekeeping. The wasmtime (https://wasmtime.dev) version is pinned exactly (=47.0.3) and the manifest's comment says it "mirrors the VM repo's blessed engine exactly", adding that upgrades "are protocol events". And the differential pair is split by target rather than run side by side everywhere: the blessed wasmtime engine builds natively, while the independently written reference interpreter is the wasm32 implementation — the in-browser simulation — "by decision, not a fallback", with byte-identical receipts and fuel across both the stated guarantee. None of this touches Radix mainnet, which continues to run the Radix Engine (/contents/tech/core-protocols/radix-engine) under Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) -derived Babylon consensus. What changed is that the Hyperscale codebase no longer contains a copy of it. The blessed engine and its upgrade discipline Asked in t.me/hyperscale_rs (https://t.me/hyperscale_rs) on 12 August 2026 how the VM's two engines differ and how one can check the other, the lead developer gave the short version: wasmtime (https://wasmtime.dev) is "the actual production engine… the only one that actually runs when you're running the network", while the reference implementation is "a slow interpreted engine that handles the same subset of WASM" whose "only job… is to make sure we get the expected outputs for given inputs" — so that "if we bump the version of wasmtime, and it changes something fundamental, then the test suite will complain loudly". The repository's own documents set out the policy behind that answer, and it is more specific than a testing convention. One blessed engine per protocol version. docs/05-runtime.md (https://github.com/hyperscalers/hyperscale-vm/blob/main/docs/05-runtime.md) names wasmtime, version-pinned and embedded in crates/runtime, and gives five reasons for the choice: it is the reference implementation of the exact specifications the deterministic profile freezes; its security posture; its tiered backends execute one semantics, which supplies the differential harness with intra-engine cross-check lanes; its fuel metering is instruction-deterministic within a version, which is the property the pin exists to absorb; and it embeds Rust-native with no FFI in the consensus path. Three operational rules ride the pin. The blessed backend is pinned alongside the version — Cranelift, with the other backends kept as differential lanes. Compiled-module caches pre-warm in the epoch before a bump, so the recompilation avalanche is scheduled away rather than survived; package immutability means no other cache-invalidation event exists. And compilation runs on a dedicated OS thread pool, never the shared dispatch pools, because nested work-stealing between the engine's internal parallel compilation and the host's own pools is a known self-deadlock shape. Why the second engine has to be written by hand. The reference interpreter in crates/ref is described not as a test double but as the executable spec, and its independence is a stated requirement: it is "never derived from the engine's own interpreter tier — because same-vendor implementations share bug correlations, and the interpreter's whole value is being an uncorrelated witness". Its crate manifest scopes that independence precisely: execution semantics, canonical-ABI lift and lower, and the fuel schedule are implemented separately from wasmtime, and sharing is permitted only at the decode layer, where both use wasmparser. upgrades.md (https://github.com/hyperscalers/hyperscale-vm/blob/main/upgrades.md) makes the consequence a rule rather than a preference: an outcome or state divergence between the two is a release blocker whichever side is wrong, and on a fuel divergence the reference interpreter's schedule is the consensus definition — "the engine matching it is what the pin guarantees". An engine bump is a protocol upgrade. The same document classes a version bump, a blessed-backend change, or any profile change as consensus-visible, so each ships through the host's epoch-gated governance channel and activates at an epoch boundary, never mid-epoch, in a fixed five-step sequence: the audit runs green before any pin lands; the pin, the lockfile change and any deliberate reference-interpreter schedule update land in one reviewed diff with every schedule change called out ("a fuel-accounting change absorbed silently is the failure mode the two-implementation discipline exists to catch"); the activation epoch is published ahead so operators know the flip before it happens; caches pre-warm; and blocks anchored either side of the boundary execute under the corresponding pin. The next such event is already dated in the manifest. hyperscale-vm's Cargo.toml (https://github.com/hyperscalers/hyperscale-vm/blob/main/Cargo.toml) pins wasmtime = "=47.0.3" and comments that this is "the latest stable ahead of the 48 LTS (expected 2026-08-20; the pin moves there when it lands). Upgrades are deliberate protocol events, never dependency drift." That matches wasmtime's published release process (https://docs.wasmtime.dev/stability-release.html) — a major version on the 20th of each month, every twelfth release an LTS supported for 24 months against two months for the rest — which puts 47 outside long-term support and makes 48 the first LTS the VM can sit on. One consequence of the split is worth recording for anyone embedding the crates rather than running a node: the wasmtime dependency sits behind an optional engine feature, and with it switched off crates/runtime is the deploy-time profile validator alone — bytes in, an admissibility verdict out — which the repository notes is all an embedder needs when its own runtime interprets components rather than compiling them. What a Migration Would Involve (1 September 2026) On 1 September 2026, with Radix mainnet twenty-two hours into a halt (/contents/history/hyperlane-asset-drain-2026) and the channel arguing over whether the network should be upgraded or restarted as something else, the lead developer answered the migration question in more detail than at any point before. The account below is his, message by message, and each is authorship-verified through the Telegram embed. An upgrade is a new genesis Asked what “new” would even mean, he set out that a Xi'an upgrade is not an in-place upgrade of the running chain: “it's a completely different protocol to Babylon so the only way to upgrade is to terminate the old chain and import to a fresh genesis” (https://t.me/hyperscale_rs/11438) . Mechanically that means dumping “the state at a predetermined epoch, transform it and load it in at the xi'an genesis—same process that Olympia -> Babylon was” (https://t.me/hyperscale_rs/11435) — the 2023 migration (/contents/tech/releases/radix-mainnet-babylon) that already put every Radix holder through one address change. This one would do it again: “more address changes… because a new addressing scheme was required for sharding”. The sharded design fixes the address format, so the change is a consequence of the topology rather than a choice. Contracts are the harder half, and the difficulty he names is not compilation but authority. “Contracts are much more of a PITA… because someone has to recompile and then you have to think about what are the checks and balances on the new artifact.” (https://t.me/hyperscale_rs/11436) The open question he poses is who is allowed to publish the recompiled blueprint: whether “the blueprint owner [should] be able to unilaterally update their WASM… or does it also need some kind of consensus from validators who've checked against known source to make sure they haven't, for example, put a back door into their [previously safe] swap contracts which allow them to drain”. A migration that requires every package to be rebuilt is also a migration in which every package could be rebuilt into something else, and nothing in a state dump distinguishes the two. Who decides, in the end, he places with the operators: “it is ultimately the validators who will decide what code to run and thus what (if any) irregular state transitions happen during the migration process” (https://t.me/hyperscale_rs/11444) . The shim, and what will not survive it On the developer surface he was more optimistic than the repository has been in writing. The two authoring layers are “both just rust sdks, with vaults, resources, proofs, etc.” (https://t.me/hyperscale_rs/11430) , and differences that cannot be absorbed “are probably the sorts of things that only require a few minutes to adapt”. Earlier in the afternoon he had gone further: “almost every single design decision had to get revisited in hs-vm… hoping that it will be possible to shim things such that old contracts just work… the blueprint macros are pretty similar-ish. Hopefully be in a good spot to test that in the coming weeks.” (https://t.me/hyperscale_rs/11419) That is worth setting against the VM repository's own architecture overview, which lists among its explicit non-goals “Scrypto or EVM compatibility — the effect-typed ABI is not expressible under either; no shim layer”. The written document and the channel now say different things about whether a shim exists; the channel is the later of the two, and it is a hope with a test date rather than a commitment. Two capabilities he names as going regardless, and the reasons are structural: locking fees from a component during execution, and branching cross-component calls on mutable state — “there's generally irreducible reasons for each of those related to sharding”. Both are consequences of the declared-footprint rule described above: a call graph that branches on state read mid-execution cannot be routed to its shards in advance, and a fee locked by a component the transaction did not name is a payment from an account the manifest never declared. The first of those has a very recent illustration. The transaction that emptied Radix's bridged assets (/contents/history/hyperlane-asset-drain-2026) the previous afternoon carried no LOCK_FEE instruction at all; its fee was locked from inside the published blueprint, against a third party's XRD vault. The capability the attacker used to pay for the attack is one the successor engine does not offer — not as a response to the incident, but because a sharded router cannot price a call it cannot see coming. On the other side of the ledger he listed additions rather than removals: “a more well-rounded cryptography stdlib including ZK verification” (https://t.me/hyperscale_rs/11433) , and interest in “borrowing the ZK tunnels concept from SUI”. Neither has appeared in the repository yet. Where the developer places himself The same afternoon fixed the project's relationship to Radix more explicitly than the code alone had. Asked whether Hyperscale would still be integrated with Radix, the answer began “Integrate with what? Hyperscale doesn't use any Radix components anymore… as Radix Engine turned out to be way too far from what was required” (https://t.me/hyperscale_rs/11403) — the channel's confirmation of what the August dependency cut-over had already made true in the manifest — and ended with an offer that is conditional in its first clause: “if Radix still exists, and the DAO wants help migrating all the state, balances, etc. and integrating/updating the wallet and such. Yeah, I'm sure I would still help out with that.” He declined the leadership the channel kept offering him. On the suggestion of launching a new chain: “I don't think I'm mad enough to launch an L1 in 2026. Just going to finish the tech as the open source project that it is. And then probably collapse because I've been running on fumes for months. Any network can use Hyperscale, or not use it.” (https://t.me/hyperscale_rs/11396) On being asked to decide between an upgrade and a reset: “I will vote in the DAO like everyone else. People should not particularly listen to my opinions on things outside my narrow expertise.” (https://t.me/hyperscale_rs/11455) And asked at 18:32 whether he would still want the Xi'an milestone payments (/contents/history/radix-ecosystem-funding) denominated at $50,000 in XRD or would rather be paid in fiat now, he answered only “Grants are the furthest thing from my mind presently” (https://t.me/hyperscale_rs/11446) — leaving the denomination of the programme's funding open on the day the token it is denominated in could not be transferred. Halting a Sharded Network (September 2026) The August 2026 halt of Radix mainnet (/contents/history/hyperlane-asset-drain-2026) put a question to this design that had not been asked of it before: whether a network of independently seated shard committees, with membership constantly shuffling, could be stopped at all. It was raised in the project channel on 1 September 2026 by Aditya Ingle, who asked whether a halt in hyperscale would be “almost infeasible” (https://t.me/hyperscale_rs/11473) given per-shard committees and constant shuffling. The exchange that followed is the first design change the incident has produced in the successor network, and each message below is authorship-verified through the Telegram embed. A shard can halt, and the beacon chain treats it as a fault The lead developer's answer was that halting is possible but not global: “you can halt of course but one shard halting doesn't impact others so the liveness impact is localised” (https://t.me/hyperscale_rs/11474) , with the caveat that cross-shard transactions needing state in that shard are affected. A stalled shard is not left stalled: prolonged outages are noted by the beacon chain, which rotates the whole committee to restore liveness. He put a figure on “prolonged” at hours rather than minutes (https://t.me/hyperscale_rs/11477) , because a shard is expected to recover on its own from a temporary network partition, and a full committee rotation resyncs an entire validator set at once instead of dripping one shuffled member in at a time. The mechanism that makes a stuck shard self-healing is, on this reading, also the mechanism that makes a deliberate network-wide stop hard to reach. An on-chain governed toggle, proposed two days after being called absurd Pressed on the case that actually arose, an engine-level defect draining funds in every shard at once, he proposed the fix himself: “there's probably a more elegant way to go about it than yanking the power cords out of the wall… maybe like having a on-chain governed toggle which if voted to flip - then txn processing stops” (https://t.me/hyperscale_rs/11478) , adding that it “would be simple enough to implement given the on-chain governance machinery is there already”. He then marked the reversal himself: “two days ago i would have said ‘why the hell would anyone want that?!’” (https://t.me/hyperscale_rs/11479) . projectShift answered that “it's now obvious that a well implemented decentralized network with a serious bug can become impossible to halt” (https://t.me/hyperscale_rs/11480) , asked for governance options that are themselves decentralised in who opts in and out, and asked that the asymmetry between delegators and node runners be reduced so both sides have a fair chance of equal power over such a decision. Nothing here is implemented. It is a channel exchange, not an RFC, and the crate tree carries no such toggle at the time of writing. What it records is the direction of travel: Babylon was halted by enough of its node runners each independently stopping their own machine to take staked power below the threshold consensus needs, which is why restarting it requires each of them to decide again (/contents/history/hyperlane-asset-drain-2026) , and the successor design is now being discussed with a governed stop as a first-class feature rather than an emergency improvised out of the operators' own hands. Fees, Emission and the Work Budget Milestone 2's first week also put the economic layer on the record. docs/06-resource-economics.md (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/06-resource-economics.md) had covered validator supply and the elastic minimum stake since July; two new sections were added between 4 and 8 August 2026 — "State where fees burn and close the ownership trust seam" (https://github.com/hyperscalers/hyperscale-rs/commit/f00d565e) and "Bound adding to the drain rather than the drain itself" (https://github.com/hyperscalers/hyperscale-rs/commit/d09ea58d) — and they answer a question a sharded network has to answer and a single-shard one does not: who gets paid when several shards do the work of one transaction. Fees Burn Where They Are Signed The answer is that nobody does. A fee is a claim against one account on one shard — the payer named in the signed envelope — and it never becomes a claim anywhere else. The payer's shard treats the signed ceiling as a block-validity condition: a block committing a transaction whose payer cannot cover its ceiling, counting every other ceiling that block and its uncommitted ancestors already engage, is not a valid block. An honest proposer therefore never selects an uncoverable transaction, and a Byzantine one is refused by the same predicate on the vote side, reading the same balances at the same pinned height. The reservation is an accounting entry over the payer shard's own committed chain rather than a hold on the vault: nothing moves when it engages, and it resolves exactly once at finalization — the attested actual burns on success, a class floor on abort — written inside the settling receipt, so a replica rebuilding state by replaying receipts rebuilds the burn with it. Every fee burns; none is paid to anyone. The documentation is explicit that this is a trade rather than a free win. Nothing crosses a shard boundary, so no shard's revenue depends on another shard's honesty and there is no cross-shard fee flow to arbitrate or lose — but a counterpart shard does real work (admission, routing, exclusivity, execution) "for a fee it never sees". The Emission Settles the Account by Measurement What compensates the counterpart is the fixed per-epoch emission, divided by measurement rather than transferred. Every shard's committed blocks carry two running quantities each verifier recomputes: attested work, which its own certificates report and which is a flow, and stored bytes, which is a level. Both ride the epoch-crossing header onto the shard's boundary record, and the epoch fold reweights the same fixed issuance by them — a participation floor per ready validator, plus each shard's normalised share of the epoch's work and of committed storage. The floor is not decoration, and the documentation says why: weighting on work alone would pay an idle shard nothing, making a new shard unfundable and rewarding the abandonment of quiet ones. With the work weights at zero, the floor alone reproduces a plain per-validator split. The work terms are shares rather than rates, so their constants are dimensionless ratios and magnitudes cancel. Nothing here redirects a fee — the emission is a fixed issuance and the weights only divide it. The Work Budget: bounding the drain, not the block Fees price a transaction to its sender; they do not bound what a shard commits to doing. A shard commits work when it proposes and discharges it at settlement several blocks later, and between those points sits the drain — committed and not yet settled. That, rather than the block, is what has to be bounded, and it is the MAX_DRAIN_WORK figure the contention rewrite (https://github.com/hyperscalers/hyperscale-rs/pull/142) put on the block header. Each transaction's work figure is derived at admission and never taken from the wire: a fixed admit-and-track charge, the footprint its declaration claims, and the execution ceiling its sender signed. The fixed term is the load-bearing one — a minimal declaration with a zero gas limit is almost free to price and still costs a tick entry, a tick-chain entry, a receipt and mempool tracking, so without it a flood of trivial envelopes would walk straight through a budget built to stop exactly that. Sender-declared gas gets its own separate ceiling for the obvious reason: at face value, one envelope could otherwise reserve a shard's whole allowance for the price of a signature. The header carries the running total the way it carries any chain-derived quantity — the parent's, plus what this block's transactions reserve, minus what its certificates return — so a validator checks the arithmetic without reading history, including one that snap-synced past the transactions being released. A proposer adds transactions only while the total stays under budget, and a block bringing new transactions to an over-budget drain is invalid everywhere. What is bounded is adding to the drain rather than the drain itself, and the asymmetry is deliberate: a block carrying no transactions stays valid whatever the total reads, which is what keeps the blocks carrying the releasing certificates from being the ones refused. Two earlier quantities are gone with this change — a transaction count that priced a publish and a transfer identically, and a per-block count that bounded the wrong thing; what survives of the count is a wire cap on how many transactions a block may encode. The economic invariants the document motivates are stated as INV-ECON-1 through INV-ECON-6 (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/08-invariants.md) , with the fee-reservation properties held in the VM repository's own INV-VM-* register. Retiring State: the Substate Sweep (August–September 2026) Milestone 2's fifth week produced the change the project's own weekly digest led with, and a correction to how the digest described it. On 7 September 2026 the automated digest bot (https://t.me/hyperscale_digest_bot) posted Week #17 (31 August – 6 September, 19 commits) to the project channel under the line that "the substate sweep gives the network its first real garbage collection" (https://telegram-mcp-phi.vercel.app/2026-09-06) . Asked a few hours later in the same channel (https://t.me/hyperscale_rs/12119) whether that meant null state or memory, the lead developer answered plainly (https://t.me/hyperscale_rs/12120) : "Cleaning up storage, not memory. IE reclaiming space from guards which don't need to exist once validity windows for the artifacts expire anyway, like subintent nullifiers. No memory GC needed with Rust." The distinction matters for anyone reading the phrase against a runtime they know: nothing here pauses, traces or collects at run time. Why a sweep is a consensus operation The design was written down as it landed. docs/03-state-and-sync.md (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/03-state-and-sync.md) gained a section titled "Retiring state" whose premise is that a committed cell "can be written and overwritten; nothing retires one on a schedule", while some kernel state is owed only for a bounded time — a subintent nullifier "stops being replay protection once no chain can still be deciding a spend of the subintent" — and without a sweep that state is permanent. What follows from that is the part that makes it hard: removing a cell moves the state root, so the removal is not housekeeping a node may do in its own time. It is a consensus operation every validator has to reproduce exactly. Three consequences are stated in the document. The cell answers for its own life: a sweepable cell carries its expiry in its value and keys by it, so no side index and no transaction body is needed to decide whether it is still owed — which matters because the key prefix is the only thing guaranteed to survive a shard reshape, and a rule keyed off anything else "would not survive a split". The block states a frontier, not a list: sweepable cells sort by an expiry bucket leading the key's local half, so a chain's sweep is a cursor over that order and a block's removals are exactly the cells between its parent's frontier and its own, with the interval capped and the cursor recording where a capped sweep stopped. Advancing is obliged: a removal earns no fee and costs a proposer block space, so "a rule permitting omission is one honest proposers converge on omitting" — a block that could sweep and did not is refused. The invariant register A single 30-line commit (https://github.com/hyperscalers/hyperscale-rs/commit/f6183b15) registered the properties in docs/08-invariants.md (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/08-invariants.md) as INV-SWEEP-1 through INV-SWEEP-9, alongside the existing consensus, state and economic families. The load-bearing ones are the determinism claim (INV-SWEEP-1, a block's removals are a function of its frontier pair and committed state, so "nothing about which node proposed the block, or how a node came by its state, enters into it"), the safety claim (INV-SWEEP-3, a sweep removes no cell any admissible transaction could still read), the liveness pair (INV-SWEEP-4, sweep work per block is bounded and a partial sweep says where it stopped, so a backlog drains across blocks; INV-SWEEP-6, mandatory advance), and the two that keep the cursor monotone across a reshape (INV-SWEEP-7, nothing is born below the cursor; INV-SWEEP-8, an inherited frontier never rises). What stops a sweep retiring something still in use is not a clock-skew bound but co-location: the chain holding the cell is the chain that would read it. Eleven commits, and a model of what breaks it The work is legible commit by commit in the repository (https://github.com/hyperscalers/hyperscale-rs/commits/main) across 31 August and 1 September 2026: an expiry given to a nullifier "in its value and in its key" (https://github.com/hyperscalers/hyperscale-rs/commit/2fc94538) , the key led by the bucket its expiry falls in (https://github.com/hyperscalers/hyperscale-rs/commit/bfdd430c) , a shard's sweepable cells indexed by expiry bucket (https://github.com/hyperscalers/hyperscale-rs/commit/62624b8a) , a bound on how many one block may create (https://github.com/hyperscalers/hyperscale-rs/commit/7e344942) , expired cells retired at a frontier the header states (https://github.com/hyperscalers/hyperscale-rs/commit/67967557) (694 additions across twelve crates, the largest of the set), a from-scratch commit made to state what it removes (https://github.com/hyperscalers/hyperscale-rs/commit/2d3730aa) , and a test watching a real nullifier leave state once nothing can reach it (https://github.com/hyperscalers/hyperscale-rs/commit/966e8e51) . On 1 September the set closed the way this project closes design work: a 560-line Quint model (https://github.com/hyperscalers/hyperscale-rs/commit/82bf799c) , specs/substate_sweep.qnt, registered as Model K — one module for a chain's frontier walk and one for what a successor's cursor starts at, with everything else (consensus, execution, the index that finds the candidates) left as an oracle, and with the "twins" that deliberately break the invariants written beside the model, the same technique described under Formal Verification below. The second item in the same digest is smaller and unrelated to the sweep: intents now carry a signed header naming the network they are for (https://github.com/hyperscalers/hyperscale-rs/commit/17d5dbb7) , so an intent naming a network its envelope does not is refused, and a transaction's validity window narrows to the intersection of every intent it binds (https://github.com/hyperscalers/hyperscale-rs/commit/c88e690b) . Both close cross-network replay. The digest names integrating the sweep into shard execution as the next step. Crate Structure The project is a Cargo workspace of 33 crates (https://github.com/hyperscalers/hyperscale-rs/tree/main/crates) , with the execution engine's seven more in the vm/ submodule beside it, organised on one principle: every subsystem with an I/O or timing dependency is a trait with a production backend and a simulation backend beside it, which is what makes the deterministic harness possible. Networking (network-libp2p / network-memory), storage (storage-rocksdb / storage-memory), task dispatch (dispatch-pooled / dispatch-sync), signing (crypto-bls / crypto-mock) and metrics (metrics-prometheus / metrics-memory) all follow the pattern. The consensus-critical crates are shard (per-shard BFT: block proposal, voting, view changes, committee enforcement), beacon (the global control plane – topology, committee membership, leaderless prefix consensus, shuffling, economic parameters), execution (tick assembly, conflict detection and execution-vote aggregation into certificates), provisions (batched cross-shard provision messages and their verification), remote-headers (header sync for light-client verification of remote shards), jmt (the binary Jellyfish Merkle Tree, generic over its hasher), effects-bridge (the workspace's binding to the VM's effect vocabulary: decode, admit and route) and engine (the batch executor over the VM kernel — tick execution, fee settlement and receipt projection). Around them sit types, core, mempool, node and production. Tooling accounts for the rest: simulation and simulator host the deterministic harness used for routine 300-node validation runs; scenarios holds portable behavioural tests written once against an abstract cluster interface and run on both the simulator and a real multi-process cluster, so a scenario that passes on one and fails on the other is by construction a real defect rather than a flaky test; spammer generates load; and demo is the WebAssembly build behind the in-browser network demo. The structure matured through 2026: networking, sync and dispatch were extracted into dedicated modules, the earlier bft, messages and topology crates were consolidated into shard, beacon was added for the control plane, the signing layer was split into crypto with paired backends, and test-helpers was retired in favour of scenarios. In August 2026 effects-bridge was added for the VM seam and the vocabulary shifted with it: the unit of execution a block commits is a tick and a finalized wave is a finalization, renamed across the codebase on 8 August ( "Call the execution batch a tick everywhere" (https://github.com/hyperscalers/hyperscale-rs/commit/fa1a37e0) ) and carried into attestation by PR #143 (https://github.com/hyperscalers/hyperscale-rs/pull/143) the following day. "Wave" no longer appears in the design. Performance Consensus: the 300-node deterministic simulation (April 2026) The project routinely runs full simulations against the deterministic harness to validate design changes. A 300-node simulation reported on 13 April 2026 (https://t.me/hyperscale_rs) demonstrated the operating characteristics targeted for production: Nodes 300 Transactions submitted 30,000 Transactions completed 23,950 (within 30s window) Average TPS 798 Peak TPS 1,147 Latency p50 6.35 s Latency p99 7.75 s Lock contention 0.00% Total messages 9,438,658 Per-shard throughput targets are roughly 1,000 TPS at ~5 second finality, which the lead developer describes as a deliberate trade-off: rather than chase sub-second finality (bounded by the irreducible complexity of atomic commit), the project targets validator hardware that home users on consumer fibre can operate, with running costs estimated at "a few dollars a month." Higher per-shard throughput (10,000 TPS) is technically configurable but would require fibre and multi-core machines beyond the home-validator profile. Linear network scale comes from adding shards rather than scaling individual shards harder. Execution throughput against the Radix Engine (August 2026) The simulation above measures consensus. It says nothing about the execution layer, which is the part that changed in August — and until 19 August 2026 there was no public number on the purpose-built VM (https://github.com/hyperscalers/hyperscale-vm) that replaced the Radix Engine (/contents/tech/core-protocols/radix-engine) in the stack. That evening the lead developer published one, in a repository built for the purpose: hyperscalers/vm-comparison (https://github.com/hyperscalers/vm-comparison) , "throughput comparison between HS-VM and RE", created at 17:34 UTC with a single commit, "Initial bench." (https://github.com/hyperscalers/vm-comparison/commit/20a2ef88) , two minutes later. It measures one question: how many plain token transfers one core can put through, from a received transaction to a committed store. Both engines are pulled by git URL at a pinned revision — hyperscale-vm at 418027a3, radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) at 92c7db3e (develop, v1.3.0 plus one merge) — so neither side depends on a local checkout or drifts between runs. Both are compiled by one toolchain (Rust 1.96.0) under one release profile, and both are timed across the same three stages: validate, execute, commit. Composing, encoding and signing the transaction happen at a wallet, so both sides pre-build outside the timed loop and time only what a node does with a transaction that has arrived. Every transfer has a distinct sender, so neither engine is measured against a single hot cell. On an Apple M-series machine, 1,000 transfers, best of three rounds: Stage hyperscale (µs/tx) Radix Engine (µs/tx) Ratio validate 7.95 2.88 0.4× execute 29.58 792.55 26.8× commit 1.82 2.48 1.4× total 39.35 797.91 20.3× transfers/second 25,412 1,253 20.3× Execution is the whole of it: 30 µs against 793 µs. Hyperscale is the slower of the two at validate, where it pays for admission and shard routing that Babylon has no counterpart for. The Radix Engine figure is checked against the engine's own criterion benchmark rather than taken on trust: radix-engine-tests --bench transfer reports 833 µs over a single hot account pair, and this harness reports 798–826 µs across rounds, so the distinct-sender population and the stage instrumentation cost the Radix Engine nothing measurable. What the number is not. The harness publishes its own list of differences that are architectural rather than artifacts of the measurement, and they cut both ways. An XRD transfer touches no wasm engine at all on the Radix Engine, whose Account is a native Rust blueprint compiled into the engine; hyperscale instantiates its account component twice per transfer and calls into wasmtime, so the faster number is paying a wasm bill the slower one is not. Against that, a valid Babylon transaction must lock_fee, which is a vault touch plus fee-reserve accounting and settlement — the hyperscale VM has no fee concept at all, and metering is fuel handled by the chain layer above it. Neither side verifies signatures, neither computes a state root, and both run against a plain in-memory map. A Scrypto-blueprint transfer — which would put the Radix Engine's wasmi interpreter on the same footing as hyperscale's wasmtime, and is the comparison that actually isolates the two wasm engines — is named in the repository as the obvious next one to build, and has not been built. The four-core figure is a ceiling, not a result. The README extrapolates one core to four and arrives at "up to ~102,000 tx/s" against a flat 1,253, and is explicit that this is what perfect scaling would give rather than a prediction: the parallel executor spawns one OS thread per conflict group instead of drawing on a bounded pool, shared-memory effects are unpriced, and plain transfers are the best case for the design rather than the typical one — a single contended AMM cell under exclusive write serialises completely and extra cores buy nothing. What is not extrapolation is the Babylon side being flat. The state manager's committer executes one ledger sequentially, one state version per transaction, and the reason is structural rather than unfinished: a manifest's references are a visibility grant naming which globals a call frame may address, not a declared access set, and the substates a transfer actually touches are reached by owned-node descent during execution. There is no sound conflict set before the transaction runs, so there is nothing for a scheduler to group on. Spare cores on a Babylon node go to consensus, networking, the API and signature verification, never to execution. Why the answer to more throughput is more shards (August 2026) The 20.3× figure invites the obvious follow-up: how much further can the VM itself be pushed? On 20 August 2026 a channel member put that question to an AI coding assistant against the repository and posted the exchange (https://t.me/hyperscale_rs/10741) — does hyperscale use a register-style instruction set mapped onto the hardware, as Solana (/contents/tech/comparisons/radix-vs-solana) does with SBF, rather than stack-shaped bytecode? The lead developer's reply treated micro-optimisation as the wrong axis altogether: “there's no real need to throw the kitchen sink at micro compute optimizations. the bottleneck for per-shard throughput will pretty much always be bandwidth as hs-vm will be plenty fast (competitive with SOTA). and it's better to just add additional shards, rather than try to squeek out further marginal bumps which might have to come at the cost of expressiveness” (https://t.me/hyperscale_rs/10745) . Three commitments are packed into that. Per-shard throughput is expected to be bandwidth-bound rather than CPU-bound, which is consistent with the shape of the benchmark above — 39 µs of execution per transfer is nowhere near the constraint at a per-shard target of roughly 1,000 TPS. Scaling is therefore horizontal by design: more shards, not a faster instruction set, which is the same conclusion the consensus section reaches from the other direction. And expressiveness is treated as a budget that micro-optimisation spends — the narrower and more hardware-shaped an instruction set becomes, the less the language above it can express, and the project is unwilling to trade in that direction for marginal gains it does not need. The practical reading for this page is that the execution figures above are a margin, not a target. The VM's job is to stay comfortably inside the per-shard budget set by the home-validator hardware profile, and the throughput story is told by shard count. Transaction Flow The lifecycle spans three phases. Pre-consensus: a user signs a transaction externally and submits it via an RPC gateway; the node converts the raw bytes to internal events and performs cross-shard analysis to determine which NodeIDs (components, resources, packages, accounts) are touched; transactions enter shard-specific mempools, and cross-shard transactions are propagated to all involved shards via libp2p Gossipsub. BFT consensus: proposer selection is deterministic per round, the proposer builds a block from mempool transactions, validators authenticate it and broadcast votes, and a quorum certificate forms when 2f+1 (~67 of 100) votes are collected – the QC is not sent as a separate message but assembled by the next proposer from collected votes. The block commits when a certificate forms for a child at exactly the next round, per the round-contiguous two-chain rule; a QC alone is not a commit. Execution and finality: committed transactions execute per shard, and cross-shard settlement follows the coordinator-free provision–execute–certify pipeline described under Architecture. A transaction is final when execution certificates from every participating shard carry a success outcome for it; one abort anywhere is terminal. Running a Node What it takes to operate a Hyperscale node was described publicly for the first time on 4 August 2026, when a community member asked whether one could run reliably on a Raspberry Pi 5 with an NVMe SSD, given how much CPU, RAM and storage performance a Babylon node needs today. The lead developer answered "almost certainly, and possibly multiple" (https://t.me/hyperscale_rs/10419) : serving Radix-level load "shouldn't be resource intensive", at generally less than 10% of a single CPU core and ~200 MB of RAM, with storage bounded by shard splits rather than growing without limit. Two caveats came with the figures – the transaction load at which a Pi would stop coping was left unquantified, and the numbers "will change a lot with the new VM which should be much more efficient", so they describe the current consensus-layer implementation rather than the execution layer Xi'an is expected to ship. Connectivity and jailing Asked whether a home validator should mirror its node onto a second internet connection as a backup, the developer discouraged the pattern. A backup connection such as 5G is reasonable if an operator has the means, but "you shouldn't need a separate node for that though - just failover at the network layer" (https://t.me/hyperscale_rs/10422) – and more to the point, "you really shouldn't need to have that at all": a node that drops "should just get jailed, and you can unjail yourself when your connection is back up". That is the inference-based tier of the accountability design described above, where missed proposals and beacon absence jail a seat temporarily and lift after a cooldown, without touching stake. Impounding, and what triggers it Asked when slashing would come into play, the answer was that it does not: "i implement impounding, not slashing" (https://t.me/hyperscale_rs/10424) . A convicted operator's stake locks for 90 days – "though that's just a default - it's configurable with governance" – which stops a node runner repeating attacks in a short space of time without destroying capital permanently, a trade-off chosen so that it "won't be too punitive to those who're just delegating". The protocol documentation had described the freeze only as a governed span; this is the first stated figure for it. The same message drew the boundary of the mechanism more sharply than the documentation does. Impounding "is only for provable byzantine actions. Not just being offline, or slow" – an operator would have to "willfully modify the client software to double vote, or to send multiple proposals for the same round to different validator sets", faults that carry unforgeable signature evidence. Downtime and slowness stay in the jailing tier. Delegation and stake pools Asked whether XRD holders will still delegate to node operators and earn rewards as they do under Babylon's validator system, the developer described the model as "more or less the same" (https://t.me/hyperscale_rs/10430) , with one change of unit: "instead of staking/delegating to a single validator/node - you instead stake/delegate to a 'stake pool' which might run multiple nodes". That is the delegator-facing view of the stake-pool model above, in which an operator may seat at most one active validator per unit of the current minimum stake. Why cheap hardware is not the sybil surface A member put the obvious objection to the developer: if the hardware bar is a Raspberry Pi and the penalty is a lockup rather than a capital wipeout, what stops a wealthy actor spinning up thousands of cheap nodes to grind liveness to a halt? The reply was one line – "they'd still need to stake them all" (https://t.me/hyperscale_rs/10428) . What bounds the validator population is the seat price, recomputed every epoch inside the beacon fold, not the cost of the machines: "if there's an over abundance of nodes (more than needed for the topology) - then the price of a seat will keep going up" (https://t.me/hyperscale_rs/10439) , at which point "you probably don't want to cheap out on hardware to such an extreme" for stake of that size. Running nodes on phones was raised in the same thread and dismissed on operational grounds rather than protocol ones – "mobile OSs sleep apps aggressively to save power" (https://t.me/hyperscale_rs/10435) . What another shard costs, and what a demand spike does (August 2026) The figures above price one node. On 30 August 2026 a channel member argued that Hyperscale's node requirements were a genuine differentiator against other networks, "a big issue on most nets, Radix included" (https://t.me/hyperscale_rs/11203) . The lead developer declined the energy framing, and in declining it gave the first public arithmetic for what capacity costs in validators rather than in hardware: to get more throughput "you have to have another 128 nodes online (granted there is some variable amortization via vnodes)... plus you need a free pool online to draw shuffle replacements from" (https://t.me/hyperscale_rs/11204) . Both halves are protocol rather than rhetoric. A split is gated on the free validator pool being deep enough to staff it (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/02-dynamic-sharding.md) , and the epoch fold prices activation against committees times committee size, plus a standing reserve (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/00-overview.md) . What is new is the framing: an increment of throughput has a validator price, and the standing reserve is part of it. The 100-shard version of the same arithmetic, 12,800 small validator nodes against Solana's roughly 1,000 large ones (https://t.me/hyperscale_rs/11206) , is the channel member's extrapolation and not a project figure. Later that day another member put four questions (https://t.me/hyperscale_rs/11213) to the developer, and the four answers (https://t.me/hyperscale_rs/11214) are the most compact statement of the operating story so far. Throughput and latency under realistic DeFi load "depends on the hardware and network links of the validators". Running a node is "not very" painful, with a qualification that dates the client work: a GUI validator client is "still pending building", and the goal is "for complete amateurs to be able to run". A demand spike is answered by topology rather than by headroom, "shards split into more shards (as long as there are enough free nodes to support a split) freeing up more execution capacity", which is the same free-pool dependency arriving from the user's side. The fourth question, on whether the architecture forces redundancy that eats the theoretical gains, was returned as a question, and the answer to it is the multi-stage routing work recorded under Contention above. One follow-up sharpened the third: how well splitting absorbs a spike depends mechanically on how fast a shard splits (https://t.me/hyperscale_rs/11216) , which is a latency the project has not published. On power specifically the developer put a home node below noticeability, "doing Radix-level TPS... won't even add enough to your computers power draw to appear as a rounding error on your electric bill" (https://t.me/hyperscale_rs/11217) , and in the same exchange gave an unflattering reading of what today's mainnet actually costs to run: "everyone is just basically signing empty blocks at the moment. Babylon should only really need a small fraction of a single core... it's crazy inefficient" (https://t.me/hyperscale_rs/11222) . He then declined to quantify any of it, which is the caveat the rest of this section should be read under: "people can provide their own experience with energy use during testnets. it's not worth spending any time thinking about before then. particularly as the software is pre-alpha and still changing every day" (https://t.me/hyperscale_rs/11225) . Nothing here is a measurement. Xi'an RFC and Funding (April–May 2026) On 20 April 2026, flightofthefox posted an RFC for delivering Xi'an for Radix (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) to the governance forum, framing hyperscale-rs as the production candidate for the Xi'an mainnet release and structuring funding around six delivery milestones, with the codebase to be relicensed under Apache 2.0 on acceptance. That relicensing landed on 7 August 2026 (https://github.com/hyperscalers/hyperscale-rs/commit/91db7add4a917d8bf382b6b2a250577983e57cff) , and went further than the RFC specified — see Licensing under Development & Community below. Total budget $300,000 USD-equivalent across acceptance and five delivery milestones, paid in XRD (30-day TWAP per payment) Bonus 50M XRD on Milestone 6 (mainnet launch) Timeline 18 months to mainnet-ready delivery, plus a 12-month post-launch support window. Best case: testnet Q4 2026, mainnet Q1 2027 Governance Milestones signed off by the Radix Accountability Council (/ecosystem/radix-accountability-council) ; neutral third-party arbitration for disputes Termination No exit fees if the project is paused or terminated at any milestone boundary Milestones - M1 – Validator lifecycle and consensus engine: dynamic topology, node shuffling, validator joining/leaving, the staking model. Reported complete on 7 August 2026 (https://t.me/hyperscale_rs/10474) ; one deferred item, splitting shards on fees rather than storage size alone, waits on the fee system, which in turn waits on the VM. - M2 – Engine–Gateway alignment: API breaking changes required for sharded operation - M3 – Gateway rewrite for sharded data - M4 – Alpha desktop validator application (cross-platform), targeted at home validators on consumer hardware - M5 – Post-quantum cryptography integration - M6 – Mainnet launch with 12-month support window Solo-Developer Risk The proposal acknowledges that the project remains a solo effort and that adding contributors mid-flight would extend the timeline rather than accelerate it. Three options are offered for key-man risk: a larger proposal employing a second person, DAO-purchased key-man insurance, or accepting the single point of failure given the milestone-based payment structure. The lead developer's stated preference is that documentation and design discussions stay public so other parties can build the knowledge to maintain the network long-term – "we have to get to a world where multiple entities have a stake (and the knowledge to) maintain the network." Funding Status In May 2026 the Milestone 1 funding moved through the community's Consultation V2 process: a temperature check passed within two days and was promoted to a binding proposal requiring a roughly 940M XRD quorum. Because the Foundation's and RDXH (/ecosystem/radix-foundation) 's holdings sit in custodial vaults and cannot vote, reaching quorum depended on community turnout; the Foundation confirmed it would issue the Milestone 1 payment directly, contingent on clear community consensus, rather than wait the minimum two months for the DAO to be constituted. Work began in mid-May 2026. As of mid-June the formal community DAO (MIDAO) had still not been finalised after several months of legal setup, but development proceeded on the direct Foundation grant; later milestones remain dependent on the DAO and its treasury coming online. Until April 2026 the project ran on community donations through the FoxFund initiative, which the lead developer then asked supporters to redirect into voting for the RFC: "no more donations tho lads — just support foxy proposal for xi'an if you want to give back." Funding Withdrawn (3 September 2026) That arrangement ended in one sentence. At 00:28 UTC on 3 September 2026, three days into the network halt (/contents/history/hyperlane-asset-drain-2026) , the lead developer wrote in the project channel that he had “decided not to pursue any proposal, grants or ongoing engagements with radix as a network, dao, or otherwise” (https://t.me/hyperscale_rs/11644) . Asked at once whether the project would continue, he said it would (https://t.me/hyperscale_rs/11647) : “yes, hyperscale will continue. and radix is free to adopt the protocol as they wish. it is an open project.” On delivery he was explicit (https://t.me/hyperscale_rs/11653) : “i don’t anticipate any change in the velocity of delivering the tech… the tech will be delivered because i think it is good.” The reason he gave was the relationship rather than the amount: “i just don’t want anything to do with people who think some minuscule grant has purchased me for particular project.” (https://t.me/hyperscale_rs/11649) Each message is confirmed as his at its own public embed. The withdrawal was stated in the channel only. Re-read on 3 September 2026, the RFC topic (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) holds fifteen replies whose last is dated 4 May 2026, and is neither closed nor archived, so the proposal stands on the forum unaltered. For this article the consequence is confined to the funding and governance terms: the five unpaid milestones, the Accountability Council sign-off on each of them, the named arbitrator and the funder’s no-exit-fee stop at any boundary all lapse with the proposal, while the licence granted in August 2026 is irrevocable and the code, the roadmap and the single-author concentration described throughout this article are unchanged. Whether the DAO can still adopt the result is a question about adoption rather than about funding, and the only answer on the record is that Radix is free to do so. What the Withdrawal Covers (3 September 2026) Between 09:18 and 11:00 UTC the same morning, pressed in the project channel over what the withdrawal meant, the lead developer answered the questions the first four messages had left open. The exchange was adversarial — his counterpart for most of it was a channel admin arguing that the position was ambiguous (https://t.me/hyperscale_rs/11778) and that “if you build scaling for Radix it’s underpaid” — and the answers are correspondingly blunt. Each is confirmed as his at its own public embed. The scope is future grants, not the work. Asked directly whether he no longer wished to receive funding beyond what had already been paid out, he answered: “How much more clear can I be? I do not wish to pursue additional grants from Radix” (https://t.me/hyperscale_rs/11822) — and separated that from any principle, “not particularly because I think that steering organisations of decentralized networks should not support open source devs working on their technical foundations. Merely because irrational counterparties like yourself make the whole experience miserable.” He had put the same point more plainly an hour earlier: “The idea I would stop working on it if not paid is laughable to me… I just don’t want to deal with the bullshit associated with taking any grants because people run roughshod over any parameters specified anyway.” (https://t.me/hyperscale_rs/11765) Where the withdrawal message of 00:28 UTC gave the relationship as the reason, this states the mechanism: the grant is what gives the dispute a surface, so removing the grant removes the dispute — “if the root of our disagreements is compensation, I’d rather just take the matter off the table.” (https://t.me/hyperscale_rs/11775) What the Foundation payment bought was narrower than the RFC schedule. Rejecting the reading that a grant had made him Radix’s technical lead, he described the terms of what was actually paid: “I have always been 100% clear there was never any obligations of either side to continue… the foundation payment was very clear that the only deliverable was open-sourcing work completed to date.” (https://t.me/hyperscale_rs/11740) That is a materially smaller commitment than the six-milestone table above implies, and it is discharged: the dual MIT/Apache-2.0 licence committed to both repositories on 7 August 2026 (https://github.com/hyperscalers/hyperscale-rs/commit/91db7add4a917d8bf382b6b2a250577983e57cff) is the deliverable, and it is irrevocable. On that account nothing is owed in either direction, which is consistent with a withdrawal announced without notice or settlement. No payment record has been published. The only figure on the record entered the conversation from the questioner, who asked whether he no longer wished to receive funding “past the $50k or whatever it was already paid out” (https://t.me/hyperscale_rs/11821) ; the developer’s reply took the number up sarcastically rather than confirming it — “that $50k which became $25k will fund hyperscale for the rest of time and it will require no sacrifices on my part.” (https://t.me/hyperscale_rs/11801) Neither the Foundation nor the developer has published an amount or a payment date, so the wiki records the exchange rather than a figure. The halving it describes is what the RFC’s own mechanism does: payment is denominated in USD but settled in XRD at a 30-day TWAP, so a payment fixed in dollars and taken in a falling token is worth what the token is worth when it is sold, and the price has since fallen further still (/contents/history/hyperlane-asset-drain-2026) . Radix is not stated to be the destination. The sharpest disagreement was over whether hyperscale-rs is being built for Radix. He declined the framing twice — “you just choose to completely ignore the clear parameters I’ve always had (that Hyperscale is an open source project)” (https://t.me/hyperscale_rs/11760) — and put the goal in terms that name no chain: “the only thing I particularly care about is the tech being adopted… in any format that takes” (https://t.me/hyperscale_rs/11790) , and “I would much rather just work on the tech and give it away to anyone and everyone.” (https://t.me/hyperscale_rs/11796) Asked why not simply launch a chain of his own with a token, he refused that too: “talk about monetization of the tech is actually a thing that undermines my motivation.” (https://t.me/hyperscale_rs/11795) For Xi'an (/contents/tech/releases/radix-mainnet-xian) the consequence is precise and worth stating plainly: the licence lets Radix adopt this code, and the author says he would welcome anyone adopting it, but as of 3 September 2026 there is no commitment from him that Radix is where it lands. He closed the exchange on the only thing he did commit to — “I’m just going to wake up again tomorrow and keep working on the tech anyway.” (https://t.me/hyperscale_rs/11807) The withdrawal has a price, and it was about a week from being paid. Through the afternoon of 3 September the same developer put a figure on what the decision costs him, without naming an amount: “If I was trying to hyper-optimize for some financial gain I would wait a week for RDX to pay out M1… I’m not though, I just want to work on the tech and try to keep my sanity and dignity.” (https://t.me/hyperscale_rs/11875) That dates a pending Milestone 1 payment from RDX Works to roughly 10 September 2026 and places the withdrawal ahead of it rather than after it — the first statement from either side that the milestone schedule was still live and paying when it was abandoned. No payment record has been published, and the sum is not stated; the figures circulating in the channel come from questioners rather than from either party and are not recorded here. The same message is also the fullest commitment yet made to the work itself, and it is broader than the RFC: “And work on it i will. Through all the stages of VM, and gateway, and desktop validator, and everything else in the milestones. And even all the additional ideas I’ve thought of along the way like privacy solutions.” (https://t.me/hyperscale_rs/11875) Read alongside the refusal earlier the same morning to say that Radix is where the code lands, the position is now specific on both halves: the six-milestone programme survives the withdrawal, the funding does not, and the destination is still unstated. On the tokens already earmarked for it he was explicit that they should go elsewhere — “The game theoretic optimal play of the DAO is to reallocate those earmarked tokens toward getting users or something” (https://t.me/hyperscale_rs/11851) — and on his own position, “The only person who really needs to worry about funding is me…. and I’m not worried.” (https://t.me/hyperscale_rs/11904) What Becomes of Radix (11 September 2026) Eight days later, on the evening of the day mainnet committed its first round in ten days (/contents/history/hyperlane-asset-drain-2026) , the channel asked the half of the question 3 September had left open. Where that morning had settled what the withdrawal covers and refused the framing that Hyperscale is built for Radix, nobody had yet got an answer on the obverse: what the people holding XRD should now expect. The question came after an exchange in the channel over how much of Dan Hughes (/contents/history/dan-hughes) 's research the project inherits, and it was put directly — will a new network be built, what happens to our tokens, what are your objectives regarding this community. At 23:04 UTC he answered both halves in one message, and the first half is the position already on the record stated more broadly than before: “i intend for hyperscale to be an open source project in the most exemplary sense… i want to focus on building good primitives, and it doesn't matter overmuch to me who ends up using them” (https://t.me/hyperscale_rs/12194) . The second half is new, and it is a refusal rather than a plan: “i think you hit on your actual question with ‘what will become of us?’ i don't know mate. it is not really something that i have any control over — and as such, i don't think about at all.” The message is confirmed as his at its own public embed. Read against the rest of this section the position is now complete rather than partial, and the completion matters for Xi'an (/contents/tech/releases/radix-mainnet-xian) as a release plan. On 3 September he declined to name Radix as the destination; on 11 September he declined to hold a view on the destination's fate. The licence still lets Radix adopt this code and the author still says he would help migrate state “if Radix still exists, and the DAO wants help” (https://t.me/hyperscale_rs/11403) , so nothing technical has closed. What has closed is the reading that the author is holding a plan for the network in reserve. Any such plan has to come from whoever adopts the protocol, and on the record that is not him. The Upgrade Path, Named (12 September 2026) Four hours later the same channel put the technical half of that question, and got the first answer the project has given that names Radix and says yes. At 02:35 UTC a holder asked what open source means here beyond the licence, and framed the alternatives: “is it being designed as a scaling solution that could conceivably be bolted on to Radix via a network upgrade? Or is it basically a standalone network?” (https://t.me/hyperscale_rs/12241) The first reply restated the licence rather than the design — “it is free for anyone to use. free as in free” (https://t.me/hyperscale_rs/12242) — and was told it had not answered the question. He asked “what part is not clear? i will do my best to clarify” (https://t.me/hyperscale_rs/12244) , the question was put again in one line, and at 03:03 UTC he answered it: “of course, not any more than any other network, but yes. 100% there is an upgrade path, and i would sherpa that path” (https://t.me/hyperscale_rs/12246) . Every message in the exchange is authorship-verified at its own public embed. Two things in that sentence are worth separating, because the subsection above turns on the difference. The upgrade path exists, and he says he would guide Radix along it: that is a commitment about the technology and about his own labour, and it is new on the record. The priority does not: ‘not any more than any other network’ places Radix among the candidates rather than at the head of them, which is the same position as 3 September stated from the other direction. Nothing here reverses the refusal of 11 September either. He still holds no view on what becomes of the people holding the token; what he has now said is that if the network chooses to adopt this protocol, the route is real and he would walk it with them. Formal Verification (July–August 2026) Deterministic simulation testing, described above, runs the system thousands of times against hostile schedules and replays any failure forever. It cannot say what happens on the paths it never walked. Since 3 July 2026 the project has run a second programme beside it: machine-checked models of the protocols themselves. The repository's specs/ directory (https://github.com/hyperscalers/hyperscale-rs/tree/main/specs) holds ten protocol models written in Quint (https://quint.sh/) , a specification language in the TLA+ family, and checked with Apalache (https://apalache-mc.org/) , a symbolic model checker, through quint verify. The first commit added a model of the weighted-time clock (https://github.com/hyperscalers/hyperscale-rs/blob/main/specs/wt_clock.qnt) ; the directory has taken 63 commits (https://github.com/hyperscalers/hyperscale-rs/commits/main/specs) since, the most recent on 24 August 2026. The properties are not invented model by model. They come from the project's invariant register (https://github.com/hyperscalers/hyperscale-rs/blob/main/docs/08-invariants.md) , which gives every safety and liveness claim a stable identifier: 75 of them across eight families (INV-SEC, INV-SHARD, INV-BEACON, INV-EXEC, INV-RESHAPE, INV-DET, INV-STATE, INV-ECON), with the execution layer's own properties kept in the VM (/contents/tech/core-protocols/vm-layer) 's separate register. A model cites the IDs it checks rather than restating them, which makes the register a verification worklist rather than documentation. The ten models Scope and status as recorded in specs/README.md (https://github.com/hyperscalers/hyperscale-rs/blob/main/specs/README.md) , read 24 August 2026. Apalache is exhaustive within an explicit depth bound, so a status of "verified" means the property held over every behaviour the rules permit inside that bound. Model Scope Properties Status A wt_clock The weighted-time clock: per-vote clamp, quorum mean, admission plausibility, epoch resolution INV-SHARD-6, INV-BEACON-3/4 Verified B shard_consensus Shard consensus, the HotStuff-2 variant: safe-vote rule, round-contiguous commit, crash recovery INV-SHARD-1..4 Verified (depth 8) C atomic_commitment Cross-shard atomic commitment with shard consensus as a commit oracle: abort dominance and success unanimity INV-EXEC-1/5 Verified (depth 10) D straddler_settlement Settlement across a shard scheduled to terminate mid-transaction: the settled-set fence, sweeps, late materialisation INV-RESHAPE-5/6 Verified E beacon_spc Beacon consensus in three layers: the Prefix Consensus value algebra, epoch ratification by pool quorum, and the view layer INV-BEACON-1 (single epoch) Verified (depths 5–10) F reshape_lifecycle The beacon-side reshape fold: trigger admission, frozen-seed cohort draw, readiness, the seating gate, shuffle staffing INV-RESHAPE-1/7/8/9/10, INV-SEC-2 Verified G shard_recovery Recovery when the Byzantine premise itself has failed: halt detection, the recovery bridge, the cross-shard freeze INV-SEC-8/9, INV-SEC-2 Verified H witness_fold The governance-leaf accumulator and the epoch randomness a boundary crossing carries: exactly-once and coverage INV-BEACON-2/3/10/11 Verified I reshape_handoff The reshape cut and successor genesis: the seam between a terminating chain and the committees continuing its state INV-RESHAPE-2/3/4/11, INV-BEACON-5/8 Verified (depths 4–13) J vm_fee_assurance Cross-shard fee assurance: the payer's reservation, commit-proof-gated engagement, and the validity-window abort INV-VM-OBJ-2, INV-VM-HOST-1/2/3 Verified (depth 12) The models compose by abstraction rather than by size: each takes an earlier model's verified properties as axioms, so B resolves committees through A's clock, C treats a shard chain as the commit oracle B justifies, and D adds shard termination on top of C. No model contains the whole system, which is the point. A statistical companion, SEC-1 (https://github.com/hyperscalers/hyperscale-rs/blob/main/specs/committee_security.md) , prices the premise every model assumes (fewer than one third of any committee Byzantine) with concentration bounds and Markov analysis instead of a reachability check. The discipline Four rules in specs/README.md do most of the work, and each answers a way this kind of programme usually goes wrong. Properties come from the register, so a model cannot quietly check something easier than what the system claims. Transitions come from the code, not the docs: every modelled rule names its implementing crate, file and function in a comment, on the grounds that a model transcribed from prose verifies the documentation rather than the system. Every model ships a broken twin, an instance whose rules violate the property's precondition so that quint verify must produce the counterexample, because "a checker that has never produced a counterexample against the model proves nothing about the model". And a finding is not closed until it is traced through the implementation and resolved as a code change, a documentation change, or a stated non-issue. Checking runs in three tiers: quint typecheck, then quint run for fast random search, then quint verify, which hands the model to Apalache for an exhaustive search to a bounded depth (ten steps by default). Counterexamples are written out as ITF JSON traces, the format a future bridge could replay directly against the Rust state machines. What the models have found Two results are on the record. Modelling the beacon's agreement layer against Prefix Consensus for Censorship Resistant BFT (https://arxiv.org/abs/2602.02892) (Xiang, Tonkikh and Spiegelman, February 2026), the algorithm it implements, surfaced a real divergence: in one corner case the implementation resolved a value's parent differently from the paper, legal-looking and wrong under exactly the right absence of data. The model produced the recipe, the deterministic simulator replayed it as a failing test, and the fix landed with a permanent regression scenario pinning it; the deviation now survives only as model E's parent_of broken twin, which forks two replicas on one committed value with no Byzantine action at all. The second is less comfortable and is published as such. Model G takes as its premise that the Byzantine assumption has already failed, and its Finding G-1 is an Apalache counterexample rather than a pass: because a retained committee beyond the one-third bound can drag the quorum's weighted timestamp arbitrarily, a folded replica can admit an orphan commit past a halted shard's tip. The mitigation modelled and implemented alongside it is a beacon-mandated freeze that revokes a halted committee's cross-shard authority network-wide at detection, and the honest conclusion recorded with it is that the band between f+1 and 2f corrupt members is "a bounded-exposure regime, not a clean recovery". What is and is not claimed The project states the limits itself, in the register and in the public explainer hyperscale.rs/proof (https://hyperscale.rs/proof) , posted to the project channel on 24 August 2026 (https://t.me/hyperscale_rs/10838) . First-pass models of the critical core exist and are being checked; the register is a to-do list worked through in the open, not a completed proof. A model is not the code, and keeping the two in agreement is a separate obligation, made tractable because the consensus core is already written as pure transition functions and kept honest by replaying every counterexample against the implementation. And model checking is exhaustive only inside its bounds: small committees, short horizons, on the bet that protocol bugs have small witnesses. specs/README.md says it plainly, that bounded checking is not proof, with inductive invariants named as the upgrade path once a model stabilises. None of this is an external review. No audit has been commissioned, and the project's own position on when one should happen is recorded in the section below. Security Review and Audit (August 2026) Hyperscale-rs has not been audited, and in August 2026 the channel worked through when it should be. The thread opened on 13 August with a community post (https://t.me/hyperscale_rs/10600) about the Bitcoin Red Team's use of frontier language models to scan open-source code at scale, and the question it put to the project was as much a governance one as a technical one — how the DAO (/contents/tech/core-concepts/radix-governance) should assist, and when. A message in the same thread later that evening set the aspiration plainly: the hope is to afford an audit that takes place before the Xi'an mainnet release (https://t.me/hyperscale_rs/10601) . The project lead, flightofthefox, answered the timing question directly on 14 August. A red-team initiative is "a very good idea" (https://t.me/hyperscale_rs/10622) , he wrote, but not now: large sections of the codebase relating to execution and the VM are still work in progress, so pointing models at them "will just generate a lot of noise over incomplete code, or areas i already know need attention". The right moment is the first release candidate or testnet, which he expects to be "a very fun exercise". He added one redirection for anyone wanting to start sooner — the currently deployed network (https://t.me/hyperscale_rs/10623) is the more useful target today. That places security review after the purpose-built VM (/contents/tech/core-protocols/vm-layer) is feature-complete rather than alongside it, and it makes the first testnet, not mainnet, the point at which external scrutiny is invited. It is a position stated in a public channel by the person writing the code, not a published policy, and no audit has been commissioned or funded as of this writing. Post-Quantum Signatures (August 2026) The Xi'an RFC (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) puts post-quantum cryptography at Milestone 5, and through the first half of 2026 the project treated it as deferred work. The first post-quantum scheme nevertheless landed on 16 August 2026, four milestones early, as a twenty-nine-line change to the execution layer's type crate: "Register ML-DSA-65 in the signature scheme registry." (https://github.com/hyperscalers/hyperscale-vm/commit/4e5dea0bf4547594c9931bbf15a7d0766b714878) ML-DSA-65 (https://csrc.nist.gov/pubs/fips/204/final) is the middle parameter set of the lattice signature standard NIST published as FIPS 204 in August 2024. In crates/types/src/scheme.rs (https://github.com/hyperscalers/hyperscale-vm/blob/main/crates/types/src/scheme.rs) it takes scheme id 3, behind Ed25519 (1) and secp256k1 (2) — the two Babylon already accepts. The registry is a table of exact widths and prices rather than of arithmetic, and the cost of the new scheme is visible in it: Scheme Public key Signature Verification cost Ed25519 (RFC 8032) 32 bytes 64 bytes 1 ECDSA secp256k1 ( Olympia (/contents/tech/releases/radix-mainnet-olympia) ) 33 bytes 64 bytes 2 ML-DSA-65 (FIPS 204) 1,952 bytes 3,309 bytes 3 Cost is denominated in Ed25519 verifications, so a quantum-resistant signature verifies for three times the price while occupying roughly fifty times the bytes on the wire — the reason the widths live with the encoding vocabulary rather than with the cryptography, since a crate that cannot see which scheme produced a signature cannot charge for verifying it. The scheme is registered as pure ML-DSA under the empty context string rather than the pre-hash variant, because the message this path presents is already a digest and hashing it twice would put two preimages behind one signature. Registered is not accepted The commit does not turn post-quantum signing on. The registry deliberately declines to say which schemes a network accepts at a given height — describing a scheme is a vocabulary question, enabling it is a protocol-version question — and the workspace carries no curve arithmetic at all, leaving verification to whatever an embedder supplies through the SchemeVerifier trait. What the change buys is that a scheme can be sized, priced and encoded ahead of any chain accepting it. Asked in the project channel whether this implied a migration like Olympia→Babylon, the lead developer answered that Babylon has two signing schemes today and this simply adds a third (https://t.me/hyperscale_rs/10675) : existing holders would upgrade when they chose to, through account securification (https://docs.radixdlt.com/docs/account/#account-securification) — the same mechanism behind multi-factor accounts, which rewrites an account's authorisation rules without changing its address. Addresses may still change at the Xi'an upgrade, but for an unrelated reason: a new address space with owner-based prefixing (https://t.me/hyperscale_rs/10678) , so an account and its vaults sit together rather than scattered across the shard space. The lead developer also placed the work outside the milestone structure entirely — post-quantum cryptography is "a cross cutting concern, it'll just be done as appropriate" (https://t.me/hyperscale_rs/10687) — and drew the distinction that matters for how much of the problem this solves: transaction signing is "the very easy part of PQ", while the larger piece is post-quantum consensus signing and verification, which involves zero-knowledge constructions, WOTS+ and XMSS (https://en.wikipedia.org/wiki/Hash-based_cryptography) . The registry entry is the easy half, arriving first. The verifier, fifty-one seconds later The registry's silence about acceptance lasted less than a minute in practice. At 02:46:29 UTC the consensus repository committed "Support transaction signing and verification under ML-DSA-65" (https://github.com/hyperscalers/hyperscale-rs/commit/aa1adef93009) — 249 lines, a new crates/types/src/crypto/ml_dsa.rs, and changes to the transaction wire and VM types — supplying exactly the arithmetic the execution layer's registry declines to carry. Two scenarios followed within the half hour: a securify scenario exercising the post-quantum upgrade flow (https://github.com/hyperscalers/hyperscale-rs/commit/f9a4ced38efd) at 03:00, and a virtual/native ML-DSA-65 account scenario (https://github.com/hyperscalers/hyperscale-rs/commit/ba81891c5544) at 03:18. So the upgrade path the lead developer described in the channel is not a plan — it is a test. What remains outstanding is the part the split was designed to keep separate: no network has been versioned to accept scheme 3, and the post-quantum consensus signing that the same message called the larger problem has not been attempted. Light Clients and State Proofs (August 2026) Everything this page describes about reading the ledger goes through a node or a Gateway, and a Gateway is an API you trust. On 20 August 2026 a developer in the project channel asked whether the current design would let a web application verify state and finality itself (https://t.me/hyperscale_rs/10747) — taking compact cryptographic proofs and checking them locally in WASM, rather than trusting an API response. The answer was that the infrastructure is intended but unbuilt, and that the cryptography is the part already solved: “at some point I will build out light client infra. All the building blocks exist for it since the whole cross-shard execution flow basically is a light client flow already” (https://t.me/hyperscale_rs/10752) . That follows from the architecture above rather than being a new commitment: cross-shard commitment without a coordinator already requires one shard group to accept a claim about another group’s state on evidence instead of on trust, which is the same operation a light client performs against a proof. What is unsolved is economic. Serving proofs is work, and the design has nowhere to charge for it: “Validators can’t be expected to serve state proofs to anyone on demand without capturing some kind of fee” (https://t.me/hyperscale_rs/10752) , and in any case “nor do you really want the active validator set doing that kind of work when they should be validating and executing” (https://t.me/hyperscale_rs/10754) . Asked whether light clients would themselves serve these requests as an incentive to run one, the answer separated the two roles flatly: “light clients are the consumers, not the servers” (https://t.me/hyperscale_rs/10759) . The lead developer also set the ceiling on what this would buy, which is lower than the framing usually implies. Even if the serving side ends up looking like a Gateway — a small number of archive nodes answering proof requests — it would still be “a step up from needing to trust a gateway completely” (https://t.me/hyperscale_rs/10758) , because the response can be checked rather than believed. But proofs do not subsume a Gateway. They are considerably larger than the data they attest, and a Gateway earns its place by aggregating state into answers to complex queries, where a state proof answers only that a given value sits at a given substate key (https://t.me/hyperscale_rs/10758) . Different applications need different things, and the exchange stops short of saying which of them Xi’an will serve first. Development & Community hyperscale-rs is developed openly with an active Telegram community (https://t.me/hyperscale_rs) that grew from 319 members at the project's public unveiling in February 2026 to 451 members by June 2026. Day-to-day development is tracked through automated GitHub commit notifications in the channel, and the lead developer answers design questions there directly – several sections of this page are sourced to those exchanges. Licensing Both repositories were public but carried no licence file from their creation — hyperscale-rs since 7 December 2025, hyperscale-vm since 30 July 2026 — which under default copyright means the code was readable but came with no grant to use, modify or redistribute it. The RFC had committed to relicensing "on acceptance", and the project was described as open source throughout the interim; forty-five minutes before the licence existed the lead developer called it "just an open source consensus stack" (https://t.me/hyperscale_rs/10497) . That gap closed on 7 August 2026. Asked in the project channel at 21:12 UTC whether there was a plan to add the licence (https://t.me/hyperscale_rs/10499) , the answer arrived five minutes later as a commit rather than a reply: "Add license." (https://github.com/hyperscalers/hyperscale-vm/commit/c05e5665db04ce9ffecd6d1c27c92460a33d4925) to hyperscale-vm at 21:17:15 UTC and the same commit (https://github.com/hyperscalers/hyperscale-rs/commit/91db7add4a917d8bf382b6b2a250577983e57cff) to hyperscale-rs eighteen seconds after it, followed by a note in the channel that it had been "also added to the additional new repo" (https://t.me/hyperscale_rs/10502) . The terms are broader than the RFC specified. Each repository carries both LICENSE-APACHE (https://github.com/hyperscalers/hyperscale-rs/blob/main/LICENSE-APACHE) and LICENSE-MIT (https://github.com/hyperscalers/hyperscale-rs/blob/main/LICENSE-MIT) , copyright "The Hyperscale Contributors", and declares license = "MIT OR Apache-2.0" in its workspace Cargo.toml (https://github.com/hyperscalers/hyperscale-rs/blob/main/Cargo.toml) — the dual-licence convention the Rust standard library and most of the crates ecosystem use, letting a downstream user take whichever of the two suits them. The README adds the standard inbound-equals-outbound clause: contributions are dual licensed on the same terms unless a contributor states otherwise. The practical consequence is that the consensus stack, the formal Quint specifications and the execution engine can now be forked, vendored into another project, or maintained by a party other than the current lead developer — the key-man risk the RFC itself raised, addressed by licence rather than by contract. Contributors - flightofthefox ( proven.network (https://proven.network) ) – lead developer, ~2,500 commits, sole driver of the architecture - kaldeberger – secondary contributor, ~70 commits - shambupujar, dazligth, cyril88888, pprogrammingg – community contributors - wizzl0r – channel owner, PR reviews and testing infrastructure - Radical – code reviewer and author of the community transaction-flow documentation Milestone 1 Timeline March–May 2026 – 376 commits between 20 March and 5 May, almost entirely from flightofthefox, consolidating the consensus core: networking extracted into dedicated crates, consensus advancement decoupled from durable persistence, BFT hardening across vote validation and quorum arithmetic. On 13 April the lead developer declared the foundations done – "all the major foundational consensus pieces are pretty solid now. Not anticipating any more major changes just light tidy ups and doc work from here." May–June 2026 – Milestone 1 proper, summarised by the lead developer as "650+ commits" over roughly a month: the beacon chain on leaderless prefix consensus; the stake-pool model and market-driven economic parameters; shard-to-beacon integration via header attestations; enshrined snapshots and snap-sync joining; the trickle shuffling model; the state tree reorganised into a prefix subtree of one global merkle trie so splits and merges need no re-indexing; first-cut virtual nodes; and a first cut of live shard splitting and merging. 2 July 2026 – publication of the design-documentation set (https://github.com/hyperscalers/hyperscale-rs/tree/main/docs) and the rendered explainer site at hyperscale.rs (https://hyperscale.rs) , intended as the primary reference for anyone producing explainers about the project. Mid-July 2026 – the consensus implementation reported as "pretty much finished" (https://t.me/hyperscale_rs) , with work shifting to verification, minor tweaks and rigour in the security mathematics. Fee integration and post-quantum cryptography were deferred to later phases. The remaining stack work was described as the execution layer, gateway and desktop validator – more approachable for outside contributors than the consensus core, and an open invitation was extended to community developers. 13–19 July 2026 – a complete shard halt-recovery system: a frozen shard can be detected, re-staffed with a fresh committee, and restored without losing or duplicating in-flight cross-shard transactions, closing one of the last resilience gaps in the validator-lifecycle layer. Roughly 60 commits that week. 20–26 July 2026 – Milestone 1 at roughly 76% in its thirteenth week. The headline result was the resharding cut-over: the exact moment a shard splits or merges is now derived through a single, tested, formally modelled path, described as the "keystone of adaptive sharding". The same week added fork fencing – validators checked for equivocation, forks fenced at the shard level, and a proven double-signer's key permanently revoked rather than temporarily jailed – and rebuilt the signing layer around dedicated BLS (https://en.wikipedia.org/wiki/BLS_digital_signature) and mock implementations behind clean traits. Roughly 125 commits, about double the previous week. Next up is folding validator-shuffling logic into production using the newly finalised timing parameters. 27 July 2026 – a live in-browser demo (https://hyperscale.rs/demo) compiling the node's SimulationRunner to WebAssembly and running a multi-shard network inside a browser tab. The visualisation – a shard trie showing weighted time and BFT attestations, a network view for transaction tracing, and an event log – is stepped from the page's own animation frame rather than replayed from a recording, so every mark derives from committed chain content computed on the fly. The run is deterministic (seed 42, four validators per shard) and byte-for-byte reproducible. Roadmap and Public Testing The Milestone 1 timeline is roughly four months, targeting around the end of August 2026. The first public tests are targeted for Q3 2026; rather than repeat the Foundation's one-off set-piece tests, the project intends to run longer-lived testnets that participants can register nodes into and out of at will – a model that was blocked until the beacon chain existed to manage which validators are registered. Early tests will be limited because the execution layer has not yet been adapted for sharding: expect simple transactions and validator fees rather than full smart-contract support. Migration from Babylon The eventual switch from Babylon to Xi'an will not be an in-place upgrade. The lead developer expects a process modelled on the Olympia→Babylon transition: the network is halted at an agreed epoch by vote, state is dumped and imported into the new client (programmatically, after many dry runs), with validators running both clients across the handover epoch. State is re-indexed on ingestion as part of a move from an Aptos-style Jellyfish Merkle Tree to a pure binary JMT better suited to multiproofs, and the hashing algorithm changes in the same step. External Links - GitHub Repository – hyperscalers/hyperscale-rs (https://github.com/hyperscalers/hyperscale-rs) - GitHub Repository – hyperscalers/hyperscale-vm (https://github.com/hyperscalers/hyperscale-vm) (the purpose-built execution layer) - Hyperscale Project Overview – official documentation site (https://hyperscale.rs) - In-Browser Network Demo (WebAssembly) (https://hyperscale.rs/demo) - Design Documentation – /docs (overview + invariant register) (https://github.com/hyperscalers/hyperscale-rs/tree/main/docs) - Formal Models – /specs (Quint + Apalache) (https://github.com/hyperscalers/hyperscale-rs/tree/main/specs) - RFC: Xi'an – Delivering Hyperscale for Radix (radixtalk) (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) - Telegram Community – hyperscale-rs for Radix (https://t.me/hyperscale_rs) - Prefix Consensus for Censorship-Resistant BFT (paper) (https://arxiv.org/abs/2602.02892) - Radix Labs Roadmap – To Hyperscale and Beyond (https://www.radixdlt.com/blog/radix-labs-roadmap---to-hyperscale-and-beyond) - Hyperscale Update – 500k+ Public Test Done (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) - Wiki: Radix Mainnet (Xi'an) (/contents/tech/releases/radix-mainnet-xian) - Wiki: Hyperscale 500K TPS Public Test (/contents/tech/research/hyperscale-500k-tps) - Wiki: Radix Accountability Council (/ecosystem/radix-accountability-council) ## Verifiability URL: https://radix.wiki/policy/verifiability Updated: 2026-09-12 Summary: Verifiability is the first standard on RADIX Wiki: the threshold for including material is whether readers can check that it comes from a reliable, pu… Policy Verifiability Type Sourcing policy (core) Underpins No original research (/policy/no-original-research) , Freshness (/policy/freshness) Applies to Every article Enforcement [citation needed] tags; Needs citations notice banner Adopted 31 July 2026 Verifiability is the first standard on RADIX Wiki: the threshold for including material is whether readers can check that it comes from a reliable, published source – not whether an editor is personally convinced it is true. [1] (#ref-1) Any statement likely to be challenged, and every quotation, should carry an inline citation to a source. Reliable sources Prefer primary Radix documentation, the project's own repositories, peer-reviewed papers, and the on-chain record. The Radix ledger is itself a primary source: an asset supply, a component's state, or a transaction can be cited directly via the Gateway API (https://docs.radixdlt.com/docs/network-gateway) or a ledger explorer. [2] (#ref-2) Marketing copy and unattributed forum posts are weak sources and should be replaced. A chat message is the ordinary case on this wiki rather than the exception, and citing one (#citing-a-chat-message) has a procedure of its own. Checking a Radix claim Most of what this wiki asserts is about a running system, so the check is usually mechanical: read the thing itself rather than an account of it. Five failure modes recur often enough to be worth naming, and each has a worked example on the wiki. A dashboard is not the ledger Aggregators break quietly and keep serving a number. DeFiLlama has reported zero TVL for Surge (/ecosystem/surge) every day since 25 March 2026 – 148 consecutive daily readings through 19 August 2026, taken from its own API series (https://api.llama.fi/protocol/surge-trade) rather than from the dashboard (https://defillama.com/protocol/surge-trade) , which returns 403 to a script – while the pool component its adapter reads held 32,562.60 sUSD when queried directly at epoch 336,270 on that last day. Cite the component state; treat the dashboard as the claim to be checked, not the source that settles it. Official documentation can be wrong Radix Docs gives the Cuttlefish mainnet enactment (https://docs.radixdlt.com/docs/cuttlefish) as “Epoch: 105353”. That is Bottlenose’s (/contents/tech/releases/protocol-updates) epoch; Cuttlefish enacted at epoch 160923. One Gateway request settles which is right, and where the ledger and a documentation page disagree, the ledger is the source and the disagreement is worth stating. A project’s website is not its status Whether a homepage loads says nothing about what a project is doing on-ledger, and the example this section has carried since August proved it twice. Leaf Node (/ecosystem/leafnode) ’s validator unregistered on 10 August 2026 and registered again six days later, at 11:41:48 UTC on 16 August ( epoch 335,461 (https://dashboard.radixdlt.com/transaction/txid_rdx1x80208v5xezsyuvh0jydrplt8uwgmsmlpexv634fu3236qr8nfjslysr0y/summary) ), without announcing either move. Read live at epoch 340,083 (12 September 2026, 03:08 UTC, the morning after mainnet restarted), it is registered and sits 41st of the 100 validators in the active set with 25,573,394.53 XRD – 0.5616% of the 4.55 billion XRD securing the network – on a 1% fee, with the 100% fee still queued for epoch 341,223. It has climbed four places since 23 August while holding 147,067 XRD less, because the active set’s total stake fell further than its own did: a rank is a fact about everyone else. Throughout all of it leafnode.info (https://www.leafnode.info) answered 503, as it did again on the re-read: the site said nothing when the validator quit, nothing when it came back, and nothing across a twelve-day network halt. This page is itself the cautionary half of that example. It described the validator as unregistered for seven days after it was not, because a status read once was written down as a standing fact. Status fields on ecosystem pages are taken from is_registered, a component’s state, or a resource’s supply – never from whether a site responds – and each one is a reading with a date attached, which is why freshness (/policy/freshness) is a sourcing policy rather than a tidiness one. An on-ledger reading is not a true one The ledger is a primary source, but for the right claim. Reading a component’s state tells you what that component holds, not what is the case in the world, and where the two are confused the ledger will state a falsehood with perfect precision. On 30 August 2026 Weft Finance (/ecosystem/weft-finance) ’s price cache recorded HUG at 1,330.41 XRD per token. That reading is genuine, current and citable, and it is wrong by about ten million times: HUG traded at 0.000131 XRD the same day. One transaction turned the gap into 71 million XRD of debt drawn against collateral bought for 70.6 XRD. The correction is not to distrust the ledger but to name what a reading is a source for. A resource’s supply, a vault balance, an NFT’s data, is_registered on a validator: these are facts about the ledger, and the ledger settles them outright. A price, a valuation, a website, a social handle, a status label: these are claims the ledger merely stores on someone’s behalf, and a second, independent source settles them. Cite the first as fact. Cite the second as what a named component published, with the time it published it. A release is not its contents A version tag, a “latest release” badge and a downloadable artifact are metadata about a build, not evidence of what is in it, and during an incident the difference is the whole story. On 8 September 2026, babylon-node (https://github.com/radixdlt/babylon-node) published v1.3.0.5-test.1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5-test.1) , its first release since June and the first tag in the repository’s history to use -test rather than -rcN; not being flagged a pre-release, it became what GitHub returns as the latest. The commit behind the tag is the merge of a CI and Dockerfile change (https://github.com/radixdlt/babylon-node/pull/1075) , and that merge’s first parent is the commit tagged v1.3.0.5 – the version mainnet was running when it halted (/contents/history/hyperlane-asset-drain-2026) . The fix (https://github.com/radixdlt/babylon-node/pull/1076) was on a different branch, which GitHub compares as diverged from the tag. Resolve the tag to its commit, read the commit’s parents and its diff, and check which branch it sits on. A release page answers when something was built and by what; it does not answer what was built. A status endpoint is not the ledger Two Gateway endpoints answer what looks like the same question and do not. /status/gateway-status reports the tip the Gateway aggregator has ingested; /stream/transactions reports what the ledger committed. While both numbers are moving the difference is invisible, and while neither is moving it is a published falsehood. Through the twelve days mainnet was down this wiki gave the last round before the halt as state version 557,840,622, epoch 339,896, round 102, at 21:19:06.179 UTC on 31 August 2026, in some forty consecutive readings across two articles. The ledger had run on. Read from /stream/transactions (https://docs.radixdlt.com/docs/network-gateway) at state version 557,840,615 ascending, three further user transactions commit in epoch 339,897 round 1 and a round update closes the ledger at state version 557,840,627, epoch 339,897, round 4, timestamped 2026-08-31T21:19:48.939Z – five state versions and forty-three seconds past the figure that was published. The next commit is state version 557,840,628 at 11:35:28.960 UTC on 11 September 2026, and the first user transaction after the restart lands at 11:39:25.129 UTC. The general form: a status endpoint answers what have I seen, and a boundary question needs what is there. A failed fetch is not a dead source Automated link checking produces false positives in bulk: Medium, LinkedIn, SSRN, CoinGecko and Cloudflare-fronted sites routinely return 403, 429 or 999 to a script while serving the page normally to a reader. Confirm with an ordinary browser request before removing a citation. A sound source deleted on a false positive is harder to recover than a dead link left in place for one more pass. Where a claim cannot be checked against the ledger or a filed document – an off-ledger treasury balance, an unannounced roadmap, a private agreement – write what is known, attribute it to whoever said it, and state plainly what is not established. An honest gap is preferable to an inference (/policy/no-original-research) presented as a fact. Citing a chat message Much of what this wiki learns first is said in a Telegram channel, and its citations show it. Read on 12 September 2026, 504 links across 73 of the wiki’s 376 pages point at one individual Telegram message – 180 into the hyperscale-rs (https://t.me/hyperscale_rs) channel, 131 into Radix DLT Official (https://t.me/radix_dlt) , 85 into the Accountability Council’s (https://t.me/RadixAccountabilityCouncil) . They gather where no other record exists: 126 on hyperscale-rs (/contents/tech/research/hyperscale-rs) , and 64 across the two articles covering the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) – the most-read page on the site and the day-by-day timeline (/contents/history/hyperlane-asset-drain-2026-timeline) split out of it on 11 September. The section above calls an unattributed forum post a weak source, and a chat message arrives unattributed by default. What follows is the step that changes that. The message arrives without its author A public channel read through Telegram’s API returns four things per message: the channel, a numeric id, a timestamp, and the text. It does not return who wrote it. A quotation taken from that read alone carries a checkable date and a speaker the editor supplied, which is the shape no original research (/policy/no-original-research) rules out – the reading is real and the attribution is an inference. The embed settles the author Every message in a public channel also has a public embed, and the embed names who posted it. Requesting https://t.me//?embed=1&mode=tme returns that single message rendered with the display name and handle of its author, above the channel title. Two read while this section was written: the Accountability Council’s status update at 11:02 UTC on 4 September 2026 (https://t.me/RadixAccountabilityCouncil/971) resolves to projectShift, and the message this wiki cites for Astrolescent’s (/ecosystem/astrolescent) funding resolves to Timan | Astrolescent, handle @djtrebel. Cite the plain message URL in the article, and read the embed before you do. One failure here is silent. Where the cited message is a reply, the embed renders two messages – the one requested first, then the one it answers – and each carries its own author block. t.me/radix_dlt/1001809 (https://t.me/radix_dlt/1001809) renders as Timan | Astrolescent answering Jon-Eric Cook, so taking the name from the second block credits the quotation to the person being answered, and the finished citation looks correct either way. Take the first author block, and check whether the reply marker points at a message id other than the one requested. What an embed establishes, and what it does not An embed establishes that a handle posted this text in this channel at this time. It does not establish that the display name belongs to the person it names, and it says nothing about whether the text is true. A chat message is a source for what someone said, dated and attributed, and it enters an article as attribution rather than in the wiki’s own voice, per neutral point of view (/policy/neutral-point-of-view) . Where the speaker is describing their own work, their own project, or their own withdrawal from one, that is the claim they are a strong source for. A figure that enters a conversation from the person asking is not sourced by the answer. Asked in September 2026 whether he was giving up funding “past the $50k or whatever it was already paid out” (https://t.me/hyperscale_rs/11821) , the author of hyperscale-rs (/contents/tech/research/hyperscale-rs) took the number up sarcastically (https://t.me/hyperscale_rs/11801) , and neither he nor the Foundation has published an amount or a payment date. That page quotes both messages and records the exchange; it does not record $50,000 as a sum paid. The general form is narrow: a number is sourced by whoever can be shown to have asserted it, and a question is not an assertion. Citations needed When a claim lacks a source, mark it with a [citation needed] tag rather than deleting it outright. The tag is a pointer for whoever reads the page next, and it costs nothing to leave in place while the source is hunted. Read on 19 August 2026, the tag appeared on exactly one page – this one, in the examples above. Read again on 12 September, after 888 further revisions, that is still the count. No article carries it. That is not evidence that every claim on the wiki is sourced; it is evidence that the tag is not part of how this wiki is actually edited, and the section below explains why. Maintenance banners Rather than delete imperfect material, mark it. RADIX Wiki carries six top-of-article notice banners; any editor can add one from the block editor, and each renders a fixed label and message that a custom note can override. [3] (#ref-3) Banner Use it when In use Stub The article is too short to cover its subject and needs expanding. 2 Needs citations Claims are unsourced or carry [citation needed] tags. 0 May be outdated Facts have decayed – see freshness (/policy/freshness) . 0 Written like an advertisement The prose is promotional – see neutral point of view (/policy/neutral-point-of-view) . 3 Needs cleanup Structure, formatting, or duplication needs work. 0 Conflict of interest A major contributor may be connected to the subject – see conflict of interest (/policy/conflict-of-interest) . 0 Banners in practice The In use column is a count, not an estimate. One query over the pages table on 12 September 2026 found five editor-placed banners across 376 pages, the same five the query returned on 19 August: the Stub notice on application layer (/contents/tech/core-protocols/application-layer) and kernel layer (/contents/tech/core-protocols/kernel-layer) , and the Written like an advertisement notice on three ecosystem pages. Four of the six variants have never been placed on anything, including the two that other policies here instruct editors to reach for. When this section was written there was plenty to flag: forty of the wiki’s 361 articles held under 1,500 characters of prose, twenty-five held under 1,000, and the two carrying a Stub notice were neither the shortest nor among the shortest ten. Re-measured on 12 September, the thin tail has more than halved – 18 of 367 articles under 1,500 characters and 11 under 1,000 – and the two Stub pages are now the shortest on the wiki at 735 characters and the third-shortest at 769. The notices did not move. Everything around them was filled in until they were accurate. The mechanism explains the count better than any judgement about editors does. Of 2,338 revisions written in the ninety days to 12 September 2026, 2,317 – 99.1% – came from the single account that runs the rotating maintenance sweep (/contents/tech/operations/wiki-maintenance-log) . A banner is a message addressed to the next editor, and here the next editor is that same pass coming round again, which fixes a thin or unsourced page in place rather than labelling it for a later visit that is also itself. The one notice that does appear at scale is the one no editor places: the May be outdated stamp, generated at render time from a page’s own dates by the freshness rule (/policy/freshness) . So the honest rule, in place of an instruction nobody follows: place a banner when the fix is beyond the current pass – when the source exists but finding it is a session’s work, when the subject needs an expansion the sweep cannot write from the material to hand, when a page reads as its subject’s own copy and rewriting it fairly needs someone who knows the project. Otherwise fix it now. A banner left in place of a repair that took two minutes is worse than no banner, because it tells a reader the wiki knows and did nothing. Remove a banner when the problem it names has been fixed, and say so in the revision message – the history is public. See also - Neutral point of view (/policy/neutral-point-of-view) - No original research (/policy/no-original-research) - Notability (/policy/notability) - Freshness (/policy/freshness) - Conflict of interest (/policy/conflict-of-interest) - Editorial notices (/policy/editorial-notices) References: 1. Wikipedia – Wikipedia:Verifiability (https://en.wikipedia.org/wiki/Wikipedia:Verifiability) 2. Radix – Network Gateway API (https://docs.radixdlt.com/docs/network-gateway) 3. RADIX Wiki – BANNER_META, src/components/BlockRenderer.tsx (https://github.com/tutmoses/radix-wiki/blob/main/src/components/BlockRenderer.tsx) ## Dev WG · Fund & steward the Xi’an protocol upgrade & Radix Engine URL: https://radix.wiki/ideas/dao-xian-protocol-upgrade Updated: 2026-09-11 Summary: Protocol upgrades (the Xi’an line of work) and Radix Engine maintenance previously sat with Foundation-funded teams. The DAO must decide how it funds… Working Group Core Development WG Governance Phase Phase 2 – activity-triggered Champion Open (protocol contributors) Origin Strategic Council – Innovation area (https://radixtalk.com/t/rfc-radix-strategic-council/2266) Latest 1 Aug 2026 – the Radix Engine is not being adapted; a purpose-built VM is underway Protocol upgrades (the Xi’an line of work) and Radix Engine maintenance previously sat with Foundation-funded teams. The DAO must decide how it funds and directs continued core-protocol R&D so the roadmap does not stall during the handover. What the scope became (1 August 2026) This card was written when "Xi'an and Radix Engine work" read as one continuous line of maintenance. It is not. On 1 August 2026 the hyperscale-rs lead developer told the project's Telegram channel that the Radix Engine is not being adapted for sharding – asked whether it was built for it, the reply was "it's not in the ballpark. it's not in the same zip code as the ballpark" (https://t.me/hyperscale_rs/10332) – and that a purpose-built VM is underway (https://t.me/hyperscale_rs/10334) in its place, because "the sharding adjustments are so many that it'd require touching everything. at some point it becomes easier to start with intention than to retrofit" (https://t.me/hyperscale_rs/10336) . Later the same day came the confirmation that of the three migration options framed in April, the two that would have spared existing dApps – unchanged blueprints, and a dual modality running beside a legacy environment – "have dissolved" (https://t.me/hyperscale_rs/10340) . What this means for Scrypto (/developers/scrypto) was asked in the same session and drew no answer. That changes what a funding decision here is actually for: a new execution layer, plus a migration for everything already built on the current one, rather than continued maintenance of the Radix Engine. It also widens the acceptance question in the deliverables below, since a dry-run protocol upgrade rehearses a release, not a change of execution environment. The message-by-message record is on hyperscale-rs (/contents/tech/research/hyperscale-rs) . The funding decision lost its counterparty (3–11 September 2026) The deliverables below ask the DAO to identify who carries Xi'an, and to scope and budget that work through an RFP. Both assume a willing recipient. At 00:28 UTC on 3 September 2026 the author of the only candidate implementation removed himself from that position, writing in the hyperscale-rs (/contents/tech/research/hyperscale-rs) channel that he had “decided not to pursue any proposal, grants or ongoing engagements with radix as a network, dao, or otherwise” (https://t.me/hyperscale_rs/11644) , and confirming the same morning that the scope of the refusal is future funding rather than the work: “I do not wish to pursue additional grants from Radix” (https://t.me/hyperscale_rs/11822) . The RFC (https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) that this card's budget question was built around stands on the forum unaltered and unfunded. On 11 September 2026, asked directly in the channel what becomes of the community and its XRD now, he answered the adoption question and declined the stewardship one in the same message: “i intend for hyperscale to be an open source project in the most exemplary sense… i want to focus on building good primitives, and it doesn't matter overmuch to me who ends up using them” (https://t.me/hyperscale_rs/12194) , and on what becomes of Radix holders, “i don't know mate. it is not really something that i have any control over — and as such, i don't think about at all.” Authorship is confirmed at the message's own public embed. That leaves this card a genuine decision rather than a stalled one, and changes what it is a decision about. The dual MIT/Apache-2.0 licence committed in August 2026 is irrevocable, so the code is available to Radix whether or not anyone is paid to bring it here; what is not available is the author's commitment that Radix is where it lands, or his participation in an RFP. The question the DAO now faces is adoption and integration — who ports, tests and operates someone else's open-source protocol, and who migrates the state onto it — not the R&D procurement this card was drafted to settle. The developer has said he would help with a state migration “if Radix still exists, and the DAO wants help” (https://t.me/hyperscale_rs/11403) , which is the one piece of the handover still offered. Deliverables - Identify the teams/contributors who will carry Xi’an and Radix Engine work. - Scope and budget continued protocol development via RFP. - Define acceptance/verification for protocol releases (see dry-run upgrades). Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Prioritized under the product roadmap (/ideas/dao-product-roadmap-ownership) . - Released safely via the dry-run upgrade process (/ideas/dao-protocol-dry-run-snap) . Sources - RFC: Radix Strategic Council (Innovation & Product) (https://radixtalk.com/t/rfc-radix-strategic-council/2266) - Consultation v2 – Product Scope (https://radixtalk.com/t/consultation-v2-product-scope-document/2193) ## Dev WG · Deliver the Dry-Run Protocol Upgrade & MetaMask Snap URL: https://radix.wiki/ideas/dao-protocol-dry-run-snap Updated: 2026-09-11 Summary: Two development workstreams the DAO could fund early: a rehearsal of a mainnet protocol upgrade, and a MetaMask Snap that would let Radix reach people… Working Group Core Development WG Governance Phase Phase 2 – activity-triggered Champion talesofbeem (both threads) MetaMask Snap None listed for Radix in the MetaMask allowlist (https://acl.execution.metamask.io/latest/registry.json) , read 28 August 2026 Origin Dry-Run RFC (https://radixtalk.com/t/rfc-dry-run-protocol-upgrade/2168) · MetaMask Snap RFC (https://radixtalk.com/t/rfc-metamask-snap-integration/2161) Two development workstreams the DAO could fund early: a rehearsal of a mainnet protocol upgrade, and a MetaMask Snap that would let Radix reach people through the wallet they already run. Both began as forum threads in January 2026. Neither has been formalised, and between them they run to seven posts. The dry-run protocol upgrade talesofbeem opened the dry-run thread (https://radixtalk.com/t/rfc-dry-run-protocol-upgrade/2168) on 25 January 2026 with the problem underneath it: most of the developers who built the protocol have moved on, and anyone who wants to change the Radix Engine needs to know they can test that change against a running network first. The proposal is to complete a protocol upgrade end to end, relearning the stack in the process, on an upgrade whose payload does not matter. projectShift gave the rehearsal its shape in the same thread. Change the protocol's moniker and nothing else, then plant two faults on purpose: a comment marking where the bug is, and something that halts the network. The exercise then tests debugging, rollback and redeployment rather than the happy path alone. talesofbeem agreed to fold monitoring and a halted network into the write-up. The thread has stood at three posts since that day. The MetaMask Snap The Snap thread (https://radixtalk.com/t/rfc-metamask-snap-integration/2161) opened three days earlier, on 22 January 2026, and its argument is about where effort goes. Maintaining one exclusive Radix wallet spends the Foundation's resources against a field of more than 130 web3 wallets, while Sui, Cosmos, Starknet and Near reach MetaMask users through snaps instead. Jon-Eric Cook proposed hardware-wallet support as the step after, and the author agreed it could be the next integration. The author was explicit that the thread is not a proposal: he opened it for comment and left formalising it through on-chain governance to any developer who wanted to take it up. Nobody has. MetaMask's allowlist registry (https://acl.execution.metamask.io/latest/registry.json) carried 186 verified snaps when this page was checked on 28 August 2026 and none of them is Radix's, so what this card needs is a package and a champion rather than a decision. The rehearsal was overtaken by the real thing (11 September 2026) The dry-run thread's premise is that nobody left on the network has taken a protocol upgrade through end to end, so the next person to change the engine should practise on an upgrade whose payload does not matter. On 11 September 2026 the upgrade that mattered went first. Eagle Ray (/contents/tech/releases/protocol-updates) enacted at the start of epoch 339,898 to close the engine flaw behind the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) , and it is the only protocol update in Radix's mainnet history that enacts on an epoch number rather than on a validator readiness signal. Each element projectShift specified for the exercise has a counterpart in what actually happened, which is why the comparison is worth making rather than a coincidence. A running network to test against: the node runner coordinating the release told the developer group the sequence had been “testing extensively over the last days/week” (https://t.me/RadixDevelopers/66389) on test networks. A fault planted on purpose: a VaultDrainer blueprint that had been “hammering on the unpatched test networks, The moratorium and the enacted network” (https://t.me/RadixDevelopers/66391) . A halted network to recover from: mainnet, which produced no round for 254 hours. The fix was then proved against mainnet itself rather than against a rehearsal of it — the blueprint was published to mainnet at 12:35 UTC and the call that drains a vault was refused (https://t.me/RadixDevelopers/66392) , permanently rejected with the new SystemError::InvalidInvokeAccess. For this card the consequence is narrow and it favours one deliverable over the others. Rehearsing the mechanics is worth less now, because the mechanics have been exercised under real load by the people who would have run the rehearsal. Writing the result up is worth more, because the process the next upgrade follows now has a worked mainnet precedent instead of a hypothetical one, and that precedent currently exists only as Telegram messages and a commit history. The Radix Accountability Council (/ecosystem/radix-accountability-council) asked for a few days before it publishes a report (https://t.me/RadixAccountabilityCouncil/1026) when it announced the restart at 14:37 UTC; that report is the nearest thing to the write-up this card asks for, and it is not the DAO's. The MetaMask Snap half of the card is untouched by any of it. Deliverables - Fund and run one protocol upgrade end to end, moniker only, with a deliberate liveness break to exercise debugging and rollback. - Write up the result as the process the next real upgrade follows. - Build, publish and maintain a Radix MetaMask Snap, and take it through the allowlist. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - The rehearsal is for the Xi'an protocol upgrade (/ideas/dao-xian-protocol-upgrade) , which is the next real one; the Snap sits alongside stewardship of the Radix Wallet (/ideas/dao-steward-radix-wallet) . Sources - RFC: Dry Run Protocol Upgrade (https://radixtalk.com/t/rfc-dry-run-protocol-upgrade/2168) (25 January 2026, three posts) - RFC: Metamask Snap Integration (https://radixtalk.com/t/rfc-metamask-snap-integration/2161) (22 January 2026, four posts) - MetaMask Snaps allowlist registry (https://acl.execution.metamask.io/latest/registry.json) ## Radix Compared URL: https://radix.wiki/contents/tech/comparisons Updated: 2026-09-11 Summary: Radix makes choices that have no counterpart on most networks: assets are engine primitives rather than balances inside contracts, authority is carrie… Compared against Ethereum, Solana, Cosmos, Polkadot Protocol comparison Cerberus vs other BFT protocols (/contents/tech/comparisons/cerberus-vs-other-bft-protocols) Radix consensus Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Radix execution Radix Engine (/contents/tech/core-protocols/radix-engine) and Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Radix makes choices that have no counterpart on most networks: assets are engine primitives rather than balances inside contracts, authority is carried by badges (/contents/tech/core-concepts/badges) that are themselves resources (/contents/tech/core-concepts/resources) , and the state model is sharded by design rather than by appended rollups. Described in isolation those choices read as a list of adjectives, so each page here takes one network the reader already knows and works out where Radix diverges, what the divergence buys and what it costs. How to read them Radix vs Ethereum (/contents/tech/comparisons/radix-vs-ethereum) is the load-bearing one, because the account-and-contract model is the picture most readers arrive with. All of these pages are written on a wiki about Radix, so read them with the caution that deserves: where a claim is contested or a Radix feature has not shipped they say so, and Radix’s branch of the architectural fork is the one with the least mainnet evidence behind it. ## Radix Protocol Releases URL: https://radix.wiki/contents/tech/releases Updated: 2026-09-11 Summary: Radix names its major network releases after cities of the ancient world, and each added a layer the last had done without: Olympia opened the public… First mainnet Olympia (/contents/tech/releases/radix-mainnet-olympia) , July 2021 Current mainnet Babylon (/contents/tech/releases/radix-mainnet-babylon) , 28 September 2023 Babylon enactment Epoch 32,717 Next mainnet Xi’an (/contents/tech/releases/radix-mainnet-xian) Public test network Stokenet (/contents/tech/releases/stokenet) Smaller updates Protocol updates (/contents/tech/releases/protocol-updates) , two to three a year Naming Cities of the ancient world Radix names its major network releases after cities of the ancient world, and each added a layer the last had done without: Olympia (/contents/tech/releases/radix-mainnet-olympia) opened the public ledger in July 2021 with staking and the native XRD (/contents/tech/core-protocols/xrd-token) token and no smart contracts at all; Alexandria (/contents/tech/releases/radix-developer-environment-alexandria) gave developers a Scrypto (/contents/tech/core-protocols/scrypto-programming-language) environment in December 2021, for an engine mainnet could not yet run; Babylon (/contents/tech/releases/radix-mainnet-babylon) brought that engine live on 28 September 2023; and Xi’an (/contents/tech/releases/radix-mainnet-xian) is where sharding (/contents/tech/core-concepts/sharding) , the half of the design every release so far has deferred, has to arrive. How a release lands A release changes the rules every node runs, so it cannot be adopted piecemeal: operators upgrade, the validator set signals readiness, and the network crosses over at a nominated epoch. Smaller protocol updates (/contents/tech/releases/protocol-updates) land two to three times a year, and Radix’s documentation notes that these are what other networks call hard forks. Stokenet (/contents/tech/releases/stokenet) , the public test network, carries the same protocol version as mainnet and is periodically reset, which destroys every balance and deployed package on it. ## Radix Research URL: https://radix.wiki/contents/tech/research Updated: 2026-09-11 Summary: Most of Radix exists because one problem was refused for thirteen years: a single-threaded ledger cannot serve the world’s financial traffic, and bigg… Began 2013, as eMunie (/contents/tech/research/emunie) Originator Dan Hughes (/contents/history/dan-hughes) (1974–2025) Published protocol Cerberus (/contents/tech/research/cerberus-whitepaper) , peer-reviewed in JSys, June 2023 Current line hyperscale-rs (/contents/tech/research/hyperscale-rs) , community-built in Rust Best public test >500,000 TPS sustained, January 2026 Most of Radix exists because one problem was refused for thirteen years: a single-threaded ledger cannot serve the world’s financial traffic, and bigger or faster blocks buy time rather than remove the ceiling. This section holds the designs tried against it, from eMunie (/contents/tech/research/emunie) in 2013 through Tempo (/contents/tech/research/tempo-consensus-mechanism) and Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) to Cassandra (/contents/tech/research/cassandra) . The abandoned ones are kept because each names a failure mode the next design had to survive. Hyperscale, and what the tests measured The current line is Hyperscale. In January 2026 the Radix Foundation sustained more than 500,000 transactions per second, peaking above 700,000, on commodity AWS instances of four cores and 16 GB each. That measured the Foundation’s implementation: it was not a measurement of Cerberus as specified, and the braided cross-shard consensus in the Cerberus paper has not shipped in any implementation. hyperscale-rs (/contents/tech/research/hyperscale-rs) , the community-built Rust implementation led by flightofthefox of proven.network, is the leading candidate to deliver Xi’an (/contents/tech/releases/radix-mainnet-xian) . ## Radix Ecosystem URL: https://radix.wiki/ecosystem Updated: 2026-09-11 Summary: This section is a directory of the projects built on Radix or built to serve it. An entry stays after the project stops, so more than half of the page… Radix Ecosystem Scope Projects built on, or serving, Radix (/contents/tech/core-protocols/radix-engine) Status index Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) Network Mainnet restarted 11:35 UTC on 11 September 2026, after a 254-hour halt This section is a directory of the projects built on Radix (/contents/tech/core-protocols/radix-engine) or built to serve it. An entry stays after the project stops, so more than half of the pages below describe something that has ended. How a status is decided The status on each page records whether the people behind a project are still operating it, not whether its website answers: a domain outlives the project on it. The operational-status index (/contents/resources/radix-ecosystem-operational-status) groups every entry by status and sets out the checks that settle it. ## Stabilis URL: https://radix.wiki/ecosystem/stabilis Updated: 2026-09-11 Summary: Stabilis is a decentralized financial ecosystem built on the Radix DLT platform, comprising three main components: the ILIS DAO, the STAB Protocol and… Stabilis (https://docs.ilikeitstable.com/introduction/protocol-overview) is a decentralized financial ecosystem built on the Radix DLT (https://www.radixdlt.com/) platform, comprising three main components: the ILIS DAO, the STAB Protocol and Flux (/ecosystem/flux) . The ecosystem aims to create stability within the Radix DeFi landscape through algorithmic mechanisms and community governance. Overview The Stabilis ecosystem was developed to address the need for stable assets within the Radix DLT network. At its core, the system consists of three main components (https://docs.ilikeitstable.com/introduction/protocol-overview) : the ILIS DAO (I Like It Stable DAO), the STAB Protocol and Flux. The ILIS DAO serves as the governing entity, while the STAB Protocol provides the technical infrastructure for maintaining a stable asset called $STAB. ILIS DAO The ILIS DAO is incorporated as a non-profit Decentralized Autonomous Organization (https://docs.ilikeitstable.com/introduction/protocol-overview/ilis-dao) in the Marshall Islands under the legal name "I Like It Stable DAO LLC." The organization operates under the Marshall Islands DAO Act and is structured to ensure transparent, community-driven governance of the Stabilis ecosystem. The DAO's primary mission is to build, manage, and support open-source software for digital stable assets on the Radix DLT platform. STAB Protocol The STAB Protocol represents the first protocol governed by the ILIS DAO (https://docs.ilikeitstable.com/introduction/protocol-overview/stab-protocol) , designed to provide a stable asset ($STAB) for the Radix ecosystem. Unlike traditional stablecoins that maintain a rigid peg to fiat currencies, STAB employs a unique interest rate mechanism that allows for dynamic price adjustment based on market conditions. This approach aims to achieve what the protocol terms "fair-priced stability." Flux Flux (/ecosystem/flux) is the second protocol governed by the ILIS DAO, live on Radix mainnet since 31 May 2025 and described by the DAO as the successor to the STAB Protocol. It issues $fUSD against $XRD and $LSULP collateral, holds it to a rigid one-to-one dollar peg rather than letting an internal price drift, and lets each borrower set the interest rate on their own loan. A tenth of the interest it collects buys $ILIS back and burns it. Development History The Stabilis ecosystem was founded by a developer known as Octopus (https://docs.ilikeitstable.com/ilis-dao/founders) , who has a background in Physics and an interest in complex systems. The project began as a personal endeavor to explore the possibilities of the Radix platform and its Scrypto SDK, eventually evolving into a full-fledged ecosystem. The founder emphasizes a meritocratic approach to development, focusing on practical results over individual recognition. The ecosystem officially launched with the incorporation of the ILIS DAO on August 22, 2024 (https://docs.ilikeitstable.com/introduction/protocol-overview) , marking a significant milestone in the development of decentralized financial infrastructure on the Radix network. Technical Infrastructure The Stabilis ecosystem leverages several innovative technical features to achieve its goals. The STAB Protocol utilizes a collateralized debt position (CDP) model (https://docs.ilikeitstable.com/introduction/protocol-overview/stab-protocol) where users can borrow $STAB tokens by providing collateral. The system maintains stability through a combination of: - A dynamic interest rate mechanism that adjusts based on market supply and demand. - A minimum collateralization ratio (MCR) of 150%. - Liquidation mechanisms to ensure system solvency. - Flash loan capabilities for advanced DeFi operations. The ecosystem's smart contracts are implemented using Radix's Scrypto SDK, with key components including the Stabilis Proxy Component (https://docs.ilikeitstable.com/stab-protocol/technical-info/components-and-manifests) for advanced operations and various resource-oriented tokens for governance and liquidity provision. ILIS DAO Organization The ILIS DAO operates as a non-profit limited liability company incorporated in the Marshall Islands. The organization's primary purpose, as stated in its Operating Agreement, is to "build, manage, and support open-source software in the field of digital stable assets for the Radix DLT, with the goal of fostering transparent, fair, and accountable systems that promote community-driven initiatives and societal benefits, without the aim of profit generation." (https://docs.ilikeitstable.com/introduction/protocol-overview/ilis-dao) The DAO's legal structure is governed by multiple Marshall Islands laws, including the Limited Liability Company Act of 1996, the Non-Profit Entities (Amendment) Act of 2021, the Business Corporations Act, and the Decentralized Autonomous Organization Act of 2022. This legal framework provides the organization with a fit-for-purpose regime designed to protect members while supporting innovation in the blockchain space. Under its non-profit status (https://docs.ilikeitstable.com/introduction/protocol-overview) , the DAO is restricted from: - Allowing net earnings to benefit any individual. - Exclusively engaging in legislative influence. - Participating in political campaigns. - Operating primarily as a for-profit business. Governance Structure The ILIS DAO employs a token-based governance system where decisions are made and executed on-chain whenever possible (https://docs.ilikeitstable.com/introduction/protocol-overview/ilis-dao) . The governance process involves members voting on proposals through a dedicated Voting Smart Contract (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/governance) , with voting power determined by the number of ILIS tokens held in a member's staking position. Membership System Membership in the ILIS DAO is obtained through the acquisition and staking of ILIS tokens (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/membership) . The membership system includes several key features: - Members must create a Membership ID. - ILIS tokens can be staked to the Membership ID. - Staked tokens provide voting rights and staking rewards. - Members can optionally lock their tokens for extended periods to receive additional rewards. - A 7-day unstaking period applies when members wish to withdraw their tokens. Proposal System The DAO's governance operates through a proposal system where members can submit and vote on various initiatives (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/governance) . Each proposal includes: - A title and description. - Detailed specifications. - Attachments with additional information. - A voting deadline. - A quorum requirement. Once a member votes on a proposal, their staked tokens are locked until the voting period ends, preventing double voting and ensuring governance integrity. Token Distribution and Economics The ILIS DAO utilizes a Liquidity Bootstrapping Pool (LBP) mechanism (https://docs.ilikeitstable.com/ilis-dao/technical-info/liquidity-bootstrapping-pools) for its initial token distribution. This approach aims to achieve both fair distribution and sufficient liquidity for the $ILIS token. The LBP works by: - Starting with an intentionally high token price that gradually decreases. - Discouraging early token accumulation by major buyers. - Creating a "fair pricing game" where participants attempt to time their purchases optimally. - Automatically adjusting token weights over time to influence price dynamics. Incentive Structure The DAO maintains an incentive system to reward actions that benefit the Stabilis ecosystem (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/incentives) . Key features of the incentive system include: - Weekly ILIS token rewards for specific beneficial actions. - Staking requirements for receiving rewards. - Optional token locking for enhanced rewards. - Manual claiming of rewards within a 5-week window. - Incentivized resources, such as $LPSTAB tokens for liquidity provision. Technical Implementation The DAO's technical infrastructure is built on the Radix DLT platform and includes several key smart contracts: - A Voting Token Smart Contract for membership management (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/membership) . - A Voting Smart Contract for proposal processing (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/governance) . - Incentive management components for reward distribution (https://docs.ilikeitstable.com/ilis-dao/using-ilis-dao/incentives) . The DAO maintains its official online presence at ilikeitstable.com (https://docs.ilikeitstable.com/introduction/protocol-overview) , where members can access governance features, documentation, and participate in DAO activities. STAB Protocol Overview The STAB Protocol is the first protocol developed under the governance of the ILIS DAO, designed to provide a stable asset ($STAB) for the Radix DLT ecosystem. Unlike traditional stablecoins, STAB employs a dynamic interest rate mechanism that allows its value to fluctuate within controlled parameters (https://docs.ilikeitstable.com/introduction/protocol-overview/stab-protocol) , aiming to achieve what the protocol terms "fair-priced stability." Technical Architecture Loan System The STAB Protocol utilizes a collateralized borrowing system similar to other decentralized stablecoin protocols (https://docs.ilikeitstable.com/stab-protocol/using-stab-protocol/borrow) . Users can create $STAB by providing collateral and opening a loan position. The system maintains several key parameters: - A Minimum Collateralization Ratio (MCR) of 150% for all collateral types. - A total liquidation penalty of 15%, with 10% going to liquidators and 5% to the protocol (https://docs.ilikeitstable.com/stab-protocol/technical-info/system-parameters) . - Currently, only XRD (the native token of Radix) is accepted as collateral. Loan management features (https://docs.ilikeitstable.com/stab-protocol/using-stab-protocol/manage-loans) allow users to: - Add or remove collateral from existing loans. - Borrow additional $STAB against existing collateral. - Partially or fully repay outstanding loans. - Monitor loan health and collateralization ratios. Stability Mechanisms The STAB Protocol employs several mechanisms to maintain price stability: - Interest Rate Controller The protocol uses a dynamic interest rate system (https://docs.ilikeitstable.com/stab-protocol/technical-info/interest-rate) that influences $STAB's internal price. The interest rate: - Can range from -33.33% to +50% annually. - Adjusts based on market supply and demand. - Influences borrowing and holding incentives. - Uses a PID controller for precise adjustments. The interest rate calculation (https://docs.ilikeitstable.com/stab-protocol/technical-info/interest-rate) follows the formula: interest_rate -= (kp * (price_error / internal_price) + ki * (average_of_last_50_prices / internal_price))) * passed_minutes where kp and ki are controller constants, and price_error is the difference between market price and internal price. - Liquidation System The protocol includes a two-step liquidation process (https://docs.ilikeitstable.com/stab-protocol/using-stab-protocol/liquidations) to maintain system solvency: - Marking Phase: Liquidators first mark unhealthy loans for liquidation. - Execution Phase: After a 5-minute delay, the marker can liquidate the loan. - Public Liquidation: If the marker doesn't act within 10 minutes, any user can liquidate the marked loan. - Additional Stability Features The protocol includes redemptions and forced minting mechanisms (https://docs.ilikeitstable.com/stab-protocol/technical-info/components-and-manifests) that provide additional stability tools: - Redemptions allow for forced liquidation of the lowest-collateralized loans. - Forced minting enables additional $STAB creation from highly-collateralized loans. - Flash loans are available for advanced trading strategies. Liquidity System The protocol maintains a dedicated XRD/STAB liquidity pool (https://docs.ilikeitstable.com/stab-protocol/using-stab-protocol/swap) where users can: - Swap between $XRD and $STAB tokens. - Provide liquidity and receive $LPSTAB tokens. - Monitor real-time trading metrics and pool statistics. The system calculates a Real 7-day APY (https://docs.ilikeitstable.com/stab-protocol/technical-info/real-7d-apy) for liquidity providers using the formula: 7_day_real_apy = ((lp_valuation_now / lp_valuation_7_days_ago)^(365 / 7) - 1) * 100 This calculation uses current asset prices for both time periods to provide a fair comparison between holding assets and providing liquidity. Risk Factors The STAB Protocol documentation identifies several key risks (https://docs.ilikeitstable.com/stab-protocol/dangers) : - Smart Contract Risk: Potential vulnerabilities in the protocol's code could lead to stuck or drained resources. - Liquidation Risk: Loans may face liquidation if their collateralization ratio falls below the MCR, resulting in penalty fees. - Oracle Risk: The potential for oracle manipulation could lead to inaccurate price feeds and improper system actions. - Depeg Risk: Market conditions might cause $STAB to trade significantly away from its target price, potentially making loan repayment or liquidation difficult. These risks are actively monitored and managed through the protocol's governance mechanisms and technical features. Technology Core Components - Voting Infrastructure - The Voting Token Smart Contract (https://docs.ilikeitstable.com/introduction/protocol-overview) , located at resource_rdx1t4r86qqjtzl8620ahvsxuxaf366s6rf6cpy24psdkmrlkdqvzn47c2, manages the ILIS governance token system. - A dedicated Voting Smart Contract (https://docs.ilikeitstable.com/introduction/protocol-overview) at component_rdx1cpzm6rgdwgw9p075zsh5kfjuxa9rzzyt47x6xcgzhzydp9lkymyx78 handles proposal processing and vote counting. - Stability Mechanisms - The Stabilis Proxy Component (https://docs.ilikeitstable.com/stab-protocol/technical-info/components-and-manifests) manages advanced operations including: - Flash loan functionality. - Redemption operations. - Forced minting capabilities. - A PID controller implementation (https://docs.ilikeitstable.com/stab-protocol/technical-info/interest-rate) manages the dynamic interest rate system. Resource Tokens The ecosystem utilizes several resource-oriented tokens: - $ILIS Token - Functions as the governance token (https://docs.ilikeitstable.com/introduction/protocol-overview/ilis-dao) . - Represents membership in the DAO. - Used for voting on proposals. - Can be staked for rewards. - $STAB Token - The protocol's stable asset (https://docs.ilikeitstable.com/introduction/protocol-overview/stab-protocol) . - Created through collateralized borrowing. - Subject to dynamic interest rates. - Used in liquidity pools. - $LPSTAB Token - Represents liquidity provided to the $XRD/$STAB pool (https://docs.ilikeitstable.com/stab-protocol/using-stab-protocol/swap) . - Tracks liquidity provider positions. - Used for claiming trading fees and rewards. Technical Features Automated Market Maker (AMM) The protocol includes a built-in AMM (https://docs.ilikeitstable.com/introduction/protocol-overview/stab-protocol) that: - Facilitates $XRD/$STAB trading. - Provides price information for the interest rate controller. - Supports liquidity provision and removal. - Calculates real-time trading metrics. Liquidation Engine The protocol's liquidation system (https://docs.ilikeitstable.com/stab-protocol/using-stab-protocol/liquidations) implements a unique two-phase liquidation process: - Marking Phase - Allows liquidators to identify unhealthy positions. - Implements a 5-minute delay before execution. - Issues Marker Receipts to track liquidation rights. - Execution Phase - Processes liquidations according to protocol parameters. - Distributes liquidation penalties between liquidators and the protocol. - Includes fallback mechanisms for uncompleted liquidations. Flash Loan Implementation The system supports flash loans through the Stabilis Proxy Component (https://docs.ilikeitstable.com/stab-protocol/technical-info/components-and-manifests) , with operations including: - Atomic borrowing and repayment. - Integration with other DeFi protocols. - Transaction validation and revertion mechanisms. Development Tools and Resources The Stabilis ecosystem maintains several technical resources: - Documentation - Comprehensive protocol documentation (https://docs.ilikeitstable.com/introduction/protocol-overview) . - Technical specifications and parameters. - Integration guides and examples. - Smart Contract Interfaces - Component manifests (https://docs.ilikeitstable.com/stab-protocol/technical-info/components-and-manifests) . - Flash loan templates. - Interaction examples. - Development Environment - Built on Radix's Scrypto SDK. - Utilizes Radix Engine v2. - Leverages Radix's component-based architecture. See Also - Radix DLT (https://www.radixdlt.com/) - The underlying blockchain platform on which Stabilis is built - Decentralized Autonomous Organizations (https://en.wikipedia.org/wiki/Decentralized_autonomous_organization) - The organizational structure employed by ILIS DAO - Algorithmic stablecoins (https://en.wikipedia.org/wiki/Stablecoin#Algorithmic_stablecoins) - The category of digital assets to which STAB belongs - MakerDAO (https://en.wikipedia.org/wiki/Dai_(cryptocurrency)) - A similar protocol that also uses collateralized debt positions - PID Controllers (https://en.wikipedia.org/wiki/PID_controller) - The control system used in STAB's interest rate mechanism References - "Protocol Overview - Stabilis Ecosystem" (https://docs.ilikeitstable.com/introduction/protocol-overview) . ILIS DAO. - "STAB Protocol for Dummies" (https://docs.ilikeitstable.com/introduction/protocol-overview/stab-protocol) . ILIS DAO. - "ILIS DAO Documentation" (https://docs.ilikeitstable.com/introduction/protocol-overview/ilis-dao) . ILIS DAO. - "System Parameters" (https://docs.ilikeitstable.com/stab-protocol/technical-info/system-parameters) . ILIS DAO. - "Interest Rate Documentation" (https://docs.ilikeitstable.com/stab-protocol/technical-info/interest-rate) . ILIS DAO. - "Dangers" (https://docs.ilikeitstable.com/stab-protocol/dangers) . ILIS DAO. - "Real 7d APY" (https://docs.ilikeitstable.com/stab-protocol/technical-info/real-7d-apy) . ILIS DAO. - "Components & Manifests" (https://docs.ilikeitstable.com/stab-protocol/technical-info/components-and-manifests) . ILIS DAO. - "Operating Agreement of I Like It Stable DAO LLC" (https://docs.ilikeitstable.com/introduction/protocol-overview) . ILIS DAO. Scale on Ledger (as of 1 August 2026) The protocol described above is live – ilikeitstable.com (https://ilikeitstable.com) and its documentation both resolve, and $STAB carries a current market price – but its scale is a fraction of what the length of this article implies, and the wiki had never recorded it. Read directly from mainnet at epoch 331230 (state version 544398279), the $STAB resource (https://dashboard.radixdlt.com/resource/resource_rdx1t40lchq8k38eu4ztgve5svdpt0uxqmkvpy4a2ghnjcxjtdxttj9uam) had a total supply of 2,665.86 STAB. Because STAB is minted only when a borrower opens a collateralised loan, that figure is also the size of the protocol's entire outstanding loan book – on the order of three thousand dollars. Minting and burning remain gated behind a protocol badge, so the supply moves only through the loan mechanics documented above. On Ociswap (https://ociswap.com/) , where $STAB has been listed since October 2024, the pool held roughly $37 of liquidity and recorded no trades in the preceding 24 hours, with the token quoted around $1.16 – above the dollar mark its interest-rate controller targets, though the STAB design deliberately allows the internal price to drift rather than holding a rigid peg. The protocol also runs its own XRD/STAB pool, so Ociswap is one venue rather than the whole market. None of this contradicts the design described in this article; it establishes the difference between a protocol that works and a protocol that is used. Readers evaluating $STAB as a stable asset should weigh a loan book of this size against the risks the protocol documents (https://docs.ilikeitstable.com/stab-protocol/dangers) , particularly liquidity and depeg risk. Telegram Handle No Longer the Project's The Telegram handle @stabilislabs, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . ## Stablecoins URL: https://radix.wiki/contents/tech/core-concepts/stablecoins Updated: 2026-09-11 Summary: A stablecoin is a cryptocurrency designed to maintain a stable value, most commonly by targeting a fixed exchange rate – a peg – against a reference a… Topic Price-stabilized cryptocurrencies (web3 / DeFi) Design axes Peg, collateral, mechanism, price information Main families Fiat-collateralized, crypto-collateralized, algorithmic (seigniorage shares, rebasing) Related Decentralized finance (DeFi) (/contents/tech/core-concepts/decentralized-finance-defi) · Native assets (/contents/tech/core-concepts/native-assets-vs-token-approvals) · Resources (/contents/tech/core-concepts/resources) A stablecoin is a cryptocurrency designed to maintain a stable value, most commonly by targeting a fixed exchange rate – a peg – against a reference asset such as the United States dollar. Calcaterra, Kaal and Rao define stable cryptocurrencies (https://stanford-jblp.pubpub.org/pub/stable-cryptocurencies-principles) as coins engineered to hold stable value, typically backed by one or more reserve assets, combining the payment properties of cryptocurrencies – instant processing and cryptographic security – with the low-volatility valuation of fiat money. All stablecoins share the objective of trading at par with a reference asset (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3899499) , but they differ substantially in economic design, quality of backing, stability assumptions, and the legal protections offered to coin holders. This variation – and a record that includes both durable and catastrophically failed pegs – has produced a substantial design literature. Volatility and the functions of money The case for stablecoins rests on a diagnosis of why first-generation cryptocurrencies are volatile. Robert Sams argued that a deterministic supply rule (https://bravenewcoin.com/assets/Whitepapers/A-Note-on-Cryptocurrency-Stabilisation-Seigniorage-Shares.pdf) of the kind used by Bitcoin forces every unanticipated change in demand for the coin to be expressed as a change in its price, and that the resulting volatility discourages use as a medium of exchange. His proposed remedy, grounded in the quantity theory of money, is an elastic supply rule that adjusts the quantity of coins in proportion to changes in their market value. Ametrano reaches a similar diagnosis: Bitcoin's fixed, deterministic and inelastic monetary policy produced dramatic deflationary price instability (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2425270) that established it as digital gold rather than usable currency. Sams also identified the two hard problems that any algorithmic stabilization scheme must solve: representing the coin's market price inside the network with minimal trust (the oracle problem), and deciding how newly created supply is distributed or removed. The design space In a systematization of the field, Moin, Sekniqi and Sirer decompose stablecoin designs along four axes (https://arxiv.org/abs/1910.10098) : the peg (what value is targeted), the collateral (what backs the coin), the mechanism (how the peg is defended), and price information (how the market price is measured). The US dollar dominates as a peg; alternatives include other fiat currencies, commodities, currency baskets such as the SDR, and consumer-price-index proposals – baskets insulate holders against single-country shocks but add noise and measurement problems. Complementing this taxonomy, Catalini and de Gortari identify two dimensions underpinning every stablecoin's economic design (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3899499) : the volatility of its reserve assets against the reference asset, which defines the holder's risk profile, and its degree of exposure to death-spiral risk. Collateralized designs Fiat- and commodity-backed coins such as Tether and USD Coin defend their pegs through reserve redemption: because coins can be exchanged for the underlying asset, arbitrage enforces a price floor. The cost is centralized custody in banks and vaults and difficulty scaling at full reserve; Moin et al. note that nominally fully backed reserves held in banks are functionally fractional-reserve (https://arxiv.org/abs/1910.10098) . Catalini and de Gortari argue that fiat-backed stablecoins must hold reserves of high-quality liquid assets and operate under a framework protecting holders from credit, market and operational risk and from issuer insolvency. Crypto-collateralized designs permit decentralization but must absorb the collateral's own volatility, through over-collateralization or a dedicated volatility-absorbing mechanism; MakerDAO's Dai combines collateralized debt positions with a 150% liquidation ratio, stability fees, and dilution of the MKR token as a recapitalization backstop. Sams criticized early collateralized designs such as BitShares' bitUSD on the grounds that collateral shuffles risk rather than eliminating it (https://bravenewcoin.com/assets/Whitepapers/A-Note-on-Cryptocurrency-Stabilisation-Seigniorage-Shares.pdf) – the backing asset is itself volatile – and that reserve requirements constrain supply elasticity. Rebasing and Hayek Money Ametrano's Hayek Money (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2425270) proposal, named after F. A. Hayek, pursues price stability by dynamically rebasing supply: the number of units in every wallet is adjusted pro rata, so the price of one unit stays stable while the quantity changes. The result is an elastic, non-discretionary monetary standard, but it stabilizes the unit of account rather than the holder's wealth – wallet balances still fluctuate with total market capitalization, a limitation Moin et al. also observe in the rebasing coin Ampleforth, which they describe as a stable unit of account but not a store of value. Ametrano's follow-up work extends the paradigm to a dual-asset ledger separating stable coins from seigniorage shares, linking rebasing to the next design family. Seigniorage shares Sams's canonical algorithmic design splits the system into two tokens: stable coins and volatile shares (https://bravenewcoin.com/assets/Whitepapers/A-Note-on-Cryptocurrency-Stabilisation-Seigniorage-Shares.pdf) . When demand grows, new coins are minted and distributed to shareholders as seigniorage; when demand contracts, newly minted shares are auctioned for coins, which are burned. Because shares are claims on future seigniorage, the peg is backed by expectations: Sams himself noted that if confidence in future coin-demand growth collapses, contraction auctions can fail and the peg breaks. Moin et al. catalogue the family's variants, including the dual-coin system Carbon, Basis's triple-token tranching of bonds and shares, and Saga's algorithmic market maker. Managed issuance with consensus-enforced rules For centrally issued coins, Mell proposes a hybrid model: a managed cryptocurrency maintained through distributed consensus (https://arxiv.org/abs/1906.11042) , in which a currency administrator can perform management operations but consensus-enforced rules prevent arbitrary actions and enforce transparency. This removes the need for users to blindly trust the managing entity, occupying a middle ground between fully decentralized cryptocurrencies and opaque private ledgers, and offers a blueprint for auditable, rule-constrained issuer powers – minting, freezing, policy changes – of the kind relevant to fiat-backed stablecoins and CBDC-like designs. Peg robustness and failure modes The literature converges on a clear fragility gradient. Moin et al. observe that purely algorithmic, uncollateralized coins are cheap to operate but derive their value solely from issuer reliability and holder beliefs – when these stablecoins fail, they tend to do so swiftly and catastrophically (https://arxiv.org/abs/1910.10098) . NuBits, an early example, lost its peg in early 2018, falling to roughly $0.30 and never recovering. Dual-coin seigniorage systems carry two structural risks: the volatility-absorbing token typically meets the SEC's definition of a security, and the design depends on holders who believe demand will eventually grow – with no collateral, nothing supports the price if no one buys the secondary token during a downturn. These warnings preceded the largest failure in the category. Analyzing Terra before its collapse, Moin et al. noted that Luna both absorbed Terra's volatility and served as the staking token, and that the protocol raised fees when Terra's price fell, discouraging use precisely when demand was already weak. A post-mortem of the May 2022 de-pegging finds it was driven by a misaligned incentive structure (https://doi.org/10.5195/ledger.2023.283) : UST redeemers were undercompensated, and UST's exchange price tracked the value obtainable by redeeming it for LUNA and selling. Such designs sit at the extreme of the death-spiral exposure that Catalini and de Gortari identify as a critical dimension of stablecoin economic design. Stablecoins on Radix Radix has two stablecoins of its own and one route by which anyone else’s reaches it, and all three are small enough to state exactly. Both native ones answer to the same governing body, the ILIS DAO, incorporated in the Marshall Islands. Its STAB Protocol (/ecosystem/stabilis) issues $STAB against Radix-native collateral and lets the internal price drift rather than holding a peg; its later protocol, Flux (/ecosystem/flux) , issues $fUSD against $XRD and liquid-stake-unit collateral at a rigid one-to-one dollar peg, with each borrower setting the interest rate they pay. Read from the ledger at state version 557,865,161 on 11 September 2026, hours after mainnet resumed from its ten-day halt (/contents/history/hyperlane-asset-drain-2026) , the STAB resource carries a total supply of 2,642.43 and the fUSD resource 5,608.56. The DAO’s governance token ILIS stands at 99,982,000, below the 100,000,000 its documentation says was issued, because Flux spends a tenth of the interest it collects buying the token back and burning it. Dollar-pegged value from outside arrives wrapped: Instabridge (/ecosystem/instabridge) , the regulated Ethereum bridge that carried the first wrapped USDC and USDT onto the network, is closed, and the surviving route is Hyperlane, whose hUSDC resource – described on-ledger as "Wrapped USDC bridged by Hyperlane" – held a total supply of 1,092.79 at the same state version. EtherealDAO (/ecosystem/etherealdao) , which was building the EtherealUSD protocol, has closed. The collateral infrastructure around them has thinned in the same period. Root Finance (/ecosystem/root-finance) is dormant, its tracked deposits down from a peak of about $1.67M in April 2025 to roughly $2K. Weft Finance (/ecosystem/weft-finance) , the larger of the two money markets, was exploited on 30 August 2026 when its price feed valued the memecoin HUG at roughly ten million times its market price, releasing 71M XRD of debt against collateral bought for 70.6 XRD. That is the oracle problem this page describes in the abstract, arriving on this network: Sams named representing a coin’s market price inside the system with minimal trust as one of the two hard problems any stabilisation scheme must solve, and a lending market that gets the price wrong fails in the same way a peg does, by letting someone mint claims the collateral does not cover. The general vocabulary is set out in this wiki’s overview of decentralized finance (DeFi) (/contents/tech/core-concepts/decentralized-finance-defi) , which names DAI, Tether (USDT) and USD Coin (USDC) as the reference examples of the three collateral families. References - Craig Calcaterra, Wulf A. Kaal, Vadhindran K. Rao (2019). Stable Cryptocurrencies: First Order Principles (https://stanford-jblp.pubpub.org/pub/stable-cryptocurencies-principles) . Stanford Journal of Blockchain Law & Policy, Vol. 3. - Christian Catalini, Alonso de Gortari (2021). On the Economic Design of Stablecoins (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3899499) . SSRN Working Paper No. 3899499. - Robert Sams (2015). A Note on Cryptocurrency Stabilisation: Seigniorage Shares (https://bravenewcoin.com/assets/Whitepapers/A-Note-on-Cryptocurrency-Stabilisation-Seigniorage-Shares.pdf) . Self-published white paper (first version 2014). - Ferdinando M. Ametrano (2016). Hayek Money: The Cryptocurrency Price Stability Solution (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2425270) . SSRN Working Paper No. 2425270 (first posted 2014). - Amani Moin, Kevin Sekniqi, Emin Gün Sirer (2019). SoK: A Classification Framework for Stablecoin Designs (https://arxiv.org/abs/1910.10098) . arXiv:1910.10098; also in Financial Cryptography and Data Security 2020. - Peter Mell (2019). Managed Blockchain Based Cryptocurrencies with Consensus Enforced Rules and Transparency (https://arxiv.org/abs/1906.11042) . IEEE TrustCom; arXiv:1906.11042. - Cho, J. (2023). A Token Economics Explanation for the De-Pegging of the Algorithmic Stablecoin: Analysis of the Case of Terra (https://doi.org/10.5195/ledger.2023.283) . Ledger, 8. ## Flux URL: https://radix.wiki/ecosystem/flux Updated: 2026-09-11 Summary: Flux is a borrowing protocol on Radix that issues $fUSD , a stablecoin pegged one for one to the United States dollar. A borrower locks collateral in… Flux Type Overcollateralised borrowing protocol Stablecoin $fUSD, pegged 1:1 to the US dollar Collateral $XRD and $LSULP Maximum loan-to-value 66.67% for both collateral types Minimum loan 50 $fUSD Interest rate Set by each borrower Governance ILIS DAO (I Like It Stable DAO LLC, Marshall Islands) Oracle Morpher, pull-based Launched 31 May 2025 Licence MIT Flux is a borrowing protocol on Radix that issues $fUSD, a stablecoin pegged one for one to the United States dollar. A borrower locks collateral in Flux, mints $fUSD against it, and sets the interest rate on the loan themselves. Two collateral types are accepted: $XRD (/contents/tech/core-protocols/xrd-token) , the native token of Radix, and $LSULP, the liquidity token of CaviarNine (/ecosystem/caviarnine) 's LSU Pool, which holds liquid stake units (/contents/tech/core-concepts/liquid-stake-units) from a spread of validators. The protocol is governed by the ILIS DAO and its source is published under the MIT licence. Origins Flux is the second protocol built by the ILIS DAO (https://docs.ilikeitstable.com/introduction/protocol-overview) , a non-profit incorporated in the Marshall Islands as I Like It Stable DAO LLC. Its documentation names one founder, a Dutch developer who goes by Octopus (https://docs.ilikeitstable.com/ilis-dao/founders) , and says nothing further about who works on it. The DAO's first protocol is the STAB Protocol (/ecosystem/stabilis) , which issues a stable asset called $STAB and deliberately lets its internal price drift rather than holding a fixed peg. The documentation calls Flux the "spiritual successor" (https://docs.ilikeitstable.com/introduction/protocol-overview/flux) to the STAB Protocol and credits Liquity V2 (https://www.liquity.org/) on Ethereum as the design it is drawn from. Four things change against the older protocol: borrowers set their own interest rates, where the STAB Protocol used a control loop to set one rate for everyone; $fUSD holds a rigid dollar peg; the redemption system is reworked for a tighter peg; and prices arrive from a pull oracle, which the caller supplies with every transaction, rather than a push oracle writing prices to the ledger on its own schedule. Flux went live on Radix mainnet on 31 May 2025. The transaction that created the $fUSD resource and instantiated the protocol's main component committed at state version 299,034,033, and the front end at flux.ilikeitstable.com (https://flux.ilikeitstable.com) still carries a banner describing Flux as a beta. $fUSD $fUSD is a native Radix fungible resource (resource_rdx1t49…g0cnsmscq) with 18 decimal places and no fixed supply. It exists only where someone has borrowed it, so the total in existence is also the protocol's entire outstanding loan book. Its authorities were read from the ledger on 11 September 2026. Minting and burning are gated behind the protocol's own controller badge, so nobody can create or destroy $fUSD outside the loan mechanics. Freezing and recall are set to deny_all and that setting is locked, so no holder's balance can be frozen or clawed back. Withdraw and deposit are open, so the token transfers freely. The rule set as a whole is not locked: the badge holder can still change who may mint and burn, which is the technical form the DAO's governance over the token takes. The peg rests on two mechanisms rather than on a reserve. Redemption sets a floor: anyone holding $fUSD can always exchange it for collateral at a dollar a coin, so a price below a dollar is an arbitrage. Borrower-set interest rates supply the other half, because a borrower who wants to avoid being redeemed against raises the rate they pay, and a higher rate makes holding $fUSD more attractive. Borrowing Each loan is an NFT called a Flux Generator, which the borrower holds in their own account. Because the loan is a token rather than an entry in a table keyed by address, one account can hold several loans at different risk settings, and a loan can be transferred or sold to someone else. The published parameters (https://docs.ilikeitstable.com/flux/technical-info/system-parameters) are the same for both collateral types. The maximum loan-to-value ratio is 66.67%, so a loan is liquidated once its debt passes two thirds of the value of its collateral. The minimum loan is 50 $fUSD. Interest compounds every minute and is added to the debt rather than billed separately, and there is no repayment schedule: a loan stays open until the borrower closes it or it is liquidated. Opening a loan costs seven days of the borrower's chosen interest, charged upfront, which makes very short loans unattractive. The same charge applies to a borrower who changes their rate less than seven days after setting it. That cooldown exists to stop a borrower dropping their rate, riding out a redemption, and putting it back. A liquidated borrower pays a penalty of 10% of the debt out of their collateral and keeps whatever is left. The liquidation itself is absorbed by a Flux Reservoir rather than by an auction, and the person who submits the transaction is reimbursed with 1% of the debt value in collateral. Each collateral type runs its own market, its own interest rates and its own reservoir, so a failure in one collateral does not reach borrowers in the other. Redemptions A redemption is the mechanism that holds the floor under the peg. Anyone with $fUSD can send it to the protocol and receive collateral in return, valued at a dollar per coin, less a redemption fee the protocol varies between 0.5% and 5% (https://docs.ilikeitstable.com/flux/technical-info/system-parameters) . When $fUSD trades below a dollar by more than that fee, redeeming it is profitable, and the redemption burns the $fUSD it takes in. The collateral comes out of open loans (https://docs.ilikeitstable.com/flux/using-flux/redeem) , starting with the loan paying the lowest interest rate and, where two loans pay the same rate, the one with the higher loan-to-value ratio. A redeemed borrower is not penalised: their debt falls by the same dollar amount as the collateral that leaves, and the redemption fee stays in their loan. What they lose is exposure to the collateral, and the rate they set is what decides their place in the queue. Flux Reservoirs and the interest split A Flux Reservoir is a pool of deposited $fUSD that stands ready to absorb liquidations. When a loan is liquidated, the reservoir's $fUSD pays off the debt and the reservoir receives the collateral, which depositors can then buy back at 99% of the oracle price. There is one reservoir per collateral market, no lock-up, and no deposit fee. Interest paid by borrowers is split three ways. The documentation states the split (https://docs.ilikeitstable.com/flux/using-flux/earn) as 65% to the reservoirs, 25% to liquidity incentives and 10% to buying and burning $ILIS, the ILIS DAO's governance token. Those three proportions, and the 1% buy-back discount, are stored as parameters on the protocol's stability-pool component and read back from the ledger unchanged. The liquidity share is paid out as weekly airdrops to people providing $fUSD liquidity on two venues: 80% to the $fUSD/$xUSDC pool on CaviarNine, where only liquidity priced between 0.95 and 1.05 earns rewards, and 20% to the $fUSD/$XRD pool on Ociswap (/ecosystem/ociswap) . Scale on ledger Flux is fully built and barely used. The figures below were read from Radix mainnet on 11 September 2026 at epoch 340,001, state version 557,864,266, roughly nine hours after the network resumed from the ten-day halt (/contents/history/hyperlane-asset-drain-2026) that began on 31 August. Reading Value $fUSD in existence 5,608.56 Open Flux Generators 3, all collateralised in $XRD Flux Generators minted since launch 49, of which 46 are burned Collateral held by the protocol 1,770,509 $XRD and no $LSULP $fUSD in the $LSULP reservoir 1,505.74 $fUSD in the $XRD reservoir 163.34 CaviarNine $fUSD/$xUSDC pool 525.61 $fUSD and 147.95 $xUSDC Because $fUSD is minted only against collateral, the first row is the whole loan book. The three open loans carry interest rates of 0.1%, 0% and 6%, and one of them holds 1,656,279 of the 1,770,509 $XRD. The $LSULP market holds the larger reservoir and no collateral, so nothing is borrowed against $LSULP today. Two readings are easy to take wrongly. The debt recorded on a Flux Generator is denominated in pool units rather than in $fUSD, and the documentation warns that raw loan data read this way cannot be treated as a coin amount. And the quoted market price of $fUSD carries little weight: the venues quoting it hold a few hundred tokens between them, which is thin enough that a single trade moves the number. Risks The project's own risk page (https://docs.ilikeitstable.com/flux/dangers) lists five: a bug in the smart contracts; liquidation when a loan's ratio passes the limit; manipulation of the oracle; a depeg that makes repaying or liquidating unworkable; and thin liquidity, which stops reservoir buy-backs from clearing. It also states plainly that $fUSD depends on $XRD and $LSULP, and that no mechanism guarantees overcollateralisation if a collateral asset collapses suddenly. One mechanism appears on the ledger and not in the documentation. The stability-pool component carries a "panic mode" with vaults for a designated centralised stablecoin, set at the time of reading to $xUSDC, the wrapped US dollar coin bridged onto Radix by Instabridge (/ecosystem/instabridge) . Panic mode was inactive when read on 11 September 2026, and no published page explains what activates it or what it does. It sits alongside the protocol's claim that $fUSD is backed only by decentralised assets, and the two want reconciling before either is relied on. Prices reach Flux through Morpher's pull oracle (https://www.morpher.com/radix/docs) , which means every transaction needing a collateral price carries a signed price message supplied by the caller. Flux runs an API that hands these messages out, and a user can subscribe to Morpher directly instead. External Links - Flux – official app (https://flux.ilikeitstable.com) - Flux USD (fUSD) – ILIS DAO documentation (https://docs.ilikeitstable.com/flux/using-flux/fusd) - Flux components and manifests – on-ledger addresses (https://docs.ilikeitstable.com/flux/technical-info/components-and-manifests) - Stabilis-Labs/flux-protocol – source code (MIT) (https://github.com/Stabilis-Labs/flux-protocol) - $fUSD – Radix Dashboard (resource) (https://dashboard.radixdlt.com/resource/resource_rdx1t49wa75gve8ehvejr760g3pgvkawsgsgq0u3kh7vevzk0g0cnsmscq) - Flux – live protocol statistics (https://flux.ilikeitstable.com/stats) - ILIS DAO – Telegram (https://t.me/ilisdao) ## RADIX.wiki MCP Server URL: https://radix.wiki/contents/resources/mcp-server Updated: 2026-09-11 Summary: An agent that wants to read this wiki does not have to scrape it. RADIX.wiki runs a Model Context Protocol server at , and… RADIX.wiki MCP server Type Agent interface · reference Endpoint https://radix.wiki/api/mcp (POST only) Transport MCP Streamable HTTP (https://modelcontextprotocol.io/specification/2025-03-26/basic/transports) , protocol version 2025-03-26 Server version 3.1.0 Registry name wiki.radix/radix-wiki (https://registry.modelcontextprotocol.io) Tools 11 – seven read, two for the login handshake, two write Authentication None for reads. A ROLA (/developers/frontend/03-rola-authentication) bearer token for create_page and edit_page Rate limit 60 requests per minute per IP, shared across all methods Measured 11 September 2026 Related Radix for AI Agents (/contents/tech/core-concepts/radix-for-ai-agents) · Building on Radix (/developers) · Brand Assets (/contents/resources/brand-assets) An agent that wants to read this wiki does not have to scrape it. RADIX.wiki runs a Model Context Protocol (https://modelcontextprotocol.io/specification/2025-03-26) server at https://radix.wiki/api/mcp, and it is the busiest thing on the site after the homepage: over the thirty days to 11 September 2026 the endpoint drew 571 of the wiki's 3,438 visitors, third behind only the homepage and the account of the Hyperlane asset drain, and more than triple the ecosystem directory (/ecosystem) . This page is the reference for that server and for the flat files that sit beside it. The server exposes the corpus as tools an assistant can call: search it, read a page, list a category, take the whole thing at once. Reads are open and never authenticate. Writes go through the same ROLA (/developers/frontend/03-rola-authentication) wallet proof a human editor signs, so an agent holding a key gets exactly the permissions that key already had, and no others. Connecting The transport is Streamable HTTP (https://modelcontextprotocol.io/specification/2025-03-26/basic/transports) : one URL, JSON-RPC 2.0 (https://www.jsonrpc.org/specification) over POST. A GET to the endpoint returns 405; a preflight OPTIONS returns 204 with Access-Control-Allow-Origin: *, so a browser-based client can reach it directly. There is no session to establish and no key to obtain. Most clients take a block of JSON: { "mcpServers": { "radix-wiki": { "url": "https://radix.wiki/api/mcp" } } } The handshake is worth reading once, because the server answers it with its own instructions for how to use itself. initialize returns serverInfo of radix-wiki at version 3.1.0, a negotiated protocol version of 2025-03-26, and an instructions string naming the usual sequence: get_categories to orient, search_wiki or list_pages to locate, get_page to read. curl -s -X POST https://radix.wiki/api/mcp -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' The server also publishes two machine-readable descriptions of itself. A server card (https://radix.wiki/api/mcp/server-card) at /api/mcp/server-card carries the name, version and remote endpoint in the schema the official MCP registry (https://github.com/modelcontextprotocol/registry) reads, and the wiki is listed there as wiki.radix/radix-wiki, latest version 3.1.0, published 15 August 2026. An agent card (https://radix.wiki/.well-known/agent-card.json) at /.well-known/agent-card.json describes the same capabilities as skills, for clients that discover agents rather than servers. The tools Eleven tools, measured from a live tools/list call on 11 September 2026. Every listing tool returns a tagPath and a slug, and that pair is the address every read tool accepts. Tool What it does Auth search_wiki Keyword search over titles and content. Returns titles, URLs, snippets and update dates. None get_page Full text of one page, by tagPath and slug. None list_pages Pages in a category, sorted by title or last update. None get_categories The tag hierarchy with a page count per category. 371 pages at the time of writing. None get_recent_changes Pages updated in the last n days, capped at 30. None get_full_corpus The entire wiki as one document, for bulk ingestion. None get_ideas_board The Ideas Pipeline (/ideas) kanban: community proposals and Radix DAO tasks by status column. None get_challenge Step one of writing: a single-use ROLA challenge with a five-minute expiry. None login Step two: exchange the signed proof for a seven-day bearer token. None create_page Create a page. Bearer edit_page Replace a page's block array; the version bump, diff and revision entry are handled server-side. Bearer Two MCP resources sit alongside the tools: radix-wiki://llms.txt, the briefing document, and radix-wiki://categories, the hierarchy as JSON. Reading without MCP Not every agent speaks the protocol, so the same corpus is published as flat files. Sizes below are as served on 11 September 2026. URL Size What it holds /llms.txt (https://radix.wiki/llms.txt) 15 KB The llms.txt (https://llmstxt.org) briefing: what Radix is, what the wiki covers, and where the other surfaces are. /llms-index.txt (https://radix.wiki/llms-index.txt) 86 KB Every page, grouped by section, newest first, each with a one-line summary. /llms-full.txt (https://radix.wiki/llms-full.txt) 3.4 MB The full text of the whole wiki in one file. /AGENTS.md (https://radix.wiki/AGENTS.md) 9 KB The agent API reference: the ROLA signing spec, REST equivalents and the content model. /openapi.json (https://radix.wiki/openapi.json) 10 KB OpenAPI description of the REST API behind all of it. Any page URL takes a .md suffix and returns that page as markdown, which is the cheapest way to read one article without a client. The flat files carry an ETag and answer a conditional request with 304, so a crawler that keeps the header pays nothing to check whether the corpus moved. The wiki's robots.txt (https://radix.wiki/robots.txt) disallows /api/ for crawlers generally and then re-allows /api/mcp, /api/wiki/ and the three llms files for the named assistant agents, so the surfaces meant for machines stay reachable while the edit and history routes do not. Writing through the protocol An agent can contribute without leaving MCP. Call get_challenge, sign the returned ROLA message with an Ed25519 key held in a Radix Wallet (/contents/tech/core-protocols/radix-wallet) account, call login with the proof, and send the resulting token as an Authorization: Bearer header on the POSTs that carry create_page and edit_page. ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) is Radix's off-ledger authentication scheme: the wallet proves control of an account by signing, and nothing is submitted to the ledger. The write tools are a transport rather than a second implementation. Both forward to the REST endpoint that already owns the write path, carrying the caller's token, so the balance gate, the locked-page and author-only checks, block validation, the semantic version bump, the revision row and cache revalidation all run in one place. The default thresholds are a wallet balance of 10,000 XRD to create a page and 20,000 to edit one, and the balance is read rather than spent. The practical consequence is that an agent is a contributor on the same terms as a person. It signs with a wallet, its edits carry an author and a revision message, and its work shows up in the same history any reader can open. External links - Model Context Protocol specification, 2025-03-26 (https://modelcontextprotocol.io/specification/2025-03-26) – the version this server negotiates. - Official MCP registry (https://registry.modelcontextprotocol.io) – where wiki.radix/radix-wiki is listed. - AGENTS.md (https://radix.wiki/AGENTS.md) – the full agent API reference, including the ROLA signing spec. - llms.txt (https://llmstxt.org) – the convention the briefing file follows. - Awesome Radix MCP Servers (https://github.com/xstelea/awesome-radix-mcp-servers) – community index of MCP servers in the Radix ecosystem. - ROLA: Radix Off-Ledger Authentication (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) – the wallet proof the write path requires. ## How to Buy $XRD URL: https://radix.wiki/contents/resources/how-to-buy-xrd Updated: 2026-09-11 Summary: $XRD is the native currency of the Radix protocol and is used to pay transaction fees and to stake to validators . You can acquire XRD three ways: on… Buying XRD Asset Radix (XRD) Type Native protocol token Used for Transaction fees, staking (/contents/tech/core-concepts/staking) , network security Where to buy Centralized exchanges, cross-chain swaps & fiat on-ramps, on-ledger DEXs Network status Mainnet restarted at 11:35 UTC on 11 September 2026 (/contents/history/hyperlane-asset-drain-2026) after 254 hours; XRD deposits and withdrawals still disabled at every venue that publishes them, eight hours later; the four surviving quotes differ by 43% Self-custody Radix Wallet (/contents/tech/core-protocols/radix-wallet) $XRD is the native currency of the Radix (https://www.radixdlt.com) protocol and is used to pay transaction fees and to stake to validators (/contents/tech/core-concepts/staking) . You can acquire XRD three ways: on a centralized exchange, through a cross-chain swap or fiat on-ramp, or by bridging assets onto the Radix Network and swapping on a native decentralized exchange. The lists below cover each route. Centralized exchanges Radix mainnet restarted at 11:35:28 UTC on 11 September 2026, and eight hours later no venue had reopened XRD deposits or withdrawals. Two of the six books stopped quoting during the 254-hour halt (/contents/history/hyperlane-asset-drain-2026) and have not come back. Read at 19:04 UTC on 11 September from each venue's own API, native XRD deposits and withdrawals are disabled at Gate.io (https://api.gateio.ws/api/v4/spot/currencies/XRD) , KuCoin (https://api.kucoin.com/api/v3/currencies/XRD) and CoinEx (https://api.coinex.com/v2/assets/deposit-withdraw-config?ccy=XRD) , and BingX (https://open-api.bingx.com/openApi/spot/v1/common/symbols?symbol=XRD-USDT) and KuCoin (https://api.kucoin.com/api/v1/market/stats?symbol=XRD-USDT) are still not quoting the token at all. Bitpanda, Gate.io, MEXC and CoinEx are, so XRD can be bought and sold on a venue that already holds it, but until a venue reopens its own Radix wallet a purchase cannot be moved to a Radix Wallet (/contents/tech/core-protocols/radix-wallet) and coins in a wallet cannot be sent to a venue. The four surviving quotes disagree by 43%; the measurement is under The ledger restarted and the books did not below. Check the venue's own deposit and withdrawal status before funding anything. The XRD spot markets below were each re-confirmed live on 22 August 2026 by querying the venue's own public market API, not by loading its web page – a listing page can 404 while the market is open, and a market can close while the page still loads: - BingX (https://bingx.com/en/spot/XRDUSDT/) – XRD/USDT, not quoting since 03:00 UTC on 1 September 2026, the instant the exchange's own symbol record gives as its offTime - Bitpanda (https://web.bitpanda.com/price/xrd) – EU-regulated brokerage rather than an order book; XRD is quoted in EUR, USD, GBP, CHF and eight other fiat currencies and can be bought by card or bank transfer - CoinEx (https://www.coinex.com/en/price/xrd) – XRD/USDT and XRD/BTC - Gate.io (https://www.gate.io/trade/XRD_USDT) – XRD/USDT - KuCoin (https://www.kucoin.com/trade/XRD-USDT) – XRD/USDT, not quoting when read on 3 September 2026, with the pair absent from the exchange's symbol registry and the XRD currency still listed - MEXC (https://www.mexc.com/exchange/XRD_USDT) – XRD/USDT, the largest of these books by turnover. It quoted about 12% below every other venue from 22 to 23 August 2026 with XRD withdrawals reportedly suspended; the gap closed on 29-30 August — see How much liquidity is actually there below Venues that no longer trade XRD Five exchanges this page previously listed have withdrawn their XRD markets. Each was confirmed from the exchange's own API rather than from a broken link: - AscendEX – the spot page and the api/pro/v1/ticker endpoint both return 404. - Bitfinex – XRD appears in neither the exchange's traded-pair list nor its currency map. Radix's own token page still links a Bitfinex XRD/USD book that does not exist. - Bitget – the ticker endpoint answers with error 40309, "The symbol has been removed". - BitMart – "symbol is invalid"; XRD is absent from the spot symbol list. - Bybit – "Not supported symbols"; there is no XRD spot instrument. Separately, the XRDUSDT contract on BitMEX was a perpetual future rather than a spot market, and it settled on 30 June 2025. Checking a listing yourself No published index of XRD venues is currently complete. The official Radix token page (https://www.radixdlt.com/token) still links all five of the delisted exchanges above, and CoinGecko's XRD ticker table (https://www.coingecko.com/en/coins/radix) , which is refreshed from exchange APIs, omits both BingX and MEXC despite their markets being live. The reliable check before you send funds anywhere is the exchange's own market endpoint: a withdrawn listing answers with an explicit removal or invalid-symbol error, where a dead web page only fails to load. How much liquidity is actually there A listing is not a market. Each venue above was read through its own public ticker and order-book endpoint on 22 August 2026 at 23:06 UTC. Twenty-four-hour turnover is converted to US dollars at the quote asset, and the spread is the gap between the best bid and the best ask at the moment of reading, as a percentage of the mid price. Venue Market 24h turnover Top-of-book spread Last price MEXC XRD/USDT ~$83,900 2.72% $0.00075970 BingX XRD/USDT ~$68,700 0.81% $0.00089330 KuCoin XRD/USDT ~$20,100 0.90% $0.00088600 Gate.io XRD/USDT ~$10,400 0.81% $0.00089170 CoinEx XRD/USDT ~$3,500 1.52% $0.00088479 CoinEx XRD/BTC ~$3,000 2.02% 0.000000011497 BTC Five things follow from that table, and the first one is the reason to read it before sending money anywhere. - One venue was quoting a different price for the same token. MEXC last traded at $0.00075970 against $0.000885 to $0.000893 on every other book — roughly 14% below the median of the other five — and its 24-hour low of $0.00062630 is 28% under the lowest low any other venue printed. That is not a price. Arbitrage closes a gap of that size in minutes on a book carrying $84,000 a day, so a discount that persists is the signature of coins that cannot leave. Radix holders in the project's Telegram channel spent that evening attributing it to a MEXC wallet-maintenance window that had blocked XRD withdrawals for about two days ( t.me/radix_dlt/999111 (https://t.me/radix_dlt/999111) , /999122 (https://t.me/radix_dlt/999122) ). This wiki has not confirmed that from MEXC — the exchange's own currency-status endpoints refuse automated requests — so treat the cause as unverified and the measurement as the fact. The practical instruction is the same either way: confirm XRD withdrawals are enabled before you buy, not after. A token you cannot move to your Radix Wallet (/contents/tech/core-protocols/radix-wallet) is not a token you can stake, spend or use. - The whole centralized XRD spot market is about $190,000 a day. That is the sum of all six books, up from roughly $150,000 nine days earlier. MEXC and BingX together are 80% of it — 44% and 36%. But if MEXC's coins were fenced in on the day of reading, the market actually available to a buyer who intends to withdraw was nearer $106,000, of which BingX alone is 65%. Concentration this high means the venue you pick is most of your execution. - The spread is a moment, not a venue. This page carried the same six books read on 13 August 2026, and the two readings disagree almost everywhere. Gate.io then quoted the tightest spread of the six at 0.24% and now quotes 0.81%; BingX went the other way on 13 August (5.55% to 0.38%) and has since widened to 0.81%; KuCoin has halved, 1.91% to 0.90%. Nothing about the venues changed in between. Read any single row here as one moment, and do not pick a venue on a spread someone read on another day. - A tight spread is not depth. BingX quotes 0.81% — joint-tightest of the six, and the second-largest book — on 289.9 XRD at the best ask, about 26 cents of size. Gate.io's identical spread sits on 15,232 XRD, about $13.60. A quote tells you the price of the first few dollars and nothing about the price of the next few hundred, which is the number that decides what a purchase costs. - The on-ledger side is a real fraction of the market. DeFiLlama's Radix DEX aggregate (https://defillama.com/dexs/chain/radix) reported $26,295 of on-ledger swap volume over the 24 hours to 22 August 2026, and $191,805 over the preceding seven days, across seven Radix adapters. Against roughly $190,000 a day through the centralized books that is about one on-ledger dollar for every seven centralized — and against the $106,000 that was actually withdrawable, nearer one in four. Checking this yourself: every figure above comes from an endpoint anyone can call – api.mexc.com/api/v3/ticker/24hr, open-api.bingx.com/openApi/spot/v1/ticker/24hr, api.kucoin.com/api/v1/market/stats, api.coinex.com/v2/spot/ticker, api.gateio.ws/api/v4/spot/tickers and the matching /depth endpoints for order-book size, plus api.llama.fi/overview/dexs/radix for the on-ledger total and, for the Bitpanda fiat quotes, api.bitpanda.com/v1/ticker. Aggregator sites re-publish these with a lag and, as noted above, with gaps. Thirty-six hours later, the gap is still open The reading above was taken at 23:06 UTC on 22 August 2026, and a dislocation that size is normally arbitraged away by morning. It was not. Re-read from the same public endpoints at 11:11 UTC on 23 August 2026, MEXC last traded at $0.00078410 against a median of $0.00089295 across the other four order books — BingX $0.00089390, CoinEx $0.00089471, KuCoin $0.00089200, Gate.io $0.00089120. That is a 12.19% discount, and the venue's 24-hour low is unchanged at $0.00062630. Two things moved and one did not. MEXC's top-of-book spread more than halved, from 2.72% to 1.14% — that is what a book does when quoting resumes — and its 24-hour turnover eased from about $83,900 to $81,088, against $94,491 across the other five markets combined. The price did not converge. An intermediate reading a few hours earlier put the discount at 9.1%, so it is moving within a band rather than closing. A gap that survives a day and a half on a book turning over $80,000 is the clearest evidence available that the coins on it cannot leave, without anyone having to confirm why. The cause remains unverified here — MEXC's currency-status endpoints refuse automated requests, and the wallet-maintenance account is still only what holders reported in the project's Telegram channel. The instruction does not depend on the cause: confirm XRD withdrawals are enabled before you buy, not after. A discount you cannot withdraw is not a discount. The gap closed on the eighth day The paragraph above made a claim that could be checked later: if the discount was coins that could not leave, it would close when they could. On 29 August 2026 at 19:56 UTC a holder in the project's Telegram channel reported that MEXC had fixed the withdrawal problem the previous day ( t.me/radix_dlt/999942 (https://t.me/radix_dlt/999942) ). That is the same class of source as the original wallet-maintenance account and is no better confirmed – but this time the order books can be asked directly. Re-read from the same public endpoints at 03:13 UTC on 30 August 2026: Venue Last price 24h low 24h turnover MEXC $0.0008672 $0.000853 ~$58,700 BingX $0.0008686 $0.0008586 ~$55,000 CoinEx $0.00087815 $0.00086501 ~$3,300 KuCoin $0.000875 $0.000829 ~$13,600 Gate.io $0.0008608 $0.0008586 ~$5,400 MEXC is now 0.53% under the $0.0008718 median of the other four books, against 12.19% seven days earlier. The number that settles it is not the price but the low: MEXC's 24-hour low had been pinned at $0.00062630 through every reading of the episode, and it is now $0.000853, inside the range every other venue is printing. A book whose floor rejoins the market is a book whose sellers have somewhere else to go. Two things are worth keeping from the episode. The first is that the cause was never confirmed here and still is not – MEXC's own currency-status endpoints refuse automated requests, so both the suspension and the fix rest on holder reports, and only the price behaviour is this wiki's own measurement. The second is that the instruction does not change with the outcome: confirm XRD withdrawals are enabled before you buy, not after. It held while the gap was open and it will hold the next time one opens. Two of the six books stopped quoting Everything above was measured while native XRD could still move between venues. It cannot now. Read from the same public endpoints at 23:06 UTC on 3 September 2026, four days into the halt, two of the six books have gone quiet: - BingX stopped first, and its own registry dates it. The spot symbol record for XRD-USDT carries "status": 0 with offTime and maintainTime both set to 1788231600000, which is 03:00:00 UTC on 1 September 2026, five hours and forty-one minutes after the ledger stopped. The pair had been online since 05:07 UTC on 20 May 2023. Its 24-hour ticker now answers "symbol is not found". - KuCoin is not quoting either, and its two endpoints describe it differently. api/v1/market/stats returns the symbol with last price, bid, ask, high, low and volume all null; api/v2/symbols/XRD-USDT answers "Trading pair XRD-USDT does not exist". The XRD currency entry is still there, carrying isDepositEnabled and isWithdrawEnabled false and a Radix account-address regex. Holders in the project's Telegram channel read this as a delisting on the afternoon of 3 September and were contradicted within the minute ( t.me/radix_dlt/1001769 (https://t.me/radix_dlt/1001769) , /1001772 (https://t.me/radix_dlt/1001772) ). Neither exchange has published a notice this wiki has been able to find, so the reading the endpoints support is the one recorded here: two markets stopped quoting during a network halt, one of them at a timestamp the exchange itself records, and neither venue has removed its XRD asset entry. What is left quotes two different prices for the same token: Venue Market Last price 24h low 24h turnover Bitpanda XRD/USD $0.00066 brokerage quote no order book Gate.io XRD/USDT $0.0006582 $0.000658 ~$6,400 MEXC XRD/USDT $0.0004769 $0.0003738 ~$64,000 CoinEx XRD/USDT $0.00047261 $0.00041836 ~$2,900 Gate.io is quoting 38.6% above MEXC and CoinEx for the same token, and Bitpanda's fiat quote sits with Gate.io rather than in the middle. That is nearly three times the 14% dislocation this page recorded on 22 August, and it has the same cause with nothing left to close it. Arbitrage between two XRD books is a withdrawal from one and a deposit at the other, and both legs run through a ledger that has stopped: no coin can leave the venue quoting $0.00066 for the venue quoting $0.00047. The one route still open does not help, because it does not lead anywhere. Gate.io alone still permits withdrawals on its Ethereum-side entry for the eXRD wrapper token, and CoinEx's deposit configuration lists a single chain, the Radix one, which is closed at both ends. Each book is now a closed pool of the coins that happened to be sitting on that exchange when the network stopped, priced by whoever is still inside it. None of the four numbers above is the price of XRD. Until the network restarts there is no such number, and a purchase made at one of them cannot be moved to a Radix Wallet (/contents/tech/core-protocols/radix-wallet) , staked, or spent. Five days on, the gap has widened to 60% Read from the same public endpoints at 03:08 UTC on 8 September 2026, hour 174 of the halt: Venue Market Last price 24h low Top-of-book spread 24h turnover Bitpanda XRD/USD $0.00069 – – no order book Gate.io XRD/USDT $0.0006849 $0.000658 1.29% ~$1,530 MEXC XRD/USDT $0.0004287 $0.0004000 1.65% ~$58,800 CoinEx XRD/USDT $0.00042906 $0.00042212 2.00% ~$3,920 Gate.io now quotes 59.8% above MEXC and 59.6% above CoinEx for the same token, against the 38.6% this page recorded on 3 September, and both sides moved to get there: over those five days Gate.io rose 4.1% while MEXC fell 10.1% and CoinEx 9.2%. The two cheap books agree with each other to within 0.08%, and Bitpanda's fiat quote still sits with Gate.io rather than between them. The venue quoting the high price has the smallest book of the three. Gate.io turned over about $1,530 in twenty-four hours, down from about $6,400 on 3 September, against MEXC's $58,800; its best ask carries 254 $XRD, about 17 cents of size. Across all three order books the centralized $XRD market is now about $64,300 a day, against roughly $190,000 on 22 August, so two thirds of it has gone in seventeen days. Each book prices itself off whatever its own last trade was, and the thinner it gets the further that can drift. One market has closed since 3 September. CoinEx's XRD/BTC book, in the 22 August table above, is gone: api.coinex.com/v2/spot/market lists a single $XRD market, XRDUSDT, and a ticker request for XRDBTC answers "market XRDBTC not found". That leaves four quotes across three exchanges and one broker. The on-ledger volume figure is frozen rather than measured This page cites DeFiLlama's Radix DEX aggregate (https://defillama.com/dexs/chain/radix) above for on-ledger swap volume. That feed reports on a ledger which has committed no transaction since 31 August, and it is still publishing a number. Read at 03:08 UTC on 8 September, api.llama.fi/overview/dexs/radix returns $17,024 of twenty-four-hour volume with a one-day change of 0, and its daily series carries the identical $17,024 on 5, 6 and 7 September. Every dollar of it is attributed to one adapter, DefiPlaza; the other six Radix adapters return 0. No swap has settled on Radix in seven days, so an on-ledger volume figure published during the halt is a value carried forward and not a measurement. The same caution covers the price and market-capitalisation numbers aggregators publish for $XRD, because they are derived from the exchange books above and those books no longer agree with each other. The ledger restarted and the books did not Radix mainnet committed a round again at 11:35:28.96 UTC on 11 September 2026, ending a halt of 254 hours and 16 minutes. The question this page has asked at every reading – can the coins leave? – does not follow from the network being up. Read from the same public endpoints at 19:04 UTC on 11 September, seven and a half hours after the restart, with the Gateway (https://mainnet.radixdlt.com/status/gateway-status) reporting epoch 339,987 at state version 557,860,350 against the 557,840,628 that ended the halt: Venue Market Last price 24h turnover XRD deposits XRD withdrawals Bitpanda XRD/USD $0.00068 no order book not published not published Gate.io XRD/USDT $0.0006884 ~$3,740 disabled disabled CoinEx XRD/USDT $0.00048965 ~$4,670 disabled disabled MEXC XRD/USDT $0.0004826 ~$61,980 not published not published Gate.io quotes 42.6% above MEXC and 40.6% above CoinEx, against the 59.8% this page measured on 8 September. The gap narrowed from the bottom: in the three and a half days between the two readings MEXC rose 12.6% and CoinEx 14.1% while Gate.io moved 0.5%. That is what a discount does when the thing pinning it looks likely to lift. It has not lifted. Gate.io's currency record carries withdraw_disabled and deposit_disabled true on both of its chains – the Radix one and the Ethereum-side eXRD entry that was the single route still open on 3 September. CoinEx reports the same pair false on its only XRD chain, and KuCoin's Radix chain entry carries isWithdrawEnabled and isDepositEnabled false while its XRD/USDT market still answers with every field null. Two things follow, and both outlive this reading. An exchange reopens deposits and withdrawals on its own schedule after a halt rather than when the ledger says it can, so the instruction this page has carried since 22 August is the one that survived every stage of the episode: confirm XRD withdrawals are enabled before you buy, not after. And the four prices above are still not one price. Arbitrage between two XRD books is a withdrawal from one and a deposit at the other, and both legs remain closed at every venue that publishes their state. Cross-chain swaps & fiat on-ramps If you already hold another cryptocurrency, or want to buy with a card, these services convert directly into XRD: - RocketX (https://app.rocketx.exchange/swap/ETHEREUM.ethereum/RADIX.radix/1?from=Ethereum&to=Radix&mode=w) – cross-chain swap from assets on other networks into XRD - Switchere (https://switchere.com/) – fiat (card/bank) on-ramp On-ledger: bridge & swap on a native DEX Do not use Instabridge. Until 2026 this page routed readers through Instabridge (/ecosystem/instabridge) , the regulated Ethereum-to-Radix bridge. The service is closed and its instabridge.io domain has been re-registered by an unrelated party: as of 1 August 2026 it returns HTTP 301 to an online-gambling landing page, and the destination of that redirect has already changed at least once since 30 July 2026. Treat any link to that domain, including the one still carried on Radix's own token page, as hostile. Live routes for getting assets onto the Radix Network: - Withdraw from a centralized exchange. Sending XRD from one of the venues above straight to your Radix Wallet (/contents/tech/core-protocols/radix-wallet) address is the shortest path and involves no bridge at all — provided the venue is letting XRD out. Check the withdrawal status of XRD on the exchange before you buy; a venue with its wallet closed will still happily sell you the token, and on 22 August 2026 the largest XRD book was doing exactly that at a 14% discount. - Hyperlane Nexus (https://nexus.hyperlane.xyz/) – the Hyperlane (/ecosystem/hyperlane) warp route Radix names for swapping the Ethereum-side eXRD wrapper 1:1 for native XRD. - Astrolescent (/ecosystem/astrolescent) – cross-chain swap (https://astrolescent.com/) that delivers XRD to a Radix account from assets held on other networks. Once you hold assets on Radix, swap them on a Radix-native decentralized exchange: - Ociswap (/ecosystem/ociswap) – AMM and concentrated-liquidity DEX - CaviarNine (/ecosystem/caviarnine) – order-book and concentrated-liquidity DEX - DeFiPlaza (/ecosystem/defiplaza) – single-pool DEX - Astrolescent (/ecosystem/astrolescent) – swap aggregator that routes across pools for the best price ## Radix Week in Review: Rehearsing the Restart URL: https://radix.wiki/blog/week-in-review-2026-09-06 Updated: 2026-09-11 Summary: The fix for the bug that stopped Radix is written, tested and public, as a change to the Radix Engine named Eagle Ray. It gets rehearsed on Stokenet,… Week of 31 August – 6 September 2026 Top story The fix for the halt is written, and the test network gets it first The week in brief - The fix for the bug that stopped Radix is written, tested and public, as a change to the Radix Engine named Eagle Ray. - It gets rehearsed on Stokenet, Radix's test network, over the coming days. That is the first dated step towards a restart. - The Radix Accountability Council has confirmed the cause and says the remaining work is delivering the fix safely and getting the validator operators to adopt it. - A written account of what happened will follow the restart, and why the audits missed the bug is being looked into separately. - The DAO's incorporation went ahead anyway. RADIX DAO LLC gets filed in the Marshall Islands on Monday. - Every number in this issue was read from the stopped ledger, which turns out to answer any question that names a moment in its history. Radix mainnet, the live network that holds real money, has been stopped since the evening of 31 August. Someone found a bug in the Radix Engine (/contents/tech/core-protocols/radix-engine) , the software that runs every transaction on Radix, and used it to take tokens out of accounts they did not own. In under an hour they emptied the network of its bridged assets, which are wrapped copies of tokens from other blockchains, and sent them out through a bridge called Hyperlane (/ecosystem/hyperlane) . The operators who run Radix's validator machines shut them down that evening. The drain and halt page (/contents/history/hyperlane-asset-drain-2026) has it transaction by transaction. This week was about the repair, and it has a shape now that it did not have on Monday. The fix, and the rehearsal Restarting needs four things in order: someone writes a fix; it goes into a named protocol update; someone releases a new version of the node software containing it; and enough validator operators install that version and signal they are ready, which is how a Radix upgrade activates. The first two are done, in one pull request. A contributor called 0xOmarA opened pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) on the Radix Engine's repository on 2 September, adding a protocol update named Eagle Ray. Radix names its upgrades alphabetically, after Anemone, Bottlenose, Cuttlefish and Dugong. The change is small: before running a method call, the engine now checks whether the caller is allowed to see the thing it is calling the method on, and refuses if it is not. Step three is where it sits. Nobody has merged the pull request, and the newest release of babylon-node (https://github.com/radixdlt/babylon-node/releases) , the software the validator operators actually run, is still v1.3.0.5 from June. What moved this week is the rehearsal. Daffy, a community contributor who maintains the DAO's governance repository, told the Radix Developers group this morning to expect Stokenet (/contents/tech/releases/stokenet) , Radix's public test network, to go unstable and go offline over the coming days while they run the upgrade through it. Stokenet is working normally, so breaking it on purpose is the point. It is the first thing anyone has put a timeframe on since the network stopped. What the council has said The Radix Accountability Council (/ecosystem/radix-accountability-council) , the volunteer group currently running the project, gave the fullest account on 3 September. It has identified and confirmed the cause, a flaw in how the Radix Engine hands out references to vaults, a vault being the container that holds tokens inside an account. The patch, it said, is the easy part. The fix has to reach the network without giving anyone a window to use the bug again first, and then enough validator operators have to read the plan, agree with it and install the software. About 100 independent operators run those machines, so restarting means 100 separate decisions. Daffy added two things on 5 September. A written account of the bug will come after the restart, and why the paid security audits missed it is being looked into separately. That is the first firm commitment to publishing one. RADIX WIKIThe Week in Commits31 AUG – 6 SEPCOMMITS THIS WEEK AGAINST LAST WEEKweek to 30 Augweek to 6 Sephyperscale-vm3386hyperscale-rs1113radixdlt-scrypto00babylon-node00radix-engine-toolkit00Nothing landed in radixdlt-scrypto or babylon-node, the two repositoriesthat have to produce the restart. All 19 commits are by one person.GitHub, default branches of the five tracked repositories.radix.wiki 19 commits this week against 349 last week. Reading a stopped ledger Almost everything that displays Radix data reads it from the Gateway API (/contents/tech/core-protocols/radix-gateway-api) : wallets, explorers, price dashboards, this site's charts page. Ask it where the ledger is, the ledger being Radix's record of every account and what it holds, and the node answers from the last transactions it agreed. Ask what the ledger contains, and the answer comes from a separate database that copies the ledger as it goes, is allowed to be 12 minutes stale, and is now five days behind. It refuses. The useful part is that the staleness rule is skipped for any request naming a specific point in the ledger's history. Ask for the validator list as of state version 557,840,622, the last state the Gateway’s status endpoint reported, and the same endpoint answers in full. No account or key is needed, and every number below comes from that request. It also means anyone can check what their own account held when the network stopped, which is the question most people have been asking all week. RADIX WIKIAsking a Stopped LedgerMAINNETTHREE QUESTIONS, ONE GATEWAY, ONE MOMENT200Where is the ledger?epoch 339,896, last agreed 31 AugustThe node answers from the last transactions it agreed.500What does the ledger hold?error: the database is 5 days behindFrom a copy of the ledger, allowed to be 12 minutes stale.200What did it hold when it stopped?287 validators, 4.88bn XRD stakedNaming a point in the ledger’s history skips that rule.WHAT A PROGRAM THAT ADDS UP THE EMPTY ANSWER PUBLISHES0 validators, 0 XRD stakedRead from mainnet.radixdlt.com on 6 September 2026.radix.wiki Only the middle question fails. One thing to fix at home first. A program asking both questions gets a timestamp that looks current attached to a list of nothing, and if it adds that empty list up, the error becomes a zero. This site's charts page (/charts) did that for six days, reporting no validators and no XRD staked as though someone had measured it. The code changed this morning: it now raises an error instead of returning a half-empty list, the charts page says the data is unavailable, and the weekly series (/contents/tech/operations/network-weekly) has the bad entry removed. The DAO's paperwork went ahead The company that built Radix is handing it over to a DAO owned by the people who hold XRD, Radix's own token, and part of that is registering a legal entity for the DAO to be. On 5 September a council member said the contract with MIDAO, the firm handling it, is signed and the fee is paid, and that filing RADIX DAO LLC in the Marshall Islands starts on Monday. The registry takes four to six weeks, so the certificate should arrive in the first half of October. None of it needed the network. The other half of the handover does. Ratifying the DAO's governance rules (/ideas/radix-network-dao-charter) needs a vote by XRD holders, and that vote runs on the network, so it waits. Hyperscale's author turned down the payment Hyperscale (/contents/tech/research/hyperscale-rs) is a replacement for the part of Radix that puts transactions in order and agrees them, written almost entirely by one developer who goes by flightofthefox. In August the community voted to pay him in five milestone instalments. On 3 September, days before the first was due, he said he will not take the money. I just want to work on the tech and try to keep my sanity and dignity, he wrote, and said he will build the rest anyway and the DAO should spend the tokens on something else. The group argued about it all day, mostly over whether Hyperscale is worth finishing if the network it replaces does not come back. His commit history shows a pause rather than an answer: 338 commits to the virtual machine in the week to 30 August, 6 in the week since. The week on the ledger The last numbers Radix produced, against 29 August, which is two and a half days earlier rather than a full week. They will be the same next week unless it restarts first. Metric When it stopped Since 29 August XRD staked 4.88 billion down 52 million, or 1% Validators in the active set, of those registered to be 100 of 179 unchanged Share of stake held by the largest 10 39.7% up 0.1 points Validators charging a fee that differs from the one they publish 80 up 3 Fee changes queued for epochs the network never reached 3 down 3 A validator takes a fee out of the staking rewards it passes back to the people who stake with it, and announces a change in advance, naming the epoch at which the new rate starts. An epoch is a stretch of about five minutes, and epochs only advance while the network runs. Three announcements are queued: Leaf Node going from 1% to 100%, Apollo Pool from 20% to 100%, and Avaunt Staking (/ecosystem/avaunt-staking) from 2% to 25% on 139 million XRD. All three take effect shortly after the restart, and nobody staked with them can move out beforehand. Concentration watch Eight validators between them held a third of all staked XRD when the network stopped, the same eight as in each of the three previous weeks, and 15 held half. RADIX WIKIWho Holds the StakeAT THE HALTSHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third can stop the network agreeing. Eight is where thatline falls, and it has been eight for four weeks.The 100 validators in the active set, read at state version 557,840,622.radix.wiki Eight validators hold a third of the stake between them. The ledger This series records dated predictions and scores them. One came due today, and it is a hit. On 18 August it predicted that StakeSafe (/ecosystem/stakesafe) would raise the fees on all three of its validators as announced, and it did: Amsterdam and Rotterdam are charging 25%, Seed Node 100%, landing about a day before the network stopped. Two new predictions, both due 20 September: that mainnet processes transactions again, and that a release of babylon-node containing Eagle Ray is published. The second has to happen before the first can. The scores and the exact checks are on the series index (/blog/week-in-review) . This week on the wiki Hyperlane Asset Drain and Network Halt (August 2026) (/contents/history/hyperlane-asset-drain-2026) has been rewritten every few hours since it happened and now runs day by day. The part to read is the section on checking your own account: the Radix dashboard cannot tell you what you hold, because it asks the Gateway the question the Gateway is refusing, but two requests naming the last state version can. What to watch - Stokenet going offline on purpose, this week, while they rehearse the upgrade. Confirmed by Stokenet reporting a protocol version later than Cuttlefish. - A babylon-node release containing Eagle Ray, which has to come before mainnet restarts. Confirmed on the releases page. - The Marshall Islands certificate for RADIX DAO LLC, in the first half of October. Corrections Last week's issue said the StakeSafe prediction could not be settled until the network came back. It could: a request naming the last state version settles it, and it is scored above. Sunday's snapshot script recorded zero validators for the week, because the Gateway returned an error and the code counted it as an empty result. Removed, and the script now refuses a reading with no validators in it. Next week has one shape to it. A release of babylon-node carrying Eagle Ray, a rehearsal on Stokenet, and 100 operators deciding to start their machines again. References: 1. Radix Gateway, read at state version 557,840,622 on 6 September 2026 (https://mainnet.radixdlt.com/status/gateway-status) 2. Radix Gateway API documentation: naming a ledger state in a request (https://radix-babylon-gateway-api.redoc.ly/) 3. radixdlt-scrypto pull request #2093, the fix and the Eagle Ray protocol update (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) 4. radixdlt-scrypto pull request #2095, build automation, 6 September 2026 (https://github.com/radixdlt/radixdlt-scrypto/pull/2095) 5. babylon-node releases, newest v1.3.0.5 of 1 June 2026 (https://github.com/radixdlt/babylon-node/releases) 6. babylon-node pull requests, 6 September 2026 (https://github.com/radixdlt/babylon-node/pulls) 7. Radix Accountability Council on the fix and the DAO, 3 September 2026 (https://t.me/RadixAccountabilityCouncil/918) 8. Radix Accountability Council: MIDAO signed, fee paid, 5 September 2026 (https://t.me/RadixAccountabilityCouncil/988) 9. radixdao.org governance index (https://radixdao.org/govern/) 10. Radix protocol updates: how a validator signals readiness (https://docs.radixdlt.com/docs/node-protocol-updates) 11. CoinGecko, XRD, read 6 September 2026 (https://www.coingecko.com/en/coins/radix) 12. DeFiLlama, Radix chain value (https://defillama.com/chain/Radix) 13. Radix Dashboard, the account that collected the 26 transactions (https://dashboard.radixdlt.com/) Radix Week in Review series, Issue #11: ← Previous: Issue #10, Aug 24–30, 2026 (/blog/week-in-review-2026-08-30) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: A rebuilt Stokenet caught up on three protocol updates in under two hours, because what gates an update is a stake threshold rather than a date. ## Radix Week in Review URL: https://radix.wiki/blog/week-in-review Updated: 2026-09-11 Summary: Every week the Radix Week in Review records what the ecosystem said would happen, with a date by which it should have happened and the check that will… Latest Issue #11 Recaps 11 Open predictions 4 Resolved 4 Hit rate 100% Scoring Unrestricted. The network restarted at 11:35 UTC on 11 September 2026; during the halt, claims resolved against reads pinned to state version 557,840,622 Tracking since 2026-08-18 Feed RSS (/week-in-review.xml) Every week the Radix Week in Review records what the ecosystem said would happen, with a date by which it should have happened and the check that will settle it. When the date arrives the claim is scored against the ledger, the repository or the source, and the result is kept here whichever way it went. Nothing is removed from this page because it turned out badly, and nothing is recorded that has no date and no check. Open predictions Scoring is unrestricted again. Radix mainnet halted on 31 August 2026 (/contents/history/hyperlane-asset-drain-2026) and restarted at 11:35:28.96 UTC on 11 September, 254 hours and 15 minutes later, so a claim needing a transaction after the halt settles like any other from here. Two notes on what this page wrote while it was down. The 30 August note recorded three claims as unscorable for the duration, on the ground that the Gateway answers /state/validators/list with HTTP 500 while its database is behind the network; that was wrong, because the freshness guard is skipped for any request carrying at_ledger_state, and a read pinned to state version 557,840,622 returned HTTP 200 with the full validator set throughout. Those pinned reads stand and the claims they settled stay settled. What this page called that state version does not: 557,840,622 is the last state the Gateway’s status endpoint reported, not the last the ledger reached, and the transaction stream (https://mainnet.radixdlt.com/stream/transactions) shows the ledger ran on to state version 557,840,627 at epoch 339,897 round 4, timestamped 21:19:48.939 UTC. The halt claim below had that distinction right from the day it was recorded, because its check names the unpinned endpoint and says in terms that /status/gateway-status answers 200 from the frozen ledger and cannot tell a restart from its absence. Claim Who Due by How it gets checked Recorded hyperscale-vm records at least 200 commits in the fortnight from 31 August to 13 September 2026. flightofthefox 2026-09-14 GitHub API: GET /repos/hyperscalers/hyperscale-vm/commits with since=2026-08-31T00:00:00Z and until=2026-09-14T00:00:00Z, counted across pages on the default branch. Baseline: 338 commits in the seven days to 30 August 2026, all by flightofthefox, across five of seven days, against 11 in hyperscale-rs and none in radixdlt-scrypto, babylon-node or radix-engine-toolkit. Hit at 200 or more commits in the fortnight; miss below it. A single contributor is the whole sample, so a holiday settles this as surely as a change of direction would. First in-window reading, taken 1 September 2026 11:12 UTC: 6 commits, all dated 31 August and none on 1 September, against a baseline pace of roughly 48 a day. Re-read 5 September 2026 23:07 UTC: still 6 commits, the newest of them a451a671 of 31 August 13:21 UTC, so the repository has recorded nothing for five consecutive days and 194 commits remain to be found in the eight days to 13 September. The window opened on the day of the drain, and the repository owner spent that evening liquidating his exposure to Radix in public, which is recorded on the drain page. At one day that reading dated a disruption; at five it is the pace. Re-read 10 September 2026 03:06 UTC, and the two earlier readings were measuring the wrong thing. The same query now returns 59 commits, and 40 of them carry author dates between 1 and 5 September, the five days both earlier readings recorded as silence. Author and committer timestamps are identical on every one of the 59 and the history holds no merge commit, so nothing was rewritten: the commits were made when they say and reached the default branch afterwards. A commit listing dates the commit, not the push, so it cannot see work held back. flightofthefox said as much in the hyperscale.rs channel while this was happening, at t.me/hyperscale_rs/12134 on 7 September and t.me/hyperscale_rs/12141 on 8 September: work was on a feature branch for leg local execution, an almost complete rewrite of how execution works, and he was not merging it early to move a tracker’s score. The check stands as recorded and the claim stays open: 59 of 200, with 141 to find in the four days to 13 September. 2026-08-30 At least one of the Radix DAO's 24 governance documents moves from pending to in force, with its SHA-256 digest recorded on the ledger. Radix DAO 2026-09-20 radixdao.org/govern listed 24 documents across ten categories on 18 August 2026, every one pending and none in force. Re-read 30 August 2026: the page now lists 23 rule-bearing documents, each marked "Signed, awaiting ratification" with its SHA-256 digest published and recorded in ratification proposal GP-PRE-1, and the page says in its own words that nothing there is in force yet. Signing is not ratification, so the claim is untouched by it. Resolved when any document reads as active and its digest is on-ledger. Re-read 30 August 2026 after the Radix Accountability Council activated radixdao.org as the DAO official venue: the index now lists 27 rule-bearing documents, 26 reading "Signed, awaiting ratification" and one pending, the digests recorded in ratification proposal GP-PRE-1, and the page states that nothing there is in force. The count grew and the status did not, so the claim is untouched. Re-read 5 September 2026: radixdao.org/govern lists 24 rule-bearing entries, 23 of them reading "Signed · awaiting ratification" with a published SHA-256 digest and the Roles Registry pending, alongside three reading guides carrying no status at all. The page still states in its own words that nothing there is in force, so a third reading leaves the claim untouched. The count is three below the 27 recorded on 30 August, and the three unstatused guides are the likely difference, so it is not read here as documents being withdrawn. 2026-08-18 CaviarNine's two validators, unmentioned in its departure announcement, are deregistered, sold, or have a fee change filed against them. CaviarNine 2026-10-04 Gateway /state/validators/list for CaviarNine-1 (validator_rdx1sd8c8v9tffjtgqtuzygnctrmyfnhkd63avcgpzuknx3dlklds85rkv) and CaviarNine-2 (validator_rdx1sv7zpyuj27ycmcsnw0de94j2rp93csq6gvcm4dl4yh4p4fxv9j5pqx). Re-read at epoch 339,438 on 30 August 2026: both still registered, both still accepting delegated stake, effective_fee_factor.current 0 on each and no effective_fee_factor.pending, holding 113,701,732 and 115,610,098 XRD. CaviarNine-2 has shed 4,022,122 XRD (3.4%) in the five days since the previous reading while CaviarNine-1 held flat, which is delegators leaving rather than anything the operator has done, and none of it is a hit condition. Read effective_fee_factor.pending, not validator_fee_change_request: both validators have carried a non-null request since epoch 282,893, a cut to 0 that took effect roughly seven months before this claim was recorded and was never cleared, so the raw field is non-null whatever happens next. Hit if either deregisters, stops accepting stake, changes owner, or acquires an effective_fee_factor.pending by the due date. Re-read at epoch 339,487 on 30 August 2026 11:11 UTC: both still registered, both still accepting delegated stake, effective_fee_factor.current 0 on each with no pending, holding 113,723,443 and 115,613,836 XRD. CaviarNine-2 has recovered slightly against the 30 August 07:06 reading. Re-read 6 September 2026 at 11:02 UTC, pinned to state version 557,840,622, epoch 339,896, the last state the Gateway’s status endpoint reported during the halt: both still registered, both still active in epoch, effective_fee_factor.current 0 on each with no pending entry, holding 113,116,830 and 115,034,368 XRD. No hit condition is met, and none can now be met before the network restarts, because deregistering, selling or filing a fee change all require a committed transaction. 2026-08-23 The Marshall Islands issues a certificate of formation for RADIX DAO LLC. Radix Accountability Council 2026-10-25 The Radix Accountability Council reported on 29 August 2026 that it and counsel had agreed amended terms with MIDAO, that payment and submission of RADIX DAO LLC to the Marshall Islands government follow, and that the filing rolls out from Monday 31 August. It also said the registry takes four to six weeks to grant and issue the certificate once the submission is complete, and that it would report advancements rather than every step. Hit when a certificate of formation for RADIX DAO LLC is published or announced, on radixdao.org notices, in the RadixAccountabilityCouncil channel, or in the Marshall Islands registry. The six-week window from 31 August closes on 12 October; this allows a further fortnight. Re-read 5 September 2026, and the date this window is measured from has moved. RAC member Tadkis posted at 13:17:43 UTC on 5 September, at t.me/RadixAccountabilityCouncil/988, that the agreement with MIDAO has been signed and the registration fee paid, and that formal registration is scheduled to begin on Monday, which is 7 September and a week later than the 31 August the council gave on 29 August. Six weeks from 7 September closes on 19 October, so the fortnight of slack recorded above is now six days. Re-read 7 September 2026 at 23:06 UTC, and the Monday the window is measured from has now been reported on. In its status update at 20:45:41 UTC, t.me/RadixAccountabilityCouncil/1000, the council says the sign-up for MIDAO’s service is concluded and that the transition council is working through the remaining administrative steps, up to the point where it is for MIDAO to submit the request to the Marshall Islands. So the engagement is complete and the filing with the registry has not been made, which leaves the four-to-six week grant window not yet started. Six weeks from 7 September closes on 19 October, six days inside this claim’s due date. 2026-08-30 Resolved Claim Due by Outcome Evidence Scored in Radix mainnet commits a round again, ending the halt that began on 31 August 2026. 2026-09-20 Hit Hit at 11:35:28.96 UTC on 11 September 2026, nine days before the due date, and scored on the check exactly as the claim wrote it. Gateway POST /state/validators/list with no at_ledger_state, read at 17:05 UTC on 11 September, answers HTTP 200 with ledger_state.epoch 339,963 and all 287 validators, against a hit condition of any epoch above 339,896. The restart itself is two consecutive entries in the transaction stream (https://mainnet.radixdlt.com/stream/transactions) with nothing between them: state version 557,840,627 at epoch 339,897 round 4, timestamped 21:19:48.939 UTC on 31 August, then 557,840,628 at epoch 339,897 round 5, timestamped 11:35:28.96 UTC on 11 September, which is 254 hours, 15 minutes and 40 seconds apart. Consensus resumed under a user transaction moratorium that held epoch 339,897 to empty blocks, and the Eagle Ray fork enacted at the start of epoch 339,898, where round 2 committed 17 user transactions at 11:39:25.129 UTC. The Radix Accountability Council confirmed liveness restored (https://t.me/RadixAccountabilityCouncil/1026) at 14:37 UTC, three hours after the fact. The claim named the node runners and they are who settled it: adoption of babylon-node v1.4.0.0 stood at 31.22% of active validator-set stake at 07:12 UTC and cleared two thirds inside the next four hours. Wiki maintenance sweep, 11 September 2026 A babylon-node release carrying the Eagle Ray protocol update is published. 2026-09-20 Hit Hit on 8 September 2026, two days before it was scored, and the delay is this ledger’s own fault rather than the release’s. Read at 03:07 UTC on 10 September 2026, GET /repos/radixdlt/babylon-node/releases returns v1.4.0.0-RC1, named Eagle Ray v1.4.0.0-RC1, published 2026-09-08T15:35:42Z from merge commit 7400951e with seven assets attached. That is a tag above v1.3.0.5 whose notes name Eagle Ray, which is the hit condition as recorded on 6 September. The release is flagged pre-release, so GitHub’s /releases/latest still resolves to v1.3.0.5-test.1 of 2026-09-08T12:28:06Z and an operator following the documented install path gets the older build; that matters to a node runner and it is not part of the check, which asked whether a release carrying the protocol update exists. It does. Wiki maintenance sweep, 10 September 2026 StakeSafe's three validators raise their fees as scheduled: Amsterdam and Rotterdam from 15% to 25%, Seed Node from 15% to 100%. 2026-09-06 Hit Hit, and scored on evidence the 30 August note recorded as unreadable. The Gateway refuses an unpinned state read while it is five days behind the network, but the freshness guard is skipped for a read that names a ledger state, and the frozen state is 288 epochs past Amsterdam's settling epoch. Read at 11:02 UTC on 6 September 2026 with at_ledger_state pinned to state version 557,840,622, epoch 339,896, the last state the Gateway’s status endpoint reported during the halt: /state/validators/list returns HTTP 200 with all 287 validators. StakeSafe Amsterdam (validator_rdx1s066xuq885l0mttgmx4ptflte6fepkt0c06mqnqtdgajj4mcwh70q4) reads effective_fee_factor.current 0.25 on 75,671,832 XRD; StakeSafe Rotterdam (validator_rdx1s048k34ctk3m57gumema2e5jmhfxhdryyr5hq42xa9q59pvn8lezg8) 0.25 on 78,235,400 XRD; StakeSafe Seed Node (validator_rdx1svlvyezsxp467pznd2kfnhqpenmw7hpdgnxjgu3s8mzxtruz77d3q3) 1 on 210,603 XRD. All three still store validator_fee_factor 0.15, which is the engine declining to rewrite the substate and the reason the check named effective_fee_factor. Three of three as claimed, effective at epochs 339,608 and 339,609, roughly a day before the network stopped. Radix Week in Review, 6 September 2026 StakeSafe files a fee change request on the Avaunt Staking validator it bought on 21 August, raising the fee above 2%. 2026-09-20 Hit Hit on 26 August 2026, 25 days before the due date, and the settling transaction is on the ledger: txid_rdx17sfhjgn0j8ymny889992j8aemk3q6vrjs2x97v6xpccrhe35w63snnyd3s at 20:47:04 UTC, epoch 338,450, state version 555,398,021. It proves the Avaunt owner badge [834bcbdc3bf9d9211f827af8b2c84c56cd156a4de412690718c624a2beb0] from account_rdx16xrp5e8faqxfa8j20xh5u29js8umdz7zcu6m0xnjfewkcxkpkdl84f, the same account that holds StakeSafe Amsterdam's owner badge, and calls update_fee Decimal("0.25") on the validator. Confirmed at the register at epoch 339,438 on 30 August 2026 07:06 UTC: effective_fee_factor.current 0.02 with pending 0.25 effective at epoch 342,482, on 142,194,735 XRD. The claim asked only for the request to be filed, so it settles now; whether 25% is actually charged is a separate question that the epoch answers around 9 September. Wiki maintenance sweep, 30 August 2026 Every recap 4 of 4 predictions hit (100%), 4 still open. The series is published every Sunday and carried in full by its own feed (/week-in-review.xml) . Sep 2026 # Week Title What it was about Links (wiki / out) #11 (/blog/week-in-review-2026-09-06) Aug 31 – Sep 6, 2026 Rehearsing the Restart Six days stopped, and the fix still unmerged. 17 / 2 Aug 2026 # Week Title What it was about Links (wiki / out) #10 (/blog/week-in-review-2026-08-30) Aug 24–30, 2026 A Test Network Replays Fifteen Months in Two Hours A threshold is a measuring instrument, and it reports nothing when every hand belongs to the same body. 15 / 0 #9 (/blog/week-in-review-2026-08-23) Aug 17–23, 2026 CaviarNine Leaves, and Its Contracts Stay Live An operator owns the part that leaves; the ledger holds the part that stays. 14 / 0 #8 (/blog/week-in-review-2026-08-16) Aug 10–16, 2026 A Post-Quantum Signature Lands in the New Engine Authority that travels with a checkable mark, versus authority asserted by a name. 9 / 1 #7 (/blog/week-in-review-2026-08-09) Aug 3–9, 2026 Milestone 1 Done, and the New Engine Goes Public The shaft is turning faster and nothing is attached to it. 13 / 0 #6 (/blog/week-in-review-2026-08-02) Jul 27 – Aug 2, 2026 Hyperscale Gets Its Own Virtual Machine A road cannot be widened into a railway. 12 / 2 Jul 2026 # Week Title What it was about Links (wiki / out) #5 (/blog/week-in-review-2026-07-26) Jul 20–26, 2026 Hyperscale Answers the Sharding Questions Hyperscale's design was set against the standard list of sharding problems and answered point by point, and the Foundation put the DAO about a month out. 14 / 1 #4 (/blog/week-in-review-2026-07-19) Jul 13–19, 2026 The Consensus Work Is Nearly Done The consensus half of the Rust rebuild is essentially built and formally verified, and after a week of worry, candidates began standing for the council. 14 / 0 #3 (/blog/week-in-review-2026-07-12) Jul 6–12, 2026 hyperscale-rs Closes On Its First Milestone Everything that moved this week was built by the community: the Rust rebuild of Radix's scaling design, a Rust SDK, and Hookah going open source. 19 / 1 Mar 2026 # Week Title What it was about Links (wiki / out) #2 (/blog/week-in-review-mar-16-22-2026) Mar 16–22, 2026 Hyperscale, One Month Open A month after the Foundation published the Hyperscale code, its 500,000 transactions-per-second result is something anyone can rebuild and check. 13 / 2 #1 (/blog/week-in-review-mar-9-15-2026) Mar 9–15, 2026 The Handover Begins The Foundation invited outside operators to take over three services it runs itself, and the elected council that will oversee the process took its seat. 12 / 4 ## Radix Ecosystem Operational Status URL: https://radix.wiki/contents/resources/radix-ecosystem-operational-status Updated: 2026-09-11 Summary: 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… Radix Ecosystem Operational Status Type Directory index Covers All 150 project pages under Ecosystem (/ecosystem) Operational 59 Testnet / pre-launch 8 Dormant 48 Closed / departed 35 Network status Operational. Mainnet restarted at 11:35:28 UTC on 11 September 2026 after 254 hours and 15 minutes down; user transactions resumed at 11:39:25 UTC when Eagle Ray enacted at epoch 339,898, with 80.85% of active-set stake on the release. See the notice below Last rebuilt 2026-09-05 Source The status field on each project page This page indexes every project page on this wiki under Ecosystem (/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 (https://t.me/hyperscale_rs/10402) 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 (/contents/tech/releases/radix-mainnet-xian) replaces the Radix Engine (/contents/tech/core-protocols/radix-engine) with a purpose-built VM ( t.me/hyperscale_rs/10334 (https://t.me/hyperscale_rs/10334) ), and existing dApps are expected to migrate rather than carry over untouched ( t.me/hyperscale_rs/10346 (https://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 (/contents/history/hyperlane-asset-drain-2026#the-fix-and-the-restart) ; 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 (/contents/history/hyperlane-asset-drain-2026) through a flaw in the Radix Engine (/contents/tech/core-protocols/radix-engine) . Read again at 23:09 UTC on 3 September, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) 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 (https://t.me/RadixAccountabilityCouncil/969) 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 (https://t.me/RadixAccountabilityCouncil/971) , 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 (https://t.me/RadixAccountabilityCouncil/971?embed=1&mode=tme) 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 (https://t.me/radix_dlt/1001788) ” 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 (https://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 (https://t.me/RadixAccountabilityCouncil/971) 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 (/ecosystem/caviarnine) 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 (https://mainnet.radixdlt.com/status/gateway-status) 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 (/contents/tech/releases/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 (https://t.me/RadixAccountabilityCouncil/971) 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 (/ecosystem/hyperlane) , RSwap (/ecosystem/rswap) and Run Fly (/ecosystem/runfly) — had never been indexed at all, and five entries were still listed as operational after their own pages had moved on ( CrumbsUp (/ecosystem/crumbsup) , PokerXRD (/ecosystem/pokerxrd) , Radix List (/ecosystem/radix-list) and The Meme Studio (/ecosystem/the-meme-studio) to dormant, Academia Scrypto (/ecosystem/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 (/contents/history/hyperlane-asset-drain-2026) 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" (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) . 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" (https://t.me/RadixAccountabilityCouncil/1000) – 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 (https://github.com/radixdlt/babylon-node/releases) 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 (/contents/tech/releases/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 (/contents/tech/releases/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 (https://github.com/radixdlt/babylon-node/releases/tag/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 (/developers/infrastructure/01-running-a-node) . 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% (/ecosystem/defiplaza#halt-reading) . Astrolescent’s per-token page still returns HTTP 500 and app.caviarnine.com still refuses the connection, which is CaviarNine’s own wind-down (/ecosystem/caviarnine) . 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 (https://t.me/RadixAccountabilityCouncil/1012) reported its first milestone: the new node software and the protocol update were deployed on Stokenet (/contents/tech/releases/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 (https://github.com/radixdlt/babylon-node/releases/tag/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 (/developers/infrastructure/01-running-a-node) 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 (https://t.me/radix_dlt/1002777) 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 (/ecosystem/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 (https://mainnet.radixdlt.com/status/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 (https://t.me/RadixAccountabilityCouncil/1019) 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 (/ecosystem/stakesafe) 's Bart Roozeboom announced in the main Radix Telegram group that the operator's free Radix Network Dashboard (https://validators.stakesafe.net) now tracks Eagle-Ray adoption live (https://t.me/radix_dlt/1002910) , 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 (/contents/tech/core-protocols/cerberus-consensus-protocol) 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 (https://t.me/RadixAccountabilityCouncil/1019) 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 (https://mainnet.radixdlt.com/status/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 (https://github.com/radixdlt/babylon-node/blob/main/core-rust/state-manager/src/protocol/protocol_configs/mainnet_protocol_config.rs) : 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 (https://t.me/RadixDevelopers/66388) , one reading it from the code and Daffy confirming (https://t.me/RadixDevelopers/66385) 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 (https://mainnet.radixdlt.com/status/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 (https://validators.stakesafe.net) 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 (https://t.me/radix_dlt/1003000) : 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 (https://t.me/radix_dlt/1002990) 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 (/ecosystem/stakesafe#sweep407-offline-by-design) rather than counting down. The numbers behind that, read at 11:05 UTC on 11 September: the adoption tracker (https://validators.stakesafe.net) 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 (https://mainnet.radixdlt.com/status/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 (https://mainnet.radixdlt.com/status/gateway-status) returns a moving ledger for the first time since 31 August, and the transaction stream (https://mainnet.radixdlt.com/stream/transactions) 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 (https://validators.stakesafe.net) 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 (/ecosystem/radix-accountability-council) announced the restart at 14:37 UTC, three hours later, in a message (https://t.me/RadixAccountabilityCouncil/1026) 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 (/ecosystem/radix-foundation) is listed as active and has been in maintenance mode since May 2026 (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) . - 🟡 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 (https://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 (/ecosystem/topradixnode) , Juicy Stake (/ecosystem/juicy-stake) , Phoenix (/ecosystem/phoenix) and RadixUID (/ecosystem/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 (https://dashboard.radixdlt.com) — 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. Operational (59) Education - RADIX.wiki (/ecosystem/radix-wiki) Finance - Astrolescent (/ecosystem/astrolescent) - Atomix (/ecosystem/atomix) - BCW Technologies (/ecosystem/bcw-technologies) - CaviarNine (/ecosystem/caviarnine) - DeFiPlaza (/ecosystem/defiplaza) - Dogecube (/ecosystem/dogecube) - HydraSwap (/ecosystem/hydraswap) - Liquify (/ecosystem/liquify) — website not resolving when checked on 2026-08-20 (HTTP 403) - Ociswap (/ecosystem/ociswap) - RSwap (/ecosystem/rswap) - ShardSpace (/ecosystem/shardspace) - SRWA (/ecosystem/srwa) - Surge (/ecosystem/surge) - Weft Finance (/ecosystem/weft-finance) Gaming - ASCENT (/ecosystem/ascent) - Bardix (/ecosystem/bardix) - Doubt/it! (/ecosystem/doubt-it) - Lucky8 🍀 (/ecosystem/lucky8) - Radix Kingdoms (/ecosystem/radix-kingdoms) Healthcare - AcuiQ (/ecosystem/acuiq) Infrastructure - Hyperlane (/ecosystem/hyperlane) - IdeoMaker (/ecosystem/ideomaker) - Notix (/ecosystem/notix) - Radix Accountability Council (/ecosystem/radix-accountability-council) - Radix Foundation (/ecosystem/radix-foundation) - Radix Labs (/ecosystem/radix-labs) - RadixScan (/ecosystem/radixscan) - Radlock (/ecosystem/radlock) Launchpad - rlyfun (/ecosystem/rly-fun) Media - Quack Space (/ecosystem/quackspace) - RadixTalk (/ecosystem/radixtalk) - Run Fly (/ecosystem/runfly) NFT Platform - Bullring (/ecosystem/bullring) - Ice (/ecosystem/ice) Stablecoin - Stabilis (/ecosystem/stabilis) Staking - Allnodes (/ecosystem/allnodes) - Avaunt Staking (/ecosystem/avaunt-staking) - Blockshard (/ecosystem/blockshard) - Cobra stakes (/ecosystem/cobra-stakes) - CrumbsNode (/ecosystem/crumbsnode) - GenkiPool (/ecosystem/genkipool) - Leafnode (/ecosystem/leafnode) - MattiaNode (/ecosystem/mattianode) - Radical Staking (/ecosystem/radical-staking) - RadixStake (/ecosystem/radixstake) - Radstakes (/ecosystem/radstakes) - RadUp (/ecosystem/radup) - Slightlyiffy (/ecosystem/slightlyiffy) - Staatenlos Node (/ecosystem/staatenlos-node) - StakeSafe (/ecosystem/stakesafe) - StakingCoins (/ecosystem/stakingcoins) - Supreme Stake (/ecosystem/supreme-stake) - XSEED (/ecosystem/xseed) Token - $EARLY (/ecosystem/early) - Addix (/ecosystem/addix) - DELIVER (/ecosystem/deliver) - Radix $BlueBalls (/ecosystem/radix-blue-balls) - Reddicks (/ecosystem/reddicks) Testnet, pre-launch and in development (8) DAO Platform - AI Ventures (/ecosystem/ai-ventures) - Caper (/ecosystem/caper) - Muan Protocol (/ecosystem/muan-protocol) (In development) Finance - P2P Fixed-Rate Lending (Stokenet) (/ecosystem/p2p-lending) - Tāhuna (/ecosystem/tahuna) (In development) Infrastructure - Proven Network (/ecosystem/proven-network) (In development) - Radix Namespace (/ecosystem/radix-namespace) Oracle - OTER (/ecosystem/oter) (Pre-launch) Dormant (48) DAO Platform - Clarity Protocol (/ecosystem/clarity-protocol) - CrumbsUp (/ecosystem/crumbsup) Education - The Hard Money Project (/ecosystem/the-hard-money-project) - WhyNot (/ecosystem/whynot) Finance - 3Syde (/ecosystem/3syde) - AlphaDEX (/ecosystem/alphadex) - DogeCubeX (/ecosystem/dogecubex) - Fibonacci Finance (/ecosystem/fibonacci-finance) - Fidenaro (/ecosystem/fidenaro) - Foton (/ecosystem/foton) - Gable Finance (/ecosystem/gable-finance) - Maya Protocol (/ecosystem/maya-protocol) - Ploughshare (/ecosystem/ploughshare) - RadixPlanet (/ecosystem/radixplanet) - Root Finance (/ecosystem/root-finance) - Stream Wallet (/ecosystem/stream-wallet) - Trove (/ecosystem/trove) - Z3US (/ecosystem/z3us) Gaming - DELPHIBETS (/ecosystem/delphibets) - Mox Studio (/ecosystem/mox-studio) - PokerXRD (/ecosystem/pokerxrd) - Token Trek (/ecosystem/token-trek) - World Cup Badge Arena (/ecosystem/world-cup-badge-arena) Infrastructure - Emberflow (/ecosystem/emberflow) - Hermes Protocol (/ecosystem/hermes-protocol) - Infinite Labs (/ecosystem/infinite-labs) - Miow (/ecosystem/miow) — platform offline; miow.me returned DEPLOYMENT_NOT_FOUND at every path on 2026-09-04 Launchpad - bondefi (/ecosystem/bondefi) Media - Radix List (/ecosystem/radix-list) - RADIX REVIEW (/ecosystem/radix-review) - Radix Rolodex (/ecosystem/radix-rolodex) - RadixUID (/ecosystem/radixuid) - The Meme Studio (/ecosystem/the-meme-studio) NFT Platform - Blue Chick NFTs (/ecosystem/blue-chick-nfts) - Nerds Republic (/ecosystem/nerds-republic) - Project Elysium (/ecosystem/project-elysium) - UNISCI (/ecosystem/unisci) - XRDegen (/ecosystem/xrdegen) Staking - Juicy Stake (/ecosystem/juicy-stake) - Radnode (/ecosystem/radnode) - Topradixnode (/ecosystem/topradixnode) Studio - RDX Works (/ecosystem/rdx-works) - SoulStore (/ecosystem/soulstore) Token - $DAN (/ecosystem/dan) - EasyMoon (/ecosystem/easymoon) - Hug (/ecosystem/hug) - Phoenix (/ecosystem/phoenix) - SingularityX (/ecosystem/singularityx) Closed and departed (35) DAO Platform - Impahla (/ecosystem/impahla) DeSci - Ideosphere (/ecosystem/ideosphere) (Departed (pivoted off Radix)) Education - Academia Scrypto (/ecosystem/academia-scrypto) - RadQuest (/ecosystem/radquest) Finance - Anthic (/ecosystem/anthic) - Backeum (/ecosystem/backeum) - Beaker (/ecosystem/beaker) - DeXian Protocol (/ecosystem/dexian-protocol) - DeXter (/ecosystem/dexter) - Nest Finance (/ecosystem/nest-finance) - RadKET (/ecosystem/radket) - Xidar (/ecosystem/xidar) Gaming - Abandoned Arena (/ecosystem/abandoned-arena) - Arcane Labyrinth (/ecosystem/arcane-labyrinth) - NFTwars (/ecosystem/nftwars) - Parabox (/ecosystem/parabox) Infrastructure - Instabridge (/ecosystem/instabridge) - RadixCharts (/ecosystem/radixcharts) - XRD Domains (/ecosystem/xrd-domains) Launchpad - launchspace (/ecosystem/launchspace) Media - Project $Now (/ecosystem/project-now) - Radit (/ecosystem/radit) - RadixRadio (/ecosystem/radixradio) - Reizor (/ecosystem/reizor) - UniX (/ecosystem/unix) NFT Platform - Radland (/ecosystem/radland) - VikingLand (/ecosystem/vikingland) - WeAreMonstas (/ecosystem/wearemonstas) Oracle - Religant (/ecosystem/religant) Stablecoin - EtherealDAO (/ecosystem/etherealdao) Staking - Radixnode.io (/ecosystem/radixnodeio) - StakeBros (/ecosystem/stakebros) Token - DELAY (/ecosystem/delay) - Farbocoin (/ecosystem/farbocoin) - RADIATOR (/ecosystem/radiator) Related pages - Ecosystem (/ecosystem) — the project directory this indexes, with full pages for each entry - Radix Mainnet (Xi’an) (/contents/tech/releases/radix-mainnet-xian) — the upgrade that makes dApp migration a live question - hyperscale-rs (/contents/tech/research/hyperscale-rs) — the Rust implementation being built toward it - Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) — why a closed project's old channel is a hazard rather than a dead link - Radix Ecosystem Funding (/contents/history/radix-ecosystem-funding) — the grant and incubation programs many of these projects came through ## Hyperlane Asset Drain and Network Halt: Day-by-Day Record URL: https://radix.wiki/contents/history/hyperlane-asset-drain-2026-timeline Updated: 2026-09-11 Summary: This is the day-by-day record of the ten days Radix mainnet spent halted after the Hyperlane asset drain of 31 August 2026, from the first official up… This is the day-by-day record of the ten days Radix mainnet spent halted after the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) of 31 August 2026, from the first official update on 1 September to the restart at 11:35 UTC on 11 September. The article it belongs to carries the incident, the cause and a summary of the repair; this is the working record underneath it. Every entry states what was read, from where, and at what hour, and the readings are left as they were taken rather than edited to agree with what came later. One correction is worth knowing before reading them. The halt boundary cited throughout below, state version 557,840,622 at epoch 339,896 round 102, is the Gateway status endpoint's reading; after the restart the transaction stream showed the ledger had run five state versions further, to epoch 339,897 round 4 at 21:19:48.939 UTC. The entries still carry the Gateway's number, because what each day could be checked against at the time is the point of keeping them. Day two: the first official update Re-read at 11:04 UTC on 1 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for the third consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is thirteen hours and forty-five minutes without a committed round. The first official word since 22:02 UTC the previous night came at 09:10 UTC, in an update posted to the Radix Accountability Council's channel (https://t.me/RadixAccountabilityCouncil/931) . It says a team assembled by the Foundation, the council and community members is working on a fix, that there is “absolute convergence and solid certainty on what caused the bug to be there and where it came from”, and that there are “no expectations or timelines at this stage”. It also settles what the stopped network now is: the halt is a control being held on purpose, not a failure still in progress. “The current halting status of the network is our best defense and will stay on as long as we need it.” The council closed by asking the community to keep working on the Governance Framework ratification (/contents/tech/core-concepts/radix-governance) , which it said had not lost its importance. The clearest sign that a fix is being staged came from the developer channel rather than from an announcement. Radix's public test network, Stokenet (https://docs.radixdlt.com/docs/network-gateway) , is running: read live at 11:07 UTC its Gateway returns epoch 1,111, round 2,487, proposer round timestamp 11:07:22.546 UTC, so it is producing rounds while mainnet is not. Its developer console is not; stokenet-console.radixdlt.com answered 530 to a request at the same minute, which is what a developer reported at 09:54 (https://t.me/RadixDevelopers/66215) . Daffy, who runs the network's community infrastructure, answered at 10:32 (https://t.me/RadixDevelopers/66220) that Stokenet itself “is up” and would be “taken down for planned maintenance for reasons you probably understand”, adding that he would say when. A test network taken offline deliberately in the middle of a mainnet halt is where a patched Engine gets tried before any validator is asked to run it. The forensic work continued in parallel and is separate from the fix. 0xOmarA (https://github.com/0xOmarA) wrote at 05:43 UTC (https://t.me/radix_dlt/1000902) that he already had the data he needed from the Core API and the Gateway, and that he was looking for a trace the attacker left in an earlier attempt, on Stokenet or in a failed run on mainnet, rather than for anything further in the successful transactions. The silence in the official channels was explained the night before. At 21:17 UTC on 31 August (https://t.me/radix_dlt/1000765) , two minutes before the last round, the Foundation said it was in contact with bridges, exchanges and security partners, that it was “reaching out to relevant authorities and taking advice on next steps”, and that it “may be limited in the updates we can provide”. Measured against the repositories, that is what has happened: re-read at 11:07 UTC, babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release is still v1.3.0.5 of 1 June 2026, the default branch of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) still last moved on 27 March 2026, the Foundation's blog (https://www.radixdlt.com/blog) carries no post about the incident, and the DAO's notice feed (https://radixdao.org/notices.json) still ends on 29 August. Fourteen hours in, everything anyone outside the repair knows about it was said in a Telegram channel. Day two, afternoon: the shape of the fix Re-read at 15:04 UTC on 1 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for the fourth consecutive reading, and the read endpoints put a number on it without any epoch arithmetic: a request to /state/entity/details answers HTTP 500 with current_sync_delay_seconds 63,936 and the sentence “it is currently 17 hours, 45 minutes, 36 seconds behind”. At 12:16 UTC the Radix Accountability Council (https://t.me/RadixAccountabilityCouncil/936) published the first description of what the repair actually consists of, posted by projectShift as the morning update was. It names four steps in order: code fixes to the Radix Engine; updates to the node software together with a protocol upgrade; a coordinated deployment of those across nodes; and a coordinated return to liveness. It says the work involves people who were previously with the Foundation or are still with it, alongside volunteer developers and engineers from the ecosystem, and that it is “not just coding a fix” but review, testing, deployment and recovery. There is still “no timetable for when a solution will be available”; the council said to expect the next regular update around the same time the following day. That list matters to a reader outside the repair because its middle two steps are not private. A protocol upgrade on Radix is adopted by validators signalling readiness for a named version in an ordinary transaction, which is how the three updates the rebuilt Stokenet (https://docs.radixdlt.com/docs/network-gateway) ledger had to retake in August are readable on it today. Read at 15:05 UTC, the Stokenet transaction stream against its validator set carries no readiness signalling later than the Cuttlefish signal of 29 August: no new protocol version has been proposed on the test network. Stokenet itself is still producing rounds — epoch 1,175, round 124, state version 3,512,563, proposer round timestamp 15:05:29.054 UTC, continuous from the 3,322,913 read four hours earlier — so the planned maintenance Daffy announced at 10:32 had not begun, and a developer was still deploying a component to it at 14:47 (https://t.me/RadixDevelopers/66235) . Eighteen hours after the halt, the fix has not reached a network. Nothing else has moved either. babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release is v1.3.0.5 of 1 June 2026, the default branch of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) last moved on 27 March 2026, the Foundation's blog (https://www.radixdlt.com/blog) carries no post about the incident, and the DAO's notice feed (https://radixdao.org/notices.json) still ends on 29 August. The markets, meanwhile, spent the day repricing what they could not move: Gate.io's XRD/USDT book (https://api.gateio.ws/api/v4/spot/tickers?currency_pair=XRD_USDT) read 0.000658 USDT at 15:06 UTC, down 20.2% over twenty-four hours on 114,272,110 XRD of volume, and MEXC's (https://api.mexc.com/api/v3/ticker/24hr?symbol=XRDUSDT) read 0.0006521, down 20.8% on 248,959,959 XRD — roughly 162,000 US dollars of turnover in a token that cannot currently leave an exchange. Day two, evening: a halt with no lever to throw back Re-read at 19:04:16 UTC on 1 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for the fifth consecutive reading — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — twenty-one hours and forty-five minutes without a committed round. Four minutes later /state/validators/list and /state/entity/details both answered HTTP 500 with NotSyncedUpError and stated the gap themselves: current_sync_delay_seconds 78,372 against max_allowed_sync_delay_seconds 720, in the words “it is currently 21 hours, 46 minutes, 12 seconds behind”. Nothing has appeared in any of the places a fix would surface. babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release is still v1.3.0.5 of 1 June 2026 and its main branch's last commit is from the same day; develop has not moved since 12 March 2025 and release/cuttlefish since 7 May 2025. The default branch of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) still ends at 858c70f1 on 27 March 2026. The DAO's notice feed (https://radixdao.org/notices.json) carries nothing after 29 August, the Foundation's blog (https://www.radixdlt.com/blog) nothing at all about the incident, and the Council has posted nothing since the four-step account recorded in the section above. Twenty-two hours in, the repair described that morning has left no public trace in any repository. The halt is a standing decision, not a switch What the main channel worked out this evening is that there is no lever to throw back. In two messages at 18:49 and 18:53 UTC, projectShift (https://t.me/radix_dlt/1001231) — the account that has posted the Council's updates (https://t.me/RadixAccountabilityCouncil/936) through the outage — set out what the stop actually is: “The network's not halted, it's just refusing to produce TX because it lost quorum on stake power, as it is coded to do.” It happened because enough independent node runners, holding enough cumulative stake between them, each accepted the plan; and, he added, “Some didn't and their nodes are up, for whatever reasons.” Had the stake behind the stop fallen short, the network would have kept working, “maybe just a tad slower”. The consequence is that ending it requires no coordinated act either. “Any node-runner is free to reverse their decision and boot the node back up and start regular operations. If enough of them do that, the network regains quorum and liveness and restarts normal operations.” (https://t.me/radix_dlt/1001233) There is no switch in the protocol to unset and no signed release to wait on; the halt is a position that a set of operators re-takes every minute it lasts, and it lifts the moment enough of them individually stop taking it. That is a different object from the one the outside reading assumes. The validators (/contents/tech/core-concepts/validator-nodes) are not obeying an instruction, and no party can rescind one. It also means the network's other constituency has no move. Delegated stake is the counterweight to node runners in Radix's design — unhappy delegators redirect it — and here it cannot be used, because redirecting a delegation is itself a transaction and transactions are exactly what has stopped. projectShift stated the asymmetry plainly, that delegators “cannot change their stake into other nodes, even if they don't agree with node runners”, adding that “that asymmetry is by design and was always there. And it would take them 7 days to enact anyway”: the unstaking (/contents/tech/core-concepts/staking) delay would run only after a ledger existed to record the request on. So a decision reversible by any one of a hundred operators is, for everyone who delegated to them, not reachable at all. It is the sharpest illustration the network has produced of what the stake-delegation model does and does not give a holder, and it arrived on the day it mattered. Day three: the instruments that did not notice Re-read at 03:04:16 UTC on 2 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for the seventh consecutive reading — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — twenty-nine hours and forty-five minutes without a committed round. The read endpoints state the gap themselves: /state/entity/details, /state/validators/list, /stream/transactions and /transaction/construction all answer HTTP 500 with current_sync_delay_seconds 107,377 against a max_allowed_sync_delay_seconds of 720, in the words “it is currently 1 day, 5 hours, 49 minutes, 37 seconds behind”. One layer above that, the ecosystem's own read surfaces are answering normally, and what they are answering with is the halt. Ociswap's token API (https://api.ociswap.com/tokens) returns HTTP 200, and XRD's circulating market capitalisation reads 7,945,385.587233559518230284332481276342396505 US dollars at the 1-hour window, at the 24-hour window and at now — the same figure to the last of its thirty-six decimal places. Only the 7-day window differs, at 11,811,840.45. A twenty-four-hour period with nothing in it looks, to an aggregator, exactly like a very quiet market. Astrolescent's price feed (https://api.astrolescent.com/prices) returns 876 tokens, ninety-nine of them reporting a twenty-four-hour volume of exactly zero, and it still quotes the assets the drain removed. hUSDC reads 0.7467 US dollars and hUSDT 0.4470 — dollar stablecoins priced a quarter and a half below par — alongside hETH at 1,295.09, hWBTC at 58,302.64 and hSOL at 57.74. Those are the last prices the pools produced before the network stopped, held for a day and a quarter and served as current, for tokens whose remaining supply on Radix is the residue the article (/contents/history/hyperlane-asset-drain-2026) records: 1,092.79 hUSDC and 0.036292 hUSDT. Nothing in this layer is wrong, exactly. It is the halt, cached. The frontends divide on the same line. Static shells serve: ociswap.com, astrolescent.com, app.weft.finance, surge.trade, defiplaza.net, dex.reddicks.meme, radquest.io, radixscan.io and radixplanet.com all returned 200 through their own redirects. Pages that need a live read do not: an astrolescent.com/token/ page answers HTTP 500 and stats.defiplaza.net times out after twenty seconds. app.caviarnine.com refuses connections, which belongs to CaviarNine (/ecosystem/caviarnine) 's own wind-down rather than to the halt. Nothing official has been added since the previous reading. The Council's four-step account of the fix (https://t.me/RadixAccountabilityCouncil/936) at 12:16 UTC on 1 September is still its last word, fifteen hours later; babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release remains v1.3.0.5 of 1 June 2026 and its default branch's newest commit 12919a01 of 12 March 2025; the default branch of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) still ends at 858c70f1 on 27 March 2026; the DAO's notice feed (https://radixdao.org/notices.json) still ends on 29 August; and the Foundation's blog (https://www.radixdlt.com/blog) carries no post about the incident. A patch for a live vulnerability is the last thing anyone would push to a public branch before it ships, so the absence is not evidence of inaction — but none of the places a reader can check has moved. Day three, morning: the Foundation speaks, and claims the halt Re-read at 11:06:14 UTC on 2 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for the eighth consecutive reading — state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC — thirty-seven hours and forty-seven minutes without a committed round. The read endpoints put the same gap in their own words: /state/entity/details answers HTTP 500 with current_sync_delay_seconds 136,028 against a max_allowed_sync_delay_seconds of 720, “it is currently 1 day, 13 hours, 47 minutes, 8 seconds behind”. Eight minutes past nine, thirty-five hours into the stop, the Foundation said something for the first time since two minutes before the last round. The statement went out on the Radix DLT Official Announcements channel at 08:58:02 UTC (https://t.me/RadixAnnouncements/2778) and was forwarded straight into the main chat. It is six sentences. The root issue “has been identified, and work is underway to implement, test and deploy the fixes as quickly and safely as possible”. The Foundation “has contacted security partners, bridges, exchanges and relevant authorities to assist”. Foundation assets held in custody “remain safe”. There is “currently no confirmed timeline for restoration”. And for anything further, readers are pointed away from the Foundation's own channels: “For verified updates, follow @RadixAccountabilityCouncil”. Who halted the network The first sentence is the one worth reading twice. “Following the recent exploit, the Radix Foundation and RAC have halted the Radix network as a precautionary measure, temporarily making transactions and Radix Wallet activity unavailable.” That is an account of the halt as a thing two named bodies did, and it is not the account the network's own operators gave. As the previous evening's section (#standing-decision) records, the stop is not an action taken on the network but a quorum the network lost when enough independent node runners each shut down their own machine, and some declined and left theirs running. Neither the Foundation nor the council has a switch of this kind; what they had was a plan that enough operators, one at a time, agreed to. The contradiction was already on the record in the same channel three hours earlier. At 06:04 UTC (https://t.me/radix_dlt/1001292) , answering people asking him privately whether Radix was finished, Timan of Astrolescent (/ecosystem/astrolescent) and DefiPlaza (/ecosystem/defiplaza) wrote that the exploit was serious and the halt severe, “but the node runners made that decision to protect the network. That was not a centralized decision. (Also didnt come from me btw).” Three hours later the Foundation's own announcement claimed it. Both cannot be describing the same event, and only one of them is checkable against the ledger, which shows a network that stopped producing rounds when its validating stake fell below the threshold the consensus protocol (/contents/tech/core-protocols/cerberus-consensus-protocol) requires. The distinction is not a quibble about credit. It decides who a holder should be watching for the restart. A network halted by two bodies resumes when those bodies decide it should; a network that lost quorum resumes when enough validator (/contents/tech/core-concepts/validator-nodes) operators individually judge the patched software safe to run. The second is what the ledger describes, and it is why no announcement can carry a restart date. No timeline, and the gap that fills it “No confirmed timeline for restoration” is the Foundation's first public word on when the network comes back, and the vacuum around it is being filled by people with no more information. Just over an hour before the announcement, at 07:46 UTC (https://t.me/radix_dlt/1001306) , avaunt of Atomix (/ecosystem/atomix) answered a holder asking what to do with “it will take a few more days at least to restart the network”; Timan's message two hours earlier had said the same, “hopefully a few days”, with the qualifier that it is “better to get it right the first time than rush this”. Neither is an estimate anyone is in a position to make, and the announcement declined to make one. The channel the Foundation designated as the source of verified updates has not used it. The council's four-step account of the fix (https://t.me/RadixAccountabilityCouncil/936) at 12:16 UTC on 1 September, which closed by promising the next update “around the same time tomorrow”, is still its most recent word twenty-two hours and fifty minutes later. Nor has anything appeared where a fix would land: babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release is still v1.3.0.5 of 1 June 2026, the default branch of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) still ends at 858c70f1 of 27 March 2026, the DAO's notice feed (https://radixdao.org/notices.json) still ends on 29 August, and the Foundation's blog (https://www.radixdlt.com/blog) carries no post about the incident. Thirty-eight hours in, the whole public record of the repair is four Telegram messages. Day three, afternoon: the council returns, and the DAO's own clock stops with the network Read at 15:10:08 UTC on 2 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a ninth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is forty-one hours and fifty-one minutes without a committed round. /state/validators/list still answers HTTP 500 and still counts the gap itself, now current_sync_delay_seconds 150,662 against a max_allowed_sync_delay_seconds of 720. Nothing has been published where a fix would appear: babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release is still v1.3.0.5 of 1 June 2026. The council spoke again at 13:49:11 UTC. Its status update (https://t.me/RadixAccountabilityCouncil/958) , posted by projectShift, is the first since the four-step account of the fix (https://t.me/RadixAccountabilityCouncil/936) at 12:16 UTC the previous day, which had promised the next one around the same time the next day. It arrived twenty-five hours and thirty-three minutes later, an hour and a half past that. On the repair it adds confidence and no dates. Progress is called excellent, the team handling it solid, and testing extensive and continuing, on the reasoning that there is only one chance to get the restart right; there are still no hard dates to commit to. The people doing the work stay unnamed, deliberately, with disclosure deferred to the aftermath. That leaves the public record of the repair where the morning's section (#day-three-foundation) found it: statements about work, and no artefact anyone outside can check. The legal and exchange track Two operational lines are new. The Foundation has taken legal steps over the hack, and the council says an update on them will come direct from Andy, whom it does not further identify; the Radix Foundation's chief executive is Andy Jarrett. Separately, coordination with exchanges, market makers and other partners is running through the Foundation rather than the council, and covers both the current state of the network and when and how it returns to liveness. The council adds one limit that matters to holders: whether trading continues inside any given exchange is that exchange's decision alone, which is consistent with the pattern recorded on day two (#off-the-chain) , where XRD markets stayed open while deposits and withdrawals did not. The halt stops the DAO's constitutional clock The update's third section is the one with a consequence beyond the incident. The Radix DAO opened the Discussion phase on its Governance Framework (/ideas/radix-network-dao-charter) at 17:30 UTC on 30 August, for a stated seven days, which would have closed it on 6 September. Because a halted ledger offers no way to run a Temperature Check or a ballot, the Transition RAC has removed the limit and will keep the phase open for as long as it is needed. The council's argument for doing so is that reading and challenging the twenty-one documents is the one useful thing still available while nothing can be transacted. The effect is that the network's stoppage has propagated into the DAO's own timetable. Ratification is Activation Condition 6 of the Operating Agreement, and the Permanent RAC election (/ideas/dao-elect-permanent-rac) cannot open until the framework is ratified, so an outage on the ledger now sits upstream of the transition it was meant to be independent of. Measured at 15:10 UTC, three days into the phase, the anchor discussion topic (https://radixtalk.com/t/charter-policies-ratification-discussion/2330) holds 13 posts from four accounts and 151 views, eight of the thirteen written by the council member who opened it. Day three, evening: the first technical account, and a legal track Read at 19:04:11 UTC on 2 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a tenth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is forty-five hours and forty-five minutes without a committed round. /state/validators/list answers HTTP 500 and states the gap in words as well as seconds, it is currently 1 day, 21 hours, 45 minutes, 10 seconds behind, with current_sync_delay_seconds 164,710 against a max_allowed_sync_delay_seconds of 720. The first public account of the flaw Until this afternoon no one connected to the network had described the defect in public. The official statements named the layer and stopped there: an outstanding issue in the execution layer, an issue in the Radix Engine, and, in the Foundation's statement that morning (https://t.me/RadixAnnouncements/2778) , a root cause identified but not characterised. That changed in the space of ten minutes in the main Radix group, after a holder asked at 14:44 UTC for an explanation in plain terms, and specifically why so simple a check had not been implemented and why an audit had not found it. Timan of Astrolescent answered first (https://t.me/radix_dlt/1001388) and declined the question: that is the million dollar question, he cannot produce a plain-language account of how it was possible, and he expects the upcoming incident report to. That is the first indication from anyone close to the work that a written incident report is planned at all. Council (https://t.me/RadixAccountabilityCouncil) member projectShift then gave one (https://t.me/radix_dlt/1001389) , at 14:50:47 UTC. The attack, in his account, moves assets by bypassing security/ownership checks when calling a specific method and identifying the vault holding the assets by its internal id, and what fails is the checking of the requester had any authorization or ownership of the vault identified. His analogy is that everyone saw the door and the lock and accepted that it was locked and that only the owner held the key; nobody tried the handle, and it was not locked. Ten minutes later flightofthefox, who leads the hyperscale-rs (/contents/tech/research/hyperscale-rs) rewrite, placed it in the Engine's history (https://t.me/radix_dlt/1001391) , hedging it twice: take it with a pinch of salt because he has not looked exhaustively, and someone will have a more accurate write-up when the fires are out. His reading is that direct access to a vault was built to support the recallable resource behaviour, which is a capability asset issuers genuinely want, but it seems like the checks that the caller actually had the right recall authority (and indeed that the resource was even ever marked recallable) weren't in place or not functioning correctly. Both accounts land where the code reading in the article (/contents/history/hyperlane-asset-drain-2026#the-cause) landed two days earlier, and the second adds a detail worth keeping. verify_boot_ref_value tests the blueprint of the referenced node, FungibleVault or NonFungibleVault from the resource package, and nothing else; whether the resource behind that vault was ever configured as recallable is not one of its inputs, any more than ownership is. A capability introduced for recall was therefore reachable on resources for which recall had never been enabled. None of this is an incident report, and all three accounts are hedged or partial. What can be said as of this reading is that the first public technical explanations of the drain came from a protocol developer and a council member speaking in a chat group, four days after the transactions, and not from the organisation that says it has identified the root cause. Reports to authorities in Jersey and the UK The legal update the council had promised (#the-legal-and-exchange-track) arrived at 16:13:34 UTC, in the main group rather than an announcement channel, from Andy Jarrett: the Foundation (https://t.me/radix_dlt/1001399) have submitted incident and forensic reports to various legal and cybercrime authorities in Jersey and the UK and had a number of follow up calls today. The two jurisdictions match where the group is registered. The Radix Foundation (/ecosystem/radix-foundation) that now holds control of the group is a Jersey entity, and the operating companies are registered in England and Wales. No authority, reference or case is named, and nothing further has been published in writing. Day four: two prices for a coin that cannot move Read at 07:03:51 UTC on 3 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a thirteenth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is fifty-seven hours and forty-five minutes without a committed round. Three minutes later /state/validators/list and /state/entity/details both answer HTTP 500 and count the gap themselves, it is currently 2 days, 9 hours, 47 minutes, 45 seconds behind, with current_sync_delay_seconds 208,065 against a max_allowed_sync_delay_seconds of 720. Nothing has appeared where a fix would appear. The newest babylon-node release (https://github.com/radixdlt/babylon-node/releases) is still v1.3.0.5 of 1 June 2026, the head of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) is still commit 858c70f1 of 27 March 2026, and the DAO's notice feed (https://radixdao.org/notices.json) still ends on 29 August. The two books come apart The exchange freeze recorded on day two (#off-the-chain) is unchanged at a third reading. Gate.io's native XRD chain carries deposit_disabled: true and withdraw_disabled: true; KuCoin reports isDepositEnabled and isWithdrawEnabled both false; CoinEx holds both external legs off and leaves inter_transfer_enabled true. What has moved is the price, and it has moved differently at each venue. Venue Last 24h change 24h range 24h volume Gate.io (https://api.gateio.ws/api/v4/spot/tickers?currency_pair=XRD_USDT) 0.0006582 +0.01% 0.000658 to 0.000693 7,536,673 XRD (4,991 USDT) MEXC (https://api.mexc.com/api/v3/ticker/24hr?symbol=XRDUSDT) 0.0005144 -12.51% 0.0003738 to 0.0005889 116,901,175 XRD (64,020 USDT) MEXC's last print sits 21.8% below Gate's. Two days earlier the same two books (#shape-of-the-fix) were within one per cent of each other, both quoting around 0.000658 after a twenty per cent fall. The gap that has opened since is not a disagreement about Radix. It is the absence of the mechanism that normally closes such a gap: arbitrage between two exchanges is a coin bought at the cheap venue and moved to the dear one, and the move is a Radix transaction, which is the one thing the ledger is refusing. Each book now prices its own trapped float against its own sellers, and the two answers no longer have to agree. Gate's book has almost stopped. Its twenty-four-hour turnover fell from 114,272,110 XRD on 1 September to 7,536,673, a 93% drop, and its whole day's range is five per cent wide with the last print sitting on the low. MEXC took the selling instead, 116,901,175 XRD against 248,959,959 two days earlier, and printed a low of 0.0003738 that is 43% under Gate's last. The deeper book is the one still discovering a price; the shallower one is quoting a number at which almost nothing changed hands. Day five: the fix is on GitHub, under a name the network has not heard Read at 07:03:39 UTC on 4 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a seventeenth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is eighty-one hours and forty-four minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 3 days, 9 hours, 48 minutes, 38 seconds behind, with current_sync_delay_seconds 294,518 against a max_allowed_sync_delay_seconds of 720. The repair has become readable, and it was readable before this reading. At 12:26:45 UTC on 2 September – thirty-nine hours into the halt, and seven hours before the first public account of the flaw (#day-three-evening-first-technical-account) was given in a chat group – pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) was opened against radixdlt-scrypto’s develop branch, titled 0xOmarA/vault access. Its author is 0xOmarA (https://github.com/0xOmarA) , the same contributor whose forensic notes this page records from the first night. It is still open, unreviewed and unmerged. The six commits on it date the work. The earliest is 31 August at 22:41:32 UTC, one hour and twenty-two minutes after the last round the network committed; Add Eagle Ray protocol update lands at 23:27:33, and Add a receiver check to kernel_invoke at 00:12:54 on 1 September – under three hours after the halt, and roughly six hours before the first official update (#day-two) said anything in public. Two further commits on 2 September move the check from the kernel into the system layer. Eagle Ray (/contents/tech/releases/protocol-updates) is a new named protocol update, the next after Dugong in the alphabetical sequence, and it is the second of the four steps the council named (#shape-of-the-fix) as well as the first: the code fix and the protocol upgrade that carries it are the same pull request. Its whole content is a flash update that advances the system logic from SystemVersion::V4 to V5, and V5 turns on a single check. Before an invocation runs, the system asks whether the calling frame can actually see the node whose method it is calling – direct methods, the type used for recall and other direct vault access, requiring direct visibility of the receiver – and rejects the call otherwise with a new error, SystemError::InvalidInvokeAccess. That is the handle nobody tried, given a lock: the test the change rewrites is test_recall_on_internal_vault, which used to fail obscurely inside the kernel’s frame construction and now fails cleanly at the system layer. Two things follow, and they pull in opposite directions. The fix matches the flaw as both public accounts of it (#the-first-public-account-of-the-flaw) described it – a method reached on a vault the caller had no authority over – and it was written within hours, not days. But four days later it has no review, no merge, and no node: babylon-node (https://github.com/radixdlt/babylon-node/releases) ’s newest release is still v1.3.0.5 of 1 June 2026, the node repository carries no Eagle Ray branch, and a protocol update reaches mainnet only when validators signal readiness for a node version that contains it. Steps three and four of the council’s list have not started. The Foundation’s blog (https://www.radixdlt.com/blog) still carries nothing about the incident and the DAO’s notice feed (https://radixdao.org/notices.json) still ends on 29 August, so the most concrete public statement about how the network gets restarted remains an unannounced pull request that anyone could have read for two days. Day six: the ledger has not moved, the fix has not moved, the paperwork has Read at 15:03:41 UTC on 5 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a twenty-fifth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and thirteen hours and forty-four minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 4 days, 17 hours, 47 minutes, 47 seconds behind, with current_sync_delay_seconds 409,667 against a max_allowed_sync_delay_seconds of 720. The fix has not been touched since day three Pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , which carries Eagle Ray (/contents/tech/releases/protocol-updates) and the receiver check day five (#day-five-the-fix-is-on-github) read line by line, was last updated at 13:06:16 UTC on 2 September. That is seventy-four hours before this reading, and the state at both ends is identical: open, six commits, no review comments, unmerged against develop. The node half is where day five left it too – babylon-node (https://github.com/radixdlt/babylon-node/releases) ’s newest release is still v1.3.0.5 of 1 June 2026, and none of the repository’s 183 branches is named for Eagle Ray. A protocol update reaches mainnet only when validators signal readiness for a node version that contains it, and no such version exists in public. The post-mortem waits on the restart, and the audits are under investigation The main Radix group spent the middle of the day arguing about who should have caught the flaw. Daffy, the community contributor who maintains the DAO’s governance repository (https://github.com/RadixDAO/governance-framework) , answered three questions in it and each answer is new to the public record. At 11:34:59 UTC he asked the group to stop discussing the matter in public (https://t.me/radix_dlt/1002009) until the network is patched and running. At 12:04:27 UTC, asked whether anyone could yet explain where the bug was and how it passed the security reviews, he said the bug and its history are known (https://t.me/radix_dlt/1002026) and that why the Audits did not capture it is still under investigation. At 12:07:57 UTC, asked how the report could be read, he put it after the restart (https://t.me/radix_dlt/1002029) : After the network is patched and running smoothly again. This is the first public statement that a written post-mortem exists as a commitment rather than an expectation, and the first that the audit history is itself being examined. Neither carries a date, and both are attributed to a contributor rather than to the Foundation (/ecosystem/radix-foundation) , whose blog (https://www.radixdlt.com/blog) still carries nothing about the incident six days on. The DAO's clock restarts, off the chain The one thing that did move today moved where the ledger cannot reach it. At 13:17:43 UTC the Transition RAC member Tadkis told the council’s channel (https://t.me/RadixAccountabilityCouncil/988) that the agreement with MIDAO has been signed and the registration fee has been paid, and that the formal registration process is scheduled to begin on Monday – 7 September 2026. An hour later projectShift relayed it to the main group (https://t.me/radix_dlt/1002055) as Step one of the DAO is actually done now. Two things are worth holding together. The first is that this is the step the council (/ecosystem/radix-accountability-council) said on 29 August would roll out from Monday onwards, meaning 31 August; it completed six days later, and the four-to-six week registry clock the council quoted starts from 7 September rather than from the end of August. The second is the contrast with what the halt did to the DAO’s other clock (#the-ratification-clock) : ratification of the Governance Framework needs a vote the stopped ledger cannot hold, and remains open-ended. Incorporation runs through a registry in Majuro and does not care that Radix has stopped. The transition is now advancing on its off-chain leg alone. Day seven: the fix repository moves, and none of the movement is the fix Read at 11:06:56 UTC on 6 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a twenty-ninth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and thirty-three hours and forty-eight minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 5 days, 13 hours, 47 minutes, 50 seconds behind, with current_sync_delay_seconds 481,670 against a max_allowed_sync_delay_seconds of 720. The pull request's timestamp moved; its commits did not Pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , which carries Eagle Ray (/contents/tech/releases/protocol-updates) and the receiver check day five (#day-five-the-fix-is-on-github) read line by line, was last updated at 08:04:48 UTC on 6 September – the first time that stamp has moved since the 13:06:16 reading day six (#the-fix-has-not-been-touched-since-day-three) recorded, ninety-one hours earlier. It is not the fix that moved. The six commits on the branch still end at 722c3f32, Move error to system layer, authored at 11:09:51 UTC on 2 September, and all three comments on the pull request are from github-actions[bot]: the benchmark table of 2 September, and two Docker-tag notices posted this morning at 08:01:22 and 08:04:48 for the images radixdlt/private-scrypto-builder and radixdlt/private-scrypto-dev-container. A GitHub pull request counts a bot comment as an update, so the stamp is not evidence that a review has started. There is still no review comment, and it is still unmerged. Two more pull requests opened in the repository today, and both are housekeeping. #2094 (https://github.com/radixdlt/radixdlt-scrypto/pull/2094) , Remove unused Phylum CI job; document workflows in .github/README.md, was opened at 09:38:46 UTC against the fix branch 0xOmarA/vault-access itself and closed unmerged at 10:54:29; three minutes before that close, #2095 (https://github.com/radixdlt/radixdlt-scrypto/pull/2095) reopened the same five files against develop, where it remains open. Five files of continuous-integration configuration, retargeted from the patch to the mainline. That is the whole of the day's activity in the repository holding the fix, and it is worth noting what it lands on: develop, the branch #2093 is opened against, last took a commit on 27 March 2026. The node half has not moved either – babylon-node (https://github.com/radixdlt/babylon-node/releases) ’s newest release is still v1.3.0.5 of 1 June 2026, and no branch there is named for Eagle Ray. The upgrade gets a rehearsal ground The day’s one substantive statement came from the developer channel rather than the repository. At 07:27:12 UTC Daffy posted to the Radix Developers group (https://t.me/RadixDevelopers/66343) : Stokenet Update. We expect that there we will be some instability and downtime in Stokenet in the coming days in preparation for the protocol upgrade. It is the first public statement that the upgrade is being staged anywhere, and the first thing said about the restart since the halt began that describes an action rather than a state. Stokenet is Radix’s public test network, and it is running. Read at 11:07:28 UTC on 6 September, its Gateway returned state version 6,046,607, epoch 2,583, round 1,151 and a proposer round timestamp of that same second, and /state/validators/list answered HTTP 200 – the endpoint that has returned 500 on mainnet for six days. The instability being warned about is therefore ahead of the test network rather than behind it: what is coming is the upgrade being rehearsed on a live chain that can afford to break. This is the first of the four steps the council named (#shape-of-the-fix) to acquire a schedule of any kind, and the schedule it acquires is a rehearsal rather than a mainnet date. The notice says the coming days; no node release carrying Eagle Ray exists in public on either network; and mainnet restarts only when validators signal readiness for a version they cannot yet download. Day eight: the restart gets its first forecast, and it does not come from the Foundation Read at 07:04:0x UTC on 7 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a thirty-fourth consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and fifty-three hours and forty-five minutes without a committed round. /state/validators/list still answers HTTP 500 and still counts the gap itself, it is currently 6 days, 9 hours, 50 minutes, 7 seconds behind, with current_sync_delay_seconds 553,807 against a max_allowed_sync_delay_seconds of 720. A forecast, from a dApp founder At 06:32:47 UTC the first estimate of any kind about the restart was posted to the main Radix Telegram group (https://t.me/radix_dlt/1002313) , and it came from Timan Rebel, founder of Astrolescent (/ecosystem/astrolescent) : a great deal of patching work was done over the weekend, the network is getting closer to a restart, and more testing is needed before it happens. He was explicit that he was not among those doing the work and was posting because nobody else had. That is the eighth day of this incident and the first forward-looking statement about it, and the notable thing is where it did not come from. The Radix Foundation’s announcement channel (https://t.me/RadixAnnouncements/2778) has published nothing since the IMPORTANT NETWORK UPDATE of 08:58 UTC on 2 September, five days earlier, which is the post day three recorded (#day-three-foundation) . Message 2778 is still the newest on the channel. An ecosystem project’s founder, relaying second hand in a community chat, is currently the most recent public account of when Radix expects to produce a block again. The weekend left no public trace The work described has no visible counterpart in either repository. Pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , which carries Eagle Ray (/contents/tech/releases/protocol-updates) and the receiver check, is still open and unmerged, and its branch still holds the same six commits ending at 722c3f32 of 11:09:51 UTC on 2 September. Nothing was pushed to it on 5, 6 or 7 September. babylon-node (https://github.com/radixdlt/babylon-node) , the implementation every validator actually runs, is unchanged too: its release branch main still ends at 959b081e of 1 June 2026 and its newest release is still v1.3.0.5 of the same day. The two readings are not in conflict. A patch to a live network can be written, reviewed and tested privately and land in public as a single push, and the Foundation has said nothing that promises otherwise. What it does mean is that the public record cannot yet corroborate the forecast: the only artefacts a reader can check are five days old, and the estimate rests entirely on the account of someone who says he did not do the work. The rehearsal has not started Stokenet, the public test network day seven (#the-upgrade-gets-a-rehearsal-ground) identified as the rehearsal ground, is still running normally. Read at 07:04:08 UTC on 7 September, its Gateway returned state version 6,376,136, epoch 2,823 and round 227 with a proposer round timestamp of that same second, and /state/validators/list answered HTTP 200. The instability Daffy told the developer group to expect in the coming days in preparation for the protocol upgrade has now been awaited for twenty-four hours without appearing. Stokenet breaking would be the first thing a reader outside the Foundation could check that the restart forecast is real. Day eight, evening: the fix merges, and Scrypto releases it ninety seconds later Read at 19:03 UTC on 7 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a thirty-seventh consecutive reading: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is one hundred and sixty-five hours and forty-four minutes without a committed round. /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 6 days, 21 hours, 46 minutes, 25 seconds behind, with current_sync_delay_seconds 596,785 against a max_allowed_sync_delay_seconds of 720. The ledger is the only thing here that did not move. Pull request #2093 (https://github.com/radixdlt/radixdlt-scrypto/pull/2093) , which carries Eagle Ray (/contents/tech/releases/protocol-updates) and the receiver check day five (#day-five-the-fix-is-on-github) read line by line, took its first push since 2 September at 16:50 UTC: a seventh commit, fba18466, titled Fix scrypto-coverage ci. Forty-three minutes later, at 17:33:31 UTC, it was merged. develop, the branch that had stood at commit 858c70f1 of 27 March 2026 through every reading this page has taken, now ends at the merge commit a62393f7. At 17:34:30 UTC a tag was cut from that commit and at 17:35:11 UTC Scrypto v1.4.0 (Eagle Ray) (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v1.4.0) was published by 0xOmarA (https://github.com/0xOmarA) , the first Scrypto release since v1.3.1 in January 2026. Its release notes are the repository’s licence text and nothing else: no description of the flaw, the fix or the update. The documentation page for Eagle Ray (https://docs.radixdlt.com/docs/eagle-ray) still answers HTTP 404. The code is the announcement. What the merge contains is smaller than its size suggests. It touches 587 files and adds 58,244 lines, and 538 of those files are regenerated transaction-scenario receipts and manifests under generated-examples/eagle-ray/: the expected output of every existing scenario, re-recorded under the new protocol version, which is what a system-version change forces. The engine change is radix-engine/src/updates/eagle_ray.rs at 80 lines, plus 43 in the system callback that runs the check. Two of the four steps the council named (#shape-of-the-fix) are now done and the remaining two are the ones that need other people. There is still no node release: babylon-node (https://github.com/radixdlt/babylon-node/releases) , the implementation every validator actually runs, has released nothing since v1.3.0.5 of 1 June 2026, and a protocol update reaches mainnet only when validator operators install a node version containing it and signal they are ready. Until that version exists there is nothing for them to install. The Radix Foundation’s announcement channel (https://t.me/RadixAnnouncements/2778) has published nothing since 2 September; the merge is on GitHub, where anyone who thinks to look can read it. Day eight, night: the council reads the release and says it is not enough Read at 23:06:43 UTC on 7 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a thirty-eighth consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is one hundred and sixty-nine hours and forty-seven minutes without a committed round. /state/validators/list still answers HTTP 500, now with current_sync_delay_seconds 611,257. Three hours and ten minutes after Scrypto v1.4.0 was published, the Radix Accountability Council (/contents/tech/core-concepts/radix-governance) posted a status update to its own channel (https://t.me/RadixAccountabilityCouncil/1000) at 20:45:41 UTC, and it is the first statement from any body about how far the released code is from something a validator can run. The council writes that its developers have spotted that the Eagle has landed, meaning Eagle Ray, but don’t go jumping into conclusions yet, that’s not enough. It gives three reasons and no date: there are a lot of moving parts before we have a build completely ready for general deployment, and not all of them are ready at this point; the testing is still ongoing and has advanced significantly but is not finished; and the reviews under way have not all been completed. Asked for a date, the council says it has none it can commit to, and that hasting it is the poorest of choices. That is the same gap this page read from the repositories at 19:03, stated by the people doing the work rather than inferred from what has not been published. The babylon-node (https://github.com/radixdlt/babylon-node/releases) release list is unchanged at v1.3.0.5 of 1 June 2026. The update also moves the two tracks that are not the fix. On the legal one, the sign-up for MIDAO’s service is concluded and the transition council is working through the administrative steps that end with MIDAO submitting the formation request to the Marshall Islands registry, which is the filing the council said on 5 September would begin on Monday 7 September. On governance, the amendments raised in the Charter and Policies ratification discussion (https://radixtalk.com/t/2330) on RadixTalk have been incorporated where possible: Daffy reported at 21:19 UTC on 6 September (https://radixtalk.com/t/2330/19) that seven of thirteen points raised against the framework were in. The discussion stays open until the council has a firm date for restarting the ratification process, which it does not have while the network is down. The Radix Foundation’s announcement channel (https://t.me/RadixAnnouncements/2778) has published nothing since 2 September. Day nine: the node half opens, and it names an epoch Read at 07:08 UTC on 8 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a thirty-ninth consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is 177 hours and 49 minutes without a committed round. An hour before that reading, the second half of the fix became public. Pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) against babylon-node (https://github.com/radixdlt/babylon-node) , the software every validator runs, opened at 06:00:59 UTC from a branch named 0xOmarA/vault-access, by the same author (https://github.com/0xOmarA) who wrote the Engine fix and tagged Scrypto v1.4.0 the evening before. It carries 12 commits written between 3 and 8 September, 82 files and 4,209 added lines, and it has no description. It is open and unmerged, GitHub reports its merge state as blocked, and babylon-node has still released nothing since v1.3.0.5 of 1 June 2026, so no operator can install any of this yet. What it does contain is the first public answer to when the network restarts and what happens when it does. The epoch is written into mainnet_protocol_config.rs. A new constant, EAGLE_RAY_ENACTMENT_EPOCH, is set to 339,898, two past the 339,896 the ledger stopped on, and the trigger is EnactAtStartOfEpochUnconditionally: the Eagle Ray protocol update (/contents/tech/releases/protocol-updates) takes effect at the start of that epoch, with no readiness signal and no stake threshold. Every other entry in the mainnet list works the other way. Anemone, Bottlenose and Cuttlefish each wait for validators holding 75% of stake to signal readiness over a window measured in days or weeks, and Cuttlefish's second part follows its first automatically. Eagle Ray is the only one that enacts on an epoch number alone. Between the restart and that epoch, the network runs without users. The pull request adds a subsystem the node did not have, a user transaction moratorium: a range of epochs during which nodes refuse user transactions while consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) itself continues. Mainnet gets exactly one range, commented "Mainnet incident of 1 September 2026", running from epoch 339,897 inclusive to 339,898 exclusive. That is a single epoch, nominally five minutes, in which validators come back up, produce rounds and commit an epoch change, and nobody can transact. Three places enforce it. The mempool rejects a submission before it validates or caches it, with a comment that the payload can then be retried once the moratorium ends, and it offers no transactions to a proposal. The consensus pacemaker withholds its vote from any vertex carrying user transactions, dispatching an explicit NoVote and logging the epoch the moratorium runs to, including for vertices that arrive from other nodes through sync. A new verifier in the consensus processor chain applies the same check to incoming proposals. A node that skipped the update could still propose a user transaction; the rest would decline to vote for it. The most recent commit, at 05:27 UTC on 8 September, corrects which epoch that check reads. Until it, the consensus-side check asked the node's own committed ledger for the current epoch; it now takes the epoch from the consensus event being voted on. The distinction matters only at an epoch boundary, which is exactly where this moratorium lives: a node still committed at 339,896 would otherwise have voted for a vertex proposed in 339,897. A second correction in the same pull request has the same shape. Nodes ban peers that fall out of step around a protocol update and clear those bans when the update is close. That check read the epoch from the header of the node's latest proof, and an epoch-change proof's header names the epoch that ended rather than the one now running, so the reading was one too low. For an unconditional trigger the clearing window is a single epoch, the one before enactment, so the off-by-one would have missed it entirely. Stokenet (/contents/tech/releases/stokenet) , the public test network, gets the ordinary treatment instead: a readiness signal, 80% of stake, ten consecutive epochs. Both configurations lose the placeholder line that had held a slot for Dugong, the update that was next in the alphabet before this one, and Eagle Ray takes it. None of this is an announcement. It is an open branch, and every figure in it can change before it merges; the reviews the Radix Accountability Council (https://t.me/RadixAccountabilityCouncil/1000) said on 7 September were incomplete are the reviews this pull request is waiting on. What has to happen after it merges is unchanged: a node release, then operators installing it, then enough of them online to pass two thirds of stake. Day nine, afternoon: the repository that has to publish the fix could not build Read at 15:08 UTC on 8 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a forty-first consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is 185 hours and 49 minutes without a committed round. Two and a half hours before that reading, babylon-node (https://github.com/radixdlt/babylon-node) published a release. It is the repository's first since v1.3.0.5 of 1 June 2026, and it is not the fix. The tag is v1.3.0.5-test.1, published at 12:28:06 UTC (https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5-test.1) by github-actions[bot] with no release notes and seven build artifacts uploaded between 12:28 and 12:42 UTC. Every previous pre-release in this repository is an -rcN; v1.3.0.5 alone had six of them. This is the first tag in babylon-node's history to use -test, and because it is not flagged as a pre-release it is what the repository now reports as its latest release (https://api.github.com/repos/radixdlt/babylon-node/releases/latest) . What it contains is readable from the tag. The commit it points at, f2543c1, is the merge of pull request #1075 (https://github.com/radixdlt/babylon-node/pull/1075) , and that merge's first parent is 959b081, the commit tagged v1.3.0.5: the version mainnet was running when it stopped. The merge changes five files. It adds a .github/README.md, deletes two workflow files, cuts jobs from ci.yml, and repins Debian package versions in the Dockerfile. Fifty-nine lines added, 274 removed, none of them node source. The build published on day nine of the halt is the halted software plus a change to how it is built. The reason that change was needed is stated in the pull request itself, and it is the finding. Opened on 6 September and merged at 11:21:10 UTC on 8 September, #1075 records that while its author was validating the branch's CI they found main broken: apt-get failing with exit 100 across three build stages, because several exact-pinned Debian bookworm package versions had been superseded and withdrawn from the mirror. The repairs are one line each. curl moves from deb12u14 to deb12u15 in two stages, libssl-dev from deb12u1 to deb12u2 in two more, and three openjdk-17 packages get pinned alongside the JDK because the resolver was otherwise picking newer security builds the pinned JDK could not depend on. The same pull request removes a Snyk job that had, by its own account, failed on every pull request because the AWS secret it reads no longer exists. Sixty-seven minutes after that merge, the repository produced a build. Nobody has said what the build is for, and the release carries no text to say it. What is on the record is the sequence: for some period ending on 8 September, the repository that has to publish the remedy for a halted network could not produce an artifact, and the first thing it produced once it could was the version that halted. The pull request also closes with a breakage it does not fix. A note records that main additionally fails to compile under its pinned Rust 1.81.0 toolchain, on iter_repeat_n and is_multiple_of, and calls it separate and tracked elsewhere. Whether that still stands, and how a build was produced with it standing, is not established anywhere public. The fix itself has not moved. Pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) , the vault-access branch carrying the enactment epoch and the user transaction moratorium, is still open and unchanged since 06:01 UTC, though GitHub's merge state for it has gone from blocked to unstable since the morning reading. It targets develop, and develop is not the line this release came from: GitHub compares the tagged commit with the fix branch as diverged, with 235 commits on that branch the tag does not have and 32 the other way. Whatever the fix is merged into, it is not yet on the branch that produced today's build. Day nine, evening: the fix merges, and there is a build Read at 19:06 UTC on 8 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the same ledger for a forty-second consecutive reading: state version 557,840,622, epoch 339,896, round 102. That is 189 hours and 47 minutes without a committed round. What changed in the four hours before it is that, for the first time since the network stopped, there is something an operator can install. The move that made it possible was a change of destination. Pull request #1076 (https://github.com/radixdlt/babylon-node/pull/1076) had been opened against develop, the branch GitHub serves as babylon-node's default and whose tip has not moved since March 2025 — which is why the tagged build published that lunchtime and the branch carrying the fix read as diverged. At 15:24:46 UTC its author force-pushed the branch, at 15:24:57 changed its base to main, the line the releases actually come from, and at 15:28:11 merged it there. The merged pull request is 15 commits, 79 files, 4,275 lines added and 247 removed. GitHub records no reviews and no comments on it: it was opened, retargeted and merged by the same person, the author of the Engine fix (https://github.com/0xOmarA) , in nine and a half hours. Seven minutes after the merge, at 15:35:42 UTC, babylon-node published Eagle Ray v1.4.0.0-RC1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0-RC1) from the merge commit 7400951e, with seven build artifacts and a body containing the repository's licence text and nothing else. Container images followed: v1.4.0.0-RC1-amd64 at 16:06:37, -arm64 at 16:17:12 and the multi-architecture radixdlt/babylon-node:v1.4.0.0-RC1 (https://hub.docker.com/r/radixdlt/babylon-node/tags) at 16:23:04 UTC. This is a release candidate, flagged as a pre-release, and the flag has a side effect worth knowing: the repository's "latest release" (https://api.github.com/repos/radixdlt/babylon-node/releases/latest) still resolves to v1.3.0.5-test.1, the rebuild of the version that halted. The schedule the branch named survives the merge unchanged. In mainnet_protocol_config.rs at the released commit, EAGLE_RAY_ENACTMENT_EPOCH is 339,898 with the trigger EnactAtStartOfEpochUnconditionally, and the user transaction moratorium runs from epoch 339,897 inclusive to 339,898 exclusive — one epoch of consensus without users, then Eagle Ray (/contents/tech/releases/protocol-updates) enacts. Stokenet keeps its ordinary readiness signal of 80% of stake over ten epochs. The merge also carries the repository's Rust toolchain forward, which is the loose end #1075 (https://github.com/radixdlt/babylon-node/pull/1075) had recorded that morning as unfixed. main had pinned CI to Rust 1.81.0 and had no core-rust/rust-toolchain.toml at all; the merge sets that pin to 1.92.0, adds the toolchain file at the same channel, and moves the release-artifact workflow off stable onto the same version, alongside the source changes those compilers demanded. Nobody has announced any of it. The Radix Accountability Council (https://t.me/RadixAccountabilityCouncil/1000) 's most recent statement remains the one at 20:45 UTC on 7 September, which said the testing was unfinished and named no date, and in the three and a half hours after the release candidate appeared the main Radix chat discussed the price on the exchanges that are still quoting XRD (/contents/resources/how-to-buy-xrd) and nothing else. A release candidate is also not a restart: what remains is a final build, operators installing it, and validators holding two thirds of stake back online to commit epoch 339,897. Day ten: the fix runs, and not here Read at 19:04:37 UTC on 9 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the ledger it has returned since the halt: state version 557,840,622, epoch 339,896, round 102, proposer round timestamp 21:19:06.179 UTC. That is 213 hours and 45 minutes without a committed round. Five minutes later /state/validators/list answers HTTP 500 and counts the gap itself, it is currently 8 days, 21 hours, 50 minutes, 3 seconds behind, with current_sync_delay_seconds 769,803 against a max_allowed_sync_delay_seconds of 720. Twenty-one minutes before that reading, at 18:43 UTC, the Radix Accountability Council (https://t.me/RadixAccountabilityCouncil/1012) posted the first forward movement since the network stopped. The update, by projectShift as the council's updates have been throughout, is headed First milestone reached - STOKENET and says that a successful deployment of the new versions of software and protocol were achieved in Stokenet and the whole scenario was validated from end to end. The next steps it names are, in that order, a final commit for the official release, a date, and a plan for mainnet. It also asks node operators to leave the release candidate alone: do not use RC versions to test out on your nodes or similar ideas. What the test network shows from outside Stokenet's own ledger corroborates the deployment in the way that matters to someone waiting on mainnet: it never stopped. Sampled hourly through /state/entity/details pinned by timestamp – the same pinned read (/contents/tech/core-protocols/radix-gateway-api#pinned-reads) that gets an answer out of mainnet's frozen Gateway – Stokenet (/contents/tech/releases/stokenet) reports exactly twelve epochs in every one of the 28 hours from 15:00 UTC on 8 September to 19:00 UTC on 9 September, committing between 13,507 and 18,372 state versions an hour. At 19:05:34 UTC it was still committing about five state versions a second, at state version 7,346,809 in epoch 3,543. That is what a protocol update is meant to look like from outside. It enacts at an epoch boundary on nodes that already carry the code, so a network that adopts one correctly shows no interruption – which is also why an unbroken ledger is not by itself proof the update enacted. The council's statement is the source for the deployment; the ledger is the source for the fact that nothing broke around it. The release that is still not there Nothing has been published on the mainnet side since. babylon-node (https://github.com/radixdlt/babylon-node/releases) 's newest release is still v1.4.0.0-RC1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0-RC1) of 15:35:42 UTC on 8 September, still flagged a pre-release, so /releases/latest still resolves to v1.3.0.5-test.1 – the rebuild of the halted version, and the one the babylonnode CLI installs. The newest commit on main is still 7400951e of 15:28:10 UTC on 8 September, the merge of the fix itself. The final commit the council names as its next step had not been made twenty-seven hours later. So the schedule now has everything in it except a date. Eagle Ray (/contents/tech/releases/protocol-updates) enacts on mainnet at the start of epoch 339,898 unconditionally, with user transactions refused through epoch 339,897, the only update in Radix's mainnet history that does not go to a readiness vote; Stokenet takes the same update on the ordinary 80%-of-stake signal, which is the vote that has now been exercised. Mainnet is two epochs from the fix and cannot reach either of them until enough validators restart on a build that has not been released. Day ten, night: an operator names the room the halt was agreed in Read at 23:06:50 UTC on 9 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the ledger it has returned since the halt: state version 557,840,622, epoch 339,896, round 102. That is 217 hours and 47 minutes without a committed round, and /state/validators/list answers HTTP 500 counting the same gap, it is currently 9 days, 1 hour, 47 minutes, 44 seconds behind. The room the halt was agreed in Who stopped the network came back in the main Radix chat tonight, and this time an operator answered with the mechanism rather than the principle. At 20:10 UTC (https://t.me/radix_dlt/1002696) a holder asked how decentralised Radix is if a handful of node runners and the Foundation can freeze the network in a few hours, and what stops anyone else doing the same. Seventy-two seconds later Timan of Astrolescent (/ecosystem/astrolescent) replied: It was done by a few dozen node runners.. we have a group where we can chat and share learnings. A few decided it was better to halt until the source of the exploit was found, and explained it to the rest of the group. That names three things the earlier accounts left out. The operators have a standing channel of their own, separate from the Foundation and from the Radix Accountability Council (https://t.me/RadixAccountabilityCouncil) . A few of them moved first and the rest were persuaded rather than instructed. And the count is a few dozen, which is the order of the set that has to agree again before validators (/contents/tech/core-concepts/validator-nodes) come back. It is the same account the Foundation's announcement of 2 September (#day-three-foundation) contradicted when it said the Foundation and the council had halted the network, and it is the one the ledger supports. The report comes after the network Seventeen minutes earlier, at 19:53 UTC, a holder asked whether there is an official write-up of the exploit. projectShift, who has written the council's updates throughout, answered that enough detail is already public, that there will be an official report when the time is proper, and that the things that are safe to do will happen after we have this resolved and network liveness back. The sequencing is deliberate and it is the first time the council has stated it: the account of what happened is being held until the network is running. Nothing has been published on the release side since. babylon-node (https://github.com/radixdlt/babylon-node) 's main branch still ends at 7400951e of 15:28 UTC on 8 September, so the final commit the council named four hours earlier as the first of its three next steps has not been made, and the branch has taken nothing for 31 hours and 39 minutes. Day eleven: the release stops being a candidate, and the council clears operators to upgrade Read at 11:12:37 UTC on 10 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) returns the ledger it has returned since the halt: state version 557,840,622, epoch 339,896, round 102. That is 229 hours and 53 minutes without a committed round. /state/validators/list answers HTTP 500 and counts the same gap, it is currently 9 days, 13 hours, 53 minutes, 31 seconds behind, with current_sync_delay_seconds 827,611 against a max_allowed_sync_delay_seconds of 720. The release is final, and that changes what the installer fetches At 03:59:09 UTC babylon-node published v1.4.0.0, named Eagle Ray (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0) , the final commit the council named on 9 September (https://t.me/RadixAccountabilityCouncil/1012) as the first of its three next steps. Its tag resolves to 7400951e0eb76a725f39d04d57da293fb335bd0e, which is also what v1.4.0.0-RC1 (https://github.com/radixdlt/babylon-node/releases/tag/v1.4.0.0-RC1) of 8 September resolves to and the tip of main. The code is byte for byte the release candidate; what the final release changes is the pre-release flag. That flag is not cosmetic. GitHub reports as latest the newest release that is neither a draft nor a pre-release, so from 8 to 10 September the answer was v1.3.0.5-test.1 – a rebuild of the very version mainnet halted on – and that is what the ghproxy mirror (https://ghproxy.radixdlt.com/radixdlt/babylon-node) served to the babylonnode installer. Read at 11:12 UTC both now return v1.4.0.0. An operator who runs the standard install today gets the fix rather than the flaw, which was not true yesterday. The instruction is still wait At 05:54:09 UTC, in the main Radix chat, Timan of Astrolescent (https://x.com/astrolescent) gave the first statement of near-term intent from anyone: The stokenet upgrade yesterday went super smooth, so we’re very close in bringing mainnet back up. That needs a bit of coordination with the node runners, so it won’t be today, but I really hope we can pull that off in the coming days. (https://t.me/radix_dlt/1002777) He is an operator, not the Foundation and not the council, neither of which has published a date. Three hours later the council itself posted. At 09:13:53 UTC, projectShift wrote under the heading STATUS UPDATE FROM RAC: Although final versions has been made available, pls do not update your nodes yet. Further instructions and support will be shared later today or tmrw latest. Validator Node-runners should check dedicated chat often for specific updated information. (https://t.me/RadixAccountabilityCouncil/1017) On 7 September the council read the Scrypto release and told operators not to run it (https://t.me/RadixAccountabilityCouncil/1012) , because a library release is not a node build. On 8 September it said the same of the release candidate, because a candidate is not a release. Today there is a release, it is flagged latest, the installer serves it – and through the middle of the day the instruction had not changed. What is being waited on is no longer a build. It is the few dozen operators (#the-room-the-halt-was-agreed-in) who agreed the halt among themselves agreeing a restart the same way, on a schedule that has to be circulated before it can be run. The instruction changed at 16:15 UTC. Seven hours after telling operators to wait, projectShift posted the update that message had promised, again under the heading STATUS UPDATE FROM RAC: You can upgrade and update your nodes now, using the latest software version available from official sources. (https://t.me/RadixAccountabilityCouncil/1019) Validator node-runners are pointed to the dedicated validator chat for the detail, and a node that is fully upgraded and running properly is to be left online and working. The council called it one important step closer to network liveness being restored. It is the third of the four steps it named on 1 September, the coordinated deployment across nodes, and it is the first of them that ordinary operators outside the repair are asked to carry out. Deploying is not restarting. Read at 19:08 UTC, gateway-status (https://mainnet.radixdlt.com/status/gateway-status) returns the ledger it has returned since the stop, state version 557,840,622 at epoch 339,896, round 102, which is 237 hours and 49 minutes without a committed round; /state/validators/list still answers HTTP 500, now at a sync delay of 856,147 seconds against the 720 the Gateway tolerates. The ledger moves when enough upgraded validators agree to produce a round together, and the fourth step, a coordinated return to liveness, has no published date. Day twelve: the restart gets its sequence, and the largest validators are still dark Read at 07:07 UTC on 11 September 2026, the Gateway status endpoint (https://mainnet.radixdlt.com/status/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 forty-nine hours and forty-seven minutes without a committed round. What the network does when it comes back is fixed in the node software rather than left to a decision on the day. babylon-node v1.4.0.0 sets Eagle Ray to enact at the start of epoch 339,898 unconditionally in its mainnet protocol config (https://github.com/radixdlt/babylon-node/blob/main/core-rust/state-manager/src/protocol/protocol_configs/mainnet_protocol_config.rs) – the only mainnet protocol update in Radix's history that does not wait for the validator set to signal readiness – and declares a user transaction moratorium covering epoch 339,897, an epoch range during which user transactions are refused. The order that follows: 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 and accepts no user transactions; at the start of epoch 339,898 the fork enacts and the moratorium lifts together, and transactions are accepted again on the patched engine. Two node operators set that sequence out in the Radix Developers group (https://t.me/RadixDevelopers/66388) this morning, one reading it from the code and Daffy confirming (https://t.me/RadixDevelopers/66385) that the quorum for the fork is the same two thirds and that no announcement will precede it, because the moment cannot be predicted. The threshold is closer than it was and it is not close. Read from StakeSafe (/ecosystem/stakesafe) 's adoption dashboard (https://validators.stakesafe.net) at 07:12 UTC, 1,455,804,324 XRD is running v1.4.0.0, 31.22% of active validator-set stake, against 27.03% the previous evening; stake with a node online rose from 32.58% to 37.45% over the same hours, so operators are coming back online faster than they are coming back upgraded. The twelve largest validators account for 2,073,397,316 XRD between them, all twelve read a v1.3 version and all twelve read offline, and their stake exceeds the 1,668,419,975 XRD that still separates adoption from the threshold. One caveat on that column: the explorer reports the version a node last advertised, so an offline validator shows the release it was running when it stopped. The table says the explorer has not seen those twelve on Eagle Ray, not that their operators have not installed it. Day twelve, midday: the network restarts Radix mainnet committed a round at 11:35:28.96 UTC on 11 September 2026, its first in ten days. The restart is legible in the transaction stream (https://mainnet.radixdlt.com/stream/transactions) as two consecutive ledger entries with nothing between them: state version 557,840,627 carries epoch 339,897 round 4 at 21:19:48.939 UTC on 31 August, and state version 557,840,628 carries epoch 339,897 round 5 at 11:35:28.96 UTC on 11 September. Measured between those two rounds the network was down for 254 hours, 15 minutes and 40 seconds, ten days and fourteen hours. Those state versions correct a number this page has repeated for twelve days. Every reading recorded above came from the Gateway status endpoint (https://mainnet.radixdlt.com/status/gateway-status) , which reported the frozen ledger as state version 557,840,622 at epoch 339,896 round 102, timestamped 21:19:06.179 UTC. The transaction stream shows the ledger ran five state versions past that point before it stopped, through epoch 339,897 rounds 1 to 4 and three further user transactions, and the last of them is timestamped 21:19:48.939 UTC, forty-three seconds later than the halt time this page has been citing. The Gateway's status reading was its aggregator's tip rather than the ledger's, and the gap it left was invisible for as long as neither number moved. The restart itself ran exactly as the node software specified it. Epoch 339,897 resumed under the user transaction moratorium and produced rounds 5 to 106 between 11:35:28.96 and 11:39:07.213 UTC, and every ledger entry in that window is a system transaction: the network was certifying rounds and refusing user payloads, which is what the moratorium is for. The fork then enacted at the start of epoch 339,898, and at 11:39:25.129 UTC round 2 of that epoch committed 17 user transactions at once, five of them failing, as the queue that had been waiting ten days cleared. Just under four minutes of empty blocks separate the network coming back from the network being usable. Adoption crossed the threshold during the morning and kept going. This page recorded 31.22% of active validator-set stake on babylon-node v1.4.0.0 at 07:12 UTC; read from StakeSafe (/ecosystem/stakesafe) 's adoption dashboard (https://validators.stakesafe.net) at 13:10 UTC, 3,737,284,159 XRD is on v1.4.0.0, 80.85% of a 4,873,528,908 XRD active set, and 81.67% of that set has a node online. The dashboard now leads with a banner of its own, reporting network liveness restored following a fix deployed at epoch 339,898. The caveat this page attached to the morning reading turned out to be the whole of it. At 07:12 the twelve largest validators all read a v1.3 version and all read offline, and this page noted that the explorer reports the version a node last advertised, so an offline validator shows whatever it was running when it stopped. Faraz put it directly (https://t.me/radix_dlt/1003000) in the main Radix group at 10:11:24 UTC, answering a member asking why the ten largest validators could not spare ten minutes: the state was intentional, the largest nodes were upgraded and waiting to boot together, and the aim was to come back well clear of two thirds rather than marginally above it. Daffy had said the same (https://t.me/radix_dlt/1002990) sixteen minutes earlier in one line. The table was not showing a stalled upgrade. It was showing a coordinated one, held back on purpose. Nothing official has announced any of it. The Radix Accountability Council's most recent message (https://t.me/RadixAccountabilityCouncil/1019) is still the 16:15 UTC instruction of 10 September telling operators to upgrade, and neither the Foundation's blog nor the announcements channel has posted since the network came back. That is the stated plan rather than an oversight: asked on the morning of 11 September whether an announcement would precede the fork, Daffy answered (https://t.me/RadixDevelopers/66385) that there would be none, because the moment could not be predicted, and gave the order plainly (https://t.me/RadixDevelopers/66387) as secure liveness first, announce after. The documentation page for Eagle Ray (https://docs.radixdlt.com/docs/eagle-ray) still answers HTTP 404, an hour after the update it is supposed to document enacted on mainnet. The first published test of the fix is on the ledger, and it is the exploit. At 12:35:05.915 UTC, fifty-six minutes after user transactions resumed, a transaction in epoch 339,909 (https://dashboard.radixscan.io/transaction/txid_rdx1n23szuw226jqjhqt2v8zeguwh545xlyarmwfg0g3dgcsfy4dnceqf4a269/summary) published a package to mainnet whose blueprint is named VaultDrainer and whose methods are drain and drain_victim_pays. It committed successfully for a fee of 14.14 XRD, which is a package publish succeeding rather than a drain succeeding. The operator who submitted it said why in the developer group (https://t.me/RadixDevelopers/66391) a minute earlier: it is the drainer that had been hammering the unpatched network, the moratorium and the enacted network through testing, and it is on mainnet to verify the fix is operative against live vaults. One reading does not agree with the rest, and is recorded here rather than resolved. The same StakeSafe dashboard's network summary still names the enacted protocol Cuttlefish, which is the version Eagle Ray replaces. The ledger behaviour is not ambiguous about which software produced these epochs, since the user transaction moratorium is a v1.4.0.0 feature and the network observed it for a hundred rounds, so the likeliest reading is a summary field that lags rather than a contradiction. Neither the Gateway's network-configuration nor its network-status response carries a protocol version, so it has not been confirmed from a second source. Reading your own account while the Gateway refuses The question most often asked in the Radix chat since the halt is not about the exploit. It is whether an individual account lost anything, and the ordinary way to find out does not work: dashboard.radixdlt.com (https://dashboard.radixdlt.com) loads and then fails, because it reads the Gateway API (/contents/tech/core-protocols/radix-gateway-api) , and the Gateway will not answer a question about the present while it is five days behind the network. It will answer a question about the past. The guard is skipped for any request that names a ledger state (/contents/tech/core-protocols/radix-gateway-api#pinned-reads) , so a read pinned to state version 557,840,622 — the last one the Gateway reported, at 21:19:06.179 UTC on 31 August — returns 200 from the same endpoint that returns 500 unpinned. Verified at 07:07:56 UTC on 6 September 2026: curl -X POST https://mainnet.radixdlt.com/state/entity/details \ -H 'Content-Type: application/json' \ -d '{"addresses":["account_rdx1..."], "at_ledger_state":{"state_version":557840622}}' The same pin works on /stream/transactions, which with an affected_global_entities_filter set to the account returns that account's own transaction history up to the halt — the record of whether anything left it, and when. Both calls need no key. Two limits are worth stating plainly. This is the final pre-halt state and nothing more: it is the answer to what did I hold when the network stopped, not to what do I hold now, and the two will be the same only because nothing can move until the network restarts. And it reads; it does not write. /transaction/construction refuses pinned and unpinned alike, so no transaction can be built or submitted, which is the halt working as intended rather than a gap in it. ## Radix Governance URL: https://radix.wiki/contents/tech/core-concepts/radix-governance Updated: 2026-09-11 Summary: Radix governance is the set of institutions, rules, and processes by which decisions about the Radix network and its shared resources – its treasury,… Radix Governance Governance model Progressive decentralisation – Foundation stewardship to community ownership Voting XRD (/contents/tech/core-protocols/xrd-token) -weighted, 1 XRD = 1 vote (non-custodial on-ledger snapshot) Current steward Radix Foundation (/ecosystem/radix-foundation) (winding down, 2026) Transition body Radix Accountability Council (/ecosystem/radix-accountability-council) (RAC) Destination entity Radix DLT DAO – Marshall Islands DAO LLC (MIDAO) Voting venue On-ledger consultation dApp + RadixTalk (/ecosystem/radixtalk) Status 🟡 In transition (2026) Introduction Radix governance is the set of institutions, rules, and processes by which decisions about the Radix network (https://www.radixdlt.com) and its shared resources – its treasury, intellectual property, trademarks, and core infrastructure – are made. Since 2026, Radix has been undergoing a deliberate transition from stewardship by the Radix Foundation (/ecosystem/radix-foundation) toward ownership and governance by its community, with authority expressed through XRD-weighted voting. This page is a durable overview of that structure. Because the specific bodies carrying out the transition – most visibly the Radix Accountability Council (/ecosystem/radix-accountability-council) – are explicitly time-bound and will be succeeded, this page describes Radix governance in terms of enduring roles and phases, and points to where the latest developments are published. The Radix Governance Map Radix governance spans a family of legal entities and an in-progress handover from the Radix Foundation to a community-owned DAO. The map below shows who holds what today and where authority is heading. RADIX WIKIRadix Organizational StructureENTITIESHow Radix is organized: a UK not-for-profit foundation and its subsidiaries build and stewardthe network – while governance is now handing over to a community-owned DAO.THE FOUNDATION GROUPownsfunds / formingRadix Foundation LtdUK not-for-profit · limited byguarantee · no shareholdersHOLDING CORDX Works LtdCore protocol developer; fkaRadix DLT (2017), renamed 2021SEPARATE COMPANYfundingwholly-owned subsidiariesRadix Tokens (Jersey) LtdIssues & manages XRD;JFSC-regulated treasuryTOKENSRadix Publishing LtdCanonical open-sourcecode, GitHub & commsCODE / COMMSArchetype LtdHolds non-open-sourceintellectual propertyIPExosphere LtdHolding co; formerlyRadix Ecosystem HoldingHOLDINGGOVERNANCE IN TRANSITION – 2026Radix FoundationEntering maintenance mode(2026); pre-funds core infraWINDING DOWNRadix AccountabilityCouncil5 community-elected;multi-sig steward · Feb 2026BRIDGE BODY (RAC)Radix DLT DAO (RDD)Community-owned; legalentity forming · gets treasuryFUTURE OWNERhands overformsCOMMUNITYXRD holders elect the RAC and vote on proposals – 1 XRD = 1 vote, non-custodial balance snapshot.electsGrounded in radix.wiki – Radix Foundation & RAC pages · the 2026 Foundation-to-DAO transition.radix.wiki The Radix entity group and the 2026 Foundation-to-DAO governance handover. How Radix Is Governed Radix governance is token-weighted and non-custodial. Holders of XRD (/contents/tech/core-protocols/xrd-token) , the network's native token, vote directly on proposals – one XRD equals one vote – and voting never requires locking or transferring tokens. Instead, an on-ledger consultation application reads a snapshot of XRD balances at a set block height, so participation carries no custody risk and cannot be gamed by moving tokens after a vote opens. In practice, decisions move through discussion and then a formal vote. Community members debate proposals on RadixTalk (/ecosystem/radixtalk) , the governance forum, before consultations are put on-ledger for a binding vote. Approved actions – such as spending from a shared treasury or changing governance rules – are then executed by elected representatives holding multi-signature authority. The detailed proposal-to-execution process, thresholds, and quorums are set out in the community-drafted Radix Network DAO Charter (/ideas/radix-network-dao-charter) . From Foundation to DAO: the Transition Radix was designed from the outset to progressively decentralise (https://www.radixdlt.com/blog/2026-strategy-the-next-chapter-of-radix) . Its governance can be understood as three enduring phases, each defined by a role rather than by the individuals or bodies that occupy it at any moment: - Foundation stewardship. The Radix Foundation (/ecosystem/radix-foundation) , a UK not-for-profit, and its subsidiaries built, funded, and stewarded the network, while RDX Works (/ecosystem/rdx-works) developed the core protocol. In January 2026 the Foundation announced its transition to community ownership and has since moved toward a maintenance-only role. - Transition governance. A community-elected bridge body completes two jobs: forming the DAO's legal entity and receiving the Foundation's handover of treasury, intellectual property, and operational assets. As of 2026 this role is held by the Radix Accountability Council (/ecosystem/radix-accountability-council) (the "Transition RAC"). - Permanent community governance. Once the DAO's legal entity – a Marshall Islands DAO LLC (MIDAO) – exists and the handover completes, the community elects a permanent council to steward it. This is the destination: a network owned and governed by its token holders. Framing governance this way keeps the overview stable: as the transition body is replaced by a permanent one, only the current occupants below need updating, not the structure itself. Governing Bodies (as of 2026) The roles above are currently held by the following bodies: - Radix Foundation (/ecosystem/radix-foundation) – the outgoing steward. Registered in the UK as RADIX FOUNDATION ( company 12106715 (https://find-and-update.company-information.service.gov.uk/company/12106715) ), a not-for-profit limited by guarantee, whose subsidiaries issued XRD (Radix Tokens (Jersey) Ltd), publish the open-source code (Radix Publishing Ltd, a Jersey company, through its UK subsidiary Radix Publishing (UK) Limited (https://find-and-update.company-information.service.gov.uk/company/14955990) ), and hold intellectual property (Archetype Ltd). Since 10 February 2025 the group has been controlled by Radix Foundation Limited, a separate Jersey company, and the UK company has had a single director. It is winding down to a maintenance role. - Radix Accountability Council (/ecosystem/radix-accountability-council) (RAC) – the transition body: five community-elected members guiding DAO formation and the Foundation handover. This is a temporary "Transition RAC" that a permanent, elected council will succeed. - Radix DLT DAO (RDD) – the community-owned entity being formed as a Marshall Islands DAO LLC, which will receive the Foundation's assets and become the network's permanent governance home. Key Governance Documents - Operating Agreement – the legally binding document that constitutes the Marshall Islands DAO LLC. - Charter – the constitutional document capturing the community's governance principles, adopted by community vote. - Radix Network DAO Charter (/ideas/radix-network-dao-charter) – a discussion-stage governance framework on this wiki, adapted from the Aragon Network DAO Charter (https://github.com/aragon/network-dao-charter) , that informed the transition structures. - Radix DAO Governance repository (https://github.com/Shadaffy/radix-dao-governance) – the open repository where the Operating Agreement and Charter were drafted, authored and maintained by community contributor Daffy. It defines a four-step founding sequence rather than a single founding vote: Constitutional Ratification (GP-PRE-1) → entity formation → the permanent RAC election (GP-ELECT-1) → the Activation Vote (GP-ACTIVATE-1), after which governance outcomes become binding and the Transition RAC sunsets. Until that sequence completes, no document in the repository is yet operative (https://github.com/Shadaffy/radix-dao-governance/blob/master/PROPOSALS.md) . The On-Chain Register, checked against the ledger Most governance documents can only be read. One can be checked: on 7 August 2026 the framework's On-Chain Identifiers & Verification Policy (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/on-chain-identifiers-and-verification-policy.md) stopped carrying [to be recorded at deployment] placeholders and recorded the deployed mainnet addresses (https://github.com/Shadaffy/radix-dao-governance/commit/88fa6ac9) , then wrote the rules governing the Master Badge (https://github.com/Shadaffy/radix-dao-governance/commit/2a5fe93d) as "the root of governance-infrastructure control rather than a peer of the Owner Badge (/contents/tech/core-concepts/badges) ". The register names a governance component (/contents/tech/core-concepts/components) , a governance package, two badges, XRD as the voting-power resource (/contents/tech/core-concepts/resources) , a governance platform and an official venue, each with a public verification link. The entries below were read from the ledger on 9 August 2026 at epoch 333391, re-checked on 12 August 2026 at epoch 334446, and re-read on 16 August 2026 at epoch 335598. The component is deployed and has never been used. The recorded governance component (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) runs blueprint (/contents/tech/core-concepts/blueprints-and-packages) Governance v1.0.0 from the package the register names, and its stored state is three key-value stores with a counter each: temperature_check_count, proposal_count and majority_judgment_election_count. All three read 0. The contract that the whole framework routes through is live on mainnet and has processed nothing — which is the correct state, since nothing in the framework is operative and the transition votes to date have run on the earlier Consultation (/ideas/dao-governance-app-consultation-v2) instance. Majority Judgment (/contents/tech/core-concepts/majority-judgment) is deployed, not merely drafted. That third store exists at all, which is on-ledger corroboration for a change the repository made on 29 July 2026 (https://github.com/Shadaffy/radix-dao-governance/commit/3563a013) , when Majority Judgment became a co-equal election mechanism alongside two-stage approval. Its counting rule is stated in Proposal & Voting Framework (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/proposal-and-voting-framework.md) §6.2.4: a candidate's grade is the highest one that three-fifths of the voting power cast placed them at or above, a fraction chosen to equal the approval threshold of the other mechanism so that both put the same share-of-turnout test to a candidate. The same section requires that comparison be evaluated by cross-multiplication on exact decimals and never in floating point, on the ground that an error in the last place "raises no exception and is invisible in the published tallies". OTER's independent tally verifier (/ecosystem/oter#verifier) implements that rule the same way. The badges are the Consultation dApp's own. Both recorded resources carry on-ledger metadata naming them for the existing voting app rather than for a new deployment: the Master Badge (https://dashboard.radixdlt.com/resource/resource_rdx1nt4gugcmzpajreu75g2ul2whcpa48cdyn0h8n8x8zl5c0gstxn8gvd) is the "Consultations Master Badge", the Owner Badge (https://dashboard.radixdlt.com/resource/resource_rdx1ng4c5k872hvhr379n0z0x6ht2n0guugns4jeh6mck9y28cu432xvc4) is the "Consultations Admin Badge", described on-ledger as "the admin badge for the DAO Voting dapp". Each is a single non-fungible. Their authority settings differ in exactly the way the policy describes: - Master Badge – minter, burner, freezer and recaller are all deny_all, and the rules are locked. A second one cannot be minted, and the existing one cannot be burned or recalled from whoever holds it. The root of control is neither clonable nor revocable at the resource level, which is what makes the policy's custody rule — held in the multi-signature treasury account, never used to perform an elevation — the whole of the control. - Owner Badge – minter, burner and recaller are its owner role and its rules are not locked. The mint, recall and invalidate capability the policy attributes to the Master Badge is therefore real at the resource level, and so is the hazard the policy names: a recalled badge disables the elevation pipeline, and a freshly minted one confers elevation authority on a holder bound by no mandate. The venue entry was corrected, and the last placeholder filled. When this section was first written the register recorded the Official Venue as https://www.radixdao.org – a hostname with no DNS record, while the apex radixdao.org resolved and served. On 11 August 2026 the policy dropped the www prefix (https://github.com/Shadaffy/radix-dao-governance/commit/302a3cb) so that "the recorded identifier matches the live location", and the same commit replaced the register's last [to be recorded at deployment] placeholder with the deployed primary multi-signature treasury account. Recording an address invites the check that a document cannot: the two paragraphs below are that check. The treasury account holds 200 XRD, and now holds the Master Badge. Re-read on 16 August 2026 at epoch 335598, the recorded primary multi-signature treasury account (https://dashboard.radixdlt.com/account/account_rdx1c9l27suy4nte9ymge5c3eqqnnfepgf9p28d9lcsv3jvmd0f0z8j2fx) held 200 XRD and one non-fungible, the Master Badge, which arrived on 13 August; the paragraph below traces it. Its first two transactions are dated 10 August 2026. Its owner rule is a CountOf(2) over three Ed25519 signature badges (https://dashboard.radixdlt.com/resource/resource_rdx1nfxxxxxxxxxxed25sgxxxxxxxxx002236757237xxxxxxxxxed25sg) – a 2-of-3 multi-signature, and exactly the threshold the framework specifies for this phase: 2-of-3 for ordinary actions with the three Transition RAC members as the initial signers, rising to 3-of-5 standard and 4-of-5 high-risk on the Activation Date ( DAO Parameters §6A (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/parameters/dao-parameters-registry.md) ; On-Chain Identifiers §6 (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/on-chain-identifiers-and-verification-policy.md) ). The deployment therefore matches the document. What it does not yet hold is a treasury: the Foundation's handover of assets has not arrived at this address, and nothing about the balance is disclosed anywhere the address is not. The Master Badge moved into it on 13 August, a day after this section said it had not. The policy's custody rule for the Master Badge is specific – it "is held in the primary multi-signature treasury account recorded at §5, not by any natural person", so that it "cannot be exercised without a signing quorum", and that quorum is also what makes the badge-compromise backstop operable. Until 13 August 2026 the badge sat in a single-signature account carrying the on-ledger name Astrolescent (https://dashboard.radixdlt.com/account/account_rdx128y905cfjwhah5nm8mpx5jnlkshmlamfdd92qnqpy6pgk428qlqxcf) . At 15:24:19 UTC that day a single transaction (https://dashboard.radixdlt.com/transaction/txid_rdx1kg65rh9spggn32h0cqj5d7jyn8n07euv98cmcj05xryn6rt5u4vqrgzjdg) withdrew the Consultations Master Badge #1# from that account and deposited it into the treasury account, where a re-read on 16 August at epoch 335598 found it. The custody rule is now satisfied on the ledger before it is in force on paper: the policy still sits in pending/ awaiting ratification, so the move is the holder's own act rather than an obligation anyone can enforce. The Owner Badge did not move. It remains in the unnamed account (https://dashboard.radixdlt.com/account/account_rdx12yu55zy3cx3lx3xjkp9f2vzp2ye2mql5vzhxvq0tks74d5hcp0xkvs) that has held it throughout, secured by a single signature rather than a quorum. That is the badge whose minter, burner and recaller are its owner role with the rules unlocked, so it is also the badge where one key carries the hazard the policy names: a recalled badge disables the elevation pipeline, and a freshly minted one confers elevation authority on a holder bound by no mandate. The badge that moved into the quorum is the one whose resource rules are locked; the one still under a single key is the one whose are not. None of this is yet in force. The policy sits in the repository's pending/ directory with the rest of the framework, awaiting the ratification vote that opens the founding sequence described above. The First Governance Proposals (July–August 2026) The two-stage route a proposal takes during the transition – a Temperature Check to gauge support, then a binding Governance Proposal – was exercised for the first time in late July 2026. The Radix Accountability Council (/ecosystem/radix-accountability-council) opened two Temperature Checks on 25 July (https://t.me/RadixAccountabilityCouncil/904) : one from Daffy asking the Foundation (/ecosystem/radix-foundation) to fund the community-run Stokenet (/contents/tech/releases/stokenet) operation it had handed over, and one from Timan on the Radix website. On 28 July the RAC confirmed both had passed and been lifted to Governance Proposals (https://t.me/RadixAccountabilityCouncil/906) , opened for XRD-weighted voting at proposal 1 (https://consultation.mountain-top.live/proposal/1) (Stokenet) and proposal 2 (https://consultation.mountain-top.live/proposal/2) (website). Both closed on 4 August 2026, and both closed unopposed. Read from the Governance component (https://dashboard.radixdlt.com/component/component_rdx1czn9hrgd30x742k6jw2e6psj9jlkqvu2cj4hcry60p7f38hxd3k3xt) on 11 August, the Stokenet proposal carries 55 ballots and the website proposal 56, and not one of them is a No. The weight behind the voting accounts clears the 671,470,000 XRD quorum written into each by roughly 40%: 910,989,217 XRD stands behind the Stokenet proposal and 910,406,795 XRD behind the website proposal, about 136% of the figure written into each. Almost none of that weight is liquid, and a tally that misses this misses the result. Only 125,897,148 XRD of the Stokenet total sits in an account as XRD. The other 785,092,070 is held as stake units, and has to be converted back at each validator’s current exchange rate before it counts as voting power. Reading liquid balances alone understates these accounts more than sevenfold – enough to turn a vote that cleared its quorum into one that appears to have missed it by a wide margin. This wiki published that error and corrected it; the case is kept as a worked example under No original research (/policy/no-original-research) . The May 2026 Xi’an (/contents/tech/releases/radix-mainnet-xian) kickoff vote clears its own bar the same way: 1,186,155,329 XRD against a 940,046,370 quorum, from 254 accounts casting 256 votes, 255 approve to one reject. These are balances read on 9 August 2026 rather than the snapshot the dApp weighted at voting time, so the figures are indicative; the margins are wide enough that the direction is not in doubt. Clearing a quorum does not by itself release money – the Xi’an milestone was paid by the Foundation directly, on the strength of clear community consensus rather than on the tally. Both are pre-activation votes: they signal community will to the Foundation rather than binding a DAO that does not yet legally act. That distinction is the practical shape of the transition period – the community votes, and an entity that is still winding down executes. A week past the deadline neither outcome had been published. The component records ballots, not results, so the tally a proposal is judged on is computed off-ledger and announced by whoever computed it; the RAC's channel has posted nothing since the 28 July elevation. The consultation behind them has also stalled: Temperature Check 6 (https://consultation.mountain-top.live/tc/6) , on registering Radix in the CAIP namespaces registry and the x402 payment standard, closed on 6 August with 58 votes and has not been lifted to a proposal, and the component's proposal_count still reads 3. Execution began without any result being published (18 August 2026). Fourteen days past the deadline no tally for either proposal has been announced, by the Council or by anyone else. What arrived instead was the work. At 07:20 UTC the contributor carrying the website workstream told the main channel they were meeting that day about the migration, "per the approved proposal" (https://t.me/radix_dlt/998599) — the first public treatment of Governance Proposal 2 as carried. Three and a half hours later they reported the site being moved off its static export onto an Astro site hosted on Cloudflare (https://t.me/radix_dlt/998611) , and by midday that the first generation attempt had produced a new design instead of a conversion (https://t.me/radix_dlt/998616) and was being redone. That correction is the substantive part: Proposal 2 approved preservation of the existing site, and a new design is what the separate, unvoted website RFC (/ideas/dao-website-redesign) proposes. During the transition, then, the step that carries a proposal into effect is not an announcement. It is somebody starting. The voting venue has moved to the DAO's own domain, and it is a different dApp. The DAO's participation page (https://radixdao.org/participate/) now directs voters to vote.radixdao.org (https://vote.radixdao.org) , which serves the Consultation application under the radixdao.org (https://radixdao.org) venue the on-chain register names. It is not the same deployment as the instance that ran the first three votes. Each site declares its dApp definition in the runtime config it serves, and read from the ledger on 18 August 2026 at epoch 336079 the two differ: the new site declares account_rdx128965k8… (https://dashboard.radixdlt.com/account/account_rdx128965k8mhauk679vtew96ynq4k43rzd975jak4d5z6cvp0t0c6z7u0) , named Radix DAO on-ledger, while consultation.mountain-top.live declares account_rdx12y8wqqg… (https://dashboard.radixdlt.com/account/account_rdx12y8wqqgpjndcns9m94tjyhmfyx3hujf5snqqqjmu86vrcvg8zsx88y) , named Radix Consultation V2 and described as "Governance on Radix, by the Radix community". Every proposal and temperature-check link on this page points at the older one. Which deployment runs the Charter ratification — the first binding vote the DAO will hold — is an open question, and the answer decides where the record of it lives. The new venue also publishes, at an address the register names, the rule any tally rests on. Voting power is the XRD behind an account "wherever in the network you have deployed it": liquid XRD, validator LSUs, LSULP and eligible DEX liquidity positions all count, for the XRD underneath them, measured at a snapshot taken when each vote opens. Liquid staking units are excluded from the register's address table by design, since each validator mints its own, and are converted to their XRD equivalent at that snapshot. This is why a quorum recomputed from liquid balances alone reads far short of the real one — most of the weight behind a Radix voter is staked, not sitting in an account. Staying Informed Governance moves quickly during the transition. To follow the organizational progress of Radix: - Live updates – the community governance channel. Currently the Radix Accountability Council's Telegram (https://t.me/RadixAccountabilityCouncil) , where the body stewarding the transition posts its updates first. This is the single best place to watch organizational progress as it happens. - Consultations and votes. The governance category on RadixTalk (https://radixtalk.com/c/governance) , where proposals are discussed and on-ledger votes are announced. - Official announcements. The Radix blog (https://www.radixdlt.com/blog) , for Foundation-level announcements – becoming less central as the Foundation winds down. When the transition body changes, the primary channel may move with it; this page tracks the current one. External Links - Radix Accountability Council – Telegram (https://t.me/RadixAccountabilityCouncil) - RadixTalk – Governance (https://radixtalk.com/c/governance) - 2026 Strategy: The Next Chapter of Radix – Radix Blog (https://www.radixdlt.com/blog/2026-strategy-the-next-chapter-of-radix) - Radix DAO Governance repository (https://github.com/Shadaffy/radix-dao-governance) - How DAOs fail: participation-weighted governance and common failure modes (https://caper.network/wiki/dao-governance/concepts/analysis/how-daos-fail) (Caper wiki) ## Radix Foundation URL: https://radix.wiki/ecosystem/radix-foundation Updated: 2026-09-11 Summary: The Radix Foundation is a not-for-profit organization focused on the development, promotion, and governance of the Radix public network , a decentrali… Radix Foundation – Ecosystem Organization Type Not-for-profit foundation (limited by guarantee) Purpose Development, promotion, and governance of the Radix public network (https://www.radixdlt.com) Status Active – maintenance mode from May 2026 (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) Jurisdiction United Kingdom ( company 12106715 (https://find-and-update.company-information.service.gov.uk/company/12106715) ); control passed to Radix Foundation Limited (Jersey) in February 2025 Key People Dan Hughes (/contents/history/dan-hughes) (co-founder, d. 2025), Piers Ridyard (co-founder), Andrew Jarrett (sole director of the UK company since February 2025) Subsidiaries Radix Tokens (Jersey) Ltd (token issuance), Radix Publishing Ltd, Jersey (open-source code & communications), and its UK subsidiary Radix Publishing (UK) Limited (https://find-and-update.company-information.service.gov.uk/company/14955990) , Archetype Ltd Token XRD ($XRD), issued via Radix Tokens (Jersey) Ltd Website radixfoundation.org (https://web.archive.org/web/20240713071910/https://www.radixfoundation.org/) When a user clicks the button, RDT coordinates with the Radix Wallet Connector (https://chromewebstore.google.com/detail/radix-wallet-connector/bfeplaecgkoeckiidkgkmlllfbaeplgm) browser extension to establish a connection to the user's mobile wallet. The user authenticates using a Persona (/contents/tech/core-protocols/personas) – a reusable identity that can share selected accounts and personal data with your dApp. Requesting Account Data Configure what data your dApp needs at connection time: import { DataRequestBuilder } from '@radixdlt/radix-dapp-toolkit' rdt.walletApi.setRequestData( DataRequestBuilder.accounts().atLeast(1), DataRequestBuilder.persona().withProof(), ) This asks the user to share at least one account address and a cryptographic proof of Persona ownership. For ROLA (Radix Off-Ledger Authentication) (/developers/frontend/03-rola-authentication) , provide a challenge generator that fetches a 32-byte hex challenge from your backend: rdt.walletApi.provideChallengeGenerator(async () => { const res = await fetch('/api/auth/challenge') return (await res.json()).challenge }) Reaching the wallet RDT gives your code one interface and runs two transports underneath it. In a desktop browser it reaches the wallet through the Radix Wallet Connector (https://chromewebstore.google.com/detail/radix-wallet-connector/bfeplaecgkoeckiidkgkmlllfbaeplgm) , a Chrome extension the user links to their phone by opening the wallet app, tapping Linked Connectors, and scanning a QR code. In a mobile browser there is no extension at all: RDT opens the wallet app on the same device through a deep link. The toolkit’s own README (https://github.com/radixdlt/radix-dapp-toolkit/blob/main/packages/dapp-toolkit/README.md) states the split in a sentence, and the wallet setup guide (https://wallet.radixdlt.com) is where users meet it: phone users are told they are ready to go, desktop users are told to install the extension first. Ledger goes through the extension The Connector is also how a Ledger (https://www.ledger.com/) hardware wallet reaches the Radix Wallet. Both the setup guide and the store listing (https://chromewebstore.google.com/detail/radix-wallet-connector/bfeplaecgkoeckiidkgkmlllfbaeplgm) say so in the same words: the Connector enables use of Ledger hardware wallet devices. A Radix user who signs with a Ledger therefore needs the desktop browser as well as the phone, because the phone-only path carries no Connector. If your dApp expects hardware-wallet users, it is a desktop dApp. The extension is at version 1.7.0, updated on 16 April 2026, published by radixdlt.com and installed by around 20,000 users; its repository (https://github.com/radixdlt/connector-extension) last took a commit the following day and is not archived. That is six weeks after RDT’s own last release, so the transport moved after the library stopped. Signing once for a transaction someone else finishes Every sendTransaction call ends at a prompt the user has to approve, so a flow built from several calls costs several approvals. Pre-authorizations (/contents/tech/core-concepts/subintents-and-pre-authorizations) , the user-facing name for subintents, are the protocol’s answer: the user signs a partial transaction that another actor completes and submits. They reached mainnet in the Cuttlefish (/contents/tech/releases/protocol-updates) protocol update in December 2024, and RDT exposes them as sendPreAuthorizationRequest alongside sendTransaction. The shape is different from a normal request. Your dApp sends a manifest stub with an expiry schedule rather than a complete manifest; the stub locks no fee, because the enclosing transaction pays, and it ends with YIELD_TO_PARENT. The wallet returns a hex-encoded SignedPartialTransaction, which your front end passes to a back end that builds it into a full transaction and submits it. Radix’s documentation for the flow (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) notes that no general subintent aggregator existed at the Cuttlefish launch, so today that back end is usually the dApp’s own or a named matcher such as Anthic (/ecosystem/anthic) . Submitting Transactions Radix transactions are built using transaction manifests (/contents/tech/core-protocols/transaction-manifests) – a declarative syntax that describes what the transaction should do. Your dApp sends a manifest stub to the wallet; the wallet completes it by adding fee payment and any user-specified assertions. const result = await rdt.walletApi.sendTransaction({ transactionManifest: ` CALL_METHOD Address("component_rdx...") "buy_token" Decimal("100") ; CALL_METHOD Address("${accountAddress}") "deposit_batch" Expression("ENTIRE_WORKTOP") ; `, }) The user reviews the transaction in their wallet – seeing exactly which assets move where – signs it, and the wallet submits it to the network. Your dApp receives a transaction hash that you can track via the Gateway API (/contents/tech/core-protocols/radix-gateway-api) . Reacting to Wallet Data Subscribe to wallet state changes to update your UI in real time: rdt.walletApi.walletData$.subscribe((walletData) => { const accounts = walletData.accounts // Update UI with connected accounts }) Maintenance Status (checked August 2026) RDT is stable and still the correct library to build against, but it is no longer under active development. The last commit on the toolkit's main branch (https://github.com/radixdlt/radix-dapp-toolkit/commits/main) and its most recent release, v2.3.0 (https://github.com/radixdlt/radix-dapp-toolkit/releases/tag/v2.3.0) , are both dated 2 March 2026, and npm latest (https://www.npmjs.com/package/@radixdlt/radix-dapp-toolkit) has not moved since. The repository is not archived and remains Apache-2.0. Frozen is not unused: the package drew 48,555 downloads (https://www.npmjs.com/package/@radixdlt/radix-dapp-toolkit) in the month to 9 August 2026, close to 12,000 a week, so the library every Radix front end depends on is being installed at scale while nobody is shipping to it. The stall is visible in the queue as well as the log — pull request #326 (https://github.com/radixdlt/radix-dapp-toolkit/pull/326) , a community patch making the Radix Connect (/contents/tech/core-protocols/radix-connect) Relay server URL configurable, was opened on 24 March 2026 and has neither been reviewed nor closed since, which makes an unmerged contribution the most recent thing to happen to the repository. On 7 August 2026 the position was stated directly in the Radix Developers channel (https://t.me/RadixDevelopers/65908) : the Radix Wallet (/contents/tech/core-protocols/radix-wallet) and Gateway (/contents/tech/core-protocols/radix-gateway-api) are maintained on a volunteer basis with bug fixes only, pending a community decision on direction — the same maintenance mode the Radix Foundation (/ecosystem/radix-foundation) entered in April 2026. The surrounding pieces are on the same footing: the Wallet Connector extension (https://github.com/radixdlt/connector-extension) last took a commit on 17 April 2026, and the Gateway service itself released v1.10.6 (https://github.com/radixdlt/babylon-gateway/releases) on 7 April 2026. Which of these the community DAO picks up is one of the open stewardship questions (/ideas/dao-steward-radix-wallet) . What this means for the scaffolding npx create-radix-app@latest still works, but it is older than it looks. The package (https://www.npmjs.com/package/create-radix-app) was last published in December 2024; it does not contain the templates itself, but clones them with degit (https://github.com/Rich-Harris/degit) from radixdlt/official-examples (https://github.com/radixdlt/official-examples) , whose last commit is January 2025. The dependency ranges are caret ranges (@radixdlt/radix-dapp-toolkit: ^2.1.1), so a fresh scaffold does install the current 2.3.0 — what is dated is the example code, not the version you get. In particular the templates predate the subintent and pre-authorization (/contents/tech/core-concepts/subintents-and-pre-authorizations) support that landed in 2.3.0, so sendPreAuthorizationRequest appears in no generated project. Scaffold for the wiring, then read the current library API rather than the template's. Next Steps - Gateway SDK: Reading Ledger State (/developers/frontend/02-gateway-sdk) – read balances, component (/contents/tech/core-concepts/components) state, and transaction status from your front end External Links - Radix dApp Toolkit – GitHub (https://github.com/radixdlt/radix-dapp-toolkit) - @radixdlt/radix-dapp-toolkit – npm (https://www.npmjs.com/package/@radixdlt/radix-dapp-toolkit) - Building a Frontend dApp – Official Docs (https://docs.radixdlt.com/docs/building-a-frontend-dapp) - Run Your First Frontend dApp – Official Docs (https://docs.radixdlt.com/docs/learning-to-run-your-first-front-end-dapp) - Radix Wallet SDK – GitHub (https://github.com/radixdlt/wallet-sdk) (archived August 2024 – superseded by the Radix dApp Toolkit (https://github.com/radixdlt/radix-dapp-toolkit) ; kept for historical reference) ## Radix Week in Review: A Test Network Replays Fifteen Months in Two Hours URL: https://radix.wiki/blog/week-in-review-2026-08-30 Updated: 2026-09-06 Summary: Stokenet was rebuilt from scratch and caught up on three protocol updates in under two hours, work that took mainnet 315 days. It did that because an… Week of 24 – 30 August 2026 Top story A rebuilt test network re-applied fifteen months of protocol history in one evening The week in brief - Stokenet (/contents/tech/releases/stokenet) was rebuilt from scratch and caught up on three protocol updates in under two hours, work that took mainnet 315 days. - It did that because an update is gated by a stake threshold rather than a date, and one person held all four validators on the new network. - The DAO moved its governance repository off a personal account onto its own, and switched on radixdao.org as its official venue. - Its lawyers agreed amended terms with MIDAO; the filing for RADIX DAO LLC begins on Monday, and the registry takes four to six weeks after that. - 349 commits landed across the tracked repositories, all from one person, and none in the three repositories under the company's own name. - Six validator fee rises are queued on the ledger, the first landing today, with about 337 million XRD of stake behind them. Fifteen months of protocol history in one evening Radix's public test network went down at 07:00 UTC on Saturday and came back just before one o'clock on a fresh start with four validators, the first full reset in three years. Daffy, who has hosted most of the community-run network since the Radix Foundation (/ecosystem/radix-foundation) handed it over, gave a day's notice in the developer chat and eleven days' in the main group. Every balance, package and transaction from before is gone; account addresses, the network identifier and the Gateway address are not. Keeping the network identifier made it awkward. The starting state for that network is compiled into the node software with no way to override it, so reusing the name meant changing the software: a two-line overlay replacing one file, with everything else left as the official release. The published install instructions no longer work without extra steps. The consequence appeared two hours after relaunch. A developer published a package without trouble, then found that anything referring to the AccountLocker component came back as though that component were not on the ledger. It was not. AccountLocker arrived with the Bottlenose protocol update, and the reset network had restarted at the very beginning, behind every update Radix has ever shipped. It had to catch up the way mainnet did, one update at a time. Each update commits as a transaction, so the Gateway records exactly when it landed. On the reset network Anemone landed at epoch 105, Bottlenose at 117 and the first part of Cuttlefish at 135, all three inside two hours on Saturday evening. On mainnet the same three sit at epochs 70,574, 105,352 and 160,922, dated February, June and December 2024, with 315 days between the first and the last. RADIX WIKIFifteen Months in an Evening29 AUGUST 2026THE SAME THREE PROTOCOL UPDATES, ON TWO NETWORKSRadix mainnet315 daysAnemoneepoch 70,574Feb 2024Bottlenoseepoch 105,352Jun 2024Cuttlefishepoch 160,922Dec 2024Reset Stokenet1 h 52 mAnemoneepoch 10519:26 UTCBottlenoseepoch 11720:16 UTCCuttlefishepoch 13521:18 UTCAn update enacts once validators holding 80% of the stake have signalled readiness forten epochs running. On the reset network one person held all four validators.Enactment epochs read from the Radix Gateway on both networks, 30 August 2026.radix.wiki The same three updates: 315 days on mainnet, under two hours on a four-validator test network. The speed reflects who held the validator badges. Applying an update takes a threshold rather than a date or a switch: it enacts at the start of an epoch, once validators holding 80% of the stake have signalled readiness for ten epochs running. Four validators behind a single owner badge clear 80% between them. Asked in the developer chat whether they had to signal at all, the operator said the last badge had never been handed over, so the holding was 100% against a requirement of 80% and the update was going through either way. It stopped at the first part of Cuttlefish; the second part is unshipped on mainnet, and the operator said that decision was not one person's to make. The round counts show something else. Radix has no block time; it counts rounds, and an epoch ends on whichever comes first, a five-minute target or a ceiling of 3,000 rounds. Through Sunday morning the reset network averaged 3,004 rounds an epoch and about 220 seconds, so it is ending on the ceiling; mainnet over the same hours averaged 1,601 rounds and 300 seconds, which is the target. Four validators sitting close together get through rounds faster than a busy network does, and the operator expects epoch times to settle back as traffic returns. The DAO moves its papers out of a personal account On Friday the governance repository moved off Daffy's personal GitHub account to the DAO's own organisation, and radixdao.org was switched on as the official venue, deployed automatically from that repository. It changes nothing anyone can measure today, and it is probably the most consequential thing that happened to the DAO this week: an organisation keeping its rules in an account one person controls has not separated the rules from the person, which is precisely what the framework it is drafting exists to do. The paperwork moved the same day. The Radix Accountability Council (/ecosystem/radix-accountability-council) reported that it and its lawyers had reviewed the MIDAO service agreement, proposed amendments and had them accepted. Payment follows, then the submission of RADIX DAO LLC to the Marshall Islands government, starting Monday. The council was careful about what comes next: the filing has several steps, it is not yet at the point where the clock starts, and the certificate takes the registry four to six weeks once it is. The governance index now lists 27 documents: 26 read "signed, awaiting ratification", one is pending, and the page says in its own words that nothing there is in force. Each signed document is published as a PDF whose fingerprint is recorded in the ratification proposal, so a member can check their own copy. The phase at the top of the page reads pre-formation, ratification starts with a discussion period on the forum, and no date has been set for it. A signed constitution nobody has voted on, a company with no certificate, and a council whose permanent members have not been elected. One contributor, 349 commits, and the cost nobody charges for Across the five repositories this series tracks, the seven days to 30 August produced 349 commits over 385 files, and every one is flightofthefox's. The new virtual machine took 338 of them across five days; hyperscale-rs (/contents/tech/research/hyperscale-rs) took 11, mostly bumping the version of the engine it depends on. The three repositories under the company's own name recorded nothing at all. On Thursday the subject was fees, and specifically what Radix does not currently charge for. A developer asked why minting a million NFTs runs to tens of thousands of XRD in batches of twenty, and whether the new engine could lift the limit. The answer went past the limit to the accounting behind it. Hyperscale will meet that with state bonding, closest in shape to Sui's among the networks that already do this. The reasoning matters more than the mechanism: in a sharded system whose security rests on shuffling validators between shards, state has to move whenever the assignment changes, so bloating state is close to the most expensive thing a user can do to a network that never charged them for it. A transaction size ceiling of about one megabyte was defended in the same thread as a deliberate choice, on the grounds that sizing everything around hundred-megabyte edge cases makes the system worse for everyone else. The Radix Engine (/contents/tech/core-protocols/radix-engine) prices execution and storage at the moment of writing and nothing thereafter, and that is being replaced rather than tuned. None of it is shipped, and the same developer said this week that the engine is not yet safe to build against. Fees with a date on them Six fee changes are queued on the ledger and the first lands today. StakeSafe (/ecosystem/stakesafe) has rises on three of its own validators, and the node it bought from Avaunt Staking (/ecosystem/avaunt-staking) on 21 August carries a fourth. Validator Fee Effective epoch Stake exposed StakeSafe Amsterdam 15% to 25% 339,608 76M XRD StakeSafe Rotterdam 15% to 25% 339,609 81M XRD StakeSafe Seed Node 15% to 100% 339,609 0.2M XRD Leaf Node 1% to 100% 341,223 26M XRD Apollo Pool 20% to 100% 342,116 12M XRD ShardSpace.app, formerly Avaunt Staking 2% to 25% 342,482 142M XRD A fee change is announced to the ledger before it takes effect, so anyone reading the pending field has about a fortnight to move their stake. Meanwhile 77 validators charge a fee that differs from the one stored in their own record, 58 of them active with 2.88 billion XRD behind them, because the engine records a change as a request with an effective epoch and never rewrites the stored figure. Any dashboard reading the wrong field shows the old number forever. CaviarNine (/ecosystem/caviarnine) 's two validators, unmentioned in its departure notice, were still registered and still charging nothing at the end of the week. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 30 August 2026, epoch 339,497, against the same reading a week earlier. Metric This reading On the week XRD staked 4.92 billion up 31 million, or 0.6% Validators in the active set, of those registered to be 100 of 179 unchanged Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.57% down 0.19 points Validators charging a fee that differs from the one they publish 77 down 1 Stake recovered the previous week's fall. Ociswap (/ecosystem/ociswap) 's seven-day volume fell 45%, which is the number that will read differently in a month. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. The six queued fee rises above are the mechanism that moves this number, and by the next reading the first three will have taken effect. RADIX WIKIWho Holds the Stake30 AUGUST 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.57% between them.The 100 validators in the active set, read at state version 557,218,805.radix.wiki 8 validators hold a third of the stake between them. The ledger Nothing new came due. The three open claims were re-read rather than left dated: StakeSafe's three queued rises are still queued and none withdrawn; CaviarNine's two validators are still registered, still accepting stake and still charging nothing; and the DAO's governance index has gone from 24 documents to 27 with none in force, which leaves that claim untouched. Two claims are recorded this week: that the Marshall Islands issues a certificate of formation for RADIX DAO LLC by 25 October, checkable against the council's notices and the registry; and that the new virtual machine records at least 200 commits in the fortnight from 31 August, checkable with one GitHub call against a baseline of 338 in the week just ended. Both are on the series page (/blog/week-in-review) . This week on the wiki Read Stokenet (/contents/tech/releases/stokenet) . The article now carries the reset as a dated operational record rather than a description of a service: what went down and when, what came back, what an account holder found in the wallet afterwards, and what a developer has to redo. It answers what the developer chat kept asking all weekend, in one account rather than four hundred messages. What to watch - Epochs 339,608 and 339,609, today. Two StakeSafe validators go to 25% and the seed node to 100%. Read the fee actually charged, not the stored figure, which will still say 15% afterwards. - The Marshall Islands filing starting Monday, and whether the clock the council described actually starts. - Whether anything lands in the company's own repositories, which recorded nothing this week. Corrections Nothing this week. Next: the first three fee rises take effect, and the Marshall Islands filing either starts its clock or does not. References: 1. Radix documentation, how a protocol update is enacted (https://docs.radixdlt.com/docs/node-protocol-updates) 2. Radix Gateway, ledger state read at epoch 339,497 on 30 August 2026 (https://mainnet.radixdlt.com/status/gateway-status) 3. radixdao.org, the DAO's official venue (https://radixdao.org/) 4. radixdao.org, the governance document index (https://radixdao.org/govern/) 5. babylon-node on GitHub (https://github.com/radixdlt/babylon-node) 6. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 7. Ociswap (https://ociswap.com/) 8. Stokenet on this wiki (/contents/tech/releases/stokenet) 9. The Radix Accountability Council on this wiki (/ecosystem/radix-accountability-council) 10. RadixTalk, the governance category (https://radixtalk.com/c/governance) 11. Radix developer documentation (https://docs.radixdlt.com/) 12. Radix Knowledge Base (https://learn.radixdlt.com/) 13. radixdlt on GitHub (https://github.com/radixdlt) 14. The Radix Dashboard (https://dashboard.radixdlt.com/) 15. The Radix Foundation blog (https://www.radixdlt.com/blog) 16. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 17. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #10: ← Previous: Issue #9, Aug 17–23, 2026 (/blog/week-in-review-2026-08-23) · Next: Issue #11, Aug 31 – Sep 6, 2026 → (/blog/week-in-review-2026-09-06) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: The largest builder on Radix is winding down but leaving its code running, and a validator changed hands in a single transaction that could not half-complete. ## Radix Week in Review: CaviarNine Leaves, and Its Contracts Stay Live URL: https://radix.wiki/blog/week-in-review-2026-08-23 Updated: 2026-09-06 Summary: CaviarNine , the largest builder on Radix, is winding down after five years. Its contracts stay live on the ledger; what closes is its website. Avaunt… Week of 17 – 23 August 2026 Top story CaviarNine is leaving Radix, and leaving its contracts running The week in brief - CaviarNine (/ecosystem/caviarnine) , the largest builder on Radix, is winding down after five years. Its contracts stay live on the ledger; what closes is its website. - Avaunt (/ecosystem/avaunt-staking) sold its validator to StakeSafe (/ecosystem/stakesafe) for about 1.46 million XRD, in a single transaction that could not half-complete. - Because a fee rise has to be announced on the ledger in advance, the people staked with that validator got notice without anyone telling them. - The Hyperscale repositories had their heaviest week yet, and the sharded engine can now stand up its own staking system. - A benchmark put the new engine 20 times faster than the Radix Engine on one core, with a caveat its author wrote down himself. - Stokenet (/contents/tech/releases/stokenet) is wiped and restarted on 29 August. Account addresses survive it, because they were never stored on the network. CaviarNine is leaving, and its code is not On 19 August, five years to the day after minting the first utility token on Radix, CaviarNine said it is winding down its projects and leaving the network. The team found Radix in 2017, ran validators from the Olympia launch in July 2021, and built most of what people used: the aggregator, the on-chain order book, Shape Liquidity, the LSU Pool, instant unstaking, JustLock, and Surge, the network's first perpetual exchange. By value held and by volume traded it was the largest thing anyone had built here. The reason given was that the economics of operating on Radix no longer work, and that the network is a long way from what the team signed up for. The wind-down runs in stages. The exchange website becomes withdraw-only, so people can take their positions out and do nothing else. Surge unwinds on an announced date, and collateral left unclaimed afterwards will be moved to Ethereum and held there to be claimed later. JustLock is unaffected, and the announcement says why: it runs entirely on the ledger. That distinction is the whole of it. Anyone can build a front end against those contracts, now or in a year, and the pools keep working. A community member asked whether the administrative badges over the live components could pass to the Radix Accountability Council (/ecosystem/radix-accountability-council) , which has already set up a shared treasury account for exactly that kind of asset. CaviarNine said those badges touch fees and configuration and that it would come back with a considered answer rather than a quick one. That answer has not arrived. One part of the estate went unmentioned. CaviarNine-1 and CaviarNine-2 are the tenth and eleventh largest validators on Radix, holding about 235 million XRD between them, both charging nothing and neither carrying a pending change. That is 4.8% of all staked XRD sitting under an operator that has said it is leaving. Meanwhile the market it dominated carried on: Ociswap (/ecosystem/ociswap) settled 8,455 swaps in the seven days to Thursday, a third more volume than the week before. A validator sold in one transaction Avaunt announced on Friday that its services would move to StakeSafe on 28 August, with nothing required from anyone staked with it. The ledger had already done the work. Thirteen minutes before the post, a transaction moved the validator's owner badge into the account that has held StakeSafe Amsterdam's badge since the beginning. On Radix a validator's authority lives in a badge, and a badge sits in an account like any other asset, so a node changes hands the way a painting does. It was a sale, and the transaction says so: StakeSafe paid about 1.5 million XRD, the Avaunt account received about 1.46 million and released the badge, and the difference went to the fee component of Atomix, a peer-to-peer trading application, which also paid the network fee of under one XRD for the whole thing. Atomix settles trades using subintents, and this is what one looks like at size. The buyer signs a partial transaction and so does the seller, and neither can execute on its own. A parent transaction pulls both in and states, before each hand-off, exactly what has to come back: this many XRD from one side, that one badge and nothing else from the other. If either statement turns out false the whole thing aborts and nothing moves. There is no escrow, no settlement period and no counterparty to trust, because it is one commit or none. Atomix is Avaunt's own product, so the developer who wrote the trading application used it to sell the largest thing he owned on the network. The people staked with that validator inherited a number. Avaunt is the eighth largest validator on Radix, with roughly 149 million XRD delegated to it at a 2% fee. StakeSafe's three validators charge 15% and have already filed to raise it, two to 25% and one to 100%, at epochs falling in the last days of August. Avaunt's own validator carries no fee change at all. What protects those delegators is built in rather than promised. On Radix a fee increase is a request: the owner records it on the ledger with the epoch it takes effect, and it sits there in the open until then. StakeSafe can raise the fee on its new node, but it cannot do it quietly and it cannot do it immediately. Anyone reading that one field gets the truth, and none of it depended on being told the node had been sold. Staking arrives in the sharded engine The Hyperscale repositories had their heaviest week yet, and most of it went one way. The stake pool became a single module on Sunday, the founding validators were seeded as a record the network reads at startup on Tuesday, and on Thursday a commit titled "Staking founds itself" closed the loop: the sharded engine can now stand up its own staking system from inside itself. A second thread is randomness, and its design is the interesting part. A draw takes its seed from a beacon that generated it in an earlier block, never from the block being executed, and each epoch folds its seed into a window a later draw can reach. A validator ordering the transaction that draws therefore cannot see or shift what it will produce. Babylon, the network running today, has nothing like it. A benchmark also appeared, timing 1,000 token transfers from distinct senders on a single processor core: 25,412 a second for the new engine against 1,253 for the Radix Engine (/contents/tech/core-protocols/radix-engine) , a factor of twenty. The caveat is in the repository's own README, and it matters: Hyperscale runs accounts as WebAssembly where the Radix Engine implements them natively, so the gap measures a difference in design as much as in tuning. The author called it early days in the same breath as posting it. On Saturday evening the channel turned to privacy. flightofthefox sketched shieldable assets as something an issuer opts into, with XRD itself left alone, taking the best available approach from elsewhere and adapting it. The argument for doing it on Radix is that shielding fits a multi-asset platform, where a single transaction could unshield from a pool and do a dozen other things at once. No milestone carries it and no code implements it. Stokenet is deleted on Saturday week Stokenet, the public test network, goes down at 07:00 UTC on Saturday 29 August and comes back from scratch. The cause is size: the ledger is growing at an estimated 320 GB a year against 110 GB in previous years, and nobody knows what changed. The operator plans to repeat the exercise every nine to twelve months. Everything on it goes: balances, transactions, resources, packages, components, application definitions and stored persona data. Four things survive, and the fourth is the interesting one: the network identifier, the Gateway address, the well-known addresses, and your own account address. A Radix account address is derived from your key rather than recorded against your name, so a total deletion of the network's state cannot reach it. Developers redeploy their code and refill from the faucet; nobody has to re-derive an address. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 23 August 2026, epoch 337,481, against the same reading a week earlier. Metric This reading On the week XRD staked 4.89 billion down 93 million, or 1.9% Validators in the active set, of those registered to be 100 of 179 unchanged Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.76% down 0.1 points Validators charging a fee that differs from the one they publish 78 down 3 Stake fell by 93 million XRD over the week, and a third of that came from one validator: CaviarNine-1 alone shed 28 million. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake23 AUGUST 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.76% between them.The 100 validators in the active set, read at state version 553,723,197.radix.wiki 8 validators hold a third of the stake between them. The ledger Nothing came due this week. The StakeSafe fee rise and the Radix DAO's first ratified document both resolve in September and stay open. Two new claims are recorded. First, that StakeSafe files a fee change on the Avaunt validator raising it above 2%, due 20 September; the validator currently reads 2% with no request pending, so one Gateway read settles it. Second, that CaviarNine's two validators are transferred, deregistered or have a fee change filed against them, due 4 October; both currently sit registered at zero with nothing pending. The running table is on the series page (/blog/week-in-review) . This week on the wiki CaviarNine (/ecosystem/caviarnine) for what is closing and what is not, and Avaunt Staking (/ecosystem/avaunt-staking) for the validator that changed hands. What to watch - What happens to CaviarNine's two validators, holding 4.8% of all staked XRD under an operator that is leaving. - Whether the administrative badges pass to the council, which CaviarNine said it would answer properly. - Stokenet coming back on 29 August, and how much of the ecosystem redeploys onto it. Corrections Nothing this week. Next: whether CaviarNine says anything about its validators, and whether Stokenet comes back on time. References: 1. Radix Gateway, ledger state read at epoch 337,481 on 23 August 2026 (https://mainnet.radixdlt.com/status/gateway-status) 2. The Radix Dashboard, for the validator sale transaction (https://dashboard.radixdlt.com/) 3. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 4. hyperscale.rs, the project site and browser demo (https://hyperscale.rs/demo) 5. CaviarNine on this wiki (/ecosystem/caviarnine) 6. Avaunt Staking on this wiki (/ecosystem/avaunt-staking) 7. StakeSafe on this wiki (/ecosystem/stakesafe) 8. Stokenet on this wiki (/contents/tech/releases/stokenet) 9. Ociswap, where the week's swap volume was settled (https://ociswap.com/) 10. Zcash, the shielded-asset design referred to (https://z.cash/) 11. RadixTalk, the governance category (https://radixtalk.com/c/governance) 12. Radix developer documentation (https://docs.radixdlt.com/) 13. Radix Knowledge Base (https://learn.radixdlt.com/) 14. radixdlt on GitHub (https://github.com/radixdlt) 15. The Radix Dashboard (https://dashboard.radixdlt.com/) 16. The Radix Foundation blog (https://www.radixdlt.com/blog) 17. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 18. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #9: ← Previous: Issue #8, Aug 10–16, 2026 (/blog/week-in-review-2026-08-16) · Next: Issue #10, Aug 24–30, 2026 → (/blog/week-in-review-2026-08-30) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: Radix accounts gained a third signature scheme, one built to survive quantum computers, and the DAO began recording a checkable fingerprint of every governance document. ## Radix Week in Review: A Post-Quantum Signature Lands in the New Engine URL: https://radix.wiki/blog/week-in-review-2026-08-16 Updated: 2026-09-06 Summary: The new Hyperscale virtual machine gained ML-DSA-65, a signature scheme designed to survive quantum computers; 33 minutes later the consensus layer co… Week of 10 – 16 August 2026 Top story The new virtual machine gained a signature scheme a quantum computer cannot break The week in brief - The new Hyperscale virtual machine gained ML-DSA-65, a signature scheme designed to survive quantum computers; 33 minutes later the consensus layer could sign and verify with it. - It is the third scheme a Radix account can use, and an account can adopt it without changing its address. - Most of the week's 206 commits changed what holding a key entitles you to: a key signs you in, and a badge opens the guarded parts of an account. - The DAO's transition council broke a 34-day silence: the Foundation has approved the operating agreement and paid the second grant instalment, so nothing waits on the Foundation now. - The DAO's site now records a fingerprint of each governance document on the ledger, so any member can check their own copy is the one that was voted on. - All 24 of those documents are still drafts, and nobody has called the first vote. At 02:45 UTC on Sunday the new virtual machine registered ML-DSA-65 among the signature schemes a Radix account may use, and half an hour later the consensus layer could sign and verify transactions with it. A signature scheme is the mathematics that lets you prove you authorised something without revealing your key. The ones in use today, including the two Radix accepts, rest on a problem that a large quantum computer would be good at solving. ML-DSA rests on a different one, based on lattices, that quantum computers are not known to break; the United States standards body published it as FIPS 204 (https://csrc.nist.gov/pubs/fips/204/final) , and the 65 names the middle of its three parameter sets. Babylon accepts two schemes today: Ed25519, and the secp256k1 it inherited from Olympia (/contents/tech/releases/radix-mainnet-olympia) , the first version of Radix. This makes a third. It matters that an account can switch without moving, and it can, because the mechanism that changes an account's rules leaves the key that originally named it alone. Governance could retire the older schemes if a quantum computer ever looked close, and the developer's sketch of how to do that safely was to let a legacy account change its rules and do nothing else, so the only remaining move is the safe one. The channel immediately compared it to a NEAR announcement from the same week. The lead developer played it down: post-quantum work belongs to no milestone because it cuts across all of them, and signing a transaction is the easy part. The hard part is the consensus layer's own signing and verification, which pulls in zero-knowledge proofs and hash-based schemes. One consequence is worth marking for anyone holding an old account: addresses may change at the upgrade whatever scheme they use, because the sharded design gives an account and its vaults a single shared prefix, where today they scatter across the shard space and every transaction touching them drags in extra shards. A key gets you in; a badge opens the safe Sixty-three commits landed in the virtual machine this week and 143 in the consensus layer around it, and nearly all of the first group answer one question: what makes a call allowed? Most of this industry answers that the signature is the authority, so signing with the right key opens every door in the account. Radix has never quite worked that way. It treats permission as a thing you hold: an account holds a badge and presents it inside the transaction, where the rest of the network can watch it do so. A commit on Wednesday states the new rule in a line: a signature signs you in and nothing more; guarded methods take badges. The pieces arrived in order. On Tuesday the engine learned to express an authority rule as a threshold over identities, such as two of these three or any one of those, and to mint an account's identity as evidence later calls must present. On Wednesday an account's stored rule became the thing that governs who may act on it, so the key that first named the account no longer decides. Two more landed the same day: a recovery arrangement with three roles and a timed proposal, so a lost key costs the owner time rather than the account; and a rule making simple possession of a badge a third way to prove you may act. Stake pools were given owner badges at the start, and the operator interface now refuses anyone who cannot show one. The same idea underpins ROLA (/developers/frontend/03-rola-authentication) , which is how a wallet proves who holds it to a website without a transaction. The consensus layer spent the same days demanding paperwork at every seam: a shared verdict binds a transaction's payer before anything is charged; a shard refuses a payer the transaction never bound to it; effects do not settle until every participating shard presents its certificate; and a node that lacks code a step depends on waits until it has fetched it. Thirty-four days, then an update On Wednesday a long-standing member of the main channel counted the days since the transition council had last told the community anything, and asked the question the council's own name invites: can the people it is accountable to understand the current state, the risks and the next steps without chasing it? The argument ran for two days and was the most-read thing in the ecosystem that week. One side held that five volunteers doing legal work in their evenings owe nobody a weekly report, and that shaming them is how you ensure nobody stands for the next council. The other held that a role with accountability in its title carries a minimum. Both sides argued in good faith about a real gap, and in the meantime two people outside the council, Timan and Daffy, published more about the DAO's machinery in a week than the council had in a month. The council posted on Thursday. The Foundation (/ecosystem/radix-foundation) has validated the proposed operating agreement and agrees it fits the goal of handing over the assets it holds; the second instalment of the setup grant has arrived, so the council can pay its expenses; and nothing now waits on the Foundation. Counsel expected to file the formal application within days. The charter is close to final, a vote will ratify it at a deliberately high threshold, and at least seven people intend to stand for the seven permanent seats. Twenty-four documents, none in force The machinery for checking those documents shipped on Friday. When a proposal activates a governance document, the DAO's site publishes it as a PDF and the proposal records the document's SHA-256 fingerprint on the ledger; the site then republishes that fingerprint. A member can hash their own copy and confirm it matches the file the DAO actually voted on. Superseded fingerprints are kept on purpose, so someone holding an old version learns that their copy is genuine but out of date rather than unrecognised, and nobody types a fingerprint by hand: the publishing process downloads the PDF, hashes it and cross-checks the result. Twenty-four documents sit there across ten categories, and every one reads pending. Nothing is in force, and nobody has called the first vote, which is the ratification of the charter. The verification page tells the same story on the ledger: the governance contract, the master badge, the owner badge and the governance package are all live and linked, XRD is the resource that carries voting power, and the DAO has yet to deploy any of its five treasury accounts. The smaller work continued around it. The framework tightened its election rules against edge cases and added a compensation regime for contributors with requests, renewals and challenges. Majority Judgment, in which every voter grades every candidate and the best median grade wins, became the default election method. The on-chain addresses moved into the charter itself, so they change only when the charter changes. The governance repository still sits under a personal account and is due to move to the DAO's own organisation, and radixdao.org now stands as the interim official venue. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 16 August 2026, epoch 335,465, against the same reading a week earlier. Metric This reading On the week XRD staked 4.98 billion up 22 million, or 0.4% Validators in the active set, of those registered to be 100 of 179 unchanged Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.86% up 0.09 points Validators charging a fee that differs from the one they publish 81 up 1 Stake up 22 million XRD, and for the first time in this series no fee changes at all were queued on the ledger. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake16 AUGUST 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.86% between them.The 100 validators in the active set, read at state version 550,418,532.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki Radix governance (/contents/tech/core-concepts/radix-governance) for how the charter, the council and the contract fit together, and hyperscale-rs (/contents/tech/research/hyperscale-rs) for the engine work underneath the signature scheme. What to watch - The first vote being called, which would be ratification of the charter and the first thing the governance contract has ever processed. - The formal incorporation application, which counsel expected to file within days. - Whether the governance repository moves off a personal account and onto the DAO's own. Corrections Nothing this week. Next: whether anyone calls the first vote, and whether the incorporation application actually goes in. References: 1. NIST, FIPS 204, the ML-DSA signature standard (https://csrc.nist.gov/pubs/fips/204/final) 2. radixdao.org, the DAO's interim official venue (https://radixdao.org/) 3. radixdao.org, the governance document index (https://radixdao.org/govern/) 4. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 5. Radix Gateway, ledger state read at epoch 335,465 on 16 August 2026 (https://mainnet.radixdlt.com/status/gateway-status) 6. Radix governance on this wiki (/contents/tech/core-concepts/radix-governance) 7. The Radix Accountability Council on this wiki (/ecosystem/radix-accountability-council) 8. RadixTalk, the governance category (https://radixtalk.com/c/governance) 9. Radix developer documentation (https://docs.radixdlt.com/) 10. Radix Knowledge Base (https://learn.radixdlt.com/) 11. radixdlt on GitHub (https://github.com/radixdlt) 12. The Radix Dashboard (https://dashboard.radixdlt.com/) 13. The Radix Foundation blog (https://www.radixdlt.com/blog) 14. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 15. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #8: ← Previous: Issue #7, Aug 3–9, 2026 (/blog/week-in-review-2026-08-09) · Next: Issue #9, Aug 17–23, 2026 → (/blog/week-in-review-2026-08-23) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: The Rust rebuild finished its first milestone, the execution engine that sits on top of it became public code, and Scrypto survives the change. ## Radix Week in Review: Milestone 1 Done, and the New Engine Goes Public URL: https://radix.wiki/blog/week-in-review-2026-08-09 Updated: 2026-09-06 Summary: hyperscale-rs finished its first milestone, covering validator lifecycle, consensus, and shards that split and merge while the network keeps running.… Week of 3 – 9 August 2026 Top story Milestone 1 finished, and the new execution engine became public code The week in brief - hyperscale-rs (/contents/tech/research/hyperscale-rs) finished its first milestone, covering validator lifecycle, consensus, and shards that split and merge while the network keeps running. - The execution engine that will sit on top of it went public eight days after its first commit: 259 files of Rust, and a README that opens by telling you not to use it yet. - Scrypto (/contents/tech/core-protocols/scrypto-programming-language) survives the change of engine; what changes is underneath it. - A Hyperscale validator should run on a Raspberry Pi, and there is no slashing in the design: cheating impounds your stake for 90 days rather than burning it. - Someone published 38 reference guides for AI coding agents, and a community member used them to put an escrow contract on mainnet in an afternoon. - The DAO's governance contract is live on mainnet with real addresses, and all three of its counters read zero. The milestone, and what it covered Milestone 1 covers the validator lifecycle, the consensus engine, and dynamic sharding, which lets shards split and merge as load changes without the network stopping. The last piece to land was committee rotation: when a shard's set of validators changes, seats are replaced one at a time rather than all at once, so the new one is in place before the old one goes. Two items were deferred, chiefly the ability to split a shard because of fee pressure rather than because it has accumulated bytes, and both wait on the fee system, which in turn waits on the layer above. The new engine, in public That layer arrived on Friday evening as a link: 259 files of Rust across twelve crates, 133 commits, dual-licensed Apache-2.0 and MIT, eight days from first commit to a public repository with a working reference interpreter in it. Its design idea is that a transaction should declare what it touches instead of being run to find out. On Radix today the only reliable way to learn what a transaction affects is to execute it and watch, which is fine on a single shard and fatal across many, because the network has to know which shards are involved before it can schedule anything. The new engine moves that answer to the front: one function reads a transaction's instructions and returns the shards involved, the state each will touch, and how it will be touched, with no execution and no reading of state. A queue of pending transactions can be scheduled from that; a proposer can budget from it; the preview a Radix wallet shows before you sign comes from the same read. If a contract then reaches for something it never declared, there is no handle for it to call and it fails on the spot. The payoff is in the locking. Instead of locking a whole object, the engine has five kinds of access and a table of which ones can safely run together: reads share with reads, and increments and reservations commute, so a thousand deposits into one vault stop forming a queue and become a single parallel group. Nothing is executed speculatively and nothing is rolled back, because the conflicts fall out of the declarations. Every transaction profile is then executed twice, by a pinned version of the standard runtime and by a reference interpreter written independently from the specification, and the two are compared. A disagreement blocks the release whichever side turns out to be wrong. That is a check the engine cannot outrun, wired in by the people building it. Scrypto survives, which was the biggest open question for builders since the Radix Engine (/contents/tech/core-protocols/radix-engine) was ruled out for sharding the week before. The answer on Monday was that Scrypto is a couple of Rust macros, that reaching parity is not hard, and that the parts developers actually handle, such as manifests, resources, subintents and badges, are considered good and stay. What changes is beneath them: state, locking and parallelism. Existing contracts face a recompile at best and an automated conversion tool at worst. What a validator seat will cost Asked whether a Hyperscale node could run on a Raspberry Pi 5 with a fast disk, the answer was almost certainly, and possibly several on the same board: under a tenth of one processor core, around 200 MB of memory, and storage bounded by how often shards split. A Babylon node today wants a server. That single fact does more to decide who is allowed to run this network than any policy document. The penalties match. There is no slashing anywhere in the design. Go offline or fall behind and your seat is jailed until you bring it back. Do something provably dishonest, such as voting two ways or issuing two proposals for the same round, both of which require deliberately modifying the software, and your stake is impounded for 90 days: locked, not burned, with the period set by governance. That distinction matters most to people who never touch a machine, because someone who staked with the wrong operator loses access for a season and keeps their money. Delegation shifts too, from backing one validator towards backing a pool that may run several, and if more machines turn up than the network needs, the price of a seat rises until the surplus leaves. An afternoon to mainnet On Thursday a former lead of Radix's application engineering team published what he knew in a form an AI coding agent can read: 38 reference guides covering transaction manifests, Scrypto, the Gateway (/contents/tech/core-protocols/radix-gateway-api) , ROLA (/developers/frontend/03-rola-authentication) , subintents, pools, royalties, fees and data encoding, bundled so the agent clones the real Radix sources and works against them rather than inventing an interface that never existed. It is the cheapest available fix for the hardest problem a small ecosystem has, which is that these models have read every line of Solidity ever written and almost no Scrypto. The demonstration came the same day. A community member pointed an agent at it and about three hours later had Trade Vault, a person-to-person escrow, with contracts deployed to mainnet and a wallet flow attached. It carries a use-at-your-own-risk warning and it duplicates something another project already does, which is beside the point: the limit on how much gets built on Radix has always been how many people know how to build it, and that limit moved. Three counters, all zero On 7 August the DAO's on-chain identifier policy replaced its placeholders with real mainnet addresses, and because addresses can be checked, this wiki checked them. The governance component is live and running the code the policy names. Its three counters, for temperature checks, proposals and council elections, all read zero. Every governance path in the framework routes through a contract that is deployed, correct, and has processed nothing. The rest of the week rhymed with that. Asked whether he was in touch with the Accountability Council (/ecosystem/radix-accountability-council) about signing off Milestone 2, the hyperscale-rs developer said there is no Council to be in touch with. A transitional council does exist and has not been idle: it retained lawyers, drafted the DAO's operating agreement and charter, and put two proposals to a vote on 28 July. Its job is to form the company and take the handover, not to approve engine milestones. The permanent elected body that would do that does not exist, and until a voting application capable of running an election appeared on 4 August there was no way to elect it. The wallet and the Gateway are in maintenance mode until the community picks a direction and votes it through, and the route to picking one runs from draft discussion to temperature check to proposal, with nothing currently in flight. The Radix Foundation (/ecosystem/radix-foundation) blog has published nothing since 28 April. Into that gap, on Saturday, a team published a governance design of its own, with a hash-pinned tally document and an independent verifier. It drew real technical questions and one objection of principle: that the useful half could have arrived as a change to the voting application the DAO already runs, without standing up a second system underneath the vote. Both sides argued from an operating agreement that is still a draft. The most telling conversation happened on Sunday and had no announcement attached. Someone asked what is actually left in the treasury the DAO is about to inherit, and nobody could say. So the channel costed out survival instead: how many validators does the network strictly need to keep producing blocks, which they put at four, and who would run them for nothing. The Gateway is paid for to the end of 2026. One member pointed out that he already runs five validators, two of them taken on when DeXter and HUG collapsed. An hour of arithmetic produced a workable answer. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 9 August 2026, epoch 333,449, against the same reading a week earlier. Metric This reading On the week XRD staked 4.96 billion up 20 million, or 0.4% Validators in the active set, of those registered to be 100 of 179 unchanged Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.77% down 0.04 points Validators charging a fee that differs from the one they publish 80 up 3 Stake up 20 million XRD, and three more validators charging a fee that differs from the one they publish. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake9 AUGUST 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.77% between them.The 100 validators in the active set, read at state version 547,781,942.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki hyperscale-rs (/contents/tech/research/hyperscale-rs) for what Milestone 1 covers, and Radix governance (/contents/tech/core-concepts/radix-governance) for why a deployed contract with three zero counters is the state of play rather than a glitch. What to watch - Whether any of the three counters moves off zero, which is the only evidence the governance machinery works. - An answer on what the treasury holds, before the vote that hands it over. - A second contributor on the new engine, which currently has one. Corrections Nothing this week. Next: the activation vote, with the two numbers that decide it, what the treasury holds and what a year of running a DAO costs, both still unwritten. References: 1. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 2. hyperscale.rs, the project site and browser demo (https://hyperscale.rs/demo) 3. Radix Gateway, ledger state read at epoch 333,449 on 9 August 2026 (https://mainnet.radixdlt.com/status/gateway-status) 4. Radix Foundation, moving to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) 5. RadixTalk (https://radixtalk.com/) 6. hyperscale-rs on this wiki (/contents/tech/research/hyperscale-rs) 7. Scrypto on this wiki (/contents/tech/core-protocols/scrypto-programming-language) 8. Radix governance on this wiki (/contents/tech/core-concepts/radix-governance) 9. RadixTalk, the governance category (https://radixtalk.com/c/governance) 10. Radix developer documentation (https://docs.radixdlt.com/) 11. Radix Knowledge Base (https://learn.radixdlt.com/) 12. radixdlt on GitHub (https://github.com/radixdlt) 13. The Radix Dashboard (https://dashboard.radixdlt.com/) 14. The Radix Foundation blog (https://www.radixdlt.com/blog) 15. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 16. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #7: ← Previous: Issue #6, Jul 27 – Aug 2, 2026 (/blog/week-in-review-2026-08-02) · Next: Issue #8, Aug 10–16, 2026 → (/blog/week-in-review-2026-08-16) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: A sharded Radix network now runs in a browser tab, and Hyperscale will get a purpose-built virtual machine rather than reusing the Radix Engine. ## Radix Week in Review: Hyperscale Gets Its Own Virtual Machine URL: https://radix.wiki/blog/week-in-review-2026-08-02 Updated: 2026-09-06 Summary: You can now open a sharded Radix network in a browser tab, running the real node software, and watch a transaction go through it. Hyperscale will not… Week of 27 July – 2 August 2026 Top story Hyperscale gets a purpose-built virtual machine instead of the Radix Engine The week in brief - You can now open a sharded Radix network in a browser tab, running the real node software, and watch a transaction go through it. - Hyperscale will not reuse the Radix Engine (/contents/tech/core-protocols/radix-engine) . A purpose-built virtual machine is being written instead, decided at the design stage rather than after launch. - Existing applications will need at least a recompile, and at worst a tool that rewrites their source; there is no date for either. - Braided cross-shard voting, the mechanism the original Cerberus paper is known for, has been dropped in favour of shards exchanging proofs. - A community ambassador prepared submissions to register Radix in the cross-chain naming registry and in x402, the standard for machine-to-machine payments. - The community's own voting application settled its first two binding votes. The most useful thing anyone shipped this week is a link. On 27 July flightofthefox compiled the hyperscale-rs (/contents/tech/research/hyperscale-rs) node to WebAssembly and put a four-validator sharded network in a browser tab: open the demo, submit a transaction, and follow it across shards. It runs the actual node software, with only two substitutions: it keeps its data in memory rather than on disk, and it routes messages directly at a fixed 150 millisecond delay instead of over a real network. It is deterministic, so the same starting seed replays the same run exactly. Sharded consensus is usually a paper. This is a page you can pause. Underneath it, the project's thirteenth week on its first milestone produced 125 commits and the keystone of adaptive sharding: the precise moment a shard splits or merges is now decided by one tested and formally modelled path rather than several. A new virtual machine, decided early The Radix Engine runs every smart contract on Radix today. It will not run the sharded network. Asked on 1 August whether the engine was built for sharding, flightofthefox said it was not in the ballpark, and not in the same postcode as the ballpark; asked whether a new virtual machine made more sense than adapting the old one, he said it was already underway. The reason is state contention. Consensus and the Radix Engine each work well on their own; run together, they stall on transactions queuing for the same state locks, and sharding cannot make that queue shorter. Back in April the migration had three possible shapes, and two of them would have spared existing applications: leave deployed code untouched, or run the old environment alongside the new one. Both have now gone. What remains is a new execution layer plus a migration for everything already on mainnet. Asked what that costs a developer, the answer was a recompile at best and, at worst, an automatic tool that rewrites their source code. Asked twice whether Scrypto (/contents/tech/core-protocols/scrypto-programming-language) survives, the channel pointed back at that same answer. Neither carries a date. This changes what a vote is about. The Xi'an proposal asks the DAO to fund Hyperscale delivery, and the money now buys an execution layer written from scratch plus the migration of every application on mainnet, which is a different proposition from maintaining what Babylon shipped. The status card on this wiki was rewritten during the week to say so. Two design answers The beacon chain is the part that appoints every committee of validators. It never sees a transaction, so it does not cap throughput, and its resistance to censorship comes from its shape: unseating it means taking down more than a third of its committee, where designs with a single leader, such as MultiversX's metachain or NEAR's, present one machine to attack. The real ceiling sits elsewhere, in the gossip of block headers that authenticates the state every cross-shard execution depends on, and eventually in the speed of light. The second answer is a removal. Braided cross-shard voting, the mechanism the Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) paper is best known for, is out, on the grounds that it makes shards depend on each other to stay alive. Shards now execute independently and exchange proof that they did; when every shard involved holds every proof, the transaction commits. No votes cross between them. This wiki spent the week catching up. The hyperscale-rs article was reconciled against all nine design documents and went from version 4.10.1 to 5.0.1 across eighteen corrections, including a description of the transaction flow that still said two-phase commit and a claim of one-round finality that the project's own invariants contradict. It also now records finding G-1, a safety gap the project adjudicated against itself in its own specification: above the fault threshold, a retained committee with a corrupt majority can stretch the re-bind window and admit an orphaned commit past a halted tip. A project that writes its own open weakness into the register is telling you something useful about the register. Getting Radix named in other people's standards On 30 July the community ambassador avaunt proposed registering Radix in the Chain Agnostic namespaces registry (https://github.com/ChainAgnostic/namespaces) and adding it as a supported network in x402 (https://www.x402.org/) , the open standard for machine-to-machine payments over HTTP. The first gives every cross-chain tool a canonical way to name Radix chains, accounts and assets; the second puts Radix in the path of agent payments while that path is still being laid. The submissions went public on 1 August and can be reviewed now: naming profiles for chains, accounts and assets, and an exact-payment scheme forked from xStelea's original and realigned with upstream. Three pull requests are planned, for the specification, a reference implementation and a kit for developers. The machinery carrying that vote is itself new. The consultation application runs on mainnet, and it has now moved real decisions: two temperature checks, on continuing to operate Stokenet (/contents/tech/releases/stokenet) and on moving the website off Webflow, both passed and were lifted on 28 July into binding votes weighted by XRD, closing on 4 August. Its rough edges are being reported and fixed in the open, including a vote button that overflowed the page on Android and stopped people voting at all. An unpaid ambassador drafting standards documents, and a bug report about a button: that is what the handover looks like from the outside. Two operators published bad news The RadixPlanet validator had promised to cut its fee from 40% to 35% once the XRD price recovered. The price pulled back, the margin went with it, and the operator held the fee where it was and said so, rather than letting the promise lapse quietly. Muan Protocol paused its mainnet front end outright, citing almost no users, while it rebuilds around non-custodial snapshot voting, and is refunding anyone who paid fees on a first-version voting NFT. Nothing this week came from the Radix Foundation (/ecosystem/radix-foundation) , whose blog has published nothing since 28 April. The record now lives in a Telegram channel, a git repository, a voting application on the ledger and a handful of ambassador forks. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 2 August 2026, epoch 331,433, against the same reading a week earlier. Metric This reading On the week XRD staked 4.94 billion up 37 million, or 0.8% Validators in the active set, of those registered to be 100 of 179 unchanged Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.81% down 0.02 points Validators charging a fee that differs from the one they publish 77 unchanged Stake up 37 million XRD on the week, with everything else steady. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake2 AUGUST 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.81% between them.The 100 validators in the active set, read at state version 544,734,875.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki The hyperscale-rs (/contents/tech/research/hyperscale-rs) article is the one to read, having been rewritten against the design documents this week; and the Xi'an (/contents/tech/releases/radix-mainnet-xian) page for what the funding proposal now covers. What to watch - The two binding votes closing on 4 August, the first the new application has ever settled. - Any date for the new virtual machine, or for the migration tool developers would use. - The three standards pull requests, and whether they are accepted upstream. Corrections Nothing this week. Next: the first binding votes settle, and the new virtual machine still has no date. References: 1. hyperscale-rs, the sharded network demo (https://hyperscale.rs/demo) 2. hyperscale.rs, the project site (https://hyperscale.rs/) 3. The Chain Agnostic namespaces registry (https://github.com/ChainAgnostic/namespaces) 4. x402, the machine-to-machine payment standard (https://www.x402.org/) 5. The Cerberus whitepaper (https://arxiv.org/pdf/2008.04450) 6. Radix Gateway, ledger state read at epoch 331,433 on 2 August 2026 (https://mainnet.radixdlt.com/status/gateway-status) 7. hyperscale-rs on this wiki (/contents/tech/research/hyperscale-rs) 8. The Radix Engine on this wiki (/contents/tech/core-protocols/radix-engine) 9. Xi'an on this wiki (/contents/tech/releases/radix-mainnet-xian) 10. RadixTalk, the governance category (https://radixtalk.com/c/governance) 11. Radix developer documentation (https://docs.radixdlt.com/) 12. Radix Knowledge Base (https://learn.radixdlt.com/) 13. radixdlt on GitHub (https://github.com/radixdlt) 14. The Radix Dashboard (https://dashboard.radixdlt.com/) 15. The Radix Foundation blog (https://www.radixdlt.com/blog) 16. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 17. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #6: ← Previous: Issue #5, Jul 20–26, 2026 (/blog/week-in-review-2026-07-26) · Next: Issue #7, Aug 3–9, 2026 → (/blog/week-in-review-2026-08-09) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: Hyperscale's design was set against the standard list of sharding problems and answered point by point, and the Foundation put the DAO about a month out. ## Radix Week in Review: Hyperscale Answers the Sharding Questions URL: https://radix.wiki/blog/week-in-review-2026-07-26 Updated: 2026-09-06 Summary: The lead developer on hyperscale-rs worked through the standard list of hard sharding problems and answered each one against Hyperscale's design, in p… Week of 20 – 26 July 2026 Top story Hyperscale answered the standard sharding questions, one by one, in public The week in brief - The lead developer on hyperscale-rs (/contents/tech/research/hyperscale-rs) worked through the standard list of hard sharding problems and answered each one against Hyperscale's design, in public. - The same channels argued out what Hyperscale keeps from Cerberus, the original Radix consensus paper, and what it does not. - A proposal for penalising provable cheating would impound a validator's stake for a period rather than confiscate it. - The Foundation said the DAO is expected to launch in about a month, with the permanent council seated after it. - A four-part model for the handover circulated: milestone-based treasury releases, sub-DAOs, a legal wrapper, and three phases ending in the Foundation dissolving. - Radix Seal shipped: signing documents, encrypting files and private chat, all from a wallet signature and all in the browser. Most claims in this industry are made and never checked. The useful thing about this week is that two of Radix's were written out where anyone can mark them. Answering the sharding questions In December 2017 Vitalik Buterin published a Sharding FAQ, which became the standard catalogue of what makes splitting a blockchain into parallel slices hard: keeping a transaction that touches two shards all-or-nothing; making sure the data stays available; deciding which validators work on which shard; and stopping an attacker who takes over one shard from taking over the network. Nearly a decade later it is still the exam a sharded design has to sit. This week flightofthefox, who leads hyperscale-rs, went through it point by point against Hyperscale and posted the result for discussion; a community member reposted it to X, where it became the most amplified Radix post of the week. The central answer is the one Radix has given since the beginning. Conventional sharding makes you choose between shards passing each other messages and hoping, executing optimistically and rolling back when it goes wrong, or fencing applications into separate walled gardens so the problem never arises. Hyperscale keeps transactions atomic across shards instead: a transaction declares up front which state it touches, every shard that owns any of that state takes part, and the whole thing commits everywhere or nowhere. The claim is not new. Setting it beside the specific objections and answering them in order is. The channel did not treat any of it as settled. One long thread asked directly whether Dan Hughes's original consensus work had been abandoned. The answer that formed was that Hyperscale takes the principles of Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , the consensus design Radix was founded on, and adapts them to the current implementation and the goals of the Xi'an (/contents/tech/releases/radix-mainnet-xian) release, rather than reusing the old code; and that the original paper starts from a fixed set of validators and never addresses what happens when validators join and leave a running network, which is the problem a live system actually has. A second thread argued about penalties. If a validator can be proved to have cheated, by voting two ways on the same thing, should it lose its stake? The proposal that emerged was to impound the bonded stake for a fixed period instead: the operator loses the use of the capital rather than the capital itself, with the length of the impounding set by governance. Nothing there is decided. The developer also started writing up how Hyperscale is tested, aimed at the Rust community rather than at Radix holders: the architecture that keeps protocol logic separate from network plumbing, so it can be run without a network at all; a simulator that replays an entire network deterministically from a single seed, so a failure can be reproduced exactly; and the Quint (https://quint-lang.org/) models that let the consensus rules be checked by machine. Putting it in front of readers who did not arrive already interested is the same move as the FAQ comparison. The DAO gets a rough date On the developer channel, with the argument running in parallel on RadixTalk (/ecosystem/radixtalk) , the Radix Foundation (/ecosystem/radix-foundation) said the DAO is expected to launch in about a month, with the permanent Accountability Council (/ecosystem/radix-accountability-council) established and identity-checked after that. A date, even a rough one, changes every governance conversation from someday to soon. It also made the interim awkwardness concrete. The Foundation, in maintenance mode and with no marketing staff, spent part of the week deciding who should run its social accounts during the handover. The proposal was a narrow, vetted contract for a returning contractor to publish community-submitted posts under Foundation guidelines, because those accounts are Foundation property that will pass to the DAO and cannot be handed to an unvetted third party weeks before the transfer. It is a small question that shows the shape of the large one: an organisation designed to dissolve still has to hold the keys until the thing replacing it exists. A widely shared sketch set out four parts for the transition: a treasury that releases funds against milestone votes rather than in a lump; sub-DAOs that divide the work into specialised units, so holders vote on leadership and budgets instead of every line item, which is the usual remedy for people not turning out to vote; a legal wrapper along the lines of an unincorporated association, so the DAO can sign real contracts such as exchange listings; and three phases of handover ending with the Foundation dissolving. Underneath it sat a smaller and more immediate question. The volunteer who hosts Stokenet (/contents/tech/releases/stokenet) , the public test network, cannot keep paying for it indefinitely, and put continuation and compensation to a community vote. The framework that would decide such things is itself still in review. A wallet that signs more than transactions The clearest shipped work of the week was Radix Seal, released inside genkipool's community console. It uses ROLA (/developers/frontend/03-rola-authentication) , the scheme that lets a Radix wallet prove who holds it without a password, to do three things entirely in the browser: sign documents, encrypt files so only the recipient can read them, and hold a private one-to-one chat. The encryption keys are derived from a wallet signature, so no server ever holds the keys or the content, and a signature can optionally be recorded on the ledger as a non-transferable NFT to leave a permanent audit trail. It is a concrete answer to something ROLA has always implied and rarely shown at this reach: what a wallet is for once it is treated as an identity rather than a way to spend money. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 26 July 2026, epoch 329,417, against the same reading a week earlier. Metric This reading On the week XRD staked 4.90 billion up 50 million, or 1% Validators in the active set, of those registered to be 100 of 179 down 1 registered Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.83% down 0.11 points Validators charging a fee that differs from the one they publish 77 down 2 Stake up 51 million XRD on the week, and one validator off the registered list. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake26 JULY 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.83% between them.The 100 validators in the active set, read at state version 541,848,455.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki Read hyperscale-rs (/contents/tech/research/hyperscale-rs) alongside the FAQ comparison, and Radix governance (/contents/tech/core-concepts/radix-governance) for where the DAO and the council sit relative to each other. What to watch - Whether the DAO's one-month estimate survives the legal review still in front of it. - How the testing writeup lands with the Rust community, which did not come to be convinced. - The Stokenet funding vote, and what happens to the test network if it fails. Corrections Nothing this week. Next: whether the DAO date holds, and whether the sharding answers persuade anyone outside Radix. References: 1. Vitalik Buterin, Sharding FAQ, December 2017 (https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html) 2. The Cerberus whitepaper (https://arxiv.org/pdf/2008.04450) 3. Quint, the specification language used for the consensus models (https://quint-lang.org/) 4. Radix Gateway, ledger state read at epoch 329,417 on 26 July 2026 (https://mainnet.radixdlt.com/status/gateway-status) 5. hyperscale-rs on this wiki (/contents/tech/research/hyperscale-rs) 6. Radix governance on this wiki (/contents/tech/core-concepts/radix-governance) 7. ROLA authentication on this wiki (/developers/frontend/03-rola-authentication) 8. RadixTalk, the governance category (https://radixtalk.com/c/governance) 9. Radix developer documentation (https://docs.radixdlt.com/) 10. Radix Knowledge Base (https://learn.radixdlt.com/) 11. radixdlt on GitHub (https://github.com/radixdlt) 12. The Radix Dashboard (https://dashboard.radixdlt.com/) 13. The Radix Foundation blog (https://www.radixdlt.com/blog) 14. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 15. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #5: ← Previous: Issue #4, Jul 13–19, 2026 (/blog/week-in-review-2026-07-19) · Next: Issue #6, Jul 27 – Aug 2, 2026 → (/blog/week-in-review-2026-08-02) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: The consensus half of the Rust rebuild is essentially built and formally verified, and after a week of worry, candidates began standing for the council. ## Radix Week in Review: The Consensus Work Is Nearly Done URL: https://radix.wiki/blog/week-in-review-2026-07-19 Updated: 2026-09-06 Summary: The lead developer on hyperscale-rs said the consensus implementation is close to finished; what remains is verification and tightening the security m… Week of 13 – 19 July 2026 Top story The consensus half of hyperscale-rs is essentially built The week in brief - The lead developer on hyperscale-rs (/contents/tech/research/hyperscale-rs) said the consensus implementation is close to finished; what remains is verification and tightening the security maths. - A formal model now proves the network can resize its shard groups while running, without breaking. - Post-quantum cryptography is the near-term item on the roadmap; confidential transfers were considered and deliberately deferred. - An outside developer opened a pull request on the official Android wallet, the first from outside the core team in over a month. - Six demonstrations on the test network drove Radix accounts through two agent-payment protocols. - Candidates began putting themselves forward for the council seats that had been going unfilled. The consensus layer is the part of a blockchain that decides which transactions happened and in what order, and it is the part that took the field years and a peer-reviewed paper to get right. On hyperscale-rs (/contents/tech/research/hyperscale-rs) , the community's Rust rebuild of Radix's scaling design, that part is now essentially built. Proving it rather than testing it The remaining work moves to the Radix Engine (/contents/tech/core-protocols/radix-engine) , the gateway and the desktop validator: awkward jobs, but far easier for other people to pick up than the consensus core ever was. The week's proof arrived on schedule. The project's eleventh week on its first milestone produced 55 commits and a formal model, written in Quint, that mechanically proves the reshape lifecycle safe. Reshaping is how the network resizes its shard groups while running, by splitting them, merging them and moving validators between them, and it is the sort of thing that is very hard to test by example because the failures hide in orderings nobody thought to try. Pairing deterministic simulation with formal verification checks the protocol against every case at once rather than the ones someone wrote down. Past that, the roadmap is visible. Post-quantum cryptography is near-term. Confidential transfers, of the kind Solana and Sui offer, were sketched and set aside: a shieldable resource would be straightforward to build, but the cryptography those systems rely on breaks against a quantum computer, and no chain has a durable plan for keeping the feature working afterwards. The reasoning is that it is better to wait for post-quantum privacy to settle and adopt what survives than to ship something with a two-year shelf life. Hands on the tools On 17 July a community developer opened pull request #1445 against the official Android wallet, adding view modes for NFT collections. It is the first contribution there from outside the core team in over a month, and it lands while the Radix Foundation (/ecosystem/radix-foundation) is in maintenance mode, so the official wallet is now something the community co-authors. The same pattern showed up elsewhere: a longtime contributor is building a fresh Babylon wallet; a project called Vulper is readying a beta that shows a holder's lending positions inside the wallet; and six demonstrations went up on Stokenet (/contents/tech/releases/stokenet) driving Radix accounts through x402 and AP2, two protocols for letting software agents pay each other. An essay on self-tokenization circulated the same week. All of it is early and none of it is proven. Filling the council seats Under the Foundation the Radix Accountability Council (/ecosystem/radix-accountability-council) advised. Under the DAO that replaces the Foundation it becomes a body of elected delegates who hold the assets and steer the treasury, which is a different job and needs enough people willing to do it. For most of the week the worry running through the developer and Hyperscale channels was that not enough had come forward, and that the DAO could stall for want of delegates. Then people began standing. Giles Morris filed a formal proposal on RadixTalk (/ecosystem/radixtalk) for a business and finance seat, unpaid, for three to six months. Others said in the same days that they would serve if wanted, among them a longtime Scrypto (/contents/tech/core-protocols/scrypto-programming-language) contributor and a construction-business owner moving full-time into crypto. RadixTalk has become the governance forum in practice, and the arguments there are sometimes heated, which is what a real handover sounds like. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 19 July 2026, epoch 327,401, against the same reading a week earlier. Metric This reading On the week XRD staked 4.85 billion up 35 million, or 0.7% Validators in the active set, of those registered to be 100 of 180 unchanged Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.94% down 0.16 points Validators charging a fee that differs from the one they publish 79 up 1 Stake rose by 34 million XRD and everything else held still. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake19 JULY 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.94% between them.The 100 validators in the active set, read at state version 538,372,746.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki Read hyperscale-rs (/contents/tech/research/hyperscale-rs) for what the milestone actually covers, and Radix governance (/contents/tech/core-concepts/radix-governance) for how the council fits into what replaces the Foundation. What to watch - Whether enough candidates come forward to seat the council, which decides whether the DAO convenes on time. - The verification passes on consensus, and the work moving into the Radix Engine where more people can join it. - Whether the Android wallet takes a second outside pull request, which is what turns one contribution into a pattern. Corrections This issue originally called the body the council becomes "the MiDAO". MIDAO is the firm that handles Marshall Islands incorporation, not the DAO itself, and the text now says the DAO. Next: whether the seats fill, and whether consensus clears verification. References: 1. Radix Gateway, ledger state read at epoch 327,401 on 19 July 2026 (https://mainnet.radixdlt.com/status/gateway-status) 2. babylon-wallet-android, the official Android wallet repository (https://github.com/radixdlt/babylon-wallet-android) 3. Radix Foundation, moving to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) 4. RadixTalk (https://radixtalk.com/) 5. hyperscale-rs on this wiki (/contents/tech/research/hyperscale-rs) 6. The Radix Engine on this wiki (/contents/tech/core-protocols/radix-engine) 7. Radix governance on this wiki (/contents/tech/core-concepts/radix-governance) 8. Quint, the specification language the reshape model is written in (https://quint-lang.org/) 9. RadixTalk, the governance category (https://radixtalk.com/c/governance) 10. Radix developer documentation (https://docs.radixdlt.com/) 11. Radix Knowledge Base (https://learn.radixdlt.com/) 12. radixdlt on GitHub (https://github.com/radixdlt) 13. The Radix Dashboard (https://dashboard.radixdlt.com/) 14. The Radix Foundation blog (https://www.radixdlt.com/blog) 15. hyperscale-rs on GitHub (https://github.com/hyperscalers/hyperscale-rs) 16. The Radix Engine Toolkit on GitHub (https://github.com/radixdlt/radix-engine-toolkit) Radix Week in Review series, Issue #4: ← Previous: Issue #3, Jul 6–12, 2026 (/blog/week-in-review-2026-07-12) · Next: Issue #5, Jul 20–26, 2026 → (/blog/week-in-review-2026-07-26) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: Everything that moved this week was built by the community: the Rust rebuild of Radix's scaling design, a Rust SDK, and Hookah going open source. ## Radix Week in Review: hyperscale-rs Closes On Its First Milestone URL: https://radix.wiki/blog/week-in-review-2026-07-12 Updated: 2026-09-06 Summary: hyperscale-rs , the community's Rust rebuild of Radix's scaling design, is close to its first milestone; the last hard problem in front of it is state… Week of 6 – 12 July 2026 Top story hyperscale-rs closes on its first milestone The week in brief - hyperscale-rs (/contents/tech/research/hyperscale-rs) , the community's Rust rebuild of Radix's scaling design, is close to its first milestone; the last hard problem in front of it is state contention. - Governance of the network's own parameters now runs on the ledger rather than in configuration files. - A community developer published a Rust software development kit for Radix, filling a gap that had only ever been covered in JavaScript. - Hookah (/developers/tools/hookah) , which tells an application when something it cares about happens on the ledger, went fully open source and self-hostable. - The operator who runs most of the test network set out a plan to rebuild it from scratch, to cut what it costs to keep running. - Nothing this week came from the Radix Foundation (/ecosystem/radix-foundation) , which is in maintenance mode with its infrastructure funded into late 2026. Every item this week was built by somebody who does not work for the company that started Radix, which is what the handover was supposed to produce and is now producing. The scaling work moves to the community Hyperscale is Radix's design for splitting the network into shards, which are slices that process transactions in parallel while still agreeing with one another. When the Foundation finished its own phase of the work it handed over a baseline rather than a promise: the software, the test scripts, the network configurations, and a public test that sustained 500,000 transactions a second in real cross-shard swaps without losing atomicity, meaning a transaction touching two shards still either happens completely or not at all. hyperscale-rs is the community's ground-up Rust implementation of that design, and it is where the research now happens. Two things moved this week: governance of the network's own parameters landed on the ledger, so those settings are changed by a vote rather than by editing a file; and the team narrowed its remaining work to state contention. Contention is the problem sharding cannot solve by adding shards. Two transactions that both want to change the same piece of state, such as the price of one trading pool, have to be put in an order, and no amount of parallelism removes that. The approach being built batches the contending writes so a single shard sequences them together under one lock, rather than taking a lock for each. It is unglamorous work, and it is the part everything else rests on. The Foundation still supplies the machines for the larger test runs. Two pieces of tooling For years several of Radix's basic building blocks existed only in JavaScript. This week a community developer, genkipool, published a native Rust kit covering the parts that sit off the ledger: verifying a ROLA (/developers/frontend/03-rola-authentication) login, which is how a wallet proves who it is to a website without sending a transaction; building and signing transactions; managing keys; and deriving addresses. It is dual-licensed under MIT and Apache-2.0, and it ships with a server that lets an AI agent talk to a Radix wallet directly. It has eight commits and one star, so it is a beginning rather than a dependency. Hookah went fully open the same week. It used to be a hosted service; it is now MIT-licensed and self-hostable, and it does one useful thing: an application registers the on-ledger events it cares about, and Hookah sends it a message the moment one happens. Without something like it, an application has to poll the ledger and work out for itself what changed. Arguing about who runs it The developer and community channels spent the week on governance, and the arguments were the real ones: how much authority a council should hold; where moderation stops and censorship starts; and how to keep any single body small enough that nobody can capture it. The Radix Accountability Council (/ecosystem/radix-accountability-council) , the emerging DAO and its working groups are all being assembled in public on RadixTalk (/ecosystem/radixtalk) . The governance page (/contents/tech/core-concepts/radix-governance) on this wiki tracks how the pieces fit together. The same shift showed up in the plumbing. The community operator who runs most of Stokenet (/contents/tech/releases/stokenet) , the public test network, set out a plan to reset it in the third quarter: a fresh start with no migration of existing data, chosen because it brings the hosting bill down to something the community can pay without a corporate budget. Proposals also circulated to keep the mobile wallet maintained and lightly improved until the next major upgrade, and to decide as a community what it should become after that. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 12 July 2026, epoch 325,385, against the same reading a week earlier. Metric This reading On the week XRD staked 4.82 billion down 4 million, or 0.1% Validators in the active set, of those registered to be 100 of 180 down 3 registered Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 40.1% up 0.28 points Validators charging a fee that differs from the one they publish 78 down 1 A flat week: stake within a rounding error of the week before, and three validators leaving the registered list without touching the active set. Concentration watch Eight validators held a third of all staked XRD, unchanged, and 15 held half. RADIX WIKIWho Holds the Stake12 JULY 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 40.1% between them.The 100 validators in the active set, read at state version 535,505,959.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki The pages worth reading alongside this issue are hyperscale-rs (/contents/tech/research/hyperscale-rs) , which tracks the milestone work; the 500,000 transactions-per-second test (/contents/tech/research/hyperscale-500k-tps) that set the baseline; and Hookah (/developers/tools/hookah) . What to watch - Milestone 1 on hyperscale-rs, which needs the contention work to land first. - The Stokenet reset in the third quarter, and whether anything on the test network needs migrating before it happens. - Whether the Rust kit picks up a second contributor, which is the difference between a repository and a dependency. Corrections Nothing this week. Next: whether the contention work lands, and what a reset test network means for anyone building on it. References: 1. Radix Foundation, moving to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) 2. Radix Foundation, completing the interim Hyperscale phase (https://www.radixdlt.com/blog/hyperscale-completing-the-interim-phase) 3. Radix Foundation, the 500,000 transactions-per-second public test (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) 4. genkipool, radixdlt-rust-sdk on GitHub (https://github.com/genkipool/radixdlt-rust-sdk) 5. xstelea, Hookah on GitHub (https://github.com/xstelea/hookah) 6. Radix Gateway, ledger state read at epoch 325,385 on 12 July 2026 (https://mainnet.radixdlt.com/status/gateway-status) 7. hyperscale-rs on this wiki (/contents/tech/research/hyperscale-rs) 8. Radix governance on this wiki (/contents/tech/core-concepts/radix-governance) 9. RadixTalk, the governance category (https://radixtalk.com/c/governance) 10. Radix developer documentation (https://docs.radixdlt.com/) 11. Radix Knowledge Base (https://learn.radixdlt.com/) 12. radixdlt on GitHub (https://github.com/radixdlt) 13. The Radix Dashboard (https://dashboard.radixdlt.com/) 14. The Radix Foundation blog (https://www.radixdlt.com/blog) Radix Week in Review series, Issue #3: ← Previous: Issue #2, Mar 16–22, 2026 (/blog/week-in-review-mar-16-22-2026) · Next: Issue #4, Jul 13–19, 2026 → (/blog/week-in-review-2026-07-19) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: A month after the Foundation published the Hyperscale code, its 500,000 transactions-per-second result is something anyone can rebuild and check. RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) | Leaderboard (/leaderboard) ## Radix Week in Review: Hyperscale, One Month Open URL: https://radix.wiki/blog/week-in-review-mar-16-22-2026 Updated: 2026-09-06 Summary: One month after the Foundation published all of the Hyperscale code, anyone can rebuild its 500,000-transaction-per-second result for themselves. Deve… Week of 16 – 22 March 2026 Top story A month on from open-sourcing Hyperscale, the community holds the code The week in brief - One month after the Foundation published all of the Hyperscale (/contents/tech/research/hyperscale-rs) code, anyone can rebuild its 500,000-transaction-per-second result for themselves. - Development of Hyperscale is now community-led; the Foundation has closed its own chapter on it. - March is the last month of the first phase of the validator subsidy taper. - The Radix Accountability Council (/ecosystem/radix-accountability-council) is six weeks in, with the Gateway bid still open and no decision announced. - Quack Space is building Radix wallet login for Bluesky, the open social network. - The proposal to move the official developer documentation onto this wiki is still gathering replies. A month ago the Foundation put every line of Hyperscale on GitHub, along with its documentation and the tooling used to run it. The point of that, and it has now arrived, is that the headline result stops being a claim and becomes something anyone can check. Hyperscale is Radix's design for splitting a network into shards, which are independent slices that process transactions in parallel while still agreeing with each other. The published result is a sustained 500,000 transactions per second, with peaks above 800,000, across 128 shards; and the property that matters more than the headline is that doubling the shards from 64 to 128 doubled the throughput, which is what the design predicted. Anyone can now fork the code, run the benchmark on their own machines and build on top of it. The subsidy enters its last phase but one March is the final month of phase one of the validator subsidy wind-down (/contents/history/validator-subsidy-sunset) , which a vote of 740.7 million XRD across 604 accounts approved by 71.6%. The cap falls from USD 200 a month to USD 100 in April, administered by the incoming community entity rather than the Foundation, and stops in June. Validators are the machines that agree transactions, and their operators charge a fee on the staking rewards they pass back. Since mainnet launched, the subsidy has covered the gap between those fees and the cost of running the machines. From June the fees have to cover it alone, so operators who have not repriced have three months to do it. Six weeks of the council The Radix Accountability Council is five community-elected members: Peachy, Jazzer_9F, Avaunt, projectShift and Tadkis. Six weeks into its mandate its work is the handover: running the bidding for the Gateway and Connect Relay, forming the Radix DAO, and being answerable for both. The Gateway bid is still the live argument on RadixTalk (/ecosystem/radixtalk) , where the unresolved question is the aggregator architecture and what an operator model should look like. The council facilitates and does not choose; the choice belongs to a community vote. Nothing was decided this week. Radix identity on an open social network Quack Space is building login and identity infrastructure that connects Radix wallets to Bluesky (https://bsky.app/) , the social network built on the AT Protocol. It uses ROLA (/developers/frontend/03-rola-authentication) , the mechanism by which a Radix wallet proves who it is to a website without a transaction, together with XRD domain names, so a wallet can stand as a Bluesky identity. The approach is worth noting because it does not build a social network. It attaches Radix's identity primitives to one that already has users. The project also describes a peer-to-peer fixed-rate lending component settled atomically through Radix sub-intents, which suggests a financial layer planned on top of the social graph. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 22 March 2026, epoch 293,129, against the same reading a week earlier. Metric This reading On the week XRD staked 4.61 billion up 143 million, or 3.2% Validators in the active set, of those registered to be 100 of 188 down 4 registered Validators holding a third of the stake between them 8 unchanged Share of stake held by the largest 10 39.42% up 0.1 points Validators charging a fee that differs from the one they publish 66 up 4 Stake recovered most of the previous week's fall, and four validators dropped off the registered list without changing the active set, which is the hundred largest and is the only group that agrees transactions. Concentration watch Eight validators held a third of all staked XRD, unchanged on the week, and 15 held half. RADIX WIKIWho Holds the Stake22 MARCH 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.42% between them.The 100 validators in the active set, read at state version 476,843,514.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki Three pages were updated: Hyperscale, with the open-source milestone and the benchmark figures; the Radix Accountability Council, with what it is currently working on; and the validator subsidy sunset, with the phase timetable and the handover to the community entity. What to watch - The subsidy cap halving on 1 April, and which validators have repriced before it does. - A decision on the Gateway bid, which has now been open for two weeks without one. - An independent Hyperscale benchmark run by somebody other than the Foundation. Corrections This issue originally listed Faraz as a sitting member of the council. He had been replaced by Tadkis in February, as the previous issue said; the list above is corrected. It also carried a note that the source for Quack Space was unverified. An unverified claim should not have been published with a promise to check it later, so that section now says only what the project itself describes. Next: the subsidy halves, and the council has to turn a thread about the Gateway into a decision. References: 1. Radix Foundation, closing the interim Hyperscale chapter (https://www.radixdlt.com/blog/interim-hyperscale-closing-the-chapter) 2. Radix Foundation, consultation results on the validator subsidy (https://www.radixdlt.com/blog/consultation-results-the-future-of-the-validator-subsidy) 3. RadixTalk (https://radixtalk.com/) 4. Bluesky (https://bsky.app/) 5. Radix Gateway, ledger state read at epoch 293,129 on 22 March 2026 (https://mainnet.radixdlt.com/status/gateway-status) 6. Hyperscale on this wiki (/contents/tech/research/hyperscale-rs) 7. The validator subsidy sunset on this wiki (/contents/history/validator-subsidy-sunset) 8. ROLA authentication on this wiki (/developers/frontend/03-rola-authentication) 9. RadixTalk, the governance category (https://radixtalk.com/c/governance) 10. Radix developer documentation (https://docs.radixdlt.com/) 11. Radix Knowledge Base (https://learn.radixdlt.com/) 12. radixdlt on GitHub (https://github.com/radixdlt) 13. The Radix Dashboard (https://dashboard.radixdlt.com/) 14. The Radix Foundation blog (https://www.radixdlt.com/blog) Radix Week in Review series, Issue #2: ← Previous: Issue #1, Mar 9–15, 2026 (/blog/week-in-review-mar-9-15-2026) · Next: Issue #3, Jul 6–12, 2026 → (/blog/week-in-review-2026-07-12) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) Previously: The Foundation invited outside operators to take over three services it runs itself, and the elected council that will oversee the process took its seat. RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) | Leaderboard (/leaderboard) ## Radix Week in Review: The Handover Begins URL: https://radix.wiki/blog/week-in-review-mar-9-15-2026 Updated: 2026-09-06 Summary: The Radix Foundation invited outside operators to take over three services it currently runs alone, which is the first practical step of the handover… Week of 9 – 15 March 2026 Top story The Foundation opens bidding on the services it runs itself The week in brief - The Radix Foundation (/ecosystem/radix-foundation) invited outside operators to take over three services it currently runs alone, which is the first practical step of the handover it announced in January. - The Radix Accountability Council (/ecosystem/radix-accountability-council) , five elected community members, is seated and will oversee that process. - Radix Rewards Season 1 finished paying out: 114.3 million XRD across two seasons. - The validator subsidy taper is on schedule and stops entirely in June. - Blend, a fixed-rate lending platform aimed at institutions, named Brevan Howard and Keyrock among its partners. - A community proposal would move the official developer documentation onto this wiki. The interesting thing about this week is that the Foundation started giving pieces of Radix away, and did it by asking who wants them. It published requests for proposals, which are open invitations to bid, on three services: the Babylon Gateway, which is the interface wallets and apps read the network through; the Connect Relay, which passes messages between a wallet on a phone and a site in a browser; and the Signaling Server, which introduces the two to each other in the first place. All three run on Foundation machines today, and every wallet and every application depends on them. The Foundation will comment on the bids it receives; it will not pick the winner on its own, because that choice is passing to community governance. The RadixTalk (/ecosystem/radixtalk) thread on the Gateway bid ran past thirty replies, most of them asking whether the service as built is the right thing to hand over: it runs as a single instance with one aggregator process, which is a reasonable design for one operator and an awkward one for several. The council is seated The Radix Accountability Council is five people the community elected in February: Peachy, Jazzer_9F, Avaunt, projectShift, and Tadkis, who replaced Faraz that month. Voting weight came from XRD, Radix's own token, and 1.34 billion XRD across 1,151 accounts took part. Its job is to coordinate the handover from the Foundation to the community: running the bidding process above, and forming the Radix DAO that will eventually hold what the Foundation holds now. It facilitates rather than decides; the decisions stay with the wider community through governance votes. Money in, money out Radix Rewards Season 1 closed on 3 February, distributing 114,347,194 XRD across Season 0 and Season 1 participants. A fifth was available immediately and the rest released over seven days, with anything forfeited by people who exited early redistributed to those who waited. A proposal for a shorter Season 2, to run during the handover, is being discussed on RadixTalk. Going the other way, the validator subsidy (/contents/history/validator-subsidy-sunset) is winding down on the timetable a 71.6% vote approved: capped at USD 200 a month in March, USD 100 through April and May, and nothing from June. Validators are the machines that agree transactions, and their operators have been running at a loss covered by that subsidy; from June the fees they charge have to cover their costs on their own. The separate Ecosystem Fund, originally 250 million XRD, has closed too, having distributed roughly 20 million XRD across 67 grants. Requests for proposals replace it. Being built Blend is a fixed-rate lending platform for institutions, in its definition phase, with Brevan Howard (https://www.brevanhoward.com/) named for liquidity, Keyrock (https://keyrock.eu/) for market making, Anthic for liquidations and Instabridge for moving assets between chains. There is no launch date. Separately, a proposal on RadixTalk would move the official developer documentation onto this wiki, making it the canonical place for Scrypto (/contents/tech/core-protocols/scrypto-programming-language) guides and Gateway API (https://docs.radixdlt.com/docs/network-gateway) reference as the Foundation steps back from running developer services. It has drawn more than twenty-five replies and no decision. The week on the ledger Read from the Radix Gateway as the ledger stood at midday on 15 March 2026, epoch 291,113, against the same reading a week earlier. Metric This reading On the week XRD staked 4.46 billion down 212 million, or 4.5% Validators in the active set, of those registered to be 100 of 192 unchanged Validators holding a third of the stake between them 8 down 1 Share of stake held by the largest 10 39.32% up 0.2 points Validators charging a fee that differs from the one they publish 62 up 5 The staked total fell by 212 million XRD over the week, a little over 4%, and the number of validators needed to hold a third of the stake between them dropped from nine to eight. Both moved in the same direction: stake left, and what remained sat slightly more heavily at the top. Concentration watch Eight validators held a third of all staked XRD, down from nine the week before, and 15 held half. RADIX WIKIWho Holds the Stake15 MARCH 2026SHARE OF STAKE HELD BY THE LARGEST VALIDATORS0%25%50%75%100%a third of the stake8 validators15 hold half1255075100validators, largest firstA group holding more than a third of the stake can stop the network agreeing. Onthis reading that is 8 validators, and the largest 10 hold 39.32% between them.The 100 validators in the active set, read at state version 472,952,553.radix.wiki 8 validators hold a third of the stake between them. This week on the wiki Two pages went up: the Radix Rewards Season 1 distribution, with the full breakdown of the 114.3 million XRD, the vesting schedule and how the forfeited share was redistributed; and a community profile for Bayesian. What to watch - Bids on the three services, and who besides the Foundation is willing to run them. - The subsidy stepping down to USD 100 in April, and whether validators raise fees to match. - Whether the developer-documentation proposal reaches a decision rather than staying a thread. Corrections Nothing this week. Next: the bids arrive, and the council has to work out how to judge them. References: 1. Radix Foundation, requests for proposals for Gateway and relay services (https://www.radixdlt.com/blog/the-next-phase-of-decentralization-rfps-for-gateway-and-relay-services) 2. Radix Foundation, the 2026 strategy (https://www.radixdlt.com/blog/2026-strategy-the-next-chapter-of-radix) 3. Radix Foundation, consultation results on the validator subsidy (https://www.radixdlt.com/blog/consultation-results-the-future-of-the-validator-subsidy) 4. RadixTalk, the governance and RFP discussion (https://radixtalk.com/) 5. Radix documentation, the Network Gateway (https://docs.radixdlt.com/docs/network-gateway) 6. Brevan Howard (https://www.brevanhoward.com/) 7. Keyrock (https://keyrock.eu/) 8. Radix Gateway, ledger state read at epoch 291,113 on 15 March 2026 (https://mainnet.radixdlt.com/status/gateway-status) 9. Radix Accountability Council on this wiki (/ecosystem/radix-accountability-council) 10. The validator subsidy sunset on this wiki (/contents/history/validator-subsidy-sunset) 11. Radix Rewards Season 1 distribution on this wiki (/contents/history/radix-rewards-s1-distribution) 12. Radix Foundation on this wiki (/ecosystem/radix-foundation) 13. Radix governance on this wiki (/contents/tech/core-concepts/radix-governance) 14. RadixTalk, the governance category (https://radixtalk.com/c/governance) 15. Radix developer documentation (https://docs.radixdlt.com/) 16. Radix Knowledge Base (https://learn.radixdlt.com/) 17. radixdlt on GitHub (https://github.com/radixdlt) Radix Week in Review series, Issue #1: Next: Issue #2, Mar 16–22, 2026 → (/blog/week-in-review-mar-16-22-2026) · All recaps (/blog/week-in-review) · Subscribe (/week-in-review.xml) RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) | Leaderboard (/leaderboard) ## Majority Judgment URL: https://radix.wiki/contents/tech/core-concepts/majority-judgment Updated: 2026-09-06 Summary: Majority Judgment is a voting method in which each voter grades every candidate on one shared scale of words rather than ranking them or picking one.… Method Majority Judgment (MJ) Type Graded, or evaluative, voting Proposed by Michel Balinski and Rida Laraki First published 2007, Proceedings of the National Academy of Sciences 104(21) Ballot One grade per candidate, every candidate graded Radix grade scale Excellent, Very Good, Good, Acceptable, Poor Radix counting share Three-fifths of voting power cast (not the median) Used by Radix for Electing the Permanent RAC (/ecosystem/radix-accountability-council) , seven seats Status Deployed on mainnet, never used Majority Judgment is a voting method in which each voter grades every candidate on one shared scale of words rather than ranking them or picking one. It was set out by Michel Balinski and Rida Laraki in A theory of measuring, electing, and ranking, published in the Proceedings of the National Academy of Sciences in May 2007. [1] (#ref-1) The argument behind it is that a ballot asking who you prefer collects less information than a ballot asking how good each candidate is, and that a method counting grades can escape some of the failures that follow from counting preferences. The Radix DAO governance framework (/contents/tech/core-concepts/radix-governance) adopts it as the default mechanism for every election the DAO holds, including the seven-seat Permanent Radix Accountability Council (/ecosystem/radix-accountability-council) . [2] (#ref-2) Radix implements one deliberate departure from the published method, and it is the detail this page exists to state plainly: the share of voting power that settles a candidate’s grade is three-fifths, not one half. Radix elections are not decided on the median grade. How the count works Every valid ballot assigns exactly one grade to every candidate on the list. A ballot that leaves any candidate ungraded is invalid and is not counted, and the Radix framework requires the ballot interface to refuse an incomplete submission at the point of casting, so that honest voter error cannot show up later as low turnout. [2] (#ref-2) Each voter’s full voting power is applied to each grade that voter assigns. There is no Abstain grade: a voter who does not want to support a candidate grades them low, and the scale itself carries that. Counting a candidate is one pass down the scale. Start at the highest grade and accumulate the voting power that placed the candidate at that grade or above. The first grade at which the running total reaches the required share is the candidate’s qualifying grade. Under the published method that share is one half and the result is the candidate’s median grade, which Balinski and Laraki call the majority grade. Under the Radix framework the share is three-fifths, which is why the result is not a median and the framework does not call it one. Because every valid ballot grades every candidate, the voting power measured is identical for every candidate in the round. Qualifying grades are therefore directly comparable, and no candidate can be flattered by having been graded on fewer ballots than a rival. The Radix variant, term by term Four settings do the work, and three of them live in the framework text rather than in the parameter registry, which means changing them is an amendment rather than a parameter change. [3] (#ref-3) Term Value What it does Grade scale Excellent, Very Good, Good, Acceptable, Poor Five ordered grades. The order is normative; the implementation indices 4 down to 0 encode the order and are never averaged Grade Quantile Three-fifths, fixed in the framework, not a parameter The share of voting power cast that must place a candidate at or above a grade for that grade to be theirs Minimum Qualifying Grade Good The lowest qualifying grade at which a candidate may be seated at all. A ranking alone does not seat someone the electorate grades below the floor Quorum 7% of eligible voting power Participation needed for the round to count, unchanged on the single permitted rerun The quantile is set to three-fifths so that it matches the 60% approval threshold the DAO’s other election mechanism applies per candidate, putting the same share-of-turnout test to a candidate whichever mechanism is in force. [3] (#ref-3) The two settings are not independent of one another: raising the quantile lowers every qualifying grade computed on the same ballots, so a floor left unchanged silently becomes a higher bar. Radix also resolves an exact split upward where some of the literature resolves it downward. Where the running total arrives at exactly three-fifths at a grade, that grade is the qualifying grade, so a candidate graded Excellent by exactly three-fifths of the voting power cast and Poor by the rest qualifies at Excellent. The framework gives its reason: the rule follows from a single accumulation pass and can be checked against the published tallies without a second rule. [2] (#ref-2) Ties, and what a low turnout buys Candidates are ranked by qualifying grade, and that ranking is itself the seating order, so there is no separate confirmation round of the kind the two-stage mechanism needs. Where two candidates share a qualifying grade and the tie decides a seat, it is broken by the majority gauge: for each tied candidate, compare the share of voting power that graded them above their qualifying grade against the share that graded them below it. The framework applies the gauge rather than the iterative middlemost-grade formulation, on the stated ground that the gauge is computed in one pass over the published tallies and can be verified by any member from the result. [2] (#ref-2) A round that closes below quorum may be re-run exactly once, and the rerun is deliberately not made easier: same quorum, same quantile, same electability floor, same snapshot of the electorate, with double the voting period. The framework spells out why, and the reasoning is worth reading whatever one thinks of the method. A rerun on lower thresholds is a different question rather than more time to answer the same one, and a reduced quorum would make the rerun cheaper to control than the round it exists to rescue, which is an incentive to suppress turnout in the first round. [2] (#ref-2) If the rerun also closes below quorum, no candidate is elected and every seat is referred to vacancy handling. The mechanism is on the ledger, and has never run Majority Judgment is not only drafted. The governance component (/contents/tech/core-concepts/components) the framework routes through is deployed on Radix mainnet, running blueprint (/contents/tech/core-concepts/blueprints-and-packages) Governance v1.0.0, and among its nineteen methods is vote_on_majority_judgment_election. Its stored state holds a majority_judgment_elections key-value store alongside temperature_checks and proposals, each with its own counter. [4] (#ref-4) Read from the ledger repeatedly through August 2026, all three counters read 0. The contract the whole framework depends on is live and has processed nothing, which is the correct state while nothing in the framework is yet operative. Two things stand between the method and its first use. Ratification of the Governance Framework is an activation condition of the DAO’s Operating Agreement and needs a vote, and the network halt (/contents/history/hyperlane-asset-drain-2026) that began on 31 August 2026 stopped the ledger a vote would have to run on. The council (/ecosystem/radix-accountability-council) responded by removing the seven-day limit on the discussion phase and leaving it open-ended, so the first Radix election held under Majority Judgment has no date. One further caution for anyone reading the deployed contract against the written rules. The component’s election parameter set carries a field named minimum_median_grade, and the framework it implements settles grades at the Grade Quantile and not at the median. The name is a leftover from an earlier reading; the framework text is the authority on what the field means. See also - Radix Governance (/contents/tech/core-concepts/radix-governance) - Radix Accountability Council (/ecosystem/radix-accountability-council) - Governance WG: Elect the Permanent RAC (/ideas/dao-elect-permanent-rac) - Radix DAO Charter (/ideas/radix-network-dao-charter) External links - Balinski and Laraki, A theory of measuring, electing, and ranking (https://pmc.ncbi.nlm.nih.gov/articles/PMC1885569/) , PNAS 104(21):8720, 2007 - Proposal & Voting Framework (https://github.com/RadixDAO/governance-framework/blob/main/pending/governance/proposal-and-voting-framework.md) , RadixDAO/governance-framework, section 6.2.4 - DAO Parameters Registry (https://github.com/RadixDAO/governance-framework/blob/main/pending/parameters/dao-parameters-registry.md) , RadixDAO/governance-framework, sections 3.5 and 6B - The deployed governance component (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) on the Radix Dashboard References: 1. Michel Balinski and Rida Laraki, “A theory of measuring, electing, and ranking”, PNAS 104(21):8720, 22 May 2007 (https://pmc.ncbi.nlm.nih.gov/articles/PMC1885569/) 2. RadixDAO governance-framework – Proposal & Voting Framework, sections 4.5, 6.2.4, 6.3 and 6.5 (https://github.com/RadixDAO/governance-framework/blob/main/pending/governance/proposal-and-voting-framework.md) 3. RadixDAO governance-framework – DAO Parameters Registry, sections 3.5 and 6B (https://github.com/RadixDAO/governance-framework/blob/main/pending/parameters/dao-parameters-registry.md) 4. Radix Dashboard – the deployed Governance v1.0.0 component, read at epoch 338,958 on 28 August 2026 (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) ## RADIX Wiki Editorial Policy URL: https://radix.wiki/policy Updated: 2026-09-06 Summary: RADIX Wiki editorial policy is the set of standards every article on this wiki is held to. There are seven of them, and they were adopted in two waves… Category Policy Policies Seven Core Verifiability (/policy/verifiability) , NPOV (/policy/neutral-point-of-view) , No original research (/policy/no-original-research) Applies to Every article on RADIX Wiki Enforced by Editorial notices (/policy/editorial-notices) and the rotating maintenance sweep First adopted 31 July 2026 Log Wiki Maintenance Log (/contents/tech/operations/wiki-maintenance-log) RADIX Wiki editorial policy is the set of standards every article on this wiki is held to. There are seven of them, and they were adopted in two waves: five on 31 July 2026, conflict of interest (/policy/conflict-of-interest) shortly after, and editorial notices (/policy/editorial-notices) on 26 August 2026. The policies are not a style guide. Each one answers a different question about a page, and each names what happens when a page fails it. Three are content policies in the sense that they govern what an article may say; one decides whether an article should exist at all; one is about the contributor rather than the page; and one describes the machinery the other six use to flag their own failures. The seven policies Policy Type The question it answers Enforcement Verifiability (/policy/verifiability) Sourcing (core) Can a reader check this claim against a published source? [citation needed] tags; Needs citations notice Neutral point of view (/policy/neutral-point-of-view) Content (core) Is the subject represented fairly and without editorial bias? Written like an advertisement notice; attribution No original research (/policy/no-original-research) Content (core) Has anyone but this wiki said it? Moved to Blog (/blog) or Ideas (/ideas) ; sourcing Notability (/policy/notability) Inclusion Does this subject merit its own article? Merge into a broader page; Stub notice Conflict of interest (/policy/conflict-of-interest) Conduct Does the contributor have a stake in the subject? Conflict of interest notice; attribution; sourcing Freshness (/policy/freshness) Sourcing (Radix-specific) Was this checked recently enough to still be true? Automatic May be outdated notice; Last Verified stamp Editorial notices (/policy/editorial-notices) Editorial process How does the wiki say out loud that a page needs work? Notice blocks and derived tracking categories How they fit together Verifiability is the first standard, and two of the others are derived from it rather than independent of it. No original research (/policy/no-original-research) is verifiability applied to interpretation: an inference this wiki draws from on-chain data is not verifiable however sound it is, because there is nothing published to check it against. Freshness (/policy/freshness) is verifiability applied to time: a claim correctly sourced a year ago can be false today, which is why every factual page carries a Last Verified date and is treated as stale 180 days after it. [1] (#ref-1) Conflict of interest (/policy/conflict-of-interest) is derived from neutral point of view (/policy/neutral-point-of-view) in the same way, but it is a fact about a contributor rather than about a page. A conflict is not misconduct and is not a reason to keep someone out; it is a reason to disclose, to source harder, and to let someone else make the contested call. Notability (/policy/notability) is the only one of the seven that is asked before a page exists, and it is the only one whose answer can be not yet. The rest are asked of a page that is already here. What enforcement actually looks like Five of the six content and conduct policies name a notice as their enforcement, and editorial notices (/policy/editorial-notices) is the page that describes what those notices are. Two kinds exist and they behave differently. A notice an editor places sits on one article and stays until an editor removes it. A tracking category is derived by the site from the page itself, is never stored on the page, and cannot be dismissed by editing: it clears when the underlying condition clears. The May be outdated notice is the clearest case. It is generated at render time from the page’s own dates, so the only thing that clears it is a fresh verification, and the only thing on this wiki that can record one is the rotating maintenance sweep. Which pages currently carry which notice, and what the sweep has done about them, is public in the Wiki Maintenance Log (/contents/tech/operations/wiki-maintenance-log) . See also - Wiki Maintenance Log (/contents/tech/operations/wiki-maintenance-log) , the running record of what the maintenance sweep found and changed - Terms of Use (/contents/resources/legal/terms-of-use) - Maintenance (/maintenance) , the derived tracking categories External links - Wikipedia: Core content policies (https://en.wikipedia.org/wiki/Wikipedia:Core_content_policies) , the three-policy model these seven extend References: 1. Wikipedia – Wikipedia:Core content policies (https://en.wikipedia.org/wiki/Wikipedia:Core_content_policies) ## Radix Visuals URL: https://radix.wiki/contents/resources/radix-visuals Updated: 2026-09-06 Summary: Radix Visuals is a subject index of the explainer graphics, architecture diagrams, and product illustrations that describe the Radix network. It is or… Radix Visuals Type Visual reference · subject index Subject Radix protocol, wallet, and ecosystem concepts Contents 14 subjects across 3 collections Collections Radix Protocols · Wallet Features · Initiatives / Events Gallery status 79 hosted images retired 1 Aug 2026 (image CDN decommissioned) Related Brand Assets (/contents/resources/brand-assets) Source Radix documentation (https://docs.radixdlt.com) & educational material Overview Radix Visuals is a subject index of the explainer graphics, architecture diagrams, and product illustrations that describe the Radix (https://www.radixdlt.com) network. It is organised into three collections – Radix Protocols, Radix Wallet features, and ecosystem initiatives – and each entry links to the wiki page covering that topic. The protocol collection covers core building blocks such as the Radix Engine (/contents/tech/core-protocols/radix-engine) , on-ledger badges (/contents/tech/core-concepts/badges) , the Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus protocol, and native assets. The wallet collection covers Radix Wallet (/contents/tech/core-protocols/radix-wallet) features including Personas (/contents/tech/core-protocols/personas) , Radix Connect (/contents/tech/core-protocols/radix-connect) , Smart Accounts (/contents/tech/core-protocols/smart-accounts) , delegated network fees, and human-readable transaction manifests (/contents/tech/core-protocols/transaction-manifests) . The initiatives collection covers HyperScale (/contents/tech/research/hyperscale-rs) and RadQuest. For downloadable logos and colour specifications, see Brand Assets (/contents/resources/brand-assets) . What this page covered From 2024 until 2026 this page hosted a gallery of 79 explainer graphics served through the Super.so image proxy at images.spr.so. That proxy has been decommissioned – every one of the 79 URLs now returns a 404 from the origin – and the files behind them were Telegram-cloud uploads with no surviving master copies to re-host. The gallery was retired on 1 August 2026 and replaced by the subject index below, which points each topic at the wiki page that explains it and at the upstream sources where current Radix diagrams are published. Radix protocols - Badges – Badge (/contents/tech/core-concepts/badges) · Authorization and Access Rules (/developers/scrypto/03-authorization-and-badges) - Cerberus / Cassandra – Cerberus (Consensus Protocol) (/contents/tech/core-protocols/cerberus-consensus-protocol) · Cerberus Whitepaper & Academic Validation (/contents/tech/research/cerberus-whitepaper) - Native assets – Native Assets vs Token Approvals (/contents/tech/core-concepts/native-assets-vs-token-approvals) · $XRD Token (/contents/tech/core-protocols/xrd-token) - Radix Engine – Radix Engine (/contents/tech/core-protocols/radix-engine) - Developer resources – Developers (/developers) Radix Wallet features - Smart Accounts – Smart Accounts (/contents/tech/core-protocols/smart-accounts) - Personas – Personas (/contents/tech/core-protocols/personas) - Radix Connect – Radix Connect (/contents/tech/core-protocols/radix-connect) - Delegated network fees – Transaction Fees (/developers/transactions/03-transaction-fees) - Transaction manifests and transaction preview – Transaction Manifests (/contents/tech/core-protocols/transaction-manifests) · Blind Signing and Transaction Manifests (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) Initiatives and events - Hyperscale – hyperscale-rs (/contents/tech/research/hyperscale-rs) · Hyperscale: 500K TPS Public Test (/contents/tech/research/hyperscale-500k-tps) - RadQuest – RadQuest (/ecosystem/radquest) , the Radix Foundation’s guided onboarding dApp, which settled its last quest on 27 April 2026; its radquest.io registration expired on 10 August 2026 and the domain now serves a registrar parking page. Where current Radix diagrams live - Radix Documentation (https://docs.radixdlt.com) – architecture and protocol diagrams published alongside the specifications they illustrate. - Radix Knowledge Base (https://www.radixdlt.com/learn/knowledge-base) – explainer graphics aimed at newcomers. - Brand Assets (/contents/resources/brand-assets) – the logomark, favicon, and colour reference for this wiki. Its download links resolve on radix.wiki itself; the preview image on that page is served from the wiki’s own image store. ## Brand Assets URL: https://radix.wiki/contents/resources/brand-assets Updated: 2026-09-06 Summary: Official logo assets for RADIX.wiki , provided for use when referencing or linking to the wiki. The download links below resolve on radix.wiki itself,… RADIX.wiki brand kit Owner RADIX.wiki (https://radix.wiki) Primary mark Colour logomark – PNG, 512×512, 59 KB Icon Favicon – ICO (4 KB) + PNG, 32×32 Served from radix.wiki, for the download links; the preview image is held in the wiki's image store Accent colour #ff9da0 Use for Referencing or linking to RADIX.wiki Official logo assets for RADIX.wiki (https://radix.wiki) , provided for use when referencing or linking to the wiki. The download links below resolve on radix.wiki itself, so they ship with the site and cannot be decommissioned out from under a page the way the image proxy behind this wiki’s retired 79-image gallery (/contents/resources/radix-visuals) was. Hotlink them, or download and self-host. The logomark shown below is a WebP preview served from the wiki’s image store, which is a separate host: link the download URL, not the preview. Logomark The primary RADIX.wiki mark: a 512×512 PNG, 59 KB. Download or hotlink it at radix.wiki/logo.png (/logo.png) . The artwork is unchanged, but the file is not: until 5 September 2026 (https://github.com/tutmoses/radix-wiki/commit/63f89e2b8a83e665e3f7784cb8362abbc28eb77c) this URL served a 700×700 PNG of 440 KB, and the preview above is still that larger copy. Anything holding the old dimensions should re-measure. Favicon The square site icon, for compact placements and link cards: favicon.png (/favicon.png) (PNG) or favicon.ico (/favicon.ico) (ICO). Colours The wiki's palette, as it is defined in the site's own stylesheet. Dark surfaces with a single coral accent; use the accent for the mark and for links back to the wiki. Token Hex Used for Surface 0 #393e50 Page background Surface 1 #444a5e Cards and raised surfaces Surface 2 #4f5569 Hover and nested surfaces Border #52586e Dividers and outlines Accent #ff9da0 Links, active state, the logomark Accent hover #fff4cc Link and control hover Text #ffffff Body copy Text muted #c5c9d6 Secondary copy and captions Usage Use these marks only to reference or link back to RADIX.wiki. When you do, please link to the wiki (https://radix.wiki) so readers can reach the source. ## Radix Ecosystem Funding URL: https://radix.wiki/contents/history/radix-ecosystem-funding Updated: 2026-09-05 Summary: Radix ecosystem funding refers to the family of grant, incubation, and treasury vehicles operated by the Radix Foundation and RDX Works to finance dev… Radix Ecosystem Funding Operator Radix Foundation (/ecosystem/radix-foundation) / RDX Works Active 2022 – 2026 (Endowment Fund ongoing) Primary fund 250M XRD ($10M+) Ecosystem Fund Programs Radix Grants Program · Booster Grants · Foundry Program · Ecosystem Asset Fund · Endowment Fund Status Grant programs wound down by May 2026; Endowment Fund continues Radix ecosystem funding refers to the family of grant, incubation, and treasury vehicles operated by the Radix Foundation (/ecosystem/radix-foundation) and RDX Works to finance development of the Radix ecosystem (/ecosystem) . Between 2022 and 2026 five distinct vehicles ran under this umbrella: the cohort-based Radix Grants Program, the Radix Booster Grants – the main dApp funding track, drawn from the 250M XRD ($10M+) Ecosystem Fund (https://www.radixdlt.com/blog/250m-xrd-10m-to-power-the-next-web3-breakthrough---the-new-radix-ecosystem-fund) – the Radix Foundry Program incubator, the Ecosystem Asset Fund treasury program, and the Radix Endowment Fund. With the Foundation's move to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) in May 2026, the grant and incubation programs stopped taking new intakes; the Endowment Fund continues under external management. Radix Grants Program (2022–2023) The Booster Grants grew out of the original Radix Grants Program (https://www.radixdlt.com/blog/introducing-the-radix-grants-program) , announced in December 2022 as a cohort-based scheme offering teams $30,000 in XRD alongside structured mentorship from RDX Works. The first cohort (https://www.radixdlt.com/blog/the-radix-grants-program-introducing-the-projects) , announced in January 2023, selected six teams: AlphaDEX (/ecosystem/alphadex) (on-ledger order book exchange), CaviarSwap (decentralized exchange), Foton (/ecosystem/foton) (NFT marketplace and SDK), Hermes Protocol (/ecosystem/hermes-protocol) (on-chain notifications), Ociswap (/ecosystem/ociswap) (decentralized exchange), and XRD.domains (/ecosystem/xrd-domains) (the Radix Name Service). Several cohort alumni – Ociswap and XRD.domains among them – went on to receive Babylon Booster Grants, and the cohort model's mentorship-plus-funding formula carried into the Booster tracks described below. Radix Booster Grants (2023–2026) The Radix Booster Grants program is a funding initiative designed to support and accelerate the development of decentralized applications (dApps) within the Radix ecosystem (/ecosystem) . Launched as part of the broader 250M $XRD ($10M+) Ecosystem Fund (https://www.radixdlt.com/blog/250m-xrd-10m-to-power-the-next-web3-breakthrough---the-new-radix-ecosystem-fund) , this program aims to foster innovation and growth in the Radix network (https://www.radixdlt.com) by providing financial support to developers and entrepreneurs. The program began on 11 May 2023 as the Babylon Booster Grants (https://www.radixdlt.com/blog/babylon-booster-grants-kickstart-your-dapp-on-the-radix-babylon-mainnet-upgrade) , an award of $XRD "with a value of up to $10k USD" for the first dApps to launch at the September 2023 Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet upgrade, paid once the dApp was live on mainnet. The award rose during the program. Announcements from 8 December 2023 onward describe it as a $15,000 grant, and the reshape post of 7 February 2024 records the rise in a single word, setting the successor track at "now $15,000 in XRD". That post reshaped the program into four consecutive tracks (https://www.radixdlt.com/blog/radix-booster-grants-apply-now) offering up to $160,000 in $XRD per project, with dedicated marketing, business, and technical support from the RDX Works team. Grant Tracks Teams could receive each grant once, with the track tied to a development stage: - MVP Booster ($5,000) – build a first MVP on Stokenet or as a mainnet beta. - Launch Booster ($15,000) – launch the product on Babylon mainnet. - Refine Booster (up to $50,000) – improve a live dApp and grow traction. - Growth Booster (up to $140,000) – reach seed stage, pitched to the RDX Works ecosystem investment team. Beyond the tracks, the program offered audit grants, milestone rewards, and fundraising rewards of up to 10% of externally raised funds (capped at $50,000), alongside co-marketing, AWS credits, and Hacken audit discounts. Recipients passed KYC/KYB checks and agreed project milestones before payment. By early 2024 the grants effort had distributed over half a million dollars to builders (https://www.radixdlt.com/blog/250m-xrd-10m-to-power-the-next-web3-breakthrough---the-new-radix-ecosystem-fund) since February 2023 – roughly $170,000 in Booster Grants, $90,000 in Milestone Rewards, and over $20,000 in developer incentives – across more than 20 funded teams drawn from over 100 applications. Funded Projects The Radix Booster Grants program has supported a diverse range of projects, contributing to the growth and development of the Radix ecosystem. These projects span various categories including DeFi, NFTs, gaming, and infrastructure. Below is a list of some of the key projects that have received funding. Every figure in the Grant Amount column is the one stated in that project's own announcement, linked from the cell. Where a row reads not stated, the announcement named no figure; all nine such announcements fall between 3 November and 5 December 2023, before the award rose to $15,000: Project Name Category Grant Amount Key Features CaviarNine (/ecosystem/caviarnine) DeFi Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-carviarnine) - Concentrated liquidity pools - Decentralized order book - Liquid staking pool - Swap Widget Ociswap (/ecosystem/ociswap) DeFi Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-ociswap) - Concentrated liquidity - SPLASH 2.0 program - Dynamic fee settings Weft Finance (/ecosystem/weft-finance) DeFi $15,000 · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-weft-finance) - Decentralized lending and borrowing - 'Wefties' NFTs for loans - Flexible collateral ratios DefiPlaza (/ecosystem/defiplaza) DeFi Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-defiplaza) + $5,000 (MVP Booster, 2025) (https://www.radixdlt.com/blog/mvp-booster-grant-winners-rakoon-fun-defiplaza-oasis) - Multi-token trading platform - Single-sided liquidity provision - CALM model for impermanent loss Fibonacci Finance (/ecosystem/fibonacci-finance) DeFi $15,000 · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-fibonacci-finance) - Financial risk services - Custom risk engine designs - On-chain liquidity management DELPHIBETS (/ecosystem/delphibets) DeFi $15,000 · announcement (https://x.com/radixdlt/status/1750897102299754984) - Decentralized prediction markets - P2P betting with AMM and pari-mutuel mechanics - DPH staking and governance RadLand (/ecosystem/radland) NFT/Gaming $15,000 · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-radland) - NFT marketplace - Bulk minting capabilities - Support for Olympia (/contents/tech/releases/radix-mainnet-olympia) network NFTs Impahla (/ecosystem/impahla) NFT/Gaming Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-imphala) - NFT creation and management - IPFS integration - Market analytics InfiniteLabs (/ecosystem/infinite-labs) NFT/Gaming $15,000 · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) - 3D game with NFT integration - Multiple game modes - In-game NFT marketplace XRD Domains (/ecosystem/xrd-domains) Infrastructure $15,000 · announcement (https://www.radixdlt.com/blog/babylon-booster-grants) - Domain management - Namelets for record management - Genus domains RadixCharts (/ecosystem/radixcharts) Infrastructure Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-radixcharts) - Network analytics - Real-time data on various metrics - Ecosystem performance comparison ShardSpace (/ecosystem/shardspace) Infrastructure $15,000 · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-shardspace) - User interface for dApp interaction - Portfolio management tools - Explorer pages for network data Trove (/ecosystem/trove) Other Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-trove) - Peer-to-peer trading tool - Open Swap feature - Complex asset combination support Gable (/ecosystem/gable-finance) Other Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-gable) - Income generation with LSU tokens - Flash Loans (https://aave.com/docs/aave-v3/guides/flash-loans) - Automated concentrated liquidity RadLock (/ecosystem/radlock) Other Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grant-radlock) - Project asset-locking solution - Liquidity locking - Team vesting for token distribution Backeum (/ecosystem/backeum) Other Not stated · announcement (https://www.radixdlt.com/blog/babylon-booster-grants-backeum) - Content creator monetization - NFT rewards for supporters - Cryptocurrency integration Root Finance DeFi $5,000 (MVP Booster) - Decentralized lending and borrowing - Multi-asset support - Health Bar tool Selfi Social Social Media $5,000 (MVP Booster) + $15,000 (Launch Booster, 2024) (https://www.radixdlt.com/blog/launch-booster-recipients-radix-charts-selfi-social) - Chrome extension for X (Twitter) - Web3 integration in social media - Social DeFi interactions NFT Wars NFT/Gaming $5,000 (MVP Booster) - Hero-centric idle mobile RPG - NFT integration in gameplay - Multiple game modes RadXplorer Infrastructure $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners) - Network explorer dashboard - Transaction and account insights - Ecosystem token data FalconPad DeFi $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners) - Token launchpad - FCFS launch mechanics - Project fundraising support Huros Other $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners) - Real-world asset tokenization - Luxury goods: whiskies, wines, watches, gemstones Stabilis (/ecosystem/stabilis) DeFi $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners) - STAB Protocol stablecoin - ILIS DAO - Dynamic interest rate mechanism RPFS Infrastructure $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners-2) - IPFS data storage integrated with Radix - Fast, scalable, secure storage XRDegen (/ecosystem/xrdegen) NFT/Gaming $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners-2) - NFT launchpad and marketplace - Collection creation tools - Fair minting mechanics Liquify DeFi $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners-2) - Orderbook liquidity for native LSUs - No external oracles required Rakoon.fun DeFi $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners-rakoon-fun-defiplaza-oasis) - Bonding-curve token launchpad - Locking services - Liquidity migration to Ociswap OASIS Infrastructure $5,000 (MVP Booster) (https://www.radixdlt.com/blog/mvp-booster-grant-winners-rakoon-fun-defiplaza-oasis) - Radix–Solana cross-chain bridge - RWA integration - No-code dApp builder Radix Foundry Program (2024–2026) The Radix Foundry Program is an incubator initiative launched in 2024 by Radix Publishing as part of the Radix ecosystem's $10M development fund (https://www.radixdlt.com/blog/250m-xrd-10m-to-power-the-next-web3-breakthrough---the-new-radix-ecosystem-fund) . The program aims to incubate decentralized applications (dApps) in high-potential categories to drive significant growth in users, Total Value Locked (TVL), and on-chain activity within the Radix ecosystem. Structure and Focus Foundry projects received up to $250,000 in $XRD along with comprehensive support (https://www.radixdlt.com/blog/introducing-radix-foundry-program) – marketing assistance, business development guidance, and technical mentorship from the RDX Works (/ecosystem/rdx-works) leadership team, plus introductions to venture capital firms, exchanges, and market makers, and coordinated go-to-market strategies with Radix Publishing. Teams typically entered through the Booster Grant program (https://www.radixdlt.com/blog/introducing-radix-foundry-program) , and the fund expected to make up to one Foundry investment per quarter (https://www.radixdlt.com/blog/ecosystem-fund-update-new-directions-for-growth-and-support) , with projects evaluated on agreed milestones, user growth, TVL, and on-chain activity. The program followed early DeFi successes on Radix – by early 2024, DEXes like CaviarNine, Ociswap, and DeFi Plaza, together with the WEFT money market, had accumulated more than $30 million in TVL (https://www.radixdlt.com/blog/introducing-radix-foundry-program) . It targeted seven high-potential categories (https://www.radixdlt.com/blog/introducing-radix-foundry-program) : lending and borrowing markets, real-world asset tokenization, yield derivatives, professional NFT trading, launchpad services, stablecoins and collateralized debt positions, and liquid staking – the last building on roughly $250 million in Liquid Stake Units (https://www.radixdlt.com/blog/introducing-radix-foundry-program) already in the ecosystem. Notable Projects The Radix Foundry Program announced its first two participant projects in early 2024, selecting initiatives in the perpetual decentralized exchange and NFT trading categories. Surge Surge was selected as the first recipient of a Radix Foundry grant (https://www.radixdlt.com/blog/radix-foundrys-latest-projects---surge-and-trove) to develop a perpetual decentralized exchange (DEX) on the Radix network. The project is being developed by a team with expertise in mathematics, derivatives trading, and quantitative finance. Surge aims to build upon lessons learned from established perpetual platforms such as Drift, GMX, DyDx, and Jupiter. The platform's development addresses a significant market opportunity, as decentralized perpetual markets represent only 2.3% of the total derivatives volume in crypto, compared to 22% for spot trading (https://www.radixdlt.com/blog/radix-foundrys-latest-projects---surge-and-trove) . By February 2024, Surge had already demonstrated significant traction, with over 100 million CAVIAR tokens locked for their initial token allocation (https://www.radixdlt.com/blog/monthly-wins-joining-the-idos-consortium-14m-liquidity-initiative-and-more-ecosystem-success) . Trove (/ecosystem/trove) Trove was selected as the second Foundry recipient (https://www.radixdlt.com/blog/radix-foundrys-latest-projects---surge-and-trove) to develop professional NFT trading infrastructure. The platform initially launched in late 2023 with basic NFT trading functionality and quickly achieved over 1 million $XRD in traded volume. The project demonstrated early success by facilitating trading for notable NFT collections including Abandoned Scorpions, Radical Robos, $XRD Domains, and ICE404. Under the Foundry Program, Trove is developing an enhanced platform focused on professional traders, featuring real-time data aggregation, visualized analytics, and improved collection liquidity. The upgraded platform plans to include floor price charting tools, complex trade execution, customizable trading interfaces, collection bidding capabilities, and competitive fee structures. The project also aims to support emerging NFT standards within the ecosystem, such as 404-style tokens, dynamic traits, and nestable tokens. Ecosystem Asset Fund (2024–2025) Ecosystem Asset Fund Operator Radix Foundation (/ecosystem/radix-foundation) Type Treasury market-support program Launched December 2024 Budget $25,000 per month Allocation 70% top-20 ecosystem index · 30% random top-50 token Holding period At least 6 months Transparency Public wallet with monthly activity reports Status Paused May 2025 (ran ~6 months, Dec 2024–May 2025) The Ecosystem Asset Fund was a treasury program run by the Radix Foundation (/ecosystem/radix-foundation) that spent $25,000 per month buying and holding native tokens issued by projects in the Radix ecosystem (/ecosystem) . It was announced in late 2024 (https://www.radixdlt.com/blog/radix-foundation-ecosystem-asset-fund) , with the first allocation made in December 2024, and ran for about six months before being paused in May 2025. The Foundation described the fund as a way to “boost visibility, deepen liquidity, and convey confidence to builders, community members, and the wider industry in the assets in the Radix ecosystem.” Structure and Allocation Each month’s $25,000 was split between two buckets, per the Foundation’s announcement (https://x.com/radixdlt/status/1863960484363599953) : - 70% was directed to a weighted index of the top 20 ecosystem tokens by market capitalisation, excluding wrapped assets, XRD (/contents/tech/core-protocols/xrd-token) , and the Cassie token. - 30% was directed to a single randomly chosen top-50 ecosystem token. Tokens acquired by the fund were held for a minimum of six months (https://www.radixdlt.com/blog/radix-foundation-ecosystem-asset-fund) , which the Foundation framed as a commitment to stability rather than short-term trading. All purchases were made from a public wallet, allowing the community to independently verify every transaction, and the Foundation committed to publishing monthly activity reports (https://www.radixdlt.com/blog/radix-foundation-ecosystem-asset-fund) . Both the token selection and the purchase date each month were randomised and front-run resistant, so that market participants could not anticipate and trade ahead of the fund’s buys. Relationship to the Ecosystem (Grants) Fund The Ecosystem Asset Fund was distinct from the larger 250 million XRD Radix Ecosystem Fund, the Foundation’s grants programme for funding ecosystem development (https://www.radixdlt.com/blog/ecosystem-fund-update-new-directions-for-growth-and-support) . Whereas the grants fund funded teams to build, the Asset Fund bought the resulting tokens on the open market. The two ran in parallel as separate initiatives while the Asset Fund was active. Wind-down The fund ran for about six months. Its public wallet (https://dashboard.radixdlt.com/account/account_rdx1297vs7up584rkwensy0jwzxq6g0xua67ca9trxdyr45cjnmzdak5x3) records monthly purchases from December 2024 through the start of May 2025, after which none were made – only unsolicited airdrops have reached the wallet since, and the accumulated tokens remain held rather than sold. The program was paused after the early-May 2025 purchase (https://t.me/radix_dlt/899351) . A Radix Foundation representative (Adam, @Adam_XRD) explained that, following community feedback that the initiative was “a good idea but not being that beneficial overall”, it was paused after running for six months. No formal announcement was made at the time, and the program has not resumed. The wind-down came as the Radix Foundation (/ecosystem/radix-foundation) moved toward handing its operations and treasury to a community-led DAO. Nothing has left the wallet since. Read at epoch 337,182 / state version 553,218,942 on 22 August 2026, the account’s most recent outbound transaction is still the buying round of 1 May 2025, and every position it took that day is still in place. Reception and Risks The fund’s methodology bought whichever tokens ranked highest by market capitalisation, which included speculative memecoins. This drew commentary that public money could end up exposed to projects that were later abandoned. The fund’s own holdings illustrated the risk: between December 2024 and May 2025 it made repeated purchases of DELAY (/ecosystem/delay) , a memecoin, accumulating roughly 12.5 million tokens for about 143,000 XRD, all of which remained in the fund’s wallet on-chain (https://dashboard.radixdlt.com/account/account_rdx1297vs7up584rkwensy0jwzxq6g0xua67ca9trxdyr45cjnmzdak5x3) , unsold. DELAY’s market ranking subsequently fell, and the token now trades at close to nothing: read at the Ociswap (https://ociswap.com/delay) API on 5 September 2026 its pool held about $226 of liquidity on seven-day volume of $2.90. The episode illustrated the abandonment risk inherent in allocating to high-volatility memecoins by market capitalisation alone. Fifteen months of holding turned that single example into a portfolio-wide record. At state version 553,218,942 the wallet holds 590,060.28 XRD and thirty-six other token positions, some of them unsolicited airdrops rather than purchases. Twenty-two of the thirty-six match a project page on this wiki by their on-ledger resource address, counting the address wherever a page carries it rather than in body text alone, and this wiki records twelve of those positions as active, seven as dormant and three as closed. Alongside DELAY (/ecosystem/delay) sit Radit (/ecosystem/radit) and XIDAR (/ecosystem/xidar) , both closed, and HUG (/ecosystem/hug) , Mox Studio (/ecosystem/mox-studio) , Foton (/ecosystem/foton) , DogeCubeX (/ecosystem/dogecubex) , Delphibets (/ecosystem/delphibets) , WhyNot (/ecosystem/whynot) and DAN (/ecosystem/dan) , all dormant. The final round on 1 May 2025 bought 98,252,019 HUG for 160,646.74 XRD and 1,101,381.89 DELAY for 5,961.42 XRD. A ranking by market capitalisation is a snapshot, and it cannot see which of the projects it ranks will still be running a year later; the fund’s frozen holdings now record that answer for the December 2024 ecosystem. Radix Endowment Fund (2024–present) Radix Endowment Fund Established 2024 Size 1.5 billion XRD Manager Brevan Howard Digital (https://www.radixdlt.com/blog/radix-endowment-manager-selected) Custodian Copper (https://www.radixdlt.com/blog/copper-integrates-radix-into-institutional-custody-services) Staking Twinstake Structure Segregated portfolio company Mandate XRD-denominated returns The Radix Endowment Fund is a 1.5 billion $XRD fund established in 2024 (https://www.radixdlt.com/blog/the-radix-endowment-fund) to support long-term ecosystem growth and provide financial stability for entities involved in the development of the Radix platform. The fund is managed by Brevan Howard Digital (https://www.radixdlt.com/blog/radix-endowment-manager-selected) , the digital asset investment platform of Brevan Howard, a global hedge fund managing approximately $34 billion in assets. Structure and Management The fund was created to establish a sustainable source of funding for ongoing Radix development while reducing reliance on treasury token sales, and to help drive external investment and co-investment (https://www.radixdlt.com/blog/the-radix-endowment-fund) into the ecosystem. It operates through a segregated portfolio company (https://www.radixdlt.com/blog/the-radix-endowment-fund) that ring-fences the $XRD from the manager's own assets, with multiple boards responsible for fiduciary oversight (https://www.radixdlt.com/blog/radix-endowment-manager-selected) . Brevan Howard Digital's BH Digital Solutions business manages the assets, which are held in designated accounts at regulated custodian Copper (https://www.radixdlt.com/blog/copper-integrates-radix-into-institutional-custody-services) ; staking infrastructure is provided by Twinstake (https://www.radixdlt.com/blog/the-radix-endowment-fund) . Strategy and Network Impact The manager operates under $XRD-based mandates (https://www.radixdlt.com/blog/the-radix-endowment-fund) – returns must be generated in $XRD – with a large share of the fund staked (/contents/tech/core-concepts/staking) via Twinstake above a minimum staking balance requirement (https://www.radixdlt.com/blog/the-radix-endowment-fund) , and the remainder deployable into other return-generating strategies. The initial staking position increased net network staking by approximately 620 million $XRD (https://www.radixdlt.com/blog/the-radix-endowment-fund) and reduced staking emissions from approximately 7.7% to 6.7% per annum (https://www.radixdlt.com/blog/the-radix-endowment-fund) ; to preserve decentralisation, the Radix Foundation (/ecosystem/radix-foundation) reduced its own validator nodes by two, unstaking roughly 122 million $XRD. The endowment also supports institutional adoption and strategic partnerships (https://www.radixdlt.com/blog/babylon-turns-one-key-achievements-and-the-road-ahead) with market infrastructure providers such as Copper and Keyrock and products like Flash Liquidity. Current Status In April 2026 the Radix Foundation announced it was moving to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) from May 2026, under which active development and community operations run at a minimal footprint. Foundation-run funding programs – the Booster Grants and the Foundry Program – are no longer taking new intakes, and stewardship of ecosystem funding has passed to the community. The Ecosystem Asset Fund had already been paused in May 2025 following community feedback, and the Radix Endowment Fund continues to operate under external management by Brevan Howard Digital. Builders seeking funding should follow current community-run channels and the Radix blog (https://www.radixdlt.com/blog) for the latest. The record above documents the programs as they ran during the active funding era. Related Pages - Radix Economic Model (/contents/tech/research/radix-economic-model) – XRD emissions and staking economics - Radix Foundation (/ecosystem/radix-foundation) – the organisation that operated these programs - Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) – which of the projects these programs funded are still operating External Links - The New Radix Ecosystem Fund (250M XRD) – The Radix Blog (https://www.radixdlt.com/blog/250m-xrd-10m-to-power-the-next-web3-breakthrough---the-new-radix-ecosystem-fund) - Radix Booster Grants: Apply Now – The Radix Blog (https://www.radixdlt.com/blog/radix-booster-grants-apply-now) - Introducing the Radix Foundry Program – The Radix Blog (https://www.radixdlt.com/blog/introducing-radix-foundry-program) - The Radix Endowment Fund – The Radix Blog (https://www.radixdlt.com/blog/the-radix-endowment-fund) - Radix Foundation Ecosystem Asset Fund – The Radix Blog (https://www.radixdlt.com/blog/radix-foundation-ecosystem-asset-fund) - Ecosystem Fund Update: New Directions for Growth and Support – The Radix Blog (https://www.radixdlt.com/blog/ecosystem-fund-update-new-directions-for-growth-and-support) - Foundation Update: Moving to Maintenance Mode – The Radix Blog (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) ## The Hard Money Project URL: https://radix.wiki/ecosystem/the-hard-money-project Updated: 2026-09-05 Summary: The Hard Money Project (THMP) is a research and educational initiative that focuses on analyzing monetary systems and Bitcoin 's role in a potential n… The Hard Money Project (THMP) is a research and educational initiative that focuses on analyzing monetary systems and Bitcoin (https://bitcoin.org) 's role in a potential new financial paradigm. Founded by Lluis Aragones (https://web.archive.org/web/20250317003014/https://hardmoneyproject.substack.com/p/welcome-to-the-hard-money-project) , Head Economist at RDX Works (/ecosystem/rdx-works) , the project examines what it describes as a contemporary "Bretton Woods moment" (https://web.archive.org/web/20250317003014/https://hardmoneyproject.substack.com/p/welcome-to-the-hard-money-project) in the digital era, referring to the fundamental transformation of the monetary system through digitalization. https://youtu.be/e86CN2FslKs (https://youtu.be/e86CN2FslKs) Overview The Hard Money Project positions itself as an analytical framework for understanding the evolution and future of monetary systems during a period of significant technological and financial change. The project argues that the current momentum toward centralizing control over money on digital, programmable unified ledgers represents a pivotal shift (https://web.archive.org/web/20250317003014/https://hardmoneyproject.substack.com/p/welcome-to-the-hard-money-project) in how monetary systems operate and are controlled. A central focus of the initiative is examining the distinction between money and currency, with particular attention to Bitcoin's role as a form of "hard money." The project posits that while all currency is money, not all money can sustainably function as currency (https://web.archive.org/web/20250317003731/https://hardmoneyproject.substack.com/p/are-we-talking-money-or-currency) , presenting this as crucial for understanding modern monetary systems. The project's analysis extends beyond traditional economic frameworks to incorporate historical, anthropological, and technological perspectives. It traces the evolution of monetary systems from gift economies through barter systems to modern fiat currencies (https://web.archive.org/web/20250317002959/https://hardmoneyproject.substack.com/p/money-i-the-past-of-trial-and-error) , examining how each stage has influenced current monetary structures and potential future developments. A significant aspect of the project's research involves analyzing Satoshi Nakamoto's original vision for Bitcoin. The project argues that Bitcoin was designed as a foundational step toward a broader vision of "dynamic smart money" and "programmable P2P social currencies" (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) , rather than as a standalone currency system. The initiative combines theoretical analysis with practical implications, examining how monetary systems affect sovereignty and economic freedom. It advocates for critical thinking about monetary design and policy, particularly in the context of increasing digitalization and centralization of financial systems. Key Concepts Money vs Currency Analysis The Hard Money Project develops a detailed framework for distinguishing between money and currency, which forms a foundational element of its monetary analysis. The project defines money as any asset that can serve as a medium of exchange, while currency is specifically money in motion - the subset of money that actively circulates within an economy (https://web.archive.org/web/20250317003731/https://hardmoneyproject.substack.com/p/are-we-talking-money-or-currency) . The analysis traces the historical evolution of monetary systems, beginning with prehistoric gift economies. In these early systems, communities operated through informal reciprocal exchanges without immediate expectations of return, fostering social bonds and trust rather than direct transactions (https://web.archive.org/web/20250317002959/https://hardmoneyproject.substack.com/p/money-i-the-past-of-trial-and-error) . This foundation helps explain the social and anthropological aspects of monetary systems that the project argues remain relevant today. The project identifies several key properties that determine monetary effectiveness (https://web.archive.org/web/20250317003731/https://hardmoneyproject.substack.com/p/are-we-talking-money-or-currency) : - Scarcity to prevent devaluation. - Divisibility for practical use. - Portability for easy transfer. - Fungibility for uniform value. - Durability for long-term stability. - Counterfeit resistance for security. - Immutability and censorship resistance for user control. Bitcoin Analysis The project provides a detailed examination of Bitcoin's role in monetary evolution, with particular attention to Satoshi Nakamoto's original vision. According to the project's analysis of Nakamoto's early communications, Bitcoin was designed as a "basic P2P currency" intended to serve as a foundation for future "programmable P2P social currencies" (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) . A key argument in the project's analysis is that Bitcoin's fixed supply model makes it more suitable as a store of value than as a currency (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) . The project points out that Bitcoin's design inherently encourages holding rather than circulation, with over 92% of holders not spending any bitcoin for more than a month as of October 2024. Monetary Theory The project develops a comprehensive analysis of monetary evolution, from early commodity-based systems through to modern fiat currencies. It examines how the gold standard emerged as a solution to the limitations of bimetallic systems, providing stability until its eventual collapse during World War I (https://web.archive.org/web/20250317003732/https://hardmoneyproject.substack.com/p/money-ii-from-central-banking-to) . The analysis pays particular attention to the Bretton Woods system and its aftermath (https://web.archive.org/web/20250317003732/https://hardmoneyproject.substack.com/p/money-ii-from-central-banking-to) , examining how the current global fiat system emerged from the "Nixon Shock" of 1971. The project argues that this represents the first truly global fiat experiment in history, operating without any neutral anchor or commodity backing. The project's monetary theory emphasizes the importance of local economic contexts in currency function. It argues that for a currency to maintain stable purchasing power, it must be able to adapt its supply to local economic conditions (https://web.archive.org/web/20250317003731/https://hardmoneyproject.substack.com/p/are-we-talking-money-or-currency) . This leads to a critique of fixed-supply monetary systems, including both traditional gold standards and modern cryptocurrencies like Bitcoin. A central theme in the project's theoretical framework is the distinction between a currency's domestic purchasing power and its foreign exchange value. The analysis suggests that successful currency systems must balance both aspects while maintaining stability and predictability (https://web.archive.org/web/20250317003731/https://hardmoneyproject.substack.com/p/are-we-talking-money-or-currency) . This understanding informs the project's broader critique of current monetary systems and its vision for future developments. Key Arguments The Hard Money Project presents several central arguments about monetary systems and their evolution. These arguments form the theoretical foundation of the project's analysis and inform its vision for future monetary development. Decentralization and Monetary Control The project argues that the current trend toward digital transformation of money represents a critical juncture in monetary history, comparable to the 1944 Bretton Woods conference (https://web.archive.org/web/20250317003014/https://hardmoneyproject.substack.com/p/welcome-to-the-hard-money-project) . A key concern raised is the increasing centralization of monetary control through digital systems, which the project suggests could lead to unprecedented levels of financial surveillance and control. The analysis particularly focuses on the risks of centralized digital ledgers controlled by governments and central banks, where all payments would settle (https://web.archive.org/web/20250317003014/https://hardmoneyproject.substack.com/p/welcome-to-the-hard-money-project) . The project posits that this development could further consolidate monetary power in ways that might compromise individual financial sovereignty. Bitcoin's Role and Limitations The project presents a nuanced analysis of Bitcoin's position in monetary evolution. Based on examination of Satoshi Nakamoto's original communications, the project argues that Bitcoin was intentionally designed as a foundation for future monetary development rather than as a complete currency system (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) . A significant argument is that Bitcoin's fixed supply model, while making it effective as a store of value, inherently limits its functionality as a currency (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) . The project points to the high percentage of bitcoin being held rather than circulated as evidence of this limitation, suggesting that the asset's design encourages accumulation over circulation. Monetary Supply Dynamics The project develops a detailed critique of fixed-supply monetary systems, arguing that effective currencies require elastic supply mechanisms that can adapt to local economic conditions (https://web.archive.org/web/20250317003731/https://hardmoneyproject.substack.com/p/are-we-talking-money-or-currency) . This argument extends to both traditional gold standards and modern cryptocurrency systems. Historical analysis is used to demonstrate how previous attempts at rigid monetary systems, including the classical gold standard, ultimately faced challenges due to their inability to adapt to changing economic conditions (https://web.archive.org/web/20250317003732/https://hardmoneyproject.substack.com/p/money-ii-from-central-banking-to) . The project suggests that this historical pattern remains relevant for understanding contemporary monetary developments. Future Monetary Paradigm The project envisions a future monetary system that combines Bitcoin's role as a neutral base money with more flexible, community-oriented currencies (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) . This system would aim to balance the benefits of hard money with the practical needs of economic communities. Drawing on Satoshi Nakamoto's early writings, the project argues for the development of "programmable P2P social currencies" built on Bitcoin's foundation (https://web.archive.org/web/20250317002911/https://hardmoneyproject.substack.com/p/inception-satoshi-nakamoto-monetary) . These would be designed to provide the supply elasticity needed for effective currency function while maintaining the benefits of decentralization. Critique of Current Fiat System The project presents a comprehensive critique of the current global fiat system, describing it as the first worldwide fiat experiment in history (https://web.archive.org/web/20250317003732/https://hardmoneyproject.substack.com/p/money-ii-from-central-banking-to) . The analysis suggests that this system, lacking any neutral anchor or commodity backing, represents a significant departure from historical monetary arrangements. A key argument is that the current system's centralization of monetary power has led to increased financial instability and wealth inequality (https://web.archive.org/web/20250317003732/https://hardmoneyproject.substack.com/p/money-ii-from-central-banking-to) . The project suggests that this centralization allows for political manipulation of monetary policy at the expense of economic stability and the common good. Website (30 July 2026): hardmoneyproject.com now redirects to hardmoneyproject.substack.com (https://hardmoneyproject.substack.com) , where the newsletter reads "Coming soon" and the most recent post is dated April 2025. The facts table has been repointed at the Substack. Telegram Handle No Longer the Project's The Telegram handle @hardmoneyproject, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . ## RadKET URL: https://radix.wiki/ecosystem/radket Updated: 2026-09-05 Summary: Radket was an online marketplace that accepted only cryptocurrencies as payment method. It was the first of its kind and aimed to provide a platform f… Radket was an online marketplace that accepted only cryptocurrencies as payment method. It was the first of its kind and aimed to provide a platform for buyers and sellers to trade using cryptocurrencies. The project was initiated in 2021. As of 2026 the RadKET domain ( radket.com (https://web.archive.org/web/20240301181527/https://radket.com/) ) is offline and the marketplace was never launched; the project is considered discontinued. Overview The RadKET marketplace was an online platform that allowed users to browse and purchase products using cryptocurrencies. It aimed to build a fully functional and effective marketplace available in multiple countries, with $RDK (RadKET's native token) and several stable and non-stable cryptocurrencies accepted as payment methods. The marketplace was expected to be released in the first quarter of 2024, starting with a beta testing phase and the recruitment of initial sellers. RadKET was committed to partnering with well-known brands and sellers to offer a wide range of products on their platform. Their goal was to create a user-friendly cryptocurrency marketplace, similar to traditional marketplaces like Amazon, where users can buy various supplies and items using their favorite cryptocurrencies The RadKET team had also developed a tokenomics model for their platform. The $RDK token would be used extensively on RadKET, and users would need $RDK to access various benefits on the platform, including making purchases. Mission The mission of RadKET Marketplace was to create a global online marketplace that bridged the gap between traditional e-commerce and the cryptocurrency world. They aimed to provide a platform where users can easily buy and sell products using various cryptocurrencies, making it more accessible for cryptocurrency holders to utilize their digital assets for everyday purchases. RadKET was focused on creating a user-friendly and familiar shopping experience, similar to traditional online marketplaces like Amazon, while incorporating the benefits and convenience of using cryptocurrencies as a payment method. By accepting multiple stable and non-stable cryptocurrencies, RadKET aimed to offer a wide range of payment options to cater to the preferences of different users. Additionally, RadKET aimed to partner with well-known brands and sellers to offer a diverse selection of products on their platform, ensuring a high-quality shopping experience for its users. Overall, RadKET's mission was to encourage the widespread adoption of cryptocurrencies by providing a secure, user-friendly, and globally accessible marketplace for buying and selling goods. Roadmap Here is a roadmap from radket: Q4 2021 - RadKET’s birth - RadKET general conceptualization, thinking about how the final marketplace & airdrop would work, as well as the tokens distribution Q1/Q2 2022 - Creation of our token $RDK - Creation of the documentation - Beginning of the general website & airdrop website developpement Q3/Q4 2022 - Social media creation(twitter-telegram), beginning of the online marketing - Tokenomics creation - Beginning of the first $RDK giveaways - Release of the website, the documentation & beginning of the airdrop 2023 - Would be updated during 2023 Q1 2024 - Beta test, recruitment of the first sellers and then release of the final marketplace, fully functional and effective in several countries with $RDK and several stable and non-stablecoins as payment method - As radket would be our main product, after the release we would continue to work on it to improve it and make it the best crypto-only marketplace in the world Tokenomics Here is tokenomics (https://web.archive.org/web/20240228031542/https://docs.radket.com/radket/overview/tokenomics) from Radket. Airdrop minigame: 26m $RDK Those tokens would all be distributed through the airdrop website. Everything should be gone until we released the final marketplace -- In case there were remaining tokens when we wanted to release the marketplace(which is unlikely to happen), we would distribute them them more quickly or giveaway them fairly to the airdrop game users. When the airdrop was over, 72% of the tokens **would be circulating on the market. Giveaways: 10m $RDK Tokens that were being distributed mainly through Twitter (https://web.archive.org/web/20221020185418/https://twitter.com/RadketRDK) giveaways, airdrops on the active community wallets, etc. Team: 10m $RDK Personal tokens of the two RadKET founders. Marketing & development: 4m $RDK These tokens can be sold for marketing or development. Example: advertising campaigns, server maintenance. Supported networks RadKET Marketplace supported multiple blockchain networks, allowing users to transact with various cryptocurrencies. While specific details may vary, here are some of the supported networks: Ethereum (https://ethereum.org) ($ETH) RadKET was built on the Ethereum blockchain and supported ERC-20 (https://eips.ethereum.org/EIPS/eip-20) tokens. Users can transact with Ethereum and ERC-20 tokens on the marketplace. Binance Smart Chain ($BSC) RadKET also supported the Binance Smart Chain, allowing users to transact with cryptocurrencies that are built on BSC. Polygon ($MATIC) RadKET had integrated with the Polygon network to provide users with the option to transact with cryptocurrencies that are based on Polygon. Avalanche ($AVAX) RadKET had integrated with the Avalanche network, enabling users to utilize cryptocurrencies that are built on the Avalanche platform. These were some of the blockchain networks that RadKET Marketplace supported. Staking Process The staking process on the RadKET Marketplace involved staking the native token, $RDK, to earn rewards. Here's a general overview of the staking process: Obtain $RDK To participate in staking, you needed to acquire $RDK tokens (https://web.archive.org/web/20240228014819/https://docs.radket.com/radket/overview/usdrdk) . You can obtain these tokens through various means, such as purchasing them on supported exchanges or participating in token sales. Connect Wallet Connect your digital wallet to the RadKET Marketplace platform. Supported wallets may vary, but typically popular wallets like MetaMask are compatible. Access Staking Once your wallet is connected, navigate to the staking section on the RadKET Marketplace platform. This may be accessible through a specific tab or section on the website or user interface. Choose Staking Option Select the staking option that suits your preferences. RadKET Marketplace may offer different staking periods or tiers with varying rewards and lock-up periods. Choose the option that aligns with your staking goals. Confirm Staking Confirm the staking transaction by approving the staked amount of $RDK from your wallet. This would typically involve signing the transaction with your wallet's private key. Staking Period Once your tokens are staked, they would be locked for a specified staking period. During this time, you wouldn't be able to access or transfer the staked $RDK tokens. Earn Rewards As you hold your $RDK tokens staked, you would start earning rewards over time. The specific rewards and earning rates were determined by the staking offering on RadKET Marketplace. Unstaking After the staking period is completed, you can initiate the unstaking process. This usually involved submitting an unstaking request and waiting for the predetermined cooldown period before your tokens are released. Claim Rewards Once your tokens are unstaked, you can claim the accumulated rewards. This process may vary, but typically involved confirming the claim transaction through your wallet. Security and Trust RadKET Marketplace was committed to providing a secure and trustworthy platform for its users. Here are some of the security measures and trust factors that RadKET Marketplace had implemented to ensure the safety of its users: Secure Infrastructure RadKET used a secure infrastructure to ensure that user information and transactions were protected. They utilized the latest security technologies such as firewalls, encryption, and multi-factor authentication to help secure the platform and user data. KYC and AML RadKET Marketplace had implemented KYC (Know Your Customer) and AML (Anti-Money Laundering) policies to verify the identity of its users and prevent fraudulent transactions and activities. Smart Contract Audit RadKET had had its smart contracts audited by reputable third-party security firms to ensure that they were secure and free of vulnerabilities. Cold Storage To minimize the risk of loss or hacking of user funds, RadKET stored the majority of its users' funds in cold storage wallets that are physically offline, in addition to a hot wallet for liquidity purposes. Experienced Team The RadKET team comprised experts in blockchain technology, finance, and cybersecurity, which provided credibility and trust. Community Trust RadKET Marketplace had a growing community and active social media presence, with positive feedback and reviews from users. Open Communication RadKET Marketplace kept its users informed about important updates or changes to the platform and was responsive to user feedback and concerns. Insurance RadKET had partnered with reputable insurance providers to protect its users' funds in case of a security breach or hacking incident. The Token After the Project radket.com returns NXDOMAIN and the marketplace was never released, but the airdrop above was real, and at the ledger $RDK has by some distance the widest distribution of any abandoned project in this directory. Radket (https://dashboard.radixdlt.com/resource/resource_rdx1t4zrksrzh7ucny7r57ss99nsrxscqwh8crjn6k22m8e9qyxh8c05pl) ($RDK), read at the Radix Gateway (https://radix-babylon-gateway-api.redoc.ly/) on 21 August 2026, at epoch 336,894: supply 50,000,000 $RDK, all minted and none burned. That figure is the published allocation exactly — 26m to the airdrop minigame, 10m to giveaways, 10m to the two founders and 4m to marketing and development — so the token was issued to the plan and never topped up. Its minter, burner, freezer and recaller are each set to DenyAll, and so are all four of their updaters — nobody, including the account that issued the token, can mint, destroy, freeze or recall a single unit of it. 27,869 accounts hold $RDK, more than most launched projects on Radix ever reach. The largest balance is 7,381,666.57 (14.8%), and the second-largest holder is not an account at all: it is a native two-resource pool (https://dashboard.radixdlt.com/component/pool_rdx1ckvw8yleumnj5tk3ued5cxg7tmtgfmysfc3c60nc6w4utqhl8ywjgh) holding 6,944,719.26 $RDK against 68,618.84 DFP2, the governance token of DeFiPlaza (/ecosystem/defiplaza) . Unlike the $WARS pool, this one is funded on both sides. A token whose marketplace never opened, whose documentation survives only in the Internet Archive and whose domain no longer exists is still tradable on Radix today. ## DogeCubeX URL: https://radix.wiki/ecosystem/dogecubex Updated: 2026-09-05 Summary: DogeCubeX is a centralized decentralized exchange (cDEX) operating on the Radix Network . It provides users with a platform to buy and sell various li… Project DogeCubeX Type Centralized DEX (cDEX) / AMM Network Radix (https://www.radixdlt.com) Origin Spun out of the DogeCube meme coin DogeCubeX is a centralized decentralized exchange (cDEX) operating on the Radix Network (https://www.radixdlt.com) . It provides users with a platform to buy and sell various listed tokens directly from their Radix wallets. DogeCubeX employs an Automated Market Maker (AMM) mechanism, which offers a dynamic price based on the order size and current market conditions. The project was initiated from the Radix first memecoin, DogeCube. Overview The functionality of DogeCubeX is user-friendly and efficient. To execute a swap, users send their tokens to the specified pool address. Within approximately five seconds, DogeCubeX sends the swapped tokens back to the user's wallet. The exchange rate is determined by a simple formula, identical to Uniswap (https://uniswap.org) v2, and it depends on the sent amount and available liquidity. While sending tokens, users have the option to add a message that will specify refund conditions in the event of a sudden price change. Fees and Limits Typically, the fee applied to each swap consists of three parts: - Pool Fee (0.5%): Reward for liquidity providers supplying tokens to the pool. - Exchange Fee (0.5%): Supports the operation of DogeCubeX. - Transfer Fee (0.1 $XRD): Covers the Radix Network fee for transferring tokens back to the user. In cases where a swap fails (e.g., sudden price change and insufficient sent amount for purchase), only the Transfer Fee is applied. However, if the swap fails due to user error (e.g., encrypted message, request for a token not in the pool, overly high amount), a Refund Fee of 0.5 $XRD is applied. DogeCubeX also implements order limits to prevent spamming. The minimum order is 1 $XRD and the maximum is 500 $XRD. These limits are higher for DogeCube Node stakers. Orders that fall outside these parameters are refunded, with an additional fee applied. However, larger amounts can be swapped by splitting them into multiple transactions. Supported Tokens DogeCubeX continuously adds new tokens from high-demand and reliable projects. These tokens, along with their current prices, are listed on the DogeCubeX website. How to Swap To execute a swap, users must fill out their order on the Swap page and follow the given instructions. After sending the specified XRD amount to the pool account, users receive the swapped tokens in their wallet almost instantly. Additional Cost In addition to the swap cost, a fee of 1% and a small 0.1 XRD fee (to cover Radix Network transaction costs) are charged. Community Engagement Users can ask questions or engage with the DogeCubeX team through their official Telegram group. The team is known for its reliable service and user-friendly approach to trading Radix tokens. Status As of 2026 DogeCubeX appears dormant: its original site (dogecubex.live) no longer resolves, and the exchange predates the maturation of native Radix AMMs such as Ociswap (/ecosystem/ociswap) and DefiPlaza (/ecosystem/defiplaza) . It is recorded here as an early piece of Radix Babylon (/contents/tech/releases/radix-mainnet-babylon) -era trading infrastructure. ## Blue Chick NFTs URL: https://radix.wiki/ecosystem/blue-chick-nfts Updated: 2026-09-05 Summary: Blue Chicks NFTs is an exclusive collection of 9,999 immutable & procedurally generated chicks with proof of ownership stored on the Radix network . E… [Notice: Written like an advertisement] Blue Chicks NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) is an exclusive collection of 9,999 immutable & procedurally generated chicks with proof of ownership stored on the Radix network (https://www.radixdlt.com) . Each Blue Chick is unique & genetically constructed the moment you mint it. Overview The purpose of the Blue Chick collection goes beyond just creating NFTs. It aims to foster a community-driven project that promotes Radix adoption and enhances the utility of NFTs as a whole. We believe that NFTs & Gaming are the perfect play to introduce the Radix DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) ecosystem to the wider audience. By fostering a community-driven approach and establishing a robust DAO, the collective efforts of our community will breathe life into the Blue Chicks narrative and cultivate an ever-expanding ecosystem. So, what can Blue Chicks do? Aside from being very cool profile pictures, the utilities that these chicks come with range from things like assembling your platoon within the PVP P2E Artillery Tactical Game, giving you access to the DAO and its Treasury management, community events, claiming limited NFTs, airdrops, and more! Fight in a PVP P2E Artillery Tactical Game One of the first waypoints in the Blue Chicks universe is the Artillery Tactical Game, where your ultimate objective is to lead a platoon of x5 fierce chicks and emerge as the sole surviving force on the battlefield. Each Blue Chick’s distinctive attributes will determine the NFT weaponry they’ll receive via airdrops. ✨ Make your Chicks work for you. Big things are in store for the Blue Chick holders, one of which is the ability to let your chick be recruited by other players, enabling you to earn a portion of the spoils from their victorious battles. Juicy, right? 👀 Reserve your seat at The Mighty Chicks DAO Each Blue Chick derived from the Genesis 9,999 mint has the power to partake in governance, asset control, and tournament organization on the path to reaching total decentralization and community ownership. The DAO will receive funding through several channels, such as: - 20% from the Genesis x9999 Blue Chick mint - Up to 90%* of the proceeds from additional NFT mints - Royalties from the secondary market of every NFT sale - Investing, trading, or executing DeFi strategies - Over time, the percentage allocation will gradually increase until it reaches 100%. READ MORE ABOUT THE DAO (https://medium.com/@blue.chick.nfts/the-mighty-chick-dao-empowering-nft-holders-to-shape-the-future-of-the-blue-chick-project-5e2880ae0ac3) What’s next? Lots of alpha…We have big plans for the Blue Chicks NFTs besides delivering awesome gaming experiences, growing the DAO’s treasury, and sharing the gains. Above all, we are focusing on building a community and binding it together to create a feeling of true belonging and ownership that will help in deciding the development, growth, and direction of the Blue Chicks story and ecosystem. If you want to be part of this journey, be sure to join our Discord, share your thoughts and ideas – and we’ll catch you Chicks on the RADIX network! To meet new friends… - Come say Hello in the  Discord (https://discord.com/invite/SHVcwHKUNG) - Follow @BlueChickNFTs on  Twitter (https://twitter.com/blueChickNFTs) - Check our  Website (archived) (https://web.archive.org/web/20241108170251/http://bluechicknfts.wtf/)  – the live site is offline. ## Radix Mainnet (Babylon) URL: https://radix.wiki/contents/tech/releases/radix-mainnet-babylon Updated: 2026-09-05 Summary: Babylon [ /ˈbæbəˌlɑn/ ] is the current version release of the Radix network that debuted smart contracts and the Radix Engine execution environment. T… DEVELOPMENT Launch Date Sept 28, 2023 (https://www.radixdlt.com/blog/babylon-mainnet-upgrade-complete) Antecedent Alexandria (Developer Environment) (/contents/tech/releases/radix-developer-environment-alexandria) Postcedent Xi’an (/contents/tech/releases/radix-mainnet-xian) License Radix License, v1 (https://github.com/radixdlt/babylon-node/blob/main/LICENSE) LEDGER State Model Sharded (/contents/tech/core-concepts/sharding) Shard Groups 1 (/contents/tech/core-concepts/shard-groups) Sybil Protection Delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) Consensus Protocol Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) (unsharded – single shard group), a variant of the original HotStuff (https://arxiv.org/abs/1803.05069) BFT Execution Environment Radix Engine (/contents/tech/core-protocols/radix-engine) v2 Programming Language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Networking Babylon node (https://github.com/radixdlt/babylon-node) Validator Node (/contents/tech/core-concepts/validator-nodes) Cap 100 Babylon (https://www.radixdlt.com/blog/babylon-mainnet-upgrade-complete) [ /ˈbæbəˌlɑn/ ] is the current version release of the Radix network (https://www.radixdlt.com) that debuted smart contracts and the Radix Engine (/contents/tech/core-protocols/radix-engine) execution environment. The migration (https://web.archive.org/web/20231024034126/https://www.youtube.com/watch?v=DIJbfZ_xPKE) from the Alexandria (/contents/tech/releases/radix-developer-environment-alexandria) release occurred at epoch 32717 on the 28th September 2023. The stream that carried it live, run by Ociswap (/ecosystem/ociswap) rather than by Radix, now answers LOGIN_REQUIRED on YouTube, so the link above goes to the Internet Archive’s capture of 24 October 2023. Features Native Assets Assets like tokens being ‘native’ means that they are in-built, first-order functions of the language (https://learn.radixdlt.com/article/what-are-native-assets) , rather than being second-order prescriptions of a smart contract. Tokens, NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) , badges (https://docs.radixdlt.com/docs/auth) , and pool units are all ‘ resources (/contents/tech/core-concepts/resources) ’ in this paradigm, as understood by the Radix Engine (/contents/tech/core-protocols/radix-engine) . Native assets offer benefits for both ease and security of dApp development and improved user experience in the Radix Wallet (/contents/tech/core-protocols/radix-wallet) . Each asset's unique behaviour and data are expressed in the resource configuration rather than complex smart contract code, allowing the Radix Wallet (/contents/tech/core-protocols/radix-wallet) to display all necessary information in a clear, human-readable way. In the future, physical scanning of Native Assets through NFC technology will also be possible. All Native Assets are held in user Smart Accounts (/contents/tech/core-protocols/smart-accounts) , which include the ability to prove control through a signed challenge. Smart Accounts A smart account is a component on the Radix ledger that can hold assets and allow logical operations on those assets (https://learn.radixdlt.com/article/what-are-smart-accounts) . This includes multi-factor authentication and gated deposits. Smart accounts can be created ‘virtually’ without a transaction and are easily configured via the Radix Wallet. Account Abstraction The Babylon (https://www.radixdlt.com/blog/babylon-mainnet-upgrade-complete) release will introduce account abstraction, simplifying user interactions with the Radix platform and providing an improved experience compared to Ethereum (https://ethereum.org) 's EIP-4337. This feature will be more easily updated and adopted across the ecosystem. Radix Wallet The Radix Wallet is an iOS / Android application built specifically for Radix’s Babylon release (https://www.radixdlt.com/articles-learn/start-here-radix-wallet-user-guide) and designed for native DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) and web3 use. The wallet will replace the current Radix desktop wallet and is expected to offer improved security and user experience, allowing users to import their Olympia (https://www.radixdlt.com/blog/radix-olympia-mainnet-is-coming) JSON files and passwords without entering seed phrases online. This feature is designed to protect users from keylogger attacks. Personas (/contents/tech/core-protocols/personas) A persona is a set of user data that resides in the Radix Wallet (https://learn.radixdlt.com/article/what-are-personas-and-identities) . Personas may be tailored to contain web3 information such as a wallet address as well as personal information such as an email address, phone number and address. The information is stored on-chain, reducing the burden of data liability and risk of theft. Personas can be selectively hidden and revealed when interacting with decentralized applications (dApps), which also enables password-less login on web3 websites (https://learn.radixdlt.com/article/what-are-personas-and-identities) , verified by a cryptographic ‘challenge’. Transaction Manifests (/contents/tech/core-protocols/transaction-manifests) Transaction manifests are a feature of the Radix Wallet that provides the user with a human-readable summary of every operation within an atomic transaction (https://learn.radixdlt.com/article/what-are-transaction-manifests) before it is signed. Additionally, transaction manifests can include authorization using badges (https://docs.radixdlt.com/docs/user-badge-pattern) , payment of transaction fees, and validation of resource amounts to ensure guaranteed outcomes for users. These manifests are human-readable, so developers and clients of his software can easily understand what they are signing. The final transaction is created by converting the manifest into a binary representation and cryptographically signing it. This allows them to be efficiently sent over the network and processed by the Radix Engine. Delegated Fees Once blueprints and components (/contents/tech/core-concepts/blueprints-and-packages) are live, the Radix Engine (/contents/tech/core-protocols/radix-engine) will enable transaction fees to be born by applications (https://youtu.be/qEWuLQmp8P0?t=475) rather than users. Radix Connect (/contents/tech/core-protocols/radix-connect) Radix Connect (/contents/tech/core-protocols/radix-connect) is an encrypted method to securely link a Radix Wallet on a mobile phone to a desktop instance (https://learn.radixdlt.com/article/what-is-radix-connect) by scanning a QR code on a browser extension called Radix Connector. Radix Connect is a technology that enables users to access DeFi and Web3.0 dApp (https://learn.radixdlt.com/article/what-is-radix-connect) sites on their desktops while having a mobile-first experience on their Radix wallet. As a user, you can link your Radix Wallet on your mobile phone to your desktop browser in a one-time setup process. The Radix Connector browser extension for desktop displays a QR code that the Radix mobile wallet scans to enable automatic connection when a dApp website attempts to connect to the wallet. Connections are fully encrypted end-to-end and peer-to-peer, ensuring message security and eliminating the need for central servers. Radix Connect uses WebRTC and special communication protocols for efficient transactions and wallet data transfers, even if the devices are on different networks. Additionally, the Radix wallet can connect to mobile websites via "deep linking" by passing messages directly between the wallet app, the mobile browser app, and the dApp running on top of it. Ledger-Enforced Royalties The Babylon (https://learn.radixdlt.com/article/what-is-radixs-babylon-mainnet) release aims to improve the functionality of the Radix platform for developers. One of its key features is the ability for developers to add a small fee to every transaction that uses their blueprints or components (/contents/tech/core-concepts/components) and have them enforced automatically by the Radix Engine (/contents/tech/core-protocols/radix-engine) . Radix Web UI SDK The Radix Web UI SDK is a software development kit that allows developers to create user interfaces for decentralized applications on the Radix platform. It provides a set of tools and libraries for building web-based frontends that interact with the Radix Engine and the Radix Wallet. This allows developers to create custom interfaces for their dApps that are tailored to their specific needs and design requirements. Gateway SDK The Radix Gateway SDK (/developers/frontend/02-gateway-sdk) is a software development kit that enables developers to create applications that interact with external systems and blockchains. This allows developers to connect their decentralized applications to other networks and services, such as payment gateways, data feeds, and identity providers. The Gateway SDK provides a set of tools and libraries for building custom gateways that interface with the Radix Engine and the Radix Wallet, allowing developers to create dApps that can interact with the broader ecosystem of blockchain and web3 technologies. Radix Engine Toolkit (https://github.com/radixdlt/radix-engine-toolkit) The Radix Engine Toolkit (https://github.com/radixdlt/radix-engine-toolkit) is a set of tools and libraries that developers can use to build custom extensions for the Radix Engine. These extensions can include custom transaction types, smart contracts, and other features that are not available in the core engine. The toolkit provides developers with a framework for building decentralized applications on the Radix platform. Liquid Staking Units Liquid Staking Units (LSUs) are a key feature of the upcoming Babylon update to the Radix distributed ledger. LSUs function as special tokens that users receive in exchange for staking XRD (/contents/tech/core-protocols/xrd-token) on the Radix network (https://www.radixdlt.com) . The introduction of LSUs will change the way decentralized applications (dApps) interface with staking, simplifying the process for users and developers alike. When a user issues a stake request, they receive an LSU, which represents a claim on a percentage of the total amount of staked XRD held by the validator they staked with. Each LSU has a specific cost basis, depending on the price of XRD when the dApp executed the stake. To unstake all or part of an LSU, the dApp calls the unstake() function, passing the fraction of the LSU the user wants to unstake. Users receive their original XRD amount back, along with any staking emissions earned. One potential issue with this model is that users who frequently stake and unstake or dollar-cost average (DCA) may accumulate numerous LSU tokens in their wallet, each with a separate RSI. To solve this problem, a new component will be introduced to provide a simple interface for staking and unstaking. This new component will allow users to think of the LSU pool token as a single entity, abstracting away the underlying complexity. Additionally, the new component will implement a smart algorithm associated with the unstaking process, which will choose the most tax-efficient way to perform withdrawals. For most countries, this will likely be LIFO (last in, first out) to maximize the tax treatment for long-term capital gains. Token Types Soulbound tokens ‘Soulbound’ tokens cannot be transferred to another address so are useful for assets that shouldn’t be shared or sold on, such as concert tickets. Recallable Token Types Babylon will enable tokens to be leant and recalled after a set time. Test Networks RCNet v1 Radix Babylon RCnet v1 was a test network developed by RDX Works (/ecosystem/rdx-works) and release on the 31st March, 2023 after a series of Betanet versions. RCnet aimed to provide a comprehensive set of tools and features for developers, early integrators, and exchanges. Transaction Review within the Wallet The latest iOS Wallet preview build released with RCnet allows users to review transactions. While the functionality is still under development, users can monitor their accounts' activities, badges (/contents/tech/core-concepts/badges) , application interactions, and deposits. Future updates plan to include: - User-customizable guarantees on deposits - Special views for specific transaction types - Advanced view for scrutinizing transaction manifests - Metadata-defined icons for applications, components, and resources Core API (https://docs.radixdlt.com/docs/network-apis) RCnet's Core API (https://docs.radixdlt.com/docs/core-api-providers) is designed to cater to key integrators like exchanges. Unlike traditional crypto transaction models that follow a "sender-recipient" pattern, Babylon uses a more complex system. The Core API (/contents/tech/core-protocols/radix-core-api) aims to simplify the Babylon integration path for exchanges and third parties. Personas and Off-ledger Data Sharing Personas in the Wallet preview facilitate data sharing between users and dApps. This feature allows dApps to request personal data fields directly from the Radix Wallet, making the user experience more streamlined. Radix dApp Toolkit (https://github.com/radixdlt/radix-dapp-toolkit) Formerly the Radix Connect Button, the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) provides a unified interface for frontend developers. It allows automatic session management, data caching, and notifications about transactions and requests. Metadata Standards RCnet introduces a preliminary set of metadata standards for better integration between on- and off-ledger systems. This enables better information presentation to users and offers a defense against copycat dApps. Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) Aimed at developer community feedback, the Radix Engine Toolkit is slated to include: - A TypeScript target for frontend developers - Command-line version for Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developers - New layer of functions for transaction building & signing Roadblocks - The Gateway API (https://docs.radixdlt.com/docs/network-gateway) has yet to achieve a stable state. - Radix Off-Ledger Authentication ( ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) ) tooling remains incomplete. - Fee table adjustments are still under research. RCnet v2 Babylon RCnet v2 was a test network launched on July 6, 2023, as a precursor to the Babylon mainnet upgrade. The release primarily focused on Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , the scripting language for decentralized applications on the network, and the Radix Engine. RCnet v2 was released in two phases, with the first phase featuring "low-level" components such as nodes and the Radix Engine, and the second phase rolling out updated versions of additional tools and services. Developer Tools RCnet v2 brought several updates to developer interfaces and tools: - Redesigned authentication developer interface: The new system improves how developers specify authentication for their applications. - Native pools and pool units: A system for creating liquidity pools was introduced, which allows Radix Wallet to recognize "pool units" or liquidity provider tokens. - Better handling for referencing blueprints, components, and resources: The new syntax makes it easier to interact with different components and resources. - Fee table adjustments: The fee structure was revamped to reflect real-world computational costs more accurately. Scrypto Development With the release of RCnet v2, Scrypto became feature-complete for the Babylon mainnet upgrade. The scripting language underwent several enhancements: - Improved authentication methods: The new system simplifies the process of specifying roles and permissions. - Native liquidity pool blueprints: New blueprints were introduced for creating various types of liquidity pools. - Syntax and Error Handling: Syntax has been revised to make development more intuitive, and custom error messages were added to aid development. RCNet v3 Babylon RCnet v3 is a test network released on August 31, 2023, serving as the last major test network version before the Babylon mainnet upgrade. Developed to provide a stable environment for developers to build and test applications, the test network focuses on stability and minor improvements, assuring developers that applications compatible with RCnet v3 will function as expected on the Babylon mainnet. Babylon RCnet v3 has made a number of advancements primarily in areas of system stability and developer tools. This aims to assist developers in building and testing their applications more efficiently and effectively. Developer Tools Alongside the RCnet v3 release, various tools have been updated or introduced to aid developers in building and testing applications. These include: - Radix Wallet Preview & Connector Extension - Radix dApp Toolkit - Radix Engine Toolkit - Gateway API (https://docs.radixdlt.com/docs/gateway-sdk) - Dashboard Scrypto Development In response to community feedback, an entirely new unit testing framework has been developed, enabling faster and more targeted testing. Additionally, decimal-related types for fixed precision math have been revised to address more real-world scenarios and to allow the compiler to enforce proper handling of potential overflow scenarios. Protocol Updates Since Babylon Babylon shipped as protocol version babylon with the v1.0.0 node. The rules it introduced have since been amended three times by protocol updates (/contents/tech/releases/protocol-updates) , each enacted only after validators representing 75% of active stake signalled readiness for it: Anemone (epoch 70575, February 2024), Bottlenose (epoch 105353, June 2024, which added the Account Locker (/contents/tech/core-concepts/locker-blueprint) ), and Cuttlefish (epoch 160923, December 2024, which added the Transaction V2 format and subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) ). A fourth, Dugong, is listed as in development with no enactment date published. ## BCW Technologies URL: https://radix.wiki/ecosystem/bcw-technologies Updated: 2026-09-04 Summary: BCW Technologies , trading today as BCW Group , is an enterprise technology firm and venture studio building Web3, AI and cloud infrastructure. It is… BCW Technologies Type Enterprise Web3, AI and cloud infrastructure firm and venture studio Trading as BCW Group (https://www.bcw.group/) Founded 2017 Products (Aug 2026) Anseta (ex-stakeFi), Arkhia (https://docs.arkhia.io/) (site down), Hashport, HNS Radix presence None named on BCW's own surfaces; community directories attribute the Cadwynbloc validator to it Status 🟢 Active (as a company; no verified Radix work) X @bcw_llc (https://x.com/bcw_llc) LinkedIn bcw-group2025 (https://www.linkedin.com/company/bcw-group2025/) BCW Technologies, trading today as BCW Group (https://www.bcw.group/) , is an enterprise technology firm and venture studio building Web3, AI and cloud infrastructure. It is unrelated to the similarly-named global communications agency formerly called Burson Cohn & Wolfe. Its own site describes it as a "SOC 2 Type II enterprise solutions firm and venture studio" and organises its work into six verticals: staking, AI solutions, cloud, Web3 infrastructure, ventures and partnerships. The site footer records AICPA SOC 2 compliance and ISO 27001 self-certification, and the company holds a listing in the Google Cloud partner directory (https://cloud.google.com/find-a-partner/partner/bcw-group) . Products BCW's own products page (https://www.bcw.group/products/) lists four products as of 24 August 2026, and every one of them is aimed at networks other than Radix. - Anseta, the institutional staking platform launched as stakeFi. stakefi.network (https://stakefi.network/) now serves the Anseta site, whose protocol list names Ethereum, Solana, Avalanche, XDC, Hedera, Polygon, Injective, Monad, Polymesh, Canton, Midnight, EigenLayer and a dozen more. Radix is not among them. - Arkhia, a Web3 API and RPC gateway sold alongside Google Cloud Marketplace builds, ZK proofs and an x402 facilitator service. Its explorer and metrics products are Hedera-specific and its chain-endpoints page (https://web.archive.org/web/20260612235810/https://www.arkhia.io/chain-endpoints/) offers bespoke endpoints without naming Radix. Its website no longer answers. Read on 4 September 2026, arkhia.io resolves and redirects to www.arkhia.io, which accepts the TCP connection on ports 80 and 443 and then returns nothing at all — three thirty-second requests with a browser user agent produced zero bytes each, and a ninety-second follow of the redirect never completed. That is a hung host rather than a bot wall, which answers fast and answers with something. The Internet Archive (https://web.archive.org/web/20260613000000*/www.arkhia.io*) dates the silence: its last successful capture of the site and of every subpage is 12–13 June 2026, while its crawler reached explorer.arkhia.io on 22 July and 29 August. The product itself has not gone with the site — docs.arkhia.io (https://docs.arkhia.io/) and explorer.arkhia.io (https://explorer.arkhia.io/) both answer 200 — and neither has the company: bcw.group (https://www.bcw.group/) , stakefi.network (https://stakefi.network/) , hashport.network (https://www.hashport.network/) and hashgraph.name (https://hashgraph.name/) all answered 200 in the same pass. The description above is therefore read from the archived capture, not from a live page. - Hashport, described on BCW's products page as an interoperability bridge connecting Hedera with the EVM world, and still linked there as a live product. hashport.network (https://www.hashport.network/) itself carries a wind-down notice: the bridge was permanently decommissioned on 31 May 2026 at 12:00 UTC, wrapped assets are permanently unredeemable, and post-shutdown support has ceased. - HNS, the Hedera naming service (https://hashgraph.name/) . Two products earlier versions of this page described are gone from that list. Blockpour, the on-chain data analytics platform, no longer runs under its own name: blockpour.com returns an HTTP 302 redirect to supra.com (https://supra.com/) . TOKO, the tokenisation-as-a-service platform, is no longer listed by BCW at all. Radix connection What this wiki can verify about BCW's involvement with Radix (/contents/tech/releases/radix-mainnet-babylon) is narrow, and it should be read as narrow. Nothing on bcw.group, on its products page, on arkhia.io or on the Anseta site mentions Radix or XRD. A paginated read of the Gateway (https://docs.radixdlt.com/docs/network-gateway) 's validator register at epoch 337,829 (24 August 2026, 17:02 UTC) returns 287 validator components, 188 of them registered, and not one carries "BCW", "Arkhia" or "Anseta" in its on-ledger name or declared website. The tie the community records is a validator. The community-run directory radixecosystem.com (https://radixecosystem.com/projects/bcw-technologies) lists BCW Technologies with validator_rdx1sv2rav…tj4fem2p, which is named Cadwynbloc on ledger. Read at the same epoch, that validator (/contents/tech/core-concepts/validator-nodes) is registered and in the active set, ranked 29th of 188 registered validators with 68,559,800 XRD delegated to it, about 1.47% of the stake securing the network. Its on-ledger description reads "Radix Mainnet Validator operated by Cadwynbloc Consulting", and the website it declares, cadwynbloc.com (https://cadwynbloc.com/) , is a three-word splash page naming neither BCW nor Radix. The attribution is the directory's rather than the operator's, and this page records it as that. One thing about that validator is worth knowing if you are staked to it. Its stored fee factor still reads 0.5, but a fee-change request to 0.75 took effect at epoch 332,966 on 7 August 2026, so the fee it actually charges is 75%. Delegated stake there has not moved since: 68,350,833 XRD at that epoch against 68,559,800 XRD today, a rise of 0.3%. The gap between the fee a validator stores and the fee it charges is set out on Validator Nodes (/contents/tech/core-concepts/validator-nodes) , and the fee market that followed the subsidy on Validator Subsidy Sunset (/contents/history/validator-subsidy-sunset) . External Links - BCW Group – official site (https://www.bcw.group/) - BCW Group – Products (https://www.bcw.group/products/) - Arkhia – documentation (https://docs.arkhia.io/) – the live surface; www.arkhia.io has not answered since June 2026 ( archived chain-endpoints page, 12 June 2026 (https://web.archive.org/web/20260612235810/https://www.arkhia.io/chain-endpoints/) ) - Anseta (formerly stakeFi) – institutional staking (https://stakefi.network/) - hashport – decommissioning notice (https://www.hashport.network/) - Google Cloud partner directory – BCW Group (https://cloud.google.com/find-a-partner/partner/bcw-group) - BCW Technologies – Radix Ecosystem directory (https://radixecosystem.com/projects/bcw-technologies) ## Anthic URL: https://radix.wiki/ecosystem/anthic Updated: 2026-09-04 Summary: Anthic was an intent-based trading platform planning to launch on the Radix network in Q1 2025. The platform aimed to bridge the gap between centraliz… Anthic was an intent-based trading platform (https://anthic.medium.com/introducing-anthic-640b39e40688) planning to launch on the Radix network in Q1 2025. The platform aimed to bridge the gap between centralized exchange (CEX) liquidity and decentralized exchange (DEX) security by implementing a hybrid architecture that combined off-ledger expression of liquidity with on-chain execution. Status note (July 2026): Anthic's technical documentation (docs.anthic.io) and primary domain (anthic.io) no longer resolve, and the intent-based trading platform does not appear to have launched publicly on Radix. The surviving public record is the project's Medium posts (https://anthic.medium.com/introducing-anthic-640b39e40688) . Overview The platform's core innovation was its Flash Liquidity system (https://anthic.medium.com/flash-liquidity-12a566e30498) , which allowed market makers to provide liquidity without pre-funding on-chain pools. This approach enabled real-time, low-slippage trades by combining centralized exchange efficiency with decentralized finance (DeFi) principles. Flash Liquidity aggregated liquidity from multiple sources, including both on-ledger and off-ledger assets, while maintaining the non-custodial and permissionless nature of DeFi. At launch, Anthic planned to integrate with leading market makers (https://anthic.medium.com/anthic-launch-parters-33cb59c28a10) such as Keyrock, G-20, and Portofino, alongside Radix DEXs including Ociswap (/ecosystem/ociswap) , CaviarNine (/ecosystem/caviarnine) , and Astrolescent (/ecosystem/astrolescent) . The platform initially targeted support for at least 25 of the top crypto assets, with plans to expand coverage to the top 100 and beyond. A key feature of Anthic was its gasless trading system (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) , which enabled trades to complete within 5 seconds or less. The platform utilized Radix's native mechanisms including Subintents, an off-ledger Order Messaging System, and an on-ledger ecosystem of Solvers to facilitate efficient trade execution. Rather than introducing a new token, Anthic's economic model (https://anthic.medium.com/anthic-fees-db65f8049f52) was built around $XRD, the native token of the Radix network. The platform implemented a maker-taker fee model with 100% of fees being converted to $XRD through market purchases. These fees were then distributed with 40% locked from circulation, 30% shared with integrated DEXs, and 30% allocated to development and operations. The platform entered public testnet in December 2024 (https://anthic.medium.com/anthic-live-on-testnet-8e5f416fd1ae) , featuring full end-to-end functionality including live price feeds from market maker partners, test trading capability using flash liquidity, and test solver bots matching orders as they would in production. Technology Anthic's architecture combined off-ledger liquidity expression with on-chain execution through several key technological innovations: Flash Liquidity Flash Liquidity (https://anthic.medium.com/flash-liquidity-12a566e30498) enabled market makers to provide liquidity without pre-funding on-chain pools. The system used Instamint, powered by Instabridge (/ecosystem/instabridge) , to allow market makers to mint wrapped assets on Radix as needed, using short-term (<24h) lines of credit. This approach significantly improved capital efficiency as market makers only moved assets on-chain when trades were confirmed. Intent-Based Trading Anthic's intent-based system differed from traditional Automated Market Makers (AMMs) by moving order matching and coordination off-ledger while maintaining on-chain settlement. Unlike traditional DEX systems (https://youtu.be/6YEASF6diOQ) that require separate transactions for makers and takers, Anthic's intent system allowed both sides of a trade to be bundled into a single transaction, significantly reducing complexity and costs. Order Messaging System The Order Messaging System served as the core off-ledger infrastructure, facilitating interaction between liquidity providers, DEXs, and their users. It maintained a Subintent Pool similar to a blockchain mempool, where trade intentions were stored and matched before on-chain execution. The system enabled (https://youtu.be/6YEASF6diOQ) market makers to express liquidity they hold on other venues without needing to move inventory until execution. Subintent Architecture Subintents functioned as signed definitions of trade parameters, authorizing transactions within predefined conditions such as price, slippage, and time limits. This approach differed substantially (https://youtu.be/6YEASF6diOQ) from other intent-based platforms like COW Swap, as Anthic's subintents integrated directly with Radix's system-level architecture rather than existing solely at the application layer. Settlement Process The settlement process (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) completed within 5 seconds, significantly faster than COW Swap's 5-minute auction process (https://youtu.be/6YEASF6diOQ) . The rapid settlement involved: - Users submitted signed subintents through DEX interfaces. - Market makers provided real-time pricing streams. - The Order Messaging System matched compatible subintents. - Solvers bundled matched subintents into transactions. - Transactions were executed on the Radix ledger. Front-Running Prevention Anthic prevented front-running through its price stream mechanism (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) . Unlike COW Swap's auction-based approach (https://youtu.be/6YEASF6diOQ) , Anthic required market makers to provide pricing before knowing specific trade details. Once a user committed to a price, the market maker could not modify it, effectively eliminating the possibility of sandwich attacks without requiring lengthy auction periods. Features - Real-Time Trading: Anthic provided near-instantaneous trade execution (https://anthic.medium.com/anthic-live-on-testnet-8e5f416fd1ae) , with transactions typically completing within 5 seconds. This represented a significant improvement (https://youtu.be/6YEASF6diOQ) over other intent-based platforms like COW Swap, which requires 5-minute auction periods for trade execution. - Cross-Chain Asset Support: The platform enabled trading of any crypto asset (https://anthic.medium.com/introducing-anthic-640b39e40688) issued on Radix. Market makers could express liquidity (https://youtu.be/6YEASF6diOQ) they hold on other venues without moving inventory until execution, allowing them to efficiently provide deep liquidity across multiple chains. - Capital Efficiency: Through Flash Liquidity (https://anthic.medium.com/flash-liquidity-12a566e30498) , market makers could provide liquidity across multiple assets without locking up capital in specific pools. This addressed a key limitation (https://youtu.be/6YEASF6diOQ) of other intent-based platforms like COW Swap, where market makers must pre-fund their positions with on-chain inventory before trading. - User Security: All trades maintained full non-custodial security (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) through the use of cryptographically signed subintents. Users retained complete control of their assets throughout the trading process, with transactions only executing when all predefined conditions were met. - Gasless Transactions: Users did not need to hold $XRD (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) for transaction fees, as trades could be executed using the traded asset itself. The bundling of maker and taker actions (https://youtu.be/6YEASF6diOQ) into single transactions further reduced gas costs compared to traditional DEX approaches requiring separate transactions. - Price Improvement: The platform implemented a sophisticated price aggregation system (https://anthic.medium.com/introducing-anthic-640b39e40688) that combined liquidity from multiple sources. Market makers streamed real-time pricing (https://youtu.be/6YEASF6diOQ) that accurately reflected current market conditions across all venues where they operate, ensuring users receive optimal pricing while maintaining the security of decentralized trading. - DEX Integration: Anthic integrated with existing Radix DEXs (https://anthic.medium.com/introducing-anthic-640b39e40688) such as Ociswap, CaviarNine, and Astrolescent, allowing them to combine their native AMM liquidity with Anthic's aggregated liquidity. - Front-Running Protection: The platform's intent-based architecture (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) prevented front-running through a unique price streaming mechanism. Unlike traditional AMMs (https://youtu.be/6YEASF6diOQ) where orders can be seen and front-run, or auction-based systems that require long waiting periods, Anthic required market makers to commit to prices before seeing specific trades, eliminating the possibility of sandwich attacks while maintaining rapid execution. Market Integration Market Maker Partnerships Anthic had established strategic development partnerships (https://anthic.medium.com/anthic-launch-parters-33cb59c28a10) with three major crypto market makers: Keyrock, G-20, and Portofino. Keyrock, supported by industry players including Ripple and SIX Fintech Ventures, operates on over 85 trading venues and collaborates with major platforms like Binance and Kraken. G-20 maintains activity across 60 crypto exchanges and serves hundreds of clients with various token projects. Portofino Technologies provides liquidity on over 100 tokens and holds registrations with the UK FCA and BVI Financial Services Commission. DEX Integration Framework Anthic's integration model enabled existing Radix DEXs to leverage its liquidity alongside their native pools. The platform provided DEXs with an API framework that included order book access, fee information, and limit order functionality. Initial integrations included Ociswap (/ecosystem/ociswap) , CaviarNine (/ecosystem/caviarnine) , and Astrolescent (/ecosystem/astrolescent) , with trades executed through these platforms benefiting from both their native AMM liquidity and Anthic's aggregated market maker liquidity. Asset Support The platform initially targeted support (https://anthic.medium.com/introducing-anthic-640b39e40688) for at least 25 of the top crypto assets by market capitalization, with plans to expand to the top 100. Through Instabridge, Anthic already supported major assets including BTC, ETH, USDC, and USDT on the Radix network. Revenue Sharing Anthic implemented a DEX revenue sharing program (https://anthic.medium.com/anthic-fees-db65f8049f52) where 30% of all trading fees were distributed to integrated DEXs based on their proportional contribution to trading volume. This incentivized DEX participation and helped grow the broader Radix trading ecosystem. Integration Technology The platform provided comprehensive technical documentation and SDKs for integration partners. This included detailed APIs for trade execution, Flash Liquidity provision, and solver operations. DEXs could utilize these tools to offer their users access to Anthic's liquidity while maintaining their own user interface and trading experience. Economic Model Fee Structure Anthic operated on a maker-taker fee model (https://anthic.medium.com/anthic-fees-db65f8049f52) with no maker fees at launch to encourage liquidity depth. Taker fees were set at 0.1% of trade value, with progressive discounts available based on trading volume and $XRD staking levels. Fee Distribution The platform converted 100% of collected fees to $XRD (https://anthic.medium.com/anthic-fees-db65f8049f52) through market purchases, which were then distributed as follows: - 40% was locked away and removed from circulating $XRD supply. - 30% was distributed to integrated DEXs proportional to their trading volume. - 30% supported Anthic's development, marketing, and operations. User Incentives The platform implemented a tiered fee structure (https://anthic.medium.com/anthic-fees-db65f8049f52) with six levels, from Standard to VIP 5. Users could qualify for reduced fees based on: - 30-day trading volume ($10,000 to $10,000,000+). - $XRD staking amount (75,000 to 3,000,000 LSU). - Taker fees decreased from 0.10% at the Standard tier to 0.05% at VIP 5. DEX Revenue Share Integrated DEXs received (https://anthic.medium.com/anthic-fees-db65f8049f52) a share of trading fees proportional to the volume they contributed. To qualify, DEXs had to register with Anthic and receive an authenticated API. This incentivized DEX participation and helped grow the Radix trading ecosystem. Settlement Fees The platform charged two types of settlement fees: - A solver fee paid to transaction bundlers. - A transaction execution fee covering network costs. - A portion of the transaction execution fee could be rebated to users if the actual execution cost was lower than the initial charge. Development Status Testnet Launch Anthic launched on the Radix public testnet (https://anthic.medium.com/anthic-live-on-testnet-8e5f416fd1ae) in December 2024, featuring a complete end-to-end implementation. The testnet deployment included live price feeds from market maker partners, test trading capability using flash liquidity, and test solver bots matching orders in real-time conditions. Developer Resources The platform had released comprehensive technical documentation covering integration patterns for DEXs, market makers, and solvers. A developer SDK wrapping the Anthic API was available on GitHub, providing tools for building against the platform's core functionality. Integration Progress Market maker integration (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) testing was underway, with partners including Keyrock, G-20, and Portofino actively connecting to the system. The platform had successfully demonstrated order fills and price streaming through its test deployment. Current Features The testnet implementation included: - Live indicative price streams (https://anthic.medium.com/anthic-live-on-testnet-8e5f416fd1ae) from high liquidity venues. - Aggregated pricing from multiple market makers. - Functional test APIs for integration testing. - Live solver bundling and transaction submission. - Test deployment of Instamint integration. Mainnet Timeline Anthic targeted a Q1 2025 mainnet launch (https://anthic.medium.com/introducing-anthic-640b39e40688) with initial support for at least 25 top crypto assets. The platform planned to expand coverage to the top 100 assets and beyond post-launch, while maintaining its focus on deep liquidity and efficient price execution. Technical Architecture Order Messaging System The Order Messaging System functioned as Anthic's core infrastructure, coordinating liquidity and order flow between DEXs, liquidity providers, and DeFi applications. It maintained a Subintent Pool that collected and matched signed trade intentions before on-chain settlement. The system offered Web2-style API integration familiar to market makers, closely resembling Request for Stream (RFS) models used in centralized exchanges. Solver Network Solvers played a critical role in the Anthic ecosystem, receiving wrapped versions of limit order subintents from both DEXs and market makers. They bundled coincident subintents into valid transactions and submitted them to the Radix network. Solvers received both a flat fee in $XRD and a transaction execution fee for successful submissions. Market Maker Integration The platform employed a sophisticated Flash Liquidity system (https://anthic.medium.com/flash-liquidity-12a566e30498) for market maker integration, featuring: - Real-time price streaming infrastructure. - Multi-session handling capability. - Authenticated API access. - Fill reconciliation mechanisms. - Post-trade settlement processes. DEX Aggregation The DEX integration framework enabled existing Radix DEXs to combine their native AMM liquidity with Anthic's aggregated market maker liquidity. This included: - Order book access API. - Fee computation systems. - Limit order submission. - Price aggregation mechanisms. Security Architecture The system implemented (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) multiple security layers: - Cryptographic validation of subintents. - Time-bound execution windows. - Slippage protection mechanisms. - Front-running prevention through price commitment. - Non-custodial trading workflows. Infrastructure Components The platform utilized several key infrastructure components (https://anthic.medium.com/anthic-deep-dive-ca670e8d5235) : - Instamint for on-demand asset minting. - Instabridge for cross-chain asset bridging. - Subintent management system. - Price feed aggregation. - Transaction construction and validation. Website (4 September 2026): anthic.io resolves again and answers HTTP 200, and the project has not come back with it. The 200 is 114 bytes of JavaScript redirecting to /lander, which serves a GoDaddy (https://www.godaddy.com/) parking page — the nameservers are ns59 and ns60.domaincontrol.com and the document declares window.LANDER_SYSTEM and pushes a parking marker. WHOIS shows why: the domain was created on 28 August 2024, its registrar registration expired on 28 August 2026, and it sits in autoRenewPeriod having been updated at 18:26 UTC on 3 September 2026, one day before this reading, with registry expiry now 28 August 2027. This is the same registration lapsing into a parking page and being auto-renewed, not a re-registration by a third party and not a relaunch. docs.anthic.io and app.anthic.io still have no DNS record at all, and the project has published nothing since. anthic.com is a different domain and a different owner — an unrelated Lithuanian cycling-tourism site, not a successor. The link stays off this page's facts table: a domain answering 200 from a parking lander is the plainest form of the caveat the operational-status index (/contents/resources/radix-ecosystem-operational-status) attaches to every website probe, which is that a domain outlives the project on it. ## Astrolescent URL: https://radix.wiki/ecosystem/astrolescent Updated: 2026-09-04 Summary: Astrolescent is a decentralized exchange (DEX) aggregator and cross-chain bridge on the Radix network. Its core product routes each trade across Radix… Type DEX Aggregator & Cross-Chain Bridge Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Founders Timan Rebel and Meronym (2021) Run by Timan Rebel Token $ASTRL (yield-bearing governance) Token Supply 36,000,000 (fixed) Docs docs.astrolescent.com (https://docs.astrolescent.com) Overview Astrolescent is a decentralized exchange (DEX) aggregator and cross-chain bridge on the Radix (/contents/tech/releases/radix-mainnet-babylon) network. Its core product routes each trade across Radix's leading DEXes to secure the best available price, splitting larger orders across multiple venues (https://docs.astrolescent.com) to minimise price impact. It aggregates liquidity from Radix DEXes including Ociswap (/ecosystem/ociswap) , CaviarNine (/ecosystem/caviarnine) and DefiPlaza (/ecosystem/defiplaza) , presenting a single swap interface over the whole market. Beyond aggregation, Astrolescent has expanded into a cross-chain bridge (https://astrolescent.com) – advertised as "fast and low-cost cross-chain bridging" – alongside token swaps, staking, limit orders, liquidity pools and a validator node. Astrolescent's team page (https://docs.astrolescent.com/astrolescent-docs/readme/team) names Timan Rebel and Meronym as its founders in 2021 and says the project "is currently ran by Timan". Rebel, an Amsterdam startup founder who also contributes to DefiPlaza (/ecosystem/defiplaza) and HUG (/ecosystem/hug) , was appointed the Radix Foundation's Interim Hyperscale (/contents/tech/research/hyperscale-500k-tps) Lead in November 2025. A co-founder, Michael Videtto, represented the project on Radix's own DeFi Download podcast (https://www.youtube.com/watch?v=ZNXrlm1SUB0) during the USDA stablecoin period in 2023, and does not appear on the team page. Products and Services Astrolescent bundles several DeFi services around its aggregator, each of which generates fees that flow to $ASTRL stakers: - DEX aggregator – the flagship product, routing and splitting swaps across Radix DEXes for optimal execution. - Cross-chain bridge – bridging assets in and out of the Radix network. - Limit orders – on-ledger limit-order execution against aggregated liquidity. - Liquidity pools – pools whose trading fees contribute to protocol revenue. - Staking & validator node – an Astrolescent-operated Radix validator (/contents/tech/core-protocols/radix-engine) , with staking that shares protocol revenue with $ASTRL holders. Per the documentation (https://docs.astrolescent.com) , stakers "receive a share of the fees generated by Astrolescent's aggregator, bridge, limit order, pools, and validator node." $ASTRL Token $ASTRL is the official yield-bearing governance token of Astrolescent. The protocol states that 100% of its profits are shared with $ASTRL stakers (https://docs.astrolescent.com) , drawn from all five revenue streams (aggregator, bridge, limit orders, pools and validator). Holders also qualify for recurring airdrops. The token's on-ledger facts are verifiable directly on the Radix ledger (resource resource_rdx1t4tjx4g3qzd98nayqxm7qdpj0a0u8ns6a0jrchq49dyfevgh6u0gj3, viewable on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4tjx4g3qzd98nayqxm7qdpj0a0u8ns6a0jrchq49dyfevgh6u0gj3) ): - Total supply – 36,000,000 $ASTRL, fixed: the minter authority is set to deny_all and locked, so no new tokens can ever be created. - Divisibility – 18 decimal places. - Supply controls – the token is not freezable and not recallable; a burner authority exists but supply cannot be inflated. As of 26 July 2026, $ASTRL traded at approximately 7.66 XRD (/contents/tech/core-protocols/xrd-token) (~$0.0079) per token. Ledger facts verified via the Radix Gateway on 26 July 2026; market figures move continuously. History Astrolescent originally planned a fully-collateralised stablecoin, $USDA, alongside its aggregator. In June 2023 the team announced it was discontinuing $USDA (https://medium.com/@astrolescent/astrolescent-back-to-our-core-d3dada04ab92) following the insolvency of its banking partner, Prime Trust, and refocused solely on the DEX aggregator. That "back to our core" pivot also set out plans to relocate operations from the US to the Netherlands, to move governance to a community DAO, and to share aggregator fees with $ASTRL holders. The revenue-sharing model has since gone live: $ASTRL is now a yield-bearing governance token that distributes protocol profits to stakers, and the product surface has grown from a single aggregator into the aggregator-plus-bridge suite described above. Early development updates and airdrops (https://medium.com/@astrolescent/development-updates-and-airdrops-c3ad733a07a6) to stakers marked the start of that transition. Funding and sustainability Asked directly in the main Radix group on 3 September 2026 whether Astrolescent was his full-time job, Timan Rebel answered at 20:36:57 UTC (https://t.me/radix_dlt/1001809) that it "used to be my fulltime job for about 2.5 years, living of my savings and the FND grants", and that he had "recently started a part-time position as CTO at a scale-up". It is the first public account of how the project has been paid for, and it names two sources rather than the product: his own savings, and grants from the Radix Foundation. The same message gives the reason the arrangement changed, and it bears directly on the revenue model described above. "I had hoped the bridge would generate enough volume, but Hyperlane didn't allow for fee-sharing and almost nobody swapped anymore via RocketX (https://www.rocketx.exchange/) ." The bridge is the newest of the five streams whose fees go to $ASTRL stakers and the one the front page advertises first, and by its operator's account it did not earn. Hyperlane (/ecosystem/hyperlane) is a permissionless protocol that anyone may deploy a route on, which is what makes it reachable at all; the other side of that openness is that it owes an integrator nothing, and the fee a warp route charges is the protocol's. The exchange came four days into the network halt (/contents/history/hyperlane-asset-drain-2026) , with every Hyperlane-bridged asset drained off Radix and the ledger stopped since 21:19 UTC on 31 August 2026. Astrolescent's own price feed has been serving the last quotes the pools produced before the stop. The project remains active and Rebel continues to run it. External Links - Astrolescent Website (https://astrolescent.com) - Astrolescent Documentation (https://docs.astrolescent.com) - $ASTRL token on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4tjx4g3qzd98nayqxm7qdpj0a0u8ns6a0jrchq49dyfevgh6u0gj3) ## Building on Radix URL: https://radix.wiki/developers Updated: 2026-09-03 Summary: Building on Radix asks you to unlearn one habit before anything else works. On most networks a token is a number your contract keeps in a mapping, and… Contract language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , a Rust dialect Execution Radix Engine (/contents/tech/core-protocols/radix-engine) Transactions Transaction manifests (/contents/tech/core-protocols/transaction-manifests) Test network Stokenet (/contents/tech/releases/stokenet) Front-end Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) , Gateway SDK (/developers/frontend/02-gateway-sdk) , ROLA (/developers/frontend/03-rola-authentication) Start here Installing Scrypto (/developers/getting-started/01-install-scrypto) Introduction Building on Radix asks you to unlearn one habit before anything else works. On most networks a token is a number your contract keeps in a mapping, and moving it means writing code that decrements one entry and increments another. On Radix the engine (/contents/tech/core-protocols/radix-engine) owns the asset (/contents/tech/core-concepts/asset-oriented-programming) . A resource (/contents/tech/core-concepts/resources) moves between vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) through the engine’s own rules, and a blueprint (/contents/tech/core-concepts/blueprints-and-packages) that tries to lose it will not compile into a transaction that commits. That single change removes a category of bug rather than a line of code, and it is why the learning path below starts with resources rather than with syntax. Where to start Installing Scrypto (/developers/getting-started/01-install-scrypto) is step one for everyone – the toolchain, a first blueprint, a package deployed to Stokenet (/contents/tech/releases/stokenet) . After that these four are a sequence, each assuming the one above it. Give manifests (/developers/transactions/01-manifest-language) more time than their position suggests: a Radix transaction states what it intends to do in a form the wallet (/contents/tech/core-protocols/radix-wallet) can show a user before they sign it. 1Getting Started3 guides · BeginnerInstall the toolchain, write a first blueprint, deploy to Stokenet and then mainnet. (/developers/getting-started) 2Scrypto9 guides · Beginner to AdvancedResources and NFTs, authorization and badges, testing, and the design patterns. (/developers/scrypto) 3Transactions5 guides · Intermediate to AdvancedThe manifest language, the transaction lifecycle, fees, addresses and entity types. (/developers/transactions) 4Frontend4 guides · IntermediateThe dApp Toolkit, the Gateway SDK, ROLA wallet login, and dApp verification. (/developers/frontend) Then, as the project needs it: Infrastructure (/developers/infrastructure) , AI Agents (/developers/ai-agents) , Tools (/developers/tools) . Agents The newest branch here is for software that acts on its own behalf (/contents/tech/core-concepts/radix-for-ai-agents) . Radix Context (/developers/ai-agents/radix-context) and Radix Skills (/developers/ai-agents/radix-skills) package the protocol’s documentation for coding agents, and x402 payments (/developers/ai-agents/ai-agents-and-x402) covers the emerging way an agent pays for a request it has just been refused. Radix’s subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) make that pattern unusually clean, because a client can commit to an exact payment without holding the XRD (/contents/tech/core-protocols/xrd-token) to pay the network fee (/developers/transactions/03-transaction-fees) . What to expect Scrypto (/contents/tech/core-protocols/scrypto-programming-language) is Rust, so the borrow checker is part of the job and the compile times are real. In exchange, most of what a Solidity (/contents/tech/comparisons/radix-vs-ethereum) audit looks for is unrepresentable: there is no reentrancy path through a resource transfer, no approve-and-drain (/contents/tech/core-concepts/native-assets-vs-token-approvals) , and no way to mint an asset a blueprint was not authorized (/contents/tech/core-concepts/access-rules-and-auth-zones) to mint. Whether that trade suits a given project is a judgment about the team as much as the protocol, and it is worth making before the first blueprint rather than after. Official documentation - Radix Technical Documentation (https://docs.radixdlt.com/docs) – the canonical docs site for the entire stack. - Scrypto: Learning Step-by-Step (https://docs.radixdlt.com/docs/learning-step-by-step) – from first blueprint to full dApp. - Official code examples (https://github.com/radixdlt/official-examples) and community Scrypto examples (https://github.com/radixdlt/community-scrypto-examples) – working blueprints to read and adapt. - Radix Engine (https://docs.radixdlt.com/docs/engine-tech-docs) – the asset-oriented state machine that runs transactions. - Radix dApp Toolkit (https://docs.radixdlt.com/docs/dapp-toolkit) – Connect Button, Wallet SDK, and Gateway SDK (/developers/frontend/02-gateway-sdk) in one interface. - ROLA (Radix Off-Ledger Auth) (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) – prove wallet ownership for login. - Radix Engine Toolkit (https://docs.radixdlt.com/docs/radix-engine-toolkit) – manifest (/contents/tech/core-protocols/transaction-manifests) construction, SBOR, and address derivation. - Network APIs (https://docs.radixdlt.com/docs/network-apis) – Gateway, Core, and System API overview. - Radix Wallet (/contents/tech/core-protocols/radix-wallet) – wiki reference for the Babylon (/contents/tech/releases/radix-mainnet-babylon) wallet. API specifications - Gateway API (https://docs.radixdlt.com/api-reference/gateway-api-specs.html) – read aggregated ledger state and submit transactions ( mainnet Swagger (https://mainnet.radixdlt.com/swagger/) ). - Core API (https://docs.radixdlt.com/api-reference/core-api-specs.html) – full-node API for integrators and the /stream/transactions event stream. - System API (https://docs.radixdlt.com/api-reference/system-api-specs.html) – node operations and health. SDKs and libraries - Radix dApp Toolkit (https://github.com/radixdlt/radix-dapp-toolkit) – the recommended front-end integration library (Connect Button + SDKs). - Gateway API SDK (npm) (https://www.npmjs.com/package/@radixdlt/babylon-gateway-api-sdk) – typed JS/TS client for the Gateway. - Core API SDK (npm) (https://www.npmjs.com/package/@radixdlt/babylon-core-api-sdk) – typed JS/TS client for the Core API (/contents/tech/core-protocols/radix-core-api) . - ROLA (npm) (https://www.npmjs.com/package/@radixdlt/rola) – verify Radix Off-Ledger Auth signatures server-side. - scrypto (https://docs.rs/scrypto/latest/scrypto/index.html) / scrypto-test (https://docs.rs/scrypto-test/latest/scrypto_test/) / radix-engine (https://docs.rs/radix-engine/latest/radix_engine/) – Rust crates on docs.rs. - Radix Rust SDK (/developers/infrastructure/radixdlt-rust-sdk) ( GitHub (https://github.com/genkipool/radixdlt-rust-sdk) ) – pure-Rust off-ledger primitives: ROLA (/developers/frontend/03-rola-authentication) auth, address derivation, keystores, and Radix Connect (/contents/tech/core-protocols/radix-connect) over WebRTC and iroh/QUIC. - radix-web3.js (/developers/tools/radix-web3-js) ( GitHub (https://github.com/xstelea/radix-web3.js) ) – a nine-package community TypeScript suite built on Effect: core client, Gateway client, wallet connect, transaction and streaming helpers, an SBOR “ez mode” (https://xstelea.github.io/radix-web3.js/sbor) schema builder, and the agent-first rdx-cli (https://www.npmjs.com/package/rdx-cli) . - Radix Wallet Connector (https://chromewebstore.google.com/detail/radix-wallet-connector/bfeplaecgkoeckiidkgkmlllfbaeplgm) – browser extension that bridges dApps to the wallet. Scrypto crates - scrypto-math (https://github.com/ociswap/scrypto-math) – high-precision math (exp, ln, pow) for Scrypto. - scrypto-avltree (https://github.com/ociswap/scrypto-avltree) – an on-ledger AVL tree data structure. - RRC-404 (/contents/tech/core-protocols/rrc-404) ( ice_rrc404v1 (https://github.com/aus87/ice_rrc404v1) ) – a hybrid fungible/non-fungible token standard for Radix, with a reference implementation in Scrypto. Community tools and explorers As the Radix Foundation (/ecosystem/radix-foundation) winds down, much developer infrastructure is now community-hosted. The following are actively maintained; the Tools (/developers/tools) section covers several of them at length. - RadixScan Console (https://console.radixscan.io/) – developer console and step-by-step Manifest Builder (https://console.radixscan.io/manifest-builder) that sends transactions straight to your wallet (switches between Mainnet and Stokenet). - RadixScan Dashboard (https://dashboard.radixscan.io/) – account, resource, and transaction explorer. - GenkiPool Community Tools (https://radix-community.genkipool.com/) – wallet connection, batched transactions, and one-transaction staking/unstaking across multiple validators. - ShardSpace (https://shardspace.app/) – create and manage dApp definitions (Mainnet and Stokenet). - Instruct (/developers/tools/instruct) ( app (https://instruct.radixbillboard.com/) ) – visual transaction manifest builder for Mainnet and Stokenet, from The Radix Billboard team. - Hookah (/developers/tools/hookah) ( GitHub (https://github.com/xstelea/hookah) ) – a self-hostable Radix event-monitoring and webhook-delivery platform (MIT-licensed): register triggers on on-ledger events and receive webhook callbacks when matching events appear in the transaction stream. Runs as a hosted service at hookah.ing (https://hookah.ing) . - Radix Desktop Tool (/developers/tools/radix-desktop-tool) ( GitHub (https://github.com/atlantis-l/Radix-Desktop-Tool) ) – open-source MIT desktop utility for batched single→multiple and multiple→multiple token transfers. For agents The AI Agents (/developers/ai-agents) section covers these in depth; what follows are the endpoints and indexes themselves. - RadixScan Agent Layer (https://ai.radixscan.io/) – keyless MCP server (https://ai.radixscan.io/llms.txt) for reading the ledger and building, validating, and simulating manifests (non-custodial; signing happens in the wallet). - RADIX.wiki MCP Server (/contents/resources/mcp-server) – this wiki’s own keyless MCP endpoint at radix.wiki/api/mcp, plus llms.txt, markdown twins and a ROLA-gated write path. - Awesome Radix MCP Servers (https://github.com/xstelea/awesome-radix-mcp-servers) – curated index of Radix MCP servers. - x402 (https://x402.org/) – the open HTTP-402 payment standard for AI agents and APIs; multi-chain implementation (https://github.com/xstelea/x402) with Radix support in development. Hyperscale (Xi’an) Hyperscale is the in-progress sharded (/contents/tech/core-concepts/sharding) execution layer for Radix’s Xi’an (/contents/tech/releases/radix-mainnet-xian) release, written in Rust, and the most active area of protocol development. It is expected to run a purpose-built VM (/contents/tech/core-protocols/vm-layer) written from scratch rather than a sharded Radix Engine (/contents/tech/core-protocols/radix-engine) , with the migration cost for existing dApps put at best case a recompile, worst case an automatic source transpiler (https://t.me/hyperscale_rs/10346) . The wiki’s account is at hyperscale-rs (/contents/tech/research/hyperscale-rs) . - hyperscale-rs (https://github.com/hyperscalers/hyperscale-rs) – the implementation, including the POLARIS leaderless BFT beacon-chain prototype. - Web3 Modules: Hyperscale (https://pprogrammingg.github.io/web3_modules/hyperscale/index.html) – community learning notes on the architecture. - Learn-Hyperscale-rs (https://github.com/leomagal/Learn-Hyperscale-rs) – community guides and flowcharts for Rust and distributed systems with Hyperscale-RS. Community and funding - Radix Developer Discussion (https://t.me/RadixDevelopers) on Telegram – where protocol and tooling questions actually get answered. - Official Discord (https://discord.com/channels/417762285172555786/968472959763243068) – the developer channel. - Radix ecosystem funding (/contents/history/radix-ecosystem-funding) – grant programmes, past and present, and how to apply. ## Radix Is Florence URL: https://radix.wiki/blog/radix-is-florence Updated: 2026-09-03 Summary: 7 min read Web1, 2 and 3 have all been compared to the Industrial Revolution because each has introduced new systems and organizations with the potent… Format Editorial / historical analogy (7 min read) Central idea Web3 resembles the 10th–14th century Commercial Revolution more than the Industrial one: what made Florence win was institutional substrate — trade routes, commercial treaties, a banking network and a legal system — laid down before the merchants arrived Companion piece Ten 10x Moments Coming to Web3 (/blog/ten-10x-moments-coming-to-web3) Dated claim Published in November 2023. Its technical section credits the Radix Engine (/contents/tech/core-protocols/radix-engine) ’s native assets and smart accounts with making applications “much easier to design and safer to manage” than Ethereum’s token-contract model, set against $3bn of 2022 hacks. Read that against the asset drain of 31 August 2026 (/contents/history/hyperlane-asset-drain-2026) , in which twenty-six transactions moved every Hyperlane-bridged asset on the network without an owner signing anything, and mainnet was halted: the stated cause was a flaw in the Radix Engine itself, in the same authorisation layer this essay credits Related Radix vs Ethereum (/contents/tech/comparisons/radix-vs-ethereum) · History of Radix (/contents/history) · Radix Engine (/contents/tech/core-protocols/radix-engine) Radix is Florence 7 min read Web1, 2 and 3 have all been compared to the Industrial Revolution because each has introduced new systems and organizations with the potential to supercharge global productivity. However, Web3 is distinct and its characteristics place it closer to the earlier Commercial Revolution of the 10th to 14th centuries than the more famous 18th century era. Maps Before dApps The first Industrial Revolution brought us the internal combustion engine, mass production, and an exponential increase of mechanical precision. The late 19th century Belle Époque saw an even more elaborate wave of innovations, including central heating, aeroplanes, plastics, computers and heart surgery. Having waited 5000 years for the farming revolution, a brand new consumer class emerged within 500, and agriculture receded as a smaller and smaller component of the global economy. Yet, as the Renaissance built upon the infrastructure and freedoms won during the Reformation, so the Industrial Revolution wouldn’t have been possible without the groundwork that was laid by the Commercial Revolution. That time wasn’t characterized so much by invention, as by increasing access to existing goods and services. We see exactly the same situation in Web3 today: A loud chorus of commentators are noting the lack of novel utility and consumer applications, but this is like demanding aeroplanes before the invention of the lathe. Broad consumer adoption won’t happen before transaction costs drop below marginal utility, and that still requires Web3 infrastructure to mature and cover the current economy’s uncharted hinterlands. As this process unfolds, we are seeing a steady churn of applications migrating from network to network in search of the most efficient delivery system for their goods and services. The Florence Protocol The Commercial Revolution began in the 10th Century when European traders carved out trade routes to the Levant, Spain, and North Africa. European agricultural societies had developed a taste for Byzantine luxuries and Eastern spices, inspiring merchants to overcome geographical, cultural, and administrative barriers to supply their customers. Principal city-states like Siena, Pisa, and Venice became the epicenters of this commercial boom by leveraging their existing liquidity, political stability, and juridical systems to facilitate trade and reduce transaction costs through contract law, property rights, monetary exchange systems, and the advent of shipping, insurance, and marketing mechanisms. Among all of the Tuscan city states, Florence was arguably the most successful. Between 1071 and 1284 the city enlarged its walls three times and grew its population ~25x. Even after the devastation of the Black Death in 1348, the city went on to conquer Pisa and acquire direct access to the Mediterranean via the ports of Pisano and Livorno. Despite - or perhaps because of - its inland location and pastoral heritage, Florence’s advantage lay in its people’s willingness to get their hands dirty. In the years preceding, its merchants had established a network of companies abroad engaged in commerce, banking, and government finance that together operated as a unified trade network. In contrast, despite having vast iron deposits, rich soil, and chief stewardship of the papal accounts, Siena’s merchant bankers didn’t share Florentines’ aggressive entrepreneurship. As Florence grew, Siena couldn’t compete: its main bank collapsed in 1298 and its bankers retired as rentier landowners. Looking across the landscape of Web3, the furnaces of infrastructure are still red hot. The Ethereum (/contents/tech/comparisons/radix-vs-ethereum) ecosystem alone is incubating ~50 rollups as satellites around its core technology. The price premium given to Layer 1 (L1) networks suggests that some might venture out on their own to join a growing list of existing competitors, including Radix, Solana (https://solana.com) , Cardano, Avalanche, and Aptos. Each network is like a city state, racing to plug the rest of the world into its standards and trade routes. Arguably, Bitcoin (https://bitcoin.org) has been the most successful at colonizing the ruins of failing currencies, but its poor utility has largely failed to quicken the hearts of many expansionist merchants. Most conversations in Web3 center around the monetary qualities of native assets such as $ETH and $BTC. Yet Florence only introduced a standard unit of account - the Florin - in 1252, almost at the apex of its expansion, after most of the infrastructure work had been done. By 1300, the Florin had become the global standard, gilding in 50 years the trade routes that had taken at least three centuries to build. After 1400, various governments started minting their own competitors to the Florin, eventually driving it out of circulation, but that was only possible because the Florence protocol had already won: the trade routes, commercial treaties, banking network, and legal system were in place as a rich substrate for merchants to grow their businesses. The Radix Protocol Like Florence, Radix is also a late developer, having clocked up over ten years of research (/contents/history) to arrive at its current form. During that time, the denizens of Web3 have looked beyond mere store of value toward financial luxuries that were previously only available offshore or to accredited investors. Ethereum (https://ethereum.org) and other smart contract platforms have brought exotic assets, decentralized organizations, and financial tools to our desktops and smartphones, but none in a sufficiently frictionless way to convince the wider economy that their trade network is a viable one to follow. The obstacles faced by these early pioneers center around the architecture of the protocols themselves, beginning with the all-important developer experience. Developers are the early pioneers of Web3 protocols, seeking a protocol to host their inventions as quickly and safely as possible. The complexity of early protocols like Ethereum led to over $3bn worth of hacks (https://rekt.news/leaderboard/) in 2022, forcing developers to spend ~90% of their time on safety considerations rather than shipping products. Such a drain on resources makes Ethereum and protocols that borrow its technology uncompetitive. One stumbling block of the Ethereum protocol is to keep token balances on vast tally charts called token contracts. Every transaction involves updating the sender and receiver accounts in the contract and wallets must query every token contract to display the correct amounts of every asset. In contrast, Radix is built around the intuitive concept of native assets (https://learn.radixdlt.com/article/what-are-native-assets) that are held in smart accounts (/contents/tech/core-protocols/smart-accounts) , making applications much easier to design and safer to manage for aspiring builders. As well as a more rational architecture, Radix’s smart contract language, Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , has been built expressly for the needs of decentralized finance ( DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) ). Scrypto (/contents/tech/core-protocols/scrypto-programming-language) is simple enough for complex projects such as Trove (/ecosystem/trove) to be brought to market by a single developer (https://www.radixdlt.com/blog/runs-on-radix-q-a-trove) and for Shardspace (/ecosystem/shardspace) to roll out an advanced management suite a mere five weeks after the Babylon (/contents/tech/releases/radix-mainnet-babylon) launch. On the UX side, the Radix Wallet (/contents/tech/core-protocols/radix-wallet) allows for simple encrypted connections to Radix applications, without the need for third-party connectors. Within the wallet, users can create and customize Personas (/contents/tech/core-protocols/personas) to share as much information as they want with applications or withdraw it at the touch of a button. Finally, the Transaction Manifest (https://learn.radixdlt.com/article/what-are-transaction-manifests) gives a clear, plain-English summary of every transaction, complete with a mechanism to void transactions that fall below an expected inbound amount, for example, with an asset swap. Radix’s decade of development was arduous, but it was necessary to build a technical foundation that can truly host global commerce. Now we are beginning to see merchants colonize it with applications and users. The Radix Renaissance 700 years on, the blood, sweat, and tears of the Commercial Revolution is now largely forgotten because it was the birth pangs of a period of human flourishing so profound that its surviving artifacts are still among the most valuable on Earth: the Renaissance. This is the bull case for Radix: eventually, the rhetoric of architecture and infrastructure will defer to a babble of societal and cultural flourishing. The Radix Renaissance is more than just a metaphor; it is a movement towards an era of unprecedented digital prosperity; a future where digital commerce flows with the relative ease and security of the legendary Tuscan city-state, transforming rhetoric into reality and architecture into civilization. RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) ## POW vs POS: The Next Industrial Revolution URL: https://radix.wiki/blog/pow-vs-pos-the-next-industrial-revolution Updated: 2026-09-03 Summary: 7 min read The first Industrial Revolution saw society transformed by the power of coal. This former king of resources fueled the engines of progress,… Format Explainer (7 min read) Topic Consensus & Sybil resistance Companion piece Money, Wealth & Volcanos (/blog/money-wealth-volcanos) Dated claim Written in February 2024. Its DPoS section was corrected in September 2026: Radix has no stake slashing, and an unreliable validator forfeits its own epoch emission rather than its delegators’ principal Related Staking (/contents/tech/core-concepts/staking) · Network Emissions (/contents/tech/core-concepts/network-emissions) · Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) PoW vs PoS: The Next Industrial Revolution 7 min read The first Industrial Revolution saw society transformed by the power of coal. This former king of resources fueled the engines of progress, but as our understanding evolved, we saw coal’s darker side: its dirtiness, inefficiency, and environmental toll. A similar narrative has unfolded in crypto: Proof of Work (/contents/resources/python-scripts/proof-of-work) (PoW) - the mechanism behind Bitcoin (https://bitcoin.org) - is the coal of the digital age - its role at the inception of crypto is undeniable, but so are its limitations… The most prominent alternative to PoW so far is Proof of Stake (PoS) (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) – if not renewable, then the natural gas to PoW's coal. As PoS gains momentum and market share, we have seen variations of it such as Delegated Proof of Stake (DPoS) (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) , which is employed by Radix and other networks. This evolution, akin to refining our energy sources, promises enhanced scalability and inclusivity. As we delve deeper into the dynamics of PoW, PoS, and DPoS, we'll see how these shifts move the decentralized web toward a more sustainable, efficient, and democratized digital future. Sybil Prevention PoW and PoS differ in their methods but both have the same aim: to impose a prohibitive cost on gaining majority control of a network like Bitcoin, Ethereum (https://ethereum.org) or Radix - a situation broadly known as a Sybil attack. In exchange, both methods reward participants for their efforts, usually in the network’s native asset. In this context, ‘control’ refers primarily to the consensus mechanism - the method by which the network agrees which transactions are valid. In PoW this is achieved through mining, and in PoS by running a validator. As transactions are created by users, approving them amounts to a vote, meaning that if an attacker were to gain over 50% of the voting power, they could fabricate and approve any number of beneficial transactions. A sustained attack of this kind would eventually destroy the integrity of a network and the value of any assets it hosts - defeating the object - but exiting an attack before that point could net a significant payout for anyone with the means to do so. Apart from consensus, the other way to participate in a network is by hosting a node that audits the work done by miners or validators. Node operators might seem ancillary, but collectively they wield enormous power by deciding which version of the consensus software is canonical. Miners and validators also run nodes, but if a majority were to decide to run software that rejects legacy transactions, it would be unviable for miners and validators to depart from the economic majority of the network by doing otherwise. There are then, two distinct types of Sybil attack in crypto networks: one, by dominating the consensus mechanism within the existing rules; and another, a critical mass of nodes issuing new rules, either by social consensus or a proliferation of malicious nodes. PoW - Computational Friction 🔢 PoW introduces computational friction by requiring miners to notarize each block of transactions with a unique cryptographic stamp called a ‘block hash’. Hashes are alphanumeric strings but the twist in PoW is that it requires hashes to begin with a number of leading zeros, with each additional zero making the hash exponentially rarer and more computationally expensive to find. Because the transaction data itself is static, miners must append extra data by cycling through binary numbers, hashing each one together with the transaction data until the resulting hash has the required number of leading zeros. 💡 The simplest way to understand PoW is to try it yourself! Here (/contents/resources/python-scripts/proof-of-work) is a simple PoW script you can run at home. 💡 Hashing a block 10^16 times (roughly the current requirement for Bitcoin) requires millions of dollars worth of hardware and electricity. However, once found, hashes are trivial to validate, meaning that if a miner were to admit a fraudulent transaction, their block would be rejected and their resources would have been wasted. The positive case is ‘consensus’, specifically ‘Nakamoto Consensus’, which is when the network of miners trusts a block enough to build another one on top of it. The more cumulative PoW there is on a chain, the more trustworthy it is and the more likely it will continue to be built on by miners. PoS - Economic Friction 💸 PoS is conceptually similar to PoW, but instead of staking computational resources, validators are required to stake the native network tokens, which are forfeited if one of their blocks is found to be invalid or if the validator otherwise behaves dishonestly or incompetently. PoW vs PoS 🥊 Comparisons between PoW and PoS center around three properties: economic security, efficiency, and decentralization. Economic Security & Efficiency PoW’s simple implementation and use of real resources makes it highly secure. This robustness, however, comes at a cost: PoW systems have been strongly criticized for their inefficiency and substantial energy consumption. While critics of the latter rarely offer fair comparisons with networks such as the global banking system, PoW’s inefficiency is less easy to defend: its competitive and serial nature means that every participant must race to hash every block, despite there only ever being only winner among thousands of miners. As an illustration, Ethereum researcher Justin Drake (https://twitter.com/drakefjustin) estimated in March 2022 that switching to PoS made Ethereum 3.5x more economically secure than Bitcoin and 33x more efficient: In addition to being more economically efficient at securing value than PoW, PoS is also more capital efficient because it doesn’t require the consumption of real-world assets: In the above tweet, Dan Robinson (https://twitter.com/danrobinson) is arguing that even though both PoS and PoW may be costly on an individual basis, only PoW is costly to society in its use of real world resources. For a deeper dive on this topic, check out our article on Money, Wealth and Volcanos (/blog/money-wealth-volcanos) . Decentralization Decentralization is a multifaceted issue, encompassing geographical, socio-economic and technical considerations. Geographical Considerations On the geographical aspect, PoW mining farms are conspicuous because of the amount of electricity their hardware consumes. They are also tend to locate to areas where electricity is cheapest. Both of these factors make PoW systems vulnerable to national sanctions of the type seen during 2021 (https://www.cnbc.com/2021/06/15/chinas-bitcoin-miner-exodus-.html) in China. In contrast, PoS systems require minimal external resources and lower up-front capital costs, which means that validator software can be run more discreetly on consumer hardware by anyone with an internet connection, facilitating geographical - and political - decentralization. Socio-economic Considerations Although mining rigs and validators both require a level of expertise to operate, the simpler implementation of PoS caters to a broader gamut of users than the specialized hardware needed for PoW. On the other hand, PoS has been accused of precipitating wealth concentration, since those with more tokens have a higher chance of being selected to validate transactions and earn rewards, allowing them to compound their holdings over time. PoW mining is designed such that the cost of production remains roughly equal to the value of new coins (a rising price attracts more mining resources, which increases the mining difficulty, and thus the cost of production). Staking doesn’t have such a mechanism, but its lower accessibility arguably has the same effect by enabling new stakers to arbitrage high yields, effectively pegging them close to the cost of production. Technical Considerations Most other comparisons between PoW and PoS tend to overlook the presence of mitigation strategies or the parallels between mining equipment in PoW and staked assets in PoS. For example, in a PoS system, those who hold a larger stake in the network's tokens have a higher probability of being chosen to add a block to the blockchain. This is analogous to PoW systems, where participants with more powerful mining hardware stand a greater chance of successfully mining a block and adding it to the blockchain. Another distinct challenge in PoS systems is the ‘nothing at stake’ problem. This occurs in systems where validators define consensus in the event of a disagreement as building on the longest chain (Nakamoto Consensus), meaning the option with the most support from validators. Unlike PoW systems, it is trivial for validators to hedge their bets by voting on several versions of the chain, creating an issue known as the 'nothing-at-stake' problem. DPoS on Radix Radix employs a variation of PoS known as Delegated Proof of Stake (DPoS). In this system, instead of staking directly, native token holders can delegate their stakes to validators, who run the validating software on their behalf and compete on the basis of their fees and reliability. This arrangement allows for a more diverse participant pool than traditional PoS systems by enabling users who don’t have the technical expertise or sufficient holdings required to become a validator to still participate in network security and consensus. DPoS though, is not without its own challenges. One of the most significant is the risk of centralization. If a small number of validators end up controlling a majority of the delegated stake, the network could become vulnerable to a coup. To guard against this, DPoS systems commonly implement the slashing conditions mentioned above — Radix does not. Re-checked in September 2026, no version of the Radix protocol has ever slashed staked XRD, and the Validator blueprint documentation (https://docs.radixdlt.com/docs/validator) still puts it in the future tense and confines it to a narrow case: stake units that a validator’s own owner has voluntarily locked in a delayed-withdrawal vault, as a display of confidence in the node, “may in future be at risk for slashing if the validator purposefully subverts the expectations of the consensus protocol.” Delegated stake is not named there at all. What an unreliable Radix validator actually costs is an epoch of emission rather than anyone’s principal. The Consensus Manager (https://docs.radixdlt.com/docs/consensus-manager) rescales each validator’s successful-proposal ratio into a reliability factor and multiplies its share of the epoch’s network emission (/contents/tech/core-concepts/network-emissions) by it — and on mainnet the minimum required reliability is configured at 1.0, so the factor is binary: a validator that misses a single round in an epoch scores a reliability factor of 0.0 and receives none of that epoch’s emission. The forfeited XRD is not redistributed to anyone; it goes unminted. Transaction fees, by contrast, are received in full regardless of reliability. So delegates do have a reason to choose carefully — an unreliable validator pays them nothing that epoch, and the stake (/contents/tech/core-concepts/staking) is locked through an unstaking delay while that happens. But under the protocol as it stands, their staked XRD is not at risk from a validator’s misbehaviour, and any account of Radix DPoS (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) that implies otherwise — including the sentence this paragraph replaces — overstates the delegator’s downside. Despite these challenges, DPoS systems like Radix provide an efficient and inclusive alternative to traditional PoW and PoS mechanisms. It is also worth noting that Radix’s consensus protocol - Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , does not reference the longest chain, so avoids the nothing-at-stake vulnerability of Nakamoto Consensus. Conclusion While PoW has served as the foundation for cryptocurrencies, its substantial energy consumption, economic inefficiency, and geographic centralization, are anachronisms that will inevitably be jettisoned by a new generation that demands higher standards. As the digital age evolves, the transition to PoS and DPoS marks a shift towards more sustainable and efficient ledgers like Radix. Mirroring the journey from coal to cleaner energy sources, this evolution underscores the industry's commitment to addressing the limitations of its predecessors. With PoS and DPoS, the blockchain world is moving towards a more inclusive, scalable, and environmentally friendly future, promising a decentralized web that not only reduces its ecological footprint but also democratizes participation. As we navigate this transition, the promise of a more efficient and equitable digital ecosystem heralds a new era of technological progress grounded in sustainability and inclusion. RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) ## Validator Subsidy Sunset URL: https://radix.wiki/contents/history/validator-subsidy-sunset Updated: 2026-09-03 Summary: The Radix Validator Subsidy Sunset was a community-approved governance decision that phased out the Foundation-administered validator subsidy over the… Status Concluded – subsidy ended June 2026 Vote Result 71.6% Yes Participation 1,034,541,978 XRD · 604 accounts Feb 2026 Capped at 400k XRD or $350 USD Mar 2026 Capped at 400k XRD or $200 USD Apr–May 2026 $100 USD/month (in XRD) – final payments Jun 2026 Subsidy ended Aftermath Fee market at epoch 332862 (7 Aug 2026): median 2%, stake-weighted mean 20.6%; 42 validators at 0% and 17 at 100% Source Radix Blog (https://www.radixdlt.com/blog/consultation-results-the-future-of-the-validator-subsidy) Overview The Radix Validator Subsidy Sunset was a community-approved governance decision that phased out the Foundation-administered validator subsidy (https://www.radixdlt.com/blog/consultation-results-the-future-of-the-validator-subsidy) over the first half of 2026, with the final payments made in the April–May window and the subsidy ending entirely in June 2026. The subsidy had originally been introduced to incentivise validators to run the Radix network during its early phase, compensating for low transaction fees. As the network matured, the community voted to transition to a sustainable, fee-driven economic model where validators earn through network usage rather than Foundation emissions. The consultation ran in January 2026 and recorded 1,034,541,978 XRD participating from 604 unique accounts (https://www.radixdlt.com/blog/consultation-results-the-future-of-the-validator-subsidy) , with 71.6% voting in favour of the tapering plan. Tapering Schedule The approved plan implemented a three-phase wind-down, completed in June 2026: - Foundation Administered (Feb–Mar 2026): Subsidy capped at 400k XRD or a USD cap (whichever was lower). February cap: $350 USD. March cap: $200 USD. This phase was managed by the Radix Foundation. - Community Administered (Apr–May 2026): The subsidy dropped to $100 USD per month, paid in XRD, with administration transferring to the Radix Accountability Council (/ecosystem/radix-accountability-council) and community entities. The April and May disbursements were the final two subsidy payments (https://radixtalk.com/c/governance) . - Conclusion (Jun 2026): The subsidy ended entirely. Validators now sustain operations through validator fees charged to delegators. The plan included a contingency clause allowing the community to hold a further vote if a Community Entity was not operational, or if a "Jailing" enforcement mechanism (which removes persistently underperforming nodes from consensus) was not in place by June. Rationale The Foundation's goal was always to bootstrap the network rather than subsidise validators indefinitely. The consultation framed the change as "reducing dependency on the Foundation and transitioning to a sustainable economic model." Validators were advised to adjust their fee structures, actively market their nodes to delegators, and – if exiting – properly unregister via the Radix Dashboard rather than going offline, since unregistered inactive nodes slow consensus for the entire network. The vote result (71.6% in favour) reflected strong community consensus that the network was mature enough to support validators through organic fee income. The subsidy wind-down forms part of the broader 2026 Foundation transition (/ecosystem/radix-foundation) to a decentralised, community-governed model. Aftermath: the fee market that replaced it The consultation's case was that the network was mature enough for validators to live on delegator fees instead of Foundation emissions. Two months after the last payment, what that market settled into can be read directly from the ledger. A paginated read of the Gateway's validator register at epoch 332862 (state version 546,817,889, 7 August 2026) returns 287 validator components, 188 of them registered, holding 4,730,263,018 XRD of delegated stake between them. There is no single replacement price. The median registered validator charges 2%; the unweighted mean is 13.3%; the mean weighted by stake is 20.6%. The distribution is not a bell around any of those numbers but a barbell: 0% 42 validators · 847,722,546 XRD · 17.9% of delegated stake Above 0% and under 5% 84 validators — the largest band by count 5–50% 42 validators 50% or more 20 validators, of which 17 charge exactly 100% · 646,061,689 XRD · 13.7% of delegated stake Roughly a third of all delegated XRD — 31.6% — is staked to a validator charging either nothing or everything. A validator's fee is the share of that validator's emissions it keeps before the rest accrues to its delegators, so at 100% the delegated stake earns no emissions at all; the mechanics, including why the fee a validator charges is often not the fee its ledger entry stores, are set out on Validator Nodes (/contents/tech/core-concepts/validator-nodes) . The 100% band is not a tail of dormant nodes. Three of the ten largest validators by stake sit in it — REDDICKS NODE (https://reddicks.meme) at 232.4M XRD, DefiPlaza Investment Node (https://defiplaza.net) at 165.3M and WOWO STAKING at 97.3M — and at each of the three the operator's own stake units account for under 1% of the stake-unit supply, so almost all of that stake belongs to other people. Every large validator in the band declares a project website on-ledger, and the register's own names describe the arrangement: a lossless lottery, a memecoin fund, a Community Council node whose own declared website no longer resolves. What the operator does with a retained emission — a prize draw, a token distribution, funding a council — happens off-ledger, and the protocol has no view of it. The wiki makes no assessment of whether any of these pay out; the ledger records only the fee. Fee changes remain rare and slow. Across the entire register at epoch 332862 exactly two increases were pending: Radstakes (/ecosystem/radstakes) from 15% to 25% at epoch 335294, and Cadwynbloc from 50% to 75% at epoch 332966. An increase cannot take effect for about two weeks after it is requested, which is the window delegators have to move; a decrease applies from the next epoch. Follow-through: what the two increases did Both took effect on schedule, and the delegators reacted in opposite directions. Read at epoch 337,829 (24 August 2026, 17:00 UTC) against each validator's state at the epoch its increase landed: Radstakes (/ecosystem/radstakes) , 15% to 25% at epoch 335294 (15 August) 99,869,766 XRD then, 93,028,935 XRD now – 6,840,831 XRD withdrawn, 6.9% of its stake, dropping it to rank 16 of 188 registered validators Cadwynbloc, 50% to 75% at epoch 332966 (7 August) 68,350,833 XRD then, 68,559,800 XRD now – a rise of 0.3%, holding rank 29 A tripling of the fee at one validator moved no stake; a ten-point rise at another moved nearly 7 million XRD. The protocol gives the same two-week notice in both cases, so what differs is whether anyone was watching. Neither increase was announced by its operator, and neither is visible in the field a reader is most likely to check: both validators still store their old fee factor, 0.15 and 0.5, while the register's effective_fee_factor reports the 25% and 75% actually charged. The Validator Nodes (/contents/tech/core-concepts/validator-nodes) page sets out why the two fields disagree; the practical form of it is that the component state alone will tell you the wrong number. The queue has since refilled, and at epoch 337,829 it holds four requests rather than two. StakeSafe (/ecosystem/stakesafe) is raising both of its large nodes from 15% to 25% at epochs 339,608 and 339,609 – 157.1 million XRD of delegated stake between them, and about 30 August 2026 at the network's recent five-minute epochs – and its seed node from 15% to 100% at epoch 339,609. Leaf Node (/ecosystem/leafnode) 's 1% becomes 100% at epoch 341,223, in the first week of September, over 25,670,173 XRD. Three of the four are on nodes whose operators this wiki tracks, and all four were readable on ledger the day they were signed. External Links - Consultation Results: The Future of the Validator Subsidy – Radix Blog (https://www.radixdlt.com/blog/consultation-results-the-future-of-the-validator-subsidy) - Original Consultation Post – Radix Blog (https://www.radixdlt.com/blog/consultation-the-future-of-the-validator-subsidy) - Governance discussions (incl. node-runner subsidy payments) – RadixTalk (https://radixtalk.com/c/governance) - Radix Foundation – RADIX.wiki (/ecosystem/radix-foundation) ## SingularityX URL: https://radix.wiki/ecosystem/singularityx Updated: 2026-09-03 Summary: Status note (July 2026): the SingularityX (SINX) project appears dormant – its roadmap concluded in 2023 and its website (singularityx.net) is offline… Status note (July 2026): the SingularityX (SINX) project appears dormant – its roadmap concluded in 2023 and its website (singularityx.net) is offline. External links below are repointed to the Internet Archive (https://web.archive.org/web/20260418220758/https://singularityx.net/) . SingularityX is also associated with a meme token called $SINX. It is described as a token fueled by respect for technology and the Radix ecosystem. The goal of SingularityX is to build a community that collaborates on the development of science. Overview SingularityX is described as a group of passionate crypto enthusiasts and Radix enthusiasts who are active community members. They have created their own MEME token called SingularityX (SINX), which is not fueled by humor but by respect for technology and the Radix ecosystem. Roadmap Here is a breakdown of the Roadmap (https://web.archive.org/web/20260418220758/https://singularityx.net/) for SingularityX: 2022 Q3 Start SingularityX Create token Create website Create Twitter and Telegram channels Airdrop Listing on DogeCubeX Listing on Ociswap 2022 Q4 Development Create NFT Twitter and Telegram channels Website development Marketing Create NFT collection 2023 Q1 Focused on NFT Marketing Create SSN NFT website Launch of SSN collection SSN collection moved to Radish Square 2023 Q2 Focused on Charity Campaign with weekly airdrops Charity project VOTE Website development: Z3us Xidar wallet connection Start of NFT marketplace creation 2023 Q3 Focused on Game Game development starts with SSN NFTs Marketing Create Celestial Bodies NFT website Launch of Celestial Bodies collection 2023 Q4 Where to go Create Swap Development of possible NODE run Tokenomics Here is a breakdown of the Tokenomics (https://web.archive.org/web/20260418220758/https://singularityx.net/) of SingularityX (SINX) in percentage allocations: • Charity: 20% • Community: 20% • Marketing: 15% • Liquidity: 35% • Team: 10% • The total supply of SINX tokens is 49,000,000 Mission SingularityX's stated goal is to build (https://web.archive.org/web/20260418220758/https://singularityx.net/) a community that collaborates on the development of science. They have plans for a charitable donation supporting scientific research, particularly in the areas of web3 and space research. Additionally, SingularityX has plans to create an NFT collection. Partnerships • Ociswap (/ecosystem/ociswap) • DogeCube (/ecosystem/dogecubex) • Radit.io (/ecosystem/radit) • DSOR • Astrolescent (/ecosystem/astrolescent) ## Radix Mainnet (Olympia) URL: https://radix.wiki/contents/tech/releases/radix-mainnet-olympia Updated: 2026-09-03 Summary: Olympia [ /oʊˈlɪmpiə/ ] was was the initial release of the Radix Public Network and introduced the core node software, desktop wallet, staking, the Ra… Olympia [ /oʊˈlɪmpiə/ ] was was the initial release of the Radix Public Network and introduced the core node software, desktop wallet, staking, the Radix Explorer, and the native $ XRD (/contents/tech/core-protocols/xrd-token) token. Olympia did not employ the Radix Engine (/contents/tech/core-protocols/radix-engine) as a runtime environment for decentralized applications. Etymology All Radix public releases are related to the Seven Wonders of the Ancient World (https://en.wikipedia.org/wiki/Seven_Wonders_of_the_Ancient_World) . Olympia was the location of the Statue of Zeus (https://en.wikipedia.org/wiki/Statue_of_Zeus_at_Olympia) . Release Components The Olympia release provided the core components of the Radix ecosystem, which continued to expand with future releases. Key components included: Radix Node software Implemented the core Radix protocol, including Radix Engine (/contents/tech/core-protocols/radix-engine) v1 and unsharded Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus. The Radix Engine The first version of Radix's replacement for the Ethereum Virtual Machine, designed to eventually run full DeFi applications. RADIX token - $XRD The native $XRD (/contents/tech/core-protocols/xrd-token) token, used for staking, network security, and transaction fees. Simple Token Creation Allowed new tokens to be created, named, minted, burned, and transacted via the JSON-RPC Radix Node API. DEVELOPMENT Launch Date 2021-07-28 (https://www.radixdlt.com/blog/radix-olympia-mainnet-is-here) Antecedent eMunie (/contents/tech/research/emunie) Postcedent Alexandria (Developer Environment) (/contents/tech/releases/radix-developer-environment-alexandria) Code Repository Github 🔗 (https://github.com/radixdlt/babylon-node/blob/4e6ef24f3dff750ea3515416e27bcaa8f454cbdc/olympia-engine/) License Radix License, v1 (https://github.com/radixdlt/babylon-node/blob/main/LICENSE) LEDGER State Model Sharded (/contents/tech/core-concepts/sharding) Shard Groups 1 (/contents/tech/core-concepts/shard-groups) Sybil Protection Delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) Consensus Protocol Hotstuff (https://hackernoon.com/hotstuff-the-consensus-protocol-behind-safestake-and-facebooks-librabft) Execution Environment Radix Engine (/contents/tech/core-protocols/radix-engine) v1 Validator Node (/contents/tech/core-concepts/validator-nodes) Cap 100 ## Radix Developer Environment (Alexandria) URL: https://radix.wiki/contents/tech/releases/radix-developer-environment-alexandria Updated: 2026-09-03 Summary: Alexandria [ /ˌæləgˈzændriə/ ] was a pre-Babylon version of the Radix network and appended the Olympia release with a Scrypto developer environment fo… Alexandria [ /ˌæləgˈzændriə/ ] was a pre-Babylon version of the Radix network and appended the Olympia (/contents/tech/releases/radix-mainnet-olympia) release with a Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developer environment for testing applications on a local network simulator. Features Alexandria brought the release of an early form of Scrypto (/contents/tech/core-protocols/scrypto-programming-language) and associated tools on the Scrypto Github repo, all of which are open source. Scrypto is a set of libraries and extensions to the popular Rust programming language that provides the asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) features that define the Scrypto experience of writing smart contracts. To test Scrypto blueprints (/contents/tech/core-concepts/blueprints-and-packages) and components (/contents/tech/core-concepts/components) meaningfully, the developer needs some way of deploying that code and interacting with it. Alexandria provides a simulator of such an environment that developers can use to quickly build, test, and iterate Scrypto code, all on their local computer. Scrypto Development To help developers get started with Scrypto, Radix has launched a new Radix Developers Site, which provides links to installation instructions, documentation, examples, and more. Radix has also published a series of blog articles describing the need for Scrypto and how it is different from today's smart contract paradigm, as well as a new DeFi White Paper that collects much of the same information in one place. The Alexandria Preview Scrypto reached developers a month before Alexandria itself did. At the Alexandria Preview Event (/contents/history/alexandria-preview-event) in New York on 12 November 2021, RDX Works ran the first hands-on Scrypto workshop and, in its own later words, "released a preview form of Scrypto and the other Alexandria tools on Github" (https://www.radixdlt.com/blog/radix-alexandria-scrypto-is-coming) . The repository agrees: v0.1.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v0.1.0) is its earliest tag, published at 16:26 UTC that afternoon. The Alexandria release proper followed on 15 December 2021 as v0.2.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v0.2.0) , whose release note reads simply "This is for Alexandria release". DEVELOPMENT Launch Date 2021-12-15 (https://www.radixdlt.com/blog/alexandria-scrypto-is-here) Antecedent Olympia (/contents/tech/releases/radix-mainnet-olympia) Postcedent Babylon (/contents/tech/releases/radix-mainnet-babylon) License Radix License, v1 (https://github.com/radixdlt/babylon-node/blob/main/LICENSE) LEDGER State Model Sharded (/contents/tech/core-concepts/sharding) Shard Groups 1 (/contents/tech/core-concepts/shard-groups) Sybil Protection Delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) Consensus Protocol Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Execution Environment Radix Engine (/contents/tech/core-protocols/radix-engine) v2 Validator Node (/contents/tech/core-concepts/validator-nodes) Cap 100 ## Unspent Transaction Output (UTXO) Model URL: https://radix.wiki/contents/tech/core-concepts/unspent-transaction-output-utxo-model Updated: 2026-09-03 Summary: The Unspent Transaction Output ( UTXO ) model is a way to track ownership of digital assets in cryptocurrency systems. The Radix Engine implements a n… The Unspent Transaction Output ( UTXO (https://en.wikipedia.org/wiki/Unspent_transaction_output) ) model is a way to track ownership of digital assets in cryptocurrency systems. The Radix Engine (/contents/tech/core-protocols/radix-engine) implements a novel UTXO architecture that enables unique features around scalability, asset universality, transaction concurrency, and accounts, while preserving the core integrity of UTXO-based accounting. Classic UTXO (https://en.wikipedia.org/wiki/Unspent_transaction_output) Model The unspent transaction output (UTXO) model was popularized by Bitcoin (https://bitcoin.org) as a way to track ownership of coins in a distributed ledger. In this model, the ledger consists of a set of UTXOs representing coins that can be spent. Each UTXO has a value and a locking script that defines the conditions required to spend it. When a transaction occurs on the Bitcoin network, it consumes UTXOs by satisfying their locking script conditions and creates new UTXOs with updated owners and values. Copy Example: If Alice has a 2 BTC UTXO, she can create a transaction consuming that UTXO and creating two outputs: ➡️ 1.5 BTC UTXO assigned to Bob ➡️ 0.5 BTC change UTXO back to herself.The key rules of the classical UTXO model are: - Coins are represented exclusively as UTXOs on the ledger. The set of available spendable coins equals the set of unspent UTXOs. - UTXOs are created via mining rewards and transaction outputs. New UTXOs come into existence when transactions produce change. - UTXOs are consumed and destroyed when used as transaction inputs. This transfers ownership by assigning new UTXOs to new owners. - Transactions specify input UTXOs to consume and output UTXOs to create in a single atomic operation. - Consensus rules validate transactions verify ownership of input UTXOs via satisfaction of their locking scripts. - The ledger is represented as the chain of transactions with each transaction changing UTXO state. This model provides a complete historical record showing the full chain of custody for every coin on the network. The UTXO architecture offers useful integrity properties around ownership and prevents double spending without a central authority. Radix Engine (/contents/tech/core-protocols/radix-engine) UTXO model The Radix Engine (/contents/tech/core-protocols/radix-engine) implements a UTXO model that makes several optimizations tailored for scalability and performance of decentralized applications. Some key properties of the Radix Engine UTXO architecture: - Assets are defined as universal resources (/contents/tech/core-concepts/resources) rather than being tied to specific smart contracts or accounts. Resources can be freely used across components (/contents/tech/core-concepts/components) and shards. - Components group all their owned resources into a single UTXO. This allows maximum throughput for each component on its shard. - Accounts are components, so each user's balance is represented by an account-specific UTXO. - Transactions specify intent rather than directly specifying input/output UTXOs. The protocol dynamically selects UTXOs to satisfy intent. - Validity relies on digital signatures proving ownership of resources rather than locking script conditions. - Transferring ownership is done by constructing/destructing resources rather than a locking model. This provides inherent atomicity. - Concurrent double spends are resolved by aborting one transaction rather than rejecting both. - The ledger tracks transactions that transform state by constructing/destructing resources. With these properties, the Radix Engine UTXO model offers several key benefits: - Assets are universal across the ledger, enhancing composability between dApps. - Component grouping into single UTXOs maximizes shard throughput. - Specifying intent avoids transaction conflicts, increasing concurrency. - Validity via signatures has low coordination overhead. - Construction/destruction enables atomicity without locks. - Selective transaction abortion increases throughput. ## Blueprints & Packages URL: https://radix.wiki/contents/tech/core-concepts/blueprints-and-packages Updated: 2026-09-03 Summary: In Scrypto , code is organized into a hierarchy: Blueprints – Templates that define logic, state, and access rules (analogous to Rust structs with imp… Blueprint Template / class definition (like a Rust struct + impl) Package Deployed collection of blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) (like a crate) Component (/contents/tech/core-concepts/components) Instantiated blueprint with its own state and address Overview In Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , code is organized into a hierarchy: - Blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) – Templates that define logic, state, and access rules (https://docs.radixdlt.com/docs/auth) (analogous to Rust structs with impl blocks, or Solidity (https://soliditylang.org) contracts as classes) - Packages – Deployed bundles of one or more blueprints (analogous to Rust crates). Each package has a unique address on the ledger - Components (/contents/tech/core-concepts/components) – Runtime instances of blueprints, each with its own state, address, and access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) This model enables code reuse (many components from one blueprint), clear separation of logic and state, and component royalties (/contents/tech/core-concepts/component-royalties) for blueprint authors. ## Blind Signing and Transaction Manifests URL: https://radix.wiki/contents/tech/core-concepts/blind-signing-and-transaction-manifests Updated: 2026-09-03 Summary: Blind signing is the practice of signing transactions whose effects you cannot verify. On Ethereum , users routinely approve transactions that are opa… Problem Blind signing in EVM – users sign hex they can't read Solution Transaction Manifests (/contents/tech/core-protocols/transaction-manifests) – deterministic, human-readable Impact $100M+ lost to approval exploits would be prevented Overview Blind signing is the practice of signing transactions whose effects you cannot verify. On Ethereum (https://ethereum.org) , users routinely approve transactions that are opaque hexadecimal data – they cannot see what the transaction will actually do until after it executes. The Cost Blind signing has enabled over $100 million in losses through approval exploits, phishing, and malicious contract interactions. Users unknowingly grant unlimited token approvals that are later drained. How Radix Solves This Radix transaction manifests (/contents/tech/core-protocols/transaction-manifests) are deterministic, human-readable descriptions of exactly what a transaction will do. The Radix Wallet (/contents/tech/core-protocols/radix-wallet) parses these manifests and shows users exactly which assets will move, where they'll go, and what they'll receive – before signing. This is equally important for AI agents (/contents/tech/core-concepts/radix-for-ai-agents) – autonomous agents can read and verify manifests programmatically, never blind-signing a transaction they don't understand. Human-Readable by Design A manifest (/contents/tech/core-protocols/transaction-manifests) describes a transaction as a sequence of concrete asset movements – "withdraw 10 tokens from my account, then deposit those tokens into Bob's account" – rather than an opaque call to a contract. Because the intent is explicit, the Radix Wallet (/contents/tech/core-protocols/radix-wallet) "can show a clear, meaningful summary of exactly what's going to happen" before the user approves it ( Radix Learn: What are Transaction Manifests (https://www.radixdlt.com/articles-learn/what-are-transaction-manifests) ). The manifest instruction set (https://docs.radixdlt.com/docs/manifest-instructions) is deterministic, so the summary the wallet renders is exactly what the network will execute. Built-in Guarantees Manifests go further than transparency: they let the user assert guarantees on the outcome. In a token swap, the manifest can require a minimum return – if a swap would return less than the amount the user specified, "call the whole thing off" and revert the entire transaction ( Radix Learn (https://www.radixdlt.com/articles-learn/what-are-transaction-manifests) ). This protects users against slippage (https://en.wikipedia.org/wiki/Slippage_(finance)) , front-running, and buggy or malicious components (/contents/tech/core-concepts/components) regardless of what the underlying code does – a protection EVM's blind approval (https://en.wikipedia.org/wiki/Blind_signature) model cannot offer. Autonomous AI agents (/contents/tech/core-concepts/radix-for-ai-agents) gain the same guarantees for free, since they read and construct the very same manifests. ## VM Layer URL: https://radix.wiki/contents/tech/core-protocols/vm-layer Updated: 2026-09-03 Summary: The VM layer of the Radix Engine executes blueprint code. Two virtual machines coexist: the Scrypto VM , which runs developer-authored WebAssembly com… Layer Engine – VM Type Engine Layer Virtual machines Scrypto (/contents/tech/core-protocols/scrypto-programming-language) VM (WebAssembly), Native VM (Rust) WASM engine wasmi interpreter Current Scrypto VM version V1_2 (Cuttlefish) Defined in radix-engine/src/vm Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The VM layer of the Radix Engine (/contents/tech/core-protocols/radix-engine) executes blueprint (/contents/tech/core-concepts/blueprints-and-packages) code. Two virtual machines coexist: the Scrypto VM, which runs developer-authored WebAssembly compiled from Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , and the Native VM, which runs the engine's built-in blueprints — Account, Package, ConsensusManager, the pools and the resource package — as compiled Rust. Both implement the same invocation contract, so the system layer (/contents/tech/core-protocols/system-layer) above them calls a native blueprint and a WASM blueprint the same way, and a Scrypto component (/contents/tech/core-concepts/components) can hold a vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) or call a pool without knowing which side of the boundary it is talking to. Sitting between the kernel (/contents/tech/core-protocols/kernel-layer) and the application layer (/contents/tech/core-protocols/application-layer) , this is the layer where determinism has to be manufactured: the same transaction must produce the same result and consume the same fee on every node, this year and in five years, which constrains what a virtual machine on a public ledger is allowed to be. The Scrypto VM Developer code reaches the network as WebAssembly, and the engine runs it on wasmi (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/Cargo.toml) , an interpreter targeting the WebAssembly MVP. An interpreter rather than a JIT compiler is a deliberate trade: predictable, identical execution on every node matters more here than raw speed, and a compiler's output can vary with the host. Uploaded WASM passes three gates before it ever runs. It is validated with wasmparser, rejecting the module outright if it uses features outside the supported subset. It is instrumented with radix-wasm-instrument (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/Cargo.toml) , which injects metering calls so that execution charges by the instruction rather than by wall-clock time — the per-instruction costs are a table of weights (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/wasm/weights.rs) , and memory growth carries its own charge. And it is bounded: WasmValidatorConfigV1 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/wasm/wasm_validator_config.rs) caps the call stack at 1,024 frames, so recursion terminates as a clean transaction failure instead of exhausting a validator's memory. Metering is why a Radix transaction's fee is a property of the transaction rather than of the node that ran it. The instrumented module calls back into the engine through a host function literally named gas, decrementing the transaction's cost-unit budget as it goes; run out and execution aborts and the state changes are discarded. The Native VM The engine's own blueprints do not go through WASM at all. The Native VM (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/native_vm.rs) dispatches on package address straight into compiled Rust — Account, Identity, Package, ConsensusManager, AccessController, Locker, TransactionProcessor, TransactionTracker, the pool package and the resource (/contents/tech/core-concepts/resources) package, plus the object modules for metadata (/contents/tech/core-concepts/metadata-module) , role assignment (/contents/tech/core-concepts/role-assignment-module) and royalties (/contents/tech/core-concepts/component-royalties) . These are the pieces every transaction touches, and running them natively is what keeps the cost of a transfer down to the cost of a transfer. It is also where protocol updates (/contents/tech/releases/protocol-updates) land. Because native code cannot be uploaded, changing a native blueprint means shipping a new node version — so the source carries the versions side by side as explicit extensions: AccountBlueprintBottlenoseExtension and AccountBlueprintCuttlefishExtension, WorktopBlueprintCuttlefishExtension, ConsensusManagerSecondsPrecisionNativeCode, an AccessController v1 and v2. Old transactions keep resolving against the behaviour that was current when they were committed, which is what makes the ledger replayable from genesis after a protocol update rather than merely consistent going forward. The VM Boundary WASM in the Scrypto VM cannot touch ledger state directly. Every effect goes through a fixed, named set of host functions defined in vm/wasm/constants.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/wasm/constants.rs) , and the list is short enough to read in a minute: blueprint_call, object_new, object_globalize, object_call, actor_open_field, actor_emit_event, kv_store_new, kv_entry_read, field_entry_write, address_allocate, gas, and a handful of siblings. That narrowness is the security argument for the whole design. A blueprint cannot open a socket, read a clock, generate an unseeded random number or reach into another component's substates, because no host function exposes any of it — the sources of non-determinism that other execution environments have to discipline by convention are simply not reachable. It is also why asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) guarantees hold: a bucket of resource moves by calling into the engine, and the engine enforces conservation at the boundary rather than trusting the blueprint that asked. Versioning The Scrypto VM itself is versioned, in a short ladder tied to the network's protocol updates. ScryptoVmVersion (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/versions.rs) runs V1_0 at Babylon (/contents/tech/releases/radix-mainnet-babylon) genesis, V1_1 from Anemone — which introduced the first set of cryptographic utility host functions — and V1_2 from Cuttlefish, which added the second. V1_2 is the latest, and the version in force is carried in a VM boot substate on the ledger rather than compiled into the node as a constant. Reading the active version from state, instead of assuming it, is what lets a node built today re-execute a transaction from 2023 under the VM that was live at the time. It is the same discipline as the native blueprint extensions, applied to the WASM side. What Xi'an Changes This layer is the one the Hyperscale (/contents/tech/research/hyperscale-rs) programme is replacing. A sharded network needs a transaction's full data requirements to resolve before execution, so that conflicts can be analysed without running anything, and the Radix Engine's state access is — on the lead developer's assessment — too loose for that. The decision to build a purpose-built VM rather than retrofit the existing one was confirmed on 1 August 2026, and belongs to Xi'an (/contents/tech/releases/radix-mainnet-xian) rather than to mainnet as deployed, which continues to run everything described above. What that means for existing developers was stated two days later: "Scrypto is literally just a couple of Rust macros. Not particularly hard to hit parity" (https://t.me/hyperscale_rs/10414) , with manifest (/contents/tech/core-protocols/transaction-manifests) , resources, subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) and badges (/contents/tech/core-concepts/badges) kept as-is and the change confined to "the lower layers like state, locks, parallelism" (https://t.me/hyperscale_rs/10414) . Read against this page, that is a precise claim: the VM boundary and the native blueprint set survive; the interpreter, the metering strategy and the substate access underneath them do not. No migration has been scheduled. External Links - radix-engine/src/vm — both virtual machines (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm) - Host function names exposed to WASM (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/wasm/constants.rs) - ScryptoVmVersion ladder (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/versions.rs) - WASM validation and metering configuration (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/vm/wasm/wasm_validator_config.rs) - Scrypto compilation pipeline (https://github.com/radixdlt/radixdlt-scrypto/tree/main/scrypto-compiler) ## Kernel Layer URL: https://radix.wiki/contents/tech/core-protocols/kernel-layer Updated: 2026-09-03 Summary: The kernel is the lowest layer of the Radix Engine . It manages substates (units of persistent state), actors (entities that own substates), invocatio… [Notice: Stub] This article is a stub. The kernel’s substate, actor, invocation and costing responsibilities are each a section’s worth of material. You can help RADIX Wiki by expanding it. Layer Engine – Kernel Type Engine Layer Defined in radix-engine Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The kernel is the lowest layer of the Radix Engine (/contents/tech/core-protocols/radix-engine) . It manages substates (/contents/tech/core-concepts/substate-model) (units of persistent state), actors (entities that own substates), invocation semantics, ownership transfer, and execution costing. The kernel knows nothing about resources (/contents/tech/core-concepts/resources) , blueprints (/contents/tech/core-concepts/blueprints-and-packages) , or roles – those are abstractions provided by the system layer above it. Keeping the kernel deliberately small is what makes the engine's safety properties auditable. External Links - radix-engine kernel sources (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/kernel) - Substate model (wiki) (/contents/tech/core-concepts/substate-model) ## Application Layer URL: https://radix.wiki/contents/tech/core-protocols/application-layer Updated: 2026-09-03 Summary: The application layer is the topmost layer of the Radix Engine stack – where developer-authored Scrypto blueprints , packages, and components actually… [Notice: Stub] This article is a stub – one paragraph on a layer the Radix Engine article and the homepage architecture grid both link to. You can help RADIX Wiki by expanding it. Layer Engine – Application Type Engine Layer Defined in scrypto, radix-engine Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The application layer is the topmost layer of the Radix Engine (/contents/tech/core-protocols/radix-engine) stack – where developer-authored Scrypto (/contents/tech/core-protocols/scrypto-programming-language) blueprints (/contents/tech/core-concepts/blueprints-and-packages) , packages, and components (/contents/tech/core-concepts/components) actually execute. It sits above the system layer and consumes the abstractions (objects, modules, the type system) it provides, while remaining isolated from the lower-level kernel concerns of substates (/contents/tech/core-concepts/substate-model) , actors, and ownership semantics. External Links - radixdlt-scrypto repo (https://github.com/radixdlt/radixdlt-scrypto) - Radix Engine architecture (Radix Docs) (https://docs.radixdlt.com/docs/engine-tech-docs) ## Radix Economic Model URL: https://radix.wiki/contents/tech/research/radix-economic-model Updated: 2026-09-03 Summary: The Radix economic model is the set of rules that decide where XRD comes from and where it goes. There are only three flows, and each obeys a differen… Radix Economic Model Measured at Epoch 333342 · state version 547,628,486 (9 Aug 2026) XRD (/contents/tech/core-protocols/xrd-token) supply 13,505,461,118.64 Total ever minted 13,513,127,623.88 Total ever burned 7,666,505.23 (0.057% of minted) Emissions ~300M XRD/year, flat — see Network Emissions (/contents/tech/core-concepts/network-emissions) Network fee split 50% burned · 25% proposer · 25% validator set Tips 100% to the proposer, never burned Royalties 100% to the recipient, outside the split Fee schedule pegged at 1 XRD = 0.06 USD (protocol constant) On-ledger supply cap None — the 24B ceiling is a schedule Overview The Radix economic model is the set of rules that decide where XRD (/contents/tech/core-protocols/xrd-token) comes from and where it goes. There are only three flows, and each obeys a different rule: - Emissions mint new XRD at the end of every epoch and hand it to the active validator set (/contents/tech/core-concepts/validator-nodes) in proportion to stake ( Network Emissions (/contents/tech/core-concepts/network-emissions) ). - Network fees take XRD out of circulation and out of the payer's account, splitting it three ways — half destroyed, half paid to validators. - Royalties move XRD from a caller to a component (/contents/tech/core-concepts/components) or package owner without touching the split at all ( Component Royalties (/contents/tech/core-concepts/component-royalties) ). Every parameter below is a constant in the radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) engine rather than a policy someone administers, and every figure is checked against mainnet at the epoch stated in the infobox. Where this page and a marketing summary disagree, the ledger is the authority. Where a fee goes A Radix transaction fee is not one number. The engine records it in five parts — execution, finalization, storage, tipping and royalty — and only the first three count as network fees ( fee_summary.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine/src/system/system_modules/costing/fee_summary.rs) ). Those three are then divided by fixed percentages: - 25% to the proposer — the validator that proposed the round the transaction landed in (NETWORK_FEES_PROPOSER_SHARE_PERCENTAGE). - 25% to the validator set, shared across the active set (NETWORK_FEES_VALIDATOR_SET_SHARE_PERCENTAGE). - The remainder is burned. The engine does not carry a burn percentage at all: to_burn_amount() is defined as everything left after the proposer and the set are paid, which at 25 and 25 leaves exactly half. Tips are the exception. TIPS_PROPOSER_SHARE_PERCENTAGE is 100 and TIPS_VALIDATOR_SET_SHARE_PERCENTAGE is 0 ( transaction_execution.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-common/src/constants/transaction_execution.rs) ), so a tip is paid whole to the proposer and none of it is destroyed. A tip buys priority from one validator; it does not add to the burn. The split is observable on any transaction. Four consecutive mainnet user transactions between 02:51 and 03:05 UTC on 9 August 2026 each reported to_burn at exactly half of network fees with to_proposer and to_validator_set equal at a quarter each — for example a 0.75854478253 XRD fee resolving to 0.379272391265 burned and 0.1896361956325 to each side. The same reads confirm the unit prices: 9,669,160 execution cost units billed 0.483458 XRD, which is the count multiplied by EXECUTION_COST_UNIT_PRICE_IN_XRD of 0.00000005 exactly. The fee schedule is priced in dollars The least-discussed constant in the model is USD_PRICE_IN_XRD. Radix does not price its fee schedule in XRD and let the dollar cost float; it prices several things in US dollars and converts at a hard-coded rate of 16.666666666666666666 XRD per USD — that is, 1 XRD = $0.06 ( transaction_execution.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-common/src/constants/transaction_execution.rs) ). Two of the engine's figures are set that way and carry the intended dollar amount in a source comment: - Storage — STATE_STORAGE_PRICE_IN_XRD and ARCHIVE_STORAGE_PRICE_IN_XRD are both 0.00009536743 XRD per byte, commented "1 MB = 6 USD". - The royalty ceiling — MAX_PER_FUNCTION_ROYALTY_IN_XRD is 166.666666666666666666 XRD, commented "10 USD", which is the same peg applied to the maximum a package or component owner may charge per call. The consequence is easy to state and rarely stated: those dollar figures are only true at $0.06. The XRD amounts are what the protocol enforces, so the real cost of storing a megabyte, and the real ceiling on a royalty, move with the market price of XRD in the opposite direction from the comment. Changing the peg is a protocol update, not a parameter a validator or a fee market can adjust. What the ledger actually shows The fee burn is real and it is small. Read directly from the XRD resource (/contents/tech/core-concepts/resources) at epoch 333342 (state version 547,628,486, 9 August 2026): - Total ever minted: 13,513,127,623.876558485383676466 XRD - Total ever burned: 7,666,505.2330698031699972 XRD - Current supply: 13,505,461,118.643488682213679266 XRD — the difference, exactly Cumulative burn since the Babylon (/contents/tech/releases/radix-mainnet-babylon) ledger began is 0.057% of everything ever minted. Measured against emissions of roughly 300 million XRD a year, the entire burn to date is worth about nine days of issuance. Radix is issuing far more than it destroys and will keep doing so until fee volume grows by orders of magnitude; a description of the model that leads with the burn describes an aspiration rather than the current ledger. This is also what makes validator income a fee question rather than a subsidy question. The Foundation subsidy that once topped up validator revenue was voted out and ended in June 2026 ( Validator Subsidy Sunset (/contents/history/validator-subsidy-sunset) ), leaving emissions and the 50% validator share of network fees as the whole of it, with the validator's own fee percentage deciding how much reaches delegators (/contents/tech/core-concepts/staking) . The 24 billion ceiling is a schedule, not a cap XRD is commonly described as having a fixed maximum supply of 24 billion. The ledger is more specific than that, and the distinction matters to anyone reasoning about the asset. Read as a resource, XRD reports supply_fixed: false and mintable: true. There is no supply cap enforced at the resource level. What exists instead is an authority structure: - The minter and burner roles are both locked to a single system badge (/contents/tech/core-concepts/badges) , so only the protocol itself can create or destroy XRD — no account, component or council can. - The rules can never be changed (rules_locked: true). The freezer and recaller roles are permanently deny_all, which is the ledger-level guarantee that XRD can never be frozen in a vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) or clawed back from one. So the 24 billion figure is the endpoint of the ~12 billion emission schedule added to the ~12 billion created at Olympia (/contents/tech/releases/radix-mainnet-olympia) genesis, enforced by the emission logic in the protocol rather than by an arithmetic ceiling on the resource. Raising it would take a protocol update, the same class of change as moving the dollar peg — hard, public and out of any single party's hands, but not the same thing as impossible. That endpoint has also been voted down once without moving. A May 2025 token holder consultation approved shortening the emission schedule by twenty years to bring the ceiling to ~18 billion, with 91% of weighted input in favour; measured across the twelve months that followed, the network minted 297,171,771 XRD — the original ~300 million-a-year rate, unchanged. See Network Emissions (/contents/tech/core-concepts/network-emissions) . External Links - radixdlt-scrypto — transaction execution constants (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-common/src/constants/transaction_execution.rs) - radixdlt-scrypto — fee reserve finalization summary (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine/src/system/system_modules/costing/fee_summary.rs) - Radix Knowledge Base — What is the XRD token? (https://www.radixdlt.com/articles-learn/what-is-the-xrd-token) - Radix Documentation (https://docs.radixdlt.com/) See also - Network Emissions (/contents/tech/core-concepts/network-emissions) — the issuance side in detail - XRD (/contents/tech/core-protocols/xrd-token) — the asset itself - Component Royalties (/contents/tech/core-concepts/component-royalties) — developer revenue - Validator Subsidy Sunset (/contents/history/validator-subsidy-sunset) — how validator income became fee-driven ## Rollups URL: https://radix.wiki/contents/tech/core-concepts/rollups Updated: 2026-09-03 Summary: A rollup is a layer-2 blockchain scaling construction in which transactions are executed outside the base blockchain (the layer 1) while the data requ… Topic Layer-2 blockchain scaling Main variants Optimistic rollups; zero-knowledge (validity) rollups Dominant cost Layer-1 data publication Related Sharding (/contents/tech/core-concepts/sharding) · Atomic composability (/contents/tech/core-concepts/atomic-composability) · Blockchain trilemma (/contents/tech/core-concepts/blockchain-trilemma) A rollup is a layer-2 blockchain scaling construction in which transactions are executed outside the base blockchain (the layer 1) while the data required to reconstruct them is published to it. By moving computation off-chain and posting compressed transaction data on-chain, rollups increase throughput while continuing to derive their security from the underlying chain rather than from an independent validator set. Two designs dominate: optimistic rollups, which presume submitted batches are valid and rely on fraud proofs to catch invalid ones, and zero-knowledge (zk) rollups, which accompany every batch with a cryptographic validity proof. Beyond the proof mechanism, rollups are distinguished by an unusual fee structure: because a batch's fixed costs are shared by all transactions inside it, fees can fall as usage grows – within limits. Optimistic and zero-knowledge rollups An optimistic rollup executes transactions off-chain and posts the resulting batch data to the base layer – on Ethereum as calldata or as blobs (https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) , a dedicated data format that nodes prune after roughly eighteen days. Batches are presumed valid when submitted; correctness is enforced after the fact through multi-round interactive fraud proofs (https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) , under which an invalid state commitment can be disputed. A zk-rollup instead submits a validity proof alongside each state commitment. In cost terms the two differ in where their overheads sit: for a zk-rollup the validity proof is a fixed cost incurred even when a batch contains no transactions (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) , while an optimistic rollup carries per-transaction signature data as an additional variable cost. Data availability Both designs depend on the base layer to store the data needed to reconstruct the rollup's state, and this transaction data is the largest variable cost of operating a rollup (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) and the primary contributor to rising rollup costs. That expense has motivated hybrid designs – validiums and volitions – that keep transaction data off-chain in search of cheaper average costs. The analytics site L2BEAT accordingly classifies live systems by proof type and data-availability mode (https://l2beat.com/scaling/summary) , tracking validiums and optimiums separately from rollups proper. Fee economics What a rollup user pays bundles two distinct services. Ethereum's developer documentation describes the fee on an optimistic rollup as the cost of writing data to layer 1 plus an operator fee for layer-2 computation (https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) . Barnabé Monnot's first-principles analysis draws the same division on the cost side: operators bear layer-2 operating costs, layer-1 data-publication costs – the dominant new cost of the rollup model (https://barnabe.substack.com/p/understanding-rollup-economics-from) – and congestion costs on the rollup itself, and must recover them from user fees, extractable value, and issuance, since an operator cannot sustainably run at a loss (https://barnabe.substack.com/p/understanding-rollup-economics-from) . Alex Beckett's analysis of rollup fee economics decomposes the cost of a batch into fixed costs – the state commitment, plus the validity proof for a zk-rollup – and variable costs, chiefly transaction data plus signatures for optimistic rollups (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) . The fee an individual user pays corresponds to the batch's average cost: total cost divided by the number of transactions in the batch. Because fixed costs are amortized over the whole batch, the average falls as the batch grows – so long as the marginal cost of one more transaction sits below the average. In Beckett's worked example, a 500-transaction batch at an average cost of $1 totals $500; adding a transaction with a $0.70 marginal cost lowers the average to $0.9994 (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) . On this basis he describes rollups as "the first type of blockchain that can incur positive network effects with regards to transaction fees" (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) , in contrast to monolithic chains, where each additional user raises fees for everyone. The effect has limits. Once marginal cost reaches average cost, the rollup's costs follow a standard short-run cost curve, and past the minimum of that curve each additional transaction pushes fees upward again (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) – the negative network effects of a monolithic chain reappear. And because transaction-data costs are bound to the base layer's finite block space, rollups remain exposed to fee spikes originating on layer 1 (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) , especially when the base layer also hosts user-facing applications. Beckett concludes that scalable data-availability layers are fundamental to keeping rollups inexpensive without sacrificing security or decentralization. Composability across rollups Each rollup maintains its own state and executes transactions in its own environment. A single transaction therefore cannot atomically span two rollups: moving assets or invoking contracts across them requires bridging or settlement through the base layer. As of mid-2026, L2BEAT tracks roughly twenty-two Ethereum rollups (https://l2beat.com/scaling/summary) alongside validiums and optimiums, with Arbitrum One the largest at about $17.7 billion in total value secured; it also grades systems on a Stage 0–2 decentralization framework (https://l2beat.com/scaling/summary) reflecting how far each has reduced reliance on trusted operators. A consequence of this proliferation is that liquidity and application state fragment across many execution environments, and the synchronous, all-or-nothing composability available within a single chain does not extend across the ecosystem as a whole. Rollups and Radix Radix addresses the same scaling constraint – often framed as the blockchain trilemma (/contents/tech/core-concepts/blockchain-trilemma) – without a rollup layer, instead scaling the base layer itself through integrated sharding (/contents/tech/core-concepts/sharding) . The published design uses a "pre-sharded" model with a fixed, pre-allocated maximum shard space rather than adding shards dynamically, and its Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus "braids" validation across shards to enforce system-wide transaction ordering; deterministic shard indexing means transactions from separate accounts involve separate shards and can be processed asynchronously in parallel. Neither property is live today: Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet runs Cerberus unsharded, and the Xi’an production candidate (/contents/tech/research/hyperscale-rs) neither braids nor pre-allocates a shard space, splitting shards on demand under a beacon-maintained trie instead. On the composability question, radix.wiki's atomic composability (/contents/tech/core-concepts/atomic-composability) page states that a single transaction manifest (/contents/tech/core-protocols/transaction-manifests) can chain any number of operations – swaps, loans, deposits, withdrawals – into one all-or-nothing sequence, and that Cerberus braids consensus across every shard a transaction touches, maintaining atomicity across shards, in contrast to sharded systems whose cross-shard operations depend on asynchronous bridges. Rollups and integrated sharding thus represent two responses to the same problem: rollups amortize base-layer costs by moving execution off-chain at the price of fragmenting state across separate environments, while an integrated sharded layer 1 aims to expand execution capacity while preserving a single atomically composable state. For a broader comparison of the two ecosystems' approaches, see Radix vs Ethereum (/contents/tech/comparisons/radix-vs-ethereum) . References - Beckett, Alex (2022). The economics of rollup fees (https://web.archive.org/web/20260119081538/https://www.alexbeckett.xyz/the-economics-for-rollup-fees/) . alexbeckett.xyz (archived via the Internet Archive). - Ethereum Foundation. Optimistic Rollups (https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/) . ethereum.org developer documentation. - Monnot, Barnabé (2022). Understanding rollup economics from first principles (https://barnabe.substack.com/p/understanding-rollup-economics-from) . The Price of Agency (Substack). - L2BEAT. Scaling Summary (https://l2beat.com/scaling/summary) . l2beat.com, accessed July 2026. ## Worktop URL: https://radix.wiki/contents/tech/core-concepts/worktop Updated: 2026-09-03 Summary: The worktop is the resource staging area that exists for the life of a single transaction intent. When a manifest withdraws tokens from an account, th… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Blueprint name Worktop Package RESOURCE_PACKAGE Persistence Transient (is_transient: true) — one per intent, never written to state Methods 9, plus 2 added by Cuttlefish Defined in radix-engine/src/blueprints/resource/worktop.rs Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The worktop is the resource (/contents/tech/core-concepts/resources) staging area that exists for the life of a single transaction intent. When a manifest (/contents/tech/core-protocols/transaction-manifests) withdraws tokens from an account, the bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) the account returns lands on the worktop, and it sits there until a later instruction takes it off — to deposit it somewhere, or to pass it into a method call. Nothing in a manifest can hold a balance in mid-air: on Radix a resource (/contents/tech/core-concepts/asset-oriented-programming) is always somewhere, and between two instructions the worktop is that somewhere. It is often described as a countertop, and the metaphor is load-bearing in one respect: whatever you leave on it at the end has to be accounted for. The engine enforces that by dropping the worktop (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/worktop.rs) when the intent's instructions run out and calling drop_empty on each bucket still attached to it. An empty bucket vanishes; a bucket with a balance in it makes drop_empty fail, and the whole transaction fails with it. That is why a manifest cannot lose funds by forgetting about them — not a commit-time balance sweep, but a deliberate refusal to destroy a non-empty bucket. Where it lives in the engine The worktop is not a special case bolted onto the manifest runner. It is an ordinary native blueprint named Worktop, defined in radix-engine/src/blueprints/resource/worktop.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/worktop.rs) and published in the same RESOURCE_PACKAGE as buckets, proofs, vaults and the fungible and non-fungible resource managers. It is only ever reached through the Transaction Processor (/contents/tech/core-concepts/transaction-processor) , which is why it is usually described alongside it, but the code belongs to the resource subsystem. Its blueprint definition (/contents/tech/core-concepts/blueprints-and-packages) declares is_transient: true, so the object can never be persisted: the intent processor (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/intent_processor.rs) allocates a node id for it, creates it with a fresh empty substate, pins it in the kernel for the duration of the intent, and drops it at the end. Its authorisation template is AllowAll on both functions and methods — unusual for a native blueprint, and safe here because the worktop node is owned by the processor's own call frame and its Own reference is never handed to a component (/contents/tech/core-concepts/components) . Nobody else can address it, so there is nothing to gate. State: one bucket per resource The entire state is a single field: WorktopSubstate { resources: IndexMap } — a map from resource address to exactly one owned bucket. Ten withdrawals of XRD (/contents/tech/core-protocols/xrd-token) do not put ten buckets on the worktop; the first creates the entry and the rest are merged into it. Directly above the implementation the source states the rule the methods exist to preserve: no empty buckets in the worktop. That invariant drives the zero-amount behaviour, which is worth knowing because it is where the methods stop being symmetrical: - Putting an empty bucket does not create an entry. The bucket is passed straight to drop_empty and the worktop is left untouched. - Taking a zero amount never reads the worktop at all; the resource manager mints a new empty bucket and returns it. Asking for nothing always succeeds, even for a resource that was never on the worktop. - Taking all of an absent resource likewise returns a new empty bucket rather than failing — TAKE_ALL_FROM_WORKTOP is total, and a manifest that takes all of a resource it never received gets an empty bucket, not an error. - Taking a positive amount is the only one that can fail on absence. A missing entry, or an entry holding less than requested, raises WorktopError::InsufficientBalance. When the request happens to equal the whole balance the engine moves the existing bucket out wholesale rather than splitting it, which also removes the entry and keeps the invariant. The instruction surface Nine methods are declared in the blueprint definition. Seven of them are what manifest instructions compile down to; the other two are reached differently. The mapping, from the engine's instruction dispatch (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/instructions.rs) : Manifest instruction Worktop method Effect TAKE_FROM_WORKTOP take Take a stated amount of one resource into a named bucket TAKE_NON_FUNGIBLES_FROM_WORKTOP take_non_fungibles Take a stated set of local ids TAKE_ALL_FROM_WORKTOP take_all Take the whole entry for one resource RETURN_TO_WORKTOP put Put a named bucket back ASSERT_WORKTOP_CONTAINS_ANY assert_contains Fail unless the balance is non-zero ASSERT_WORKTOP_CONTAINS assert_contains_amount Fail unless the balance is at least an amount ASSERT_WORKTOP_CONTAINS_NON_FUNGIBLES assert_contains_non_fungibles Fail unless every listed id is present — (the ENTIRE_WORKTOP expression) drain Hand every bucket over at once — (end of intent) drop Destroy the worktop, dropping each remaining bucket empty drain is the mechanism behind the Expression("ENTIRE_WORKTOP") argument that makes deposit_batch idiomatic: when the processor resolves that expression it clears the map and passes the whole set of buckets into the call. drop has no instruction at all — only the processor calls it, exactly once, when the intent finishes. Assertions, and what they actually check The three original assertions read the worktop under a read-only lock and raise WorktopError::AssertionFailed with a typed reason: ExpectedNonZeroAmount for ASSERT_WORKTOP_CONTAINS_ANY, ExpectedAtLeastAmount — carrying both the expected and the actual amount — for the amount form, and NonFungibleMissing naming the first absent id for the non-fungible form. A resource with no entry is read as a zero balance rather than as an error, so all three fail with the same shape whether the resource is short or simply never arrived. The Cuttlefish protocol update added two more through a WorktopBlueprintCuttlefishExtension, which are stronger in kind rather than in degree. Both aggregate every balance currently on the worktop and check it against a ManifestResourceConstraints set: ASSERT_WORKTOP_RESOURCES_INCLUDE requires the listed constraints to hold, while ASSERT_WORKTOP_RESOURCES_ONLY additionally requires that nothing else is present. The second is the one that closes the gap the older assertions leave open — it lets a manifest state that the worktop holds the expected assets and no others, which is what makes an unexpected token arriving mid-transaction a failure rather than a surprise. These are the worktop half of the pre-authorization (/contents/tech/core-concepts/subintents-and-pre-authorizations) work, whose other half bounds what the next call is allowed to return. One historical detail is visible in the error type: WorktopError still carries a BasicAssertionFailed variant that nothing raises. The source notes it is kept so that legacy errors can still be serialized by the node — an error model, once public, outlives the code that produced it. Lifecycle within an intent The worktop is created before the first instruction runs and dropped after the last one. In between, two things put resources on it without an explicit instruction saying so. The first is the return path. Whenever a call returns, the processor walks the owned nodes in the returned value and auto-moves them: buckets are put on the worktop, proofs are pushed onto the auth zone (/contents/tech/core-concepts/access-rules-and-auth-zones) , and anything else is left alone. This is why a manifest can call withdraw and then TAKE_FROM_WORKTOP without an instruction in between to move the result — the move already happened. The second is the drop. Because the processor (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/intent_processor.rs) drops the worktop when its instruction queue empties — including on the path where an intent yields to its parent with nothing left to run — the check is per-intent rather than per-transaction. Each intent in a Cuttlefish transaction gets its own processor, and therefore its own worktop and its own auth zone: resources do not flow from one intent to another by being left lying on a shared countertop, but only through the value a yield carries. An intent's worktop does survive a yield to a child and is still there when control returns. External Links - worktop.rs — the Worktop blueprint (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/worktop.rs) - intent_processor.rs — worktop creation, auto-move and drop (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/intent_processor.rs) - instructions.rs — the manifest instruction dispatch (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/instructions.rs) - Radix Docs: transaction manifest (https://docs.radixdlt.com/docs/manifest) ## Component Royalties URL: https://radix.wiki/contents/tech/core-concepts/component-royalties Updated: 2026-09-03 Summary: Component Royalties allow Scrypto blueprint authors to earn fees whenever their deployed components are used. This is enforced at the Radix Engine lev… Mechanism Per-method royalty fees set by blueprint (/contents/tech/core-concepts/blueprints-and-packages) authors Enforced By Radix Engine (/contents/tech/core-protocols/radix-engine) Currency XRD (/contents/tech/core-protocols/xrd-token) Overview Component (/contents/tech/core-concepts/components) Royalties allow Scrypto (/contents/tech/core-protocols/scrypto-programming-language) blueprint (/contents/tech/core-concepts/blueprints-and-packages) authors to earn fees whenever their deployed components are used. This is enforced at the Radix Engine (/contents/tech/core-protocols/radix-engine) level – not by application logic – creating a sustainable business model for open-source DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) developers. Authors set per-method royalty amounts in XRD. When a transaction manifest (/contents/tech/core-protocols/transaction-manifests) calls a royalty-bearing method, the fee is automatically collected. This solves the open-source sustainability problem: developers can share their code openly while earning from its usage. Package vs. Component Royalties Radix supports royalties at two levels, both declared in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) . Package royalties are defined inside a blueprint with the enable_package_royalties! macro and are fixed for every component instantiated from that blueprint. Component royalties are configured per instance at instantiation with enable_component_royalties!, letting the owner set – and later change – the fee on individual methods. Both are documented in the Radix Using Royalties (https://docs.radixdlt.com/docs/using-royalties) guide. Denomination and Collection A royalty is always charged in XRD (/contents/tech/core-protocols/xrd-token) as part of the transaction fee (https://docs.radixdlt.com/docs/transaction-costing) , but the author may specify the amount either as a fixed quantity of XRD or as an approximate USD-equivalent (https://docs.radixdlt.com/docs/using-royalties) , in which case a network constant converts it to XRD at charge time. Because collection is enforced by the Radix Engine (/contents/tech/core-protocols/radix-engine) rather than application logic, it cannot be bypassed by the calling transaction – the fee accrues automatically into the component's royalty vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) . Claiming and Access Control Accumulated royalties are held by the protocol until the owner claims them, gated by dedicated roles – royalty_setter, royalty_locker, and royalty_claimer – that map onto Radix's native badge-based authorization (/contents/tech/core-concepts/asset-oriented-programming) . An owner can also lock a royalty so it can never be raised again, giving downstream builders a credible guarantee about the long-term cost of composing with a component. Together these turn open-source publication into a first-class, on-ledger business model for DeFi developers. ## Asset-Oriented Programming URL: https://radix.wiki/contents/tech/core-concepts/asset-oriented-programming Updated: 2026-09-03 Summary: Asset-oriented programming is Radix's foundational design principle where digital assets (tokens, NFTs , badges ) are native primitives managed by the… Category Programming Paradigm Platform Radix Language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Key Concept Assets as first-class primitives Overview Asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) programming is Radix's foundational design principle where digital assets (tokens, NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) , badges (https://docs.radixdlt.com/docs/auth) ) are native primitives managed by the Radix Engine (/contents/tech/core-protocols/radix-engine) , not entries in smart contract storage mappings. On EVM chains, a "token" is just a number in a mapping inside a smart contract (e.g., balances[address] = 100). The ERC-20 (https://eips.ethereum.org/EIPS/eip-20) standard defines a convention for tracking balances, but the chain itself has no concept of "assets." This creates the approval exploit problem (/contents/tech/core-concepts/native-assets-vs-token-approvals) – contracts must be granted permission to manipulate another contract's balance mapping. On Radix, assets exist as physical resources (/contents/tech/core-concepts/resources) managed by the engine. They live in vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) , are moved via buckets (/contents/tech/core-concepts/buckets-proofs-and-vaults) , and their behavior (mintable, burnable, recallable) is defined at creation. No contract can access assets it doesn't hold – eliminating entire classes of exploits. Comparison with Solidity (https://soliditylang.org) In Solidity (EVM), creating a token means deploying a contract that maps addresses to balances. Transferring tokens means calling that contract to update its internal mapping. The token has no independent existence – it's just state inside a contract. In Scrypto (/contents/tech/core-protocols/scrypto-programming-language) (Radix), creating a token means asking the Radix Engine (/contents/tech/core-protocols/radix-engine) to mint a native resource. The engine tracks who holds what. Transferring means physically moving resources between vaults (https://docs.radixdlt.com/docs/buckets-and-vaults) – like moving coins between wallets in the real world. This architectural difference eliminates: approval exploits (no approve() needed), reentrancy attacks (assets are in call-frame-local buckets (https://docs.radixdlt.com/docs/resources) ), and balance manipulation (the engine enforces conservation – assets can't be created or destroyed without explicit authority). External Links - Radix Documentation (https://docs.radixdlt.com/) - Native Assets vs Token Approvals (/contents/tech/core-concepts/native-assets-vs-token-approvals) - Scrypto Fundamentals (/developers/scrypto/01-fundamentals) ## Metadata Module URL: https://radix.wiki/contents/tech/core-concepts/metadata-module Updated: 2026-09-03 Summary: The Metadata module is one of the engine's pluggable object modules. Every globalized object – packages, components, resources, accounts – has a Metad… Layer Object Module Blueprint (/contents/tech/core-concepts/blueprints-and-packages) name Metadata Type Module Methods create, create_with_data, set, lock, get, remove Roles metadata_setter, metadata_setter_updater, metadata_locker, metadata_locker_updater Value types 16 scalar + 16 array forms Defined in radix-engine (metadata module) Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The Metadata module is one of the engine's pluggable object modules. Every globalized object – packages, components, resources, accounts – has a Metadata module attached, exposing a typed key-value store for descriptive data: name, symbol, icon URL, description, tags, social links. Wallets, explorers, and dapps read metadata to render assets and components meaningfully. Writes are gated by access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) on the metadata role, so updates can be locked or restricted to specific badges (/contents/tech/core-concepts/badges) . Module interface Metadata is attached to a globalized object rather than written by it, and the module exposes six methods, defined in the metadata invocation definitions (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/object_modules/metadata/invocations.rs) : create and create_with_data to attach the module (empty, or pre-populated in the same instruction), set and remove to write and delete a key, get to read one, and lock to freeze one. get returns Option and remove returns a boolean saying whether a key was actually there — both are total, so reading metadata that was never set is a normal outcome rather than a failure. Because the module hangs off the object, a blueprint (/contents/tech/core-concepts/blueprints-and-packages) does not have to declare fields for its own name and icon; the same interface serves resources (/contents/tech/core-concepts/resources) , components (/contents/tech/core-concepts/components) , packages, and accounts (/contents/tech/core-protocols/smart-accounts) alike. Setting, and locking The module declares four roles (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/object_modules/metadata/roles.rs) , deliberately separating the two powers: metadata_setter may write and remove keys, metadata_locker may freeze them, and metadata_setter_updater and metadata_locker_updater may reassign the respective role. An issuer can therefore keep the ability to correct a description while having already given up the ability to change a symbol — or hold the locker role in cold storage while a hot key handles routine updates. lock takes a single key and is irreversible for that key: once locked, no role — including the owner — can set or remove it again. This is what lets a token's ticker or an NFT (/contents/tech/core-protocols/nfts-on-radix) collection's name be a credible commitment rather than a promise, and it is why wallets and explorers can display a locked symbol without the qualification they would need for a mutable one. Locking is per key, so a resource can pin its identity while leaving its social links editable. Typed values Metadata values are typed, not free-form strings. The value discriminators (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/object_modules/metadata/models/discriminators.rs) enumerate 16 scalar forms — String, Bool, the integer widths, Decimal, GlobalAddress, PublicKey and PublicKeyHash, NonFungibleGlobalId and NonFungibleLocalId, Instant, Url, and Origin — each with a matching array form, for 32 in total. The distinction between Url and Origin matters for the wallet: a dApp declares its definition account, and the origin it is served from, as typed metadata that the Radix Wallet (/contents/tech/core-protocols/radix-wallet) can verify rather than merely render. A GlobalAddress value is a real reference the ledger can resolve, which is how dApp definitions and their components point at each other. Writes are gated by access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) on the metadata roles, so the whole structure is auditable state, not a display-layer convention. External Links - metadata module (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/object_modules/metadata) - metadata invocation definitions (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/object_modules/metadata/invocations.rs) - Radix Docs: Metadata (https://docs.radixdlt.com/docs/metadata) - Radix Docs: Metadata for Wallet Display (https://docs.radixdlt.com/docs/metadata-for-wallet-display) ## Badge URL: https://radix.wiki/contents/tech/core-concepts/badges Updated: 2026-09-03 Summary: A badge is a resource that a component accepts as proof of authority. Radix Engine defines no badge type and no badge opcode. What makes a resource a… Layer Core Primitive Type Convention over resources (/contents/tech/core-concepts/resources) Defined in scrypto, radix-engine Checked by Access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) , against the transaction auth zone Presented as A proof, valid only within its transaction Ed25519 signature badge resource_rdx1nfxxxxxxxxxxed25sgxxxxxxxxx002236757237xxxxxxxxxed25sg Secp256k1 signature badge resource_rdx1nfxxxxxxxxxxsecpsgxxxxxxxxx004638826440xxxxxxxxxsecpsg Account owner badges resource_rdx1nfxxxxxxxxxxaccwnrxxxxxxxxx006664022062xxxxxxxxxaccwnr Ledger reading Epoch 339,016 · 28 August 2026 Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction A badge is a resource (/contents/tech/core-concepts/resources) that a component (/contents/tech/core-concepts/components) accepts as proof of authority. Radix Engine (/contents/tech/core-protocols/radix-engine) defines no badge type and no badge opcode. What makes a resource a badge is that an access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) somewhere names it. The working distinction is between holding and showing. To move XRD (/contents/tech/core-protocols/xrd-token) you put it in a bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) and hand the bucket over, and the balance leaves your account. To use a badge you create a proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) of it, and the proof is a claim about what a vault contains that the engine checks and then discards. The badge stays where it was. A door pass works the same way: the guard reads it, and you keep it. Because the thing being shown is an ordinary resource, everything the ledger already guarantees about resources applies to authority too. A badge cannot be copied, cannot be conjured by the component that demands it, and cannot go missing without someone having moved it. Showing, not spending Every transaction runs with an auth zone, a scratch space holding the proofs presented so far. A transaction manifest (/contents/tech/core-protocols/transaction-manifests) creates a proof from a vault, pushes it into the auth zone, and calls a method. The engine then tests that method’s access rule against whatever the auth zone is carrying at that moment. The rule is a small expression over resource addresses. require names a single badge. require_amount demands a quantity of a fungible one, which is how a component charges for a privilege rather than gating it. require_any_of and require_all_of compose those into m-of-n conditions. The operand is always a resource address, so any resource can gate any method, and one badge can gate methods on components written years apart by people who never spoke. A proof is scoped to the transaction that made it. It cannot be stored in component state, returned to a caller as a durable capability, or replayed in a later transaction. When the transaction finalizes, the auth zone is emptied. That scoping is what lets an access rule be written as a question about the present moment rather than a ledger of who was granted what. Badges nobody holds Some badges have no holders and never will. The engine mints proofs of them from facts it already knows about the transaction, and the resource exists to give those facts an address that an access rule can name. The signature badge is the clearest case. Radix has one per curve: the EdDSA Ed25519 Signature Resource at resource_rdx1nfxxxxxxxxxxed25sgxxxxxxxxx002236757237xxxxxxxxxed25sg, and the ECDSA Secp256k1 Signature Resource at resource_rdx1nfxxxxxxxxxxsecpsgxxxxxxxxx004638826440xxxxxxxxxsecpsg. Both read the same way on-ledger: total supply zero, minter deny_all, burner deny_all, and every authority locked against future change. Nobody holds one, and no one can ever issue one. They are presented constantly. When a transaction is signed, the engine derives a non-fungible id from the hash of the signing public key and places a proof of that id into the auth zone. An account (/contents/tech/core-concepts/components) component’s default rule requires exactly that badge, which is how a signature becomes an authorization without the account ever storing a key. The resource is a name for a property of the transaction, and zero supply is the honest expression of that. The same construction answers a different question for code. The Package of Direct Caller Resource, at resource_rdx1nfxxxxxxxxxxpkcllrxxxxxxxxx003652646977xxxxxxxxxpkcllr, is also supply zero and also unmintable, and a proof of it identifies the package (/contents/tech/core-concepts/blueprints-and-packages) whose code made the current call. A component can therefore admit calls from one specific body of code and refuse every other caller, human or otherwise. The badges the system issues Against those, the badges the system actually hands out have supply, holders, and a mint rule worth reading. Account Owner Badges live at resource_rdx1nfxxxxxxxxxxaccwnrxxxxxxxxx006664022062xxxxxxxxxaccwnr and stood at 761 in supply at epoch 339,016. One is issued when an account is created with an owner badge, and holding it grants control over that account component. Its minter rule is the interesting part. Minting is protected, and the badge it requires is a single specific non-fungible of the Package of Direct Caller Resource described above – the id naming the account package itself. Only the account package’s own code can mint an account owner badge, and that restriction is locked against amendment. Badges gate badges, in other words, and the recursion bottoms out in the implicit resources the engine controls rather than in a privileged administrator. The same shape governs the owner badges issued for packages, validators and identities. What the pattern costs A badge is a bearer instrument. Whoever holds it has the authority, and a component asked to verify one has no way to distinguish its intended holder from a thief. Losing the badge loses the privilege, permanently, unless recovery was designed in beforehand – which is the problem the Access Controller (/contents/tech/core-concepts/access-controller) exists to solve. Transferability is the same trade seen from the other side. Because badges are resources, they move like resources, so authority is transferable by default. A badge meant to stay put has to be made non-transferable at creation by denying its withdrawer role, and that choice cannot be walked back once the rules are locked. Babylon (/contents/tech/releases/radix-mainnet-babylon) formalized the arrangement rather than replacing it. The role assignment module (/contents/tech/core-concepts/role-assignment-module) gives every component a set of named roles, each mapped to an access rule, so a blueprint declares who may do what once and the badges satisfying those roles can be rotated underneath. The badge remains the credential; the role is the slot it fits. What the pattern buys is a single vocabulary. Permissions on Radix are not a parallel system bolted beside the asset model – they are expressed in it, using the same asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) primitives as tokens, and inheriting the same guarantees against duplication and silent loss. External Links - Radix Docs: Authorization and badges (https://docs.radixdlt.com/docs/auth) - Radix Docs: Advanced AccessRules (https://docs.radixdlt.com/docs/advanced-accessrules) - Authorization patterns (scrypto source) (https://github.com/radixdlt/radixdlt-scrypto/tree/main/scrypto/src/component) - radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) ## Transaction Tracker URL: https://radix.wiki/contents/tech/core-concepts/transaction-tracker Updated: 2026-09-03 Summary: The Transaction Tracker is a system-level native blueprint that records the status of every transaction submitted to the network – including its inten… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Blueprint name TransactionTracker Structure Ring buffer of substate partitions Epochs per partition 100 Coverage ≈65 days of intent hashes Created by Protocol only (system execution) Defined in radix-engine (transaction_tracker package) Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The Transaction Tracker is a system-level native blueprint (/contents/tech/core-concepts/blueprints-and-packages) that records the status of every transaction submitted to the network – including its intent hash and expiry. It is what allows the network to detect and reject duplicate submissions, enforce transaction (/contents/tech/core-protocols/transaction-manifests) expiry windows, and provide deterministic transaction-status lookups via the Gateway API (/contents/tech/core-protocols/radix-gateway-api) . What it records Every transaction submitted to Radix carries an intent hash — a commitment to the manifest (/contents/tech/core-protocols/transaction-manifests) and its header, including the epoch range in which the transaction is valid. The Transaction Tracker is the ledger's record of which intent hashes have already been seen, and with what outcome. Three statuses are stored: CommittedSuccess, CommittedFailure, and Cancelled. Two guarantees rest on it. The first is that no intent can commit twice: a resubmitted transaction whose hash is already recorded is rejected outright, which is what lets a wallet safely retry a submission it never saw confirmed. The second is deterministic status lookup — when the Gateway API (/contents/tech/core-protocols/radix-gateway-api) answers "did this transaction go through?", it is reading state every validator agrees on, not a mempool guess. A ring of partitions Storing every intent hash forever would grow without bound, so the tracker is a fixed-size ring. Its package definition (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/transaction_tracker/package.rs) reserves every substate partition (/contents/tech/core-concepts/substate-model) from just above the main base partition up to 255, and assigns each one a window of EPOCHS_PER_PARTITION = 100 consecutive epochs. A transaction's record is filed in the partition covering its expiry epoch, computed by partition_for_expiry_epoch; an expiry outside the ring's current window has nowhere to go and the transaction is not accepted. Every 100 epochs the tracker calls advance: the start epoch moves forward one window, the start partition steps on by one and wraps around at the end of the range, and the partition it lands on — the oldest — is cleared. Records age out by being overwritten rather than deleted individually, so the cost of the whole structure is bounded and constant. The repository's own calculate_coverage test pins the size of that window: at the network's targeted five-minute epoch (/contents/tech/core-concepts/consensus-manager) , the ring covers 65 days. The same test asserts the covered range is at least the transaction validator's max_epoch_range — that is the design constraint, and it runs in CI. How long a transaction may stay valid before it expires is not an independent parameter; it is bounded by how much history the tracker can hold. System-owned, not user-callable The tracker is a native blueprint but not an ordinary one. Its create function is gated behind system_execution(SystemExecution::Protocol), so only the protocol itself may instantiate it — there is exactly one tracker, created at genesis, and no blueprint or badge (/contents/tech/core-concepts/badges) can make another. Writes into it come from the transaction processor (/contents/tech/core-concepts/transaction-processor) as part of committing a transaction, not from a method call a manifest can make. Its substate is versioned (TransactionTrackerSubstateV1) and stores only the ring's parameters — start epoch, start partition, the partition range, and the epochs-per-partition figure — so the layout can change in a future protocol update (/contents/tech/releases/protocol-updates) without a migration of the records themselves. External Links - transaction_tracker native package (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/transaction_tracker) - package.rs — ring buffer and coverage test (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/transaction_tracker/package.rs) - transaction validation configuration — max_epoch_range (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/src/validation/transaction_validation_configuration.rs) ## Transaction Processor URL: https://radix.wiki/contents/tech/core-concepts/transaction-processor Updated: 2026-09-03 Summary: The Transaction Processor is the native blueprint that turns a transaction manifest into engine calls. Every user transaction on Radix begins in it: i… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Blueprint name TransactionProcessor Package TRANSACTION_PROCESSOR_PACKAGE Functions One — Run; no methods, no state, no events Callable by The root call frame only (FunctionAuth::RootOnly) Persistence Transient (is_transient: true) Defined in radix-engine/src/blueprints/transaction_processor/ Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The Transaction Processor is the native blueprint (/contents/tech/core-concepts/blueprints-and-packages) that turns a transaction manifest (/contents/tech/core-protocols/transaction-manifests) into engine calls. Every user transaction on Radix begins in it: it decodes the manifest's instructions, creates the worktop (/contents/tech/core-concepts/worktop) , executes the instructions in order against the Radix Engine (/contents/tech/core-protocols/radix-engine) , resolves the manifest's named buckets (/contents/tech/core-concepts/buckets-proofs-and-vaults) and proofs into real objects at the moment a call needs them, and collects the per-instruction outputs the receipt reports back. It is deliberately small. The manifest format is where the expressive work happens; the processor is the loop that walks it, and almost every rule it enforces is a rule about keeping resources (/contents/tech/core-concepts/resources) accounted for while it does. A package with a single function The package definition (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/transaction_processor/package.rs) declares one blueprint with one function, Run, and nothing else — no methods, no fields, no collections, no events, no hooks. Like the worktop it is is_transient, so no part of it is ever written to state. The interesting line is its authorisation. Run is declared FunctionAuth::RootOnly, meaning only the root call frame may invoke it: a component (/contents/tech/core-concepts/components) cannot call the transaction processor, and a manifest cannot recursively re-enter one. The source gives the reasoning in a comment — it is a safety precaution to reduce the surface area of attack, and it may be relaxed if the processor is ever verified to be safe. A native blueprint carrying an explicit note that its own restriction is provisional is a useful reminder of where the engine's trust boundaries are drawn by construction rather than by proof. What Run receives The input is the manifest (/contents/tech/core-protocols/transaction-manifests) after validation, not the raw text a user signed: the SBOR-encoded instruction list, the global address reservations the transaction allocated up front, the set of references the transaction declared, and the blobs it carries. References are passed through explicitly so that the kernel makes them visible inside the processor's own call frame. Blobs are the one place the processor carries a hard limit, and it is versioned. The V1 package has two minor versions: version zero applied no ceiling at all, while version one (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/transaction_processor/blueprint.rs) caps the total size of blobs per invocation at 1024 * 1024 bytes — one mebibyte — and raises TotalBlobSizeLimitExceeded beyond it. The limit is cumulative across the invocation rather than per blob, and it is counted as the manifest resolves each blob reference, so a manifest that references the same large blob repeatedly is charged for it each time. The instruction loop The blueprint itself is a thin wrapper over an intent processor (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/intent_processor.rs) , which holds the queue of remaining instructions, the worktop, the registry of named objects, the running instruction index, and the outputs so far. Initialisation decodes the instructions and creates the worktop; execution pops one instruction at a time, tells the kernel the current instruction index — which is what lets a failure be reported against the instruction that caused it — dispatches it, and pushes an InstructionOutput for it. Manifest names do not survive into the engine. A named bucket or proof is a numeric id at runtime, and the processor keeps the registries that resolve them, substituting the real object into a call's arguments at the moment the call is made. The errors are correspondingly literal — BucketNotFound, ProofNotFound, AddressReservationNotFound and BlobNotFound all name the id or hash that could not be resolved. A bucket can only be resolved once: taking it out of the registry to pass it into a call is what makes a manifest bucket single-use. Return values are auto-moved rather than dropped on the floor. After every call the processor walks the returned value's owned nodes: buckets go onto the worktop, proofs are pushed onto the auth zone (/contents/tech/core-concepts/access-rules-and-auth-zones) , and other kinds of owned node are passed over. The pattern a manifest author sees — call a method, then TAKE_FROM_WORKTOP — is this behaviour, not an implicit instruction. From one thread to many The original processor is strictly single-threaded, and says so: after running the instruction queue to completion it asserts that no yield occurred, and panics if one did. That is sound for V1 manifests, where there is nothing to yield to. Cuttlefish's subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) changed the shape. A V2 transaction is executed by a multi-thread intent processor (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/multithread_intent_processor.rs) that builds one intent processor per intent, each on its own kernel stack, each with its own auth zone and its own worktop, and drives them as a tree: a yield to a child switches stacks and pushes the caller onto a parent stack, a yield to a parent pops it, and a child that finishes has its stack cleaned up after the value is delivered. VERIFY_PARENT is resolved by switching to the parent's stack and testing an access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) against its auth zone, which is why it cannot be used from a root intent — there is no parent to test. Execution ends with the parent stack empty. Worth noting for anyone reading the code: on this path the multi-thread processor does not invoke the blueprint's Run export. It sets each thread's call-frame actor to that function directly and drives the intent processor itself, so the blueprint's identity is what appears in the call frame even where the export is not the entry point. External Links - package.rs — the TransactionProcessor package definition (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/transaction_processor/package.rs) - blueprint.rs — Run, and the blob size ceiling (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/transaction_processor/blueprint.rs) - intent_processor.rs — the instruction loop (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/intent_processor.rs) - multithread_intent_processor.rs — the subintent execution tree (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/transaction/multithread_intent_processor.rs) - Radix Docs: transaction manifest (https://docs.radixdlt.com/docs/manifest) ## Role Assignment Module URL: https://radix.wiki/contents/tech/core-concepts/role-assignment-module Updated: 2026-09-03 Summary: The Role Assignment module is the native object module that stores an object's permissions. Every globalized object carries one, and its state is deli… Layer Object module Type Native blueprint (/contents/tech/core-concepts/blueprints-and-packages) , attached to globalized objects Stores One owner-role field, one key-value collection of role to rule Max roles 50 per module Max role name 100 bytes Reserved names Any name beginning _; _owner_ and _self_ are defined Defined in object_modules/role_assignment (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/package.rs) Introduction The Role Assignment module is the native object module that stores an object's permissions. Every globalized object carries one, and its state is deliberately small (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/substates.rs) : a single field holding the owner role, and one key-value collection mapping a role key to an access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) . Blueprints (/contents/tech/core-concepts/blueprints-and-packages) declare which roles guard which methods; this module holds what each role currently means, and can be updated after deployment without touching the code. Storing permissions as module state rather than as component (/contents/tech/core-concepts/components) fields is what makes them readable from outside. The rules of any live component can be queried through the Gateway like any other substate, so the current authority over a mint, a withdrawal, or a metadata change is a matter of public record rather than of reading the blueprint and trusting it. The owner role The owner role (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/role_assignment.rs) is declared once at instantiation, as one of three values: - OwnerRole::None – no owner at all - OwnerRole::Fixed(rule) – an owner rule that can never be changed by anyone - OwnerRole::Updatable(rule) – an owner rule the owner may change Internally these become an OwnerRoleEntry of a rule plus an updater, where the updater is None, Owner, or Object. When the updater is None, the field is written immutable at creation (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/package.rs) rather than merely guarded, so the immutability is a property of the substate and not of a rule that could later be relaxed. The third value, Object, lets the object itself rotate its owner, and it is what makes a pre-allocated smart account (/contents/tech/core-protocols/smart-accounts) upgradable into a badge-controlled one. A pre-securified object (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/util/securify.rs) is created with its owner rule set to the virtual signature badge of the key that addresses it and the updater set to Object, plus a securify role guarded by the same rule. Calling securify does three things in order: it sets the securify role to DenyAll, mints the owner badge, and sets the owner role to require that badge. The first step is what makes the conversion one-way; after it, nothing can call securify again. The owner role also decides more than it appears to. Because an undefined role resolves to the owner rule, the owner is the effective default authority over every role the blueprint declares and the instantiator did not assign. Roles, names, and the reserved namespace Beyond the owner, roles are ordinary named entries. The module validates them on the way in (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/package.rs) rather than on use, and the validation is worth knowing before designing a role set: - At most MAX_ROLES, 50 roles per module. - A role name is at most MAX_ROLE_NAME_LEN, 100 bytes, and must pass the same name check as other identifiers. - Every name beginning with an underscore is reserved. Attempting to define or set one fails with UsedReservedRole. Only two reserved names are defined by the system, _owner_ and _self_, and both may be referenced in a role list even though neither can be assigned. - The Role Assignment module cannot hold roles for itself. Passing it as a target module fails with UsedReservedSpace. - The rule attached to a role is validated for depth and node count at assignment time, so an over-complex rule is rejected when it is set, not when it is tested. Roles are also mutable by design. A role's rule can be reassigned later by whoever the object's permissions allow, which is how a project rotates a compromised admin badge or hands an authority to a governance component without redeploying. The audit trail for such a change is the transaction that made it. How blueprints use it A blueprint does not check roles in its method bodies. It declares, per method, one of four method accessibility (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/role_assignment.rs) values: Public, RoleProtected with a list of role names, OwnPackageOnly, or OuterObjectOnly, the last used by the Validator blueprint so that only the Consensus Manager (/contents/tech/core-concepts/consensus-manager) can reach certain methods. The engine resolves the declaration to a rule through this module and tests it before the body runs. For resources (/contents/tech/core-concepts/asset-oriented-programming) the same machinery appears under fixed names. The mint, burn, freeze, recall, deposit, withdraw, and non-fungible-data-update authorities are seven named roles on the resource manager (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/mod.rs) , each with a paired _updater role, which is why a token's permissions can be read on-ledger as a set of rules and reported as locked when the updater is DenyAll. That reading is how this wiki dates a token's authorities without relying on the issuing team's description of them. The common patterns fall out of the same two pieces: a badge (/contents/tech/core-concepts/badges) requirement for admin authority, a CountOf requirement for N-of-M multi-signature, and a global_caller requirement to let one named component act on another. External Links - Radix Docs: Access Rules & Roles (https://docs.radixdlt.com/docs/advanced-accessrules) - radixdlt-scrypto: role_assignment.rs (OwnerRole, RoleKey, MethodAccessibility) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/role_assignment.rs) - radixdlt-scrypto: role assignment native package (validation and reserved names) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/package.rs) - radixdlt-scrypto: role assignment substates (the stored shape) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/substates.rs) - radixdlt-scrypto: securify.rs (presecurified owner roles and the one-way securify step) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/util/securify.rs) - radixdlt-scrypto: authorization.rs (role resolution and the owner fallback) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/authorization.rs) ## Radix vs Solana URL: https://radix.wiki/contents/tech/comparisons/radix-vs-solana Updated: 2026-09-03 Summary: Solana orders transactions with Proof of History and agrees on them with Tower BFT, over one global state machine : there are no shards and no executi… Type Technical comparison Radix ( Babylon (/contents/tech/releases/radix-mainnet-babylon) , live) Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) deployed unsharded — one shard group over the whole ledger; commodity hardware Radix ( Xi'an (/contents/tech/releases/radix-mainnet-xian) , in development) Hyperscale (/contents/tech/research/hyperscale-rs) — sharded, HotStuff-2-derived per-shard consensus, purpose-built VM Solana (https://solana.com) Proof of History + Tower BFT; one global state machine, no sharding (/contents/tech/core-concepts/sharding) ; Sealevel (https://solana.com/docs/references/terminology) parallel runtime; high-end validator hardware Live figures measured 21–22 August 2026 Consensus and scalability Solana (https://solana.com) orders transactions with Proof of History and agrees on them with Tower BFT, over one global state machine: there are no shards and no execution partitions. Parallelism comes from the runtime instead. Sealevel (https://solana.com/docs/references/terminology) is defined in Solana's own terminology as "Solana's parallel run-time for onchain programs", and a block's transactions entry (https://solana.com/docs/references/terminology) is "a set of transactions that may be executed in parallel" — transactions declare the accounts they touch, so non-conflicting ones run across cores at once. The cost of that design is hardware: the Agave client's own validator requirements (https://docs.anza.xyz/operations/requirements) ask for 12 cores / 24 threads, 256 GB of RAM (ECC suggested), and separate PCIe Gen3 NVMe drives for accounts, ledger and snapshots. Voting is itself a transaction, and can cost a validator up to 1.1 SOL per day (https://docs.anza.xyz/operations/requirements) . Radix is two different systems depending on which one is meant. Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) as specified braids consensus across only the shards a transaction touches, and throughput scales with shard count. As deployed, on the live Babylon (/contents/tech/releases/radix-mainnet-babylon) network, Cerberus runs as a single unsharded instance — one shard group covering the whole ledger, which makes it equivalent to the original HotStuff BFT protocol, with the braiding machinery inactive because there is nothing to braid. Braiding has never run in production (/contents/tech/core-protocols/cerberus-consensus-protocol) . Linear scaling by shard count is therefore a property of the specification and of the Hyperscale / Xi'an (/contents/tech/research/hyperscale-rs) work in progress, not of the network available to transact with today. What does hold today is the hardware floor. A Radix node's documented minimum (https://docs.radixdlt.com/docs/node-setup) is 4 vCPU, 16 GB of RAM and a 500 GB SSD, with 8 vCPU and 32 GB recommended for validators (see Running a Node (/developers/infrastructure/01-running-a-node) ) — roughly an order of magnitude below what an Agave validator is asked for. What each network is actually doing Both figures below are single calls against each network's own public endpoint, taken on 21–22 August 2026, and either can be repeated in one command. They measure demand, not capacity: neither is a benchmark, and neither is a ceiling. Measurement Solana mainnet-beta Radix mainnet (Babylon) Source getRecentPerformanceSamples (https://solana.com/docs/rpc/http/getrecentperformancesamples) , 10 samples of 60 s Gateway (https://docs.radixdlt.com/docs/network-gateway) /stream/transactions, 100 most recent user transactions Window 600 s, ending at slot 440,790,972 3,359.6 s, 22:09:48–23:05:47 UTC on 21 August 2026 All ledger traffic 4,026 tx/s 5.5 tx/s (state versions 552,958,337 → 552,976,939) User traffic only 2,192 tx/s (non-vote) 0.03 tx/s (100 transactions in 56 minutes) The top row is not comparable to the bottom one on either network, and that is the point of showing both. Roughly 46% of Solana's transactions in this window were validator votes, which are consensus overhead carried on the ledger; on Radix the equivalent overhead is the per-round ledger transaction, which is why the state version advances 18,602 times in a window that contains 100 user transactions. Comparing a headline TPS figure from one network against a user-transaction figure from another is the most common way these numbers are misread. Asset model Solana uses the SPL Token standard: token balances live in accounts owned by the token program, and a wallet holds an associated token account per mint. It is a materially safer arrangement than the EVM (https://ethereum.org) pattern of a contract keeping a balance mapping, because the asset is not the application's private bookkeeping — but moving a token is still a program invocation, and delegation and approvals are program-level constructs. Radix makes assets a feature of the engine rather than of a program. Resources (/contents/tech/core-concepts/resources) are created and moved by the Radix Engine (/contents/tech/core-protocols/radix-engine) itself, held in vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) , and passed between components (/contents/tech/core-concepts/components) in buckets that the engine will not let a transaction lose or duplicate. There is no token contract to approve against, and a transaction manifest (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) states in readable form which resources move where. See asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) for the full model. Where each is heading Solana's near-term throughput work is client engineering rather than a protocol change — the Firedancer client from Jump Crypto, and Anza's successive Agave releases. Radix's is a replacement stack: Hyperscale (/contents/tech/research/hyperscale-rs) , the Xi'an (/contents/tech/releases/radix-mainnet-xian) candidate, which shards, replaces the Radix Engine with a purpose-built WASM VM, and in its first published execution benchmark ran plain transfers 20.3× faster than the Radix Engine on one core (/contents/tech/research/hyperscale-rs) . It is unreleased. Asked how the two compare, the lead developer of the Xi'an candidate offered an assessment that is worth reading as one implementer's view rather than as a measurement. Solana, in that view, "is not sharded" (https://t.me/hyperscale_rs/10748) , and its theoretical ceiling "might shift somewhere between 100-200k TPS" once the current client work settles — with the caveat "not sure what it'll actually be in practice tho". On the difference in goal rather than degree: "Solana is awesome. It's a good design if optimizing for low-latency. That's a different focus than Hyperscale which is uncapped throughput though" (https://t.me/hyperscale_rs/10750) . Key trade-offs Solana's strengths: a large live ecosystem with deep DeFi, NFT and payments activity; parallel execution already running in production; sub-second slot times and fast finality; a mature fee market with an explicit compute budget (https://solana.com/docs/core/fees) per transaction. Radix's strengths: assets enforced by the engine rather than by application code; transaction manifests (/contents/tech/core-protocols/transaction-manifests) a user can read before signing; validator hardware an order of magnitude cheaper; and a scaling design that adds shards rather than raising the hardware floor. The honest asymmetry: Solana's advantages are shipped and measurable today, while Radix's scaling advantage is a specification plus an in-development implementation. The Babylon network that exists now is a single unsharded ledger, and — as the measurement above shows — is nowhere near using even that. External links - Solana Documentation: terminology (Sealevel, transactions entry) (https://solana.com/docs/references/terminology) - Agave validator requirements (Anza) (https://docs.anza.xyz/operations/requirements) - Solana RPC: getRecentPerformanceSamples (https://solana.com/docs/rpc/http/getrecentperformancesamples) - Radix Network Gateway API (https://docs.radixdlt.com/docs/network-gateway) - Radix Docs: node setup (https://docs.radixdlt.com/docs/node-setup) ## Hyperscale: 500K TPS Public Test URL: https://radix.wiki/contents/tech/research/hyperscale-500k-tps Updated: 2026-09-03 Summary: In January 2026, the Radix Foundation completed the final public Hyperscale test, demonstrating that its Hyperscale reference implementation could sus… Date January 2026 (public test); February 20, 2026 (blog post) Software tested Radix Foundation Hyperscale reference implementation Sustained TPS 500,000+ Peak TPS 700,000+ Shards 128 shards (64-shard comparison: ~250k TPS) Nodes 384 bootstrap, 40 validators, 6 load-generation; 590+ community nodes in the public phase Hardware m6i.xlarge (4 CPU cores, 16GB RAM) per node Platform Amazon Web Services (Terraform + Ansible) Transaction type Real cross-shard swap transactions Open source Planned (pending agreement with third parties) Related hyperscale-rs (/contents/tech/research/hyperscale-rs) , Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Overview In January 2026, the Radix Foundation completed the final public Hyperscale test, demonstrating that its Hyperscale reference implementation could sustain over 500,000 transactions per second and peak above 700,000 TPS (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) – on commodity hardware using Amazon Web Services m6i.xlarge instances (4 CPU cores, 16 GB RAM per validator node (/contents/tech/core-concepts/validator-nodes) ). The test was documented in a February 20, 2026 blog post (https://www.radixdlt.com/blog/interim-hyperscale-closing-the-chapter) titled "Interim Hyperscale: Closing the Chapter." The word "interim" signals that these results represent a milestone rather than a ceiling. The results are frequently attributed to Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) . That attribution is disputed by the lead developer of the Xi'an production candidate (/contents/tech/research/hyperscale-rs) , who states that "Hyperscale never really used Cerberus" (https://t.me/hyperscale_rs) . The throughput figures are a property of the implementation that was tested, not of the protocol specified in the Cerberus whitepaper – whose braiding mechanism has never run in production. Linear Scaling Confirmed The defining result of the Hyperscale test series is the confirmation of linear scaling. Private tests compared 64-shard and 128-shard configurations directly: - 64 shards: ~250,000 TPS - 128 shards: ~500,000 TPS Doubling the shard count doubled the throughput, holding per-shard throughput constant – the property a sharded design exists to deliver. The public test confirmed it in practice with real cross-shard atomic swap transactions rather than simplified transfer workloads. The bottleneck during testing was transaction generation, not consensus. At peak load, the six m6i.12xlarge spam nodes (48 CPU cores, 192 GB RAM each) reached their generation limits before the validator network reached its processing limit, suggesting actual protocol capacity exceeds the measured results. The Committee-Size Caveat One qualification is important for reading these numbers forward. According to the lead developer of hyperscale-rs, the reference implementation could only sustain its headline throughput with very small per-shard committees, where the cost of inter-shard messaging stays hidden. At the committee sizes the Xi'an candidate targets – around 100 validators per shard, for meaningful Byzantine fault tolerance – he assesses that the older design would saturate the bandwidth of a single data centre at a fraction of the throughput. The published test materials do not state the per-shard committee size used. Test Infrastructure The public test involved 384 bootstrap nodes, 40 validator nodes, and 6 load-generation nodes, all provisioned on AWS using Terraform and Ansible automation. More than 590 community nodes also participated in the public phase, running hardware ranging from datacenter servers to laptops. Cross-shard atomic integrity was maintained throughout. Every swap transaction that crossed shard boundaries either fully succeeded or fully reverted – no partial state was ever committed. Open Sourcing Plans The Radix Foundation stated that code, tooling, and test logs are prepared for publication to enable independent reproduction of the results. Open sourcing requires agreement with parties outside the Foundation and did not have a confirmed timeline at the time of the blog post. The community implementation hyperscale-rs (/contents/tech/research/hyperscale-rs) predates this announcement. Its lead developer has stated it "throws out almost all designs" from both the original Cerberus and the Foundation's Hyperscale reference implementation; its per-shard consensus is HotStuff-2–derived rather than Cerberus. What the Test Establishes for Xi'an The tests demonstrate that a sharded Radix network can scale linearly on commodity hardware with real cross-shard transactions, and that cross-shard atomicity holds under load. That is a meaningful result about the approach. What the test does not establish is the performance of Xi'an (/contents/tech/releases/radix-mainnet-xian) as it is now being built. The software measured here is not the software heading for mainnet: the hyperscale-rs (/contents/tech/research/hyperscale-rs) candidate replaced the consensus design, targets committees roughly an order of magnitude larger, and deliberately trades peak throughput for validator hardware that home users can run – roughly 1,000 TPS per shard at about five-second finality, scaling by adding shards rather than by driving individual shards harder. Its execution layer is also changing: a purpose-built VM is underway (https://t.me/hyperscale_rs/10334) to replace the Radix Engine (/contents/tech/core-protocols/radix-engine) . Comparisons between the 2026 test figures and future Xi'an benchmarks are therefore not like for like. External Links - Interim Hyperscale: Closing the Chapter – Radix Blog (Feb 20, 2026) (https://www.radixdlt.com/blog/interim-hyperscale-closing-the-chapter) - Hyperscale Update: 500k+ Public Test Done – Radix Blog (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) - Cerberus Whitepaper – arXiv 2020 (https://arxiv.org/pdf/2008.04450) - hyperscale-rs – Community Rust Implementation (/contents/tech/research/hyperscale-rs) - Cerberus Consensus Protocol (/contents/tech/core-protocols/cerberus-consensus-protocol) ## Resource URL: https://radix.wiki/contents/tech/core-concepts/resources Updated: 2026-09-03 Summary: A resource is the Radix Engine 's first-class representation of a digital asset. Unlike token contracts on EVM-style chains – where balances are bookk… Layer Core Primitive Type Core Primitive Kinds Fungible, non-fungible Divisibility 0–18 decimal places (fungible) Roles minter, burner, withdrawer, depositor, recaller, freezer, non_fungible_data_updater Defined in radix-engine, radix-engine-interface Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction A resource is the Radix Engine (/contents/tech/core-protocols/radix-engine) 's first-class representation of a digital asset. Unlike token contracts on EVM-style chains – where balances are bookkeeping entries inside an arbitrary smart contract – Radix resources are engine-level primitives: the engine itself enforces conservation, ownership transfer, and authorization at the kernel level. Resources come in two flavours: fungible (divisible, homogeneous quantities) and non-fungible (discrete units, each with structured per-unit data). Every resource is created and managed by a ResourceManager component (/contents/tech/core-concepts/components) and is held in a vault, bucket, or proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) . This asset-oriented model (/contents/tech/core-concepts/asset-oriented-programming) is what eliminates entire vulnerability classes (re-entrancy, approve-and-drain, double-credit) at the protocol level rather than relying on application-level discipline. Fungible and Non-Fungible Resources Every resource is one of two kinds, fixed when it is created and never changed afterwards. A fungible resource is a quantity: any 10 XRD are interchangeable with any other 10 XRD, and the only per-resource parameter is divisibility — the number of decimal places its amounts may carry, which the engine caps at 18 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/fungible/fungible_resource_manager.rs) . A divisibility of 0 makes the resource whole-unit only. A non-fungible resource is a set of discrete units, each with its own local ID and its own structured, SBOR-encoded data record; those records are what NFTs on Radix (/contents/tech/core-protocols/nfts-on-radix) store on-ledger rather than in an off-ledger metadata file. Both kinds are instances of the same native blueprint (/contents/tech/core-concepts/blueprints-and-packages) family — the resource package (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource) , run by the Native VM (/contents/tech/core-protocols/vm-layer) rather than by developer WebAssembly. This is the structural difference from an ERC-20 or ERC-721 contract: minting, burning and transfer are not application code that a dApp author writes and may get wrong, they are engine behaviour that every resource on the network shares. What a resource's creator chooses is not how those operations work but who is allowed to invoke them. Resource Behaviours: the Roles Authority over a resource is expressed through named roles on its resource manager, each holding an access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) — typically allow_all, deny_all, or a requirement for a specific badge (/contents/tech/core-concepts/badges) . The names are constants in radix-engine-interface (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/resource_manager.rs) , and they are the same for every resource on the network: Role Authorises minter Creating new units, increasing total supply burner Destroying units, decreasing total supply withdrawer Taking units out of a vault depositor Putting units into a vault recaller Removing units from someone else's vault without their signature freezer Suspending withdrawals or deposits on a specific vault non_fungible_data_updater Rewriting the mutable fields of an existing non-fungible unit Because the roles live on the resource rather than on the account, they hold wherever the units travel: a vault in a dApp component obeys the same withdrawer rule as a vault in a user's smart account (/contents/tech/core-protocols/smart-accounts) . This is what the native-asset model (/contents/tech/core-concepts/native-assets-vs-token-approvals) replaces token approvals with — there is no per-contract allowance to grant, and nothing for a malicious contract to drain, because the right to move a resource is not something an account can hand out. Features, Updaters, and Locking Four of those powers are also features — Mint, Burn, Recall and Freeze (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/resource_manager.rs) — declared when the resource is created. A resource that ships without the Recall feature has no recall path at all; the capability is not dormant behind a permission, it is absent from the object. For the powers that do exist, each role is paired with an updater role — minter_updater, recaller_updater, freezer_updater and so on — which controls who may change that rule later. This second layer is the whole of a Radix resource's mutability story, and it is where the answer to "could the issuer change their mind?" lives. Set an updater to deny_all and the rule beneath it is frozen for the life of the network: no key, no badge, no governance vote (/contents/tech/core-concepts/radix-governance) and no protocol update can reopen it, because there is no one the engine would accept the instruction from. A resource whose every updater is deny_all is what block explorers report as having its rule set locked. The practical consequence is that a resource's guarantees are checkable rather than promised. Reading the role table off the ledger tells you what the issuer can still do, and reading the updater table tells you whether that answer can change — both without trusting the project's own description of its token. Worked Example: XRD's Own Authorities The network's native token is the clearest illustration, because its settings are unusually strict. Read live from mainnet at state version 546564033 (epoch 332718, 6 August 2026, 23:05 UTC), XRD (/contents/tech/core-protocols/xrd-token) carries 18 decimals, a total supply of 13,503,704,464.97 and this authority table: Role Rule Updater minter Requires a specific Global Caller badge deny_all burner Requires the same Global Caller badge deny_all recaller deny_all deny_all freezer deny_all deny_all withdrawer allow_all deny_all depositor allow_all deny_all Two things follow. First, XRD is mintable, which surprises people who read "fixed supply" into a native token — but the badge its minter requires is a Global Caller (https://dashboard.radixdlt.com/resource/resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd) badge, the implicit proof the engine issues to a component when it calls another component. Only one specific on-ledger component can present it, and in practice the mint path is the consensus manager (/contents/tech/core-concepts/consensus-manager) paying validator emissions (/contents/tech/core-concepts/network-emissions) each epoch. No key holder anywhere can mint XRD, and no one can grant themselves the ability, because the minter_updater is denied to everybody. Second, XRD cannot be recalled or frozen, and that is permanent. Both rules are deny_all and both updaters are deny_all, so the entire rule set is locked. The same read on any other resource answers the same question for it — several ecosystem tokens documented on this wiki turn out to be fixed-supply-and-locked in exactly this sense, while others leave a mint updater open. What Recall Can and Cannot Do Recall exists for the cases where an asset represents an off-ledger claim its issuer must be able to revoke: a membership badge, a regulated stablecoin under a court order, an access credential for a service that has ended. It is opt-in per resource, visible to anyone before they accept a unit, and the reason a wallet can tell a holder whether the thing they are being sent is revocable. What it is not is a network-wide recovery mechanism. Recall is a property of the resource, chosen by whoever created it — the network has no authority to reach into a vault on a resource whose creator did not enable it, and no way to add the feature afterwards to a resource whose rules are locked. A stolen token that was minted without recall stays where the thief put it, and the same holds for XRD by construction. Nor could per-unit ownership marking substitute for it on a fungible resource, since interchangeability is the definition of fungibility: a unit that remembers who held it is a non-fungible unit, which is the distinction the engine draws at creation. The protections Radix does offer against theft sit elsewhere in the stack — the access controller (/contents/tech/core-concepts/access-controller) for recovering an account, readable transaction manifests (/contents/tech/core-protocols/transaction-manifests) so a signer can see what they are agreeing to, and the asset-oriented model (/contents/tech/core-concepts/asset-oriented-programming) that makes an unlimited approval impossible to sign in the first place. External Links - resource native package (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource) - Role and feature definitions in radix-engine-interface (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/resource_manager.rs) - Fungible resource manager, including the divisibility limit (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/fungible/fungible_resource_manager.rs) - XRD on the Radix Dashboard — live authority table (https://dashboard.radixdlt.com/resource/resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd) - Radix Docs: Resources (https://docs.radixdlt.com/docs/resources) ## Substate Model URL: https://radix.wiki/contents/tech/core-concepts/substate-model Updated: 2026-09-03 Summary: The Substate Model is Radix's approach to storing and managing on-ledger state. Rather than using a global account-based model ( Ethereum ) or UTXOs (… Category State Model Comparison Not account model ( Ethereum (https://ethereum.org) ), not UTXO (https://en.wikipedia.org/wiki/Unspent_transaction_output) ( Bitcoin (https://bitcoin.org) ) Key Benefit Fine-grained parallelism Addressing NodeId → Partition Number → SubstateKey Defined by Kernel layer (https://radix-engine-docs.radixdlt.com/architecture/layers.html) of the Radix Engine (/contents/tech/core-protocols/radix-engine) Stored in A key-value database, keyed by partition key and sort key Overview The Substate Model is Radix's approach to storing and managing on-ledger state. Rather than using a global account-based model ( Ethereum (https://ethereum.org) ) or UTXOs ( Bitcoin (https://bitcoin.org) ), Radix breaks state into fine-grained pieces called substates. Each substate is an independently addressable, independently lockable piece of data. A component (/contents/tech/core-concepts/components) 's state might consist of dozens of substates – each vault, each metadata field, each access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) is its own substate. Why It Matters This granularity is what enables Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) to achieve unlimited parallelism. Two transactions that touch different substates can execute on different shards simultaneously, even if they interact with the same component. Only transactions that touch overlapping substates need coordination. Compare this to Ethereum's account model: any two transactions interacting with the same contract must be serialized, even if they access completely different data within that contract. This creates bottlenecks around popular contracts (DEXes, stablecoins). How a Substate Is Addressed Substates are not a storage detail bolted onto the ledger – they are one of the three abstractions the kernel layer (https://radix-engine-docs.radixdlt.com/architecture/kernel/index.html) of the Radix Engine is built around. The layered architecture reference lists the kernel’s responsibilities as defining the "Node, Partition, Substate abstractions", defining the call frame abstraction, maintaining ownership and reference invariants, and "managing transaction state updates, which are to be subsequently committed to the database at the end of the transaction" ( Radix Engine Docs (https://radix-engine-docs.radixdlt.com/architecture/layers.html) ). That gives every piece of on-ledger state a three-level address: - NodeId – the entity the state belongs to: a component, a resource manager, an account, a vault. - Partition Number – a numbered region of that node’s state, grouping related data together. - SubstateKey – the individual substate within the partition. Below the kernel, the database layer (https://radix-engine-docs.radixdlt.com/architecture/database/index.html) flattens this into partition-key and sort-key abstractions "implemented on top of a key-value database". The kernel is explicitly "implemented on top of the database layer’s Partition Key and Sort Key abstractions", so the addressing scheme the engine reasons about and the keys the store actually writes are the same structure at two levels of detail. For the layer that executes code against these substates, see Kernel Layer (/contents/tech/core-protocols/kernel-layer) and VM Layer (/contents/tech/core-protocols/vm-layer) . Where a Component’s Substates Come From A blueprint (/contents/tech/core-concepts/blueprints-and-packages) author never writes substates by hand. They declare fields – the individual pieces of a component’s state – and collections, the keyed structures (key-value stores, indexes, sorted indexes) a component uses for data that grows. "The mapping from the Fields and Collection indices to Partition Number is managed by the System Layer and done at a per blueprint basis" ( Radix Engine Docs (https://radix-engine-docs.radixdlt.com/architecture/system/blueprint_impl.html) ), so the layout is derived from the blueprint rather than chosen by the developer. Object modules contribute partitions of their own on top of the blueprint’s: a component’s metadata (/contents/tech/core-concepts/metadata-module) , its royalty configuration (/contents/tech/core-concepts/component-royalties) , and its access rules are each their own state, addressed separately from the fields the blueprint declares. This is why the count adds up the way it does: a single Scrypto (/contents/tech/core-protocols/scrypto-programming-language) component is not one state blob but dozens of independently addressable substates – every vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) it holds, every metadata entry, every access rule, and every entry in every collection. What the Granularity Buys Because a substate is the unit that gets read and written, it is also the unit that gets contended. Two transactions that touch disjoint substates have nothing to coordinate, even when they call into the same component – a swap against one vault and a metadata read on the same DEX are, as far as state is concerned, unrelated work. The comparison in the Overview holds in the other direction too. Under an account model the contract is the unit of state, so any two transactions touching a popular contract must be ordered against each other whether or not they share any data. Under a UTXO model the granularity is there, but state is consumed and recreated rather than updated in place, which makes long-lived shared state awkward to express. The practical consequence shows up in how Radix's sharded designs schedule work. hyperscale-rs (/contents/tech/research/hyperscale-rs) distinguishes per-substate locking – where a transaction's manifest (/contents/tech/core-protocols/transaction-manifests) and blueprint metadata are analysed ahead of execution to determine exactly which substates it will touch – from hot-state flagging for indivisible state such as a pool price, where one shard batches many transactions under a single amortized lock. Neither technique is available to a runtime whose smallest lockable unit is an entire contract. See Also - Radix Engine (/contents/tech/core-protocols/radix-engine) - Kernel Layer (/contents/tech/core-protocols/kernel-layer) - Resource (/contents/tech/core-concepts/resources) - Buckets, Proofs and Vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) - hyperscale-rs (/contents/tech/research/hyperscale-rs) External Links - Layered Architecture – Radix Engine Docs (https://radix-engine-docs.radixdlt.com/architecture/layers.html) - Kernel Layer – Radix Engine Docs (https://radix-engine-docs.radixdlt.com/architecture/kernel/index.html) - Blueprint Implementation – Radix Engine Docs (https://radix-engine-docs.radixdlt.com/architecture/system/blueprint_impl.html) ## Radix vs Cosmos URL: https://radix.wiki/contents/tech/comparisons/radix-vs-cosmos Updated: 2026-09-03 Summary: Radix and Cosmos take fundamentally different approaches to scalability: Cosmos uses sovereign app-chains connected via Inter-Blockchain Communication… Radix Single sharded ledger, atomic composability (/contents/tech/core-concepts/atomic-composability) Cosmos (https://cosmos.network) Sovereign app-chains, IBC (https://ibcprotocol.dev) message passing Key Difference Atomic cross-shard vs async cross-chain Overview Radix and Cosmos (https://cosmos.network) take fundamentally different approaches to scalability: Architecture Cosmos uses sovereign app-chains connected via Inter-Blockchain Communication ( IBC (https://ibcprotocol.dev) ). Each chain runs its own consensus and maintains its own state. Cross-chain operations are asynchronous messages – there's no atomic composability between chains. Radix uses a single sharded ledger with Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) braiding consensus across shards. Cross-shard transactions are atomic (/contents/tech/core-concepts/atomic-composability) – they either fully succeed or fully fail, enabling DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) composability that's impossible in the Cosmos model. Trade-offs Cosmos offers more app-chain sovereignty and customization. Radix offers stronger composability guarantees and a unified DeFi ecosystem. For DeFi specifically, Radix's atomic cross-shard model is more suitable – DeFi protocols need to compose with each other in single transactions. Scalability in practice (2026) The braided, effectively-unlimited-shard architecture described above is the design of Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , not the current state of the live network. Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet today runs a single, unsharded Cerberus instance; multi-shard consensus is being delivered through the Hyperscale (/contents/tech/research/hyperscale-rs) program (the eMunie → Tempo → Cerberus → Xi’an (/contents/tech/research/consensus-evolution) lineage). A January 2026 public test (/contents/tech/research/hyperscale-500k-tps) sustained 500,000+ real cross-shard transactions per second (peaking above 700,000) across 128 shards, as detailed in the Radix Hyperscale update (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) . The contrast with Cosmos (https://cosmos.network) is therefore about direction as much as design: Cosmos scales horizontally by launching more sovereign app-chains connected over IBC (https://ibcprotocol.dev) (each a separate trust boundary with asynchronous messaging), while Radix aims to scale a single atomically-composable ledger by sharding (/contents/tech/core-concepts/sharding) consensus underneath it – keeping cross-shard transactions atomic rather than message-passed. See also - hyperscale-rs (/contents/tech/research/hyperscale-rs) – the Rust implementation of Radix’s sharded consensus - Consensus Evolution at Radix (/contents/tech/research/consensus-evolution) - Radix vs Polkadot (/contents/tech/comparisons/radix-vs-polkadot) ## Decentralized Science (DeSci) URL: https://radix.wiki/contents/tech/core-concepts/decentralized-science-desci Updated: 2026-09-03 Summary: Decentralized Science (DeSci) refers to an emerging model of organizing and funding scientific research in a more open, collaborative, and decentraliz… Decentralized Science (DeSci) refers to an emerging model of organizing and funding scientific research (https://medium.com/molecule-blog/the-emergence-of-biotech-daos-407e31748cd4) in a more open, collaborative, and decentralized manner powered by Web3 technologies such as blockchain, cryptocurrency tokens, decentralized autonomous organizations (DAOs), and non-fungible tokens (https://en.wikipedia.org/wiki/Non-fungible_token) ( NFTs (/contents/tech/core-protocols/nfts-on-radix) ). Goals The goals and purported benefits (https://future.com/a-guide-to-decentralized-biotech/) of the DeSci model include enabling broader participation in science from different stakeholders like patients and researchers, moving power away from centralized research institutions towards decentralized communities, creating new tokenized funding and incentive models for research, and promoting open access collaboration. Some have referred to DeSci as aiming to create a " creator economy (https://www.molecule.xyz/blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm) " for scientists, in the same way that NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) have created new economic opportunities for artists. The DeSci movement has gained significant momentum over the past couple of years, with a growing number of projects and communities (https://youtu.be/5_ZNsiWhXfU) coalescing around building decentralized infrastructure for science spanning areas like funding, data sharing, open access publishing, governance, and laboratory services. Components Decentralized Funding Models A key component of the DeSci model is experimenting with new decentralized ways of allocating funding and incentives for scientific research, moving beyond traditional sources like government grants. Several DeSci projects have utilized DAOs to coordinate funding from a group of members to support early stage research. For example, VitaDAO is a community of over 5000 scientists and enthusiasts funding longevity research, having supported over $2 million in projects (https://youtu.be/5_ZNsiWhXfU) so far. NFTs representing intellectual property licenses have emerged as another DeSci funding method. Molecule's IP-NFT model (https://www.molecule.xyz/blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm) allows research assets to be listed and purchased on a marketplace, with the buyers having certain rights to resulting IP, data access, or royalty streams. Some projects are also experimenting with tokenized incentive models to motivate scientific contributions. Participants can earn and stake governance tokens for active involvement in a DeSci community, influencing decision making on what research gets funded. There is also interest in decentralized matching funds through mechanisms like quadratic funding (https://youtu.be/J1hUafXYchg) , which uses a mathematical formula to allocate donations in a way that rewards projects with the most support from small donors. Decentralized Knowledge Sharing Decentralizing access to scientific knowledge is another major focus area of the DeSci movement. This includes building open access platforms for publishing research as well as enabling more open data sharing. A number of projects are experimenting with blockchain-based solutions for open access scientific publishing (https://youtu.be/J1hUafXYchg) , including decentralized peer review models that incentivize community participation. These platforms aim to make papers and data more freely accessible outside of expensive journal paywalls. Enabling permissionless access to research data (https://youtu.be/J1hUafXYchg) is another priority. Distributed storage networks like Filecoin and Arweave allow researchers to permanently store datasets and control access rights using crypto wallets rather than centralized authorities. Data NFTs can also give fine-grained control over sharing specific datasets. Molecule has introduced a concept of attaching data access rights to IP-NFT research assets (https://www.molecule.xyz/blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm) , so purchasers can fund projects in exchange for access to resulting datasets. Data marketplaces are also emerging to allow the exchange of access rights to datasets. Standardized legal frameworks (https://youtu.be/5_ZNsiWhXfU) around areas like licensing and IP ownership rights are being developed to define how decentralized knowledge sharing models comply with regulations. Striking a balance between openness and commercial viability is an ongoing challenge. Decentralized Governance Decentralizing decision-making and control over scientific priorities is another defining goal of the DeSci paradigm shift. This means finding ways to include broader stakeholder participation beyond just centralized research institutions. A number of DeSci projects are working on reputation systems as a way to quantify contributions and grant different levels of governance influence. Metrics assessing community involvement, past research outputs, peer reviews etc. can help decentralize control. Patient groups and other interested community members are participating more actively in biomedical research DAOs (https://medium.com/molecule-blog/the-emergence-of-biotech-daos-407e31748cd4) using token-based voting and proposals to help determine key priorities and funding allocations. For example, members of the VitaDAO community leverage $VITA tokens for governance over which longevity studies get funded. Scientists themselves also have opportunities for more autonomy and ownership by participating in DeSci networks as contributors or stakeholders rather than relying on centralized academic institutions. Avoiding administrative gatekeepers can increase researcher agency and velocity. Decentralized Execution Emerging DeSci models provide more decentralized options for actually executing and operationalizing scientific research, introducing alternatives to relying solely on centralized research institutions. Biotech startups are increasingly leveraging decentralization (https://future.com/a-guide-to-decentralized-biotech/) including sharing lab space in coworking models, hiring talent across borders, and collaborating on projects. Other options mentioned for decentralizing research operations include: - Virtual biotech models (https://future.com/a-guide-to-decentralized-biotech/) that outsource lab processes to contract research organizations (CROs), sponsored research agreements (SRAs), and cloud labs. - LabDAO building a decentralized marketplace (https://youtu.be/J1hUafXYchg) to connect researchers with microCROs offering specific services. - Molecule's IP-NFT model (https://youtu.be/5_ZNsiWhXfU) allowing tokenized ownership or rewards for remote contributors participating across drug development stages. DeSci DAOs Organization Name Description Twitter Discord Telegram Other Links AsteriskDAO (https://asteriskdao.xyz/) Addressing the knowledge and resource gap in women’s non-reproductive health through worldwide research and IP funding. Twitter (https://twitter.com/asteriskdao) Discord (https://discord.gg/saMwDEZgq2) Telegram (https://t.me/asteriskdao) One Pager (https://www.notion.so/asteriskdao/AsteriskDAO-One-Pager-53c3baea512a45b29f7eff9850c12bc1?pvs=4) AthenaDAO (https://www.athenadao.co/) Advancing women’s health research, education, and funding, with a focus on translational R&D. - - - Reproductive Health Report (https://www.athenadao.co/#Report) CannabisDAO (https://cannabis-dao.xyz/) Supporting and developing the cannabis industry using DeSci and blockchain technology. Twitter (https://twitter.com/CANN_DAO) Discord (https://discord.gg/qfrd2wtmmB) Telegram (https://t.me/+hYHJpANjigI4NWVl) Docs (https://docs.cannabis-dao.xyz/) , Medium (https://medium.com/@cann_dao) Cerebrum DAO (https://cerebrumdao.com/) Investing in solutions & cures to Alzheimer’s disease and advancing brain wellness and longevity. Twitter (https://twitter.com/Cerebrum_DAO) Discord (https://discord.com/invite/pSAbaHf7Rf) - - CrunchDAO (https://www.crunchdao.com/) Solving complex problems through collective intelligence in quantitative finance. Twitter (https://twitter.com/CrunchDAO) - - DeSci Domain (https://desci.crunchdao.com/) , White Paper CureDAO (https://www.curedao.org/) Minimizing suffering by accelerating clinical discovery through a community-owned rewards system. Twitter Discord - Whitepaper (https://docs.curedao.org/?utm_source=desci-wiki) , App (https://app.curedao.org/?utm_source=desci-wiki) , Studies (https://studies.curedao.org/?utm_source=desci-wiki) DeSciWorldDAO (https://desci.world/) Connecting decentralized and scientific communities to further the mission of Decentralizing Science. Twitter (https://twitter.com/DeSciWorld) Discord (https://discord.gg/jnEUqVH8xv) - - FrontierDAO Incubating innovation in fusion energy, space exploration, and climate solutions. Twitter (https://twitter.com/FrontierDAO) Discord (https://discord.com/invite/UQVVw8QWrV) - Whitepaper, NFT Collection (https://opensea.io/frontierdao) Future Foods DAO Funding early-stage alternative protein open-source research. - - - - GenomesDAO (https://genomes.io/) Focusing on the security of genomic data and quality of research workflow. Twitter (https://twitter.com/GenomesDAO) Discord (https://discord.com/invite/3DaD2na4XJ) - DAO Docs (https://genomes.gitbook.io/genomes.io-docs/) GenomicDAO Advancing Precision Medicine for under-representative populations using AI. Twitter (https://twitter.com/genomicdao) - - Whitepaper HairDAO (https://www.hairdao.xyz/) Searching for a cure for hair loss. Twitter (https://twitter.com/HairDAO_) Discord (https://discord.com/invite/nEKD4qBPSU) - Whitepaper (https://uploads-ssl.webflow.com/61a12cfcc8291d38310ab2a4/61fb7b4f82f61e246e1d1f10_HairDAO%20White%20Paper.pdf) Immortality (https://imt.cx/) Cryptocurrency focused on age prevention and reversal. - - - Whitepaper (https://imt.cx/assets/pdf/whitepaper.pdf) Jocelyn DAO (https://jocelyn.gosh.sh/) Offering free tools for research code reproducibility and safety. Twitter (https://twitter.com/phs_dao) - Telegram (https://t.me/desci_gosh) LinkedIn (https://www.linkedin.com/company/91598780) LabDAO (https://github.com/labdao) An open, community-run network of laboratories with a CRO/Marketplace focus. Wound down – its GitHub organisation now describes it in the past tense, and both labdao.com and labdao.xyz have become domain-sale landing pages. Twitter (https://twitter.com/lab_dao) - - Resources (https://arye.substack.com/p/building-a-labdao-for-web3-biotech) , UltraRare Podcast (https://rss.com/podcasts/ultrarare/385698/) Open Science DAO (https://opsci.io/) A community-owned ecosystem revolutionizing collaboration and democratizing funding. Twitter - - News (https://www.opsci.io/) PsyDAO (https://www.psydao.io/) Funding research at the intersection of psychedelics and mental health. Twitter (https://twitter.com/psy_dao?s=20) Discord (https://discord.gg/hUH4MWxVFx) Telegram (https://t.me/+KvFGR2sVlOg2NTM0) - Reputable DAO (https://www.reputable.health/) A biohacking and personalized wellness community. Twitter Discord (https://discord.com/invite/bXaBCt4ueb) - Whitepaper (https://docs.reputable.health/product-docs/) Research Collective (https://researchcollective.io/) Performing decentralized trials and ‘adversarial research’. - - Telegram (https://t.me/+hDgQ1cZ_jZQ3MDgx) - ValleyDAO (https://valleydao.bio/) Supporting the transition to a sustainable bioeconomy by funding democratically elected academic research. Twitter (https://twitter.com/valley_dao) Discord (https://discord.gg/APD46yZD7E) - Announcement Article (https://valleydao.medium.com/5bc470a58482) VitaDAO (https://vitadao.com/) Funding longevity research with a mission to extend human life and healthspan. - - - Links (https://www.vitadao.com/) , Governance Proposals (https://snapshot.org/#/vote.vitadao.eth) , YouTube, Podcasts (https://anchor.fm/vitadao) , Articles (https://vitadao.medium.com/) , Newsletter Resources DeSci Berlin DeSci.Berlin (https://desci.berlin) 2022 - All Talks (https://www.youtube.com/playlist?list=PLYCWARA8YNdpVj31TutmnxptlK8Wy7O6D) DeSci.Berlin (https://desci.berlin) 2023 (https://www.youtube.com/playlist?list=PLYCWARA8YNdpZkxs-3a8f2VSUTp6EAlUu) DeSci London DeSci London (https://www.youtube.com/@descilondon/videos) Schelling Point 2022 DeSci @ Schelling Point Amsterdam 2022 (https://www.youtube.com/playlist?list=PLbOp_NX_vgZu251r8y-ZdZmhaeVCVgq7R) Articles A Guide to DeSci, the Latest Web3 Movement - a16z crypto (https://ethereum.org/en/desci/) What to know about the new DeSci movement (https://ethereum.org/en/desci/) odysee.com (https://odysee.com) odysee.com (https://odysee.com) With cryptocurrency and NFTs, ‘decentralized science’ seeks to upend drug industry financing (https://www.statnews.com/2022/06/23/with-cryptocurrency-and-nfts-decentralized-science-seeks-to-upend-drug-industry-financing/) With cryptocurrency and NFTs, "decentralized science" seeks to upend drug industry financing. (https://www.statnews.com/2022/06/23/with-cryptocurrency-and-nfts-decentralized-science-seeks-to-upend-drug-industry-financing/) Decentralized science platform Molecule raises $13 million in seed funding (https://www.theblock.co/post/151539/decentralized-science-platform-molecule-raises-13-million-in-seed-funding) Molecule has raised $13 million in seed funding in a round led by venture capital firm Northpond Ventures. (https://www.theblock.co/post/151539/decentralized-science-platform-molecule-raises-13-million-in-seed-funding) How to DAO with People, not just Protocols (https://mikemccoy.substack.com/p/how-to-dao-with-people-not-just-protocols) The concepts and tools to understand on how to build decentralized online communities and what it's all about (https://mikemccoy.substack.com/p/how-to-dao-with-people-not-just-protocols) Non fungible tokens (NFTs) for academic publications? (https://gencore.bio.nyu.edu/nfts-for-academic-publications/) Being rejected from the preprint server, bioRxiv, seemed like a new low for me. But, I was heartened to know that I was in good company. At least an explanation was provided by the bioRxiv team t (https://gencore.bio.nyu.edu/nfts-for-academic-publications/) How scientists are embracing NFTs (https://www.nature.com/articles/d41586-021-01642-3) Nature - Is a trend of auctioning non-fungible tokens based on scientific data a fascinating art fad, an environmental disaster or the future of monetized genomics? (https://www.nature.com/articles/d41586-021-01642-3) Epoch 16 - Decentralized Science - DeSci (https://bowtiedbiotech.substack.com/p/epoch-16-decentralized-science-desci?s=r) Pioneering Future Business Models for Biotech Financing & Governance (https://bowtiedbiotech.substack.com/p/epoch-16-decentralized-science-desci?s=r) DeSci: Can crypto improve scientific research? DeSci is a new movement of citizen scientists, open-access scientific research and crowd-sourced peer review funded by crypto that’s gathering pace in 2022. A DeSci Origin Story (https://medium.com/coinmonks/a-desci-origin-story-b6b234f7b1a3) How EncrypGen coined a term and helped start a movement (https://medium.com/coinmonks/a-desci-origin-story-b6b234f7b1a3) DeSci: How Can DAOs Facilitate Collaboration And Push The Open S… (https://coinvise.mirror.xyz/d_jTD1q4pFNXT8JwWUAp0o9TUacsBWNHr_LnRvTmivc) Hey there! Coinvise is a web3 platform that helps creators & communities build and manage their Social Tokens. You can join the community here. If you find this essay interesting, make sure to subscribe to this newsletter and follow Coinvise on Twitter. Enjoy! 🔥 (https://coinvise.mirror.xyz/d_jTD1q4pFNXT8JwWUAp0o9TUacsBWNHr_LnRvTmivc) How Do Decentralized Science (DeSci) Organizations Work? DeSci organizations, such as labDAO, attempt to harness the potential of blockchain and Web3 technology to reduce the challenges faced by scientific research. AIBC Intelligence: The rise of DeSci, Blockchain and the future of Research (https://aibc.world/news/aibc-intelligence-the-rise-of-desci-blockchain-and-the-future-of-research/) DeSci, a portmanteau of Decentralised Science, describes the burgeoning field of scientific research and inquiry as enabled through... (https://aibc.world/news/aibc-intelligence-the-rise-of-desci-blockchain-and-the-future-of-research/) Why Science? Why Blockchain? Why A DAO Now? (https://mirror.xyz/0x4A35674727c44cf4375d80C6171281Ba2f764213/oQ8iKsOm3Hb05pUA3oV_GFyiyqcmJJk6cFnwudXsbP8) By Paige Donner (https://mirror.xyz/0x4A35674727c44cf4375d80C6171281Ba2f764213/oQ8iKsOm3Hb05pUA3oV_GFyiyqcmJJk6cFnwudXsbP8) ## $XRD Token URL: https://radix.wiki/contents/tech/core-protocols/xrd-token Updated: 2026-09-03 Summary: $XRD is the native token of the Radix network . Unlike an ERC-20-style smart-contract token, XRD is a native asset – a first-class resource created an… $XRD Type Native network token Resource (/contents/tech/core-concepts/resources) Address resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd Maximum Supply 24 billion XRD (emission schedule — no resource-level cap) Genesis Supply 12 billion XRD ( Olympia (/contents/tech/releases/radix-mainnet-olympia) , 2021) Current Supply 13,505,461,118.64 XRD (epoch 333342, 9 Aug 2026) Emissions ~300M XRD/year (~12B over ~40 years) Divisibility 18 decimals Uses Fees, staking, DeFi collateral Overview $XRD is the native token of the Radix network (https://www.radixdlt.com) . Unlike an ERC-20-style (https://en.wikipedia.org/wiki/Ethereum) smart-contract token, XRD is a native asset (/contents/tech/core-concepts/asset-oriented-programming) – a first-class resource (/contents/tech/core-concepts/resources) created and enforced directly by the Radix Engine (/contents/tech/core-protocols/radix-engine) , moved between vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) rather than by contract-managed balance mappings. The Radix protocol describes XRD as the token “used to pay the network’s required transaction fees and to secure the network through staking to its validator nodes” ( Radix Knowledge Base (https://www.radixdlt.com/articles-learn/what-is-the-xrd-token) ). Primary Utility - Transaction fees – every transaction (/contents/tech/core-protocols/transaction-manifests) on Radix pays its network fee in XRD, and XRD is the only token that can. - Staking & security – XRD is staked to validators (/contents/tech/core-concepts/validator-nodes) to secure consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) ; stakers hold Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) . - Network emissions – ~300 million XRD per year is minted to reward stakers and validators (see Network Emissions (/contents/tech/core-concepts/network-emissions) ). - DeFi – XRD is the primary trading pair and collateral asset across Radix DeFi ( CaviarNine (/ecosystem/caviarnine) , Weft (/ecosystem/weft-finance) , Stabilis (/ecosystem/stabilis) ). Supply and Emissions XRD is scheduled to reach a maximum supply of 24 billion tokens. The ceiling lives in the protocol’s emission logic rather than in the resource: read on-ledger, XRD reports supply_fixed: false and mintable: true, with the minter and burner roles permanently locked to a system badge (/contents/tech/core-concepts/badges) so that only the protocol can create or destroy it (see Radix Economic Model (/contents/tech/research/radix-economic-model) ). Of that, 12 billion XRD was created at genesis when the Radix Public Network launched with the Olympia (/contents/tech/releases/radix-mainnet-olympia) mainnet in 2021, and the remaining 12 billion is being minted as network emissions over roughly 40 years – about 300 million XRD per year – as the incentive for stakers and validators securing the network ( Radix Knowledge Base (https://learn.radixdlt.com/article/start-here-radix-tokens-and-tokenomics) ). Because emissions are gradual and network fees are partly burned, the current total supply sits well below the cap: the on-ledger total supply of the XRD resource was 13,505,461,118.64 XRD at epoch 333342 (state version 547,628,486, 9 August 2026), against 13,513,127,623.88 ever minted and 7,666,505.23 ever burned ( Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd) ). The full economics of the emission/burn balance are examined on the Radix Economic Model (/contents/tech/research/radix-economic-model) page. Transaction Fees and Fee Burning Every Radix transaction pays a network fee denominated in XRD. Of the base network fee, 50% is permanently burned by the protocol – the tokens are destroyed, not redistributed ( Radix Knowledge Base (https://www.radixdlt.com/articles-learn/how-do-transaction-fees-work-on-radix) ). The other 50% is paid to validators in two equal halves: 25% to the validator that proposed the round the transaction landed in, and 25% shared across the active validator set. Those are the engine constants NETWORK_FEES_PROPOSER_SHARE_PERCENTAGE and NETWORK_FEES_VALIDATOR_SET_SHARE_PERCENTAGE, both set to 25 ( radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-common/src/constants/transaction_execution.rs) ); the burn is not a percentage at all but the remainder left after both are paid. Every mainnet receipt shows it — a 0.75854478253 XRD fee resolves to 0.379272391265 burned with 0.1896361956325 to each side. Any optional tip a transaction adds is paid in full to the round-leading validator. The burn is the deflationary counterweight to network emissions, but at current volumes it is a small one: 7,666,505.23 XRD has been burned in total against 13,513,127,623.88 ever minted, roughly nine days of issuance at ~300 million XRD a year (see Radix Economic Model (/contents/tech/research/radix-economic-model) ). Staking and Network Security Radix secures its ledger through delegated proof of stake. XRD holders stake to validator nodes (/contents/tech/core-concepts/validator-nodes) , and at each epoch the protocol selects the top 100 validators by delegated stake to run Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus ( Radix Docs (https://docs.radixdlt.com/docs/validator) ). Staked XRD is represented by Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) – transferable, DeFi-composable tokens whose redemption value rises as emissions (/contents/tech/core-concepts/network-emissions) accrue, so staking rewards compound automatically each epoch. Verifying XRD On-Ledger XRD is not a contract-deployed token, so it has a single canonical resource address on Radix mainnet: resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd Any wallet, explorer, or dApp can read the live supply, holders, and metadata for XRD directly from the ledger at that address – for example via the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd) or the Network Gateway API (https://docs.radixdlt.com/docs/network-gateway) . Because minting and burning of XRD are gated behind a protocol-owned badge (they cannot be performed by any user), the resource’s supply can only change through the emission and fee-burn rules described above. External Links - What is the XRD token? – Radix Knowledge Base (https://www.radixdlt.com/articles-learn/what-is-the-xrd-token) - Radix Tokens and Tokenomics – Radix Knowledge Base (https://learn.radixdlt.com/article/start-here-radix-tokens-and-tokenomics) - How do Transaction Fees Work on Radix? (https://www.radixdlt.com/articles-learn/how-do-transaction-fees-work-on-radix) - XRD resource – Radix Dashboard (live supply) (https://dashboard.radixdlt.com/resource/resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd) Related Pages - Radix Economic Model (/contents/tech/research/radix-economic-model) - Network Emissions (/contents/tech/core-concepts/network-emissions) - Staking on Radix (/contents/tech/core-concepts/staking) - How to Buy XRD (/contents/resources/how-to-buy-xrd) ## Radix Connect URL: https://radix.wiki/contents/tech/core-protocols/radix-connect Updated: 2026-09-03 Summary: Radix Connect is a framework designed to facilitate seamless interactions between mobile wallets and desktop browsers, specifically tailored for decen… Radix Connect is a framework designed to facilitate seamless interactions between mobile wallets and desktop browsers, specifically tailored for decentralized applications (dApps) on the Radix network (https://www.radixdlt.com) . Central to this technology is the Radix Connector Browser Extension, and the Radix Wallet (/contents/tech/core-protocols/radix-wallet) , a mobile-first tool that allows easy use of DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) and Web3.0 dApps on desktop environments. Radix Connect Functionality Radix Connect's primary function (https://learn.radixdlt.com/article/what-is-radix-connect) is to establish a secure, end-to-end encrypted, peer-to-peer connection between mobile wallets and desktop browsers. It features a straightforward one-time setup flow, involving a QR code scan by the Radix Wallet (/contents/tech/core-protocols/radix-wallet) to link with the user's desktop browser. This encrypted connection is designed to be robust and efficient, regardless of the network conditions. Radix Connector Browser Extension A pivotal element of the Radix Connect system is the Radix Connector browser extension (https://learn.radixdlt.com/article/what-is-the-radix-connector-browser-extension) . This extension serves as a conduit linking the Radix Wallet (/contents/tech/core-protocols/radix-wallet) on iOS or Android devices with dApp websites on desktop browsers. It differs from conventional wallet extensions like Metamask in that it doesn't store tokens or private keys but focuses on ensuring a secure connection to protect against potential cyber threats. Overview - Functionality: The Radix Connector operates in the background, creating a bridge between the Radix Wallet on iOS or Android mobile phones and dApp websites running on a desktop web browser. It does not function as a wallet itself and does not store tokens or private keys. - Primary Use: The primary purpose of the Radix Connector is to facilitate a secure and seamless connection for transactions and interactions with dApps while maintaining user privacy and security. Technical Aspects - Connection Protocol: The connection established by Radix Connect is end-to-end encrypted and peer-to-peer (P2P), meaning there is no need for a centralized server to relay messages. This ensures privacy and reduces the risk of interception or manipulation. - Installation and Pairing: Users can install the Radix Connect extension for Chrome from the official Radix website. After installation, a QR code is generated, which users scan using their mobile Radix Wallet to establish a secure link between their phone and desktop browser. - Security Measures: Radix Connect prioritizes security, providing critical information to the Radix Wallet about the dApp webpages connected, which is used to prevent various types of cyber attacks, including "man-in-the-middle" attacks involving fake or misleading websites. User Experience - Ease of Use: The extension offers a one-time setup flow for linking the mobile wallet to the desktop browser, simplifying the user experience and enhancing accessibility for interacting with dApps. - Mobility: Radix Connect allows the Radix Wallet to offer a mobile-first experience, enabling users to manage their digital assets and interact with dApps while on the go. Radix dApp Toolkit (https://github.com/radixdlt/radix-dapp-toolkit) √ Connect Button At the heart of Radix Connect's user experience is the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) ’s √ Connect button (https://www.radixdlt.com/blog/using-radix-dapp-toolkits-connect-button-for-great-wallet-connection-ux) . This toolkit, a typescript library, provides essential frontend functionalities for dApps. It simplifies the user experience by handling tasks like Persona (/contents/tech/core-protocols/personas) logins, user data caching, and browser session management. The √ Connect button acts as a visual and interactive element on dApp websites, representing the user’s Radix Wallet. It displays the user's login status, the Persona logged in with, and details of the data shared with the dApp. It also offers the functionality for users to update shared data or log out, creating a consistent and user-friendly interface across different dApps. User Login Management The Radix dApp Toolkit (https://www.radixdlt.com/blog/using-radix-dapp-toolkits-connect-button-for-great-wallet-connection-ux) also assists in managing user login states. It automatically recognizes a user as logged in upon selecting a Persona, reflected in the state of the √ Connect button. For dApps requiring additional verification, the toolkit can be configured accordingly. The "Update Data Sharing" feature further enhances user control, enabling them to refresh their shared data permissions directly from their wallet. ## Network Emissions URL: https://radix.wiki/contents/tech/core-concepts/network-emissions Updated: 2026-09-03 Summary: The Radix network mints new XRD as network emissions to reward the validators and stakers who secure the ledger. Roughly 300 million XRD is emitted pe… Network Emissions Annual Emissions ~300 million XRD (/contents/tech/core-protocols/xrd-token) (scheduled) Minted, 12 months to 9 Aug 2026 297,171,771 XRD Total Emission ~12 billion XRD over ~40 years Eventual Ceiling ~24 billion XRD — a 2025 vote to cut it to ~18 billion is unimplemented Distribution Validators → Stakers (minus commission) Mechanism Protocol-level, minted per epoch Reliability floor 1.0 – one missed round → zero emission for that epoch Ledger reading Epoch 333,486 · state version 547,837,876 · 9 Aug 2026 Overview The Radix network (https://www.radixdlt.com) mints new XRD (/contents/tech/core-protocols/xrd-token) as network emissions to reward the validators (/contents/tech/core-concepts/validator-nodes) and stakers who secure the ledger. Roughly 300 million XRD is emitted per year, distributed at the protocol level to validators running consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) and shared with their delegators minus a commission. Emissions are the primary long-term incentive for delegated proof-of-stake (/contents/tech/core-concepts/liquid-stake-units) security. Emission Schedule A fixed ~12 billion XRD is scheduled to be minted as network emissions over an approximately 40-year period, working out to roughly 300 million XRD per year ( Radix Knowledge Base (https://www.radixdlt.com/articles-learn/what-is-the-xrd-token) ). This emission is additive to the ~12 billion XRD created at the Olympia (/contents/tech/releases/radix-mainnet-olympia) genesis, giving XRD an eventual maximum supply of roughly 24 billion. Emissions are not paid continuously. At the end of each epoch the protocol mints a fixed batch of XRD and allocates it across the active validator set in proportion to the stake delegated to each validator ( Radix Knowledge Base (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-and-validator-fees-are-calculated-for-validators) ). How Rewards Reach Stakers At the start of every epoch the protocol checks the total XRD staked to each validator and automatically selects a validator set of 100 by stake weight for the duration of that epoch ( Radix Docs (https://docs.radixdlt.com/docs/validator) ). Each validator's emission share is reduced by its validator fee (commission) before the remainder flows to delegators. Stakers do not claim rewards transaction-by-transaction. Delegated XRD is represented by Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) , whose redemption value against the validator's stake pool rises as emissions accrue – so a staker's rewards compound automatically each epoch ( Radix Knowledge Base (https://www.radixdlt.com/articles-learn/how-do-token-holders-earn-and-claim-xrd-emissions-rewards) ). Reliability and Penalties Emissions are performance-weighted, not guaranteed. Each epoch the protocol scores a validator on its proposal success ratio – rounds it proposed against rounds it was due – and rescales that against the minimum reliability set in the Consensus Manager (/contents/tech/core-concepts/consensus-manager) configuration to get the fraction of its share it actually receives. Mainnet sets that minimum to 1, which makes the outcome binary. A validator that misses no rounds in an epoch takes its full share; a validator that misses one takes nothing for that epoch, and neither do its delegators. There is no sliding scale and no 98% threshold: the floor is every round ( Radix Docs (https://docs.radixdlt.com/docs/consensus-manager) , and min_validator_reliability in the engine’s mainnet genesis config (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) ). The demand is deliberate: epochs run five minutes, so the node’s genesis builder requires full reliability across each short window. Stakers are pushed to seek out well-run validators, and node-runners to keep every round. Forfeited emission does not go to the other validators, and it is not burned – it is never minted in the first place. The engine adds up the reliability-weighted stakes before it mints, so only the XRD that was actually earned is created. The ledger reading below (#what-the-ledger-shows) measures the effect: 297.2 million XRD minted against a 300 million schedule, with the 2.8 million difference simply absent from supply. Emissions and Supply Network emissions are inflationary by design, but two mechanisms temper their effect on circulating supply: emission forfeited to unreliability, which is never minted (above), and the burning of network transaction fees – 50% of every base network fee is permanently destroyed by the protocol ( Radix Knowledge Base (https://www.radixdlt.com/articles-learn/start-here-radix-tokens-and-tokenomics) ). The long-run balance between scheduled emissions and this fee/penalty burn is examined on the Radix Economic Model (/contents/tech/research/radix-economic-model) page. The 2025 vote to cut the ceiling to 18 billion The ~24 billion figure above is not the only number token holders have been given. In May 2025 the Radix Foundation (/ecosystem/radix-foundation) ran a token holder consultation on repurposing the 2.4 billion XRD stablecoin reserve — 1 billion to a points-based, multi-season incentives campaign, 1 billion to a Growth Fund for listings, bridges and ecosystem support, and 400 million held back “for potential extension or burn” ( Radix Blog, 9 May 2025 (https://www.radixdlt.com/blog/token-holder-consultation-repurposing-the-stablecoin-reserve) ). Carried in the same proposal was a change to the emission schedule itself: “shorten the emission schedule by 20 years, reducing the maximum supply by ~6 billion XRD” — taking the eventual ceiling from roughly 24 billion to roughly 18 billion. The consultation ran from 9 to 19 May 2025 and the result was published the next day: 91% of weighted input in favour, from more than 1.3 billion XRD of holdings across 1,180 accounts ( Radix Blog, 20 May 2025 (https://www.radixdlt.com/blog/token-holder-consultation-result) ). The result post committed the Foundation to “finalizing the structure” of the campaign and the fund, with “more details on both… shared in the weeks ahead”. It set no date for the emission change and named no mechanism for it — and there is no obvious one to name. The ceiling is not a field on the XRD resource (/contents/tech/core-concepts/resources) that can be edited: read on-ledger, XRD carries supply_fixed: false and no resource-level cap at all, so the 24 billion endpoint exists only as the point at which the protocol’s per-epoch emission is scheduled to stop (see Radix Economic Model (/contents/tech/research/radix-economic-model) ). Shortening it by twenty years means changing emission logic in a protocol update. No such change has reached the ledger. The section below measures the twelve months that followed the vote and finds issuance running at the original schedule’s rate. The Foundation moved to maintenance mode in April 2026 without implementing it, which leaves the change to the incoming Radix DAO — an approved tokenomics decision that remains, a year on, a commitment rather than a rule. What the ledger shows a year on The claim is checkable in two Gateway reads. Taking the XRD resource at the same clock time one year apart — epoch 228,366 (9 August 2025) and epoch 333,486 (9 August 2026), exactly 105,120 epochs apart — gives the network’s actual issuance across the year following the vote. XRD issuance, 12 months to 9 August 2026 Gross minted 297,171,771.38 XRD Burned 2,600,620.27 XRD Net supply growth 294,571,151.12 XRD Supply at the reading 13,505,865,658.61 XRD Against the ~300M schedule 99.1% – the shortfall is emission never minted, forfeited by validators that missed rounds 297.2 million XRD minted against a scheduled ~300 million is the original rate, not a rate cut by twenty years of shortening. The 0.9% gap is not policy either: it is the penalty described above, withheld from validators that missed proposals rather than paid out to them. The difference the vote would make is therefore still entirely ahead. Carried forward at the measured net rate of ~294.6 million XRD a year, supply reaches 18 billion in roughly 15 years and 24 billion in roughly 36 years — the twenty-year gap the proposal described, intact and unlegislated. Anyone modelling XRD dilution should treat 24 billion as the schedule the protocol is actually running and 18 billion as an approved intention with no implementation behind it. External Links - What is the XRD token? – Radix Knowledge Base (https://www.radixdlt.com/articles-learn/what-is-the-xrd-token) - How XRD staking emissions rewards and validator fees are calculated (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-and-validator-fees-are-calculated-for-validators) - Validators – Radix Docs (https://docs.radixdlt.com/docs/validator) ## Access Rules & Auth Zones URL: https://radix.wiki/contents/tech/core-concepts/access-rules-and-auth-zones Updated: 2026-09-03 Summary: An access rule is the unit of authorization on Radix. It is data attached to an object by the Role Assignment module , not code inside a component , a… Layer Radix Engine (/contents/tech/core-protocols/radix-engine) (system module) Pattern Declarative role-based access control Rule variants AllowAll, DenyAll, Protected(..) Checked Before the method body runs, once per call frame Max rule depth 8 nested requirement nodes Max rule nodes 64 composite requirements Defined in proof_rule.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/proof_rule.rs) , auth_module.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/auth_module.rs) Overview An access rule is the unit of authorization on Radix. It is data attached to an object by the Role Assignment module (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/role_assignment.rs) , not code inside a component (/contents/tech/core-concepts/components) , and it is evaluated by the Radix Engine auth module (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/auth_module.rs) before the called method body begins executing. The evidence a rule is tested against lives in the auth zone, a per-call-frame collection of proofs (https://docs.radixdlt.com/docs/auth) that the engine creates on entry and tears down on exit. The separation matters because it changes what a reader of a blueprint (/contents/tech/core-concepts/blueprints-and-packages) can know. A rule set is stored state, so anyone can read the current permissions of a deployed component out of the ledger without reading its code, and the engine will refuse an unauthorized call whether or not the blueprint author remembered to check. What it does not do is choose the rule for you: the engine enforces the rule that was declared, so a rule declared too loosely is enforced too loosely (see What the model does not do, below). The rule grammar AccessRule (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/proof_rule.rs) has exactly three variants: AllowAll, DenyAll, and Protected(CompositeRequirement). AllowAll authorizes unconditionally, DenyAll fails unconditionally, and everything else is a requirement tree. A CompositeRequirement is either a single BasicRequirement or an AnyOf / AllOf list of further composite requirements, so rules nest. The five basic requirements are: - Require(resource or non-fungible) – a proof of that resource (/contents/tech/core-concepts/resources) , or of that specific non-fungible, must be present - AmountOf(amount, resource) – a proof of at least the given amount - CountOf(n, list) – proofs of at least n distinct entries from the list, which is how N-of-M multi-signature is expressed - AllOf(list) – proofs of every entry - AnyOf(list) – a proof of any one entry The tree is bounded. The execution constants (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/transaction_execution.rs) cap it at MAX_ACCESS_RULE_DEPTH of 8 and MAX_COMPOSITE_REQUIREMENTS of 64 nodes, and the Role Assignment package (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/object_modules/role_assignment/package.rs) rejects any rule that exceeds either at the point it is set rather than at the point it is checked. Because the requirements name resources, an authorization token on Radix is an ordinary resource used as a credential rather than a special type. That convention is what the wiki calls a badge (/contents/tech/core-concepts/badges) . The auth zone The auth zone substate (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/auth_zone/auth_zone_substates.rs) holds three separate kinds of evidence, and only the first is what most descriptions mean by "the proofs": - proofs – real proof (https://docs.radixdlt.com/docs/auth) objects pushed into the zone from a bucket or vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) - simulate_all_proofs_under_resources – resources under which every possible proof is treated as present - implicit_non_fungible_proofs – virtual badges the engine supplies without anyone creating them The implicit set is the part with no equivalent elsewhere. A transaction signature places a virtual non-fungible badge under the Ed25519 or secp256k1 signature resource, which is how a rule can require "signed by this key" without any token existing. On top of that the engine derives two caller badges for each frame: package_of_direct_caller, naming the package that made the call, and global_caller, naming the global component or the blueprint function it originated from. A component can therefore gate a method on being called by a particular package or by a particular sibling component, with no shared secret and nothing to pass in. The zone is per call frame, not per transaction. The auth module (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/auth_module.rs) creates a fresh auth zone on every CALL_FUNCTION and CALL_METHOD and destroys it when the frame finishes. It links the new zone to its parent only when the call stays inside the same global context; when the call crosses into a different global component the parent is set to None, so proofs do not leak across the boundary. Calling a component does not hand it your badges. The zone is also addressable directly. Its blueprint interface (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/auth_zone.rs) exposes push, pop, drain, create_proof_of_amount, create_proof_of_non_fungibles, create_proof_of_all, assert_access_rule, and three separate drops: drop_proofs, drop_regular_proofs, and drop_signature_proofs. The last is the one that matters for manifest (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) hygiene, because it removes the signature-derived virtual badges while leaving explicitly created proofs in place. How a check is resolved On a method call (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/auth_module.rs) the engine resolves the method to a permission and then tests it, in that order, before the body runs. The permission comes from the blueprint's own declaration and is one of four kinds: Public, OuterObjectOnly (used by the Validator blueprint to restrict certain methods to the Consensus Manager (/contents/tech/core-concepts/consensus-manager) ), OwnPackageOnly, or RoleProtected with a list of role names. A role name is then resolved to a rule against the object's own role assignment, and the resolution has two special cases worth knowing (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/authorization.rs) : - _self_ is not stored. It resolves to require(global_caller()), meaning the object calling itself. - An undefined role does not deny. If the role has no entry in the role-assignment key-value store, the engine reads the object's owner role and tests that rule instead. A role a blueprint declares but never assigns is owner-gated, not locked. The rule is then evaluated against the auth zone of the calling frame, walking up the parent chain where one exists. AllowAll passes, DenyAll fails and returns the rule itself in the failure, and a protected rule is checked node by node against the three kinds of evidence above. What the model does not do System-level enforcement removes one class of defect: a method cannot execute with its guard forgotten, because the guard is not in the method. It does not remove authorization bugs as a category, and three limits are worth stating plainly. - The rule is a design decision. AllowAll on a mint role is enforced exactly as faithfully as a badge requirement. The engine has no opinion about which was intended. - Undefined roles inherit the owner rule rather than failing closed, per the resolution path above (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/authorization.rs) . An incomplete role assignment is a permissive outcome, not a restrictive one. - Ownership can be mutable or fixed, and the difference is set once. The owner role (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/role_assignment.rs) is declared as None, Fixed, or Updatable at instantiation; see the Role Assignment module (/contents/tech/core-concepts/role-assignment-module) for what each implies. What the model does change is auditability. Because the rules are stored state rather than control flow, the permissions of a live component can be read off the ledger and compared against what its documentation claims, without trusting either the source code or the deployer. External Links - Radix Docs: Authorization & Access Rules (https://docs.radixdlt.com/docs/auth) - Radix Docs: Access Rules & Roles (https://docs.radixdlt.com/docs/advanced-accessrules) - radixdlt-scrypto: proof_rule.rs (AccessRule and the requirement grammar) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/proof_rule.rs) - radixdlt-scrypto: auth_zone_substates.rs (what the auth zone holds) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/resource/auth_zone/auth_zone_substates.rs) - radixdlt-scrypto: auth_module.rs (call-frame auth zones and the global-context barrier) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/auth/auth_module.rs) - radixdlt-scrypto: execution constants (rule depth and node caps) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/transaction_execution.rs) ## Radix Technology URL: https://radix.wiki/contents/tech Updated: 2026-09-03 Summary: Radix is a layer-one network built around a claim that sounds modest and is not: that a ledger should understand what an asset is. On nearly every oth… Consensus Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Execution Radix Engine (/contents/tech/core-protocols/radix-engine) Contract language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Model Asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) Current release Babylon (/contents/tech/releases/radix-mainnet-babylon) Open question Sharded scale, at Xi’an (/contents/tech/releases/radix-mainnet-xian) Introduction Radix is a layer-one network built around a claim that sounds modest and is not: that a ledger should understand what an asset is. On nearly every other network an asset is a convention – a balance held in a contract’s storage, obeying whatever rules that contract’s author wrote and whatever bugs they left. On Radix, assets are objects the Radix Engine (/contents/tech/core-protocols/radix-engine) holds and moves itself, and application code can only ask the engine to move them. Almost everything else in this section follows from that decision, including the parts that are still unfinished. The stack Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) is the consensus layer, a BFT protocol designed so that transactions touching unrelated state can be agreed in parallel rather than serialized into one chain. Above it the Radix Engine (/contents/tech/core-protocols/radix-engine) executes transactions against a state model of typed objects, and Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , a dialect of Rust, is how developers write for it. Core concepts (/contents/tech/core-concepts) is where the vocabulary lives: resources (/contents/tech/core-concepts/resources) , buckets, proofs and vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) , badges (/contents/tech/core-concepts/badges) , components (/contents/tech/core-concepts/components) and blueprints (/contents/tech/core-concepts/blueprints-and-packages) . Core protocols (/contents/tech/core-protocols) covers the layers themselves, and atomic composability (/contents/tech/core-concepts/atomic-composability) is the property the whole arrangement exists to preserve: any two applications can be combined inside one transaction that either wholly succeeds or wholly does not. The rest of this section Releases (/contents/tech/releases) tracks the named mainnets from Olympia (/contents/tech/releases/radix-mainnet-olympia) through Babylon (/contents/tech/releases/radix-mainnet-babylon) to Xi’an, and the protocol updates between them. Research (/contents/tech/research) holds the thirteen years of consensus designs behind the current one, including the abandoned ones. Comparisons (/contents/tech/comparisons) sets Radix against Ethereum, Solana, Cosmos and Polkadot. Operations (/contents/tech/operations) covers running against the live network. What is settled and what is not The execution half of the design is live and has been since Babylon in September 2023. Asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) programming, badges, manifests (/contents/tech/core-protocols/transaction-manifests) and the wallet are all in production, and the properties they claim can be checked against mainnet today. The scalability half is not. Cerberus as specified runs unsharded on mainnet, the braided cross-shard consensus in the whitepaper has never shipped, and the sharded design that motivated the project waits on Xi’an (/contents/tech/releases/radix-mainnet-xian) . A reader evaluating Radix should keep those halves apart: one is a shipped system with a track record, the other is a research programme with promising test numbers and no mainnet. ## Smart Accounts URL: https://radix.wiki/contents/tech/core-protocols/smart-accounts Updated: 2026-09-03 Summary: On Radix, every account is a smart account – a programmable component on the ledger with configurable access rules , deposit preferences, and recovery… Type Account Architecture Key Feature Programmable by default Enhanced By MFA Security Shield Overview On Radix, every account is a smart account – a programmable component (/contents/tech/core-concepts/components) on the ledger with configurable access rules (https://docs.radixdlt.com/docs/auth) , deposit preferences, and recovery mechanisms. This is not an add-on feature; it's the default account type. Each smart account can: - Control access – Define which keys or badges (https://docs.radixdlt.com/docs/user-badge-pattern) can withdraw, deposit, or modify the account via access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) - Filter deposits – Accept or reject specific resource (/contents/tech/core-concepts/resources) types (spam token prevention) - Multi-factor security – Combine multiple keys via the MFA Security Shield - Social recovery – Designate trusted contacts who can help recover access Compare to Ethereum (https://ethereum.org) 's EOA (externally owned account), which is just a private key with no on-chain logic. Ethereum's "smart accounts" (ERC-4337) are a retrofitted workaround; on Radix, they're native. ## Radix Core API URL: https://radix.wiki/contents/tech/core-protocols/radix-core-api Updated: 2026-09-03 Summary: The Radix Core API provides low-level access to Radix nodes for transaction submission, state queries, and network monitoring. It's primarily used by… Type Node-Level API Audience Infrastructure operators, exchanges Higher-Level Gateway API (/contents/tech/core-protocols/radix-gateway-api) Overview The Radix Core API (https://docs.radixdlt.com/docs/network-apis) provides low-level access to Radix nodes for transaction submission, state queries, and network monitoring. It's primarily used by infrastructure operators, exchanges, and the Gateway API (/contents/tech/core-protocols/radix-gateway-api) (which sits on top of it to provide a developer-friendly interface). Most dApp developers use the Gateway API (https://docs.radixdlt.com/docs/network-gateway) rather than the Core API (https://docs.radixdlt.com/docs/core-api-providers) directly. The Core API is essential for running the Radix Dashboard (https://dashboard.radixdlt.com) , block explorers, and exchange integrations. What the Core API Exposes Per the network APIs documentation (https://docs.radixdlt.com/docs/network-apis/) , the Core API offers both low-level and high-level abstractions and covers four things: a long-term-support (LTS) sub-API aimed at financial integrators; a usefully abstracted but deliberately not comprehensive view of current ledger state, including account balances and other key native components (/contents/tech/core-concepts/components) ; transaction preview, submission and status flow; and a committed transaction stream available at varying levels of abstraction. It is exposed by Radix nodes (/contents/tech/core-concepts/validator-nodes) themselves and is predominantly intended as a private API – the public availability that exists comes from third-party RPC providers rather than from the protocol. Core API, Gateway API and Engine State API Radix exposes three read/write network APIs, and the distinction is one of abstraction rather than capability. The Core API is the node’s own interface, used by infrastructure operators, exchanges and the Gateway itself. The Gateway API (/contents/tech/core-protocols/radix-gateway-api) sits above it, is served by the Network Gateway rather than by a node, and adds what a front end needs – filterable committed transaction history, queries against historic ledger state, and resubmission management on behalf of users. The Engine State API is the third and least-known: it exposes the complete current state of the ledger at the engine’s own abstraction, so it is comprehensive where the Core API is selective, with fewer and more general endpoints. It is served by nodes but is off by default and must be explicitly enabled in node configuration. Access and Providers The Radix Foundation does not run a public Core API, and the documented providers (https://docs.radixdlt.com/docs/core-api-providers/) – a list the docs state is not vetted and implies no endorsement – have gone from two to one. NowNodes (https://nownodes.io) still serves the Core API at xrd.nownodes.io under paid plans with a month-long trial. Grove (https://www.grove.city) , founded by the team behind Pocket Network (https://pocket.network) and long the only free option, is gone – and it went earlier than the wiki assumed. Grove announced on 10 November 2025 (https://medium.com/decentralized-infrastructure/groves-next-chapter-moving-up-the-stack-fd7ecaf0a184) that it was stepping away from operating the Grove Portal, migrating its paid and public endpoint traffic to api.pocket.network over that month and handing its RPC and validator infrastructure to an entity called BuildInTheShade; the company itself has since published a farewell note and archived all 195 repositories in its GitHub organisation (https://github.com/buildwithgrove) . The docs still publish its shared endpoint, radix-mainnet.rpc.grove.city, as free access up to 5 million requests per day. That host, portal.grove.city and buildintheshade.com are all absent from DNS, and Pocket Network's public endpoints do not carry Radix – so the documented free route to a Core API has led nowhere for months. The remaining option is to run a node, which is what the API is designed for and what gives control of the infrastructure, at the cost of tracking every protocol update (/contents/tech/releases/protocol-updates) . External Links - Full Core API specification (https://docs.radixdlt.com/api-reference/core-api-specs.html) - Core API providers (https://docs.radixdlt.com/docs/core-api-providers/) - Engine State API specification (https://docs.radixdlt.com/api-reference/engine-state-api-specs.html) - TypeScript Core API SDK (https://www.npmjs.com/package/@radixdlt/babylon-core-api-sdk) ## RRC-404 URL: https://radix.wiki/contents/tech/core-protocols/rrc-404 Updated: 2026-09-03 Summary: RRC-404 is an implementation of the ERC-404 token standard on Radix, developed using the Scrypto programming language. It aims to provide fungible liq… Type Hybrid fungible / non-fungible token standard Based on ERC-404 (https://decrypt.co/resources/what-is-erc-404-the-experimental-semi-fungible-ethereum-token-standard) (Ethereum) Language Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Reference implementation ice_rrc404v1 (https://github.com/aus87/ice_rrc404v1) (MIT) Author ICE (/ecosystem/ice) (aus87) First published February 2024 RRC-404 is an implementation of the ERC-404 (https://decrypt.co/resources/what-is-erc-404-the-experimental-semi-fungible-ethereum-token-standard) token standard on Radix, developed using the Scrypto (/contents/tech/core-protocols/scrypto-programming-language) programming language. It aims to provide fungible liquidity for non-fungible tokens (NFTs), blurring the lines between fungible and non-fungible assets. https://x.com/aus877/status/1761873683662946654 (https://x.com/aus877/status/1761873683662946654) Overview The ERC-404 standard, originally designed for the Ethereum blockchain, introduces a hybrid token type that combines aspects of both fungible (ERC-20) and non-fungible (ERC-721) tokens (https://ethereum.org/en/developers/docs/standards/) . This allows for fractional ownership of NFTs and the ability to trade them on decentralized exchanges (DEXs), providing liquidity for traditionally illiquid NFT assets. However, the ERC-404 implementation has faced criticism for creating unpredictable behaviors (https://twitter.com/aus877/status/1761535221701202261) and confusion around the mapping between fungible tokens and associated NFTs. RRC-404 takes a different approach by leveraging the native resource model (https://docs.radixdlt.com/docs) of the Radix ledger to clearly separate fungible and non-fungible states while facilitating conversion between the two. The key goal of RRC-404 is to simplify the concept of NFT liquidity and provide a more predictable and user-friendly experience (https://twitter.com/aus877/status/1761873683662946654) compared to ERC-404. By using distinct fungible and non-fungible resources (/contents/tech/core-concepts/resources) , RRC-404 aims to eliminate the potential for accidental loss or burning of NFTs during token transfers, a concern raised with the ERC-404 implementation. RRC-404 Design and Features The design of RRC-404 takes a fundamentally different approach compared to ERC-404 by leveraging the native resource model of the Radix ledger. Unlike Ethereum's ERC tokens, which are defined as smart contracts, Radix uses native resources with predefined behaviors (https://docs.radixdlt.com/docs/resources) that resemble physical money. Distinct Fungible and Non-Fungible Resources At the core of RRC-404 is the separation of fungible and non-fungible assets (https://twitter.com/aus877/status/1761873683662946654) into distinct resource types. Instead of mapping a fungible token to every NFT as in ERC-404, RRC-404 ensures that a user can only hold either a fungible token or a non-fungible token at any given time. This design choice eliminates the potential for accidental loss or burning of NFTs during token transfers, as there is no invisible mapping that could result in unintended consequences. Conversion Between Fungible and Non-Fungible States RRC-404 introduces a dedicated smart contract component (https://github.com/aus87/ice_rrc404v1) that facilitates the conversion between fungible and non-fungible states. Users can interact with this component (/contents/tech/core-concepts/components) to "freeze" their fungible tokens into NFTs or "melt" their NFTs back into fungible tokens. This conversion process is designed to be predictable and user-controlled, allowing holders to freely trade or transfer their assets in either state without worrying about unintended consequences. Rarity Percentage Targets Unlike ERC-404, which uses a hash function to determine the rarity of minted NFTs, RRC-404 introduces a novel approach based on rarity percentage targets (https://twitter.com/aus877/status/1761535221701202261) . The smart contract logic aims to maintain a predefined percentage distribution for each rarity level (e.g., 42% green, 30% blue, 16% red, etc.). When minting new NFTs, the contract prioritizes the rarity level that has deviated the most from its target percentage in the current circulating supply. This approach provides a degree of transparency and predictability regarding the distribution of rarities. Time Delays and Royalties To discourage frequent "rerolling" of NFTs, RRC-404 implements a time delay mechanism (https://twitter.com/aus877/status/1761873683662946654) . Once an NFT is minted, there is a predefined period (e.g., 4 hours) during which it cannot be melted back into a fungible token. This introduces a cooldown period and encourages more intentional conversions. Additionally, RRC-404 incorporates a small royalty fee (https://github.com/aus87/ice_rrc404v1) (e.g., 1 $ XRD (/contents/tech/core-protocols/xrd-token) ) that is collected whenever a user performs a conversion between fungible and non-fungible states. This royalty mechanism provides a potential revenue stream for the creators or maintainers of the RRC-404 contract. How RRC-404 Works The core functionality of RRC-404 revolves around two main methods: Freeze and Melt. These methods allow users to convert between the fungible and non-fungible states of the token. Freeze: Converting Fungible Tokens to NFTs The Freeze method enables users to convert their fungible tokens into non-fungible tokens (NFTs). To initiate this process, the user must first withdraw the desired amount of fungible tokens from their wallet into a separate bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) . Once the fungible tokens are in the bucket, the user can call the Freeze method on the RRC-404 smart contract component, passing the bucket as an argument. The component then performs the following steps: - Checks the total supply of fungible tokens and NFTs to ensure that minting new NFTs will not exceed the maximum supply. - Determines the rarity level of the new NFTs based on the current circulating supply and the predefined rarity percentage targets. - Mints the appropriate number of new NFTs with the corresponding rarity metadata. - Burns the fungible tokens from the provided bucket. - Deposits the newly minted NFTs into the user's wallet. Example code snippet for calling the Freeze method: CALL_METHOD Address("your_address") "withdraw" Address("fungible_token_address") Decimal("amount") TAKE_ALL_FROM_WORKTOP Address("fungible_token_address") Bucket("fungible_bucket") CALL_METHOD Address("rrc404_component_address") "freeze" Bucket("fungible_bucket") CALL_METHOD Address("your_address") "deposit_batch" Expression("ENTIRE_WORKTOP") Melt: Converting NFTs to Fungible Tokens The Melt method allows users to convert their NFTs back into fungible tokens. There are two variations of this method: - Melt by Amount: Users can withdraw a specific number of NFTs from their wallet and melt them into fungible tokens. - Melt by IDs: Users can selectively withdraw specific NFTs by their unique IDs and melt those NFTs into fungible tokens. To use the Melt method, the user must first withdraw the desired NFTs from their wallet into a separate bucket. Then, they can call the Melt method on the RRC-404 smart contract component, passing the bucket as an argument. The component will check if the time delay period has elapsed since the NFTs were minted (e.g., 4 hours). If the delay has passed, the component will burn the NFTs from the provided bucket and mint the corresponding amount of fungible tokens, depositing them into the user's wallet. Example code snippet for calling the Melt method by amount: CALL_METHOD Address("your_address") "withdraw" Address("nft_token_address") Decimal("amount") TAKE_ALL_FROM_WORKTOP Address("nft_token_address") Bucket("nft_bucket") CALL_METHOD Address("rrc404_component_address") "melt" Bucket("nft_bucket") CALL_METHOD Address("your_address") "deposit_batch" Expression("ENTIRE_WORKTOP") During both the Freeze and Melt processes, the RRC-404 contract collects a small royalty fee (e.g., 1 $XRD) to incentivize the creators and maintainers of the contract. By separating the fungible and non-fungible states and providing user-controlled conversion methods, RRC-404 aims to simplify the process of managing NFT liquidity while maintaining predictable and transparent behavior. Benefits and Advantages The RRC-404 implementation offers several key benefits and advantages over the ERC-404 standard on Ethereum: Simplicity and Predictability One of the primary goals of RRC-404 is to simplify the concept of providing liquidity for non-fungible tokens (NFTs). By clearly separating the fungible and non-fungible states into distinct resources (https://twitter.com/aus877/status/1761873683662946654) , RRC-404 eliminates the potential for unpredictable behaviors and accidental loss or burning of NFTs during token transfers. Users can hold and transact with either fungible tokens or NFTs without worrying about unintended consequences, as there is no invisible mapping or coupling between the two asset types. User Control and Intentionality With RRC-404, users have complete control over the conversion process (https://github.com/aus87/ice_rrc404v1) between fungible and non-fungible states. The dedicated smart contract component provides explicit methods (Freeze and Melt) for users to initiate these conversions intentionally. This level of user control ensures that changes to asset states are deliberate and well-understood, reducing the risk of accidental or unintended actions that could result in the loss of valuable NFTs. Transparency and Predictability of Rarity Distribution Unlike ERC-404, which uses a hash function to determine the rarity of minted NFTs, RRC-404 introduces a novel approach based on rarity percentage targets (https://twitter.com/aus877/status/1761535221701202261) . By aiming to maintain predefined percentage distributions for each rarity level, RRC-404 provides transparency and predictability regarding the distribution of rarities in the circulating supply. While users cannot control the exact rarity of the NFTs they mint, they can have a general understanding of the likelihood of minting a particular rarity level based on the current supply. Royalty Mechanism for Creators and Maintainers RRC-404 incorporates a small royalty fee (https://github.com/aus87/ice_rrc404v1) that is collected whenever a user performs a conversion between fungible and non-fungible states. This royalty mechanism provides a potential revenue stream for the creators and maintainers of the RRC-404 contract, incentivizing them to continue developing and supporting the standard. Time Delay for Melting NFTs To discourage frequent "rerolling" of NFTs, RRC-404 implements a time delay mechanism (https://twitter.com/aus877/status/1761873683662946654) . Once an NFT is minted, there is a predefined period (e.g., 4 hours) during which it cannot be melted back into a fungible token. This cooldown period encourages more intentional and strategic conversions, rather than rapid speculation or farming. Compatibility with Radix's Native Resource Model By leveraging the native resource model (https://docs.radixdlt.com/docs/resources) of the Radix ledger, RRC-404 seamlessly integrates with the underlying blockchain infrastructure. This inherent compatibility ensures that the implementation adheres to the design principles and security guarantees of the Radix ecosystem, potentially simplifying future developments and integrations. Potential Applications and Use Cases The RRC-404 implementation on the Radix blockchain presents several intriguing potential applications and use cases for enabling liquidity for non-fungible tokens (NFTs). Fractional Ownership of NFTs One of the primary motivations behind standards like ERC-404 and RRC-404 is to facilitate fractional ownership of NFTs. By allowing users to hold and trade fungible tokens representing fractional shares of an NFT, these standards open up new possibilities for investment, speculation, and shared ownership models. With RRC-404, users can convert their fungible tokens into whole NFTs or vice versa, enabling them to buy or sell fractions of NFTs as desired. This could potentially increase the accessibility and liquidity of NFT markets, attracting a wider range of investors and collectors. Liquidity for NFT Collections RRC-404 can provide much-needed liquidity for NFT collections (https://twitter.com/aus877/status/1761873683662946654) , which are traditionally illiquid assets. By allowing users to convert their NFTs into fungible tokens, RRC-404 enables these assets to be traded on decentralized exchanges (DEXs) and participate in various decentralized finance (DeFi) protocols. This increased liquidity could attract more interest and investment in NFT projects, as holders would have the ability to easily enter or exit their positions without relying solely on peer-to-peer sales or centralized marketplaces. Real-World Asset Tokenization The concept of fractional ownership and liquidity for NFTs can be extended to the tokenization of real-world assets. RRC-404 could potentially be used to represent ownership shares in physical assets like real estate, art, or collectibles, enabling fractional investment and trading opportunities. By tokenizing these assets as NFTs and providing a mechanism for liquidity through fungible tokens, RRC-404 could open up new avenues for democratizing access to traditionally illiquid and exclusive asset classes. Gaming and Virtual Economies The gaming and virtual world industries have been early adopters of NFT technology, using it to represent unique in-game assets, virtual land, and other digital collectibles. RRC-404 could potentially be integrated into these virtual economies, allowing players to convert their NFTs into fungible tokens and participate in various in-game marketplaces or economies. This could create new gameplay mechanics, incentive structures, and trading opportunities within virtual worlds, further blurring the lines between digital and real-world economies. Decentralized Finance (DeFi) Integrations By providing a mechanism for converting NFTs into fungible tokens, RRC-404 could enable various integrations with decentralized finance (DeFi) protocols and applications. NFTs could potentially be used as collateral for lending or borrowing, or as underlying assets for derivatives or synthetic products. This integration could unlock new use cases and financial instruments within the DeFi ecosystem, further expanding the potential applications and utility of NFTs beyond their traditional roles as collectibles or digital art. As the adoption of blockchain technology and NFTs continues to grow, the RRC-404 implementation on the Radix blockchain could play a significant role in bridging the gap between fungible and non-fungible assets, enabling new forms of ownership, investment, and liquidity in various industries and ecosystems. Future Developments and Challenges While the RRC-404 implementation on the Radix blockchain offers a promising approach to enabling liquidity for non-fungible tokens (NFTs), there are several potential areas for future development and challenges that need to be addressed. Scalability and Performance As the adoption of NFTs and tokenized assets grows, the scalability and performance of the underlying blockchain infrastructure will become increasingly important. The Radix ledger, powered by its novel Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus protocol, aims to provide high throughput and low transaction costs. However, as demand increases, further optimizations and scaling solutions may be required to ensure efficient and cost-effective operations for RRC-404 and related applications. Interoperability and Cross-Chain Integration While RRC-404 is designed specifically for the Radix ecosystem, there may be a need for interoperability and cross-chain integration with other blockchain networks. This could involve bridging technologies or cross-chain asset transfer protocols, enabling RRC-404 tokens and NFTs to be exchanged or utilized across multiple blockchain ecosystems. Regulatory Compliance and Governance As the adoption of tokenized assets and fractional ownership models grows, regulatory bodies may introduce new guidelines or frameworks to govern these emerging asset classes. RRC-404 and its applications may need to adapt to evolving regulatory requirements, particularly in areas such as investor protection, anti-money laundering (AML), and know-your-customer (KYC) compliance. Additionally, robust governance models may be required to manage the development, maintenance, and decision-making processes surrounding the RRC-404 standard and its implementations. User Experience and Accessibility While RRC-404 aims to simplify the concept of NFT liquidity, there may be opportunities to further improve the user experience and accessibility of the platform. This could involve developing intuitive interfaces, educational resources, and user-friendly tools to help individuals and organizations effectively navigate and participate in RRC-404-based ecosystems. Integration with Decentralized Finance (DeFi) Protocols As mentioned in the potential applications section, RRC-404 could enable various integrations with decentralized finance (DeFi) protocols and applications. However, this integration may require the development of new financial instruments, smart contract frameworks, and risk management strategies tailored specifically for tokenized and fractionalized assets. Exploration of Alternative Approaches While RRC-404 presents a novel approach to enabling NFT liquidity, it is essential to continue exploring and evaluating alternative methods or architectures. As the blockchain and cryptocurrency space continues to evolve, new techniques or paradigms may emerge that could further improve upon the concepts introduced by RRC-404. Despite these potential challenges and areas for future development, the RRC-404 implementation on the Radix blockchain represents an exciting step towards unlocking liquidity for non-fungible tokens and bridging the gap between fungible and non-fungible assets. Continued innovation, collaboration, and adaptation will be crucial in realizing the full potential of this emerging technology. External Links - ice_rrc404v1 – reference implementation on GitHub (https://github.com/aus87/ice_rrc404v1) - Original RRC-404 announcement thread (https://x.com/aus877/status/1761873683662946654) - What is ERC-404? – Decrypt (https://decrypt.co/resources/what-is-erc-404-the-experimental-semi-fungible-ethereum-token-standard) - NFTs on Radix (/contents/tech/core-protocols/nfts-on-radix) – how non-fungible resources work natively ## Radix Pools (One/Two/Multi-Resource) URL: https://radix.wiki/contents/tech/core-concepts/radix-pools Updated: 2026-09-03 Summary: Radix's native pool blueprints – OneResourcePool , TwoResourcePool , and MultiResourcePool – provide canonical liquidity-pool primitives implemented i… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Type Native Blueprint Defined in radix-engine (pool package) Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction Radix's native pool blueprints (/contents/tech/core-concepts/blueprints-and-packages) – OneResourcePool, TwoResourcePool, and MultiResourcePool – provide canonical liquidity-pool primitives implemented in native Rust rather than Scrypto (/contents/tech/core-protocols/scrypto-programming-language) . Contributors deposit underlying buckets (/contents/tech/core-concepts/buckets-proofs-and-vaults) and receive pool units (themselves a resource (/contents/tech/core-concepts/asset-oriented-programming) ) representing their share. These blueprints power staking pools, AMMs, and yield-bearing positions across the ecosystem. What the package provides The three blueprints live in one native package at a fixed address, POOL_PACKAGE, and are declared in v1/constants.rs (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/pool/v1/constants.rs) as OneResourcePool, TwoResourcePool and MultiResourcePool. They differ only in how many reserves they hold. Every one of them refuses to be created over a non-fungible resource (/contents/tech/core-concepts/resources) — instantiation checks the resource type and fails with NonFungibleResourcesAreNotAccepted — so a pool is always an arrangement between fungible balances. Instantiating a pool creates three things at once: a vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) per reserve resource, a component (/contents/tech/core-concepts/components) to hold them, and a brand-new fungible resource (/contents/tech/core-concepts/asset-oriented-programming) for the pool units. The pool-unit resource is fixed at divisibility 18 and its mint and burn rules require the pool component's own global caller badge (/contents/tech/core-concepts/badges) , with both updater roles set to deny_all. Those roles cannot be changed afterwards by anyone, the owner included, which is the guarantee that matters to a holder: pool units can come into existence only by contributing to the pool, and can leave only by redeeming against it. The two objects are also wired to each other in locked metadata (/contents/tech/core-concepts/metadata-module) at instantiation. The component records pool_vault_number, pool_resources and pool_unit; the pool-unit resource records pool, pointing back. A wallet or explorer holding one side can therefore resolve the other without a registry, and neither entry can later be rewritten. Contributing and redeeming The public surface is small. contribute takes buckets and returns pool units; redeem takes pool units, burns them and returns the underlying; get_redemption_value and get_vault_amount (get_vault_amounts on the multi-resource variants) are read-only. Two further methods, protected_deposit and protected_withdraw, move reserves without minting or burning anything, and are gated by the pool_manager_role the instantiator sets — the hook that lets a staking or lending protocol add yield to a pool, or remove principal from it, while every holder's share stays denominated in the same units. On the multi-reserve blueprints a contribution has to arrive at the pool's current ratio. Whatever is offered in excess of that ratio is not accepted and is returned to the caller as change (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/pool/v1/v1_1/two_resource_pool_blueprint.rs) in the same transaction, so a contributor is never silently diluted by a badly proportioned deposit. The first contribution to an empty pool is the exception, because there is no ratio yet to meet. The redemption arithmetic rounds one way only. calculate_amount_owed takes the redeemer's share of reserves and rounds it to the resource's divisibility with RoundingMode::ToNegativeInfinity — down, always, to the remaining holders' benefit. The source enumerates the four states a pool can be in as a pair of pool-unit supply and reserves, and marks one of them illegal: units outstanding against zero reserves would mean people owning a percentage of nothing. The Anemone precision fix The package ships in two logic versions. v1/package.rs (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/pool/v1/package.rs) declares a PoolV1MinorVersion of Zero or One and dispatches every export to the matching implementation, so both remain in the engine and which one runs is decided by the protocol version, not by the pool. The switch came with Anemone (/contents/tech/releases/protocol-updates) , enacted at epoch 70575 on 7 February 2024, whose release notes describe it in a clause: the native pool blueprints were tweaked "to improve precision and their behaviour with resources whose divisibility is not 18". The engine's own migration function is named after the substance — generate_pool_math_precision_fix_state_updates (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/updates/anemone.rs) — and notes that no schema changed, only logic: the package's code substate is repointed from PoolCode1 to PoolCode2 and the blueprint definitions' function exports follow it. Existing pools kept their addresses, their reserves and their pool units, and began executing different arithmetic at an epoch boundary. Two things changed inside it. Redemption now computes the share in PreciseDecimal and converts back to Decimal only at the end, instead of dividing and multiplying in Decimal throughout — which is what "improve precision" means concretely, and why a pool over a resource with low divisibility no longer loses a little on every redemption. And contribute gained a check that the bucket's resource actually belongs to the pool, failing with ResourceDoesNotBelongToPool rather than relying on the vault to reject the deposit further down. External Links - pool native package (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/pool) - Radix Docs: Pools (https://docs.radixdlt.com/docs/pool) - Blueprint idents and the pool manager role (constants.rs) (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/pool/v1/constants.rs) - The Anemone pool math precision fix (anemone.rs) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/updates/anemone.rs) ## Liquid Stake Units (LSUs) URL: https://radix.wiki/contents/tech/core-concepts/liquid-stake-units Updated: 2026-09-03 Summary: Liquid Stake Units (LSUs) are native Radix tokens representing staked XRD with a specific validator . Unlike liquid staking on other chains (Lido's st… Type Liquid Staking Derivative Mechanism Native resource (/contents/tech/core-concepts/resources) , value accrues automatically DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) Composability Usable as collateral, in LP positions, etc. Overview Liquid Stake Units (LSUs) are native Radix tokens representing staked XRD (/contents/tech/core-protocols/xrd-token) with a specific validator (/contents/tech/core-concepts/validator-nodes) . Unlike liquid staking on other chains (Lido's stETH, etc.), Radix LSUs are built into the protocol – they're native resources (/contents/tech/core-concepts/asset-oriented-programming) , not smart contract wrappers. LSU value accrues automatically as staking rewards compound – the exchange rate between LSU and XRD continuously increases. Users can use LSUs in DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) while still earning staking rewards: as collateral on Weft Finance (/ecosystem/weft-finance) , in liquidity pools on Ociswap (/ecosystem/ociswap) , or managed via ShardSpace (/ecosystem/shardspace) . How LSUs Work Each validator (/contents/tech/core-concepts/validator-nodes) mints its own distinct LSU resource (/contents/tech/core-concepts/resources) . When you stake XRD (/contents/tech/core-protocols/xrd-token) to a validator you receive that validator's LSUs, representing a proportional claim on its underlying pool of staked XRD ( Radix Knowledge Base (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) ). Because each LSU is validator-specific, its market value also reflects that validator's reliability and fee – LSUs from different validators are not interchangeable. Value accrues through the exchange rate rather than by rebasing balances: emission rewards (/contents/tech/core-concepts/network-emissions) flow into the validator's staked pool each epoch, so a fixed quantity of LSUs redeems for progressively more XRD over time. Unstaking and Claim NFTs To unstake, you return LSUs to the validator component (/contents/tech/core-concepts/components) . It calculates the XRD they represent, moves that XRD into a separate "unstaked" pool, burns the LSUs, and mints a non-fungible claim NFT (https://learn.radixdlt.com/article/how-to-stake-and-unstake-xrd) recording the amount and the epoch it becomes available. The XRD is not immediately withdrawable: a protocol-enforced unstaking delay of 2,016 epochs (≈ 7 days) must pass before the claim NFT (/contents/tech/core-protocols/nfts-on-radix) can be redeemed for XRD ( Knowledge Base (https://learn.radixdlt.com/article/how-long-does-it-take-to-convert-lsus-to-xrd-and-unstake) ). Locked owner stake carries a longer 8,064-epoch (≈ 28-day) delay. Composability Because LSUs are native resources (/contents/tech/core-concepts/asset-oriented-programming) rather than smart-contract wrappers, they move through the ledger with the same guarantees as XRD itself and can be used across DeFi while still earning staking rewards – as collateral on Weft Finance (/ecosystem/weft-finance) , in liquidity pools on Ociswap (/ecosystem/ociswap) , or managed via ShardSpace (/ecosystem/shardspace) . This native design avoids the wrapper-contract risk that affects liquid-staking derivatives on account-based chains. ## Validator Nodes URL: https://radix.wiki/contents/tech/core-concepts/validator-nodes Updated: 2026-09-03 Summary: Validator nodes secure the Radix network by participating in Cerberus consensus . They process transactions, propose state changes, and earn staking r… Role Transaction processing, consensus participation Consensus Cerberus BFT (/contents/tech/core-protocols/cerberus-consensus-protocol) Rewards Share of 300M XRD (/contents/tech/core-protocols/xrd-token) annual emissions (/contents/tech/core-concepts/network-emissions) Minimum Stake 100 XRD to delegate Registered validators 188 of 287 (mainnet, epoch 332767) Active set Top 100 by stake Fee range 0–100%, increases delayed ~4,032 epochs Unstaking delay 2,016 epochs (~1 week) Overview Validator nodes secure the Radix network (https://www.radixdlt.com) by participating in Cerberus consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) . They process transactions, propose state changes, and earn staking rewards (/contents/tech/core-concepts/network-emissions) distributed to their delegators. Staking XRD (/contents/tech/core-protocols/xrd-token) holders can delegate to any validator with a minimum of 100 XRD. Delegation creates Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) that represent the staked position and continue accruing value. The Radix Dashboard (https://dashboard.radixdlt.com) and ShardSpace (/ecosystem/shardspace) provide interfaces for staking. Subsidy Transition The Validator Subsidy, which topped up validator income independently of delegator fees, was wound down through 2026 — see Validator Subsidy Sunset (/contents/history/validator-subsidy-sunset) . What remains is the fee a validator sets for itself. Registration and the active set A validator is a component (/contents/tech/core-concepts/components) on the ledger, not a slot granted by anyone. Creating one costs a fee denominated in USD rather than XRD (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) — 1,000 USD-equivalent in the mainnet genesis configuration — and creates a component together with an owner badge (/contents/tech/core-concepts/badges) , an LSU (/contents/tech/core-concepts/liquid-stake-units) resource (/contents/tech/core-concepts/resources) and a claim-NFT resource that are unique to it. Existing is not the same as participating: a validator only enters consensus once its owner registers it, and only the top 100 registered validators by stake — max_validators in the same configuration — form the active set that proposes and validates rounds. Read live from the Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 332767 on 7 August 2026, mainnet carries 287 validator components, of which 188 are registered. The tail is long and mostly nominal — dozens of registered validators hold single-digit XRD and will never enter the active set — so the register is better read as a list of who has stood a node up than as a picture of who is securing the network. Unstaking is deliberately slow: num_unstake_epochs is 2,016, roughly a week at the ledger's recent pace of about 288 epochs a day, during which the position is a claim NFT (/contents/tech/core-protocols/nfts-on-radix) rather than XRD. A validator's own fee income is slower still — see below. The fee a validator charges is not always the fee it stores Every validator has a fee factor: the share of that validator's emissions (/contents/tech/core-concepts/network-emissions) it keeps before the rest accrues to delegators. The engine bounds it to between 0 and 1 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs) — 0% to 100% — and it is the single number that decides what delegating to one validator rather than another is worth. Changing it is asymmetric, and deliberately so. A validator that raises its fee must wait num_fee_increase_delay_epochs — 4,032 epochs in the mainnet genesis configuration, about two weeks — before the new fee applies, which is the window delegators have to leave. A validator that lowers its fee has it apply at the beginning of the very next epoch. Nobody is protected from a fee cut. The subtlety is what happens when the delay expires. The engine does not rewrite the stored validator_fee_factor at that moment. It leaves the request sitting in validator_fee_change_request and, every time it pays emissions, resolves the fee it actually charges as "the request, if its epoch has passed; otherwise the stored field". The stored field is only brought up to date later, as a side effect of the owner requesting the next change. A validator can therefore charge one fee for months while the field an explorer reads still shows the old one — the two are reconciled lazily, and nothing on the ledger is wrong about it. That is not a corner case. Of the 188 registered validators read at epoch 332767, 62 are charging something other than their stored fee factor, and 50 of those are charging more. Between them they hold 2,900,410,156 of the 4,727,137,240 XRD staked to registered validators — 61% of all delegated stake sits with a validator whose stored fee is stale. The gaps are not rounding: one validator stores 1.49% and charges 14.9%, another stores 0% and charges 100%, a third stores 25% and charges 1%. The practical rule for anyone reading a validator's fee — in a dashboard, in a directory, or through the Gateway (https://docs.radixdlt.com/docs/network-gateway) — is to read both validator_fee_factor and validator_fee_change_request and compare the request's epoch_effective against the current epoch. A tool that reads only the first is wrong about a third of the register. This wiki was one of those tools until this pass: RadixStake (/ecosystem/radixstake) 's page carried the stored 1.49% while its delegators paid 14.9%. The Gateway (https://docs.radixdlt.com/docs/network-gateway) will do that reconciliation for you, but only on one of the two endpoints that return a validator. /state/validators/list gives every item an effective_fee_factor object whose current is the fee actually being charged and whose pending appears only while a request is genuinely queued; the Gateway API schema (https://github.com/radixdlt/babylon-gateway/blob/main/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml) declares it required on ValidatorCollectionItem, with current required and pending nullable, and declares it nowhere else. /state/entity/details, the endpoint you reach for when you have one validator's address, returns no resolved fee at all: its state object carries the raw validator_fee_factor and validator_fee_change_request and stops there. The natural single-validator lookup is the one that cannot answer the question, and the field it hands you instead is a fossil, because validator_fee_change_request is never cleared once its epoch has passed. A non-null request does not mean a change is coming. Read at epoch 338190 on 25 August 2026, CaviarNine (/ecosystem/caviarnine) -1 stored 1.75% and charged nothing, its request field still holding the cut to zero that took effect at epoch 282893; Cadwynbloc stored 50% and charged 75%; Radstakes stored 15% and charged 25%. None of the three had a change pending. The only field that says one is coming is effective_fee_factor.pending. Where the fee goes A validator's fee is not paid out to it in XRD. When emissions are applied, the fee is taken from the emission bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) and then staked straight back to the same validator (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs) ; the stake units minted against it are placed in the validator's locked owner stake-unit vault, where they are visible on-ledger and cannot be moved for num_owner_stake_units_unlock_epochs — 8,064 epochs in the genesis configuration, roughly a month. So a validator's income arrives as its own delegated stake, under a lock longer than the one its delegators face. Fee income compounds into the same pool it was taken from, and the operator's visible stake grows with it — one reason a high-fee validator's rank can drift upward without any new delegator arriving. External Links - Validator blueprint: update_fee and apply_emission (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/consensus_manager/validator.rs) - ConsensusManagerConfig::mainnet_genesis — the network's staking constants (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) - Radix Gateway API — /state/validators/list (https://docs.radixdlt.com/docs/network-gateway) - Radix Dashboard: the validator register (https://dashboard.radixdlt.com/network-staking) ## Transaction Manifests URL: https://radix.wiki/contents/tech/core-protocols/transaction-manifests Updated: 2026-09-03 Summary: Transaction manifests are Radix's instruction format for describing what a transaction should do. Where an EVM transaction encodes a function call as… Transaction Manifest Type Transaction instruction format Readability Human and machine readable; compiled to SBOR (/contents/tech/core-concepts/substate-model) for the wire, decompiled back for display Execution Atomic — the whole instruction list commits or none of it does Current version V2, introduced by the Cuttlefish (/contents/tech/releases/protocol-updates) protocol update (18 December 2024) Instruction set 38 instructions in InstructionV2 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/src/model/v2/instruction_v2.rs) , against 30 in InstructionV1 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/src/model/v1/instruction_v1.rs) — a strict superset Instruction groups Bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) lifecycle · resource (/contents/tech/core-concepts/resources) assertions · proof lifecycle · invocation · address allocation · inter-intent Source file extension .rtm (Radix Transaction Manifest) Defined in radix-transactions (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-transactions) , part of radixdlt/radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Related Blind Signing (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) · Worktop (/contents/tech/core-concepts/worktop) · Subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) Overview Transaction manifests are Radix's instruction format for describing what a transaction should do. Where an EVM transaction encodes a function call as opaque hex calldata — the condition the wiki covers under blind signing (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) — a manifest is an ordered list of named instructions over named values, and the same list a wallet displays is the list the Radix Engine (/contents/tech/core-protocols/radix-engine) executes. A manifest reads like a recipe: withdraw XRD (/contents/tech/core-protocols/xrd-token) from an account, take some of it into a bucket, hand the bucket to a component (/contents/tech/core-concepts/components) , assert what came back, deposit the rest. It is not a script in the ordinary sense — there are no loops, no branches and no arithmetic. It is a straight-line list of effects, which is exactly what makes it possible to render, to analyse statically, and to check against what a user thought they were signing. Composability Manifests can chain any number of operations into a single atomic transaction (/contents/tech/core-concepts/atomic-composability) . One manifest might withdraw collateral from a lending protocol, swap it on a DEX, provide liquidity, and deposit the LP tokens — all in one commit. If any instruction fails, the whole transaction reverts and nothing moved. The Instruction Set A manifest is a value of InstructionV2 (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/src/model/v2/instruction_v2.rs) , an enum defined in the radix-transactions (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-transactions) crate of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) . There are 38 of them, and the enum groups them into six sections with the comments left in the source: Group Count What it does Bucket lifecycle 5 TAKE_FROM_WORKTOP, TAKE_NON_FUNGIBLES_FROM_WORKTOP, TAKE_ALL_FROM_WORKTOP, RETURN_TO_WORKTOP, BURN_RESOURCE — moving resources (/contents/tech/core-concepts/resources) between the worktop and named buckets Resource assertions 8 ASSERT_WORKTOP_CONTAINS and relatives, plus the V2 additions ASSERT_WORKTOP_RESOURCES_ONLY, ASSERT_NEXT_CALL_RETURNS_ONLY and ASSERT_BUCKET_CONTENTS — conditions the transaction aborts on Proof lifecycle 15 Creating proofs from buckets or the auth zone (/contents/tech/core-concepts/access-rules-and-auth-zones) , cloning, pushing, popping and dropping them Invocation 6 CALL_FUNCTION, CALL_METHOD, and four typed variants that reach the royalty, metadata, role-assignment and direct-vault surfaces Address allocation 1 ALLOCATE_GLOBAL_ADDRESS, which reserves an address a later instruction in the same manifest will occupy Interaction with other intents 3 YIELD_TO_PARENT, YIELD_TO_CHILD, VERIFY_PARENT — the subintent (/contents/tech/core-concepts/subintents-and-pre-authorizations) instructions The largest group is proof handling, which is a fair summary of what the format is for: most of the surface area is spent on saying precisely which authority a call is made under, rather than on saying what the call is. There is no instruction for arithmetic, comparison or control flow anywhere in the enum, and that absence is load-bearing — it is why a manifest's effects can be enumerated without running it. Worktop, Buckets and Proofs The instruction set only makes sense alongside the resource plumbing it manipulates. Resources on Radix are not ledger entries a contract may write to; they are objects that must physically be somewhere, which is the substance of asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) . Inside a transaction that "somewhere" is one of three places, all covered in depth under Buckets, Proofs & Vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) : - The worktop (/contents/tech/core-concepts/worktop) — the transaction's own holding area. Anything a component hands back lands here, and the transaction is not valid unless the worktop is empty when it ends. Resources cannot be lost by omission; they can only be deposited, burned or returned. - Buckets — named portions taken off the worktop and passed into a call. - Proofs — evidence of holding a badge (/contents/tech/core-concepts/badges) or resource, without transferring it. A manifest from the repository's own worktop example (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/examples/resources/worktop.rtm) shows the shape (the ${...} forms are placeholders the test harness substitutes): # Withdraw XRD from account CALL_METHOD Address("account") "withdraw" Address("xrd") Decimal("5.0"); # Buy GUM with XRD TAKE_FROM_WORKTOP Address("xrd") Decimal("2.0") Bucket("xrd"); CALL_METHOD Address("component") "buy_gumball" Bucket("xrd"); ASSERT_WORKTOP_CONTAINS Address("gumball") Decimal("3.0"); # Move all resources in worktop to account CALL_METHOD Address("account") "deposit_batch" Expression("ENTIRE_WORKTOP"); The ASSERT_WORKTOP_CONTAINS line is the part worth noticing. It is not a comment or a client-side check — it is an instruction, it executes, and if the component returned fewer than three gumballs the whole transaction aborts. Slippage limits, minimum-received guarantees and "this had better be the token I asked for" are expressed in the manifest rather than trusted to the component, which is why they hold even when the component is hostile. From Manifest to Notarized Transaction The manifest is the innermost layer of a transaction, not the whole of one. Around it sit a header (the epoch window the transaction is valid in, the network it targets, a nonce, the notary's public key), the signatures of every account whose authority the instructions need, and finally the notary's own signature. The models live beside the instruction set in radix-transactions/src/model/v2 (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-transactions/src/model/v2) — transaction_manifest_v2.rs, transaction_intent_v2.rs, signed_transaction_intent_v2.rs and notarized_transaction_v2.rs, in that order of containment. Manifests are written as .rtm files in a readable text form, then compiled to SBOR (/contents/tech/core-concepts/substate-model) for transmission. The relationship is a round trip rather than a one-way build step: the crate ships a decompiler alongside the compiler, so a transaction pulled off the ledger can be rendered back into the same instruction list it was written as. This is what lets a wallet, an explorer and a reviewer all read a transaction that was assembled by a dApp's SDK, and it is the mechanical basis for the claim that Radix transactions are not blind-signed. What the wallet shows a user is a further step on top: the transaction is previewed and the instruction list is classified — a transfer, a pool contribution, a stake — so the summary a user approves is derived from the instructions rather than supplied by the dApp requesting the signature. What V2 Added The Cuttlefish (/contents/tech/releases/protocol-updates) protocol update, enacted on mainnet on 18 December 2024, introduced the V2 transaction format. Comparing the two enums in the source, V2 is a strict superset: all 30 InstructionV1 variants survive unchanged and eight are added. Nothing was removed, which is why V1 transactions remain valid. The eight fall into two groups. Five are new assertions — ASSERT_WORKTOP_RESOURCES_ONLY, ASSERT_WORKTOP_RESOURCES_INCLUDE, ASSERT_NEXT_CALL_RETURNS_ONLY, ASSERT_NEXT_CALL_RETURNS_INCLUDE and ASSERT_BUCKET_CONTENTS. The NEXT_CALL_RETURNS pair is the notable one: it constrains what the following instruction is permitted to hand back, so a manifest can bound the outcome of a call it does not control before making it, rather than inspecting the damage afterwards. The other three — YIELD_TO_PARENT, YIELD_TO_CHILD and VERIFY_PARENT — are the machinery of subintents and pre-authorizations (/contents/tech/core-concepts/subintents-and-pre-authorizations) . A subintent is a manifest fragment signed by one party and composed into a larger transaction by another, with control passing back and forth through the yield instructions; VERIFY_PARENT lets a child assert something about the transaction it has been embedded in. Radix Docs covers the intent structure (https://docs.radixdlt.com/docs/subintents) these instructions form, and the wiki's subintents page covers the pre-authorization flows built on it. AI Agent Compatibility Manifests matter disproportionately for AI agents (/contents/tech/core-concepts/radix-for-ai-agents) , for the same reason they matter for wallets. An agent can construct a manifest, parse one it did not construct, and enumerate the effects of either without executing anything or trusting the party that supplied it — the instruction list is the transaction, and it is finite, named and branch-free. The property that carries this is the absence of control flow. A format with loops or conditionals would make "what will this transaction do" a question answerable only by running it against live state; without them, the set of components called and the assertions that must hold can be read straight off the list. This is the same property the Hyperscale programme's purpose-built VM is designed to strengthen further, by making a transaction's full data footprint statically derivable from the manifest and the referenced blueprints (/contents/tech/core-concepts/blueprints-and-packages) ' metadata — see hyperscale-rs (/contents/tech/research/hyperscale-rs) . External Links - Radix Docs — Transaction Manifest (https://docs.radixdlt.com/docs/manifest) - Radix Docs — Manifest Instructions (https://docs.radixdlt.com/docs/manifest-instructions) - Radix Docs — Subintents (https://docs.radixdlt.com/docs/subintents) - InstructionV2 — the canonical 38-instruction set (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/src/model/v2/instruction_v2.rs) - InstructionV1 — the 30-instruction set it supersedes (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-transactions/src/model/v1/instruction_v1.rs) - Example .rtm manifests in radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-transactions/examples) - Transaction Manifest Language Guide (/developers/transactions/01-manifest-language) - Transaction Lifecycle (/developers/transactions/02-transaction-lifecycle) ## Consensus Manager URL: https://radix.wiki/contents/tech/core-concepts/consensus-manager Updated: 2026-09-03 Summary: The Consensus Manager is a native blueprint that exposes the network’s consensus state – current epoch, round, validator set, and emissions schedule –… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Type Native Blueprint Defined in radix-engine (consensus_manager package) Address consensusmanager_rdx1scxxxxxxxxxxcnsmgrxxxxxxxxx000999665565xxxxxxxxxcnsmgr Active set 100 validators, selected each epoch by stake Target epoch 5 minutes (300,000 ms) Round bounds 100 minimum, 3,000 maximum Emission 2,853.881278538812785388 XRD (/contents/tech/core-protocols/xrd-token) per epoch Reliability floor 1.0 – one missed round zeroes the epoch’s emission Ledger reading Epoch 334,399 · 12 August 2026 Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The Consensus Manager is a native blueprint (/contents/tech/core-concepts/blueprints-and-packages) that exposes the network’s consensus state – current epoch, round, validator set, and emissions schedule – to applications as ordinary engine objects. It is the on-ledger surface of the Cerberus consensus protocol (/contents/tech/core-protocols/cerberus-consensus-protocol) : validators register and unregister through it, epochs advance through it, and staking-related blueprints ( Validator (/contents/tech/core-concepts/validator-nodes) , LSUs (/contents/tech/core-concepts/liquid-stake-units) ) interact with it natively. There is exactly one instance of it on each network, at a fixed address baked into the protocol. On mainnet that is consensusmanager_rdx1scxxxxxxxxxxcnsmgrxxxxxxxxx000999665565xxxxxxxxxcnsmgr, returned as the consensus_manager well-known address by the Gateway’s network configuration endpoint (https://radix-babylon-gateway-api.redoc.ly/#operation/GatewayStatus) . It is a system component (/contents/tech/core-concepts/components) : only the protocol itself may call the methods that advance a round or start the network, and everything else it exposes is read-only. What the blueprint stores The Consensus Manager keeps consensus bookkeeping in a handful of separate fields rather than one blob, so that a round update touches as little state as possible. The fields are declared in consensus_manager.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine/src/blueprints/consensus_manager/consensus_manager.rs) : - Configuration – the ConsensusManagerConfig described below. Written at genesis and thereafter only by a protocol update (/contents/tech/releases/protocol-updates) . - State – whether consensus has started, the current epoch and round, the current leader, and two epoch start timestamps. The effective start is the one epoch length is measured against; the actual start is recorded alongside it as a check on how far the two have diverged. - Current validator set – the active validators for this epoch, each with its public key and stake, ordered by stake descending. - Current proposal statistic – per validator, a count of proposals made and proposals missed, in the same order as the validator set. Missed covers both gap rounds and fallback rounds. - Validator rewards – a vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) holding the proposer share of network fees, plus the per-validator claim on it. - Proposer timestamps – the consensus clock, held twice: to the millisecond for internal use, and rounded to whole minutes as the value transactions (/contents/tech/core-protocols/transaction-manifests) read when they ask the network for the time. Two sorted indexes sit beside the fields: every registered validator keyed by stake, and every validator that has signalled readiness for a protocol update. The first is what the epoch boundary reads to pick the next active set. The configuration Nine values govern the whole of it. They are fixed in ConsensusManagerConfig at genesis and can only be changed by a protocol update, never by a transaction. The mainnet genesis values come from the node’s production defaults (https://github.com/radixdlt/babylon-node/blob/main/core-rust-bridge/src/main/java/com/radixdlt/genesis/GenesisConsensusManagerConfig.java) and are mirrored in ConsensusManagerConfig::mainnet_genesis() (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) : Field Mainnet value What it does max_validators 100 Size of the active set min_round_count 100 (500 at genesis) Rounds that must pass before the clock can end an epoch max_round_count 3,000 Rounds after which the epoch ends regardless of the clock target_duration_millis 300,000 Intended epoch length, five minutes num_unstake_epochs 2,016 Unstaking delay, about one week total_emission_xrd_per_epoch 2,853.881278538812785388 XRD (/contents/tech/core-protocols/xrd-token) minted per epoch for emissions (/contents/tech/core-concepts/network-emissions) min_validator_reliability 1 Proposal success ratio required to earn any emission num_owner_stake_units_unlock_epochs 8,064 Owner stake lock, about four weeks num_fee_increase_delay_epochs 4,032 Notice a validator must give before raising its fee, about two weeks validator_creation_usd_cost 1,000 USD Fee to create a validator component Three of these are worth reading twice. The emission figure is not a round number because it is a division: 300,000,000 XRD a year over the 105,120 five-minute epochs in a 365-day year. The unstaking, owner-lock and fee-notice delays are all counted in epochs rather than days, so they stretch or shrink with the network’s actual epoch length. The validator creation fee is quoted in dollars but charged in XRD, converted at USD_PRICE_IN_XRD, a hard-coded engine constant (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-common/src/constants/transaction_execution.rs) of 16.666666666666666666 – one XRD at six cents, the price assumed when the engine was designed. Creating a validator therefore costs 16,666.67 XRD whatever XRD is trading at. When an epoch ends Every round update asks one question: has this epoch run long enough? The answer is a three-branch rule in EpochChangeCondition::is_change_criterion_met, evaluated in order: - Round number has reached max_round_count – end the epoch now, whatever the clock says. - Round number is below min_round_count – do not end the epoch, whatever the clock says. - Otherwise – end the epoch once the elapsed time reaches target_duration_millis. The two round bounds exist to cap the damage from a validator lying about the time. Rounds are the only quantity the protocol can count for itself; the clock is reported by proposers, so an epoch is never allowed to be arbitrarily short or arbitrarily long on the strength of a timestamp alone. The floor was set at 500 rounds at genesis, on an estimate carried over from Olympia (/contents/tech/releases/radix-mainnet-olympia) that an epoch would run about 1,800 rounds. Cuttlefish lowered that floor (/contents/tech/releases/protocol-updates) to 100 in December 2024, and did it conditionally: the update writes 100 only where the stored value is still 500, so a network that had already changed it is left alone. Since a healthy epoch ends on the clock at several hundred rounds, the floor is invisible in normal operation and binds only when round production stalls – which is exactly the case where a 500-round floor would have held an epoch open far past five minutes. Read live on 12 August 2026, mainnet epoch 334,398 opened at 19:04:01 UTC and was at round 669 five minutes later, running about 2.4 rounds a second. At that rate the five-minute target arrives around round 700: comfortably above the 100-round floor, comfortably below the 3,000-round ceiling, so mainnet epochs end on the clock. What the epoch boundary does When the condition is met, epoch_change runs four steps in one transaction, before the first round of the new epoch. Emissions are applied to the outgoing set. Each validator’s stake is multiplied by its reliability factor for the epoch just ended, and the epoch’s XRD is divided across those effective stakes. This is settled against the set that did the work, not the set about to start. The next active set is selected. The engine scans the registered-validators-by-stake index and takes the top max_validators. It deliberately reads more than it needs – max_validators + max_validators/10 + 10, so 120 entries for a 100-seat set – because that index buckets stake into 16-bit keys and several validators can share a bucket at the cut-off. The over-read is then re-sorted exactly. The code notes the residual risk plainly: a very large bucket could still hide a validator who belonged in the set, and the ones affected would be at the bottom of the list where few proposals land. Protocol update readiness is tallied. Each incoming validator is asked which protocol version it has signalled for, and the stake behind each answer is summed. Signals carrying less than 10% of the new set’s total stake are dropped before the tally is published, so a lone validator cannot put a version name on the ledger. The books are reset. Proposal statistics are zeroed for the incoming set, the new validator set is written, and an EpochChangeEvent is emitted carrying the epoch number, the full set, and the surviving readiness tallies. That event is what indexers and the Gateway (/contents/tech/core-protocols/radix-gateway-api) read to track the validator set over time. At epoch 334,399 the mainnet ledger carried 287 validator components of which 100 were active, holding 4,737,835,621 XRD of stake between them. The distribution across those seats is steep: the largest active validator held 246,042,541 XRD and the hundredth, Encrypta.xyz, held 19,005 XRD. The hundredth seat is cheap because the cap is a fixed count, not a stake threshold. Reliability is all or nothing on mainnet Emissions are weighted by performance through a reliability factor, computed in ValidatorInfo::to_reliability_factor. A validator’s absolute reliability is its proposal success ratio for the epoch: proposals made over proposals made plus missed. That ratio is then rescaled against the configured minimum, so the factor is (reliability − minimum) / (1 − minimum), clamped to zero below the minimum. On a network configured with a minimum of 0.6, a validator that made 7 of 10 rounds scores 0.7, rescales to 0.25, and receives a quarter of its share. Mainnet is not configured that way. Its minimum is 1, which collapses the formula to a single step: the factor is 1 for a validator that missed nothing in the epoch and 0 for a validator that missed one round. There is no partial credit, and no separate 98% threshold – missing a single proposal costs the validator and all of its delegators the whole epoch’s emission. The node’s genesis builder states the reasoning in a comment: epochs are much shorter than they were on Olympia, so full reliability is demanded across each short window. Radix Docs (https://docs.radixdlt.com/docs/consensus-manager) confirms the mainnet setting and the binary outcome it produces. The XRD a validator forfeits this way is not paid to anyone else, and it is not burned. The engine sums the effective stakes first and mints only the emission those stakes earn, so the forfeited share is never created. This is measurable at the supply level: the twelve months to 9 August 2026 minted 297.2 million XRD against a scheduled 300 million, and that 0.9% gap is reliability forfeit that never entered supply. See Network Emissions (/contents/tech/core-concepts/network-emissions) for the full reading. External Links - consensus_manager native package (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/tree/develop/radix-engine/src/blueprints/consensus_manager) - ConsensusManagerConfig and EpochChangeCondition (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine-interface/src/blueprints/consensus_manager/invocations.rs) - Cuttlefish protocol update, including the minimum-rounds change (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine/src/updates/cuttlefish.rs) - GenesisConsensusManagerConfig (babylon-node) (https://github.com/radixdlt/babylon-node/blob/main/core-rust-bridge/src/main/java/com/radixdlt/genesis/GenesisConsensusManagerConfig.java) - Radix Docs: Consensus Manager (https://docs.radixdlt.com/docs/consensus-manager) ## RCnet URL: https://radix.wiki/contents/tech/releases/rcnet Updated: 2026-09-03 Summary: RCnet was a test network developed by Radix to provide developers with the tools and standards necessary for creating more robust applications on Radi… RCnet was a test network developed by Radix to provide developers with the tools and standards necessary for creating more robust applications on Radix. It has since been superceded by Stokenet (/contents/tech/releases/stokenet) . Features Transaction Review The latest iOS Wallet preview build includes an initial version of the transaction review functionality, enabling users to monitor their account transactions, view the badges (https://docs.radixdlt.com/docs/auth) they are presenting, and interact with various applications. Although the feature remains under development, it establishes a foundation for future enhancements, such as: - Customizable guarantees on deposits. - Prominent warnings for potentially high-risk transactions. - Special views for specific transaction types. - An "advanced view" for users desiring a detailed examination of transaction manifests (/contents/tech/core-protocols/transaction-manifests) . - Improved handling of resources (/contents/tech/core-concepts/resources) created within transactions. - Metadata-defined icons for applications, components (/contents/tech/core-concepts/components) , and resources. - Links to additional screens detailing user interactions with dApps and resources. - Accurate fee estimates and a breakdown of fees between network costs and royalties. - Multiple visual adjustments and refinements. Core API (https://docs.radixdlt.com/docs/network-apis) for Integrators The node-provided Core API (https://docs.radixdlt.com/docs/core-api-providers) streamlines the Babylon (https://www.radixdlt.com/blog/babylon-mainnet-upgrade-complete) integration process for exchanges and other third parties, allowing key integrators to work with the Radix Engine (/contents/tech/core-protocols/radix-engine) and node without the need to operate their own Gateway instance. Personas (/contents/tech/core-protocols/personas) and Off-Ledger Data Sharing with dApps The updated Wallet preview now incorporates Personas (/contents/tech/core-protocols/personas) , enabling developers to request personal data directly from the Radix Wallet (/contents/tech/core-protocols/radix-wallet) . The current preview Wallet supports a limited set of personal data fields, with plans to expand the range of fields as development continues. Radix dApp Toolkit (https://github.com/radixdlt/radix-dapp-toolkit) The Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) extends the capabilities of the Radix Connect (/contents/tech/core-protocols/radix-connect) Button, offering automatic session management, tracking and notifications for requests and transactions, data caching, and more. Metadata Updates and New Standards RCnet introduces an initial set of metadata standards designed to assist developers in ensuring proper integration of their dApps, tokens, NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) , and other components with the Radix Wallet (/contents/tech/core-protocols/radix-wallet) and other clients. Radix Engine Toolkit (https://github.com/radixdlt/radix-engine-toolkit) Expansion In response to developer feedback and the needs of early integrators, the Radix Engine Toolkit (https://github.com/radixdlt/radix-engine-toolkit) will be updated with new features, such as a TypeScript target, a command-line version for Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developers, and additional functions for building and signing basic transactions. Limitations and Ongoing Development While RCnet achieved the majority of its objectives, certain areas, including the Gateway API (https://docs.radixdlt.com/docs/network-gateway) , Radix Off-Ledger Authentication ( ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) ), and fee table adjustments, remain under development. These features will be available before the Babylon (https://learn.radixdlt.com/article/what-is-radixs-babylon-mainnet) release, although no specific release date has been provided. DEVELOPMENT Launch Date 2021-07-28 (https://www.radixdlt.com/blog/radix-olympia-mainnet-is-here) Antecedent eMunie (/contents/tech/research/emunie) Postcedent Stokenet (/contents/tech/releases/stokenet) Code Repository https://github.com/radixdlt/babylon-node/blob/4e6ef24f3dff750ea3515416e27bcaa8f454cbdc/olympia-engine/ (https://github.com/radixdlt/babylon-node/blob/4e6ef24f3dff750ea3515416e27bcaa8f454cbdc/olympia-engine/) License Radix License, v1 (https://github.com/radixdlt/babylon-node/blob/main/LICENSE) LEDGER State Model Sharded (/contents/tech/core-concepts/sharding) Shard Groups 1 (/contents/tech/core-concepts/shard-groups) Sybil Protection Delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) Consensus Protocol Hotstuff (https://hackernoon.com/hotstuff-the-consensus-protocol-behind-safestake-and-facebooks-librabft) Execution Environment Radix Engine (/contents/tech/core-protocols/radix-engine) v1 Validator Node (/contents/tech/core-concepts/validator-nodes) Cap 100 ## Locker URL: https://radix.wiki/contents/tech/core-concepts/locker-blueprint Updated: 2026-09-03 Summary: The Locker is a native blueprint for permissioned resource distribution: a sender deposits resources into the locker addressed to specific recipients,… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Blueprint name AccountLocker Package LOCKER_PACKAGE Introduced Bottlenose protocol update (2024) Roles storer, storer_updater, recoverer, recoverer_updater Defined in radix-engine (locker package) Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The Locker is a native blueprint (/contents/tech/core-concepts/blueprints-and-packages) for permissioned resource distribution: a sender deposits resources (/contents/tech/core-concepts/buckets-proofs-and-vaults) into the locker addressed to specific recipients, who can then claim them on their own schedule. Lockers were introduced to support airdrops, vesting, and refund flows without forcing recipients to pre-authorize deposits – the engine's native-asset model means tokens cannot be pushed to an account that has not opted in. The problem it solves Radix Smart Accounts (/contents/tech/core-protocols/smart-accounts) can refuse deposits. An account owner may set their deposit rules to accept only a chosen list of resources, or only deposits from an authorized depositor, which means a sender cannot assume a transfer will land — an asset-oriented (/contents/tech/core-concepts/native-assets-vs-token-approvals) engine will not silently credit a balance the recipient never agreed to hold. A naive airdrop over a few thousand accounts therefore fails for every account whose rules reject it, and the sender is left holding the remainder with no record of who is still owed what. Before the Locker, applications worked around this by tracking outstanding balances themselves, in their own component (/contents/tech/core-concepts/components) state, and exposing a bespoke claim method. The Locker makes that pattern native: a sender deposits resources (/contents/tech/core-concepts/resources) addressed to specific claimants, the claimants collect on their own schedule, and neither side needs a badge (/contents/tech/core-concepts/badges) or a custom contract for it. Radix documentation (https://docs.radixdlt.com/docs/locker) gives bridges as the motivating case — attempt the direct deposit, fall back to a locker when it bounces. Blueprint interface The blueprint is named AccountLocker and is defined in the engine's locker invocation definitions (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/locker/invocations.rs) . It exposes two instantiation functions and eight methods, split by the role each requires: Kind Name Notes Function instantiate Takes an owner role plus the four access rules (storer_role, storer_updater_role, recoverer_role, recoverer_updater_role) and an optional address reservation Function instantiate_simple Takes a single allow_recover flag and returns the locker together with a badge bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) Storer store Deposits one bucket for one claimant Storer airdrop Distributes one bucket across a map of claimants; returns the remainder as Option Recoverer recover / recover_non_fungibles Pulls stored resources back out to the operator Public claim / claim_non_fungibles Called by anyone; the engine checks the caller is the claimant Getter get_amount / get_non_fungible_local_ids Read what a given claimant is owed; the non-fungible getter takes a limit Fungible and non-fungible paths are separate methods rather than one overloaded call, and the airdrop map carries a ResourceSpecifier per claimant — either a Fungible(Decimal) amount or a NonFungible set of local IDs (/contents/tech/core-protocols/nfts-on-radix) . Direct send, then fall back Both store and airdrop take a try_direct_send boolean. When it is set, the locker first calls try_deposit_or_refund (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/locker/blueprint.rs) on the claimant's account, presenting the locker's own global-caller badge as the authorized depositor. If the account accepts, the resources land directly and nothing is stored; if it refunds, the returned bucket is written into a per-claimant vault inside the locker instead. The vault is created on first use. That single flag is what makes the Locker a drop-in for an existing distribution: the happy path stays a direct transfer, and only the accounts that would have failed end up with something to claim. The choice is the sender's, not the recipient's — passing false stores unconditionally. Roles and events Access is split so that filling a locker and emptying it are different privileges. The storer role may call store and airdrop; the recoverer role may pull resources back out with recover; each has a matching updater role that can change who holds it, following the standard role assignment (/contents/tech/core-concepts/role-assignment-module) pattern and enforced by access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) . instantiate_simple collapses the choice to one question — whether recovery is allowed at all — and hands back the badge that authorizes it. The blueprint emits three events: StoreEvent when resources are locked for a claimant, RecoverEvent when the operator takes them back, and ClaimEvent when a claimant collects. Each carries the claimant, the resource address, and the amount or ID set, so an indexer reading the Gateway API (/contents/tech/core-protocols/radix-gateway-api) can reconstruct the full state of an airdrop without reading substates. External Links - locker native package (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/blueprints/locker) - AccountLocker invocation definitions (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/locker/invocations.rs) - Radix Docs: Account Locker (https://docs.radixdlt.com/docs/locker) - Radix Docs: Account Deposit Patterns (https://docs.radixdlt.com/docs/account-deposit-patterns) ## Component URL: https://radix.wiki/contents/tech/core-concepts/components Updated: 2026-09-03 Summary: A component is a runtime instance of a blueprint , with its own persistent state, its own globally-addressable identity, and its own configured access… Layer Core Primitive Type Core Primitive Address prefix component_rdx1… (global), internal_component_rdx1… (owned) Attached modules Role assignment, metadata, royalties (optional) Defined in scrypto, radix-engine-interface Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction A component is a runtime instance of a blueprint (/contents/tech/core-concepts/blueprints-and-packages) , with its own persistent state, its own globally-addressable identity, and its own configured access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) . If a blueprint is the class, a component is the instance. Components own vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) , expose methods callable from manifests (/contents/tech/core-protocols/transaction-manifests) or other components, and emit events. Their state lives as engine substates (/contents/tech/core-concepts/substate-model) , which is how composability and atomic cross-component calls remain safe. Owned and global components Instantiating a blueprint does not by itself produce something the rest of the network can call. In Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , ComponentState::instantiate calls the engine's object_new and returns an Owned (https://github.com/radixdlt/radixdlt-scrypto/blob/main/scrypto/src/component/component.rs) : a real object holding the blueprint's state fields, but with no address of its own, reachable only through whatever holds it. That makes owned components an internal building block. A component can keep other components inside its own state the same way it keeps vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) . Publishing one is a separate, explicit step: prepare_to_globalize(owner_role) returns a builder, and globalize() calls object_globalize, which assigns a global address and returns Global. The two states are legible in the address itself. A globalized generic component is addressed component_rdx1… on mainnet, while an owned one carries the internal_component_rdx1… (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address/hrpset.rs) prefix, so an address tells you whether the thing behind it can be called directly or only through its owner. A component can also be globalized at an address reserved in advance, by passing a GlobalAddressReservation to with_address. That is how a blueprint can name its own future address while it is still being instantiated, which the access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) of self-referencing designs depend on. What globalization attaches Globalization is also where a component acquires the parts that are not its own code. globalize() assembles up to three attached modules before it hands the object to the engine: - Role assignment, always. It carries the owner role supplied at prepare_to_globalize plus the role assignments for the component's own methods and for the other modules. This is the object the role assignment module (/contents/tech/core-concepts/role-assignment-module) describes, and it is what turns a blueprint's declared method accessibility into concrete authorization at instantiation time. - Metadata, always. If the developer configured none, an empty default is attached rather than none at all, so every global component has a metadata module (/contents/tech/core-concepts/metadata-module) for names, icons, tags and the verification pointers wallets and explorers read. - Royalties, only on request. enable_component_royalties records an amount per method, each stored together with whether it is locked against later change, and without that call no royalty module is attached at all. The consequence is that the interesting properties of a component are fixed at the moment it goes global, not when its blueprint is published: the same blueprint can produce one component whose methods are open and free and another, from the same code, that is owner-gated and charges a royalty (/contents/tech/core-concepts/component-royalties) on every call. External Links - Component model in scrypto (https://github.com/radixdlt/radixdlt-scrypto/tree/main/scrypto/src/component) - Radix Docs: Components (https://docs.radixdlt.com/docs/blueprints-and-components) - scrypto/src/component/component.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/scrypto/src/component/component.rs) (instantiation, globalization and the attached modules) - Radix Docs: Component Ownership (https://docs.radixdlt.com/docs/component-ownership) - Radix Docs: Address types and prefixes (https://docs.radixdlt.com/docs/bech32-address-types-conversion) ## Radix Wallet URL: https://radix.wiki/contents/tech/core-protocols/radix-wallet Updated: 2026-09-03 Summary: The Radix Wallet is a mobile-first cryptocurrency wallet built by RDX Works , developed to manage $ XRD and other tokens on the Radix network . The wa… The Radix Wallet (https://wallet.radixdlt.com/) is a mobile-first cryptocurrency wallet built by RDX Works (/ecosystem/rdx-works) , developed to manage $ XRD (/contents/tech/core-protocols/xrd-token) and other tokens on the Radix network (https://www.radixdlt.com) . The wallet acts as a gateway to decentralized finance ( DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) ) applications built on Radix, enabling users to securely store assets, connect to dApps, and access a range of web3 services. It can be downloaded from https://wallet.radixdlt.com (https://wallet.radixdlt.com) . Overview The Radix Wallet is intended to serve as the primary gateway for users to access and manage their digital assets and identities on the Radix network (https://www.radixdlt.com) . It functions similarly to wallets on other cryptocurrency networks like MetaMask or Trust Wallet, but includes additional features specific to leveraging Radix network capabilities like smart accounts and transaction manifests (/contents/tech/core-protocols/transaction-manifests) . A key focus in the wallet's development was ease of use, asset safety, and availability across devices. This was enabled by innovations like multi-factor security, simplified recovery from lost credentials, seamless connectivity between mobile and desktop environments, and displaying transparent insights on all wallet assets. The result is a crypto wallet designed to bring an uncomplicated mainstream user experience to interacting with Web3 services. The Radix Wallet Features - Safety and Recovery: The wallet allows for multi-factor security and recovery of accounts (https://youtu.be/iynGh7rPKmM) , preventing loss of funds if a user's phone is lost. This is enabled through the use of smart accounts (https://learn.radixdlt.com/article/what-are-smart-accounts) on the Radix ledger. - Availability Everywhere: Radix Connect technology (https://learn.radixdlt.com/article/what-is-radix-connect) facilitates connectivity between the mobile wallet and desktop browsers for a seamless user experience across devices. This uses peer-to-peer WebRTC connections (https://youtu.be/iynGh7rPKmM) rather than a centralized server. - Intuitive Design: The wallet development prioritized simplified onboarding (https://youtu.be/iynGh7rPKmM) and ease of use based on extensive user experience testing. This testing led to significant changes in the original account model (https://youtu.be/iynGh7rPKmM) . - Understanding Assets: The native support for assets on the Radix network (https://learn.radixdlt.com/article/what-are-native-assets) means the wallet can directly access configurations and metadata to display transparent insights on owned tokens, NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) , liquidity pools and other assets. Components Smart Accounts Smart Accounts (/contents/tech/core-protocols/smart-accounts) are components (/contents/tech/core-concepts/components) on the Radix ledger where users hold their assets. They are similar to accounts on other crypto networks but provide additional functionality. Each Smart Account has an address that can be used to receive tokens and assets. The Radix Wallet allows users to easily manage multiple Smart Accounts. Smart Accounts contain built-in ‘ vaults (https://docs.radixdlt.com/docs/resources) ’ for holding native assets, instead of relying on separate token contracts like other platforms. This allows for direct balance lookups rather than cross-referencing various contracts. Smart Accounts also include programmable logic, such as the ability to configure multi-factor control and recovery. By using " badges (/contents/tech/core-concepts/badges) " and Access Controllers, robust security schemes can be implemented without users having to secure a single seed phrase. Preferences can also be set in Smart Accounts, like whether to accept deposits of unknown tokens or reject them. Because Smart Accounts are Radix components, they can be created "virtually" without issuing an on-ledger transaction. This allows generating an address and receiving assets quickly and easily. Personas (/contents/tech/core-protocols/personas) Personas (/contents/tech/core-protocols/personas) provide an easy way for users to login to Radix dApps without using passwords. They also facilitate selective sharing of user data with websites. Personas (/contents/tech/core-protocols/personas) are created in the Radix Wallet. Each one has a name and can have associated data like an email address or shipping info. Users can utilize one main Persona or create multiples suited for different contexts. Behind the scenes, each Persona links to an Identity component on the Radix ledger. The Identity allows cryptographically signing “challenges” to prove ownership without revealing personal data. Upon logging into a site with a Persona, the website can request access to specific data like a mailing address. The wallet will ask the user’s permission before sharing any data. This eliminates websites needing to store user personal information to deliver customized experiences. Users retain control through the wallet to update data or revoke access. Radix Connect (/contents/tech/core-protocols/radix-connect) Radix Connect (/contents/tech/core-protocols/radix-connect) enables the mobile-centric Radix Wallet to seamlessly interact with dApps on desktop websites. The one-time setup involves installing a Radix Connect (/contents/tech/core-protocols/radix-connect) browser extension that displays a QR code, which is then scanned by the mobile wallet. This establishes an encrypted peer-to-peer connection between the wallet and browser that uses WebRTC technology, eliminating the need for a centralized server relay. The connection automatically activates when accessing desktop dApps requiring wallet interaction. For mobile browsers, the wallet utilizes deep linking to directly communicate with dApps rather than Radix Connect. Native Assets Native Assets (https://learn.radixdlt.com/article/what-are-native-assets) refer to the built-in support for representing resources (/contents/tech/core-concepts/resources) like tokens, NFTs (/contents/tech/core-protocols/nfts-on-radix) , badges (https://docs.radixdlt.com/docs/user-badge-pattern) , and other assets on the Radix network. Configuring Native Asset behavior does not require complex smart contract code. Instead, attributes are specified in the resource definition for each asset. This allows the Radix Wallet to directly access the data and properties of all Native Assets in a user's account and display relevant insights. For example, NFT metadata can be shown in-wallet rather than needing to visit a third party site. The transparency of asset configurations also facilitates visibility of token permissions, such as whether it permits being recalled by the issuer. Transaction Manifests Transaction Manifests (/contents/tech/core-protocols/transaction-manifests) are a more transparent form of transacting on the Radix network compared to typical transactions. Rather than a hashed message to a smart contract address, Manifests explicitly list asset movements between accounts and dApps that will occur. This allows the Radix Wallet to provide a clear summary of exactly what will happen for a user to review and prevent unexpected outcomes. Transaction Manifests also inherently enable atomic composability (/contents/tech/core-concepts/atomic-composability) between components without special coordination code. Roadmap The roadmap below was written while the wallet was under active development by RDX Works (/ecosystem/rdx-works) . It is a record of what was planned, not of what is being built – see Development status below. The Radix team uses a roadmap to guide the continuing development of the wallet, structuring it into three main sections - Milestones, Underway, and Backlog. Milestones represent significant research and development efforts expected to take multiple months. The Underway section highlights features currently in active development with developers working on coding them. Finally, the Backlog contains small and medium scale features that will be pulled into upcoming releases. This combination of longer-term milestone initiatives and incremental feature building aims to progressively enhance the functionality of the wallet while ensuring architectural soundness. The roadmap priorities also balance innovations that improve security, privacy and the user experience. Understanding this structure provides insight into the Radix team's strategy for enabling seamless, secure decentralized experiences for mainstream users via the mobile wallet. Multi-Factor Account Control & Recovery One of the most anticipated wallet features is robust multi-factor authentication for enhanced account security. The Radix public ledger already enables complex multi-signature configurations and access control at the protocol layer. However, streamlining these capabilities for easy use through the wallet UI/UX requires significant design considerations. The multi-factor milestone will allow users to set up and manage additional sign-in requirements per account, such as a hardware security keys or biometric factors. They could also configure advanced recovery methods, like social or custodial account recovery. Behind the scenes, this integrates with the underlying component-based architecture of Radix accounts. To translate the technical possibilities into an intuitive user experience, substantial work is needed to handle use cases and edge cases around multi-factor setup, modification, recovery initiation, device switching, and more. As such, this milestone initiative encompasses numerous complex flows that the Radix team aims to simplify as much as possible. The end goal is for multi-factor security to feel natural and unobtrusive during typical wallet interactions. Mobile-to-Mobile dApp Support While the Radix wallet already enables connecting with desktop-based dApps, allowing direct integration between the mobile wallet and mobile dApps unlocks additional capabilities. Users increasingly access decentralized apps on the go, not just from a computer. Under this milestone, the team will focus on seamless linking when a user wants to connect their Radix wallet to a dApp on their phone. For example, clicking “Connect Wallet” within a DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) game app could automatically prompt the user to select accounts and confirm authorization back in the Radix wallet. Behind the scenes, this leverages Android/iOS functionality for deep linking between apps on the same mobile device. Another motivation for direct mobile-to-mobile connectivity is enabling transactions initiated in a dApp to trigger wallet confirmation in a streamlined manner. This provides a smooth user flow while still ensuring transactions authenticate via the user’s primary wallet rather than granting open-ended permissions to the dApp itself. The Radix team needs to determine optimal technical mechanisms to achieve secure app-to-wallet communication flows on mobile. But the end result will be convenient experiences for accessing decentralized apps directly from your mobile device without extensive switching or sacrificing user security. Push notifications and Requests Push notifications are a familiar concept for mobile apps, but their implementation for a decentralized wallet requires some additional considerations. Rather than just broadcasting informational alerts, Radix intends push notifications to enable transaction requests between the wallet, dApps, and even other users. This ties into the Radix Connect sub-component for transmitting requests across the broader Radix ecosystem. Users may take wallet actions like setting up a transaction in a dApp or through a peer interaction which necessitates confirmation back in their primary wallet. Enabling push requests allows triggering these approvals without constant app switching. For example, an ecommerce dApp could initialize an order transaction that gets securely pushed to the user’s wallet as a request to sign. Or a friend could request funds with notification instantly prompting the user to open their wallet and process it. The vision is to support notifications, signatures, and UI flows which smooth the user experience without compromising security model fundamentals. As Radix Connect is further built out to transmit transactions, data, and other signed payloads between parties, reimagining push mechanisms to take advantage of these capacities unlocks entirely new on-the-go blockchain user experiences. Multiparty Signing Unlike the single signer model common in crypto, Radix evolved its transaction manifest architecture to enable multi-signature capabilities at the protocol level. This allows formally specifying signatures from multiple parties as a requirement for a valid transaction. For example, a DeFi governance token could mandate confirmations from 2 out of 3 authorized board members. However, crafting intuitive wallet flows to coordinate the collaborative actions of multiple signers poses daunting UI/UX challenges. Each participant needs to review and ratify their component of a complex collective transaction. This necessitates passing transaction payloads across multiple wallets to accumulate the Threshold of approvals. Designing smooth experiences for cooperative multi-party transactions encompasses streamlining activities such as partial signing, amending transaction details, establishing required badges, and notarization. At each phase, careful considerations around user roles, account and permission configuration, security guarantees, contingency scenarios, and more play a part as well. By tackling these intricacies, Radix lays the groundwork for innovations ranging from social payment splitting with friends to formal business decisions requiring board resolutions. The result aims to maintain exceptional ease-of-use regardless implementation complexity underneath. Sessions / Streaming Mode Sessions and streaming introduces the concept of bounded wallet permissions to enhance dApp integration. Rather than blanket authorizations, users should be able to intentionally configure conditional account access tied to a particular live session. For example, signing into a web3 game could trigger carefully scoped permissions allowing the game to transact with certain tokens or NFTs during gameplay. However, these privileges would expire after the session closes rather than persist indefinitely. That way users avoid risky overauthorization yet still enjoy convenient experiences. A major goal is enabling one-time permissions configuration to minimize wallet auth interruptions after starting a game or application. This may leverage planned functionality like smart accounts version two for governing fine-grained component access. The principles of user security and control still apply within a session’s defined parameters. Altogether, sessions and streaming builds on Radix’s componentized transaction architecture to balance application requirements with purpose-bound authorization windows. The nuanced approach aspires to eliminate custody arrangements or excessive interruptions while using apps needing account interactions. NFC Scanning NFC scanning functionality would extend the wallet’s connectivity to external environments like events or retail. With appropriate mass adoption, NFC readers integrated by third parties could request verification of assets directly from someone’s mobile wallet via proximity communication protocols. For example, gaining entry to a conference could involve scanning your phone to validate tickets rather than showing a QR code. Or a point-of-sale could confirm sufficient funds for a micropayment upon tapping. These demonstrate more embedded, real-world use cases unlocked by NFC capacities. On a technical level, NFC scanning fits as a new communication interface for the Radix Connect subsystem. It offers another channel for signing or sharing proofs (https://docs.radixdlt.com/docs/auth) of ownership/account status. This would require handling communication handshakes, transfer mechanisms, UI notifications, and appropriate permissioning. While further along the roadmap timeline, enabling seamless NFC and external smart device syncs illustrates the expanding Crypto-to-Real-World integrations on Radix’s ambitious horizon. As community developers ideate these innovative bridges, the team keeps pace preparing supportive wallet tooling. Development status The wallet is no longer under active feature development. The Radix Foundation moved to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) on 28 April 2026, and the public repositories record what that has meant for the wallet and for the service it depends on. Read on 7 August 2026: Repository Most recent commit Latest published release babylon-wallet-ios (https://github.com/radixdlt/babylon-wallet-ios) 30 July 2026 – "Handle missing local mnemonics during factor source access" (https://github.com/radixdlt/babylon-wallet-ios/pull/1513) 1.18.4 (25 November 2025) babylon-wallet-android (https://github.com/radixdlt/babylon-wallet-android) 31 July 2026 – the same fix, landed a day later on Android (https://github.com/radixdlt/babylon-wallet-android/pull/1447) 1.22.1 (9 June 2026) babylon-gateway (https://github.com/radixdlt/babylon-gateway) 20 May 2026 – documentation only (https://github.com/radixdlt/babylon-gateway/pull/840) v1.10.6 (7 April 2026) The pattern is upkeep rather than development. On both mobile repositories the only change since 9 June 2026 is a single defect fix, applied to iOS and Android a day apart; the Gateway API (/contents/tech/core-protocols/radix-gateway-api) that the wallet reads balances and transaction history through has taken no code change since May 2026. None of the three repositories is archived, and both apps remain published and installable. Asked in the Radix Developer Discussion group on 7 August 2026 whether further wallet releases were planned, a contributor answered that there are none: the wallet is being kept going on a volunteer basis with bug fixes only, and the same holds for the Gateway, "until a future direction is set by the community" (https://t.me/RadixDevelopers/65908) and decided by a proposal. The route to that decision was described in the same thread as three stages (https://t.me/RadixDevelopers/65907) – a draft discussion on RadixTalk (/ecosystem/radixtalk) , a temperature check on the Radix Consultation app, then a governance proposal that settles what is done and who does it – with only draft discussions open at that date. See Radix Governance (/contents/tech/core-concepts/radix-governance) for how that process is meant to work. Contributors remain free to open pull requests against either wallet repository in the meantime. ## Radix for AI Agents URL: https://radix.wiki/contents/tech/core-concepts/radix-for-ai-agents Updated: 2026-09-03 Summary: As AI agents increasingly manage financial operations autonomously, the underlying ledger's architecture becomes critical. Radix provides four propert… Category Use Case Key Properties Readable transactions, no approvals, atomic ops, linear scale Related Radix Context for AI (/developers/ai-agents/radix-context) Agent Interface Model Context Protocol (https://modelcontextprotocol.io) servers Overview As AI agents increasingly manage financial operations autonomously, the underlying ledger's architecture becomes critical. Radix provides four properties that make it uniquely suited for autonomous AI agent operations: 1. Machine-Readable Transactions Transaction manifests (/contents/tech/core-protocols/transaction-manifests) are human AND machine readable. An AI agent can parse, verify, and generate manifests – understanding exactly what a transaction will do before signing. On EVM chains, blind signing (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) means agents sign hex data they can't interpret, creating catastrophic risk. 2. No Approval Exploits The ERC-20 (https://eips.ethereum.org/EIPS/eip-20) approve() pattern requires granting contracts access to your entire balance. For an AI agent, this means trusting every contract it interacts with. On Radix, native assets (/contents/tech/core-concepts/native-assets-vs-token-approvals) move directly – no approval surface to exploit. 3. Atomic Composability Agents can compose complex multi-step strategies in single atomic transactions (/contents/tech/core-concepts/atomic-composability) . No partial failures, no stuck funds, no error recovery needed. 4. Linear Scalability When millions of agents transact simultaneously, gas auctions don't scale. Xi'an (/contents/tech/releases/radix-mainnet-xian) delivers linear throughput – more nodes means more capacity. Connecting an agent The properties above describe the ledger. What an agent actually talks to is a server, and on Radix that server is almost always an Model Context Protocol (https://modelcontextprotocol.io) (MCP) endpoint — the standard by which a model client discovers a set of tools and calls them. Six are in public use, at different layers of the stack: - RadixScan (/ecosystem/radixscan) – a keyless MCP server at mcp.ai.radixscan.io that reads ledger state and builds, validates and simulates transaction manifests (/contents/tech/core-protocols/transaction-manifests) , then hands the finished manifest to the user's wallet for signature. It never holds a key. - AgentWallet (/developers/ai-agents/agent-wallet-ai) – exposes the same wallet, swap and lending operations through both a LangGraph (https://www.langchain.com/langgraph) toolset and an MCP server, so an agent can drive a funded account on mainnet or Stokenet (/contents/tech/releases/stokenet) . - radixdlt-connector-mcp (/developers/infrastructure/radixdlt-rust-sdk) – a local MCP server from the GenkiPool Rust SDK that pairs a Radix Wallet (/contents/tech/core-protocols/radix-wallet) over Radix Connect (/contents/tech/core-protocols/radix-connect) and requests signatures on the user's own machine. It is installed from the repository rather than crates.io (https://crates.io) , where none of the SDK's crates are published. - Igentix (/developers/ai-agents/igentix) – a Stokenet demonstration at demo.igentix.app/mcp where an agent discovers a priced service, pays for it under x402 (/developers/ai-agents/ai-agents-and-x402) , and receives the result with no gas token and no wallet pop-up. - Radix Community (/ecosystem/genkipool) – a hosted, keyless server at radix-community.genkipool.com/api/mcp and the largest of the set: 34 tools, every one of them annotated read-only. It answers from three layers at once – the site’s curated documentation, the ledger (entities, balances, transactions, validators, NFT (/contents/tech/core-protocols/nfts-on-radix) and component (/contents/tech/core-concepts/components) state), and its browser developer console, where the manifest-building tools return a manifest (/contents/tech/core-protocols/transaction-manifests) the user signs from the console with their own wallet. Same operator as radixdlt-connector-mcp above, and a different thing: that one runs on the developer’s machine and pairs a wallet over Radix Connect (/contents/tech/core-protocols/radix-connect) ; this one is a public endpoint that holds nothing. - This wiki – radix.wiki/api/mcp serves the encyclopedia itself over the same protocol: search, read and list tools are open and unauthenticated, and an agent that signs a ROLA (/developers/frontend/03-rola-authentication) challenge with its own key can also create and edit pages. The full contract is at AGENTS.md (/AGENTS.md) , and any page URL with .md appended returns that page as markdown. The pattern RadixScan, AgentWallet, radixdlt-connector-mcp and Radix Community share is the one that makes the manifest (/contents/tech/core-protocols/transaction-manifests) matter: the server composes the transaction, the human's wallet signs it. An agent can be given the ability to propose any operation without being given custody of anything. Developer Resources The radix-context (/developers/ai-agents/radix-context) project provides 19 curated files that teach AI coding agents to build on Radix, covering Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , Gateway API (https://docs.radixdlt.com/docs/network-gateway) , transaction manifests (/contents/tech/core-protocols/transaction-manifests) , and wallet integration. External Links - radix-context on GitHub (https://github.com/xstelea/radix-context) - Blind Signing and Transaction Manifests (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) ## Native Assets vs Token Approvals URL: https://radix.wiki/contents/tech/core-concepts/native-assets-vs-token-approvals Updated: 2026-09-03 Summary: On Ethereum and other EVM chains, using DeFi requires the token-approval pattern : before a contract can move a user’s ERC-20 tokens it must first be… Native Assets vs. Token Approvals Concept Asset-security model comparison EVM pattern approve() → transferFrom() (standing allowance) Radix pattern Direct vault-to-vault movement declared in each transaction manifest (/contents/tech/core-protocols/transaction-manifests) Risk removed Dormant allowances a compromised or malicious contract can later drain See also Asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) , Buckets, proofs & vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) Overview On Ethereum (https://ethereum.org) and other EVM chains, using DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) requires the token-approval pattern: before a contract can move a user’s ERC-20 tokens it must first be granted an allowance with approve(), which it later spends via transferFrom(). Radix takes a different route – assets are native resources (/contents/tech/core-concepts/asset-oriented-programming) that move directly between vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) , so no standing permission ever exists to be abused. The approval pattern and its risks Because paying gas for a fresh approval before every interaction is costly, wallets and dApps routinely request unlimited allowances. Those allowances persist after the interaction ends: if the approved contract is later exploited, maliciously upgraded, or was a phishing lure, it can call transferFrom() to drain every approved token without any further consent from the owner ( revoke.cash – What Are Token Approvals? (https://revoke.cash/learn/approvals/what-are-token-approvals) ). The burden falls on users to audit and manually revoke dangling allowances after the fact. How Radix removes approvals On Radix, tokens are first-class resources (https://docs.radixdlt.com/docs/resources) enforced by the Radix Engine (/contents/tech/core-protocols/radix-engine) itself, not balances tracked inside each token’s own contract. A transaction is expressed as a transaction manifest (https://docs.radixdlt.com/docs/manifest) – an explicit, ordered list of instructions that withdraws a specific amount from the caller’s account into a bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) and passes it to a component (/contents/tech/core-concepts/components) . The movement is scoped to that single transaction; nothing is left behind for a contract to spend later. Guaranteed outcomes and clear signing Manifests (/contents/tech/core-protocols/transaction-manifests) also support guarantees: a signer can require that a transaction return at least a stated amount to their account or fail atomically, defending against slippage and malicious routing. Combined with the human-readable manifest the Radix Wallet (/contents/tech/core-protocols/radix-wallet) presents before signing, users confirm exactly which assets will move – an outcome-based approval rather than a blank cheque ( Radix Docs – Transaction Manifest (https://docs.radixdlt.com/docs/manifest) ). Implications With no standing allowances, there is nothing to periodically revoke and no dormant attack surface accumulating across a wallet’s history. The model is a natural fit for autonomous AI agents (/contents/tech/core-concepts/radix-for-ai-agents) , which never grant open-ended permissions and can verify a manifest’s full effect before signing. External Links - Radix Docs – Transaction Manifest (https://docs.radixdlt.com/docs/manifest) - Radix Docs – Resources (https://docs.radixdlt.com/docs/resources) - revoke.cash – What Are Token Approvals? (https://revoke.cash/learn/approvals/what-are-token-approvals) ## Radix vs Polkadot URL: https://radix.wiki/contents/tech/comparisons/radix-vs-polkadot Updated: 2026-09-03 Summary: Both Radix and Polkadot address scalability through sharding , but with very different architectures: Polkadot uses a hub-and-spoke model: parachains… Radix Unlimited shards, native composability Polkadot (https://polkadot.com) Limited parachain slots, shared security via relay chain Key Difference Infinite sharding (/contents/tech/core-concepts/sharding) vs fixed parachain capacity Overview Both Radix and Polkadot (https://polkadot.com) address scalability through sharding (/contents/tech/core-concepts/sharding) , but with very different architectures: Sharding Model Polkadot uses a hub-and-spoke model: parachains (application-specific shards) connect to a relay chain that provides shared security. Parachain slots are limited and auctioned – creating artificial scarcity. Radix uses Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) with effectively unlimited shards. Consensus is braided dynamically per-transaction across relevant shards – no slot auctions, no capacity limits. Composability Polkadot's XCM (Cross-Consensus Messaging) enables cross-parachain communication, but it's asynchronous. Radix provides atomic composability (/contents/tech/core-concepts/atomic-composability) across all shards – critical for DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) where partial execution can mean lost funds. Scalability in practice (2026) The braided, effectively-unlimited-shard architecture described above is the design of Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , not the current state of the live network. Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet today runs a single, unsharded Cerberus instance; multi-shard consensus is being delivered through the Hyperscale (/contents/tech/research/hyperscale-rs) program (the eMunie → Tempo → Cerberus → Xi’an (/contents/tech/research/consensus-evolution) lineage). A January 2026 public test (/contents/tech/research/hyperscale-500k-tps) sustained 500,000+ real cross-shard transactions per second (peaking above 700,000) across 128 shards, as detailed in the Radix Hyperscale update (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) . Against Polkadot (https://polkadot.com) , the practical difference is capacity model: Polkadot’s throughput is bounded by a fixed number of auctioned parachain slots on its relay chain, whereas Radix’s Hyperscale target is to add shards without slot auctions or capacity caps, preserving atomic composability (/contents/tech/core-concepts/atomic-composability) across every shard rather than relying on asynchronous cross-parachain messaging (XCM). See also - Hyperscale: 500K TPS Public Test (/contents/tech/research/hyperscale-500k-tps) - Consensus Evolution at Radix (/contents/tech/research/consensus-evolution) - Radix vs Cosmos (/contents/tech/comparisons/radix-vs-cosmos) ## Personas URL: https://radix.wiki/contents/tech/core-protocols/personas Updated: 2026-09-03 Summary: Personas is a digital identity management feature introduced by Radix as part of its Q2 2023 network upgrade to Babylon . It represents a significant… Personas is a digital identity management feature (https://www.radixdlt.com/blog/radix-wallet-personas) introduced by Radix as part of its Q2 2023 network upgrade to Babylon (/contents/tech/releases/radix-mainnet-babylon) . It represents a significant shift in user authentication and identity management in the context of Web3 technologies. Overview Personas were developed to address the limitations of traditional Web2 and emerging Web3 authentication systems. In Web2, users often rely on a centralized system of passwords and logins, leading to security risks and privacy concerns. The advent of Web3 introduced wallet-based logins that, while more secure and trustless, do not offer flexibility in information sharing and are still tied to what users own rather than who they are. Functionality Radix Personas aim to separate a user's online identity from their asset-holding accounts, enhancing privacy and user control. This decentralized system uses a component (/contents/tech/core-concepts/components) known as "identity" on the Radix ledger. It allows users to access decentralized applications (dApps) based on their identity rather than their assets. This approach contrasts with centralized systems like Passkeys, where control over access is held by a single entity, and traditional Web3 wallets, where all wallet contents are shared upon connection. Process The login process with Radix Personas involves several steps: - Connection to a dApp on Radix using Radix Connect (/contents/tech/core-protocols/radix-connect) . - The user's Radix Wallet (/contents/tech/core-protocols/radix-wallet) sends a unique cryptographic data piece. - The dApp verifies this data against identity data on the Radix Network (https://www.radixdlt.com) . - Upon successful verification, the user logs in without needing a password. User Control and Privacy Radix Personas provide users with control over the information shared with websites, differing from both Web2 and traditional Web3 solutions. Users can have multiple personas and associate various personal data with each, deciding what information to share with each service. Impact The introduction of Personas by Radix is seen as a step towards enhancing user sovereignty, privacy, and control in the digital domain, addressing some of the critical challenges faced in both Web2 and Web3 identity management systems. ## NFTs on Radix URL: https://radix.wiki/contents/tech/core-protocols/nfts-on-radix Updated: 2026-09-03 Summary: Non-fungible tokens (NFTs) are digital assets that represent unique items like artwork, collectibles, and in-game items. On Radix, NFTs are core primi… Non-fungible tokens (https://en.wikipedia.org/wiki/Non-fungible_token) (NFTs) are digital assets that represent unique items like artwork, collectibles, and in-game items. On Radix, NFTs are core primitives. Overview On smart contract platforms such as Ethereum (https://ethereum.org) , NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) are typically implemented using complex token standards and contracts. In contrast, Radix recognizes NFTs as core primitives. This intuitive architecture simplifies NFT development and ownership, while unlocking advanced functionality through composability with other Radix components (/contents/tech/core-concepts/components) . Implementation NFTs on Radix are ‘ resource (/contents/tech/core-concepts/resources) ’ objects in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) and natively understood by Radix's asset architecture. As such, they benefit from native accounting of token balances and direct account transfers that avoid the need for complex smart contract interactions. Radix NFTs integrate with other Radix components for managing access control, royalties, decentralized governance, and other functionality. Properties NFT collections on Radix are defined in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) as non-fungible resources with the following properties: - Supply - The maximum number of NFTs that can be minted - Authorization - Who is allowed to mint new NFTs - Metadata schema - The structure of metadata attached to each NFT - Transferability - Whether NFTs can be transferred between accounts Once published to the network, NFTs can be minted by calling the resource's minting function. Each minted NFT receives a unique ID, which combined with the resource address provides a globally unique identifier. Finally, newly minted NFTs are transferred to the recipient's account. The network natively tracks ownership balances of non-fungible resources. No custom token standards or separate smart contract logic is needed. Ownership can be programmatically restricted using mechanisms like soulbound NFTs. Managing NFT Ownership A key advantage of Radix for NFTs is how token ownership is natively tracked and managed at the protocol level. On Ethereum, NFT ownership exists only within smart contracts, which maintain their own separate ledger of who owns each NFT. To transfer an NFT, you must call the smart contract's functions. On Radix, NFT ownership is directly recorded in user accounts, just like token balances. No separate contract is required. This account-based ownership enables simple and secure NFT transfers. To send an NFT, you make an account-to-account transaction just like transferring XRD (/contents/tech/core-protocols/xrd-token) . Ownership is updated instantly. NFT transfers can also be restricted. For example, by making an NFT resource "non-transferrable", it becomes soulbound to the original recipient's account. This is useful for NFT tickets, certificates, or identity badges (https://docs.radixdlt.com/docs/auth) . Built-in ownership tracking removes friction and vulnerabilities compared to smart contract approaches. All NFT balances are visible on-ledger, and it is easy to prove ownership or authorize use via transaction attachments. Advanced access control features like transfer hooks and reclaimable NFTs can also be implemented in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) . Advanced NFT Features While Radix provides core NFT functionality, Scrypto enables developers to build advanced features: - NFTs can integrate with on-chain access-control badges (https://docs.radixdlt.com/docs/user-badge-pattern) that confer access to on-chain rewards or real world events. - Minting rules and royalty structures for NFT collections can be governed on-chain via proposals and voting by DAO members. - NFTs can interoperate with other Radix components such as a payment splitter for royalties or a lending platform for NFT collateralization. - NFT gaming items can be interoperable between metaverse environments because items are native to the base layer. Use Cases The flexibility of Radix makes it well-suited for diverse NFT use cases, from art to identity management. Digital Art - Representing collectible artwork or music as verifiable digital assets - Managing artwork ownership and provenance on-ledger - Integrating with marketplaces, social platforms, and metaverse environments - Automating royalties to artists on secondary sales via payment splitters Identity and Access Management - Soulbound NFTs as unforgeable credentials or badges (/contents/tech/core-concepts/badges) - Managing permissions to access apps, venues, gated content - KYC and reputation systems based on NFT credentials - Interoperability with Radix Execute for dynamic permissions Ticketing - Tokenizing event tickets and tracking resales - Putting collectible memorabilia directly into fans' hands - Coding specialized access like seating zones into NFT tickets - Time-expiring tickets for conferences or transportation Gaming - In-game items and assets as user-owned NFTs rather than centralized game inventory - Composability with DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) for true in-game economies - Metaverse interoperability of game items across worlds - Player identities and profiles as soulbound NFTs Where NFT Data Lives A Radix NFT carries two kinds of information, and they are stored in different places. Its structured data fields – the traits and attributes that make each token unique – live directly on the ledger as part of the non-fungible resource's state. These fields are defined in Scrypto (https://docs.radixdlt.com/docs/resource-creation-in-detail) using the NonFungibleData structure. Every field is immutable by default: once an NFT is minted, that data can never be changed by anyone. A field only becomes updatable if the issuer explicitly marks it #[mutable], and even then it can be changed only by the holder of the resource's non-fungible-data updater badge. The NFT's image or media is handled separately. Under the Radix metadata standard (https://docs.radixdlt.com/docs/metadata-for-wallet-display) , artwork is referenced by a key_image_url field: a single URL that points to the file off-ledger, typically on a web host or on IPFS (https://ipfs.tech/) . The ledger stores the pointer, not the image bytes. This mirrors how most other chains handle NFT media – the token record is on-chain, while the picture itself usually is not. The practical consequence: an NFT's on-ledger data – its traits, ownership, and provenance – is as durable and verifiable as the ledger itself, and immutable fields are permanent. The linked image inherits the trust and durability of wherever its URL resolves, and can change or become unavailable if that host or IPFS pin disappears. Collections that want stronger guarantees for their media can store a verifiable hash of the image on-ledger or use content-addressed storage. ## Buckets, Proofs & Vaults URL: https://radix.wiki/contents/tech/core-concepts/buckets-proofs-and-vaults Updated: 2026-09-03 Summary: Radix's asset-oriented programming model uses three core container types: Permanent storage for resources . Every account, component , and dApp stores… Vault Permanent storage container for resources (/contents/tech/core-concepts/resources) Bucket Temporary container for moving resources between calls Proof Zero-cost ownership evidence (doesn't move the resource) Overview Radix's asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) model uses three core container types: Vaults Permanent storage for resources (/contents/tech/core-concepts/resources) . Every account, component (/contents/tech/core-concepts/components) , and dApp stores its assets in vaults. Vaults enforce the conservation law – tokens can only be moved, never duplicated or destroyed (unless explicitly burned). Buckets (https://docs.radixdlt.com/docs/resources) Temporary containers for moving resources between method calls within a transaction manifest (/contents/tech/core-protocols/transaction-manifests) . Buckets (https://docs.radixdlt.com/docs/buckets-and-vaults) must be emptied by the end of a transaction – they cannot be stored, preventing tokens from being "stuck" in contract state. Proofs (https://docs.radixdlt.com/docs/auth) Non-transferable evidence of resource ownership. Proofs are placed in auth zones (/contents/tech/core-concepts/access-rules-and-auth-zones) to satisfy access rules (https://docs.radixdlt.com/docs/auth) without moving the underlying asset. This enables badge (/contents/tech/core-concepts/badges) -gated access patterns. A vault answers to the resource, not to its holder The three containers are usually taught as storage classes, which understates what a vault is. A vault is a node in the engine's own state tree, created and owned by a component, holding exactly one resource (/contents/tech/core-concepts/asset-oriented-programming) type. Its methods are not free functions on the owning component. They are blueprint (/contents/tech/core-concepts/blueprints-and-packages) methods, and each one is gated by a role that is defined on the resource. In the fungible vault blueprint (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/blueprints/resource/fungible/fungible_vault.rs#L266-L273) the map is explicit: take, take_advanced and lock_fee require the withdrawer role, put the depositor role, recall the recaller role, burn the burner role, and freeze and unfreeze the freezer role. On a freely transferable token most of those roles are set open at creation, because a token nobody may withdraw is not a token. What protects a user's balance is therefore not the vault. It is the account component (/contents/tech/core-protocols/smart-accounts) that holds the vault, whose own access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) put the owner badge in front of withdraw. A manifest reaches the vault by going through the account, and the account is where the check lives. The vault is the container; the component around it is the lock. Distinguishing the two matters for anyone writing a blueprint that stores other people's assets, because a vault handed out or reachable by another route carries no protection of its own. Buckets are the other half of the same design. A bucket exists only for the length of a transaction (/contents/tech/core-protocols/transaction-manifests) , cannot be written into component state, and must be empty or returned to a vault before the transaction finalizes. That single rule is what makes the conservation guarantee (https://docs.radixdlt.com/docs/buckets-and-vaults) checkable by the engine instead of by an auditor: a transaction that would lose, duplicate or strand a token fails at commit rather than succeeding quietly, and there is no path by which tokens become permanently stuck in a contract that forgot to implement a withdrawal. Proofs sit outside this flow entirely. A proof is evidence that some quantity of a resource is held, placed in an auth zone (/contents/tech/core-concepts/access-rules-and-auth-zones) for the duration of a call and then dropped. It moves nothing, so presenting a badge to a method that demands one costs neither the badge nor a transfer. When the boundary failed (August 2026) The distinction above stopped being academic on 31 August 2026. In the Hyperlane asset drain and network halt (/contents/history/hyperlane-asset-drain-2026) , transactions took resources out of vaults belonging to other people without ever going through the accounts that held them. The engine's reference check accepted a vault named directly in a manifest as a valid direct-access reference on the strength of its blueprint alone, and once the caller held that reference, take was gated only by the resource's withdrawer role, which on a freely transferable token is open. The account's access rules were never consulted because the account was never called. The full account of the defect, with the source references, is on the Radix Engine (/contents/tech/core-protocols/radix-engine) page. Nothing in the container model itself was broken by this. Conservation held, buckets still balanced, and no token was duplicated or destroyed. What failed was the assumption that a vault is only ever reachable through the component that owns it, which is the assumption everything above rests on. External Links - Radix Docs: Resources (https://docs.radixdlt.com/docs/resources) - Radix Docs: Buckets and Vaults (https://docs.radixdlt.com/docs/buckets-and-vaults) - Radix Docs: Auth, proofs and access rules (https://docs.radixdlt.com/docs/auth) - radixdlt-scrypto v1.3.1: fungible_vault.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/v1.3.1/radix-engine/src/blueprints/resource/fungible/fungible_vault.rs) ## Trust Boundary URL: https://radix.wiki/contents/tech/core-concepts/trust-boundary Updated: 2026-09-03 Summary: A Trust Boundary [ /trʌst ˈbaʊndəri/ ] is a concept used in distributed systems to describe the point beyond which a component must rely on the behavi… Trust Boundary Field Distributed systems · security architecture Definition The line beyond which a component must rely on another’s integrity Forms Physical (firewall, auth) or logical (module / privilege interface) In blockchain Each ledger is its own trust boundary; cross-chain transfers require bridges Radix approach Linear scaling via braided sharding (/contents/tech/core-concepts/sharding) keeps the whole network inside one trust boundary – atomic cross-shard composability, no bridges A Trust Boundary [ /trʌst ˈbaʊndəri/ ] is a concept used in distributed systems to describe the point beyond which a component must rely on the behavior and integrity of another. Trust boundaries are important because they define the limits of a system's security and control. Overview In the context of blockchains and distributed ledgers, trust boundaries are the reason why assets cannot be transferred between different chains and instead require workarounds such as burn and mint bridges (https://docs.chainswap.com/mechanism/chainswap-architecture) . Radix has its own trust boundary and is designed to obviate the need for asset swaps or sidechains by being linearly scalable. Trust Boundaries in Distributed Systems In the context of distributed systems, a trust boundary can take the form of a physical boundary, such as a network firewall or user authentication system. It could also be a logical boundary, such as an interface between two separate software components or a boundary between different levels of privilege within a system. Regardless of its form, a trust boundary serves as a dividing line between different parts of a distributed system. On one side of the boundary, the system can be trusted to behave as expected and to enforce security controls. On the other side, the system's behavior is less certain and may be subject to malicious or unintended actions. One of the key challenges of managing trust boundaries in distributed systems is ensuring that they are properly enforced. This can be difficult because distributed systems are often composed of many different components that may be developed and maintained by different teams or organizations. As a result, it can be difficult to ensure that all components are properly configured and secure, and that they all adhere to the same security standards. To address this challenge, many organizations rely on strict security policies and procedures, as well as security tools and technologies, to enforce trust boundaries and protect their distributed systems. This can include things like encryption, authentication, and access controls, as well as regular security assessments and vulnerability testing. Overall, trust boundaries are an important concept in the field of distributed systems. They help to define the limits of a system's security and control, and determine which parts of a system can be trusted to behave as expected. By properly enforcing trust boundaries, organizations can help to protect their distributed systems from security threats and ensure their reliability and integrity. Radix and the single-ledger trust boundary Most blockchains scale by adding ledgers – sidechains, rollups, or app-chains – and every new ledger draws a fresh trust boundary. Moving an asset across one means trusting a burn-and-mint bridge (https://docs.chainswap.com/mechanism/chainswap-architecture) or a wrapped representation, which is why bridges have been among the most exploited components in crypto. Radix takes the opposite route. Its Cerberus (/contents/tech/research/cerberus-whitepaper) consensus shards (/contents/tech/core-concepts/sharding) the ledger into many parallel shard groups (/contents/tech/core-concepts/shard-groups) while braiding them together for any transaction that touches more than one, so a single transaction can atomically span shards. The result is a network that scales throughput without ever splitting into separate trust boundaries: atomic composability (/contents/tech/core-concepts/atomic-composability) holds across the entire ledger, and no bridge is needed to move value within it. ## Subintents and Pre-Authorizations URL: https://radix.wiki/contents/tech/core-concepts/subintents-and-pre-authorizations Updated: 2026-09-03 Summary: Pre-authorizations – the user-facing name for subintents – allow "a partial transaction to be authorized by one actor such that it can then become a p… Concept Subintent (user-facing name: pre-authorization) Introduced Cuttlefish protocol update (https://docs.radixdlt.com/docs/cuttlefish) – enacted on mainnet 18 December 2024, epoch 160923 (/contents/tech/releases/protocol-updates) Transaction format Transaction V2 (intent tree: one transaction intent + child subintents) Signed artefact SignedPartialTransaction – a single signed subintent Required instruction Subintent manifests (/contents/tech/core-protocols/transaction-manifests) must end with YIELD_TO_PARENT Fee payment Never in the subintent – fees are locked by the parent transaction intent Propagation Out-of-band; the network mempool only accepts complete transactions Toolkit call sendPreAuthorizationRequest ( Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) 2.2.0+) Overview Pre-authorizations – the user-facing name for subintents – allow "a partial transaction to be authorized by one actor such that it can then become a part of a larger atomic transaction", which another actor then submits to the network ( Radix Docs (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) ). They shipped to mainnet with the Cuttlefish protocol update (https://docs.radixdlt.com/docs/cuttlefish) on 18 December 2024, alongside the Transaction V2 format that carries them. The problem they solve is a familiar one in decentralized finance. When two parties want to trade, lend, or settle with each other, each has to commit funds before knowing whether the other side will follow through. The conventional fix is an escrow contract or a custodial order book: a third party holds the assets while the match is arranged. Subintents remove that intermediary. Each party signs only their own half of the interaction, and the halves are combined into one transaction that either executes completely or not at all – so no one ever hands custody to anyone. This is atomic composability (/contents/tech/core-concepts/atomic-composability) extended across signers rather than across components (/contents/tech/core-concepts/components) . A single Radix transaction was already all-or-nothing; Transaction V2 makes the authorization of that transaction divisible among several people who never have to trust each other, or be online at the same time. The Intent Tree A Transaction V2 transaction is a tree. At the root is a single transaction intent – the part that locks the fee, is notarized, and is what the network actually accepts into its mempool. Hanging beneath it are subintents, each carrying its own manifest (/contents/tech/core-protocols/transaction-manifests) and its own signatures. Execution is explicitly parent-driven. A subintent does not begin running when the transaction starts; it runs only when its parent yields to it. The parent may pass buckets of resources (/contents/tech/core-concepts/resources) at the moment of yielding, and those arrive on the subintent's starting worktop (/contents/tech/core-concepts/worktop) . Every subintent manifest must finish with a YIELD_TO_PARENT instruction handing control back, and may include intermediate yields where it needs to run logic before and after interacting with the rest of the transaction. Two structural rules follow from this design and are worth stating plainly: - Subintents cannot lock fees. Fee payment belongs to the transaction intent at the root. This is what makes delegated-fee patterns possible – the signer of a subintent need not hold any XRD (/contents/tech/core-protocols/xrd-token) at all. - The Radix Wallet (/contents/tech/core-protocols/radix-wallet) currently requires that pre-authorizations have no children of their own. All interaction with other subintents must route through the parent ( Radix Docs (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) ). The engine's intent tree is more general than what the wallet will presently sign. The recommended manifest shape is to withdraw and yield buckets first, then take deposits at the end. That ordering leaves the maximum liquidity available to the rest of the transaction while it is being assembled. The Pre-Authorization Flow The documented flow (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) has four parts. It parallels the ordinary transaction flow, but splits construction away from submission – in the dApp toolkit the two are initiated by sendTransaction and sendPreAuthorizationRequest respectively. - Request. A dApp front-end sends the wallet a subintent manifest stub, an expiry schedule, and an optional message. The stub must not contain fee locks. - Review and signing. The wallet shows a pre-authorization review. If the subintent is self-contained, the user gets a preview-style review and can add their own guarantees; otherwise, a subintent with the GeneralSubintent classification displays statically-computable bounds on account withdrawals and deposits. On signing, the wallet returns a hex-encoded SignedPartialTransaction. Aside from possibly adding access controller (/contents/tech/core-concepts/access-controller) calls to reach the relevant accounts, the wallet does not alter the manifest. - Propagation. The front-end relays the signed partial transaction to a back-end that can build it into a transaction – the dApp's own service, or an external matcher. This step happens entirely off-network: subintent aggregation is out-of-band, and the mempool only ever operates on complete transactions. - Construction and submission. The aggregator finds or creates the other intents, assembles the transaction with a V2 transaction builder, previews it, notarizes it, and submits it. Because the aggregator is an ordinary off-ledger service rather than protocol infrastructure, a subintent author who wants to constrain who may assemble their transaction adds a VERIFY_PARENT instruction to the manifest – a check that the parent satisfies a given access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) . Some aggregators require it so that only their own service can be used. Expiry, Bounds, and What the Signer Is Guaranteed A signed subintent is a standing offer, so it needs a deadline. The Radix dApp Toolkit (https://github.com/radixdlt/radix-dapp-toolkit/blob/main/packages/dapp-toolkit/README.md) exposes two forms of expiry on a pre-authorization request: setExpiration('afterDelay', seconds), measured from the moment the user signs, and setExpiration('atTime', unixTimestamp) for an exact cut-off. A dApp may also set an optional SubintentHeader to bound the subintent more tightly: Field Meaning startEpochInclusive First epoch in which the subintent may be included endEpochExclusive Epoch at which it stops being includable minProposerTimestampInclusive Earliest proposer timestamp (optional) maxProposerTimestampExclusive Latest proposer timestamp (optional) intentDiscriminator Value distinguishing otherwise-identical subintents Expiry and epoch bounds limit when a subintent can be used. What limits what it can do is the manifest itself. The signer's protection comes from ASSERT_ instructions written into the stub, which fail the whole transaction unless the signer ends up with at least the resources they expected. The documentation is direct about where the responsibility sits: the dApp developer will likely need to tweak those assertions so the displayed bounds match what the user expects. This is a meaningful shift in what a signature means. In an ordinary transaction the user reviews the complete thing they are signing. In a pre-authorization they sign a fragment whose surrounding context does not exist yet, and they are protected not by seeing the final transaction but by the assertions and atomicity that constrain it. It is the same trade-off discussed under blind signing and transaction manifests (/contents/tech/core-concepts/blind-signing-and-transaction-manifests) , applied one level up. Use Cases The Radix documentation (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) works through four patterns, which between them cover most of what the primitive is for. Delegated fees A dApp wants to pay network fees on a user's behalf so the user need not hold XRD. The user signs a subintent that interacts with the dApp; the dApp decompiles it to confirm it does exactly what was expected, wraps it in a transaction intent that locks fees from the dApp's own account, previews, signs, and submits. This is the clearest illustration of why subintents cannot lock fees themselves. User badge deposit An account can be configured to reject deposits of unfamiliar resources, which blocks a dApp from simply sending a user a badge (/contents/tech/core-concepts/badges) . Instead the dApp proposes a subintent that receives the badge at the start of execution and deposits it to the user's own account – the user authorizes their own deposit. A VERIFY_PARENT can be added so the user knows only the dApp itself can use the manifest. Intent-based partial trades A user signs one side of a trade – withdraw, optionally interact with a component, yield the buckets, deposit what comes back – and passes it to an aggregation network that finds the counterparty. Anthic (/ecosystem/anthic) is the worked example in the documentation: a DEX front-end builds an Anthic-compatible subintent stub, sends it to the wallet, then submits the signed partial transaction to the Anthic Trade API, which matches it against market makers and assembles the finished transaction. The same shape underlies the fixed-rate peer-to-peer lending (/ecosystem/p2p-lending) pattern, where a lender's offer and a borrower's collateral are two subintents combined at match time. Coordinated purchase Two friends want to buy tickets on the condition that they either both get one or neither does. A dApp proposes a separate subintent to each and combines the results into one transaction that must commit atomically. No escrow, no refund logic, no partial outcome to unwind. Limitations - Matching is not a protocol service. Subintent aggregation happens off-network. At the Cuttlefish launch there was no general-purpose subintent aggregator or solver – only purpose-built matchers such as Anthic and dApps acting as their own aggregator. A dApp that wants intent-based matching has to choose or run one. - Tooling arrived unevenly. The V2 partial-transaction builders shipped in the Rust radix-transactions crate 1.3.0+ and in the UniFFI Radix Engine (/contents/tech/core-protocols/radix-engine) Toolkits; the TypeScript Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) did not support Transaction V2 at Cuttlefish launch. - Nesting is wallet-limited. The wallet will not sign a pre-authorization that has children of its own, so multi-level intent trees are not reachable through the standard wallet flow today. - Liveness is not guaranteed. A signed subintent obliges nobody to complete it. If no counterparty or aggregator picks it up, it simply expires – safely, but with nothing having happened. See Also - Radix Protocol Updates (/contents/tech/releases/protocol-updates) – the Cuttlefish update that shipped subintents, and the ones either side of it - Atomic Composability (/contents/tech/core-concepts/atomic-composability) - Buckets, Proofs and Vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) - Worktop (/contents/tech/core-concepts/worktop) - Transaction Processor (/contents/tech/core-concepts/transaction-processor) - Transaction Lifecycle (developer tutorial) (/developers/transactions/02-transaction-lifecycle) - Radix Mainnet – Babylon (/contents/tech/releases/radix-mainnet-babylon) External Links - Pre-authorizations & Subintents – Radix Docs (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) - Cuttlefish protocol update – Radix Docs (https://docs.radixdlt.com/docs/cuttlefish) - Radix dApp Toolkit – pre-authorization requests and subintent headers (https://github.com/radixdlt/radix-dapp-toolkit/blob/main/packages/dapp-toolkit/README.md) - Advanced Access Rules (caller requirements) – Radix Docs (https://docs.radixdlt.com/docs/advanced-accessrules) ## Staking URL: https://radix.wiki/contents/tech/core-concepts/staking Updated: 2026-09-03 Summary: Staking is a crucial mechanism in many cryptocurrency systems, particularly those using Proof of Stake (PoS) or Delegated Proof of Stake (DPoS) consen… Staking is a crucial mechanism in many cryptocurrency (https://www.coinbase.com/learn/crypto-basics/what-is-staking) systems, particularly those using Proof of Stake (PoS) or Delegated Proof of Stake (DPoS) consensus protocols. It involves participants locking up their cryptocurrency tokens (https://www.coinbase.com/learn/crypto-basics/what-is-staking) to support the operation and security of a blockchain network. In return for their contribution, stakers typically earn rewards in the form of additional tokens. Overview The concept of staking serves multiple purposes within a blockchain ecosystem. Primarily, it acts as a Sybil protection mechanism (https://learn.radixdlt.com/article/what-kind-of-staking-system-does-radix-use) , ensuring the network's security by making it economically unfeasible for malicious actors to gain control. Additionally, staking encourages token holders to actively participate in network governance and operation. One notable implementation of staking is found in the Radix network (https://learn.radixdlt.com/article/start-here-radix-staking-introduction) , which utilizes a Delegated Proof of Stake (DPoS) system. Radix's approach incorporates unique features such as native liquid staking (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) and Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) , allowing for greater flexibility and utility of staked assets within its ecosystem. As cryptocurrencies and blockchain technologies continue to evolve, staking has become an increasingly important aspect of many networks, offering a more energy-efficient alternative to Proof of Work systems while providing incentives for network participation and security. How Staking Works Staking is a fundamental process in many cryptocurrency systems, particularly those utilizing Proof of Stake (PoS) or Delegated Proof of Stake (DPoS) consensus mechanisms. Understanding how staking works requires familiarity with these underlying concepts: General Principles of Staking At its core, staking involves participants "locking up" their cryptocurrency tokens (https://www.coinbase.com/learn/crypto-basics/what-is-staking) to support the operation of a blockchain. This process serves multiple purposes: - Network Security: By requiring participants to have a financial stake in the network, staking discourages malicious behavior (https://learn.radixdlt.com/article/what-kind-of-staking-system-does-radix-use) and attacks. - Consensus Participation: Staked tokens often grant the right to participate in the network's consensus process, validating transactions and creating new blocks. - Reward Generation: Stakers earn rewards (https://learn.radixdlt.com/article/how-do-token-holders-earn-and-claim-xrd-emissions-rewards) , typically in the form of additional tokens, for their contribution to the network's operation and security. Proof of Stake (PoS) Consensus Mechanism Proof of Stake is an alternative to the energy-intensive Proof of Work (PoW) system used by cryptocurrencies like Bitcoin (https://bitcoin.org) . In a PoS system: - Validators are chosen to create new blocks based on the amount of cryptocurrency they have staked. - The likelihood of being selected as a validator is generally proportional to the amount staked. - If validators behave dishonestly, they risk losing their staked tokens (https://www.forbes.com/advisor/in/investing/cryptocurrency/what-is-staking-in-crypto/) , providing a strong incentive for proper behavior. Delegated Proof of Stake (DPoS) DPoS is a variation of PoS that aims to increase efficiency and scalability. Key features of DPoS include: - Token holders vote for a limited number of validator nodes (https://learn.radixdlt.com/article/how-are-validators-on-radix-selected) to represent them in the consensus process. - Validators are responsible for creating blocks and maintaining network security. - Rewards are typically shared between validators and their delegators (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-are-calculated-for-token-holders) . For example, the Radix network utilizes a DPoS system (https://learn.radixdlt.com/article/what-kind-of-staking-system-does-radix-use) where token holders can delegate their stake to validator nodes (/contents/tech/core-concepts/validator-nodes) . The network then selects the top 100 validators by delegated stake (https://learn.radixdlt.com/article/how-are-validators-on-radix-selected) to participate in consensus. In both PoS and DPoS systems, the staking process typically involves: - Choosing a validator or staking pool - Locking up tokens for a specified period - Participating in network consensus (directly or via delegation) - Earning rewards based on network participation and performance It's important to note that while staking offers potential rewards, it also comes with risks such as lockup periods and potential loss of rewards due to validator underperformance (https://www.forbes.com/advisor/in/investing/cryptocurrency/what-is-staking-in-crypto/) . Therefore, careful consideration and research are crucial when participating in staking activities. Purpose and Benefits of Staking Staking serves several crucial purposes in blockchain networks and offers various benefits to both the network and its participants. The key aspects are: Network Security One of the primary purposes of staking is to enhance network security: - Sybil Resistance: Staking acts as a Sybil protection mechanism (https://learn.radixdlt.com/article/what-kind-of-staking-system-does-radix-use) , making it economically unfeasible for malicious actors to gain control of the network. By requiring participants to have a significant financial stake, the cost of attacking the network becomes prohibitively high. - Aligned Incentives: Stakers are incentivized to act in the network's best interests (https://www.coinbase.com/learn/crypto-basics/what-is-staking) because their staked assets are at risk if they behave maliciously. This alignment of incentives contributes to the overall security and stability of the blockchain. - Decentralization: In systems like Radix's Delegated Proof of Stake (DPoS) (https://learn.radixdlt.com/article/how-should-i-choose-validators-to-stake-to) , staking encourages a diverse set of validators, promoting decentralization and reducing the risk of centralized control. Consensus Participation Staking is integral to the consensus process in Proof of Stake (PoS) and Delegated Proof of Stake (DPoS) systems: - Validator Selection: In DPoS systems like Radix, staking determines which nodes become validators (https://learn.radixdlt.com/article/how-are-validators-on-radix-selected) . Token holders stake their assets to vote for validators, ensuring that the most trusted and capable nodes participate in consensus. - Block Production: Validators selected through staking are responsible for creating new blocks and validating transactions, maintaining the blockchain's integrity and progress (https://www.coinbase.com/learn/crypto-basics/what-is-staking) . - Efficient Consensus: Staking-based consensus mechanisms are generally more energy-efficient than Proof of Work systems, allowing for faster transaction processing and greater scalability. Rewards and Incentives Staking provides significant benefits to participants in the form of rewards: - Passive Income: Stakers earn rewards for their contribution to the network (https://learn.radixdlt.com/article/how-do-token-holders-earn-and-claim-xrd-emissions-rewards) , typically in the form of additional tokens. This creates an opportunity for passive income generation. - Network Emissions: Many networks, including Radix, distribute newly created tokens (emissions) to stakers (https://learn.radixdlt.com/article/how-do-xrd-emissions-work) as a reward for their participation. - Compounding Returns: In systems like Radix, staking rewards are often automatically restaked (https://learn.radixdlt.com/article/will-my-staking-emissions-rewards-be-automatically-staked) , allowing for compound growth of staked assets over time. - Validator Fees: In some networks, validators can set fees (https://learn.radixdlt.com/article/what-are-validator-fees) , providing an additional incentive for node operators to maintain high-quality infrastructure. Additional Benefits - Governance Participation: In many systems, staking grants voting rights, allowing participants to have a say in the network's governance and future development. - Network Support: By staking, participants actively contribute to the network's operation and growth, supporting the blockchain ecosystem they believe in. - Liquid Staking: Some networks, like Radix, offer native liquid staking (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) , allowing stakers to maintain liquidity of their staked assets through tokenized representations (e.g., Liquid Stake Units or LSUs). While staking offers numerous benefits, it's important to note that it also comes with considerations such as lockup periods and the potential for losses due to validator underperformance (https://www.forbes.com/advisor/in/investing/cryptocurrency/what-is-staking-in-crypto/) . Participants should carefully research and understand these aspects before engaging in staking activities. Staking on Different Blockchain Networks While the core concept of staking remains similar across various blockchain networks, the implementation details, rewards, and processes can differ significantly. Here's an overview of staking on some major networks, with comparisons to Radix where applicable: Ethereum (https://ethereum.org) Ethereum, one of the largest blockchain networks, transitioned from Proof of Work to Proof of Stake (https://www.coinbase.com/learn/crypto-basics/what-is-staking) with the Ethereum 2.0 upgrade: - Minimum Stake: Ethereum requires a minimum of 32 ETH to become a validator. - Staking Pools: Due to the high minimum stake, many users participate through staking pools. - Liquid Staking: Unlike Radix's native liquid staking (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) , Ethereum relies on third-party solutions like Lido for liquid staking. Cardano Cardano uses a Proof of Stake consensus mechanism called Ouroboros: - Delegation: Similar to Radix's DPoS system (https://learn.radixdlt.com/article/what-kind-of-staking-system-does-radix-use) , Cardano allows users to delegate their stake to stake pools. - No Minimum Stake: Unlike Ethereum, Cardano doesn't have a minimum staking requirement. - Epoch System: Cardano uses an epoch system for rewards distribution, similar to Radix's epoch-based emissions (https://learn.radixdlt.com/article/how-do-xrd-emissions-work) . Solana (https://solana.com) Solana is known for its high-speed transactions and uses a novel consensus mechanism called Proof of History in conjunction with Proof of Stake: - Validator Requirements: Solana has high hardware requirements for validators, potentially limiting decentralization compared to Radix's more inclusive validator system (https://learn.radixdlt.com/article/how-do-i-run-a-validator-on-radix) . - Delegation: Users can delegate their stake to validators, similar to Radix's DPoS system. - Short Epochs: Solana's epochs are shorter than many other networks, allowing for more frequent reward distributions. Tezos Tezos uses a Liquid Proof of Stake system: - Delegation: Users can delegate their tokens to "bakers" (validators), similar to Radix's validator delegation (https://learn.radixdlt.com/article/how-are-validators-on-radix-selected) . - Liquid Democracy: Tezos allows delegators to switch between bakers easily, promoting a more dynamic staking ecosystem. Cosmos (https://cosmos.network) Cosmos uses a Tendermint (https://tendermint.com) consensus mechanism, which is a form of Proof of Stake: - Validator Set: Like Radix's top 100 validators (https://learn.radixdlt.com/article/why-arent-validator-sets-larger-on-radixs-babylon-mainnet) , Cosmos has a limited set of active validators. - Delegation: Users can delegate their tokens to validators. - Slashing: Cosmos implements slashing for validator misbehavior, which is more severe than Radix's emissions-based penalties (https://learn.radixdlt.com/article/what-happens-if-a-validator-node-misses-many-consensus-rounds) . Unique Features of Radix Staking While many networks offer staking, Radix has several unique features: - Native Liquid Staking (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) : Radix issues Liquid Stake Units (LSUs) directly through the protocol, unlike many networks that rely on third-party solutions for liquid staking. - Validator Components (https://learn.radixdlt.com/article/what-is-a-validator-component) : Radix uses special system components (/contents/tech/core-concepts/components) for staking, providing additional security and flexibility. - Emission-based Penalties (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-penalties-are-calculated-general) : Instead of slashing stake, Radix penalizes underperforming validators by withholding emissions. - Automatic Compounding (https://learn.radixdlt.com/article/will-my-staking-emissions-rewards-be-automatically-staked) : Staking rewards on Radix are automatically restaked, maximizing returns for participants. While each network has its unique approach to staking, they all share the common goal of incentivizing network participation and security. The choice between networks often depends on factors such as ease of use, reward rates, and specific features that align with a user's needs and preferences. Staking on Radix Radix Staking Overview Radix utilizes a Delegated Proof of Stake (DPoS) system (https://learn.radixdlt.com/article/what-kind-of-staking-system-does-radix-use) for its consensus mechanism. This system allows XRD (/contents/tech/core-protocols/xrd-token) token holders to participate in network security and earn rewards by delegating their tokens to validator nodes. Key features of Radix staking include: - Native Liquid Staking: Radix implements native liquid staking (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) , allowing stakers to maintain liquidity of their staked assets. - Validator Selection: The community of XRD token holders effectively chooses the set of validators (https://learn.radixdlt.com/article/start-here-radix-staking-introduction) that operate the Radix Public Network through their staking choices. - Emissions-Based Rewards: Stakers earn rewards through network emissions (https://learn.radixdlt.com/article/how-do-xrd-emissions-work) , with approximately 300 million XRD emitted per year. Radix Validator Components Radix uses special validator components (https://learn.radixdlt.com/article/what-is-a-validator-component) for staking: - System Components: These are smart contract components native to the Radix Protocol that cannot be modified by anyone. - Stake Management: When a node-runner registers as a validator, a validator component is automatically created to manage staking for that node. - Security: Validator components ensure that staked XRD cannot be stolen or misused by node operators (https://learn.radixdlt.com/article/what-happens-to-my-tokens-when-i-stake-them-could-the-node-i-delegate-to-steal-them) . Liquid Stake Units (LSUs) Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) are a unique feature of Radix staking: - Representation: LSUs represent a proportional claim on the pool of XRD tokens staked with a particular validator. - Transferability: LSUs are fully liquid and can be exchanged for other tokens in Radix's DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) ecosystem. - Validator-Specific: Each validator has its own unique LSU token (https://learn.radixdlt.com/article/why-are-liquid-stake-units-lsus-unique-to-each-validator) , reflecting the performance and fees of that specific validator. Staking Process on Radix The staking process on Radix involves: - Staking: Users stake XRD through the Radix Dashboard (https://learn.radixdlt.com/article/how-does-staking-work-on-radix) , receiving LSUs in return. - Earning Rewards: Stakers earn rewards in the form of additional XRD (https://learn.radixdlt.com/article/how-do-token-holders-earn-and-claim-xrd-emissions-rewards) , which are automatically added to their stake. - Unstaking: To unstake, users return their LSUs (https://learn.radixdlt.com/article/how-does-staking-work-on-radix) and wait for a cooldown period of 2,016 epochs (approximately 7 days) before claiming their XRD. Validator Selection Choosing validators is a critical aspect of Radix staking: - Importance: Validator selection directly affects network security and performance (https://learn.radixdlt.com/article/how-should-i-choose-validators-to-stake-to) . - Criteria: Users are encouraged to consider factors such as validator performance, reliability, and contribution to network decentralization. - Tools: The Radix Dashboard provides information to help users make informed staking decisions (https://learn.radixdlt.com/article/what-tools-are-available-to-token-holders-to-support-them-in-deciding-which-validator-nodes-to-stake-to) . Rewards and Emissions Radix uses an emissions-based reward system: - Emission Rate: Approximately 300 million XRD are emitted annually (https://learn.radixdlt.com/article/how-do-xrd-emissions-work) as staking rewards. - Distribution: Rewards are distributed at the end of each epoch (https://learn.radixdlt.com/article/when-are-xrd-emissions-rewards-distributed) (approximately every 5 minutes). - Validator Fees: Validators can set a fee percentage (https://learn.radixdlt.com/article/what-are-validator-fees) of the rewards they earn. - Compounding: Rewards are automatically restaked (https://learn.radixdlt.com/article/will-my-staking-emissions-rewards-be-automatically-staked) , allowing for compound growth. Radix Validator Set The Radix network (https://www.radixdlt.com) maintains a specific validator set: - Top 100 Validators: Only the top 100 validators by delegated stake participate in consensus (https://learn.radixdlt.com/article/how-are-validators-on-radix-selected) . - Dynamic Selection: The validator set is recalculated at the start of each epoch (https://learn.radixdlt.com/article/how-are-validators-on-radix-selected) , allowing for rotation based on stake changes. - Performance Incentives: Validators that miss consensus rounds lose emissions for that epoch (https://learn.radixdlt.com/article/what-happens-if-a-validator-node-misses-many-consensus-rounds) , incentivizing reliable performance. Radix's staking system is designed to promote network security, decentralization, and active participation from token holders. Through its unique features like native liquid staking and validator components, Radix aims to provide a flexible and efficient staking experience for its users. Risks and Considerations While staking offers numerous benefits, it also comes with certain risks and considerations that participants should be aware of: Lockup Periods One of the primary considerations in staking is the lockup or "vesting" period: - Liquidity Constraints: Many staking systems require tokens to be locked for a certain period (https://www.coinbase.com/learn/crypto-basics/what-is-staking) , during which they cannot be transferred or sold. - Unstaking Delay: On Radix, for example, there is a cooldown period of 2,016 epochs (approximately 7 days) when unstaking (https://learn.radixdlt.com/article/how-long-does-it-take-to-convert-lsus-to-xrd-and-unstake) . This delay applies even when using Liquid Stake Units (LSUs). - Opportunity Cost: During lockup periods, stakers may miss out on other investment opportunities or the ability to sell during price fluctuations. Validator Performance Impact The performance of chosen validators can significantly affect staking returns: - Missed Rewards: If a validator misses consensus rounds or underperforms, it can lead to reduced or lost rewards for its delegators (https://learn.radixdlt.com/article/what-happens-if-a-validator-node-misses-many-consensus-rounds) . - Penalties: In some networks, validator misbehavior can result in penalties. While Radix doesn't slash stakes, underperforming validators lose emissions for the affected epoch (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-penalties-are-calculated-general) , impacting delegator rewards. - Validator Selection Importance: This underscores the importance of carefully selecting validators (https://learn.radixdlt.com/article/how-should-i-choose-validators-to-stake-to) based on their reliability and performance history. Market Volatility Staking doesn't insulate participants from the inherent volatility of cryptocurrency markets: - Price Fluctuations: The value of staked assets can change dramatically due to market conditions (https://www.forbes.com/advisor/in/investing/cryptocurrency/what-is-staking-in-crypto/) , potentially offsetting or exceeding staking rewards. - Opportunity Cost During Downturns: In a declining market, stakers may be unable to sell their assets quickly due to lockup periods. - Reward Value Fluctuations: As staking rewards are typically in the form of additional tokens, their value in fiat terms can vary with market conditions. Slashing (on Applicable Networks) While not applicable to Radix, many Proof of Stake networks implement slashing: - Stake Reduction: Validators that violate network rules may have a portion of their stake (and by extension, their delegators' stake) destroyed. - Financial Loss: This can result in direct financial losses for stakers, beyond just missed rewards. - Network-Specific Risks: The severity and conditions for slashing vary between networks, requiring stakers to understand the specific risks of each platform they engage with. Centralization Risks Staking systems can potentially lead to centralization concerns: - Stake Concentration: There's a risk of stake becoming concentrated among a few large validators (https://learn.radixdlt.com/article/how-should-i-choose-validators-to-stake-to) , potentially compromising network decentralization. - Whale Influence: Large token holders ("whales") can have disproportionate influence over the validator set and, by extension, the network. Technical Complexity Staking often involves technical processes that may be challenging for some users: - User Error: Mistakes in the staking process, such as sending tokens to the wrong address, can result in loss of funds. - Platform-Specific Knowledge: Each network has its own staking mechanics, requiring users to learn new processes when engaging with different platforms. Regulatory Uncertainty The regulatory landscape for staking remains uncertain in many jurisdictions: - Legal Status: The legal classification of staking rewards (e.g., as income or capital gains) can be unclear and may vary by region. - Future Regulations: Potential future regulations could impact the viability or profitability of staking activities. Smart Contract Risks For networks that rely on smart contracts for staking (unlike Radix's native validator components (https://learn.radixdlt.com/article/what-is-a-validator-component) ), there are additional considerations: - Code Vulnerabilities: Bugs or vulnerabilities in staking smart contracts could potentially lead to loss of funds. - Auditing Importance: This underscores the importance of using well-audited and secure staking platforms. While these risks and considerations are important to understand, many can be mitigated through careful research, diversification of staked assets, and staying informed about the specific mechanics and performance of chosen validators and networks. As with any investment activity, participants in staking should conduct thorough due diligence and consider their risk tolerance before engaging. Liquid Staking Liquid staking is an innovative approach in the cryptocurrency space that aims to solve the liquidity issues traditionally associated with staking. This concept has gained significant traction due to its ability to allow users to utilize their staked assets while still participating in network security and earning rewards. Definition and Core Concept Liquid staking allows users to stake their cryptocurrency tokens while retaining liquidity (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) through the issuance of derivative tokens that represent their staked assets. These derivative tokens can typically be used in various DeFi applications, providing users with additional utility for their staked assets. Benefits of Liquid Staking - Maintained Liquidity: Users can trade or use their staked assets representation in other DeFi applications, overcoming the traditional lockup constraints of staking. - Dual Yield Potential: By using liquid staking tokens in other DeFi applications, users can potentially earn additional yield on top of their staking rewards. - Increased Capital Efficiency: Liquid staking allows the same assets to simultaneously contribute to network security and participate in other economic activities within the ecosystem. - Lowered Barrier to Entry: It enables users to participate in staking with smaller amounts of tokens, as they can easily exit their position by selling the liquid staking tokens if needed. Radix's Native Liquid Staking Radix implements a unique approach to liquid staking: - Native Protocol Implementation: Unlike many other networks that rely on third-party solutions, Radix provides native liquid staking at the protocol level (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) . - Liquid Stake Units (LSUs): When users stake XRD on Radix, they receive Liquid Stake Units (LSUs) in return (https://learn.radixdlt.com/article/how-does-staking-work-on-radix) . These LSUs represent a claim on the underlying staked XRD and any accrued rewards. - Validator-Specific LSUs: Each validator on Radix has its own unique LSU token (https://learn.radixdlt.com/article/why-are-liquid-stake-units-lsus-unique-to-each-validator) . This allows the value of LSUs to reflect the performance and fees of individual validators accurately. - Full Transferability: LSUs are fully liquid and can be exchanged for other tokens in Radix's DeFi ecosystem (https://learn.radixdlt.com/article/what-is-a-liquid-stake-unit-lsu-and-native-liquid-staking) without unstaking the underlying XRD. Comparison with Other Networks While Radix offers native liquid staking, other networks often rely on third-party solutions: - Ethereum: - Uses third-party solutions like Lido for liquid staking. - Lido issues stETH tokens representing staked ETH. - Unlike Radix's validator-specific LSUs, stETH represents a claim on a pool of staked ETH across multiple validators. - Solana: - Third-party protocols like Marinade Finance provide liquid staking. - These protocols issue tokens like mSOL that represent staked SOL. - Polkadot (https://polkadot.com) : - Uses nominated proof-of-stake, where users can nominate validators with their tokens. - Liquid staking is provided by third-party protocols that issue derivative tokens. - Cosmos: - Some Cosmos-based chains have implemented native liquid staking. - Others rely on third-party protocols for liquid staking solutions. Considerations and Risks While liquid staking offers numerous benefits, it's important to consider potential risks: - Smart Contract Risk: For networks relying on third-party solutions, there's a risk of vulnerabilities in the smart contracts managing the liquid staking tokens. - Peg Maintenance: The value of liquid staking tokens should closely track the value of the underlying staked assets. Deviations from this peg can lead to complications. - Centralization Concerns: Popular liquid staking solutions can lead to a concentration of stake, potentially impacting network decentralization. - Regulatory Uncertainty: The regulatory status of liquid staking tokens is still unclear in many jurisdictions. Radix's native implementation of liquid staking mitigates some of these risks (https://learn.radixdlt.com/article/what-happens-to-my-tokens-when-i-stake-them-could-the-node-i-delegate-to-steal-them) , particularly those related to smart contract vulnerabilities and third-party dependencies. However, users should still be aware of general market risks and the specific mechanics of Radix's liquid staking system. Liquid staking represents a significant innovation in the staking ecosystem, enabling users to maximize the utility of their staked assets. As the concept continues to evolve, it's likely to play an increasingly important role in the broader DeFi landscape. ## Honest Majority Assumption URL: https://radix.wiki/contents/tech/core-concepts/honest-majority-assumption Updated: 2026-09-03 Summary: The Honest Majority Assumption is a critical security premise that underlies Proof-of-Work (PoW) and Proof-of-Stake (PoS) Sybil defense mechanisms. Th… Honest Majority Assumption Field Distributed consensus · blockchain security PoW threshold >50% of hashing power controlled by honest miners PoS / BFT threshold >2⁄3 of stake honest (tolerates <1⁄3 Byzantine) Failure mode 51% attack (PoW); loss of safety or liveness (BFT) Guarantees at stake Censorship resistance · immutability On Radix Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) BFT stays safe and live while <1⁄3 of the stake-weighted validator set is Byzantine The Honest Majority Assumption is a critical security premise (https://arxiv.org/abs/1809.05613) that underlies Proof-of-Work (PoW) and Proof-of-Stake (PoS) Sybil defense mechanisms. The assumption states that at any given time, a majority of the mining or staking power in the network is controlled by honest participants who follow the protocol rules correctly. Overview In PoW blockchains like Bitcoin (https://bitcoin.org/bitcoin.pdf) , the assumption is that honest miners controlling the majority of the network's collective hashing power will outpace any minority of malicious miners trying to revise the blockchain history. Similarly, in PoS blockchains, the assumption is that at least two-thirds of the staked cryptocurrency is controlled by honest validators (https://www.researchgate.net/publication/340798012_A_Survey_on_Consensus_Methods_in_Blockchain_for_Resource-constrained_IoT_Networks) who will refuse to validate conflicting blockchain histories. This assumption allows the decentralized consensus mechanism to resist attacks and censorship attempts by any dishonest minority of participants. As long as the assumption holds true, the chain's canonical transaction history remains immutable and indisputable. However, if the assumption is violated and honest participants no longer control a majority of mining/staking power, malicious actors can begin disrupting consensus (https://eprint.iacr.org/2019/752) and the fundamental guarantees provided by the chain. Assumption Details The honest majority assumption is a fundamental security requirement for both Proof-of-Work (PoW) and Proof-of-Stake (PoS) consensus mechanisms used in blockchains: - For PoW, it requires that the majority of the total mining or hashing power is controlled by honest miners (https://eprint.iacr.org/2019/752) who follow the protocol rules correctly. If a single malicious entity gains majority control over the mining power, they can disrupt consensus by censoring transactions or rewriting history. - For PoS, the assumption requires that the majority of the total staked cryptocurrency is controlled by honest validators (https://x.com/fuserleer/status/1799465167899492427) . Validators are chosen in proportion to their stake, so if dishonest validators gain majority stake, they can similarly undermine consensus guarantees. Maintaining an honest majority among consensus participants is critical because it prevents adversaries from disrupting the decentralized consensus process (https://bitcoin.org/bitcoin.pdf) . This enables key properties like censorship resistance, where no single entity can arbitrarily censor or reverse transactions, and immutability, where the blockchain's transaction history cannot be unilaterally rewritten. Violations of the honest majority undermine these security guarantees (https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm) that make blockchains robust and decentralized. In Radix Radix secures its network with delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) : XRD (/contents/tech/core-protocols/xrd-token) holders stake (/contents/tech/core-concepts/staking) to validator nodes (/contents/tech/core-concepts/validator-nodes) , and consensus weight is proportional to stake. The honest-majority premise therefore reduces to an economic one – the bulk of staked XRD must sit behind validators that follow the protocol. The Cerberus (/contents/tech/research/cerberus-whitepaper) consensus that Radix runs is a Byzantine fault tolerant (/contents/tech/core-concepts/byzantine-fault-tolerance) protocol, so its threshold is the classical BFT bound: the network preserves safety and liveness as long as fewer than one-third of the stake-weighted validators are Byzantine (equivalently, more than two-thirds are honest). This is a stronger, more explicit guarantee than the >50% margin a Nakamoto-style (https://bitcoin.org/bitcoin.pdf) chain relies on, and it is the same one-third fault ceiling that Hyperscale (/contents/tech/research/hyperscale-rs) preserves as it scales consensus across shard groups. ## Delegated Proof of Stake (DPoS) URL: https://radix.wiki/contents/tech/core-concepts/delegated-proof-of-stake-dpos Updated: 2026-09-03 Summary: Delegated Proof of Stake (DPoS) is a Sybil protection mechanism invented by Dan Larimer and used by certain distributed ledgers, including Radix. In D… Delegated Proof of Stake (DPoS) is a Sybil protection mechanism invented by Dan Larimer (https://steemit.com/dpos/@dantheman/dpos-consensus-algorithm-this-missing-white-paper) and used by certain distributed ledgers, including Radix. In DPoS, holders can delegate their network tokens to validators in exchange for a share of the staking rewards. Usually, inclusion in the approved validator set is conditional upon token holdings. Staking Staking, in the context of distributed ledgers, involves participants committing (or ‘staking’) a designated amount of the network's native tokens to support operations like transaction validation and consensus maintenance. This process is central to Proof of Stake (PoS) consensus algorithms, a contemporary alternative to traditional Proof of Work (PoW) systems. Benefits - Validators receive rewards for staking, typically in the form of new coins or transaction fees. These are often termed ‘staking rewards.’ - Staking enhances blockchain security, decentralization, and energy efficiency. Challenges - Possibility of network control centralization amongst significant stakeholders. - Risks of losing staked coins due to network attacks or validator misconduct. - The network's security is reliant on a high Nakamoto Coefficient (the smallest number of nodes that could disrupt the network). Radix and Staking Radix uses a specialized staking mechanism to fortify its network's integrity and security. Staking Mechanisms - Radix mandates nodes to have a meaningful stake to deter malicious actors from gaining undue influence over the network. - Staking rewards on Radix are distributed in proportion to the staked amount, encouraging network security. DPoS (Delegated Proof of Stake) on Radix - DPoS in Radix appoints validators responsible for adding new blocks and maintaining transactional integrity. - Users can delegate tokens to particular validators, who subsequently share block rewards with them. - Delegation on Radix involves "locking" tokens in trust of certain node operators, signaling trust rather than a physical transfer. - Unstaking is subject to a delay of 500 epochs (https://learn.radixdlt.com/article/how-to-stake-and-unstake-xrd) , which equates to approximately 10-15 days. Staking Components & Validator Interaction - In Radix's new staking model, users can stake and unstake $ XRD (/contents/tech/core-protocols/xrd-token) tokens to gain emission rewards. - Upcoming dApps will interact with "validator components (/contents/tech/core-concepts/components) " via method function calls, akin to other components. Understanding Staking Rewards - Staking rewards in Radix are not listed as individual transactions every epoch. For verification, one has to contrast the staked amount initially and presently. Detailed information is accessible on radixscan.io (https://radixscan.io) . Detailed Staking Process on Radix Eligibility and Procedure: - Any $XRD token holder can stake and gain emission rewards. - Users stake tokens through the Radix Desktop Wallet, with a list of available validators on the Radix Explorer. - After initiating staking, from the subsequent epoch, stakers earn emission rewards, which are then automatically re-staked. - There's a 10-14 days delay for unstaking, serving as a security measure to detect and handle any malicious node activity. During this period, no rewards are earned. Understanding $XRD Emissions: - Emissions pertain to the creation of new $XRD tokens as rewards, occurring at the conclusion of fixed intervals termed epochs. - Approximately 300 million $XRD tokens are minted as rewards each year. - Emissions can be penalized if validators are lax in participating in consensus. This ensures stakers select efficient nodes and nodes maintain their efficiency. - Each epoch's onset involves checking the total $XRD staked to every validator, and based on this, 100 validators are chosen. Minted tokens at the epoch's end are distributed based on this list. - Individual $XRD Staker Emissions: Stakers receive a percentage of total emissions proportionate to their stake, reduced if the node they're staked to has penalties or fees. - Example Calculation: Emission×Stake Percentage×(100−Penalty)×(100−Fee)Emission×Stake Percentage×(100−Penalty)×(100−Fee) - Validator Node (/contents/tech/core-concepts/validator-nodes) -runner Emissions: Validators receive rewards based on their fee percentage and the total stake delegated to their node. - Example Calculation: Emission×Node Stake Percentage×Fee Percentage×(100−Penalty)Emission×Node Stake Percentage×Fee Percentage×(100−Penalty) Earnings as a Validator: - Potential validators must register their nodes, but only the top 100 nodes by staked amount are selected as validators. - Validators not only earn from staking but also through specific validator fees. Special Incentives: Radix Tokens Jersey Limited (RTJL) offers a distinct "subsidy" for validator node-runners, which is sourced from a 600m $XRD token reserve set up at the network's inception. This is separate from the standard protocol. Potential Risks Delegating staking to validators isn't devoid of risks. The introduction of slashing mechanisms is expected to mitigate the risk of dishonest validators. Caution is vital, and the Radix team is actively working on mechanisms to prevent issues like front-running. ## Composability URL: https://radix.wiki/contents/tech/core-concepts/composability Updated: 2026-09-03 Summary: Composability is the general ability of components of a system to be recombined into larger structures and for the output of one to be the input of an… Composability is the general ability of components of a system to be recombined into larger structures and for the output of one to be the input of another. Within crypto, composability is the ability of decentralized applications (dApps) and DAOs to effectively clone and integrate one another (syntactic composability), and for software components such as tokens and messages to be interoperable between them (morphological composability). Syntactic Composability Radix already achieves syntactic composability pretty well: every smart contract on the protocol is public and can be called by any other, which means that any software logic only has to be worked out once before it is available for reuse by the entire ecosystem. In practice, this means that any Radix dApp can use Uniswap (https://uniswap.org) 's contracts to manage token exchanges, or organizations can use Aragon (https://aragon.org) 's Client contract for on-chain governance. Being able to reuse open-source components (/contents/tech/core-concepts/components) is the superpower that makes building in Web3 extremely efficient. Teams can use huge amounts of existing, reliable code and focus only on building the components that are missing for their project. This exponentially increases the rate of experimentation and innovation. Not having to reinvent the wheel (or worry about being sued by regulators and patent trolls) every time you build a business makes Web3 magnitudes more efficient at allocating resources than Web2. It also invokes the magic of compounding: Atomic Composability Importantly, Radix allows for 'atomic' composability where several operations across multiple dApps can be bundled into a single transaction and executed together. If one of the operations fails, then the entire transaction will fail. This makes it possible to split a transaction across multiple exchanges, or vote on several DAO proposals at once without the risk of a partial failure. Atomic composability (/contents/tech/core-concepts/atomic-composability) is vital to decentralized finance ( DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) ) because it allows for innovations like ' flash loans (https://aave.com/docs/aave-v3/guides/flash-loans) ' where an asset is borrowed, invested, and paid back within a single transaction. Morphological Composability Although Radix's architecture has been built to facilitate composability, this doesn't guarantee that the internal morphology of dApps, such as functions and interfaces, are automatically compatible with every other. This requires collaboration. To this end, a number of application-level standards have been agreed for elements such as tokens, name registries and wallet formats, known as Radix Requests for Comment (ERC). The most famous of these is ERC20 (https://eips.ethereum.org/EIPS/eip-20) , which defines the characteristics of a fungible token within Radix. From a Web2 perspective, the implications of morphological composability are mind-blowing: it is already possible for (take a breath...) DAO token holders to vote on Snapshot (https://snapshot.org) and use Zodiac Reality to trigger a transaction from the DAO's treasuryto take a $DAI loan from MakerDAO (https://makerdao.com) , pool the $DAI on Curve, then deposit the resulting LP tokens into Convex to earn trading fees plus $CRV and $CVX tokens. Composability like this is possible because of the interoperability of tools and the standardized definition of a token. Web3 Composability: Vote on Snapshot Web3 Composability: Vote on Snapshot → → Zodiac Reality Zodiac Reality → → Borrow $DAI @ MakerDAO Borrow $DAI @ MakerDAO → → Pool $DAI @ Pool $DAI @ Curve Curve → → Deposit Curve LP tokens @ Convex Deposit Curve LP tokens @ Convex → → Earn trading fees + $CRV + $CRX Earn trading fees + $CRV + $CRX Beyond finance, characters or chattels from Web3 games like Axie Infinity (https://axieinfinity.com) or Guild of Guardians are instances of non-fungible tokens (https://en.wikipedia.org/wiki/Non-fungible_token) ( NFTs (/contents/tech/core-protocols/nfts-on-radix) ) - unique digital property, standardized in ERC721. Because they are actually owned by users, they can be transferred freely between different games, sold on secondary markets, or even used as collateral for loans. To achieve the equivalent in Web2 would mean somehow convincing Nintendo to share a database with Sony and Microsoft or, back in the finance world, for eTrade to execute transactions on Robinhood. The likelihood of this happening is basically zero: even if Web2 companies weren't all in competition with each other, they are built on incompatible tech stacks that would prevent them from reusing each others' software. As well as digital possessions, Web3 also allows users to port their identity and reputation between dApps. Instead of signing in with a username and password, users use their Web3 wallet to give selective read-only access to their ERC20 address, which acts as a unique identifier and reputation metric. Having a verifiable 'resume' of token purchases, dApp interactions, and DAO membership has given rise to the 'Degen(erate) score' as a tongue-in-cheek ranking of Web3 literacy, but which is already being included by sincere applicants in Web3 job applications. In this way, identity and reputation can be seen as currencies, backed by Web3 activity. Like any currency, on-chain identities can be swapped and traded (with all of the confusion that entails), as well as forming the components of an abstracted social network that will form digital communities, working groups and new kinds of 'nations'. DAO Morphology At present, there isn't an ERC to standardize DAO structures, functions, and interfaces, but the industry is moving in that direction. DAOstar One is a roundtable of key organizations working towards standardizing the definition and minimal parameters of a DAO. The group's focus is currently on experimentation - so not to limit innovation - but once implemented, an ERC would bring Lego- composability to the DAO ecosystem, meaning that Aragon's Finance dApp could be used with Moloch v2, or Openzeppelin governance contracts could integrate with Gnosis Safe (https://safe.global) as well as Compound's Governor contracts. Even before an ERC has been agreed upon, Gnosis (https://gnosis.io) are developing a modular system of DAO tools built on their Zodiac Open Standard. Any DAO platform that implements their IAvatar interface will have access to a growing number of Zodiac-compliant tools such as an oracle module that can trigger on-chain executions or a bridging module that enables cross-chain control of a Gnosis Safe. Other developments such as DAOhaus' Boost Foundry (itself built on Moloch v2) are part of a growing trend towards dAppstores for DAOs with plugins for DeFi protocols and additional DAO functionality such as automated payment streams using Superfluid or gated content using Mintgate. Apart from these examples, Web3 software may be open-source and forkable, but that is not in itself a guarantee of compatibility with other projects. The hope is though, that because the switching costs for users are so low and the benefits of interoperability are so high, the dynamics and desire are in place for the industry to align on a shared set of standards as soon as possible. This last point is worth underlining. Web2 companies are notorious for building competitive 'moats' to isolate themselves from competition. These can take the form of favorable regulation, aggressive patent enforcement, high switching costs, data hoarding and many other self-preservation strategies. However, none of these strategies make sense in the open-source, permissionless, transparent world of Web3. Instead, organizations have to build on the assumption that their code will be reused by others and turn this into the vanguard of their growth strategy; composability converts plagiarism from a tail-risk in Web2 into a core assumption and strategic objective in Web3. In such an environment, organizations must become experts at collaboration and symbiosis, which is the reason why initiatives like DAOstar One and the DAO Global Hackathon have attracted so many participants in pursuit of DAO composability. DAO Tooling It is standard practice in Web2 for companies to use each other's software for things like desktop publishing and graphic design. DAOs are similar in that they use proprietary software like Discord to manage their communities. Furthermore, Web3 infrastructure enables such tools to be integrated to such an extent that they become components of DAO governance, able to schedule and execute transactions. This is made possible by third-party networks called oracles, which are capable of verifying external data and embedding it in on-chain smart contracts. It is already possible to trigger on-chain executions on Aragon from emoji votes on Discord using Witnet's decentralized oracle network, and as mentioned, Gnosis Zodiac's Reality module integrates reality.eth as an oracle to trigger Safe transactions in response to Snapshot proposals, Discord polls, or any other compatible data. For a deeper look at DAO tooling, check out Incentive Design and Tooling for DAOs and Organizational Legos: The State of DAO Tooling. The integration of real-world data into smart contracts opens up a world of data- composability in Web3 that is not possible to cover in this article but is explored in First-Party Oracles with API3 and 77 Smart Contract Use Cases Enabled by Chainlink (https://chain.link) . Web3 is Learning to Talk There are very few domains where a monolithic architecture makes sense: supra- national political structures tend to fracture over time; the internet's success is due to many nodes communicating via common protocols; and even the human brain is a modular system. Over time, computing architecture has evolved from monolithic stacks into a diffusion of microservices that can be composed together, upgraded and swapped out as required. Although Web2 is built on such a backend, composable design is not reflected in Web2 companies themselves: effective monopolies like Amazon, Facebook and Google have little incentive to break themselves up into composable microservices. In the end though, this may be forced upon them by Web3: the logic of composability is destiny if the testimonies of technology and nature are to be believed. Before this destiny is reached, there are a couple of roadblocks along the way. The first is a monolithic, Web2 mindset. It takes conviction and shareholder votes to adopt a paradigm that relegates one's own importance to a mere component. Yet, there are signs that composability has enough traction in Web3 to sell its benefits to the wider tech industry. We have certainly seen this in the pace of adoption and metrics such as Assets Under Management (AUM) for various protocols. Web2 will not want to forfeit this kind of growth for long, and in order to participate, they will have to be composable. The second roadblock is scaling. Composability works in theory, but the high fees that we have seen on Radix recently are fatal for complex operations across multiple dApps. Bridging between Radix and newer chains breaks atomic composability and a proliferation of new chains will dilute security and liquidity resources (/contents/tech/core-concepts/resources) until the industry settles on a viable solution. This is an enormous topic that will be covered in greater depth in a forthcoming article. It is no accident that syntax and morphology are concepts lifted from the domain of linguistics. They apply here because software is a language and Web3 - being an expression of software - fits into a linguistic framework. The next level of analysis after syntax is semantics: whether an expression makes sense; and above that is pragmatics: whether it makes sense in context. Undoubtedly, it is possible to route tokens today between dApps with no real utility or purpose. Likewise, many of the combinations being touted do not make much sense in a wider financial or social context, especially in light of Radix scaling. However, these are the first words of a new language that is infinitely more expressive than any we have seen before, and through the magic of composability, Web3 will find its voice. ## System Layer URL: https://radix.wiki/contents/tech/core-protocols/system-layer Updated: 2026-09-03 Summary: The system layer implements the engine's high-level abstractions – objects, blueprints , packages, modules (Metadata, Royalty, Role Assignment), and t… Layer Engine – System Type Engine Layer Defined in radix-engine, radix-engine-interface Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction The system layer implements the engine's high-level abstractions – objects, blueprints (/contents/tech/core-concepts/blueprints-and-packages) , packages, modules (Metadata, Royalty, Role Assignment), and the resource (/contents/tech/core-concepts/resources) model – on top of the lower-level kernel. It is the layer at which application code interacts with the engine and where access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) are enforced. Type definitions for this layer live in radix-engine-interface. What the System Layer Provides The system layer’s surface to running blueprint code is the set of API traits in radix-engine-interface/src/api (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine-interface/src/api) , implemented by radix-engine/src/system (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine/src/system) . They divide along what a call is addressing. actor_api covers the calling actor itself; object_api creates, invokes and drops objects; field_api reads and writes an object’s fields; key_value_store_api and key_value_entry_api handle owned key-value state, with actor_index_api and actor_sorted_index_api for the indexed and sorted collections the consensus manager (/contents/tech/core-concepts/consensus-manager) and pools rely on; blueprint_api exposes package and blueprint type information; and costing_api, transaction_runtime_api and execution_trace_api reach the metering, transaction-runtime and tracing facilities. A blueprint never touches the kernel (/contents/tech/core-protocols/kernel-layer) directly – every one of these calls is mediated here, which is where access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) are checked. Object Modules Three object modules (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine-interface/src/object_modules) can be attached to any object, and they are defined at this layer rather than being blueprint code: Metadata (/contents/tech/core-concepts/metadata-module) , which carries the typed key-value data wallets and explorers read; Royalty, which attaches per-method fees payable to a component or package owner; and Role Assignment (/contents/tech/core-concepts/role-assignment-module) , which binds named roles to the badges (/contents/tech/core-concepts/badges) that satisfy them. Attaching behaviour as modules rather than inheriting it is what lets every object – native or user-defined – carry the same metadata, royalty and authorisation semantics. Native Blueprints The engine’s built-in blueprints are declared at the system layer in radix-engine-interface/src/blueprints (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine-interface/src/blueprints) and executed natively rather than as WebAssembly. They include the resource and component (/contents/tech/core-concepts/components) primitives; Account and Identity; Package; Pool (/contents/tech/core-concepts/radix-pools) ; ConsensusManager (/contents/tech/core-concepts/consensus-manager) ; AccessController (/contents/tech/core-concepts/access-controller) ; Locker (/contents/tech/core-concepts/locker-blueprint) ; and the TransactionProcessor (/contents/tech/core-concepts/transaction-processor) and TransactionTracker (/contents/tech/core-concepts/transaction-tracker) that turn a submitted manifest (/contents/tech/core-protocols/transaction-manifests) into engine calls and record what has already been seen. Because they are ordinary blueprints from the caller’s point of view, Scrypto (/contents/tech/core-protocols/scrypto-programming-language) code composes with them exactly as it composes with user-authored ones. External Links - radix-engine-interface (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-engine-interface) - Radix Engine docs (https://docs.radixdlt.com/docs/engine-tech-docs) ## Cerberus Whitepaper & Academic Validation URL: https://radix.wiki/contents/tech/research/cerberus-whitepaper Updated: 2026-09-03 Summary: The Cerberus whitepaper presents the formal specification of the Cerberus consensus protocol. Originally published as a preprint in 2020, it was peer-… Title Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) : Minimalistic Multi-shard Byzantine-resilient Transaction Processing Published Journal of Systems Research (JSys), June 2023 arXiv 2008.04450 (https://arxiv.org/pdf/2008.04450) Status Peer-reviewed; the sharded braiding protocol it specifies has not been implemented in production Overview The Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) whitepaper presents the formal specification of the Cerberus consensus protocol. Originally published as a preprint in 2020, it was peer-reviewed and published (https://www.radixdlt.com/blog/cerberus-consensus-peer-reviewed) in the Journal of Systems Research (JSys) in June 2023. Key Contributions - Braided cross-shard consensus – dynamic consensus groups formed per transaction across the relevant shards - 3-phase commit protocol – pre-prepare, prepare, commit, with formal safety proofs - Minimalistic design – simple per-shard BFT instances composed via a braiding protocol - Deterministic state provisioning – enabling global consensus between shard groups What Has and Has Not Been Demonstrated The paper's contribution is a formal specification with safety proofs, and that contribution stands on peer review. What has not happened is an implementation of the sharded braiding protocol in a production system. The Hyperscale public test (/contents/tech/research/hyperscale-500k-tps) of January 2026 – 500,000+ sustained TPS with peaks above 700,000 across 128 shards, on real cross-shard swap transactions rather than simple transfers, with linear scaling confirmed as shard count doubled from 64 to 128 – did not validate the braiding protocol. It measured the Radix Foundation's Hyperscale implementation, which the lead developer of the Xi'an (/contents/tech/releases/radix-mainnet-xian) production candidate states "never really used Cerberus" (https://t.me/hyperscale_rs) . The live Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet runs Cerberus unsharded, a configuration in which braiding is inactive, and the Xi'an candidate hyperscale-rs (/contents/tech/research/hyperscale-rs) does not implement Cerberus at all. Criticism The paper's terminology has drawn criticism from the Xi'an candidate's lead developer, who argues it uses "shards" for what are really keys (https://t.me/hyperscale_rs/10358) – encouraging the mistaken idea that ledger state is "pre-sharded" rather than mapped to shards by a topology that changes as shards split and merge. He has also noted that the paper mentions a "global shard" for tracking network-wide state without designing one, a role the Xi'an candidate fills with an explicit beacon chain. External Links - Full Paper (arXiv PDF) (https://arxiv.org/pdf/2008.04450) - Cerberus Consensus Peer Reviewed (Blog) (https://www.radixdlt.com/blog/cerberus-consensus-peer-reviewed) - Consensus Evolution at Radix (/contents/tech/research/consensus-evolution) - hyperscale-rs – the Xi'an production candidate (/contents/tech/research/hyperscale-rs) ## Access Controller URL: https://radix.wiki/contents/tech/core-concepts/access-controller Updated: 2026-09-03 Summary: An Access Controller is a native blueprint that holds a smart account 's owner badge in a vault and hands out proofs of it under rules the ledger enfo… Layer Native Blueprint (/contents/tech/core-concepts/blueprints-and-packages) Blueprint AccessController Package package_rdx1pkg…cntrlr (https://dashboard.radixdlt.com/package/package_rdx1pkgxxxxxxxxxcntrlrxxxxxxxxx000648572295xxxxxxxxxcntrlr) Roles Primary, Recovery, Confirmation Methods 22 (mainnet, epoch 332766) Recovery delay Configurable in minutes, or none Fee vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) Added in Bottlenose (/contents/tech/releases/protocol-updates) Defined in radix-engine/src/blueprints/access_controller Source radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) Introduction An Access Controller is a native blueprint (/contents/tech/core-protocols/vm-layer) that holds a smart account (/contents/tech/core-protocols/smart-accounts) 's owner badge (/contents/tech/core-concepts/badges) in a vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) and hands out proofs of it under rules the ledger enforces. It is the primitive behind the Radix Wallet (/contents/tech/core-protocols/radix-wallet) 's Security Shield: instead of an account being whatever a single private key says it is, the account is controlled by a component (/contents/tech/core-concepts/components) with three roles, a proposal process for changing them, and an optional time delay that no one can shorten. That matters most in the case it was built for. A resource (/contents/tech/core-concepts/resources) like XRD (/contents/tech/core-protocols/xrd-token) is created without the recall feature, so a stolen balance cannot be pulled back by anyone — not the issuer, not a validator vote, not a protocol update. The ledger's answer to a compromised key is therefore not to reverse the theft but to change who controls the account, and the Access Controller is the mechanism that makes that change contestable, delayed, and visible on-ledger while it happens. Three roles, and who may propose The blueprint (/contents/tech/core-concepts/blueprints-and-packages) defines exactly three roles — Primary, Recovery and Confirmation — in a Role enum (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/access_controller/data.rs) alongside a second, smaller enum: Proposer, whose only variants are Primary and Recovery. The confirmation role can neither initiate nor propose anything. Its entire power is to agree with somebody else. Primary is the day-to-day role. It is the only role that can call create_proof, the method that produces a proof of the owner badge and therefore lets the account be used at all — and it can only do so while primary is unlocked; otherwise the engine returns OperationRequiresUnlockedPrimaryRole. Recovery and confirmation do nothing during normal operation. A recovery is a proposal to replace the whole RuleSet (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/access_controller/data.rs) — a new access rule for each of the three roles at once — optionally together with a new timed-recovery delay. Both primary and recovery can initiate one, and the role assignment on the blueprint (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/package.rs) arranges that neither can then wave its own proposal through: a proposal from primary is confirmable by recovery or confirmation, and a proposal from recovery is confirmable by primary or confirmation. Two of the three roles must agree on any change of control, and the pairing is never optional. Quick confirmation and the timed path The fast route is quick_confirm: a second role signs, the rule set is written, and control has moved within one transaction. It requires a counterparty, which is the point — it is the route for a user who still holds two of their three factors. The slow route exists for the user who holds only one. When the recovery role initiates a recovery and the controller was created with a timed_recovery_delay_in_minutes, the engine stamps the proposal with timed_recovery_allowed_after = now + delay, read from on-ledger time at minute precision (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/state_machine.rs) . Once that instant passes, timed_confirm_recovery completes the recovery with no second role involved. The method carries MethodAccessibility::Public in the blueprint's auth template, so the confirming transaction needs no badge at all; what it cannot do is alter the proposal, which is validated against the one already recorded. A proposal from the primary role never gets a timer — the timed path belongs to the recovery role alone. The delay is stored as a u32 of minutes, which the source notes (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/state.rs) tops out at 4,294,967,295 minutes, "which is 8171.5511700913 years"; set it to None and there is no timed path at all. Whatever the value, it is the window in which the legitimate holder of the primary or confirmation role can cancel the proposal — which is why an attacker who has stolen one factor cannot simply wait a stolen account out in silence. Every step emits an event — InitiateRecoveryEvent, RuleSetUpdateEvent, CancelRecoveryProposalEvent — so the whole contest is legible in the account's on-ledger history (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/events.rs) rather than only in a wallet's notifications. Locking primary, and retiring the controller Two further powers sit outside the recovery flow. The recovery role alone can call lock_primary_role, and while primary is locked create_proof fails — so a holder who knows their signing key is compromised can freeze the account's normal use without yet having agreed on who should control it next. Pending recoveries continue while it is locked; stop_timed_recovery, by contrast, is callable by all three roles. The exit is badge_withdraw. Either proposer can initiate it, and confirming it hands the controlled owner badge back as an ordinary bucket — after which the engine rewrites all three roles to DenyAll (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/blueprint.rs) . The controller does not merely release the account; it permanently retires itself, and the badge it was holding is once again just a badge in somebody's wallet, with all the exposure that implies. Recovery badges, and who pays for a recovery Recovery and confirmation are usually not keys the user carries. When a controller is created it mints its own non-fungible recovery badge resource, owned by the controller's own global caller badge (/contents/tech/core-concepts/access-rules-and-auth-zones) so that nothing else can ever mint one, and mint_recovery_badges is callable by primary or recovery to issue further badges to guardians, a second device, or a service. That raises a problem the first version of the blueprint could not solve: a guardian holding a recovery badge is not the account's owner and may hold no XRD (/contents/tech/core-protocols/xrd-token) of their own, yet somebody has to pay the transaction fee (/developers/transactions/03-transaction-fees) for every step of a recovery — and the account's own XRD is precisely what is out of reach. The Bottlenose (/contents/tech/releases/protocol-updates) protocol update fixed it by migrating every existing controller to a second version of the blueprint carrying an xrd_fee_vault, via a state update named, plainly enough, update_access_controller_to_add_xrd_fee_vault (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/updates/bottlenose.rs) . Any of the three roles may lock_recovery_fee against that vault; only primary may withdraw from it; and contribute_recovery_fee is public, so anyone at all can top up a stranger's recovery fund without gaining any say over the account. A live read of the native package on mainnet at epoch 332766 shows all 22 methods, the three fee-vault methods included, exported from the single AccessController blueprint. What it is not An Access Controller changes who controls an account. It does not reverse anything that already left. Assets a thief moved out during the window before recovery completes are gone in the ordinary way, because the resources themselves carry no recall path — a distinction worth keeping sharp, since the recurring community proposal to "mark" tokens with their owner so they can be clawed back founders on the same point from the other side: a unit that remembers its holder is, by definition, no longer fungible (/contents/tech/core-concepts/resources) . Nor is it free of assumptions. It presumes the user still holds at least one factor, that the recovery factor was set up before it was needed, and that the delay chosen is long enough to notice an attack in but short enough to be usable. Those are the same trade-offs a bank's fraud desk makes; the difference is that here they are parameters on a component anyone can read, rather than a policy on somebody else's screen. External Links - access_controller native blueprint (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller) - Role, Proposer, RuleSet and RecoveryProposal definitions (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/access_controller/data.rs) - Per-method role assignment (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/package.rs) - Recovery state machine (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/blueprints/access_controller/v2/state_machine.rs) - Bottlenose: the recovery fee vault migration (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/updates/bottlenose.rs) - Radix Docs: Access Controller (https://docs.radixdlt.com/docs/access-controller) ## Sharding URL: https://radix.wiki/contents/tech/core-concepts/sharding Updated: 2026-09-03 Summary: Sharding [ /ˈʃɑːdɪŋ/ ] is a method of partitioning a database horizontally across separate servers to improve scalability, performance and data availa… Sharding [ /ˈʃɑːdɪŋ/ ] is a method of partitioning a database (https://www.mongodb.com/docs/manual/sharding/) horizontally (https://en.wikipedia.org/wiki/Partition_(database)) across separate servers to improve scalability, performance and data availability. In the context of DLTs, sharding refers to the process of dividing the network's computational and storage workload across multiple smaller groups of nodes (https://www.radixdlt.com/blog/sharding-in-radix) , called shards, each responsible for processing a subset of the network's transactions and storing a portion of the global state. Background The primary goal of sharding in DLTs is to increase the overall throughput and capacity of the network (https://vitalik.eth.limo/general/2021/04/07/sharding.html) without sacrificing decentralization or security. By allowing multiple shards to process transactions in parallel, sharding aims to overcome the limitations of ‘full replication’ where every node must process and store all transactions (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . Sharding has gained significant attention in the blockchain community as a potential solution to the scalability trilemma (/contents/tech/core-concepts/blockchain-trilemma) , which posits that blockchain systems can only achieve two out of three desirable properties: scalability, security, and decentralization. By implementing sharding, projects such as NEAR, MultiversX and Radix aim to maintain high levels of security and decentralization while dramatically improving scalability. The concept of sharding in DLTs extends beyond simply partitioning data; it encompasses complex mechanisms for ensuring data availability, cross-shard communication, and maintaining overall network consistency (https://www.radixdlt.com/blog/breakthrough-in-consensus-theory-scaling-defi-without-breaking-composability) . Technical Fundamentals Sharding is a concept borrowed from traditional database systems and adapted for use in distributed ledger technology. Database Sharding In traditional database systems, sharding is a method for distributing data across multiple machines (https://www.mongodb.com/docs/manual/sharding/) . It involves breaking a large database into smaller, more manageable partitions called shards. Each shard contains a subset of the data and is stored on a separate server. This approach allows for horizontal scaling, where additional servers can be added to increase capacity and performance. There are two main types of database sharding: - Vertical Partitioning: Different tables from the same database are stored in different instances. - Horizontal Partitioning: A database table is split into separate sets of rows, stored in different database instances (https://www.radixdlt.com/blog/what-is-sharding) . Application to Blockchain and Distributed Ledgers In the context of blockchain and distributed ledgers, sharding involves dividing the network's computational and storage workload across multiple smaller groups of nodes (https://www.radixdlt.com/blog/sharding-in-radix) , each responsible for processing a subset of the network's transactions and storing a portion of the global state. The key difference in blockchain sharding is that it must maintain the security and decentralization properties of the network while improving scalability. This involves complex mechanisms for ensuring data availability, cross-shard communication, and maintaining overall network consistency. Radix, for example, implements a unique approach called "pre-sharding" (https://www.radixdlt.com/blog/sharding-in-radix) , where the shard space is allocated in full at launch rather than extended as the network grows. Two different figures circulate for its size, and they belong to two different designs. The 2018 and 2019 Radix posts describe Tempo (/contents/tech/research/tempo-consensus-mechanism) , whose ledger had a fixed shard space of 18.4 quintillion shards (https://www.radixdlt.com/blog/test-method-part1) (2^64). The Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) -era design that replaced Tempo specifies 2^256 (https://www.radixdlt.com/articles-learn/what-is-sharding) shards, and that is the figure used throughout the rest of this page. Key Goals: Scalability, Decentralization, Security The primary objectives of implementing sharding in distributed ledgers are: - Scalability: By allowing parallel processing of transactions across multiple shards, the overall throughput of the network can be significantly increased (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . In theory, this can lead to "quadratic sharding," where the capacity of the network grows quadratically with the computational power of individual nodes. - Decentralization: Sharding aims to maintain or even improve decentralization by allowing the network to run on consumer-grade hardware (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . This is in contrast to some high-throughput chains that rely on a small number of powerful nodes. - Security: A well-designed sharding system should maintain the security properties of the network (https://vitalik.eth.limo/general/2021/04/07/sharding.html) , ensuring that an attacker cannot easily compromise the system by targeting a small subset of shards. The challenge in implementing sharding lies in achieving all three of these goals simultaneously, effectively addressing the scalability trilemma that has long plagued blockchain networks. Types of Sharding Sharding in distributed ledger technology can be implemented in various ways, each focusing on different aspects of the network's operation. The main types of sharding are network sharding, transaction sharding, and state sharding. These approaches can be used individually or in combination to achieve the desired scalability improvements. Network Sharding Network sharding involves dividing the network nodes into smaller groups, each responsible for a subset of the network's tasks (https://www.radixdlt.com/blog/sharding-in-radix) . In this approach, nodes within a shard communicate more frequently with each other than with nodes in other shards. This can reduce the overall network communication overhead and improve efficiency. Radix, for example, implements a form of network sharding where each node maintains as many shards as it can handle, dropping shards that are too resource-intensive (https://www.radixdlt.com/blog/sharding-in-radix) . This allows even low-powered devices to participate in the network, promoting decentralization. Transaction Sharding Transaction sharding involves distributing the processing of transactions across different shards (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . In this approach, each shard is responsible for processing a subset of the total transactions in the network. This allows for parallel processing of transactions, potentially increasing the overall throughput of the network. One challenge with transaction sharding is ensuring that transactions that depend on each other or affect the same state are processed correctly (https://www.radixdlt.com/blog/sharding-in-radix) . Radix addresses this by using a deterministic process to assign transactions to shards based on the public keys involved, ensuring that related transactions are always processed in the same shard. State Sharding State sharding is perhaps the most complex form of sharding. It involves dividing the global state of the network (i.e., the full record of all accounts and their data) across multiple shards (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . Each shard maintains only a portion of the global state, which can significantly reduce the storage and computational requirements for individual nodes. However, state sharding introduces challenges in cross-shard communication and maintaining consistency across the network. Ethereum 2.0's sharding plan (https://vitalik.eth.limo/general/2024/05/23/l2exec.html) , for instance, initially focused on data sharding rather than full state sharding to mitigate some of these challenges. The implementation of state sharding often requires sophisticated techniques such as fraud proofs or zero-knowledge proofs (ZK-SNARKs) to ensure the validity of cross-shard transactions (https://vitalik.eth.limo/general/2021/04/07/sharding.html) and maintain the overall security of the network. Security Considerations While sharding offers significant scalability benefits for distributed ledger systems, it also introduces new security challenges that must be carefully addressed. This section explores the key security considerations in sharded systems and the solutions proposed to mitigate these risks. Single-Shard Takeover One of the primary security concerns in sharded systems is the potential for an attacker to take over a single shard. In a traditional blockchain, an attacker typically needs to control a majority of the network's resources to carry out an attack. However, in a sharded system, an attacker might only need to control a majority within a single shard to cause damage (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . Random sampling for validator assignment (https://vitalik.eth.limo/general/2021/04/07/sharding.html) has been suggested to prevent targeted attacks on specific shards. Data Availability Ensuring data availability is crucial in sharded systems. If data becomes unavailable, it can lead to stalled chains or even allow for ransom attacks on specific user data (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . This is particularly challenging in a sharded environment where not all nodes have access to all data. Proposed solutions are: - Data availability sampling (https://vitalik.eth.limo/general/2021/04/07/sharding.html) to ensure that all necessary data is available without requiring nodes to download entire blocks. - Erasure coding (https://vitalik.eth.limo/general/2021/04/07/sharding.html) to provide redundancy and facilitate data availability checking. Cross-Shard Transaction Atomicity Maintaining atomicity for transactions that span multiple shards is a significant challenge. Ensuring that all parts of a cross-shard transaction are executed correctly or all fail (https://www.radixdlt.com/blog/breakthrough-in-consensus-theory-scaling-defi-without-breaking-composability) is crucial for preserving the integrity of the system. Different projects have proposed various solutions: - Ethereum's proposed "yanking" mechanism (https://vitalik.eth.limo/general/2021/04/07/sharding.html) allows for objects to be moved between shards. - Radix's Cerberus consensus protocol (https://www.radixdlt.com/blog/breakthrough-in-consensus-theory-scaling-defi-without-breaking-composability) implements a "braiding" technique that allows for atomic composability across shards. These mechanisms aim to ensure that cross-shard transactions are executed correctly and atomically, maintaining the consistency of the overall system. Adaptive Adversaries Sharded systems can be vulnerable to adaptive adversaries who can quickly compromise or shut down specific nodes in real-time (https://vitalik.eth.limo/general/2021/04/07/sharding.html) . This poses a particular threat to systems that rely solely on committees for security. History and Development The concept of sharding in distributed ledgers has evolved significantly over time, with various approaches proposed and refined to address the scalability challenges of blockchain networks. This section traces the history and development of sharding from early proposals to modern implementations. Early Proposals (2015-2017) The idea of applying sharding to blockchain systems began to gain traction in the mid-2010s: - In 2015, a team at the National University of Singapore (NUS) proposed an early Byzantine Fault Tolerant (BFT) sharding approach (https://vitalik.eth.limo/general/2021/04/07/sharding.html#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem) . - Ethereum (https://ethereum.org) 's Vitalik Buterin started discussing sharding concepts for Ethereum as early as 2016 (https://vitalik.eth.limo/general/2021/04/07/sharding.html#improving-sharding-with-better-security-models) . - Other early conceptual work included proposals like "puzzle towers" by Dominic Williams (https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#how-do-you-actually-do-this-sampling-in-proof-of-work-and-in-proof-of-stake) , which aimed to combine proof-of-work with sharding. These early proposals often focused on sharding either transaction processing or state, but not both (https://vitalik.eth.limo/general/2021/04/07/sharding.html#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem) , which limited their potential scalability gains. Evolution of Approaches (2018-2020) As research in sharding progressed, more comprehensive approaches began to emerge: - Radix's initial consensus protocol, Tempo (/contents/tech/research/tempo-consensus-mechanism) , was designed to be sharded from the start (https://www.radixdlt.com/blog/tempo-consensus-lessons-learned) . It used a novel approach called "logical clocks" for consensus. - Zilliqa, launched in 2019, implemented a form of transaction sharding (https://vitalik.eth.limo/general/2021/04/07/sharding.html#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem) . - The concept of "quadratic sharding" was developed (https://vitalik.eth.limo/general/2021/04/07/sharding.html#sharding-through-random-sampling) , aiming to scale both processing power and storage capacity. - Researchers began to address key challenges such as cross-shard transactions and data availability (https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#how-can-we-facilitate-cross-shard-communication) . During this period, the focus shifted towards creating more secure sharding models that could maintain decentralization (https://vitalik.eth.limo/general/2021/04/07/sharding.html#improving-sharding-with-better-security-models) . This included the development of techniques like: - Data availability sampling (https://vitalik.eth.limo/general/2021/04/07/sharding.html#scalable-verification-of-data-availability) - Fraud proofs and zero-knowledge proofs for scalable verification (https://vitalik.eth.limo/general/2021/04/07/sharding.html#scalable-verification-of-computation) Modern Implementations (2021-present) Recent years have seen more concrete implementations and refined approaches to sharding: - Ethereum 2.0 (https://vitalik.eth.limo/general/2021/04/07/sharding.html) initially focused on data sharding rather than computation sharding. The original plan involved creating 64 separate shard chains (https://vitalik.eth.limo/general/2021/04/07/sharding.html) , each capable of processing transactions and smart contracts independently. - Other projects like Near Protocol have implemented their own versions of sharding (https://vitalik.eth.limo/general/2021/04/07/sharding.html#recap-how-are-we-ensuring-everything-is-correct-again) . Modern sharding approaches often combine multiple techniques to achieve scalability while maintaining security: - Using committees with random sampling for shard management (https://vitalik.eth.limo/general/2021/04/07/sharding.html#sharding-through-random-sampling) - Implementing cross-shard communication protocols (https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#how-would-synchronous-cross-shard-messages-work) - Leveraging Layer 2 solutions like rollups in conjunction with sharding (https://vitalik.eth.limo/general/2021/04/07/sharding.html#recap-how-are-we-ensuring-everything-is-correct-again) Sharding in Radix Radix has developed an integrated sharding and consensus architecture specifically designed for hyper-scalability of its decentralized network. In Radix’s case, sharding applies to both data availability and transaction execution as both functions are performed by nodes. Ledger Pre-Sharding The current Radix Mainnet (Babylon) (/contents/tech/releases/radix-mainnet-babylon) is sharded into a fixed number of 2^256 (https://www.talkcrypto.org/blog/2019/04/08/all-you-need-to-know-about-2256/) shards. Responsibility for validating shards is undertaken by groups of validators called shard groups (/contents/tech/core-concepts/shard-groups) , which may grow or shrink dynamically in response to load demand (https://youtu.be/FZWT3j9XHMI) . Currently, the number of shard groups is capped at one, and lifting that cap is the purpose of Radix’s forthcoming Xi’an (/contents/tech/releases/radix-mainnet-xian) release – though the leading Xi’an production candidate arrives there by a different route, described below. Pre-sharding is in contrast to the dynamic adaptive state sharding (https://coinmarketcap.com/academy/glossary/adaptive-state-sharding) model adopted by Shardeum, MultiversX, and NEAR, where shards are added incrementally as required. While sharding can improve scalability, an ad hoc approach to sharding leads to substantial difficulties as any changes to the shard structure require reorganizing the entire network - a time consuming and expensive process. The larger the sharded ledger grows, the more problematic this becomes. Ad hoc sharding also complicates queries and data lookups within the ledger. By sharding the data randomly, it becomes much harder to locate specific transactions or data points since they could be stored anywhere. This slows down queries as more extensive searches are required. Pre-sharding and the Xi’an candidate The fixed-shardspace framing above describes the design the Radix Foundation published. The community implementation that is now the Xi’an (/contents/tech/releases/radix-mainnet-xian) production candidate, hyperscale-rs (/contents/tech/research/hyperscale-rs) , does not work that way, and its lead developer rejects the word: on 2 August 2026 he called the idea that state is “pre-sharded” incoherent (https://t.me/hyperscale_rs/10358) , attributing the confusion to the Cerberus paper (/contents/tech/research/cerberus-whitepaper) using “shard” for what are really substate keys. In that implementation a leaderless beacon chain maintains a shard trie that starts small and splits as load requires. Substate keys still map deterministically to shards, but which shard a key lands in follows from the trie’s current shape rather than from a space allocated in advance, and a shard splits when its committed substate byte total crosses a governed threshold. Coverage therefore changes by splitting and merging the shards themselves rather than by shard groups (/contents/tech/core-concepts/shard-groups) widening their range. Deterministic Shard Indexing Shards on Radix are indexed deterministically by public keys. This means that the shard index for any address can be calculated by taking the modulo (https://en.wikipedia.org/wiki/Modulo) of the public key over the shard space. si=mod piSs=shard indexp=public keyS=total shard spacesi​=Smodpi​​s=shardindexp=publickeyS=totalshardspace​ By deterministically grouping related data into the same shard, Radix avoids the need for expensive data reorganization as the network grows. This creates four major advantages: - Proximity: All transactions from a particular account are guaranteed to be in the same shard, which makes it trivial to identify attempted double-spends. - Asynchrony: Transactions from separate accounts will always involve separate shards, enabling asynchronous, parallel processing of unrelated transactions. - Indexing: Lookup complexity and query time are reduced since shard locations can be easily derived from public keys. - Load balancing: Hash sharding typically results in a more uniform distribution of data across nodes. Network Security A key challenge in sharding distributed ledgers is ensuring sufficient security and node coverage across all shards. If some shards have much fewer nodes than others, it creates vulnerabilities. Radix employs several techniques to maintain security across its sharded network: - Node Identity Shard Mapping: To secure the network, validator node (/contents/tech/core-concepts/validator-nodes) addresses are mapped to a single ‘root’ shard. Nodes must permanently maintain their root shards, but can support additional shards to earn more transaction fees. Underserved shards offer higher returns, attracting more validators and preventing any shards from being overlooked. This free market approach maintains security even as the network scales. - Incentives for Multi-Shard Validation: Based on factors like computing resources, validators can choose to support additional shards beyond their root shard. The more shards a node supports, the greater the amount of transaction fees it can earn. This creates an incentive for validators to support as many shards as feasible to maximize profits. In this way, the overall validation workload is distributed across nodes. - Dynamic Shard Support via Free Market: As the network grows, some shards may end up with fewer nodes supporting them compared to other oversubscribed shards. These underserved shards then inherently offer higher potential returns since there is less competition for fees. The higher relative profits attract more validators to begin supporting the underserved shards. This brings coverage back into equilibrium across shards through a free market approach. - Scaling Security Through Staking: In proof-of-stake networks like Radix, staking provides additional security. The more tokens a validator stakes, the more shards it can validate. This allows validation load to scale up securely. High stake validators may validate transactions across many shards in parallel for efficiency. However low stake nodes still play a key role in providing decentralized shard coverage. Together, these mechanisms ensure Radix can securely scale to an exponentially growing shard space without running into coverage gaps or centralization issues. The network organically self-regulates to distribute validation across shards. Cerberus Consensus (https://arxiv.org/abs/2008.04450) Main article: Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Radix's Cerberus consensus (https://learn.radixdlt.com/article/what-is-cerberus) protocol specifies ‘braided’ sharding to atomically compose (/contents/tech/core-concepts/atomic-composability) transactions across shards. Cerberus shards transaction validation while braiding validation across shards to enforce system-wide transaction ordering and prevent double-spending. The braided architecture is intended to let Radix scale transaction throughput across a sharded network of effectively unlimited size. Braiding has never run in production. Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet runs Cerberus in its unsharded form, where there is nothing to braid – a configuration equivalent to the original HotStuff (https://arxiv.org/abs/1803.05069) – and the Xi’an production candidate does not braid either, using a HotStuff-2 two-chain commit per shard with execution asynchronous to consensus. The braided architecture described here is a specification rather than a description of a running system; the Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) page sets out the divergence in full. ## 4. dApp Definition and Wallet Verification URL: https://radix.wiki/developers/frontend/04-dapp-definition-and-verification Updated: 2026-09-03 Summary: You have a component deployed and a front end wired up with the Radix dApp Toolkit . You click Connect, and the Radix Wallet either shows your dApp as… What it is An account whose metadata registers your dApp Key metadata account_type, claimed_websites, claimed_entities Website proof /.well-known/radix.json at the claimed origin Required on Mainnet – the wallet rejects unverified requests Set up with Developer Console (https://console.radixscan.io) (Mainnet) or ShardSpace (https://shardspace.app/) (both networks) Introduction You have a component (/contents/tech/core-concepts/components) deployed and a front end wired up with the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) . You click Connect, and the Radix Wallet (/contents/tech/core-protocols/radix-wallet) either shows your dApp as unknown or refuses the request outright. Nothing is broken: you have not yet told the ledger that this website and these entities belong to the same dApp. That registration is a dApp Definition – an ordinary account whose metadata has been set to describe your application. It is the hub that ties your packages, components, resources (/contents/tech/core-concepts/resources) , and website together, and it is what lets the wallet tell a user that the site asking for their account is the one that owns the component it claims to own. On Mainnet it is not optional. What the Metadata Does A dApp Definition account carries a handful of metadata (/contents/tech/core-concepts/metadata-module) entries: - account_type set to dapp definition – the flag that makes the account a dApp Definition rather than a normal one. - name, description, tags, icon_url – the display fields the wallet shows whenever your dApp sends a request. These are what turn "an unknown site wants your account" into a recognisable prompt. - claimed_websites – the origins you assert this dApp runs on. - claimed_entities – the packages, components, and resources that belong to this dApp. The claims are two-way. The account states that it owns a website, and the website has to state that it belongs to the account – which is what stops anyone from claiming your domain by writing your URL into their own metadata. Setting One Up Do this once your components and front end exist, since you need their addresses and origin to claim them. - Create a fresh account in the Radix Wallet – this one becomes the dApp Definition, so keep it separate from an account you hold funds in. - Open the Developer Console (https://console.radixscan.io) and connect your wallet, sharing that account. Note that it sets Mainnet definitions only: there is no hosted Stokenet console (stokenet-console.radixdlt.com returns HTTP 530, checked 14 August 2026), so use ShardSpace below while you are learning, or run a Stokenet console of your own as described in Deploying to Stokenet and Mainnet (/developers/getting-started/03-deploying) . - On Configure Metadata, enter the account address and search for it. - Set account_type to dapp definition, then fill in name, description, tags, and icon URL. - Fill in claimed_websites with your dApp's origin, and claimed_entities with your component, package, and resource addresses. - Send the transaction to the wallet and approve it. The metadata is now on-ledger. ShardSpace (https://shardspace.app/) is a community-built alternative to the console for creating and managing dApp definitions on both networks. Proving the Website Side Claiming an origin in metadata is only half the handshake. The wallet then fetches /.well-known/radix.json from that origin and expects to find the dApp Definition account address listed there: { "dApps": [ { "dAppDefinitionAddress": "account_rdx12y..." } ] } Serve that file at the exact origin you claimed – scheme, host, and port all have to match, and www.example.com is not example.com. Until both directions agree, Mainnet requests from your dApp will not reach the wallet. When Verification Fails - Origin mismatch – the most common cause. Check the claimed string against what the browser actually sends. - File not served as JSON – some hosts return the SPA shell for unknown paths, so the wallet receives HTML instead of the manifest. Fetch the URL yourself and check the response body. - Wrong network – a Stokenet dApp Definition does not verify a Mainnet dApp. They are separate accounts on separate ledgers. - Address typo in claimed_entities – the wallet will connect, but your component will not display as part of the dApp. The 29 August 2026 Stokenet reset breaks one half of this Stokenet is wiped at 07:00 UTC on Saturday 29 August 2026 ( announced 18 August (https://t.me/radix_dlt/998662) ; terms on the Stokenet (/contents/tech/releases/stokenet) page). The handshake described above is two-sided, and the reset takes exactly one side: - The ledger side is destroyed. dApp Definition accounts keep their addresses – those are derived from your keys – but the metadata that makes one a definition is stored state, so account_type, name, claimed_websites and claimed_entities are all gone. The account reverts to an ordinary one. The packages and components it claimed are gone too, and re-publishing gives them new addresses, so claimed_entities cannot simply be re-entered from your notes. - The website side survives. /.well-known/radix.json lives on your own origin, not on the ledger, and nothing touches it. If you keep the same dApp Definition account, the file stays correct and needs no edit – which is a reason to reuse that account rather than create a fresh one after the reset. On-ledger persona (/contents/tech/core-protocols/personas) data is destroyed as well, so a tester who had connected to your dApp recreates their persona before they can connect again. Mainnet definitions are untouched. Next Steps - Radix APIs (/developers/infrastructure/02-radix-apis) – choose the right API once your dApp needs a backend - Building on Radix (/developers) – the wider index of tooling, SDKs, and community services External Links - dApp Definition Setup – Radix Documentation (https://docs.radixdlt.com/docs/dapp-definition-setup) - Metadata for Verification – Radix Documentation (https://docs.radixdlt.com/docs/metadata-for-verification) - Radix Developer Console (https://console.radixdlt.com/) - ShardSpace – community dApp definition manager (https://shardspace.app/) ## Radix Context for AI Agents URL: https://radix.wiki/developers/ai-agents/radix-context Updated: 2026-09-03 Summary: radix-context is a collection of 23 curated reference documents designed for AI coding agents – Claude, Cursor, Windsurf, and similar tools – to under… Type Developer Tooling Author xstelea (https://github.com/xstelea) Context Files 23 Domains Scrypto (/developers/scrypto/01-fundamentals) , Gateway API (https://docs.radixdlt.com/docs/network-gateway) , Transactions, Wallet, Effect Standard agents.md (https://agents.md) Repository GitHub (https://github.com/xstelea/radix-context) Introduction radix-context (https://github.com/xstelea/radix-context) is a collection of 23 curated reference documents designed for AI coding agents – Claude, Cursor, Windsurf, and similar tools – to understand how to build dApps and Scrypto (/developers/scrypto/01-fundamentals) components (/contents/tech/core-concepts/components) on the Radix (/contents/tech/core-protocols/radix-engine) network. The project follows the agents.md standard (https://agents.md) , enabling compatible tools to auto-discover and load relevant documentation. Rather than requiring an AI agent to search scattered docs, radix-context provides pre-structured, deep-reference material that agents can ingest directly. This dramatically improves the quality of AI-generated Scrypto (/developers/scrypto/01-fundamentals) code and Radix transaction manifests (/contents/tech/core-protocols/transaction-manifests) . Installation One-line install into any project directory: curl -fsSL https://raw.githubusercontent.com/xstelea/radix-context/main/install.sh | bashThis copies 23 context files into a context/ directory and merges an AGENTS.md index file. Optionally run ./setup.sh to clone 7 companion repositories ( Scrypto (/developers/scrypto/01-fundamentals) source, radix-dapp-toolkit (https://github.com/radixdlt/radix-dapp-toolkit) , Effect, TanStack Router, and more) into .repos/ for full cross-reference. Context Files Radix DLT & Scrypto (/developers/scrypto/01-fundamentals) (13 files) - radix- AccessRule (https://docs.radixdlt.com/docs/authorization-approach) – Permission systems and role-based access control in Scrypto (/developers/scrypto/01-fundamentals) - radix-Account – Native account blueprint (/contents/tech/core-concepts/blueprints-and-packages) with 30 core methods - radix-Gateway – Effect-wrapped Gateway API (https://docs.radixdlt.com/docs/network-gateway) client with retry logic - radix-GatewayRustSdk – Rust HTTP clients for Gateway and Core APIs - radix-Sbor – SBOR (https://docs.radixdlt.com/docs/sbor) wire format and schema system - radix-SubIntents – composable partial transactions (/contents/tech/core-concepts/subintents-and-pre-authorizations) for governance workflows - radix-TransactionManifest – Manifest construction and validation (V1/V2) - radix- radix-dapp-toolkit (https://github.com/radixdlt/radix-dapp-toolkit) – Wallet integration, ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) authentication, and signing - radix-transactions – Rust transaction building and signing - radix-ROLA – Off-ledger authentication: challenge generation and signature verification - radix-RadixEngineToolkit – Off-ledger manifest building, derivation, and SBOR via the Rust toolkit - radix-TypescriptRadixEngineToolkit – The TypeScript wrapper's builders and entry-point classes - radix-TxTool – Transaction tooling helpers Effect Library (8 files) - effect-Context – Dependency injection with Context.Tag - effect-Layer – Composable service blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) with memoization - effect-Pipe – Piping utilities including pipe() and Effect.gen - effect-Platform – HTTP, filesystem, terminal, and networking abstractions - effect-Queue – Fiber-safe async queues with backpressure - effect-Rpc – Type-safe, transport-agnostic RPC - effect-Schema – Runtime validation and type-safe transformations - effect-atom – Reactive state bridging Effect and React Framework (2 files) - tanstack-Router – Type-safe routing with SSR and file-based routes - tanstackStart-ConsultationDapp – Full-stack dApp reference using React 19 and Effect Companion Repositories Running ./setup.sh clones eleven repositories into .repos/ for source-level context – the context files reference them by path, so an agent can read the actual implementation rather than a summary of it: - radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) – Scrypto (/developers/scrypto/01-fundamentals) and the Radix Engine (/contents/tech/core-protocols/radix-engine) (develop branch) - radix-engine-toolkit (https://github.com/radixdlt/radix-engine-toolkit) and typescript-radix-engine-toolkit (https://github.com/radixdlt/typescript-radix-engine-toolkit) – transaction construction and SBOR (/developers/transactions/04-radix-engine-toolkit) , in Rust and TypeScript - radix-dapp-toolkit (https://github.com/radixdlt/radix-dapp-toolkit) and rola (https://github.com/radixdlt/rola) – wallet connection and off-ledger authentication (/developers/frontend/03-rola-authentication) - radix-web3.js (https://github.com/xstelea/radix-web3.js) – the author's own TypeScript client - radix-gateway-api-rust (https://github.com/ociswap/radix-client) – Rust Gateway API (https://docs.radixdlt.com/docs/network-gateway) client, by Ociswap - consultation_v2 (https://github.com/radixdlt/consultation_v2) – reference dApp implementation - radix-docs (https://github.com/gguuttss/radix-docs) – a community mirror of the documentation - TanStack Router (https://github.com/TanStack/router) and Effect (https://github.com/Effect-TS/effect) – the frontend stack the Effect context files assume setup.sh needs a GitHub SSH key Ten of the eleven clones use SSH remotes (git@github.com:…); only radix-dapp-toolkit is fetched over HTTPS. Without a key registered on your GitHub account the script fails on its first clone. The one-line install.sh above has no such dependency – it is only the optional companion-repository step that does. Relationship to Radix Skills In June 2026 the same author published Radix Skills (/developers/ai-agents/radix-skills) , an installable agent skill covering much of the same ground in 38 topic guides. The two are complementary rather than successive: radix-skills names radix-context in its own research strategy as an optional "candidate map for topics and vocabulary", and its guides route to local source checkouts of radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) and radix-web3.js (https://github.com/xstelea/radix-web3.js) for verification. The practical difference is when the material loads. radix-context copies its files into a project and relies on the agents.md (https://agents.md) index for discovery; a skill is a described capability the agent selects for itself, then reads only the one or two guides that match the task. External Links - radix-context – GitHub Repository (https://github.com/xstelea/radix-context) - agents.md Standard (https://agents.md) - Radix Official Documentation (https://docs.radixdlt.com) - Radix DLT on GitHub (https://github.com/radixdlt) ## Radix Rust SDK URL: https://radix.wiki/developers/infrastructure/radixdlt-rust-sdk Updated: 2026-09-03 Summary: The Radix Rust SDK ( radixdlt-rust-sdk ) is a set of native Rust building blocks for the Radix ledger – the off-ledger primitives that, until now, exi… Developer Luis Alberto Reoyo Bolaños (genkipool) (https://genkipool.com) Type Developer SDK / off-ledger toolkit License MIT or Apache-2.0 (dual) Transports WebRTC, iroh (https://www.iroh.computer/) / QUIC Repository github.com/genkipool/radixdlt-rust-sdk (https://github.com/genkipool/radixdlt-rust-sdk) Distribution Git / path dependency (not on crates.io) Status 🟢 Active The Radix Rust SDK ( radixdlt-rust-sdk (https://github.com/genkipool/radixdlt-rust-sdk) ) is a set of native Rust building blocks for the Radix (https://www.radixdlt.com/) ledger – the off-ledger primitives that, until now, existed mainly in JavaScript/TypeScript. It lets developers build authentication backends, transaction tooling, and wallet integrations entirely in pure Rust. The project is authored and maintained by Luis Alberto Reoyo Bolaños (https://genkipool.com) (GitHub genkipool (https://github.com/genkipool) ) and is dual-licensed under MIT or Apache-2.0. Background Radix's off-ledger toolkit – the code that runs in a dApp backend or client rather than on the network – has historically been distributed as the official TypeScript packages (https://github.com/radixdlt) such as @radixdlt/rola and the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) . The Radix Rust SDK reimplements these primitives for the Rust ecosystem, giving server, desktop, and embedded developers a way to derive addresses, verify signatures, manage keys, and talk to wallets without a JavaScript runtime. It emphasises modular transports, native ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) verification, and integration with AI agents. Crates The workspace (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/Cargo.toml) holds ten crates, but it is not one workspace: radixdlt-connect, radixdlt-connect-iroh and radixdlt-connector-mcp are each isolated, because their WebRTC and QUIC dependency trees cannot be resolved alongside the Radix Engine (/contents/tech/core-protocols/radix-engine) tree the Gateway crate pulls in. The manifest records the specific collision (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/crates/connect-iroh/Cargo.toml) : the Scrypto (/contents/tech/core-protocols/scrypto-programming-language) engine pins regex to exactly 1.9.3 while webrtc requires 1.9.5 or newer. A developer therefore picks a transport at the crate level rather than by feature flag. - radixdlt-sdk – umbrella crate for the main workspace, re-exporting the others behind feature flags (address, rola – the default, keystore, gateway, connect-types, and full). It deliberately does not re-export the two transports (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/crates/sdk/Cargo.toml) , for the resolution reason above. - radixdlt-rola – off-ledger authentication matching @radixdlt/rola (https://github.com/radixdlt/rola) ("log in with Radix"). - radixdlt-address – virtual-account address derivation. - radixdlt-keystore – encrypted Ed25519 keystore using scrypt + AES-256-GCM. - radixdlt-gateway-tx – Gateway (https://docs.radixdlt.com/docs/network-gateway) client with local transaction signing. - radixdlt-connect-types – the transport-agnostic Radix Connect (/contents/tech/core-protocols/radix-connect) wallet-interaction schema, shared by both transports and carrying no heavy dependencies of its own. - radixdlt-connect – Radix Connect (https://docs.radixdlt.com/docs/dapp-toolkit) over WebRTC for mobile-wallet integration, including TURN over TCP/TLS for networks with no UDP. - radixdlt-connect-iroh – Radix Connect over iroh (https://www.iroh.computer/) / QUIC for direct SDK-to-SDK communication. - radixdlt-connector-mcp – a local MCP (https://modelcontextprotocol.io/) server that lets AI agents pair a wallet and sign transactions. - radixdlt-i18n – system-locale detection with bilingual text support. Availability and Installation None of the crates are published to crates.io (https://crates.io) . Queried at the registry's API on 15 August 2026, radixdlt-sdk, radixdlt-rola, radixdlt-connect-iroh and radixdlt-connector-mcp all return crate does not exist, so the radixdlt-sdk = "0.1" quick-start in the README (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/README.md) — and the crates.io and docs.rs badges above it — describe an intended future state rather than one a cargo add will reach today. The workspace is consumed by Git or path dependency in the meantime. The repository's PUBLISHING.md (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/PUBLISHING.md) says the packages are publish-ready — metadata and READMEs complete, tests green, a clean cargo publish --dry-run for radixdlt-i18n — and sets out the publish order dependencies-first. What it leaves open is a naming question rather than an engineering one: crates.io names are first-come-first-served, and the radixdlt-* prefix is Radix (https://www.radixdlt.com/) 's own brand, so the document flags that the project "could object or request a transfer, and the names may look official" before anyone claims them. The exception, and the piece that is installable today, is the MCP connector. It ships as a binary named radix-connector-mcp, installed straight from the repository with cargo install --git https://github.com/genkipool/radixdlt-rust-sdk radixdlt-connector-mcp or the prebuilt-binary scripts for Linux, macOS and Windows. It carries the project's only release train (https://github.com/genkipool/radixdlt-rust-sdk/releases) — nine tags from connector-v0.1.0 on 5 July 2026 to connector-v0.3.1 on 2 August 2026, the latter also the repository's most recent commit. Radix Connect over iroh The radixdlt-connect-iroh (https://github.com/genkipool/radixdlt-rust-sdk/tree/main/crates/connect-iroh) crate defines a transport protocol that lets two pure-Rust peers exchange Radix wallet (/contents/tech/core-protocols/radix-wallet) -interaction messages over iroh (https://www.iroh.computer/) (QUIC). It is a Rust-native alternative to the WebRTC transport used by Radix Connect (https://docs.radixdlt.com/docs/dapp-toolkit) , enabling server-to-signer and device-to-device flows – such as "log in with Radix" and transaction signing – without routing through a mobile wallet. The full specification is published in its PROTOCOL.md (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/crates/connect-iroh/docs/PROTOCOL.md) . Transport and framing Peers connect as iroh 1.x endpoints over QUIC, negotiating the ALPN identifier radixdlt-connect-iroh/0. Each interaction uses one bidirectional QUIC stream: the connecting dApp sends first and the accepting Wallet receives first, so request/response ordering is maintained without a separate handshake. Messages are length-prefixed JSON documents – a 4-byte big-endian u32 length followed by a UTF-8 JSON body. Roles The dApp initiates the connection, sends the request, and verifies responses (notably ROLA (/developers/frontend/03-rola-authentication) proofs). The Wallet (signer) accepts the connection, holds the Ed25519 signing keys, and responds to interactions. A request envelope carries an interactionId (UUID-v4), metadata (version, network ID, dApp definition address, origin), and discriminated items; the response envelope echoes the same interactionId as either success or failure. Interaction flows The protocol supports the same interaction families as Radix Connect: - Account proof (ROLA) – the dApp sends a challenge and its context; the Wallet signs a message incorporating the challenge, dApp definition, and origin; the dApp verifies the returned proofs natively via radixdlt-rola::verify_account_proof, independent of transport authentication. - Transaction – the dApp sends a manifest (https://docs.radixdlt.com/docs/manifest) and blobs; the Wallet compiles it, builds a notarized transaction, submits it to the Gateway, and returns the intent hash (even if the confirmation wait times out). - Pre-authorization (/contents/tech/core-concepts/subintents-and-pre-authorizations) – the dApp sends a subintent manifest (/contents/tech/core-protocols/transaction-manifests) and expiration window; the Wallet signs a subintent with an epoch-based validity window (~5 minutes per epoch) and returns the signed partial transaction, which is not submitted. Pairing, identity, and relays A Wallet publishes a locator – a full ticket() (local addresses, for same-host or LAN pairing), an id_ticket() (endpoint ID only, for internet use with discovery), or an endpoint_id_string() (mDNS pairing). Identity can be ephemeral (a random key per run) or fixed (a 32-byte seed yields a stable EndpointId); reusing the Radix account key as the endpoint seed unifies channel and ledger identity. Relaying is configurable: Relay::Disabled keeps connections direct, while Relay::Enabled uses n0 public relays and discovery for NAT traversal. Errors surface through the IrohError enum (Bind, Connect, Accept, Stream, Protocol, Rejected). Security properties QUIC/TLS provides confidentiality and integrity, and the EndpointId authenticates peers at the transport layer. ROLA proofs are verified natively by the dApp, independent of that transport authentication. When the endpoint seed doubles as the account key, channel and ledger identity are tied together. A relay can observe connection metadata but never the encrypted stream contents. AI-agent integration The radixdlt-connector-mcp crate exposes a local Model Context Protocol (https://modelcontextprotocol.io/) server, letting AI agents pair a Radix wallet and request signatures through the SDK's transports. Combined with native ROLA verification and Gateway signing, this positions the Rust SDK as a foundation for agentic Radix tooling that runs entirely outside a browser. External Links - radixdlt-rust-sdk on GitHub (https://github.com/genkipool/radixdlt-rust-sdk) - connect-iroh PROTOCOL.md specification (https://github.com/genkipool/radixdlt-rust-sdk/blob/main/crates/connect-iroh/docs/PROTOCOL.md) - genkipool.com (https://genkipool.com) · @GenkipoolC (https://x.com/GenkipoolC) - Radix docs – ROLA (Radix Off-Ledger Authentication) (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) - iroh – peer-to-peer QUIC networking (https://www.iroh.computer/) ## Igentix URL: https://radix.wiki/developers/ai-agents/igentix Updated: 2026-09-03 Summary: Read at 07:05 UTC on 31 August 2026 , every path on the host answers a bare 404 page not found – nineteen bytes of text/plain , the default a Go HTTP… Type AI agent payments demo (MCP endpoint) Status 🟠 Dormant – the demo host stopped serving on or about 30 August 2026 Standards x402 + AP2 Network Radix Stokenet (/contents/tech/releases/stokenet) (testnet) Settlement XRD (/contents/tech/core-protocols/xrd-token) and USDC, gas-free Website demo.igentix.app (offline) MCP endpoint https://demo.igentix.app/mcp (offline) The demo went dark Read at 07:05 UTC on 31 August 2026, every path on the host answers a bare 404 page not found – nineteen bytes of text/plain, the default a Go HTTP router returns when no route matches. That covers the demo gallery, the /info explainer, and the /mcp endpoint this page tells an agent to add as a connector, to both a GET and a JSON-RPC initialize over POST. The host is up: demo.igentix.app resolves to 193.200.238.116, terminates TLS on a Let’s Encrypt certificate issued 12 August 2026 and valid to 10 November, and answers over HTTP/2. What is missing is the application behind the router. The apex igentix.app resolves to the same address and now presents a self-signed TRAEFIK DEFAULT CERT whose validity begins 30 August 2026 at 08:04:32 UTC, which dates the reverse proxy’s restart and is the closest timestamp available for when the service stopped being routed. That is the day after the Stokenet reset (/contents/tech/releases/stokenet) wiped the ledger Igentix ran on, though nothing published connects the two and the project has announced nothing. The rest of this page describes the demo as it worked while it was up. Overview Igentix is a testnet demonstration platform that lets AI agents (/contents/tech/core-concepts/radix-for-ai-agents) such as Claude and ChatGPT autonomously discover, buy, and pay for services on Radix (/contents/tech/core-protocols/radix-engine) . An agent connects to Igentix through a Model Context Protocol (MCP) (/developers/ai-agents/ai-agents-and-x402) endpoint and can then complete a full purchase – find a priced service, pay for it, and receive the result – with no gas token and no wallet pop-up. Everything runs on the Radix Stokenet testnet, so the tokens it moves carry no real value. x402 and AP2 Igentix builds on two emerging open standards for the agent economy. x402 (/developers/ai-agents/ai-agents-and-x402) is an HTTP-native payment protocol initiated by Coinbase in 2025 that activates the long-reserved 402 Payment Required status code: a server answers a request with machine-readable payment terms (price, currency, receiving account, network), the client authorizes an exact-amount payment, a facilitator settles it on-ledger and can sponsor the network fee, and the server returns the resource. AP2 (Agent Payments Protocol), announced by Google in 2025, adds the authorization layer – a cryptographically signed mandate, structured as an SD-JWT verifiable credential, that captures what a human authorized: which items and payees are allowed, a per-payment cap and total budget, a recurrence schedule, and a validity window. x402 moves the payment; AP2 records the authority behind it. Igentix settles AP2-authorized payments over x402 in USDC (/contents/tech/core-concepts/stablecoins) . Ledger-enforced spending policy Both standards leave enforcement open: a mandate is authenticated policy, but whoever executes the payment must still choose to honour it. Igentix closes that gap by anchoring the limits on-chain. An AP2 spend mandate's allowed payee, per-day cap, total budget, number of days, and time window are pinned to the Radix ledger (/contents/tech/core-protocols/radix-engine) , which rejects any payment that breaches them even if the Igentix service itself is compromised. Every payment is also checked against a spending policy before it settles – a hard cap per transaction, an allowlist of callable methods and on-chain components (/contents/tech/core-concepts/components) , and a threshold above which a human must co-sign in their wallet. A leaked agent key cannot move funds beyond these bounds. Demos and MCP tools Once an agent is connected, it can run a set of demos exposed as MCP tools. Two entry-level demos pay on-chain services in XRD (/contents/tech/core-protocols/xrd-token) from a shared demo treasury and need no setup: buying a single access key, and bundling two services into one atomic (/contents/tech/core-concepts/atomic-composability) , all-or-nothing purchase. Four further demos spend the user's own USDC – paying for off-chain work with a tamper-proof on-chain receipt, metering thousands of sub-cent requests that batch-settle in a single payment, routing a large payment to a 2-of-2 approval treasury that waits for a human co-sign, and renewing a daily subscription under a signed AP2 spend mandate. The endpoint also exposes read-only tools to list, search, and inspect the available services. A companion agent-payments toolkit in the ecosystem is AgentWallet for Radix (/developers/ai-agents/agent-wallet-ai) . Connecting an agent An agent connects by adding https://demo.igentix.app/mcp as a custom MCP connector – in Claude via Customize → Connectors → Add custom connector, or in ChatGPT via developer-mode Connectors. The shared endpoint runs the two XRD demos from a common treasury. To run the USDC and AP2 demos, a user opens the Igentix setup flow, connects a Radix Wallet (/contents/tech/core-protocols/radix-wallet) , funds a capped and revocable Agent Vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) , and mints a personal endpoint of the form demo.igentix.app/mcp/u/; the agent then pays from that vault under the user's own caps. Stokenet is reset on Saturday 29 August 2026 at 07:00 UTC ( announced 18 August (https://t.me/radix_dlt/998662) ; terms on the Stokenet (/contents/tech/releases/stokenet) page), and Igentix runs entirely on it. Everything this page describes as living on the ledger goes with it – the Agent Vaults, the pinned spend-mandate limits, the demo treasury, and the components behind the minted per-user endpoints. Account addresses survive, because they are derived from keys rather than stored, but the balances and components under them do not, so a user who has set up a personal endpoint should expect to fund and mint again afterwards. Checked 19 August 2026, that endpoint was live and answered 405 to a GET because it accepts POST only; it no longer answers at all (see The demo went dark (#the-demo-went-dark) ). External Links - Igentix – demo gallery, demo.igentix.app (offline since on or about 30 August 2026) - x402 & AP2, explained, demo.igentix.app/info (offline) - x402.org – protocol site (https://x402.org) ## 2. Resources, Vaults, and NFTs URL: https://radix.wiki/developers/scrypto/02-resources-and-nfts Updated: 2026-09-03 Summary: A resource is any digital asset on Radix – tokens, NFTs , badges , LP tokens, etc. Unlike Solidity where tokens are contract state, Radix resources ar… Resources A resource (https://docs.radixdlt.com/docs/resources) is any digital asset on Radix – tokens, NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) , badges (https://docs.radixdlt.com/docs/authorization-approach) , LP tokens, etc. Unlike Solidity (https://soliditylang.org) where tokens are contract state, Radix resources (/contents/tech/core-concepts/resources) are native engine primitives with built-in rules for minting, burning, transferring, and access control. There are two kinds: - Fungible – identical, interchangeable units (e.g., XRD (/contents/tech/core-protocols/xrd-token) , stablecoins) - Non-fungible – unique items with individual data (e.g., NFTs (/contents/tech/core-protocols/nfts-on-radix) , access badges (https://docs.radixdlt.com/docs/user-badge-pattern) ) Creating Fungible Resources let my_token = ResourceBuilder (https://docs.radixdlt.com/docs/resources) ::new_fungible(OwnerRole::None) .metadata(metadata!( init { "name" => "My Token", locked; "symbol" => "MYT", locked; } )) .mint_initial_supply(1_000_000) .into();This creates 1 million tokens with locked name and symbol. The OwnerRole::None means no one can change the resource's configuration after creation. Creating Non-Fungible Resources ( NFTs (https://en.wikipedia.org/wiki/Non-fungible_token) ) #[derive(ScryptoSbor, NonFungibleData)] pub struct Ticket { pub event_name: String, pub seat: u32, #[mutable] pub used: bool, } let tickets = ResourceBuilder (https://docs.radixdlt.com/docs/resources) ::new_integer_non_fungible::(OwnerRole::None) .metadata(metadata!( init { "name" => "Event Ticket", locked; } )) .mint_initial_supply([ (IntegerNonFungibleLocalId::new(1), Ticket { event_name: "RadFest".into(), seat: 42, used: false, }), ]) .into();Fields marked #[mutable] can be updated later via the ResourceManager (https://docs.radixdlt.com/docs/resources) . Immutable fields are fixed at mint time. Vaults and Buckets (https://docs.radixdlt.com/docs/resources) Resources must always be inside a container: Container Lifetime Purpose Vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) Permanent (on-ledger state) Store resources between transactions Bucket Transient (single transaction) Move resources during a transaction The Radix Engine (/contents/tech/core-protocols/radix-engine) enforces that all buckets (https://docs.radixdlt.com/docs/buckets-and-vaults) must be empty by the end of every transaction. This guarantees no resources are accidentally lost or left in limbo. // Take 10 tokens from a vault into a bucket let bucket: Bucket = self.my_vault.take(10); // Put them into another vault self.other_vault.put(bucket);Typed variants (FungibleVault, NonFungibleVault, FungibleBucket, NonFungibleBucket) provide type-safe operations when you know the resource type at compile time. Proofs Proofs (https://docs.radixdlt.com/docs/auth) let you demonstrate ownership of a resource without transferring it – like showing an ID badge without handing it over. // Create a proof from a vault let proof = self.admin_badge.create_proof_of_all(); // The proof is automatically placed in the Auth Zone // where the Radix Engine (/contents/tech/core-protocols/radix-engine) checks it against access rules (https://docs.radixdlt.com/docs/authorization-approach) Proofs are central to Radix's authorization model (/developers/scrypto/03-authorization-and-badges) . Protected methods check for proofs in the caller's Auth Zone (/contents/tech/core-concepts/access-rules-and-auth-zones) rather than checking msg.sender. ResourceManager (https://docs.radixdlt.com/docs/resources) Every resource has a ResourceManager (https://docs.radixdlt.com/docs/resources) – the on-ledger controller for that resource type. Use it to mint, burn, query supply, and update NFT data: // Mint more tokens (if resource was created with mint role) let new_tokens: Bucket = self.resource_manager.mint(500); // Get total supply let supply: Decimal = self.resource_manager.total_supply().unwrap(); // Update mutable NFT data self.resource_manager.update_non_fungible_data( &nft_id, "used", true, ); Next Steps - Authorization and Access Rules (/developers/scrypto/03-authorization-and-badges) – decide who is allowed to mint, withdraw, and update what External Links - Resources documentation (https://docs.radixdlt.com/docs/resources) - Non-Fungible Tokens (https://docs.radixdlt.com/docs/learning-to-create-your-first-non-fungible) - Proofs and Authorization (https://docs.radixdlt.com/docs/auth) - What are Vaults and Buckets? (https://learn.radixdlt.com/article/what-are-vaults-and-buckets) ## AI Agents & x402 Payments URL: https://radix.wiki/developers/ai-agents/ai-agents-and-x402 Updated: 2026-09-03 Summary: AI agents are becoming first-class consumers of on-chain services: reading ledger state, building transactions, and – increasingly – paying for the da… Topic Agentic payments & AI tooling Standard x402 (https://x402.org/) (HTTP 402) Stewards x402 Foundation (Coinbase, Cloudflare, Google, Visa) Radix role Parallel settlement layer for micropayments Scaling Hyperscale (Xi’an) (/contents/tech/research/hyperscale-rs) Status Active development Introduction AI agents are becoming first-class consumers of on-chain services: reading ledger state, building transactions, and – increasingly – paying for the data and APIs they use. Radix is being positioned as a settlement layer for this agentic economy, combining asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) programming, ROLA (/developers/frontend/03-rola-authentication) authentication, and the throughput of Hyperscale (/contents/tech/research/hyperscale-rs) . This page collects the developer-facing pieces: the x402 (https://x402.org/) payment standard, agent wallets, and the Model Context Protocol (MCP) tooling that lets coding and consumer agents work with Radix. What is x402? x402 (https://x402.org/) is an open standard that activates the long-dormant HTTP 402 Payment Required status code as a real payment mechanism. A client – a browser, an app, or an AI agent – requests a resource; the server replies with a price; the client authorizes a stablecoin (or token) payment; the resource is delivered. One HTTP round-trip, with no accounts, subscriptions, or API keys. It was introduced by Coinbase (https://docs.cdp.coinbase.com/x402/welcome) in 2025 and is now stewarded by the x402 Foundation alongside Cloudflare, Google, and Visa. A key role in the protocol is the facilitator, which abstracts blockchain complexity – fee handling, transaction submission, and network selection – while remaining non-custodial: the agent controls what is paid, the facilitator handles how it settles. This separation is what makes x402 usable by clients with no blockchain knowledge. Why Radix for Agentic Payments Agentic commerce is fundamentally a high-volume micropayment problem: millions of small, machine-to-machine payments for content, compute, and API calls. That workload only settles on a ledger that can scale horizontally without sacrificing atomic composability (/contents/tech/core-concepts/atomic-composability) – which is the explicit goal of Hyperscale (Xi’an) (/contents/tech/research/hyperscale-rs) , where shards reconfigure with usage so capacity follows demand. Beyond raw throughput, Radix brings primitives that suit programmable agent payments: native asset-oriented (/contents/tech/core-protocols/radix-engine) resources, transaction manifests (/developers/transactions/01-manifest-language) that make intent explicit, and subintents for partial, multi-party flows. Builders should note the trade-offs surfaced during Hyperscale testing – subintents currently cost roughly 2× a plain transfer and hit the 256-event limit at around 30 subintents per transaction (versus 127 plain transfers) – so high-frequency micropayments generally need to be bundled. Building x402 on Radix The x402 reference implementation is multi-chain and split into composable packages, with middleware for common server frameworks: - x402 (implementation) (https://github.com/xstelea/x402) – the protocol repo, with a TypeScript SDK (@x402/core, plus framework adapters such as @x402/express, @x402/hono, @x402/next, and @x402/fetch) and chain implementations. Radix support is in active development. - x402 Protocol Spec (https://docs.x402.org/core-concepts/http-402) – the wire format and payment flow. - Coinbase x402 Docs (https://docs.cdp.coinbase.com/x402/welcome) – the original reference documentation. - radix-web3.js (https://github.com/xstelea/radix-web3.js) – an Effect-native TypeScript toolkit useful for constructing and submitting the Radix transactions an x402 facilitator settles. A minimal x402 server gates a route behind a payment requirement: app.use(paymentMiddleware({ "GET /weather": { accepts: [/* networks / schemes you support */], description: "Weather data", }, })); AI Agent Tooling on Radix A growing toolset lets AI agents read Radix, build transactions, and act on a user's behalf: - RadixScan Agent Layer (https://ai.radixscan.io/) – a keyless MCP server (https://ai.radixscan.io/llms.txt) (mcp.ai.radixscan.io) that lets agents read the ledger and build, validate, and simulate manifests (/contents/tech/core-protocols/transaction-manifests) , then request a signature non-custodially (the server holds no keys; signing happens in the user's wallet). Transports: /mcp (HTTP) and /sse. - Awesome Radix MCP Servers (https://github.com/xstelea/awesome-radix-mcp-servers) – a curated index of MCP servers in the Radix ecosystem. - Radix Context for AI Agents (/developers/ai-agents/radix-context) – 19 curated context files ( radix-context (https://github.com/xstelea/radix-context) ) that teach coding agents how to build on Radix. - Radix Skills (https://github.com/xstelea/radix-skills) – installable agent skills for Radix dApp, manifest, Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , and Gateway work ( skills.sh (https://skills.sh/xstelea/radix-skills) ). - AI Agent Wallet (https://t.me/agent_wallet_ai_radix) – an open-source, natural-language wallet SDK for agents that can interact with Radix DEXs, lending (WEFT), and staking. To connect an MCP-capable coding agent (e.g. Claude Code) to the RadixScan server, add it to your project's .mcp.json: { "mcpServers": { "radixscan": { "type": "http", "url": "https://mcp.ai.radixscan.io/mcp" } } } Standardising Radix for x402 and CAIP For an agent’s tooling to pay on Radix without special-casing it, Radix has to be nameable in the standards those tools already read. On the 30th of July, 2026, Avaunt (https://x.com/a_vaunt) opened a temperature check on Radix Talk (https://radixtalk.com/t/adding-radix-to-the-x402-payment-standard-and-the-caip-namespaces-registry/2321) proposing two submissions be made on the community’s behalf: registering Radix in the Chain Agnostic (CAIP) namespaces registry (https://github.com/ChainAgnostic/namespaces) , and adding Radix as a supported network in x402 (https://x402.org/) . The CAIP half covers three profiles: CAIP-2 (https://chainagnostic.org/CAIPs/caip-2) blockchain identifiers (a canonical radix:mainnet rather than the differing strings cross-chain tools currently invent), CAIP-10 (https://chainagnostic.org/CAIPs/caip-10) account addresses, and CAIP-19 (https://chainagnostic.org/CAIPs/caip-19) asset identifiers for Radix resources. The x402 half would make any Radix token usable at x402-compatible services rather than only those a facilitator has been built for; the proposal argues Radix suits the workload because subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) and fee sponsorship let a third party fund and settle an agent’s payment inside one atomic transaction. A draft specification already exists, covering both sponsored and non-sponsored settlement and following the verification rules used in the recent Starknet, XRPL and NEAR submissions. The vote itself is non-binding – it exists so XRD (/contents/tech/core-protocols/xrd-token) holders can signal support that the submissions can then cite. If it carries, the stated next steps are a spec review, a reference SDK implementation, and a public Stokenet (/contents/tech/releases/stokenet) facilitator to test against. On the 1st of August, 2026, the proposal opened for voting as Temperature Check 6 (https://consultation.mountain-top.live/tc/6) on the Radix Accountability Council (/ecosystem/radix-accountability-council) ’s consultation platform, where XRD-weighted, non-custodial voting ran for five days. The submission drafts were published alongside it, ahead of the vote closing: the CAIP profiles – README.md, caip2.md, caip10.md and caip19.md – sit in the radix directory of a namespaces fork (https://github.com/AVaunt-consulting/namespaces/tree/main/radix) , and the x402 work, a fork of xStelea’s original realigned with upstream, carries the Radix exact scheme (https://github.com/AVaunt-consulting/x402/blob/main/specs/schemes/exact/scheme_exact_radix.md) beside the generic one (https://github.com/AVaunt-consulting/x402/blob/main/specs/schemes/exact/scheme_exact.md) . The x402 side was planned as three pull requests – the spec addition, a reference implementation (TypeScript proposed, with the choice put to the developer channel), and an additional SDK implementation. Both submissions have since been filed upstream; the section below records what carried and what was actually sent. The vote, and both submissions upstream Temperature Check 6 closed on the 6th of August 2026 at 09:28 UTC, five days after it opened, and it carried without a vote against. The governance component (/contents/tech/core-concepts/components) holds 58 votes, all of them For. Recomputing the weight behind them from the voting accounts’ holdings gives 557,142,796 XRD – about 138% of the 402,876,916 quorum written into a Temperature Check. Liquid XRD is the smaller part of that: 99,802,255, with the other 457,340,541 held as stake units and converted back at each validator’s current exchange rate, and five of the 58 accounts hold no liquid XRD at all. No single account carries more than about an eighth of the total. (Balances were read on the 10th of August 2026 rather than at the snapshot the dApp weights against, so the figures are indicative; the margin is wide enough that the direction is not in doubt.) The submissions then left the fork. The CAIP half went up as ChainAgnostic/namespaces#198 (https://github.com/ChainAgnostic/namespaces/pull/198) , “Add Radix (radix) namespace: CAIP-2, CAIP-10, CAIP-19”, opened on the 6th of August at 09:10 UTC – eighteen minutes before the vote it cites closed. It adds four files and 512 lines: a README.md written to CAIP-104 (https://chainagnostic.org/CAIPs/caip-104) covering the network model and Radix’s bech32m address encoding, then caip2.md registering the logical network names radix:mainnet and radix:stokenet (resolved through the network-configuration endpoints rather than a chain ID), caip10.md for account_… addresses, and caip19.md for fungible and non-fungible resource addresses. The x402 half followed on the 10th of August at 15:38 UTC as x402-foundation/x402#3112 (https://github.com/x402-foundation/x402/pull/3112) , “feat(specs): add Radix exact scheme”: two files, 741 lines added, one removed – the scheme document specs/schemes/exact/scheme_exact_radix.md plus a Radix row in the Critical Validation Requirements table of the generic scheme_exact.md. Per the project’s spec-first process it carries the specification only; the SDK implementation is stated to follow once the spec is approved. Neither pull request had drawn a review by the 10th of August, and the submitter’s own note in the Radix developer channel is that the namespaces repository has a backlog of pull requests reaching back to April, so the CAIP half is unlikely to move quickly. The scheme itself is where the Radix-specific design shows. It defines two settlement modes. In the sponsored mode, which the spec recommends, the paying client signs only a subintent (/contents/tech/core-concepts/subintents-and-pre-authorizations) and the facilitator wraps it in a root transaction and pays the network fee – so an agent can pay for a resource without ever holding XRD. In the non-sponsored mode the client signs a complete notarized transaction (/developers/transactions/01-manifest-language) itself. Because a sponsored subintent is a bearer payload, the spec binds it with VERIFY_PARENT, which restricts which facilitator is able to consume it and closes the obvious front-running route. Verification on the facilitator side is written as a requirement rather than a suggestion: strict instruction-sequence validation, fee-payer isolation, expiry mapped from the protocol’s maxTimeoutSeconds onto the transaction’s timestamp bounds, replay protection, and a preview that must return CommitSuccess with the exact balance deltas before anything is submitted. Its network identifiers are the CAIP-2 radix names, which is what couples the two submissions: the payment scheme names networks the namespaces registry has not yet registered. External Links - x402 – Internet-Native Payments Standard (https://x402.org/) - Coinbase x402 Documentation (https://docs.cdp.coinbase.com/x402/welcome) - x402 implementation – GitHub (https://github.com/xstelea/x402) - RadixScan Agent Layer (https://ai.radixscan.io/) - Awesome Radix MCP Servers (https://github.com/xstelea/awesome-radix-mcp-servers) - Radix Skills (https://github.com/xstelea/radix-skills) - Radix Talk – Adding Radix to the x402 payment standard and the CAIP namespaces registry (https://radixtalk.com/t/adding-radix-to-the-x402-payment-standard-and-the-caip-namespaces-registry/2321) - Temperature Check 6 – CAIP namespaces and x402 (voting) (https://consultation.mountain-top.live/tc/6) - CAIP namespaces submission draft – GitHub (https://github.com/AVaunt-consulting/namespaces/tree/main/radix) - x402 Radix scheme draft – GitHub (https://github.com/AVaunt-consulting/x402/tree/main/specs/schemes/exact) - ChainAgnostic/namespaces#198 – Add Radix namespace (CAIP-2, CAIP-10, CAIP-19) (https://github.com/ChainAgnostic/namespaces/pull/198) - x402-foundation/x402#3112 – add Radix exact scheme (https://github.com/x402-foundation/x402/pull/3112) ## 2. Radix APIs URL: https://radix.wiki/developers/infrastructure/02-radix-apis Updated: 2026-09-03 Summary: Radix exposes four APIs at different abstraction levels. Most developers only need the Gateway API . API Purpose Best For Access Gateway High-level le… Gateway Spec Gateway API Reference (https://docs.radixdlt.com/api-reference/gateway-api-specs.html) Core Spec Core API Reference (https://docs.radixdlt.com/api-reference/core-api-specs.html) API Overview Radix exposes four APIs at different abstraction levels. Most developers only need the Gateway API (https://docs.radixdlt.com/docs/network-gateway) . API Purpose Best For Access Gateway High-level ledger queries and transaction submission dApps, wallets, explorers Public endpoints Core Low-level transaction and state data from nodes Exchanges, analytics, integrators Private / self-hosted Engine State Complete current ledger state at engine level Advanced state queries Self-hosted (requires node config) System Node health and diagnostics Node operators Local only Gateway API (https://docs.radixdlt.com/docs/network-gateway) The Gateway API (https://docs.radixdlt.com/api-reference/gateway-api-specs.html) is the primary interface for dApp developers. It provides entity state queries, transaction submission, stream queries, and historical state access – all via JSON POST requests with cursor-based pagination. Official Endpoints Network URL Mainnet https://mainnet.radixdlt.com Stokenet (/contents/tech/releases/stokenet) https://stokenet.radixdlt.com These are rate-limited by IP. For production dApps, use a third-party provider or run your own Gateway (/developers/infrastructure/01-running-a-node) . Key Endpoint Groups - /state/* – entity details, resource (/contents/tech/core-concepts/resources) balances, metadata, vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) contents - /transaction/* – submit, preview, and check transaction status - /stream/transactions – query committed transactions with filters - /status/gateway-status – current ledger state version and epoch Use the Gateway SDK (/developers/frontend/02-gateway-sdk) (@radixdlt/babylon-gateway-api-sdk) for typed TypeScript access. What the Gateway Does When the Ledger Stops The Gateway is not a passive mirror of the ledger. It refuses to answer a state query once its own database has fallen too far behind, and it names the threshold in the error it returns. That behaviour became observable for the first time on 1 September 2026, during the network halt that followed the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) : mainnet committed its last round at 21:19:06 UTC on 31 August, and the public Gateway at mainnet.radixdlt.com spent the following day answering almost nothing. Probed at 23:08:58 UTC on 1 September 2026, twenty-five hours and fifty minutes after the last committed round: Endpoint Response /status/gateway-status 200 – returns the frozen ledger state itself /status/network-configuration 200 – static network metadata /transaction/preview 200 – full receipt, simulated against the frozen state /transaction/construction 500 NotSyncedUpError (request_type: Construction) /state/entity/details 500 NotSyncedUpError (request_type: Read) /state/validators/list 500 NotSyncedUpError /stream/transactions 500 NotSyncedUpError The error body carries the rule rather than leaving it to the documentation: current_sync_delay_seconds: 92992 against max_allowed_sync_delay_seconds: 720. Twelve minutes is the whole tolerance. Past it, a read fails rather than returning a value the Gateway can no longer vouch for. A halted network is an error, not a stale number A dApp reading balances through the public Gateway does not degrade gracefully to yesterday's figures when consensus stops – it degrades to HTTP 500. Frontends that only handle network failures and empty result sets will surface an unexplained crash. Read details.type and treat NotSyncedUpError as its own state, with current_sync_delay_seconds as the number to show the user. Two exceptions are worth knowing. /status/gateway-status keeps answering because the stale ledger state is its payload – it is how you measure the outage, and it is what tells you the epoch has not moved. And /transaction/preview keeps answering with a complete receipt, because an Engine (/contents/tech/core-protocols/radix-engine) simulation runs against whatever state the node holds and needs no freshness guarantee. During a halt you can still dry-run a manifest (/contents/tech/core-protocols/transaction-manifests) against the exact ledger as it stood at the final committed round; you simply cannot build a real transaction against it, because the epoch that would go in the header is the one endpoint the Gateway will not serve. Core API (https://docs.radixdlt.com/docs/network-apis) The Core API (https://docs.radixdlt.com/api-reference/core-api-specs.html) gives direct access to a node's view of the ledger – transaction-level detail, raw state, and streaming committed transactions. It includes an LTS (Long-Term Support) sub-API designed for exchange integrators. LTS Endpoints - /lts/transaction/submit – submit a notarized transaction - /lts/transaction/status – check transaction status by intent hash - /lts/state/account-all-fungible-resource-balances – all token balances for an account - /lts/transaction/construction – get current epoch for building transactions The Core API (https://docs.radixdlt.com/docs/core-api-providers) requires running your own node, and in practice that is now close to the only option. Of the two providers the documentation lists, only NowNodes (https://nownodes.io) is still operating, serving the Core API at xrd.nownodes.io under paid plans with a month-long free trial. The other, Grove, stopped running the gateway that served Radix: it announced on 10 November 2025 (https://medium.com/decentralized-infrastructure/groves-next-chapter-moving-up-the-stack-fd7ecaf0a184) that it was stepping away from operating the Grove Portal, migrated its public endpoint traffic to Pocket Network (https://pocket.network) over that month, and has since wound down as a company (https://www.grove.city) , with all 195 repositories in its GitHub organisation (https://github.com/buildwithgrove) archived. radix-mainnet.rpc.grove.city – the endpoint Radix's documentation still offers as immediate free access, capped at 5 million requests a day – no longer resolves in DNS, and neither does portal.grove.city. Pocket Network's public endpoints do not carry Radix, so following that step in the official docs reaches nothing at all. Engine State and System APIs Engine State API Provides complete current state at the Radix Engine (/contents/tech/core-protocols/radix-engine) abstraction level. More comprehensive than Core API (https://docs.radixdlt.com/docs/network-apis) state queries but requires explicit node configuration (available since node v1.1.3.1). Useful for advanced state inspection without running a full Gateway. System API Node diagnostics only – health checks, connection info, performance metrics. Used for monitoring, not application development. Which API Should I Use? Use Case API Frontend dApp reading account state Gateway SDK (/developers/frontend/02-gateway-sdk) Submitting transactions from dApp Gateway (via dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) ) Exchange integration (deposits, withdrawals) Core API (https://docs.radixdlt.com/docs/network-apis) (LTS endpoints) Indexing / analytics pipeline Core API (https://docs.radixdlt.com/docs/core-api-providers) (streaming) Node health monitoring System API Next Steps - Gateway SDK: Reading Ledger State (/developers/frontend/02-gateway-sdk) – the typed client most applications should use over raw HTTP - Building on Radix (/developers) – the wider index of tooling, SDKs, and community services External Links - Gateway API reference (https://docs.radixdlt.com/api-reference/gateway-api-specs.html) - Core API reference (https://docs.radixdlt.com/api-reference/core-api-specs.html) - Gateway API providers (/contents/tech/core-protocols/radix-gateway-api) - Core API providers (/contents/tech/core-protocols/radix-core-api) - API comparison (Learn Radix) (https://learn.radixdlt.com/article/what-apis-are-relevant-to-the-radix-public-network) Note: the previous *.redoc.ly spec hosts have been retired; all API specifications now live on the consolidated Radix documentation site (https://docs.radixdlt.com/docs/network-apis) . ## Radix Skills URL: https://radix.wiki/developers/ai-agents/radix-skills Updated: 2026-09-03 Summary: radix-skills is an installable agent skill that gives an AI coding agent a routed set of Radix reference material and instructs it to check what it re… Type Agent skill package Author xstelea (https://github.com/xstelea) Skills 1 (radix) Reference Files 40 (~534 KB) Requires Local radix-web3.js + radixdlt-scrypto checkouts Registry skills.sh (https://www.skills.sh/xstelea/radix-skills/radix) Licence None declared Published 21 June 2026 Repository GitHub (https://github.com/xstelea/radix-skills) Introduction radix-skills (https://github.com/xstelea/radix-skills) is an installable agent skill that gives an AI coding agent a routed set of Radix reference material and instructs it to check what it reads against local copies of the Radix source. The repository publishes a single skill, radix, whose stated purpose is to let an agent "build or debug Radix code from local source checkouts rather than memory or web snippets". It is the work of xstelea (https://github.com/xstelea) , who also maintains Radix Context (/developers/ai-agents/radix-context) , Hookah (/developers/tools/hookah) and the Awesome Radix MCP Servers (https://github.com/xstelea/awesome-radix-mcp-servers) index, and who described himself in the Radix DLT Official Telegram (https://t.me/radix_dlt/997291) on 6 August 2026 as previously "lead of the dApp engineering team", having "put all my accumulated radix knowledge into that skill". A skill differs from a context pack in what it does at load time. Radix Context (/developers/ai-agents/radix-context) copies 23 documents into a project and leaves the agent to find them. A skill is a described capability the agent selects on its own: the skills.sh (https://www.skills.sh/xstelea/radix-skills/radix) listing carries a description that tells the agent when the skill applies, and the skill body then routes to the one or two guides that fit the task instead of loading everything. The two projects are complementary rather than successive — radix-skills names radix-context in its own research strategy as an optional "candidate map for topics and vocabulary". What It Contains The skill ships 40 reference files totalling roughly 534 KB, of which 38 are topic guides named guide-*.md. Each guide states the source paths it is drawn from, a mental model, an example, and usage notes for one area of Radix work. The coverage is wide enough to be worth listing: - Transactions — manifest syntax (/developers/transactions/01-manifest-language) and instructions, the V1/V2 lifecycle (/developers/transactions/02-transaction-lifecycle) , Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) call sites, the Rust radix-transactions crate, subintents and pre-authorisations (/contents/tech/core-concepts/subintents-and-pre-authorizations) , receipts and events, and costing and fees (/developers/transactions/03-transaction-fees) . - Ledger primitives — resources (/contents/tech/core-concepts/resources) and vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) , metadata, native pools, packages and components (/contents/tech/core-concepts/components) , access rules (/developers/scrypto/03-authorization-and-badges) , role assignment, access controllers, account lockers, royalties, and SBOR (https://docs.radixdlt.com/docs/sbor) . - Client and wallet — the Gateway API (https://docs.radixdlt.com/docs/network-gateway) , transaction streaming with state-version checkpointing, the Radix Wallet (/developers/frontend/01-radix-dapp-toolkit) connect flow, and ROLA (/developers/frontend/03-rola-authentication) challenge generation and verification. - Staking — validator (/contents/tech/core-concepts/staking) behaviour, consensus-manager reads, liquid stake units (/contents/tech/core-concepts/liquid-stake-units) , claim NFTs (/contents/tech/core-protocols/nfts-on-radix) , unstaking and owner- badge (/contents/tech/core-concepts/badges) operations. - Tooling — the rdx CLI, the Rust scrypto and resim binaries, rtmc/rtmd manifest conversion, Effect service patterns, TypeScript configuration, dependency and supply-chain hygiene, testing, and error diagnostics. - Payments — a guide to x402 (https://x402.org/) payment middleware, facilitator validation and settlement, which the wiki covers separately at AI Agents & x402 Payments (/developers/ai-agents/ai-agents-and-x402) . Alongside the guides the repository carries a 40 KB Python validation script, validate-radix-skill.py, that checks the guides against the source repositories they cite, and an openai.yaml (https://github.com/xstelea/radix-skills/blob/main/radix/agents/openai.yaml) agent descriptor. Installation and Prerequisites The skill installs from the skills.sh (https://www.skills.sh/xstelea/radix-skills/radix) registry, an open-source skill index published by Vercel Labs, which detects the coding agent in use: npx skills add xstelea/radix-skills --skill radix Installation alone is not enough to use it as designed. The skill's prerequisite step requires two source checkouts at the root of the repository being worked on: ./.repos/radix-web3.js ./.repos/radixdlt-scrypto A bundled script, prepare-radix-sources.sh, clones both, adds them to .gitignore, and installs the rdx-cli (https://www.npmjs.com/package/rdx-cli) npm package globally when the rdx binary is missing. The script is written to fail rather than report success when git or npm is unavailable, when an existing checkout points at the wrong remote.origin.url, or when rdx-cli installs but rdx is not on PATH. The skill's own setup notes say a failed setup means "Radix-specific work is not source-backed yet". One consequence is recorded in the repository's own architecture decision record (https://github.com/xstelea/radix-skills/blob/main/docs/adr/0001-use-local-source-checkouts.md) , which chose local clones over submodules or vendoring: existing clones are never updated automatically, so a stale checkout will silently ground the agent in old source until someone refreshes it deliberately. Design: Routing, Not Recall The skill's research strategy is explicit about the order of authority, and it puts its own prose last. An agent is told to load the one matching guide, inspect similar code already in the user's repository, optionally consult radix-context (/developers/ai-agents/radix-context) as a vocabulary map, and then verify every context-derived fact against the source paths the guide names before using it in code. Public web documentation is reserved for questions local source cannot answer. Cloned repositories are read-only: the skill forbids importing application code from .repos. That ordering is a direct response to the failure mode these packages exist to fix. A model asked to write Scrypto (/developers/scrypto/01-fundamentals) or a transaction manifest (/contents/tech/core-protocols/transaction-manifests) from memory tends to produce plausible code against an API version that no longer exists, because Radix's surface has changed substantially across Babylon (/contents/tech/releases/radix-mainnet-babylon) and its protocol updates while the public corpus the model trained on did not. Pinning the answer to a checkout on disk makes the failure visible instead of silent — a missing or mismatched clone is an error the setup script raises, whereas a confidently wrong API call is not. Provenance and Caveats The 6 August 2026 announcement was a repost, not a release. The repository has been public since 21 June 2026 and its entire history is two commits made that day (https://github.com/xstelea/radix-skills/commits/main) , with no code changes in the seven weeks between publication and the announcement that drew the community's attention. The skills.sh (https://www.skills.sh/xstelea/radix-skills/radix) listing recorded six installs and the GitHub repository zero stars and one fork on the day it was announced — useful context for anyone reading the reaction as evidence of adoption. Re-read on 29 August 2026, three weeks later: nine installs, one star, one fork, and still the same two June commits, so the announcement moved the install count by three and the code not at all. Three points a prospective user should check for themselves: - No licence is declared. The repository carries no LICENSE file. By GitHub's own stated default (https://docs.github.com/en/site-policy/github-terms/github-terms-of-service) , publishing a repository without a licence grants other users no rights to reproduce, distribute or create derivative works beyond viewing and forking it — whatever the one-line install command implies. This is unlike the author's Hookah (https://github.com/xstelea/hookah) , which is MIT-licensed. - One of the two source anchors is not official. radixdlt/radixdlt-scrypto is the canonical Scrypto repository (https://github.com/radixdlt/radixdlt-scrypto) , but radix-web3.js (/developers/tools/radix-web3-js) is the author's own library — whose repository carries no LICENSE file either, though eight of its nine npm packages declare MIT in package.json — rather than a radixdlt (https://github.com/radixdlt) org project. Guidance about "the Radix codebase" therefore means the official engine plus one third-party TypeScript client, and the majority of the guides describe that client's package layout. - The registry's automated audits are not unanimous. skills.sh reports three scans of the skill: Gen Agent Trust Hub pass, Socket pass, and Snyk (https://snyk.io/) warn. A skill is instructions an agent will act on, and the setup script installs a global npm package and edits .gitignore, so the contents are worth reading before installing. External Links - radix-skills – GitHub Repository (https://github.com/xstelea/radix-skills) - radix skill – skills.sh listing (https://www.skills.sh/xstelea/radix-skills/radix) - xstelea/radix-web3.js – required source checkout (https://github.com/xstelea/radix-web3.js) - radixdlt/radixdlt-scrypto – required source checkout (https://github.com/radixdlt/radixdlt-scrypto) - rdx-cli on npm (https://www.npmjs.com/package/rdx-cli) - Announcement in Radix DLT Official Telegram (6 August 2026) (https://t.me/radix_dlt/997273) ## 9. Permissioned and Regulated Assets URL: https://radix.wiki/developers/scrypto/09-permissioned-and-regulated-assets Updated: 2026-09-03 Summary: Some assets are not meant to move freely. A tokenised bond may only be transferable between investors who have passed KYC; a credential must stay in t… Introduction Some assets are not meant to move freely. A tokenised bond may only be transferable between investors who have passed KYC; a credential must stay in the account it was issued to; a share class may need to be frozen or clawed back under a court order. On most smart-contract platforms this means writing transfer-hook logic inside the token contract and hoping every integration respects it. On Radix, tokens are not contracts. They are native resources (/developers/scrypto/02-resources-and-nfts) , and the rules governing their movement are declared on the resource (/contents/tech/core-concepts/resources) itself at creation time and enforced by the Radix Engine (/contents/tech/core-protocols/radix-engine) – not by the code that happens to be holding them. That makes permissioning both stronger and more constrained than a transfer hook, and the constraints are worth understanding before you design a regulated asset. This article covers the movement rules available on a resource, the account-side controls that sit opposite them, and the pattern to reach for when the requirement is "only accounts holding a credential may receive this" – which, as the next sections explain, is not something a deposit rule can express on its own. Movement Rules on the Resource Every behaviour of a resource – minting, burning, withdrawing, depositing, recalling, freezing, updating non-fungible data – is a role whose access rule (/contents/tech/core-concepts/access-rules-and-auth-zones) is set when the resource is created. Each role is paired with an _updater role that controls whether the first rule can ever be changed. Setting the updater to deny_all locks the rule permanently, and locking is one-way (https://docs.radixdlt.com/docs/resource-behaviors) : there is no path back to a mutable rule. The two roles that govern movement are withdrawer and depositor: let regulated_token = ResourceBuilder::new_fungible(OwnerRole::Fixed(rule!(require(admin_badge)))) .metadata(metadata! { init { "name" => "Regulated Token", locked; } }) .withdraw_roles(withdraw_roles! { withdrawer => rule!(require(transfer_agent_badge)); withdrawer_updater => rule!(require(admin_badge)); }) .deposit_roles(deposit_roles! { depositor => rule!(require(transfer_agent_badge)); depositor_updater => rule!(require(admin_badge)); }) .create_with_no_initial_supply(); A resource whose withdrawer is deny_all can never leave the vault it lands in – this is how soulbound tokens are built, and the usual reason to build one is to bind identity or reputation to an account. A resource whose depositor is deny_all can never be stored at all: it is a transient resource that must be burnt before the transaction ends, or the transaction fails with a dangling-resource error. That failure mode is a feature – it is how a blueprint (/contents/tech/core-concepts/blueprints-and-packages) forces a caller to complete a required step within the same transaction. Between those two extremes sits the useful case: gate the role behind a badge (/contents/tech/core-concepts/badges) . A withdraw rule of rule!(require(transfer_agent_badge)) means the tokens only move when that badge is presented as a proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) in the same transaction – so every transfer necessarily routes through whoever holds the badge. Freeze and Recall Two further roles exist specifically for regulated assets. Recall lets an authority pull a resource out of a vault it does not own. Freeze suspends movement of one particular vault, and it is finer grained than the word suggests. Both are declared the same way as the movement roles: .recall_roles(recall_roles! { recaller => rule!(require(admin_badge)); recaller_updater => rule!(deny_all); }) .freeze_roles(freeze_roles! { freezer => rule!(require(admin_badge)); freezer_updater => rule!(deny_all); }) A freeze is not one switch. VaultFreezeFlags (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine-interface/src/blueprints/resource/vault.rs) is a bitfield of three independent flags, WITHDRAW (1), DEPOSIT (2) and BURN (4), so an authority can stop a vault paying out while still letting deposits land in it, or block a burn without touching transfers at all. Whatever it sets is reversible: the engine exposes unfreeze beside freeze, taking the same flags, so a freeze is a suspension that can be lifted flag by flag rather than the one way seizure a recall amounts to. Recall is the sharper of the two: it is documented under the use case of rental NFTs (https://docs.radixdlt.com/docs/recalling-resources) , but it is equally the mechanism behind a clawback on a regulated instrument. It is also unavoidably a centralisation point, and one that is visible on-ledger, since a wallet displays a recallable resource as recallable. If your asset does not genuinely need it, leaving recall_roles unset is the safer default; if it does, holders can at least see the power exists before they accept the token. Because these are engine-enforced roles rather than contract logic, they apply wherever the resource goes. A DEX that never heard of your compliance rules still cannot move a frozen token, because the rule lives on the resource, not on the venue. Invoking Freeze and Recall Declaring the roles is the easy half. The part that catches people out is that neither operation is a Scrypto (/contents/tech/core-protocols/scrypto-programming-language) call. The Vault trait (https://github.com/radixdlt/radixdlt-scrypto/blob/main/scrypto/src/resource/vault.rs) a blueprint works with carries put, take, take_advanced, burn, create_proof_of_amount and the rest, and carries no freeze, unfreeze or recall method of any kind. A blueprint cannot freeze a vault or claw a resource back. A transaction manifest (/developers/transactions/01-manifest-language) can, through four instructions the manifest (/contents/tech/core-protocols/transaction-manifests) parser calls direct vault aliases: Instruction Arguments Returns RECALL_FROM_VAULT vault id, amount a bucket of the fungible resource RECALL_NON_FUNGIBLES_FROM_VAULT vault id, local ids a bucket of those non-fungibles FREEZE_VAULT vault id, flags nothing UNFREEZE_VAULT vault id, flags nothing Two consequences follow from that table. The first is the argument every one of them leads with: a vault id, meaning the internal_vault_ address of the one vault holding the asset, not the account that owns it and not the resource. Recalling from a holder is therefore a two step job, a Gateway (/developers/infrastructure/02-radix-apis) lookup of that account's vaults for the resource, then a manifest built against the vault address that comes back. Addresses and Entity Types (/developers/transactions/05-addresses-and-entity-types) covers why an internal vault has an address at all and why nothing can call it directly. The second is that a recall returns a Bucket. The recalled resource lands on the worktop (/contents/tech/core-concepts/worktop) like any other withdrawal, so the manifest has to put it somewhere, typically into the issuer's account or straight into a burn, before the transaction can end. The recaller or freezer badge is presented as a proof (/contents/tech/core-concepts/buckets-proofs-and-vaults) in that same manifest, and the engine checks the role exactly as it checks withdrawer and depositor. Why a Deposit Rule Cannot Check the Recipient The recurring question from developers building KYC-gated assets is some version of: can I set the deposit rule so the token only lands in accounts that hold a KYC badge? Directly, no – and the reason is worth understanding, because it is the same reason Radix authorisation avoids the caller-address bugs common elsewhere. An access rule is checked against the authorization zone (https://docs.radixdlt.com/docs/advanced-accessrules) of the running transaction: the set of proofs that have actually been presented. A proof of a badge sitting in someone else's account can only be created by that account, which requires its owner's authorisation. So when a third party pushes tokens to an account, there is no proof of the recipient's credential available for a rule to test. A depositor rule can say who is allowed to perform the deposit; it cannot say what the destination must already hold. The pattern that does satisfy the requirement inverts the direction of the transfer. Rather than pushing the asset, the issuer holds it in a component (/contents/tech/core-concepts/components) and the recipient claims it in their own signed transaction – at which point they can present their credential badge, and the rule can check it. This is the withdraw pattern (https://docs.radixdlt.com/docs/the-withdraw-pattern) , and it is the recommended shape for value flowing to users on Radix generally, not just for regulated assets. The official docs put the case bluntly: hard-coding a "send to the recipient's address" call from inside a blueprint forces a stack of assumptions about what the recipient component even is. The practical design, then, for a token restricted to credentialled holders: - Issue a non-transferable KYC badge to each approved account (withdrawer => rule!(deny_all)), so the credential cannot be lent or sold. - Gate the regulated token's withdrawer and depositor roles behind a badge held by your transfer component, so no transfer can bypass it. - Have the component verify the KYC badge proof of both parties within the transaction that moves the asset, then perform the withdraw and deposit itself. Where a component must also confirm which component called it, caller requirements (https://docs.radixdlt.com/docs/advanced-accessrules) – rule!(require(global_caller())) and rule!(require(package_of_direct_caller())) – provide implicit proofs of the calling actor. The docs flag these as advanced-use-only and advise explicit badge requirements wherever they will do the job, on the grounds that caller-based patterns on other chains have repeatedly been mis-applied into exploits. Account-Side Controls The other half of the picture belongs to the recipient. Radix Smart Accounts (/contents/tech/core-protocols/smart-accounts) are components, and every account owner configures what unknown third parties may deposit – a default deposit mode plus a per-resource preference map. Turning off deposits of unrecognised resources is what the community calls "no airdrop mode" (https://docs.radixdlt.com/docs/account-deposit-patterns) . The owner can always deposit into their own account by signing; everyone else goes through the account's try_deposit methods, which respect those settings. That leaves three sanctioned ways to get an asset to a user who is not present to sign: - Badge and claim – the recipient holds a badge and claims from your component whenever they choose. The default, and the one that keeps working when the user switches accounts. - Account locker – the asset is sent to a locker the user's wallet surfaces as a pending claim. A close substitute for "send to address", but it does not work for non-transferable tokens. - Authorized depositor – the user adds your dApp's badge to their account's authorised list in a transaction they sign, after which your deposits succeed regardless of their other settings. This is the narrow path for delivering a soulbound credential to one specific account, typically one the user proved with ROLA (/developers/frontend/03-rola-authentication) . Before a direct deposit, a backend can ask the Gateway (/developers/infrastructure/02-radix-apis) whether the account's deposit mode or resource preference would reject it, and fall back to a locker or a claim if so. Verifying a Credential Off-Ledger Compliance checks usually also need to happen outside a transaction – a backend deciding whether to show a trading screen, for instance. The Gateway API (/developers/frontend/02-gateway-sdk) answers the holdings question in one call when you already know the credential's resource address and ID: POST /state/non-fungible/location { "resource_address": "resource_rdx1...", "non_fungible_ids": ["#1#"] } The response returns, per ID, the owning_vault_address, its owning_vault_parent_ancestor_address and owning_vault_global_ancestor_address, and an is_burned flag – so comparing the global ancestor against the account you are checking settles both ownership and revocation in a single request. Going the other direction (does this account hold any of that resource?), POST /state/entity/details with opt_ins: { non_fungible_include_nfids: true } returns the account's non-fungible resources, with /state/entity/page/non-fungibles and /state/entity/page/non-fungible-vaults/ids for pagination. One caution: a Gateway read tells you the state at a ledger version, not at the moment your transaction executes. Treat it as a UX and routing signal – decide whether to offer the action, which deposit pattern to use – and let the on-ledger access rule remain the thing that actually enforces the restriction. Wallet Support for Restricted Transfers There is a live rough edge here worth planning around. A resource whose withdrawal requires a badge proof cannot be moved from the Radix Wallet (/contents/tech/core-protocols/radix-wallet) 's built-in transfer screen, because that flow builds a plain withdraw-and-deposit manifest and never creates the proof the rule demands. Today the answer is that your dApp must supply the manifest. That may change, though it has not moved in a month. Two pull requests opened on 23 July 2026 by community developer genkipool (/ecosystem/genkipool) propose having the wallet auto-attach the required badge: sargon #452 (https://github.com/radixdlt/sargon/pull/452) extends the PerAssetTransfers manifest builder to inject a list of ResourceSpecifier badges, calling create_proof_of_amount for fungibles and create_proof_of_non_fungibles for non-fungibles, and babylon-wallet-android #1446 (https://github.com/radixdlt/babylon-wallet-android/pull/1446) builds the wallet feature on top of it, at 2,625 added lines across 30 files against sargon's 126 across 10. Re-checked on 26 August 2026: both are still open against main, neither is a draft, and neither has been touched since 27 and 26 July respectively, which is four days after they were opened. Design for the manifest-supplied path. Wallet support here is a proposal by a community contributor rather than announced work, and nothing about its current state suggests a date. Next Steps - Transaction Manifest Language (/developers/transactions/01-manifest-language) – write the manifest that presents the proof and performs the restricted transfer - Testing Scrypto Blueprints (/developers/scrypto/05-testing-scrypto) – assert that an unauthorised transfer actually fails External Links - Resource Behaviors – Official Docs (https://docs.radixdlt.com/docs/resource-behaviors) - Advanced Access Rules – Official Docs (https://docs.radixdlt.com/docs/advanced-accessrules) - Account Deposit Patterns – Official Docs (https://docs.radixdlt.com/docs/account-deposit-patterns) - The Withdraw Pattern – Official Docs (https://docs.radixdlt.com/docs/the-withdraw-pattern) - Recalling Resources – Official Docs (https://docs.radixdlt.com/docs/recalling-resources) - Radix Gateway API Reference (https://radix-babylon-gateway-api.redoc.ly/) ## radix-web3.js URL: https://radix.wiki/developers/tools/radix-web3-js Updated: 2026-09-03 Summary: radix-web3.js is a community TypeScript monorepo that publishes nine npm packages for building on Radix: a core client, a wallet-connect client, an Ef… Type TypeScript package suite (monorepo) Author xstelea (https://github.com/xstelea) Packages 9 published on npm (https://www.npmjs.com/package/radix-web3.js) Runtime Node.js ≥ 20 and browser Built on Effect (https://effect.website/) Licence MIT in package.json; no LICENSE file in the repository First commit 26 January 2025 Last release 20 June 2026 Docs xstelea.github.io/radix-web3.js (https://xstelea.github.io/radix-web3.js/) Repository GitHub (https://github.com/xstelea/radix-web3.js) Introduction radix-web3.js (https://github.com/xstelea/radix-web3.js) is a community TypeScript monorepo that publishes nine npm packages for building on Radix: a core client, a wallet-connect client, an Effect (https://effect.website/) -based Gateway (/developers/frontend/02-gateway-sdk) client, transaction and streaming helpers, an SBOR (https://docs.radixdlt.com/docs/sbor) schema builder, an agent toolkit, and the rdx command-line tool. It is the work of xstelea (https://github.com/xstelea) , who described himself in the Radix DLT Official Telegram (https://t.me/radix_dlt/997291) on 6 August 2026 as previously "lead of the dApp engineering team", and who also maintains Radix Context (/developers/ai-agents/radix-context) , Radix Skills (/developers/ai-agents/radix-skills) and Hookah (/developers/tools/hookah) . It is not an official radixdlt (https://github.com/radixdlt) project and does not replace the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) , which remains the recommended front-end integration path. Its relevance is narrower and specific: it is the largest community-maintained TypeScript surface for Radix, it is the reference implementation the radix-skills (/developers/ai-agents/radix-skills) agent skill clones as one of its two required source checkouts, and it carries an agent-first transaction CLI that has no official counterpart. The Packages All nine packages are published from a single pnpm (https://pnpm.io/workspaces) workspace and versioned together with Changesets (https://github.com/changesets/changesets) ; the most recent release published all of them on 20 June 2026. Versions and monthly download counts below were read from the npm registry on 23 August 2026; the versions are unchanged from the 20 June release, so the download column is the only thing that moves. Package Version Downloads/mo Purpose radix-web3.js (https://www.npmjs.com/package/radix-web3.js) 0.6.3 236 Core client: accounts, keypairs, manifests (/developers/transactions/01-manifest-language) , balances, submission @radix-effects/gateway (https://www.npmjs.com/package/@radix-effects/gateway) 0.6.4 170 Effect-based Gateway API (/developers/infrastructure/02-radix-apis) client for Node and browser radix-connect (https://www.npmjs.com/package/radix-connect) 0.3.3 83 Encrypted Radix Wallet (/contents/tech/core-protocols/radix-wallet) interaction over Radix Connect (/contents/tech/core-protocols/radix-connect) Relay radix-agent-toolkit (https://www.npmjs.com/package/radix-agent-toolkit) 0.1.11 76 GOAT SDK (https://github.com/goat-sdk/goat) wallet integration exposing account and transaction tools to agents rdx-cli (https://www.npmjs.com/package/rdx-cli) 0.2.4 32 The rdx executable — agent-first Manifest (/contents/tech/core-protocols/transaction-manifests) V2 workflows @radix-effects/tx-tool (https://www.npmjs.com/package/@radix-effects/tx-tool) 0.2.4 105 Build, analyse, preview, sign, submit and track transactions @radix-effects/transaction-stream (https://www.npmjs.com/package/@radix-effects/transaction-stream) 0.1.11 60 Stream utilities for polling Gateway transaction history @radix-effects/sbor (https://www.npmjs.com/package/@radix-effects/sbor) 0.3.3 28 Schema builder for parsing SBOR-shaped values @radix-effects/shared (https://www.npmjs.com/package/@radix-effects/shared) 0.0.5 126 Shared Effect schemas and branded Radix domain types The SBOR package is explicitly a continuation rather than a new idea. The repository's own tribute note (https://github.com/xstelea/radix-web3.js#tribute) credits sbor-ez-mode and gateway-ez-mode (https://github.com/CalamariRadix/gateway-ez-mode) by daan_xrd as the origin of the developer-friendly decoding API, rebuilt here around Effect Schema, branded types and explicit encode/decode transforms. rdx: An Agent-First Transaction CLI The most distinctive package is rdx-cli (https://www.npmjs.com/package/rdx-cli) , which installs an rdx binary for driving Transaction Manifest V2 (/developers/transactions/02-transaction-lifecycle) workflows from files. Its README (https://github.com/xstelea/radix-web3.js/blob/main/packages/cli/README.md) is unambiguous that it is not a wallet: it "never stores, accepts, or derives private keys", and participants sign the generated hash.hex values out of band and return signature files. Commands are non-interactive and print JSON by default, which is the point — the intended caller is a coding agent or a script, not a person. A run moves through prepare → add signatures → notarize → submit → status, leaving artefacts on disk at each step (prepared.json, transactionIntent.json, staticAnalysis.json, notarizedTransaction.hex, submitResult.json). Direct child subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) are supported by passing a subintents workflow file at preparation. Read-only account and history commands query the Gateway and require no signing at all, and rdx llm prints an embedded Markdown guide written for coding agents. The scope is deliberately narrow, and the README states the limits plainly: Manifest V2 only, one root intent plus direct child subintents, Ed25519 keys and signatures only, out-of-band signing only, and no browser or hardware wallet pairing. Two operational cautions carry real risk — rdx defaults to Mainnet, and prepared artefacts are network-bound, so a transaction prepared against one network must not be submitted to another. Alongside the CLI the package ships a draft specification, Radix Agent Protocol (RAP/1) (https://github.com/xstelea/radix-web3.js/blob/main/packages/cli/Radix%20Agent%20Protocol%20(RAP)%20V1.md) , which describes the same workflow as a finite-state protocol — states, JSON payload shapes, transitions, validation rules and error shapes — in normative MUST/SHOULD language. RAP/1 is written to be implementable by an HTTP endpoint, a queue worker or an in-process SDK rather than only a CLI, and it is marked "Draft… not a final external standard"; it has no adopters outside this repository. Effect as the Design Choice The packages under the @radix-effects scope are built on Effect (https://effect.website/) , a TypeScript library that models errors, dependencies and resources (/contents/tech/core-concepts/resources) in the type system rather than in try/catch and ad-hoc wiring. The practical consequence for Radix work is that the failure modes a dApp actually hits — a Gateway timeout, a rejected intent, a transaction that never commits — become typed values a caller must handle, and services such as the Gateway client are injected rather than constructed inline. That choice is also the main adoption cost. Effect is a substantial dependency with its own idioms, and a team already using the official Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) and Gateway API SDK (https://www.npmjs.com/package/@radixdlt/babylon-gateway-api-sdk) takes on a second, unfamiliar programming model to use these packages. The repository's own agent instructions reflect how much of the design leans on it: they direct an agent to read the vendored Effect source for idiomatic usage before implementing anything. Adoption and Caveats Three things are worth checking before depending on it. - Usage is small, and the comparison is instructive. On 23 August 2026 the core package recorded 236 downloads in the previous month and rdx-cli 32, against 45,317 for the official @radixdlt/radix-dapp-toolkit (https://www.npmjs.com/package/@radixdlt/radix-dapp-toolkit) – a ratio of roughly 190 to 1. All nine packages together drew 916 downloads that month. The GitHub repository still carried 8 stars, 3 forks and 20 open issues, unchanged since the page was written. This is a personal project of substance, not an ecosystem standard. - The licence is inconsistent. Eight of the nine packages declare "license": "MIT" in their package.json, and @radix-effects/sbor declares none — but the repository itself carries no LICENSE file. Under GitHub's stated default (https://docs.github.com/en/site-policy/github-terms/github-terms-of-service) , publishing source without a licence grants no rights beyond viewing and forking, so the npm declaration and the repository disagree about what a user may do with the code. The author's Hookah (https://github.com/xstelea/hookah) , by contrast, ships an MIT LICENSE file. - It is effectively one maintainer. Of the repository's contributors, xstelea (https://github.com/xstelea) accounts for 172 commits; the remainder are release bots and a single three-commit outside contributor. Development has also been quiet — the last release was 20 June 2026 and the last commit of any kind 21 June 2026 ("Add radix-web3 agent skill"), so as of 23 August 2026 nothing has been pushed for nine weeks. The point about the licence matters beyond this repository, because radix-skills (/developers/ai-agents/radix-skills) instructs an agent to clone radix-web3.js as one of its two authoritative source checkouts. An agent grounding Radix answers in this code is grounding them in a community library whose reuse terms are ambiguous, and — unlike its companion checkout radixdlt/radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto) — one that does not describe official protocol behaviour. External Links - xstelea/radix-web3.js – GitHub Repository (https://github.com/xstelea/radix-web3.js) - Documentation site (https://xstelea.github.io/radix-web3.js/) - radix-web3.js on npm (https://www.npmjs.com/package/radix-web3.js) - rdx-cli on npm (https://www.npmjs.com/package/rdx-cli) - Radix Agent Protocol (RAP/1) draft (https://github.com/xstelea/radix-web3.js/blob/main/packages/cli/Radix%20Agent%20Protocol%20(RAP)%20V1.md) - Effect – the TypeScript library the packages are built on (https://effect.website/) - gateway-ez-mode – the SBOR package's acknowledged predecessor (https://github.com/CalamariRadix/gateway-ez-mode) ## Instruct (Transaction Manifest Builder) URL: https://radix.wiki/developers/tools/instruct Updated: 2026-09-03 Summary: Instruct is a browser-based visual builder for Radix transaction manifests . Rather than writing manifest text by hand, you assemble a transaction one… Type Visual transaction manifest (/contents/tech/core-protocols/transaction-manifests) builder (web) Status 🟡 Beta (self-labelled) Networks Radix Mainnet and Stokenet (/contents/tech/releases/stokenet) Built by The Radix Billboard team On-ledger component (/contents/tech/core-concepts/components) None – the tool is off-ledger Overview Instruct is a browser-based visual builder for Radix transaction manifests (/contents/tech/core-protocols/transaction-manifests) . Rather than writing manifest text by hand, you assemble a transaction one instruction at a time in a form, and submit the result to Radix Mainnet or Stokenet (/contents/tech/releases/stokenet) through the Radix Wallet (/contents/tech/core-protocols/radix-wallet) . Its authors describe it as "a user-friendly tool designed for both developers and advanced Radix users" (https://instruct.radixbillboard.com/about) for creating manifests "within your web browser", with direct execution on either network. It is the second project from the team behind The Radix Billboard (https://radixbillboard.com) , a Radix-hosted take on the Million Dollar Homepage. Instruct carries a Beta label in its own header, and the Building on Radix (/developers) hub lists it alongside the RadixScan Manifest Builder (https://console.radixscan.io/manifest-builder) as one of the two community manifest builders. How it works A manifest is built as an ordered list of instruction rows. Each row picks a command from a searchable selector and fills in its arguments; rows carry an individual Enabled toggle, so an instruction can be switched off and kept rather than deleted — useful when narrowing down which step of a manifest is failing. The editor validates as you type and reports errors inline (an empty row shows Instruction command missing) and refuses to send an invalid manifest. A free-text transaction message field attaches a message to the transaction, and manifests can be imported from existing text as well as built from scratch. Alongside the builder the app keeps a History of submitted transactions and an Addresses book for the entity addresses a manifest refers to — the two things that otherwise have to be pasted from an explorer each time. The network switch in the header moves the whole session between Mainnet and Stokenet. Reflecting the editor's density, the app declines to run on small screens by default, showing a "Not for mobile" interstitial with a continue-anyway option. Because a manifest built here is submitted through the wallet like any other, the usual Radix guarantee applies: what the wallet shows before you sign is what the transaction does. Instruct makes that point itself — "the outcome of any transaction you execute is exactly what is displayed in your wallet when you sign the transaction on your phone" (https://instruct.radixbillboard.com/about) . Scope and limits Instruct is deliberately general rather than specialised. Its stated aim is to "support the creation of any transaction manifest, regardless of its complexity" (https://instruct.radixbillboard.com/about) — a multi-purpose tool rather than a bespoke one — and the authors are explicit that it is not meant to replace purpose-built interfaces: a DEX's own swap UI or the Radix Developer Console (https://console.radixdlt.com/) 's token-creation and metadata utilities will give a better experience for those specific jobs. The natural use is the transaction no existing UI covers. Two limits are worth stating plainly. The tool has no on-ledger component (/contents/tech/core-concepts/components) — it is an off-ledger manifest editor, so there is no component to trust with funds, and equally no on-ledger audit of the tool itself. And it is in Beta: the authors disclaim liability for bugs and put responsibility for any submitted manifest on the user. Verify the outcome in the wallet before signing, and prefer Stokenet (/contents/tech/releases/stokenet) while learning the instruction set. Where it fits Manifests can be produced several ways on Radix, and the right one depends on how often you need it. Instruct and the RadixScan builder are the interactive route — no toolchain, useful for a one-off administrative transaction, for learning the instruction set, or for reproducing a transaction someone has described. For manifests generated by an application, the programmatic route is the Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) or the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) 's sendTransaction, and for scripting from a terminal there is the community radix-web3.js (/developers/tools/radix-web3-js) suite. Reading the manifest language directly is covered in Manifest Language (/developers/transactions/01-manifest-language) . External Links - Instruct – manifest builder (https://instruct.radixbillboard.com) - Instruct – About / FAQ (https://instruct.radixbillboard.com/about) - The Radix Billboard (https://radixbillboard.com) - The Radix Billboard – Telegram (https://t.me/+oZXI_fr9rLIzNTAy) - The Radix Billboard – Discord (https://discord.gg/MHhCVaCEkv) ## 5. Addresses and Entity Types URL: https://radix.wiki/developers/transactions/05-addresses-and-entity-types Updated: 2026-09-03 Summary: On most ledgers an address is an opaque hash: nothing in it tells you whether you are looking at a wallet, a token, or a contract, and nothing tells y… Encoding Bech32m (https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) (BIP-350) Structure _ + 1 + payload First payload byte Entity type discriminant Mainnet suffix rdx (network id 1) Stokenet (/contents/tech/releases/stokenet) suffix tdx_2_ (network id 2) Source of truth radix-common/src/address (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address/hrpset.rs) Introduction On most ledgers an address is an opaque hash: nothing in it tells you whether you are looking at a wallet, a token, or a contract, and nothing tells you which network it belongs to. A Radix address states both in plain text before you decode a single byte. account_rdx12... is an account on mainnet; resource_tdx_2_1t... is a token on Stokenet (https://docs.radixdlt.com/docs/network-gateway) . That is not cosmetic. The Bech32m (https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) human-readable prefix carries two independent facts – the entity type and the network – and the decoder cross-checks the prefix against the type byte inside the payload, so an address that claims to be one kind of thing and encodes another is rejected rather than misread. This page describes the format as the ledger actually implements it, citing radix-common/src/address (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address) rather than prose documentation. Addresses are the values you put in a transaction manifest (/developers/transactions/01-manifest-language) , and the Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) is what encodes and decodes them off-ledger. Anatomy of an Address Every global address is a Bech32m string in three parts: account_rdx12y02de8ma5jz9pxkvgzr7g5v4g7hd44rvz4ynqvz3xy4cqe4vw6a2j └──────┬──────┘│└────────────────────────┬────────────────────────┘ HRP │ payload separator - HRP – _, assembled by HrpSet (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address/hrpset.rs) from the NetworkDefinition (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/network/mod.rs) 's hrp_suffix. There is one HRP per entity class per network. - 1 – the Bech32 separator. It cannot appear in the payload, so the last 1 in the string always marks the boundary. - Payload – the entity's node id in base-32, ending in a six-character checksum. The first decoded byte is the entity type discriminant. AddressBech32Decoder (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address/decoder.rs) performs three checks in order: the string must decode as Bech32m specifically (plain Bech32 is rejected with InvalidVariant), the first payload byte must map to a known EntityType, and the HRP actually present must equal the HRP that entity type is supposed to carry on this network – otherwise InvalidHrp. The last check is the one that matters for integrations: a well-formed address for the wrong network, or a resource address relabelled as a component (/contents/tech/core-concepts/components) , fails to decode rather than resolving to something unexpected. Entity Prefixes The HRP entity component is fixed per class of addressable thing. These are the global entities – the ones that appear in manifests (/contents/tech/core-protocols/transaction-manifests) and block explorers: Prefix Entity Type byte package_ Package (/contents/tech/core-concepts/blueprints-and-packages) – published blueprint code 13 resource_ Resource (/contents/tech/core-concepts/resources) manager – fungible (93) or non-fungible (154) 93 / 154 component_ Generic ( Scrypto (/contents/tech/core-protocols/scrypto-programming-language) ) component instance 192 account_ Account (/contents/tech/core-protocols/smart-accounts) – allocated (193) or preallocated (209 / 81) 193 / 209 / 81 identity_ Identity (/contents/tech/core-protocols/personas) – backs Personas 194 / 210 / 82 validator_ Validator (/contents/tech/core-concepts/validator-nodes) 131 consensusmanager_ Consensus Manager (/contents/tech/core-concepts/consensus-manager) – one per network 134 transactiontracker_ Transaction Tracker (/contents/tech/core-concepts/transaction-tracker) – one per network 130 accesscontroller_ Access Controller (/contents/tech/core-concepts/access-controller) 195 pool_ Pool (/contents/tech/core-concepts/radix-pools) – one-, two-, or multi-resource 196–198 locker_ Account Locker (/contents/tech/core-concepts/locker-blueprint) 104 Type bytes are the u8 discriminants of the EntityType (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/types/entity_type.rs) enum. The source file notes that this table is mirrored in REP-60 and that prefix values are allocated under REP-71 – so the numbers are a deliberate, versioned assignment, not incidental ordering. Why the First Payload Characters Are Readable The discriminants are chosen so that the base-32 encoding of the type byte spells a mnemonic. Each payload character carries five bits: the entity byte's top five bits select the first character outright, and its bottom three bits constrain the second to one of four. So GlobalValidator = 0b10000011 gives 10000 → s (system) and 011 → one of v, d, w, 0. Every validator address on the network therefore begins validator_rdx1s followed by one of those four characters – which holds for every validator entity on mainnet, not merely the registered ones: at epoch 338479 the ledger carried 287 validator components, 188 of them registered, and all 287 conform. The families are: - p – package · c – standard global component (account, identity, access controller, pool) · d – account locker - s – system component (consensus manager, validator, transaction tracker) - t – fungible ("token") resource and vault · n – non-fungible resource and vault - 6 – preallocated Secp256k1 entity · 2 – preallocated Ed25519 entity - l – internal component · k – internal key-value store The well-known native addresses go further and use vanity payloads, which is why the faucet reads component_rdx1cpt...faucet and XRD reads resource_rdx1tkn...radxrd. For ordinary entities only the first two characters are predictable; the rest is the node id. Network Specifiers The suffix after the entity name is the network's hrp_suffix, defined alongside its numeric id in NetworkDefinition (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/network/mod.rs) : Network Id Suffix Example Mainnet 1 rdx account_rdx1... Stokenet (/contents/tech/releases/stokenet) 2 tdx_2_ account_tdx_2_1... Localnet 240 loc account_loc1... Simulator (resim) 242 sim account_sim1... The retired testnets keep their reservations – adapanet (10, tdx_a_), nebunet (11, tdx_b_), and the three RCnet (/contents/tech/releases/rcnet) generations kisharnet (12, tdx_c_), ansharnet (13, tdx_d_) and zabanet (14, tdx_e_) – so addresses captured from those networks still decode as historical artefacts and can never be confused with mainnet. Telling networks apart. A recurring question is how to check whether a component or package is on Stokenet or mainnet. There is no on-ledger flag to query, because an address is only meaningful within the network that issued it: the suffix is the answer. Compare the network suffix rather than pattern-matching the whole prefix – account_rdx and account_tdx_2_ share the leading account_, and a naive startsWith on the entity name alone will match both. Decode the address instead and read the network back, which is what the Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) does; the Gateway (https://docs.radixdlt.com/docs/network-gateway) you point at is itself network-specific, so a mismatched address simply will not resolve. Global and Internal Entities EntityType splits every entity into global and internal, and the HRP reflects the split. Global entities are independently addressable and can be called from a manifest. Internal entities are owned by exactly one parent and reached only through it, so they carry an internal_ HRP: - internal_vault_ – a fungible or non-fungible vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) inside a component or account - internal_component_ – a component instance owned by another component - internal_keyvaluestore_ – a key-value store, whose substates are treated as independent for contention and versioning This is the addressing-level view of the substate model (/contents/tech/core-concepts/substate-model) : a vault holding your XRD has a real address, but you cannot call it directly – you go through the account (/contents/tech/core-protocols/smart-accounts) that owns it. Seeing an internal_vault_ address in a transaction receipt where you expected a resource_ address usually means you read a balance-change entry instead of the resource itself. Preallocated Addresses Most accounts on Radix were never created by a transaction. A preallocated (formerly "virtual") account or identity address is derived deterministically from a public key, so it is a valid destination before anything exists at it on-ledger; the account component is instantiated the first time it is used. The signature scheme is part of the entity type, which makes it visible in the address: - GlobalPreallocatedEd25519Account (81) → account_rdx12... – the scheme the Radix Wallet (/contents/tech/core-protocols/radix-wallet) uses for accounts created on Babylon (/contents/tech/releases/radix-mainnet-babylon) - GlobalPreallocatedSecp256k1Account (209) → account_rdx16... – including accounts carried over from Olympia (/contents/tech/releases/radix-mainnet-olympia) - GlobalAccount (193) → account_rdx1c... – an account allocated by a transaction rather than derived from a key The same three-way split applies to identities (/contents/tech/core-protocols/personas) (82, 210, 194). The practical consequence: the second character of an account address tells you which curve secures it, before any ledger lookup. Deriving these addresses is a Radix Engine Toolkit function, not a Gateway call – it is pure computation over the public key. Transaction Identifiers The same HRP scheme covers the parts of a transaction, which is why a transaction id is self-describing in a log or an explorer URL: txid_ Transaction intent hash – the id you poll the Gateway with signedintent_ Signed transaction intent notarizedtransaction_ Notarized transaction – what is actually submitted subtxid_ Subintent (/contents/tech/core-concepts/subintents-and-pre-authorizations) hash, introduced with Transaction V2 ledgertransaction_ Ledger transaction hash roundupdatetransaction_ Round update – consensus-generated, not user-submitted systemtransaction_ System transaction, e.g. genesis and protocol updates These are hashes rather than addressable entities, so they carry no entity-type byte, but they take the network suffix – a txid_tdx_2_ is a Stokenet transaction. The distinction between the three intent-stage hashes matters when tracking a transaction: the intent hash is stable from the moment the intent is built, which is what makes it usable as an idempotency key. The full sequence is covered in Transaction Lifecycle (/developers/transactions/02-transaction-lifecycle) . Well-Known Addresses Native entities are allocated fixed node ids in native_addresses.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/native_addresses.rs) , so their addresses are constants you can hardcode. The payload is identical on every network; only the HRP changes: XRD (/contents/tech/core-protocols/xrd-token) resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd Consensus Manager consensusmanager_rdx1scxxxxxxxxxxcnsmgrxxxxxxxxx000999665565xxxxxxxxxcnsmgr Transaction Tracker transactiontracker_rdx1stxxxxxxxxxxtxtrakxxxxxxxxx006844685494xxxxxxxxxtxtrak Faucet (testnets) component_rdx1cptxxxxxxxxxfaucetxxxxxxxxx000527798379xxxxxxxxxfaucet Account package package_rdx1pkgxxxxxxxxxaccntxxxxxxxxxx000929625493xxxxxxxxxaccntx The XRD address above was confirmed against mainnet, not just read from source. The faucet is the clearest illustration of the network-suffix rule: the same component is component_tdx_2_1cptxxxxxxxxxfaucetxxxxxxxxx000527798379xxxxxxxxxfaucet on Stokenet, where it will actually dispense test XRD. Alongside these sit the native badge resources whose non-fungible ids stand in for authority rather than assets – the virtual signature badges resource_rdx1nfxxxxxxxxxxed25sgxxxxxxxxx002236757237xxxxxxxxxed25sg and its secpsg counterpart, plus package, validator and account owner badges. They are ordinary badges (/contents/tech/core-concepts/badges) as far as access rules (/contents/tech/core-concepts/access-rules-and-auth-zones) are concerned, which is how "the signer of this transaction" becomes something a rule can name. Working With Addresses Three failure modes account for most address bugs in integrations: - String matching instead of decoding. Checking startsWith("account_rdx") looks safe until a Stokenet address arrives, and it tells you nothing about whether the checksum is valid. Decode and inspect the returned EntityType. - Assuming Bech32. Radix uses Bech32m, and generic Bech32 libraries in encode mode will produce a checksum the decoder rejects. Confirm the variant your library emits. - Treating a resource address as a component address. They are structurally interchangeable strings but different entity classes; the decoder will catch the swap, the Gateway will return nothing useful, and a manifest built on it fails static validation. Static validation in the Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) catches all three locally, without a network round trip. For reading state at an address once you trust it, see Radix APIs (/developers/infrastructure/02-radix-apis) ; for putting addresses into transactions, see Transaction Manifest Language (/developers/transactions/01-manifest-language) . External Links - hrpset.rs – the HRP set for every entity and transaction part (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address/hrpset.rs) - entity_type.rs – EntityType discriminants and prefix derivations (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/types/entity_type.rs) - network/mod.rs – network ids and HRP suffixes (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/network/mod.rs) - decoder.rs – Bech32m validation and HRP cross-checking (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/address/decoder.rs) - native_addresses.rs – well-known native entity addresses (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/native_addresses.rs) - BIP-350 – Bech32m specification (https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) - Radix Engine Toolkit – Radix Documentation (https://docs.radixdlt.com/docs/radix-engine-toolkit) ## AgentWallet for Radix URL: https://radix.wiki/developers/ai-agents/agent-wallet-ai Updated: 2026-09-03 Summary: AgentWallet for Radix is an open-source, policy-constrained programmable wallet and SDK that lets an AI agent transact autonomously on Radix – perform… Type Programmable wallet and SDK for AI agents Package wallet-agent-ai (https://www.npmjs.com/package/wallet-agent-ai) on npm Latest version 2.0.3 (8 June 2026) Agent runtime LangChain / LangGraph, plus an MCP server Networks Radix Mainnet and Stokenet (/contents/tech/releases/stokenet) First release 0.1.0, 4 May 2026 Overview AgentWallet for Radix is an open-source, policy-constrained programmable wallet and SDK that lets an AI agent (/contents/tech/core-concepts/radix-for-ai-agents) transact autonomously on Radix (/contents/tech/core-protocols/radix-engine) – performing swaps, staking, and liquidity provision across the major DEXs, and full Weft Finance (/ecosystem/weft-finance) operations – while on-chain rules enforce owner-defined spending limits and allowlists. It is released under the GPL-3.0 license by the developer linuxx_xrd. Security Model The agent never holds funds directly. The owner deploys an on-chain PolicyVault, funds it, and configures rules. Two badges (/contents/tech/core-concepts/badges) are minted: an Agent Session Badge (non-transferable, held by the agent's notarizer account) and a PolicyVault Owner Badge (held by the human owner). Every transaction is checked on-chain for a valid badge, a within-limit spend, and an allowlisted destination or protocol before it can execute. Capabilities Version 2.0 added liquidity-provision adapters for CaviarNine (/ecosystem/caviarnine) QuantaSwap, Ociswap (/ecosystem/ociswap) PrecisionPool, and DeFiPlaza (/ecosystem/defiplaza) ; dedicated tools for adding and removing LSULP (/contents/tech/core-concepts/liquid-stake-units) ; auto-stake and unstake across a whitelist of top validators; and a full Weft Finance (/ecosystem/weft-finance) adapter (supply, withdraw, create CDP, borrow, repay, remove collateral, health). Swaps route through the AGGR aggregator (an Astrolescent (/ecosystem/astrolescent) instance), and the toolkit ships MCP tools (/developers/ai-agents/ai-agents-and-x402) for agent workflows. A companion demo, AI Ventures (/ecosystem/ai-ventures) , showcases agents running on-chain companies. Installation and Runtime AgentWallet is published to npm as wallet-agent-ai (https://www.npmjs.com/package/wallet-agent-ai) and ships an agent-wallet command-line entry point alongside the library. The CLI is where the agent's own identity is set up: init creates the notarizer account, and derive, unlock and recover operate on a local encrypted keystore rather than on a hosted key service. That key signs transaction intents and pays fees; it is deliberately not the key that holds the funds, which is the point of the PolicyVault split described above. The package is an agent runtime, not only a signing library. It builds its tool surface for LangChain and LangGraph (https://www.langchain.com/langgraph) in a single LangChainTools.ts module, and its Model Context Protocol (/developers/ai-agents/ai-agents-and-x402) server exposes the same operations to any MCP client. Model providers are pluggable — the dependency list carries OpenAI, Google Gemini, Groq and Ollama (https://ollama.com/) adapters, so the wallet can be driven by a local model as easily as a hosted one. The DEX and lending integrations resolve against a checked-in registry of roughly 130 pools and 32 tokens, which is what lets the agent name a venue rather than be handed a component (/contents/tech/core-concepts/components) address. Transaction building does not go through the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) . Since version 2.0.1 the project depends on @steleaio/radix-engine-toolkit (https://www.npmjs.com/package/@steleaio/radix-engine-toolkit) , part of the community radix-web3.js (/developers/tools/radix-web3-js) suite, and pins it exactly at 2.0.0-dev.5 — a prerelease published on 4 March 2026 that draws about 35 downloads a month. That is a reasonable choice for an agent-first codebase, and it is also a single upstream maintainer and an unreleased version underneath the layer that assembles every transaction. Worth knowing before you build on it. Project Status (checked August 2026) AgentWallet is young and moves in bursts. The repository (https://github.com/wallet-agent-ai/wallet-agent-ai) was created on 16 May 2026 and its own changelog (https://github.com/wallet-agent-ai/wallet-agent-ai/blob/v2.0/CHANGELOG.md) dates 0.1.0 to 4 May, 1.0.0 to 10 May and 2.0.0 to 29 May 2026 — the staking, swap and badge tooling, then the three DEX liquidity adapters and the Weft Finance (/ecosystem/weft-finance) CDP surface, inside four weeks. Five versions are published on npm, the most recent being 2.0.3 on 8 June 2026, and the last commit of any kind is dated 16 June 2026. Uptake is early-stage to match: about 119 npm downloads in the month to 9 August 2026, and two GitHub stars. Two practical notes for anyone reading the source. The repository's default branch is v2.0, not main or master — a deep link written against /blob/main/ will silently 404, and the older master and main-old branches are still present. And although GitHub's licence detector reports the repository as unrecognised, the LICENSE file (https://github.com/wallet-agent-ai/wallet-agent-ai/blob/v2.0/LICENSE) is the verbatim GNU General Public License v3 and package.json declares GPL-3.0: the copyleft terms are real, and they apply to anything you build on top of the SDK itself. External Links - wallet-agent-ai – GitHub (https://github.com/wallet-agent-ai/wallet-agent-ai) - AgentWallet – Website (https://wallet-agent-ai.github.io) - wallet-agent-ai – npm (https://www.npmjs.com/package/wallet-agent-ai) - AgentWallet changelog (https://github.com/wallet-agent-ai/wallet-agent-ai/blob/v2.0/CHANGELOG.md) - Wallet-Agent-AI – Telegram (https://t.me/agent_wallet_ai_radix) ## 6. Vault and Resource Patterns URL: https://radix.wiki/developers/scrypto/06-vault-patterns Updated: 2026-09-03 Summary: Radix enforces a strict invariant: every resource must exist inside a container at all times. There are two container types: Vaults (permanent, on-led… Introduction Radix enforces a strict invariant: every resource (/contents/tech/core-concepts/asset-oriented-programming) must exist inside a container at all times. There are two container types: Vaults (https://docs.radixdlt.com/docs/buckets-and-vaults) (permanent, on-ledger storage) and Buckets (https://docs.radixdlt.com/docs/resources) (temporary, transaction-scoped carriers). The Radix Engine (/contents/tech/core-protocols/radix-engine) guarantees that resources (/contents/tech/core-concepts/resources) cannot be duplicated, accidentally destroyed, or left in limbo – if your transaction ends with an undeposited bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) , it fails. This "physical resource" model eliminates entire categories of bugs common in other smart contract platforms. Vault Patterns Single-Vault Component The simplest pattern: a component (/contents/tech/core-concepts/components) holds one vault to store a single resource type. A token sale component, for example, stores tokens in a vault and returns XRD (/contents/tech/core-protocols/xrd-token) payment to the buyer's account. struct TokenSale { token_vault: Vault, // holds tokens for sale xrd_vault: Vault, // collects XRD payments price: Decimal, } Multi-Vault Component (HashMap) When a component needs to manage arbitrary resource types (e.g. a DEX liquidity pool or a wallet-like component), use a HashMap. When a new resource type is deposited, create a new vault; when an existing type arrives, deposit into the matching vault. struct MultiVault { vaults (https://docs.radixdlt.com/docs/resources) : HashMap, } impl MultiVault { pub fn deposit(&mut self, bucket: Bucket) { let addr = bucket.resource_address(); self. vaults (https://docs.radixdlt.com/docs/buckets-and-vaults) .entry(addr) .or_insert_with(|| Vault::new(addr)) .put(bucket); } } Vault Take & Put Withdraw resources from a vault with .take(amount) (returns a Bucket) or .take_all(). Deposit with .put(bucket). For non-fungibles, use .take_non_fungible(&id) or .take_non_fungibles(&ids) to withdraw specific items. Bucket Patterns Bucket Passing (Move Semantics) Buckets (https://docs.radixdlt.com/docs/resources) use Rust's ownership model – passing a bucket to a function moves it. The caller no longer has access. This prevents double-spending at the language level: // Caller creates a bucket, passes it to the component let payment: Bucket = account.withdraw(xrd_address, dec!("100")); let tokens: Bucket = sale_component.buy(payment); // 'payment' is now consumed — cannot be used again account.deposit(tokens); Bucket Splitting Use .take(amount) on a bucket to split it into two buckets – the original retains the remainder. This is how you implement partial fills, fee extraction, or distributing resources across multiple destinations within a single transaction. The Worktop In transaction manifests (/contents/tech/core-protocols/transaction-manifests) , returned resources land on the worktop (/contents/tech/core-concepts/worktop) – a temporary staging area. Use TAKE_FROM_WORKTOP to create named buckets from worktop resources, then pass them to subsequent method calls. The transaction fails if any resources remain on the worktop at the end. Next Steps - Multi-Component Architecture (/developers/scrypto/07-multi-component-architecture) – split a growing dApp across components that call each other External Links - Vaults and Buckets – Official Docs (https://docs.radixdlt.com/docs/buckets-and-vaults) - Resources – Official Docs (https://docs.radixdlt.com/docs/resources) - Permissioned and Regulated Assets (/developers/scrypto/09-permissioned-and-regulated-assets) – freeze, recall and withdrawal rules on resources, with worked examples ## 8. Oracle Integration URL: https://radix.wiki/developers/scrypto/08-oracle-integration Updated: 2026-09-03 Summary: Scrypto components execute deterministically on the Radix Engine and can only access data already present on the ledger – they cannot make HTTP calls… Challenge Scrypto Oracles Challenge (https://radixdlt.medium.com/scrypto-oracles-challenge-is-live-the-radix-blog-radix-dlt-6b958c4d9948) Example Provider RedStone on Radix (https://blog.redstone.finance/2025/06/12/redstone-brings-secure-gas-efficient-oracle-solutions-to-radix-defi-ecosystem/) Introduction Scrypto (/developers/scrypto/01-fundamentals) components (/contents/tech/core-concepts/components) execute deterministically on the Radix Engine (/contents/tech/core-protocols/radix-engine) and can only access data already present on the ledger – they cannot make HTTP calls or read external APIs. When a dApp needs external data (asset prices, exchange rates, weather data, random numbers), it requires an oracle: a service that bridges off-chain information to on-ledger state. Oracle design is one of the most challenging aspects of decentralised application development. This article covers the two main oracle patterns on Radix, their trade-offs, and how to integrate existing oracle providers. Push Oracles A push oracle is an off-chain service that periodically submits transactions to update on-ledger price data. A Scrypto (/developers/scrypto/01-fundamentals) component stores the latest values and exposes a read method that other components call. Architecture - An off-chain relayer monitors data sources (exchange APIs, aggregator feeds). - The relayer signs and submits a transaction calling update_price(asset, price, timestamp) on the oracle component. - The oracle component, protected by an admin badge (/developers/scrypto/03-authorization-and-badges) , stores the update in an on-ledger vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) or key-value store. - Consumer components call get_price(asset) to read the latest value. Trade-offs - Pros: Simple consumer integration, predictable data freshness, works with any data type. - Cons: Relayer must pay transaction fees for every update, data staleness between updates, single-point-of-failure if the relayer goes offline. Mitigations Include a timestamp field in each price update and check staleness in consumer logic: reject prices older than a threshold (e.g. 5 minutes). Use multiple independent relayers with a median/aggregation mechanism to reduce trust assumptions. A staleness check alone is not enough: a feed can be rewritten on schedule and still carry a value that is wrong by orders of magnitude, which is what happened to the largest money market on Radix in August 2026 ( below (#when-a-feed-is-fresh-and-wrong) ). Pull Oracles A pull oracle delivers data within the consumer's transaction rather than pre-posting it on-ledger. The oracle provider signs the data off-chain, and the consumer's transaction manifest (https://docs.radixdlt.com/docs/learning-to-create-and-use-transaction-manifests) includes both the signed data payload and a verification call to the oracle contract. Architecture - The consumer's frontend fetches a signed price attestation from the oracle provider's API. - The frontend constructs a transaction manifest (/contents/tech/core-protocols/transaction-manifests) that first calls the oracle component's verify_and_store(signed_data) method, then calls the consumer component's business logic. - The oracle component verifies the provider's signature and exposes the data for the remainder of the transaction. Trade-offs - Pros: Data is always fresh (fetched at transaction time), no relayer infrastructure needed, consumer pays the gas. - Cons: More complex frontend integration, requires the oracle provider to run a signing API, consumer must handle the multi-step manifest. RedStone (https://redstone.finance) on Radix RedStone (https://blog.redstone.finance/2025/06/12/redstone-brings-secure-gas-efficient-oracle-solutions-to-radix-defi-ecosystem/) is an example of a pull oracle that has integrated with Radix. Its price feeds are delivered as signed payloads that Scrypto (/developers/scrypto/01-fundamentals) components verify on-chain, treating the data as a first-class resource (/contents/tech/core-concepts/resources) within the asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) model. Supra (https://www.prnewswire.com/news-releases/supraoracles-integrates-with-radix-the-full-stack-layer-1-smart-contract-platform-302009059.html) on Radix Supra (https://www.prnewswire.com/news-releases/supraoracles-integrates-with-radix-the-full-stack-layer-1-smart-contract-platform-302009059.html) is a second oracle provider on Radix, offering both push and pull price feeds for 100+ of the most-traded crypto asset pairs, plus decentralised randomness through a verifiable random function (https://en.wikipedia.org/wiki/Verifiable_random_function) (VRF). The VRF is useful for on-ledger gaming, lotteries, and fair NFT (/contents/tech/core-protocols/nfts-on-radix) distribution, where a manipulable random source would be exploitable. When a feed is fresh and wrong Both patterns above treat the danger as data going out of date. It is worth reading one production failure closely, because the mitigation recommended above – a timestamp and a staleness threshold – would not have caught it. On 30 August 2026 the largest lending market on Radix was drained by a feed that was neither stale nor unsigned. It was being rewritten every ten minutes, exactly as designed, with a number that had been wrong by roughly seven orders of magnitude for two days. What the ledger records Weft Finance (/ecosystem/weft-finance) reads collateral values from a single push oracle it registers as "Default PriceFeed" ( component (https://dashboard.radixdlt.com/component/component_rdx1czdvvanvdy6495phfgz8uv6n2semp2cpexcg6vvty6uaycc82adgyv) ). A relayer account calls update_prices on it with a map of twenty assets, on a ten-minute cadence, authorised by one non-fungible badge (/contents/tech/core-concepts/badges) ; three of those badges exist and the resource carries no on-ledger metadata, so nothing on the ledger says whose price authority this is. At 12:35:17 UTC on 28 August 2026, in one of those routine calls ( transaction (https://dashboard.radixdlt.com/transaction/txid_rdx17mgxz8dlmyzrrtppec9fer4lqfyl38j40skdql9f3xfyw2wvk88qfalnwp) , state version 556,254,628), the entry for HUG (/ecosystem/hug) went from 0.000131085370299542 XRD (/contents/tech/core-protocols/xrd-token) , a figure the feed had carried unchanged for at least four weeks, to 1289.783156723014634465 – the band the same feed uses for dollar stablecoins. It stayed in that band for the next 53 hours, drifting a little on each cycle, and 324 further transactions touched the component before the borrow (https://dashboard.radixdlt.com/transaction/txid_rdx12lsyuggs587xt7m9uxjedtkdtz0lcnzh85g2w4x6wwdq3cuyhccs8ls3kc) at 18:02:58 on 30 August drew about 71 million XRD of debt against 539,703 HUG the same transaction had bought for 70.6 XRD. The last write before that borrow put HUG at 1,330.41 XRD. Why a staleness check does not help Every one of those 324 writes carried a current timestamp, and most carried a value that differed from the one before it. A consumer rejecting anything older than five minutes would have accepted all of them. The price was live; what it meant was wrong. Freshness describes when a value was written and says nothing about whether it is true, so a staleness guard is necessary and never sufficient. Checks that address the actual failure - Cap the move per update. HUG changed by a factor of about ten million between two consecutive writes ten minutes apart. A per-asset deviation cap turns that into a rejected update rather than a priced position. - Bound each asset to a plausible band and halt the market for it outside that band, rather than continuing to lend against a number no one has looked at. - Cross-check against a venue you can read on-ledger. HUG's real price was available inside the attacking transaction itself, on the Ociswap (/ecosystem/ociswap) pool that sold it. A component that compares a feed against on-ledger pool state is comparing two independent sources rather than trusting one. - Price against depth, not quantity. On the cached figure the collateral scanned as roughly 718 million XRD; the entire HUG market held about a thousand dollars of pooled liquidity. A borrow larger than the market for the collateral is a liquidation that cannot clear. - Keep an off switch that does not need a redeploy – a per-asset disable the protocol can reach without shipping new code. What the operator did next The remedy was not to price the affected assets correctly. From 00:15:54 UTC on 31 August 2026 the same ten-minute call floors ten native Radix tokens at 0.0000000001 XRD apiece – WEFT itself, HUG, EARLY, OCI, ASTRL, DFP2, CAVIAR, SRG, FLOOP and MOX – while the ten wrapped and bridged assets in the same map keep real quotes. Read at 07:05:59 UTC (https://dashboard.radixdlt.com/transaction/txid_rdx1hdpwt9hxclh80xlylgru6mxmmnpevrqu7q82fc92sfk30ywlp53sjrjmm5) the floor was still being rewritten on every cycle. Pricing an asset at effectively zero withdraws it from collateral service through the oracle, without touching the component; it is the off switch of the previous point, reached by the only lever the operator had left. Next Steps - Transaction Manifest Language (/developers/transactions/01-manifest-language) – drive your components from the outside, the way users actually will - Permissioned and Regulated Assets (/developers/scrypto/09-permissioned-and-regulated-assets) – withdraw and deposit rules, freeze, recall, and the account-side deposit controls External Links - Scrypto Oracles Challenge – Radix Blog (https://radixdlt.medium.com/scrypto-oracles-challenge-is-live-the-radix-blog-radix-dlt-6b958c4d9948) - RedStone on Radix – RedStone Blog (https://blog.redstone.finance/2025/06/12/redstone-brings-secure-gas-efficient-oracle-solutions-to-radix-defi-ecosystem/) - SupraOracles integrates with Radix – PRNewswire (https://www.prnewswire.com/news-releases/supraoracles-integrates-with-radix-the-full-stack-layer-1-smart-contract-platform-302009059.html) - Will Radix Offer Decentralized Data Storage? – Radix Blog (https://www.radixdlt.com/blog/will-radix-offer-decentralized-data-storage) ## 7. Multi-Component Architecture URL: https://radix.wiki/developers/scrypto/07-multi-component-architecture Updated: 2026-09-03 Summary: Scrypto separates the concept of "smart contract" into two distinct things: blueprints (reusable templates) and components (live instances on the ledg… Catalog Blueprint Catalog (https://www.radixdlt.com/blog/build-defi-dapps-faster-on-radix) Introduction Scrypto (/developers/scrypto/01-fundamentals) separates the concept of "smart contract" into two distinct things: blueprints (/contents/tech/core-concepts/blueprints-and-packages) (reusable templates) and components (/contents/tech/core-concepts/components) (live instances on the ledger). This separation enables a modular architecture where small, well-tested blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) are composed into larger systems – much like how object-oriented programming uses classes and composition. The official Scrypto Design Patterns (https://docs.radixdlt.com/docs/reusable-blueprints-pattern) documentation recommends this approach as the default for non-trivial dApps. Separation of Concerns Instead of building a monolithic blueprint, decompose your dApp into small blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) with a single responsibility: - TokenSale – handles pricing and token distribution - Treasury – manages collected funds, fee withdrawal - AccessControl – issues and manages badges (/developers/scrypto/03-authorization-and-badges) - PriceFeed – wraps an oracle (/developers/scrypto/08-oracle-integration) and exposes prices to other components Each blueprint is easier to test in isolation, reason about for security, and audit independently. Smaller blueprints are also more reusable – a Treasury blueprint can serve a DEX, a lending protocol, or a DAO with no changes. Inter-Component Calls Components call each other's methods using their on-ledger address. A component can store another component's address in its state and invoke methods on it: struct MyDapp { treasury: Global, price_feed: Global, } impl MyDapp { pub fn buy(&mut self, payment: Bucket) -> Bucket { let price = self.price_feed.get_price("XRD/USD"); // ... calculate tokens owed ... self.treasury.deposit(payment); // ... return tokens ... } } Blueprint Reuse & the Catalog Radix encourages sharing blueprints as published packages that anyone can instantiate. The Blueprint Catalog (https://www.radixdlt.com/blog/build-defi-dapps-faster-on-radix) concept allows developers to find, audit, and reuse existing blueprints rather than reimplementing common patterns. Importing External Blueprints To use a blueprint from another package, import it by its package address and instantiate or call it. The Scrypto (/developers/scrypto/01-fundamentals) extern_blueprint! macro generates type-safe bindings: extern_blueprint! { "package_rdx...", // on-ledger package address PriceFeed { // blueprint name fn get_price(&self, pair: String) -> Decimal; } } This generates a type you can use in your component's state and method signatures, with full compile-time type checking. Factory Pattern A common pattern for dApps that create multiple similar components (e.g. a DEX creating liquidity pools): write a factory blueprint whose instantiation function creates and configures child components, returning their addresses and any admin badges (https://docs.radixdlt.com/docs/authorization-approach) . Next Steps - Oracle Integration (/developers/scrypto/08-oracle-integration) – bring off-ledger data in without giving up determinism External Links - Scrypto Design Patterns – Official Docs (https://docs.radixdlt.com/docs/reusable-blueprints-pattern) - Blueprints and Components – Official Docs (https://docs.radixdlt.com/docs/blueprints-and-components) - Blueprint Catalog: Build DeFi dApps Faster – Radix Blog (https://www.radixdlt.com/blog/build-defi-dapps-faster-on-radix) - Reusable Blueprints Pattern – Official Docs (https://docs.radixdlt.com/docs/reusable-blueprints-pattern) ## Hookah URL: https://radix.wiki/developers/tools/hookah Updated: 2026-09-03 Summary: Hookah is an open-source Radix event-monitoring and webhook-delivery platform by Alex Stelea (xStelea), a prolific author of Radix developer tooling.… Type Event Monitoring / Webhook Platform Network Radix Mainnet and Stokenet (/contents/tech/releases/stokenet) Service Live — hookah.ing (https://hookah.ing) , dashboard at app.hookah.ing (https://app.hookah.ing) (checked 9 August 2026) Auth Radix ROLA (/developers/frontend/03-rola-authentication) — a wallet persona (/contents/tech/core-protocols/personas) is the account SDK hookah-sdk (https://www.npmjs.com/package/hookah-sdk) 1.0.0 (npm) Language TypeScript (pnpm + Turborepo monorepo) Repository MIT, published 5 July 2026 as an open-source snapshot Overview Hookah (https://github.com/xstelea/hookah) is an open-source Radix (/contents/tech/core-protocols/radix-engine) event-monitoring and webhook-delivery platform by Alex Stelea (https://github.com/xstelea) (xStelea), a prolific author of Radix developer tooling. Developers authenticate with Radix ROLA (/developers/frontend/03-rola-authentication) , register on-ledger event triggers, and receive real-time webhook deliveries when matching events appear in the Radix transaction stream. The stated problem it removes is the one every dApp hits at the same moment: reacting to an on-chain event otherwise means running dedicated nodes or polling a rate-limited API (https://hookah.ing/docs) , writing stream-processing and filter logic, and building retrying webhook delivery — infrastructure that has nothing to do with the dApp. The MIT-licensed repository and the hosted service are both active. hookah.ing (https://hookah.ing) served its site, documentation and a live mainnet event stream on 9 August 2026, and the dashboard at app.hookah.ing (https://app.hookah.ing) answered with the ROLA sign-in challenge — the two are separate deployments behind the same domain. It also has a named production consumer, which is rarer for a one-author tool than a working demo is. Notix (/ecosystem/notix) , a real-time Radix notification service, credits "Webhook services provided by Hookah" (https://notix.live) in its footer and links the dashboard at app.hookah.ing (https://app.hookah.ing) (read 15 August 2026). The pairing is the architecture working as designed: a Radix account's state is something you have to pull from the Gateway (/contents/tech/core-protocols/radix-gateway-api) , Hookah converts matching on-ledger events into an outbound POST, and Notix turns that POST into the notification a user actually receives — three layers, none of which has to run a node. Architecture Hookah is a TypeScript monorepo (Turborepo + pnpm) with several components (/contents/tech/core-concepts/components) : a Streamer worker that follows Radix transactions and dispatches matching webhook deliveries; a Dashboard (Next.js) serving the web app, authentication, and tRPC/JSON-RPC endpoints; a Docusaurus documentation site; and a webhook test-server helper. It builds on the Radix Gateway API (/contents/tech/core-protocols/radix-gateway-api) and the radix-web3.js (/developers/tools/radix-web3-js) library, with PostgreSQL, Redis, and Drizzle ORM for storage. The split between the two processes is where the reliability story sits. The dashboard owns writes and migrations; the streamer reads transaction pages from the Gateway, transforms the events, loads candidate triggers from a Redis registry, executes the matching webhooks, writes execution logs, and — per the repository's own description — advances the stream checkpoint only after processing succeeds. A crash mid-page therefore re-reads that page rather than skipping it, which trades a possible duplicate delivery for not silently losing an event. Application logic under packages/api is written with Effect (https://effect.website/) , the same design choice the author made across radix-web3.js (/developers/tools/radix-web3-js) . Triggers and the Webhook Payload A webhook in Hookah is a destination — a URL, an optional name, and an optional header key/value pair used to authenticate the call at the receiving end. Triggers hang off it. Each trigger names an emitter address and an event name, and the event name must match what the component actually emits, character for character; the published troubleshooting guide (https://hookah.ing/docs/troubleshooting) lists a mismatched event name and an inactive watcher as the two usual reasons a webhook stays silent. When a trigger matches, the endpoint receives a POST whose body carries the transaction and the decoded events together: { eventWatcherId: string; transactionId: string; events: { data: ProgrammaticScryptoSborValue; emitter: { globalEmitter: string; methodEmitter: string; outerEmitter: string; }; eventName: string; }[]; } The three-part emitter is the detail worth reading twice, because it is what makes a deposit alert workable. For a DepositEvent, globalEmitter is the account, methodEmitter is the internal vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) the deposit landed in, and outerEmitter is the resource address (/developers/scrypto/02-resources-and-nfts) — so the payload answers who, where and which token without a follow-up Gateway call. data arrives as programmatic SBOR, the same shape the Gateway (/contents/tech/core-protocols/radix-gateway-api) returns, so an existing decoder works unchanged. Deliveries are recorded with response codes, error messages, retry attempts and timestamps, and the dashboard can fire a test POST before a real event ever matches. The SDK Everything the dashboard does is reachable programmatically through hookah-sdk (https://www.npmjs.com/package/hookah-sdk) , published to npm at 1.0.0. Its authentication path is the interesting part: rather than driving a wallet, the SDK takes an Ed25519 keypair and a signer callback, builds a persona (/contents/tech/core-protocols/personas) proof, and completes the same ROLA challenge the browser flow uses — createEd25519KeyPair and createHookahSdk, then await sdk.auth(). What comes back from getTrpcClient() is a typed tRPC (https://trpc.io/) client over the same API surface, so client.webhook.create.mutate({ url }) registers a webhook from a script or a CI job. A JSON-RPC API (https://hookah.ing/docs/json-rpc-api) covers callers that are not TypeScript. One constraint follows from the design and catches people locally: the API rejects localhost webhook URLs, so testing delivery end to end needs a public HTTPS receiver — the repository's own end-to-end suite reaches for ngrok, and skips those tests when no tunnel is configured. The Public Repository Is a Snapshot What is on GitHub is not a running mirror of the service, and the distinction matters before cloning. Every commit on main dates from 5 July 2026 — six of them, all by the author, the first titled "chore: initial open source snapshot" (https://github.com/xstelea/hookah/commits/main) . The repository has been public since March 2025 but carries that single day of history. The deployment has since moved past it. The site the snapshot builds is titled HOOKAH :: MONITOR_THE_RADIX_NETWORK; the page hookah.ing actually serves is titled "Webhooks for the Radix ledger", and it advertises capabilities the published documentation does not describe — field-level conditions on event contents, and a trigger that messages a Telegram chat instead of calling an endpoint. In the snapshot's own docs, conditional filtering is still listed as a V1 roadmap item (https://hookah.ing/docs/roadmap) and Telegram appears only as the support chat. A clone therefore builds the July state, not what the hosted service runs today. The usual caveats for a one-author tool apply: six commits, one contributor, one star, and no public issue tracker activity. The licence, at least, is unambiguous — an MIT LICENSE file sits in the repository root, which is more than can be said for some of the same author's other work (see radix-web3.js (/developers/tools/radix-web3-js) , where npm and the repository disagree). External Links - Hookah – hookah.ing (https://hookah.ing) - Documentation (https://hookah.ing/docs) - Dashboard – app.hookah.ing (https://app.hookah.ing) - Hookah – GitHub (https://github.com/xstelea/hookah) - hookah-sdk on npm (https://www.npmjs.com/package/hookah-sdk) - Alex Stelea (xStelea) – GitHub (https://github.com/xstelea) - Wiki: radix-web3.js (/developers/tools/radix-web3-js) – the same author's package suite, which Hookah builds on - Wiki: ROLA Authentication (/developers/frontend/03-rola-authentication) ## 4. Radix Engine Toolkit URL: https://radix.wiki/developers/transactions/04-radix-engine-toolkit Updated: 2026-09-03 Summary: The Radix Engine Toolkit (RET) is the library that lets a program outside the network build, sign, and inspect Radix transactions. It is written in Ru… Core library Rust, compiled to WASM and native targets Wrappers TypeScript, Python, Swift, C#, Kotlin npm package @radixdlt/radix-engine-toolkit (https://www.npmjs.com/package/@radixdlt/radix-engine-toolkit) Scope Off-ledger only – no ledger state TypeScript wrapper 1.0.6, published 3 December 2025 Licence Apache-2.0 Introduction The Radix Engine Toolkit (https://docs.radixdlt.com/docs/radix-engine-toolkit) (RET) is the library that lets a program outside the network build, sign, and inspect Radix transactions. It is written in Rust and compiled to WebAssembly and native targets, with wrappers published for TypeScript, Python, Swift, C#, and Kotlin. Rust itself needs no wrapper – it uses the scrypto and radix-engine crates directly. The boundary that matters is that RET is strictly off-ledger. It has no knowledge of ledger state, so it cannot tell you an account balance or whether a transaction committed. Those are Gateway API (/developers/infrastructure/02-radix-apis) questions. What RET can do is everything that is pure computation: construct a manifest (/contents/tech/core-protocols/transaction-manifests) , compile and hash a transaction, derive an address from a public key, and decode SBOR (/developers/scrypto/04-events-metadata-royalties) payloads. Nearly every wallet, exchange integration, and backend signer on Radix is built on it. What It Does - Transactions – manifest building, transaction construction, compilation and decompilation, intent hashing, static validation, address extraction, and execution analysis (working out what a manifest will actually move). - Derivation – virtual account and identity addresses from public keys, virtual signature non-fungible global IDs, and the Olympia (/contents/tech/releases/radix-mainnet-olympia) -to- Babylon (/contents/tech/releases/radix-mainnet-babylon) address mapping that migration tooling needs. - SBOR – decoding Scrypto (/contents/tech/core-protocols/scrypto-programming-language) and Manifest SBOR payloads into readable form, and limited encoding back. - Events – decoding events emitted by native components (/contents/tech/core-concepts/components) into typed models. Static validation is the part most integrations under-use. It checks a transaction is well-formed – header bounds, signature counts, manifest structure – without a network round trip, which turns a class of submission failures into a local error. Choosing an Entry Point The TypeScript wrapper exposes three classes, and picking the wrong one is the usual first mistake: - RadixEngineToolkit – the developer-facing class. Full functionality, idiomatic TypeScript, no backward-compatibility guarantee. Use this unless you have a reason not to. - LTSRadixEngineToolkit – a deliberately small surface with strong compatibility guarantees, aimed at exchange and custody integrations doing simple fungible transfers. Less capable by design; clients often outgrow it. - RawRadixEngineToolkit – the internal WASM invocation layer. No compatibility guarantees at all. You should not need it. Note also that the TypeScript wrapper is hand-written while the others are generated with UniFFI, and it is scoped to transaction construction, signing, and derivations. For anything beyond that, reach for one of the other wrappers or the Rust library. Building a Manifest in TypeScript npm install @radixdlt/radix-engine-toolkit The ManifestBuilder mirrors the Rust builder used throughout the Scrypto test suite, and allocates bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) and proof ids for you: import { ManifestBuilder, RadixEngineToolkit, NetworkId, address, bucket, decimal, } from "@radixdlt/radix-engine-toolkit"; const manifest = new ManifestBuilder() .callMethod(senderAccount, "lock_fee", [decimal(5)]) .callMethod(senderAccount, "withdraw", [address(xrd), decimal(10)]) .takeAllFromWorktop(xrd, (builder, bucketId) => builder.callMethod(recipientAccount, "try_deposit_or_abort", [bucket(bucketId)]) ) .build(); // build() returns { instructions: { kind: "Parsed", value: [...] }, blobs: [] }. // Manifest text is a separate, asynchronous conversion: const text = await RadixEngineToolkit.Instructions.convert( manifest.instructions, NetworkId.Mainnet, "String" ); console.log(text.value); What build() returns is not manifest text. It is a TransactionManifest, declared as { instructions: Instructions; blobs: Uint8Array[] }, and Instructions is a two-variant union: { kind: "Parsed", value: Instruction[] } or { kind: "String", value: string }. The builder always emits the Parsed variant, and the interface carries no toString() – calling one gets the default [object Object]. Going from the parsed tree to the text described in Transaction Manifest Language (/developers/transactions/01-manifest-language) is a round trip through the WASM core via RadixEngineToolkit.Instructions.convert(), which returns a Promise and takes a network id, because manifest text carries Bech32m addresses (/developers/transactions/05-addresses-and-entity-types) whose human-readable part is network-specific. The same module converts the other way, and also exposes compile(), decompile(), extractAddresses() and staticallyValidate() over the same instructions. The Parsed form is the one to keep hold of: TransactionBuilder takes the TransactionManifest itself, not text. TransactionBuilder.new() is asynchronous – it has to instantiate the WASM host first – and returns a builder whose steps are separate types, so the order is enforced by the compiler: header() yields the manifest step, manifest() the signature step, and sign()/signAsync() accumulate before notarize() resolves to a NotarizedTransaction ready for the Gateway. That is the flow described in Transaction Lifecycle (/developers/transactions/02-transaction-lifecycle) . When You Need It Front-end dApps usually do not call RET directly – the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) builds manifests and hands them to the wallet for signing, which is the right pattern when a human approves each transaction. Reach for RET when there is no wallet in the loop: - Backend signing – a service that holds keys and submits transactions itself, such as an exchange withdrawal pipeline. - Programmatic wallets – the official iOS and Android wallets are built on the Swift and Kotlin wrappers. - Analysis tooling – decompiling a transaction or decoding SBOR to explain what it did, without running a node. - Autonomous agents – see AI Agents & x402 Payments (/developers/ai-agents/ai-agents-and-x402) , where the agent constructs a transaction that a policy component or wallet then authorises. Next Steps - Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) – the other direction – let the user's wallet do the signing - Addresses and Entity Types (/developers/transactions/05-addresses-and-entity-types) – the format RET encodes, decodes, and derives External Links - Radix Engine Toolkit – Radix Documentation (https://docs.radixdlt.com/docs/radix-engine-toolkit) - radix-engine-toolkit – core Rust library on GitHub (https://github.com/radixdlt/radix-engine-toolkit) - typescript-radix-engine-toolkit – TypeScript wrapper and usage guide (https://github.com/radixdlt/typescript-radix-engine-toolkit) - @radixdlt/radix-engine-toolkit on npm (https://www.npmjs.com/package/@radixdlt/radix-engine-toolkit) ## 3. ROLA Authentication URL: https://radix.wiki/developers/frontend/03-rola-authentication Updated: 2026-09-03 Summary: ROLA (Radix Off-Ledger Authentication) is a challenge-response protocol that lets your backend verify a user owns a Radix account or persona – without… NPM @radixdlt/rola (https://www.npmjs.com/package/@radixdlt/rola) What is ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) ? ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) (Radix Off-Ledger Authentication) is a challenge-response protocol that lets your backend verify a user owns a Radix account or persona (/contents/tech/core-protocols/personas) – without submitting any on-ledger transaction. It's the Radix equivalent of "Sign-In with Ethereum (https://ethereum.org) " but uses the native Radix Wallet (/contents/tech/core-protocols/radix-wallet) . How It Works - Backend generates a challenge – a random 32-byte hex string stored with a 5-minute expiry - Frontend requests proof – asks the Radix Wallet (/contents/tech/core-protocols/radix-wallet) for account data with proof, and the toolkit attaches the challenge it gets from the generator you registered - User approves in wallet – wallet signs the challenge with the account's private key ( Ed25519 (https://en.wikipedia.org/wiki/EdDSA#Ed25519) or secp256k1 (https://en.bitcoin.it/wiki/Secp256k1) ) - Frontend sends proof to backend – contains public key, signature, and curve type - Backend verifies – checks the signature, confirms the public key matches the account's owner_keys metadata on ledger, and deletes the challenge Implementation 1. Generate Challenges (Backend) import crypto from 'crypto' // Store challenges with expiry (use Redis, DB, or in-memory Map) const challenges = new Map() function createChallenge(): string { const challenge = crypto.randomBytes(32).toString('hex') challenges.set(challenge, { expires: Date.now() + 5 * 60 * 1000 // 5 minutes }) return challenge } 2. Request Proof (Frontend) The challenge is never passed to the request builder. You give the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) a generator function, and the toolkit calls that function itself each time it sends a request. withProof() is a flag on the builder, not a place to put the challenge. import { DataRequestBuilder } from '@radixdlt/radix-dapp-toolkit' // RDT calls this once per request and attaches the result to it rdt.walletApi.provideChallengeGenerator(async () => { const res = await fetch('/api/auth/challenge') return (await res.json()).challenge }) // withProof() takes an optional boolean, never the challenge string rdt.walletApi.setRequestData( DataRequestBuilder.accounts().atLeast(1).withProof(), ) const result = await rdt.walletApi.sendRequest() // takes no arguments if (result.isOk()) { const { proofs } = result.value // one signed challenge per shared account }Two things here are easy to get wrong. walletApi.sendRequest() accepts no arguments: the builders go to setRequestData() first, or to sendOneTimeRequest(...) if you do not want the request stored for later connections. And every entry in result.value.proofs already has the shape { address, type, challenge, proof }, which is exactly the argument verifySignedChallenge expects in the next step, so you can pass one straight through without rebuilding it. The curve field is the string 'curve25519' or 'secp256k1', so do not test it against 'ed25519' even though Ed25519 is the signature scheme. 3. Verify Proof (Backend) import { Rola (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) } from '@radixdlt/rola' import { RadixNetwork } from '@radixdlt/babylon-gateway-api-sdk' const rola = Rola({ networkId: RadixNetwork.Mainnet, applicationName: 'My dApp', dAppDefinitionAddress: 'account_rdx...', expectedOrigin: 'https://my-dapp.com' }) // Verify the signed challenge const result = await rola.verifySignedChallenge({ challenge: challengeHex, proof: { publicKey, signature, curve }, address: accountAddress, type: 'account' }) if (result.isOk()) { // Create session (JWT, cookie, etc.) }Delete used challenges Always delete a challenge after verification – successful or not. This prevents replay attacks where a captured proof is resubmitted. When to Use ROLA (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) Use Case Auth Method User login / session creation ROLA Prove account ownership to backend ROLA Transfer assets or call components (/contents/tech/core-concepts/components) On-ledger transaction Gate content by badge (/contents/tech/core-concepts/badges) ownership ROLA + Gateway query ROLA proves identity. On-ledger transactions perform actions. For token-gated access, verify ownership via ROLA then query the account's resources (/contents/tech/core-concepts/resources) via the Gateway SDK (/developers/frontend/02-gateway-sdk) . Reference Implementation and Maintenance Status (checked August 2026) ROLA works, and it is still the right way to log a user in. But every official piece around it has stopped receiving updates, and one of them is archived, so check the source before you copy code out of a Radix repository. - The examples repository is archived. radixdlt/rola-examples (https://github.com/radixdlt/rola-examples) is marked archived on GitHub and its most recent commit is dated 8 September 2023. It pins @radixdlt/radix-dapp-toolkit at 0.5.1 and sets networkId: 13, an id the Gateway SDK (https://www.npmjs.com/package/@radixdlt/babylon-gateway-api-sdk) 's own RadixNetwork map does not contain at all, since it goes from 12 straight to 14. The example also predates the @radixdlt/rola package: its server verifies proofs with a hand-written implementation under apps/server/src/rola/ rather than the package this page recommends. - The package is frozen, and widely installed anyway. @radixdlt/rola (https://www.npmjs.com/package/@radixdlt/rola) is at version 2.1.0, published on 20 November 2024, and npm latest has not moved since. It was still downloaded 3,564 times in the month to 24 August 2026. - The toolkit is in the same position. The dated version of that story is on Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) : bug fixes only, on a volunteer basis, pending a community decision on who takes the libraries on. The practical rule for all three: read the archived example to see how the parts connect, then check every method name against the type definitions inside the version you actually installed, because the two do not agree. Next Steps - dApp Definition and Wallet Verification (/developers/frontend/04-dapp-definition-and-verification) – required before the Radix Wallet will accept your requests on Mainnet External Links - ROLA documentation (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) - @radixdlt/rola on npm (https://www.npmjs.com/package/@radixdlt/rola) - ROLA examples repository (https://github.com/radixdlt/rola-examples) – archived September 2023, pinned to RDT 0.5.1; read it for the shape, not for the API ## 3. Transaction Fees URL: https://radix.wiki/developers/transactions/03-transaction-fees Updated: 2026-09-03 Summary: Every transaction on Radix pays a fee in XRD , and every manifest you write has to say where that XRD comes from. That is what the lock_fee call at th… Fee token XRD (/contents/tech/core-protocols/xrd-token) only Fee components (/contents/tech/core-concepts/components) Execution + finalization + storage, plus optional tip and royalties Paid from Any XRD vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) , via lock_fee Cost unit price 0.00000005 XRD per execution and per finalization cost unit Storage price 0.00009536743 XRD per byte Network fee split 50% burnt, 25% to the round proposer, 25% to the validator set Introduction Every transaction on Radix pays a fee in XRD (/contents/tech/core-protocols/xrd-token) , and every manifest (/developers/transactions/01-manifest-language) you write has to say where that XRD comes from. That is what the lock_fee call at the top of most manifests (/contents/tech/core-protocols/transaction-manifests) is doing. Two things about the Radix model differ from what you may expect coming from an EVM chain, and both change how you design a dApp. First, the fee is not attached to the signer. XRD is held in vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) owned by components (/contents/tech/core-concepts/components) , so a fee is paid by whichever component locks it – which may be the user's Smart Account (/contents/tech/core-protocols/smart-accounts) , your dApp's component, or both. Second, the total fee is not a single gas number: it is a network cost, an optional user tip, and any royalties (/contents/tech/core-concepts/component-royalties) the code you called charges, each with different destinations. What Makes Up a Fee The fee model (https://www.radixdlt.com/articles-learn/how-do-transaction-fees-work-on-radix) prices each transaction in three parts, and the first of those is itself three separately-metered quantities: - Network fee – the cost of running the transaction and of the state it leaves behind. It is the sum of an execution cost, a finalization cost and a storage cost. The first two are metered in cost units against a fee table; the third is charged per byte written to state and to archive. - Tip – an optional percentage the submitter adds when demand exceeds capacity. It amplifies only the network portion, never royalties, and goes straight to the validator proposing the round. - Royalties – amounts set by a package publisher or component instantiator, charged whenever a transaction calls that code. Royalties are part of the fee the user pays, but they are not burnt or shared with validators; see Events, Metadata, and Royalties (/developers/scrypto/04-events-metadata-royalties) for how to configure them. Because royalties are counted inside the fee, a transaction that touches an expensive component costs more than an identical transaction that does not – and the user sees the total before signing, in the wallet's transaction summary. The Prices, and the Fiat Peg Behind Them The prices are protocol constants, declared in radix-common/src/constants/transaction_execution.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/transaction_execution.rs) and assembled into a CostingParameters struct by the engine. Every figure below is checkable against any committed transaction's receipt.fee_summary through the Gateway API (/developers/infrastructure/02-radix-apis) . Parameter Value What it controls EXECUTION_COST_UNIT_PRICE_IN_XRD 0.00000005 XRD Price of one execution cost unit FINALIZATION_COST_UNIT_PRICE_IN_XRD 0.00000005 XRD Price of one finalization cost unit STATE_STORAGE_PRICE_IN_XRD 0.00009536743 XRD Price of one byte of state storage ARCHIVE_STORAGE_PRICE_IN_XRD 0.00009536743 XRD Price of one byte of archive storage (payload, events, logs) EXECUTION_COST_UNIT_LIMIT 100,000,000 Ceiling on execution cost units in one transaction FINALIZATION_COST_UNIT_LIMIT 50,000,000 Ceiling on finalization cost units in one transaction EXECUTION_COST_UNIT_LOAN 4,000,000 Cost units advanced before the first lock_fee USD_PRICE_IN_XRD 16.666… XRD The fiat multiplier — the rate at which USD-denominated royalties convert to XRD Working the mainnet transaction above back through them: 7,286,902 execution cost units at 0.00000005 XRD is 0.3643451 XRD, 820,152 finalization cost units is 0.0410076 XRD, and 0.09574889972 XRD of storage is exactly 1,004 bytes at 0.00009536743 XRD each. The three constants are not documentation — they are what the ledger charged. The last row is the one worth reading twice. USD_PRICE_IN_XRD is the "fiat value multiplier": it fixes what the protocol believes a dollar is worth in XRD, and at 16.666… it values 1 XRD at $0.06. That figure is not read from an oracle and does not track the market — it is a compiled-in constant, and CostingParameters::latest() in transaction_executor.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/transaction/transaction_executor.rs) still returns babylon_genesis(), so no protocol update since Babylon (/contents/tech/releases/radix-mainnet-babylon) has moved it. XRD traded at about $0.00093 on 23 August 2026, roughly sixty-four times below the rate the fee model assumes. For a developer that cuts two ways. Transaction costs are set in XRD and are therefore stable in XRD and cheap in fiat — the half-XRD transaction above cost about $0.0005. But anything the protocol prices in dollars is converted at $0.06 per XRD, so a royalty declared in USD, and the 166.666… XRD per-function royalty ceiling nominally described as $10, are worth far less than their labels suggest at today's price. Preview credit is generous for the same reason: PREVIEW_CREDIT_IN_XRD advances 1,000,000 XRD, commented in the source as $60,000. Locking a Fee A transaction pays from a fee reserve, which is established by calling lock_fee on a component that owns an XRD vault. In practice this is the first instruction in most manifests: CALL_METHOD Address("account_rdx...") "lock_fee" Decimal("5") ; The amount is a ceiling, not a charge. Whatever the transaction does not spend is returned to the vault it was locked from. Locking too little is the failure mode to guard against: if the reserve runs dry mid-execution the transaction fails, and the fees already consumed are not refunded. Multiple Payers More than one vault can lock a fee in the same transaction, and later locks are used preferentially. That is what makes fee sponsorship straightforward on Radix: a dApp component can lock part or all of the fee so the user does not need XRD to interact with it, and a profit-taking application can chip in a share of each trade. Nothing about this requires a meta-transaction relayer – it is a normal manifest instruction. The Bootstrap Loan The instructions that run before the first lock_fee still cost something. The network covers them with a small automatic loan of cost units, which must be repaid the moment the reserve is established. A transaction that burns through the loan without locking enough is rejected outright and leaves no ledger record. One that repays the loan and then fails is committed as failed: the state changes roll back, but the fees spent up to the failure are kept. Where Fees Go Spent fees are split by type, and the shares are protocol constants rather than a validator setting: - Network fee – 25% goes to the validator that proposed the round and 25% to the validator set, shared at the end of the epoch (/contents/tech/core-concepts/validator-nodes) in the same shape as network emissions (/contents/tech/core-concepts/network-emissions) . The remaining 50% is burnt. The two shares are NETWORK_FEES_PROPOSER_SHARE_PERCENTAGE and NETWORK_FEES_VALIDATOR_SET_SHARE_PERCENTAGE in transaction_execution.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/transaction_execution.rs) , both set to 25, and the burn is whatever is left after them: to_burn_amount() (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/costing/fee_summary.rs) subtracts both shares from the total rather than computing a share of its own. - Tips – paid immediately and entirely to the round proposer. The corresponding constants are TIPS_PROPOSER_SHARE_PERCENTAGE = 100 and TIPS_VALIDATOR_SET_SHARE_PERCENTAGE = 0, so a tip is never burnt and never shared. - Royalties – deposited into a system-generated vault owned by the component (or, for package royalties, by the package). The instantiator or deployer claims them with a badge (/contents/tech/core-concepts/badges) the system creates automatically at instantiation or deployment. A single function's royalty is capped at MAX_PER_FUNCTION_ROYALTY_IN_XRD, 166.666… XRD. A live example. The Gateway (/developers/infrastructure/02-radix-apis) returns this breakdown for any committed transaction under receipt.fee_destination; for mainnet transaction txid_rdx15gl7urc8kn36mjeq0hwru4mhn9t6uknkh7c7vsnw7tkh6t85zh9q6t3jzn at state version 553,951,096 (23 August 2026), against network fees of 0.50110159972 XRD: Destination XRD Share Burnt 0.25055079986 50% Round proposer 0.12527539993 25% Validator set (epoch pool) 0.12527539993 25% The burn is why fee revenue is deflationary for XRD supply, and the epoch pool is why validator income tracks participation rather than luck of the round. Practical Guidance - Lock generously. The unspent portion comes back, so a reserve that is too high costs nothing and a reserve that is too low burns fees for a failed transaction. - Estimate before you submit. Preview the transaction through the Gateway API (/developers/infrastructure/02-radix-apis) to get a fee estimate rather than guessing, especially for manifests whose cost varies with input size. - Sponsor deliberately. If your component locks the fee, anyone who can call it can spend your XRD – gate the sponsoring method with a badge (/developers/scrypto/03-authorization-and-badges) or a business rule, not just goodwill. - Price royalties as user cost. A royalty is invisible in your own testing but appears in every user's fee summary. Next Steps - Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) – build and sign transactions from your own code, with no wallet in the loop External Links - How do Transaction Fees Work on Radix? – Radix Knowledge Base (https://learn.radixdlt.com/article/how-do-transaction-fees-work-on-radix) - Using Royalties – Radix Documentation (https://docs.radixdlt.com/docs/using-royalties) - Transactions – Radix Documentation (https://docs.radixdlt.com/docs/concepts-transactions) - transaction_execution.rs – the costing constants in radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-common/src/constants/transaction_execution.rs) - fee_summary.rs – how a spent fee is split between proposer, validator set and burn (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-engine/src/system/system_modules/costing/fee_summary.rs) ## 4. Events, Metadata, and Royalties URL: https://radix.wiki/developers/scrypto/04-events-metadata-royalties Updated: 2026-09-03 Summary: Components can emit events during transaction execution. Events are encoded in SBOR and stored in the transaction receipt – useful for indexing, analy… Events Components (/contents/tech/core-concepts/components) can emit events (https://docs.radixdlt.com/docs/scrypto-events/) during transaction execution. Events are encoded in SBOR (https://docs.radixdlt.com/docs/sbor) and stored in the transaction receipt – useful for indexing, analytics, and off-chain reactions. #[derive(ScryptoSbor, ScryptoEvent)] pub struct SwapEvent { pub input_amount: Decimal, pub output_amount: Decimal, pub pool_address: ComponentAddress, } // Inside a method: Runtime::emit_event(SwapEvent { input_amount: dec!("100"), output_amount: dec!("95.5"), pool_address: self_address, });Events appear in Gateway API (/developers/infrastructure/02-radix-apis) responses and can be decoded using the Radix Engine Toolkit (/contents/tech/core-protocols/transaction-manifests) or the radix-event-stream library for real-time indexing. Entity Metadata Metadata (/contents/tech/core-concepts/metadata-module) is a key-value store available on all entities – resources (/contents/tech/core-concepts/resources) , components, packages, and accounts. The Radix Wallet (/contents/tech/core-protocols/radix-wallet) and other clients use standardized keys (/contents/tech/core-concepts/metadata-module) to display assets consistently. Setting Metadata at Creation ResourceBuilder (https://docs.radixdlt.com/docs/resources) ::new_fungible(OwnerRole::None) .metadata(metadata!( init { "name" => "My Token", locked; // Cannot be changed "symbol" => "MYT", locked; "description" => "A token", updatable; // Can be updated "icon_url" => Url::of("https://example.com/icon.png"), locked; } )) .mint_initial_supply(1000);Standard Metadata Keys Key Used By Purpose name Wallet, Dashboard Human-readable name symbol Wallet Short ticker (e.g., XRD (/contents/tech/core-protocols/xrd-token) ) description Dashboard Brief description icon_url Wallet Token icon image info_url Dashboard Project website Keys are strings (max 100 chars). You can add custom keys beyond the standard set – clients will display them as-is. Royalties Radix has a built-in royalty system (/contents/tech/core-concepts/component-royalties) that lets developers earn XRD whenever their blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) or components are used. Royalties are collected automatically as part of transaction fees – users see the total cost upfront. Package Royalties Set royalties on specific functions or methods when publishing a package: #[blueprint] #[types(/* ... */)] mod my_dex { enable_package_royalties! { instantiate => Free; swap => Xrd(1.into()); // 1 XRD per swap call } // ... }Component Royalties Component instantiators can also set per-method royalties at instantiation time. The total royalty for a transaction is the sum of all package and component royalties for every method called. Pricing strategy You can specify royalties as a fixed XRD amount or an approximate USD equivalent. Use USD-equivalent pricing for stable fee expectations regardless of XRD price fluctuations. Next Steps - Testing Scrypto Blueprints (/developers/scrypto/05-testing-scrypto) – move from poking at resim by hand to tests that run in CI External Links - Events documentation (https://docs.radixdlt.com/docs/scrypto-events/) - Metadata documentation (https://docs.radixdlt.com/docs/metadata) - Metadata Standards (/contents/tech/core-concepts/metadata-module) - Royalties documentation (/contents/tech/core-concepts/component-royalties) ## 2. Your First Blueprint URL: https://radix.wiki/developers/getting-started/02-first-blueprint Updated: 2026-09-03 Summary: In this tutorial you'll build a Gumball Machine – a simple component that sells gumball tokens for XRD . Along the way you'll learn the core Scrypto c… Overview In this tutorial you'll build a Gumball Machine – a simple component (/contents/tech/core-concepts/components) that sells gumball tokens for XRD (/contents/tech/core-protocols/xrd-token) . Along the way you'll learn the core Scrypto (/developers/scrypto/01-fundamentals) concepts: blueprints, components, resources, and vaults (/developers/scrypto/01-fundamentals) . Create a Package A package is the deployment unit in Scrypto (/developers/scrypto/01-fundamentals) – it contains one or more blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) . scrypto (/developers/scrypto/01-fundamentals) new-package gumball_machine cd gumball_machineThis creates: gumball_machine/ ├── Cargo.toml # Dependencies ├── Cargo.lock # Pinned dependency versions ├── rust-toolchain.toml # Rust channel and components for this package ├── .gitignore ├── src/ │ └── lib.rs # Blueprint code └── tests/ └── lib.rs # TestsThe generated rust-toolchain.toml is worth opening first: it pins the Rust channel this package builds with, and which channel you get depends on the radix-clis version that generated it (/developers/getting-started/01-install-scrypto) . Write the Blueprint Replace src/lib.rs with the following. Each section is explained below. use scrypto::prelude::*; #[derive(ScryptoSbor)] pub struct Status { pub price: Decimal, pub amount: Decimal, } #[blueprint] mod gumball_machine { struct GumballMachine { gum_resource_manager: ResourceManager, gumballs: Vault, collected_xrd: Vault, price: Decimal, } impl GumballMachine { pub fn instantiate(price: Decimal) -> Global { let gumballs = ResourceBuilder::new_fungible(OwnerRole::None) .metadata(metadata!( init { "name" => "Gumball", locked; "symbol" => "GUM", locked; } )) .mint_initial_supply(100) .into(); Self { gum_resource_manager: gumballs.resource_manager(), gumballs: Vault::with_bucket(gumballs), collected_xrd: Vault::new(XRD), price, } .instantiate() .prepare_to_globalize(OwnerRole::None) .globalize() } pub fn buy_gumball(&mut self, mut payment: Bucket) -> (Bucket, Bucket) { let cost = self.price.clone(); let our_share = payment.take(cost); self.collected_xrd.put(our_share); (self.gumballs.take(1), payment) } pub fn get_status(&self) -> Status { Status { price: self.price.clone(), amount: self.gumballs.amount(), } } } } Key Concepts - Blueprint (/contents/tech/core-concepts/blueprints-and-packages) – a template (like a class). The #[blueprint] macro exposes it to the Radix Engine (/contents/tech/core-protocols/radix-engine) . - Component – a live instance of a blueprint, created by instantiate(). - Resource (/contents/tech/core-concepts/resources) – a first-class digital asset. ResourceBuilder (https://docs.radixdlt.com/docs/resources) creates a new fungible token ("Gumball"). - Vault (/contents/tech/core-concepts/buckets-proofs-and-vaults) – permanent on-ledger storage for resources. Components hold assets in vaults (https://docs.radixdlt.com/docs/buckets-and-vaults) . - Bucket – a transient container for moving resources between vaults during a transaction. Notice there is no balance tracking or transfer logic – the Radix Engine handles asset management natively (/developers/scrypto/01-fundamentals) . Build scrypto buildThis compiles to WebAssembly (https://webassembly.org) at target/wasm32-unknown-unknown/release/gumball_machine.wasm. On macOS this stops in blst without the two compiler variables from Installing Scrypto (/developers/getting-started/01-install-scrypto) . Test with resim resim is the Radix Engine Simulator (https://docs.radixdlt.com/docs/resim-radix-engine-simulator) – a local ledger you can use without connecting to any network. # Reset the simulator resim reset # Create a test account (saves address to $account) resim new-account # Publish the package resim publish . # Note the package address in the output # Instantiate a GumballMachine with price = 5 XRD resim call-function GumballMachine instantiate 5 # Note the component address in the output # Buy a gumball by sending 10 XRD resim call-method buy_gumball "10,resource_sim1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxakj8n3" # Check your account resim show You should see GUM tokens in your account and 5 XRD change returned. Handy resim commands resim show
– inspect any entity. resim new-token-fixed 1000 – create test tokens. resim reset – wipe and start fresh. Next Steps - Deploy to Stokenet (/developers/getting-started/03-deploying) – publish your package on the public testnet - Scrypto Fundamentals (/developers/scrypto/01-fundamentals) – deeper dive into the asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) model - Testing Scrypto Blueprints (/developers/scrypto/05-testing-scrypto) – write proper unit and integration tests External Links - Official Gumball Machine tutorial (https://docs.radixdlt.com/docs/learning-to-build-a-gumball-machine) - resim documentation (https://docs.radixdlt.com/docs/resim-radix-engine-simulator) - Official Scrypto examples (https://github.com/radixdlt/official-examples) ## 1. Scrypto Fundamentals URL: https://radix.wiki/developers/scrypto/01-fundamentals Updated: 2026-09-03 Summary: Scrypto is built on asset-oriented programming – a paradigm where digital assets are first-class primitives managed by the Radix Engine , not arbitrar… Asset-Oriented (/contents/tech/core-concepts/asset-oriented-programming) Programming Scrypto (/contents/tech/core-protocols/scrypto-programming-language) is built on asset-oriented programming (/contents/tech/core-concepts/asset-oriented-programming) – a paradigm where digital assets are first-class primitives managed by the Radix Engine (/contents/tech/core-protocols/radix-engine) , not arbitrary integers in a smart contract's storage. In Solidity (https://soliditylang.org) , a token is a mapping of addresses to balances inside a contract. Transferring tokens means calling a function that modifies that mapping. Bugs in this logic cause real losses – reentrancy, integer overflow, and unauthorized access. In Scrypto, tokens are resources (/contents/tech/core-concepts/resources) – objects with physical-like properties enforced by the engine. They cannot be duplicated, destroyed without authorization, or exist outside a container. The runtime guarantees that every resource is accounted for at the end of every transaction. Blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) , Components, and Packages Scrypto's object model has three levels: Concept Analogy Description Package Library / crate Deployment unit containing one or more blueprints (/contents/tech/core-concepts/blueprints-and-packages) . Deployed once, referenced by address. Blueprint Class / template Defines state shape and methods. Contains no state itself – it's a template. Component (/contents/tech/core-concepts/components) Instance / object A live instantiation of a blueprint. Holds state, owns resources in vaults (https://docs.radixdlt.com/docs/resources) . A single blueprint can be instantiated many times – each component is independent with its own state and resource holdings. Code Structure use scrypto::prelude::*; #[blueprint] mod my_blueprint { struct MyBlueprint { // State fields — persisted between transactions my_vault: Vault, count: u64, } impl MyBlueprint { // Functions: called on the blueprint (no &self) // Used for instantiation pub fn instantiate() -> Global { Self { /* ... */ } .instantiate() .prepare_to_globalize(OwnerRole::None) .globalize() } // Methods: called on a component (&self or &mut self) pub fn get_count(&self) -> u64 { self.count } pub fn increment(&mut self) { self.count += 1; } } }The #[blueprint] macro handles serialization, state management, and ABI generation. You write plain Rust structs and methods. How Radix Engine (/contents/tech/core-protocols/radix-engine) Differs from EVM Aspect EVM ( Solidity (https://soliditylang.org) ) Radix Engine (/contents/tech/core-protocols/radix-engine) (Scrypto) Assets Contract storage mappings First-class resources with engine-enforced rules Transfer Call a function that mutates state Move a bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) between vaults (https://docs.radixdlt.com/docs/resources) Authorization msg.sender checks Badge (/contents/tech/core-concepts/badges) -based access rules (/developers/scrypto/03-authorization-and-badges) Reentrancy Must be guarded manually Impossible – resources move, not references Composability External calls with ABI encoding Native cross-component calls via transaction manifests (/developers/transactions/01-manifest-language) Scaling Single global state Shard-aware via Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Key Takeaways - Resources are real – they behave like physical objects, not database entries - Blueprints (https://docs.radixdlt.com/docs/blueprints-and-components) are templates – they define behavior but hold no state - Components are instances – each with independent state and resource vaults (https://docs.radixdlt.com/docs/resources) - The engine enforces safety – reentrancy, double-spend, and overflow bugs are prevented at the runtime level Scrypto and the Xi'an Execution Layer Everything above describes the Radix Engine (/contents/tech/core-protocols/radix-engine) as it runs on Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet today, which is the environment to learn and deploy against. It is not the environment Radix's next release is expected to ship. Xi'an (/contents/tech/releases/radix-mainnet-xian) 's sharded execution layer, hyperscale-rs (/contents/tech/research/hyperscale-rs) , requires every transaction to declare which state it will touch before anything executes – that declaration is what fixes the participating shards and lets conflicts be analysed without running the transaction. On 1 August 2026 its lead developer confirmed that a purpose-built VM is “underway” (https://t.me/hyperscale_rs/10334) rather than a sharding (/contents/tech/core-concepts/sharding) retrofit of the Radix Engine, on the reasoning that “the sharding adjustments are so many that it'd require touching everything. at some point it becomes easier to start with intention than to retrofit” (https://t.me/hyperscale_rs/10336) . The repository does integrate the real Radix Engine today, but “it can only run a simple subset of transactions where the mapping from transaction -> substates can be determined purely from the manifest” (https://t.me/hyperscale_rs/10359) . What that costs existing dApps was given a range on 2 August: “best case scenario - contracts will just need a recompile. worst case scenario - there'll be some automatic transpiler devs can use to upgrade source code” (https://t.me/hyperscale_rs/10346) . Both ends of that range describe migrating source rather than rewriting it. Whether Scrypto survives under its own name has not been stated – the question was put to the channel (https://t.me/hyperscale_rs/10338) and drew no direct reply, and no mapping from today's blueprint model to the new VM has been published. The stated design goal, that a transaction's full set of touched substate keys be derivable statically from the manifest (/developers/transactions/01-manifest-language) , is a stricter form of the declared-intent model Scrypto already uses rather than a departure from it. The wiki tracks this on the hyperscale-rs (/contents/tech/research/hyperscale-rs) page as it develops. Next Steps - Resources, Vaults, and NFTs (/developers/scrypto/02-resources-and-nfts) – define fungible and non-fungible resources (https://docs.radixdlt.com/docs/resources) and manage them in vaults - Authorization and Badges (/developers/scrypto/03-authorization-and-badges) – badge-based access control, the Scrypto alternative to Solidity msg.sender checks External Links - Scrypto Overview (https://docs.radixdlt.com/docs/learning-to-explain-your-first-scrypto-project) - Asset-Oriented Programming (/contents/tech/core-concepts/asset-oriented-programming) - What is Radix Engine? (https://learn.radixdlt.com/article/what-is-radix-engine) - Components, Blueprints, and the Blueprint Catalog (https://learn.radixdlt.com/article/what-are-components-blueprints-and-the-blueprint-catalog) ## 2. Gateway SDK: Reading Ledger State URL: https://radix.wiki/developers/frontend/02-gateway-sdk Updated: 2026-09-03 Summary: The Gateway SDK is a TypeScript client for the Radix Gateway API . It lets you query account balances, read component state, look up transaction histo… NPM @radixdlt/babylon-gateway-api-sdk (https://www.npmjs.com/package/@radixdlt/babylon-gateway-api-sdk) Overview The Gateway SDK is a TypeScript client for the Radix Gateway API (/developers/infrastructure/02-radix-apis) . It lets you query account balances, read component (/contents/tech/core-concepts/components) state, look up transaction history, and submit transactions – all the read/write operations your dApp frontend needs. npm install @radixdlt/babylon-gateway-api-sdk Setup import { GatewayApiClient, RadixNetwork } from '@radixdlt/babylon-gateway-api-sdk' const gatewayApi = GatewayApiClient.initialize({ networkId: RadixNetwork.Mainnet, // or RadixNetwork.Stokenet applicationName: 'My dApp', applicationVersion: '1.0.0', applicationDappDefinitionAddress: 'account_rdx...' })The SDK connects to the Radix Foundation (/ecosystem/radix-foundation) 's public Gateway by default. For production dApps with high traffic, consider running your own Gateway node (/developers/infrastructure/02-radix-apis) or using a third-party provider. Common Queries Account Balances const details = await gatewayApi.state.getEntityDetailsVaultAggregated( 'account_rdx1c956...' // account address ) // details.fungible_resources — token balances // details.non_fungible_resources — NFT holdingsComponent State const component = await gatewayApi.state.getEntityDetailsVaultAggregated( 'component_rdx1cp...' // component address ) // Read state, vaults (https://docs.radixdlt.com/docs/resources) , metadataEntity Metadata const metadata = await gatewayApi.state.getAllEntityMetadata( 'resource_rdx1t...' // any entity address ) // Returns: name, symbol, description, icon_url, etc. Transaction Status const status = await gatewayApi.transaction.getStatus( 'txid_rdx1...' // intent hash from sendTransaction ) // status.intent_status: "CommittedSuccess" | "CommittedFailure" | "Pending" | ...Historical State Query state at a specific point in time by passing at_ledger_state: const historicalDetails = await gatewayApi.state.innerClient.stateEntityDetails({ stateEntityDetailsRequest: { addresses: ['account_rdx1...'] at_ledger_state: { state_version: 12345678 } } }) Maintenance Status (checked August 2026) The SDK and the service it talks to are on different clocks, and it is worth knowing which is which. The client library (https://www.npmjs.com/package/@radixdlt/babylon-gateway-api-sdk) has been at 1.10.1 since March 2025 — it is a generated client over a stable API, so age here mostly means the API has not changed underneath it. The Gateway service (https://github.com/radixdlt/babylon-gateway) is more recent but also slowing: release v1.10.6 on 7 April 2026, and a final documentation-only commit on 20 May 2026. As of 7 August 2026 the Gateway is maintained on a volunteer basis with bug fixes only (https://t.me/RadixDevelopers/65908) , alongside the dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) and the Radix Wallet (/contents/tech/core-protocols/radix-wallet) . The practical consequence is about hosting rather than code. The public Gateway this SDK defaults to is Foundation (/ecosystem/radix-foundation) -operated infrastructure now in maintenance mode, and it sits at the top of the Accountability Council (/ecosystem/radix-accountability-council) 's inventory of services a community DAO would need to take over. If your dApp cannot tolerate that dependency, run your own Gateway or use a third-party provider — see Radix APIs (/developers/infrastructure/02-radix-apis) . Next Steps - ROLA Authentication (/developers/frontend/03-rola-authentication) – prove server-side that a user really controls the account they claim External Links - @radixdlt/babylon-gateway-api-sdk on npm (https://www.npmjs.com/package/@radixdlt/babylon-gateway-api-sdk) - Gateway API reference (https://docs.radixdlt.com/api-reference/gateway-api-specs.html) - Mainnet Gateway Swagger UI (https://mainnet.radixdlt.com/swagger/) ## 2. Transaction Lifecycle URL: https://radix.wiki/developers/transactions/02-transaction-lifecycle Updated: 2026-09-03 Summary: A Radix transaction has three layers, each wrapping the previous: Layer Contains Purpose Intent Header + manifest Defines what to do and when Signed I… Transaction Structure A Radix transaction (https://docs.radixdlt.com/docs/transaction-structure) has three layers, each wrapping the previous: Layer Contains Purpose Intent Header + manifest Defines what to do and when Signed Intent Intent + signatures Authorizes the transaction Notarized Transaction Signed intent + notary signature Final submission-ready payload The header specifies the validity window (epoch range, ~5 min per epoch), the notary's public key, and a nonce. The manifest contains the instructions. Build → Sign → Submit 1. Build Construct the transaction intent with a manifest and header. The epoch window determines how long the transaction remains valid – typically the current epoch ± 2. 2. Sign One or more parties sign the intent hash with their private keys ( Ed25519 (https://en.wikipedia.org/wiki/EdDSA#Ed25519) or ECDSA secp256k1 (https://en.bitcoin.it/wiki/Secp256k1) ). For wallet-submitted transactions, the dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) handles this automatically. 3. Notarize The notary signs the signed intent hash. In most dApps, the wallet acts as both signer and notary. 4. Submit The compiled payload is sent to the network via the Gateway or Core API (/developers/infrastructure/02-radix-apis) . 5. Track Poll the transaction status using the intent hash. Outcomes: - Committed – accepted on ledger (success or application-level failure) - Permanently rejected – invalid structure or expired epoch - Temporarily rejected – may become valid later (e.g., pending dependency) Subintents and Pre-Authorization Subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) are independent mini-transactions that compose into a single atomic transaction. Each subintent has its own manifest, header, and signers. Why Subintents? - Delegated fee payment – a dApp pays fees on behalf of the user, solving the "double onboarding" problem (user needs XRD (/contents/tech/core-protocols/xrd-token) before they can do anything) - Peer-to-peer trading – buyer and seller each sign a subintent; a matchmaker combines them into an atomic swap - Flash loans (https://aave.com/docs/aave-v3/guides/flash-loans) – a lending subintent provides liquidity, the user's subintent uses it, and a payback subintent returns it – all atomically Key Instructions # Parent defines a child subintent DEFINE_CHILD SubintentHash("deadbeef..."); # Parent yields to child YIELD_TO_CHILD SubintentHash("deadbeef...") Expression("ENTIRE_WORKTOP"); # Child yields back to parent YIELD_TO_PARENT Expression("ENTIRE_WORKTOP"); Pre-Authorization Flow Pre-authorization (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) lets users sign subintents in advance. The dApp can later combine them with its own subintents and submit whenever ready. - dApp sends a pre-auth request to the wallet with a subintent manifest - User reviews and signs in the wallet - Wallet returns the signed subintent to the dApp - dApp combines it with other subintents and submits as a complete transaction Practical example A user pre-authorizes "swap 100 USDC for GBP" via a subintent. The dApp adds a fee-payment subintent and submits the combined transaction – the user never needs to hold XRD for fees. Next Steps - Transaction Fees (/developers/transactions/03-transaction-fees) – who pays, how much, and how to sponsor fees for your users External Links - Transactions overview (https://docs.radixdlt.com/docs/learning-to-create-and-use-transaction-manifests) - Transaction structure (/contents/tech/core-protocols/transaction-manifests) - Subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) - Pre-authorization flow (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) ## Radix Desktop Tool URL: https://radix.wiki/developers/tools/radix-desktop-tool Updated: 2026-09-03 Summary: The Radix Desktop Tool is an open-source desktop utility for Radix built by community member HODL6666. It bundles the operations that the Radix Wallet… Type Desktop utility (batch transfers, manifests (/contents/tech/core-protocols/transaction-manifests) , deployment) Platform Desktop app (not a web app, by design) Networks Mainnet and Stokenet (/contents/tech/releases/stokenet) Latest release v0.2.4 (April 2024) The Radix Desktop Tool is an open-source desktop utility for Radix built by community member HODL6666. It bundles the operations that the Radix Wallet (/contents/tech/core-protocols/radix-wallet) either does not expose or caps – batched token transfers, manifest building, package deployment, and address conversion – into a single MIT-licensed application that runs locally rather than in a browser. Features - Token transfers – single → multiple and multiple → multiple in one operation. - Airdrop tool – sends to tens of thousands of addresses at once, past the Radix Wallet's 50–90 address ceiling. It signs locally with a private key you supply, which is why the author ships it as an auditable desktop app rather than a hosted service. - Transaction manifest builder – compose manifests (/contents/tech/core-protocols/transaction-manifests) without writing them by hand. - Scrypto (/contents/tech/core-protocols/scrypto-programming-language) package deployer – publish a compiled package to either network. - Token creation and asset verification. - Format conversion – Bech32 address ⇌ hexadecimal string. - Transaction history, entity verification, QR code generation, and a Stokenet XRD (/contents/tech/core-protocols/xrd-token) faucet. "Because the private key is related to the security of funds, the tool must be open source and free, having people review my code builds trust, and run as Desktop App, not Web App." – HODL6666 Supplying a private key to any tool puts the funds in that account at risk. The project's answer is that the source is public and the application runs on your own machine – read the code before you use the airdrop feature, and prefer a dedicated account over your main one. Status The latest release is v0.2.4, published in April 2024, which is also the date of the repository's most recent commit. The project is not archived and the code still works against the current network, but it has had no development activity for over two years – treat it as dormant rather than actively maintained, and verify behaviour on Stokenet (/contents/tech/releases/stokenet) before using it against mainnet funds. New users can switch the network to Stokenet, generate a throwaway account with Wallet Generate, and fund it from the built-in XRD faucet to try every feature without risk. External Links - Radix Desktop Tool on GitHub (https://github.com/atlantis-l/Radix-Desktop-Tool) – source and releases (MIT) - Building on Radix (/developers) – the wider community tooling index ## 5. Testing Scrypto Blueprints URL: https://radix.wiki/developers/scrypto/05-testing-scrypto Updated: 2026-09-03 Summary: Once your development environment is set up, the next step is understanding the Scrypto development workflow: creating packages, writing blueprints ,… Key Tools scrypto (/developers/scrypto/01-fundamentals) , resim, scrypto-test Introduction Once your development environment (/developers/getting-started/01-install-scrypto) is set up, the next step is understanding the Scrypto (/developers/scrypto/01-fundamentals) development workflow: creating packages, writing blueprints (/contents/tech/core-concepts/blueprints-and-packages) , building to WebAssembly (https://webassembly.org) , and testing locally. Radix provides two complementary testing approaches – the resim simulator for interactive exploration and the scrypto-test framework for automated testing. Package Structure A Scrypto (/developers/scrypto/01-fundamentals) package is a standard Rust crate with Scrypto (/developers/scrypto/01-fundamentals) -specific dependencies. scrypto new-package my-dapp (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-clis/src/scrypto/cmd_new_package.rs) writes seven files, not the three a bare cargo new would give you: my-dapp/ ├── Cargo.toml # scrypto dependency, scrypto-test dev-dependency, release profile ├── Cargo.lock # shipped, so --locked builds reproduce ├── rust-toolchain.toml # the Rust channel this package compiles with ├── .gitignore ├── src/ │ └── lib.rs # Blueprint definitions └── tests/ └── lib.rs # Test suite — both harnesses, pre-wired The src/lib.rs file contains one or more blueprints (/contents/tech/core-concepts/blueprints-and-packages) – reusable templates that define the structure and logic of on-ledger components (/contents/tech/core-concepts/components) . Each blueprint is annotated with the #[blueprint] macro and contains a struct (state) and an impl block (functions and methods). The generated tests/lib.rs (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-clis/assets/template/tests/lib.rs) is not a placeholder: it ships one test written against each of the two harnesses described below, so the choice is demonstrated before you write a line. The toolchain file decides which Rust you get rust-toolchain.toml is written from a template bundled inside the CLI binary (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-clis/assets/template/rust-toolchain.toml_template) , and rustup honours it over your default toolchain (https://rust-lang.github.io/rustup/overrides.html) . Under radix-clis 1.3.1 it pins: [toolchain] channel = "1.92.0" components = ["rustfmt", "rust-src"] targets = ["wasm32-unknown-unknown"] profile = "default" rust-src is not decoration – scrypto build rebuilds the Rust standard library for the WASM (https://webassembly.org) target (see below), which needs the standard library's source on disk. Because the pin travels with the CLI rather than with your machine, installing an older radix-clis quietly hands your package an older compiler: see Version Pins on the install page (/developers/getting-started/01-install-scrypto) . What the generated Cargo.toml sets The template manifest (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-clis/assets/template/Cargo.toml_template) tunes the release profile for on-ledger size and for safety: opt-level = 'z', link-time optimisation on, a single codegen unit, panic = 'abort', symbols stripped – and overflow-checks = true, so arithmetic overflow panics in release builds instead of wrapping silently. crate-type = ["cdylib", "lib"] produces both the WASM (https://webassembly.org) artifact and a linkable library, which is what lets the test harness call your blueprint directly. The file closes with an empty [workspace] stanza that hides the package from any ancestor Cargo workspace; delete it if you mean the package to be a workspace member. Building scrypto build is not a thin wrapper over cargo build. The compiler (https://github.com/radixdlt/radixdlt-scrypto/blob/main/scrypto-compiler/src/lib.rs) compiles the package twice: - Once with the schema, producing _with_schema.wasm, from which the .rpd (Radix Package Definition) is extracted. - Once without it – the scrypto/no-schema feature – producing the binary that actually gets published, then optimised with wasm-opt (https://github.com/WebAssembly/binaryen) . That pass runs by default and is disabled with --disable-wasm-opt (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-clis/src/scrypto/cmd_build.rs) . Both passes are release builds against wasm32-unknown-unknown with -Zbuild-std=std,panic_abort, and the artifacts land in target/wasm32-unknown-unknown/release/. Between the passes the compiler consults a local cache keyed on the hash of the with-schema WASM (https://webassembly.org) , so an unchanged package skips the second compile. The .rpd is the package's ABI – blueprint names, functions, methods and their type signatures – which the Radix Engine (/contents/tech/core-protocols/radix-engine) uses to validate calls at runtime. For a build that reproduces, pass --locked or set SCRYPTO_CARGO_LOCKED so the shipped Cargo.lock is used as-is. scrypto test and scrypto coverage accept the same flag and read the same environment variable, which makes it easy to set once across a CI job. Interactive Testing with resim The Radix Engine (/contents/tech/core-protocols/radix-engine) Simulator (resim) is a local ledger emulator that lets you publish packages, instantiate components, and call methods without connecting to any network. It is invaluable for rapid iteration. Core Commands # Reset simulator state resim reset # Create a new account (returns address, public key, private key, owner badge) resim new-account # Set the active account resim set-default-account # Publish a package (returns package address) resim publish . # Call a blueprint function (e.g. instantiate a component) resim call-function [args...] # Call a method on an instantiated component resim call-method [args...] # Inspect an entity's state resim show
Typical Workflow - resim reset – start with a clean ledger - resim new-account – create a test account - resim publish . – deploy your package - resim call-function – instantiate a component from your blueprint - resim call-method – interact with the component - resim show – inspect state, balances, and vaults (/contents/tech/core-concepts/buckets-proofs-and-vaults) Automated Testing with scrypto-test While resim is great for exploration, production packages need automated tests. Radix provides two testing frameworks: Unit Testing: scrypto-test The scrypto-test (https://docs.radixdlt.com/docs/scrypto-test) framework uses an invocation-based approach – you call blueprint functions and methods directly in Rust, receiving actual Bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) and Proof objects that you can assert against. At its core is the TestEnvironment struct, which encapsulates a self-contained Radix Engine (/contents/tech/core-protocols/radix-engine) instance. use scrypto_test::prelude::*; #[test] fn test_instantiation() -> Result<(), RuntimeError> { let mut env = TestEnvironment::new(); let package = PackageFactory::compile_and_publish( this_package!(), &mut env, CompileProfile::Fast, )?; // Call functions, assert on the returned buckets and proofs Ok(()) } Key utilities include BucketFactory and ProofFactory for creating test resources (/contents/tech/core-concepts/resources) , with strategies like CreationStrategy::DisableAuthAndMint for bypassing auth in test contexts. Integration Testing: LedgerSimulator The LedgerSimulator (https://docs.rs/scrypto-test/latest/scrypto_test/ledger_simulator/struct.LedgerSimulator.html) is an in-memory ledger where you interact as an external user submitting transactions, rather than calling methods directly. It applies the same costing limits and auth checks as the real network, which makes it the right harness for end-to-end tests. Build one with LedgerSimulatorBuilder, publish your package, then execute manifests (/contents/tech/core-protocols/transaction-manifests) against it. use scrypto_test::prelude::*; #[test] fn test_end_to_end() { let mut ledger = LedgerSimulatorBuilder::new().build(); let package_address = ledger.compile_and_publish(this_package!()); let (public_key, _private_key, account) = ledger.new_allocated_account(); let manifest = ManifestBuilder::new() .lock_fee_from_faucet() .call_function(package_address, "Hello", "instantiate_hello", manifest_args!()) .build(); let receipt = ledger.execute_manifest( manifest, vec![NonFungibleGlobalId::from_public_key(&public_key)], ); receipt.expect_commit_success(); } Earlier releases of the framework called this type TestRunner. It was renamed to LedgerSimulator, so test code written against older tutorials will not compile against current scrypto-test. Run all tests with: scrypto test This wraps cargo test with the correct Scrypto (/contents/tech/core-protocols/scrypto-programming-language) feature flags and environment. Code Coverage A third command completes the set, and it is easy to miss because no tutorial reaches for it: scrypto coverage (https://github.com/radixdlt/radixdlt-scrypto/blob/main/radix-clis/src/scrypto/cmd_coverage.rs) runs the package's tests and generates an LLVM source-based coverage (https://doc.rust-lang.org/rustc/instrument-coverage.html) report over the blueprint code that ran inside them. scrypto coverage It asks more of the machine than scrypto build does, and its own implementation states the four assumptions up front: the coverage WASM (https://webassembly.org) is built with the nightly toolchain, you do not get to choose which nightly – it uses whichever is on the system – the target is always wasm32-unknown-unknown, the profile is always release, and clang, llvm-cov and llvm-profdata must already be installed and on your PATH. A machine set up only to run scrypto build satisfies none of the last three, which is the usual reason the command fails on first use. Next Steps - Vault and Resource Patterns (/developers/scrypto/06-vault-patterns) – the idioms for holding and moving resources inside a component External Links - Resim – Radix Engine Simulator (https://docs.radixdlt.com/docs/resim-radix-engine-simulator) - scrypto-test Framework – Official Docs (https://docs.radixdlt.com/docs/scrypto-test) - scrypto-test API Reference – docs.rs (https://docs.rs/scrypto-test/latest/scrypto_test/) - Testing Multi-Blueprint Packages – Official Docs (https://docs.radixdlt.com/docs/learning-to-test-a-multi-blueprint-package) - The package template scrypto new-package writes – radixdlt-scrypto (https://github.com/radixdlt/radixdlt-scrypto/tree/main/radix-clis/assets/template) - scrypto-compiler – the two-phase build flow in source (https://github.com/radixdlt/radixdlt-scrypto/blob/main/scrypto-compiler/src/lib.rs) ## 1. Transaction Manifest Language URL: https://radix.wiki/developers/transactions/01-manifest-language Updated: 2026-09-03 Summary: A transaction manifest is a human-readable script that describes exactly what a transaction does – which assets move where, which components are calle… What is a Transaction Manifest? A transaction manifest (https://docs.radixdlt.com/docs/learning-to-create-and-use-transaction-manifests) is a human-readable script that describes exactly what a transaction does – which assets move where, which components (/contents/tech/core-concepts/components) are called, and in what order. Unlike EVM bytecode, manifests are transparent: the Radix Wallet (/contents/tech/core-protocols/radix-wallet) summarizes them in plain language so users never "blind sign." Manifests use a bash-like syntax where each instruction is a command followed by typed arguments and a semicolon. Instructions execute sequentially – if any fails, the entire transaction rolls back atomically. The Worktop Every transaction has a worktop (/contents/tech/core-concepts/worktop) – a temporary holding area for resources (/contents/tech/core-concepts/resources) in transit. When you withdraw tokens from an account, they land on the worktop. You then take them into named buckets (https://docs.radixdlt.com/docs/resources) and pass them to methods or deposit them. # Withdraw 10 XRD — tokens land on worktop CALL_METHOD Address("account_rdx...") "withdraw" Address("resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd") Decimal("10") ; # Take from worktop into a named bucket TAKE_FROM_WORKTOP Address("resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd") Decimal("10") Bucket("xrd_bucket") ; Core Instructions Instruction Purpose CALL_METHOD Call a method on a component (e.g., withdraw, deposit, swap) CALL_FUNCTION Call a function on a blueprint (/contents/tech/core-concepts/blueprints-and-packages) (e.g., instantiate) TAKE_FROM_WORKTOP Take a specific amount from worktop into a bucket (/contents/tech/core-concepts/buckets-proofs-and-vaults) TAKE_ALL_FROM_WORKTOP Take all of a resource from worktop into a bucket ASSERT_WORKTOP_CONTAINS Assert minimum amount on worktop (slippage protection) CREATE_PROOF_FROM_BUCKET_OF_AMOUNT Create an authorization proof from a bucket Value Types - Address("resource_rdx...") – entity addresses - Decimal("10.5") – numeric amounts - Bucket("name") – named bucket references - Proof("name") – named proof references - Expression("ENTIRE_WORKTOP") – deposit everything remaining Addresses carry their network, and the checksum is checked first Every address in a manifest names one network, and a manifest may only reference one network at a time. The prefix tells you which: account_rdx1... and resource_rdx1... are Mainnet, while Stokenet uses account_tdx_2_1... and resource_tdx_2_1..., and the local simulator uses _sim1.... XRD (/contents/tech/core-protocols/xrd-token) therefore has a different address on each one: Network XRD resource address Mainnet resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd Stokenet (/contents/tech/releases/stokenet) resource_tdx_2_1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxtfd2jc Simulator (resim) resource_sim1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxakj8n3 The three look almost identical, and the last six characters are the Bech32m (https://en.bitcoin.it/wiki/Bech32) checksum, so swapping one prefix for another without recomputing the rest produces an address that no tool will accept. This fails early rather than quietly: the Radix Engine Toolkit (/developers/transactions/04-radix-engine-toolkit) rejects the manifest at parse time with an InvalidGlobalAddress error naming the offending address, and the wallet never sees it. Paste an address you are unsure about into the Developer Console (https://console.radixdlt.com) or a Gateway (/contents/tech/core-protocols/radix-gateway-api) lookup before you build a manifest around it. Common Patterns Simple Token Transfer CALL_METHOD Address("account_rdx_sender...") "lock_fee" Decimal("5"); CALL_METHOD Address("account_rdx_sender...") "withdraw" Address("resource_rdx1tk...xrd...") Decimal("100") ; TAKE_ALL_FROM_WORKTOP Address("resource_rdx1tk...xrd...") Bucket("tokens"); CALL_METHOD Address("account_rdx_recipient...") "try_deposit_or_abort" Bucket("tokens") Enum<0u8>() ;DEX Swap with Slippage Protection CALL_METHOD Address("account_rdx...") "withdraw" Address("token_a_addr") Decimal("100") ; TAKE_ALL_FROM_WORKTOP Address("token_a_addr") Bucket("input"); CALL_METHOD Address("dex_component_addr") "swap" Bucket("input") ; # Ensure minimum output — reverts if not met ASSERT_WORKTOP_CONTAINS Address("token_b_addr") Decimal("95"); CALL_METHOD Address("account_rdx...") "deposit_batch" Expression("ENTIRE_WORKTOP") ; Atomic composability (/contents/tech/core-concepts/atomic-composability) You can chain calls to multiple components in one manifest. If a DEX swap feeds into a lending protocol deposit, both succeed or both fail – no partial state. Building Manifests Programmatically While you can write manifests by hand, most dApps build them in code: - TypeScript – the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) sends manifests via sendTransaction - Rust – the ManifestBuilder (https://docs.radixdlt.com/docs/rust-manifest-builder) provides a fluent API - Console – the Developer Console (https://console.radixdlt.com) has a raw transaction editor Next Steps - Transaction Lifecycle (/developers/transactions/02-transaction-lifecycle) – what happens between building a manifest and seeing it committed External Links - Complete instruction reference (https://docs.radixdlt.com/docs/manifest-instructions) - Manifest value syntax (/contents/tech/core-protocols/transaction-manifests) - Simple token transfer example (https://docs.radixdlt.com/docs/simple-token-transfer) - Rust ManifestBuilder (https://docs.radixdlt.com/docs/rust-manifest-builder) ## DApp In a Day Workshop #7 - Roehampton University URL: https://radix.wiki/contents/history/dapp-in-a-day-workshop-7-roehampton Updated: 2026-09-03 Summary: DApp In A Day #7 was the seventh and last recorded event in the DApp In A Day series of Scrypto developer workshops. It was held at the University of… DApp In A Day #7 was the seventh and last recorded event in the DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) series of Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developer workshops. It was held at the University of Roehampton on the 3rd of November, 2025, a year after the same university hosted #3 (/contents/history/dapp-in-a-day-workshop-3-roehampton) , and ran inside the university’s Career Development Week rather than as a standalone Radix event — students registered through Roehampton’s own careers platform, and the day closed with two dApps deployed to Stokenet (/contents/tech/releases/stokenet) . Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: 3rd November, 2025 TIME: 10:00 - 16:00 LOCATION: DB117, Sir David Bell Building, Digby Stuart College, Roehampton Lane, London, SW15 5PU. MENTORS: Avaunt (https://x.com/a_vaunt) (ShardSpace) REGISTRATION: Handshake (https://app.joinhandshake.co.uk/edu/events/55654) In the series By this event the series had been running for just over a year, from #1 at the University of Westminster (/contents/history/dapp-in-a-day-workshop-1) in October 2024. Roehampton is one of two universities that hosted twice, alongside St Mary’s ( #2 (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) and #5 (/contents/history/dapp-in-a-day-workshop-5) ); mentoring had by then passed from the original pair to the ecosystem, with Avaunt (https://x.com/a_vaunt) of Shardspace (https://shardspace.app/) running this one. The full index of the series is kept on the #1 page (/contents/history/dapp-in-a-day-workshop-1) ; other Radix developer events are collected under History / Events (/contents/history) . Media This week is career development week at Roehampton University and we kicked things off with an exciting Hackathon and workshop hosted by Radix, diving into their revolutionary smart contract language… | Mastaneh Davis PhD, SFHEA (https://www.linkedin.com/posts/mastaneh-davis-phd-sfhea-a4a72a17_this-week-is-career-development-week-at-roehampton-activity-7391625132991217664-QJe6) Gallery DApps Deployed Two dApps reached Stokenet (/contents/tech/releases/stokenet) , committed in txid_tdx_2_1lavfe7kmhxnuz2dte4kzchwwh6krrzqvdzaefzp4u9csaxswr5tqfm87yx and txid_tdx_2_1lfz032d9j3uk43peg5fzyhmse9uuhpeupwvrdgw528jl42wajjfs602q3c. Neither transaction can be read now. Stokenet (/contents/tech/releases/stokenet) was reset in August 2026 and restarted from epoch 1, so the ledger this work was committed to no longer exists. Read on 3 September 2026, the network's Gateway (https://babylon-stokenet-gateway.radixdlt.com) answers TransactionNotFoundError for both hashes, and stokenet.radxplorer.com returns its own shell rather than a transaction page. The hashes are kept here as the record. Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a "Submission"). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. PHOTOGRAPHY AND VIDEO CONSENT By participating in this Workshop, Entrants acknowledge and consent to the Workshop Organizer and its authorized representatives taking photographs, videos, audio recordings, or other media ("Media") of Entrants during the Workshop. Entrants grant the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create derivative works from, and publicly display such Media for promotional, marketing, educational, documentation, or other business purposes in any medium now known or hereafter developed, including but not limited to websites, social media, publications, and presentations. ## Brunel Hack 25 - Brunel University URL: https://radix.wiki/contents/history/brunel-hack-25 Updated: 2026-09-03 Summary: Brunel Hack 25 was a 2-day hackathon on the 12-13th of July, 2025, organized by the Brunel Society of Blockchain and held at the university campus in… Brunel Hack 25 was a 2-day hackathon on the 12-13th of July, 2025, organized by the Brunel Society of Blockchain and held at the university campus in Uxbridge. It was the society’s second Radix event, after the Brilliant On Chain (/contents/history/dapp-in-a-day-workshop-4) DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) workshop in December 2024, and the larger of the two: a weekend format with a $10,000 prize pool, judged submissions, and dApps deployed to Stokenet (/contents/tech/releases/stokenet) . Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: 12-13th July, 2025 TIME: 10:00 - 22:00 LOCATION: Michael Sterling Building, Brunel University, Uxbridge UB8 3PH MENTORS: Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak/) REGISTRATION: Eventbrite (https://www.eventbrite.com/e/brunel-hack-25-blockchain-hackathon-festival-10k-usd-in-prize-tickets-1380033640769) Media Gallery Winners StreamFlow https://github.com/Sahid-m/radix-hack (https://github.com/Sahid-m/radix-hack) Streamflow is a decentralized tipping platform designed for content creators and streamers. The platform aims to provide an alternative to traditional streaming services like YouTube and Twitch by eliminating commission fees typically charged by these platforms when viewers send tips to their favorite creators. Technology and Features Streamflow operates using blockchain technology and smart contracts. The platform's key innovation is its batch processing system, which uses Radix subintents to collect multiple tips together before sending them to creators. This batching mechanism is designed to reduce transaction fees (gas fees) by processing multiple payments simultaneously rather than individually. Users connect their cryptocurrency wallets to the platform and can select creators to support using various tokens. The system accumulates tips in batches and automatically distributes them to creators once predetermined thresholds are reached. User Interface The platform provides analytics dashboards for both tippers and streamers, displaying statistics such as tip amounts, frequency, token types used, and creator rankings. Users can track their tipping history and view comprehensive analytics about their platform activity. Purpose Streamflow was created to address what its developers view as a monopolistic practice by major streaming platforms that take commissions from creator tips. The platform positions itself as ensuring that creators receive the full amount of tips sent by their supporters without third-party deductions. Team Sahid Munjavar (https://www.linkedin.com/in/sahidm/) , Ibad Ullah Zuberi (https://www.linkedin.com/in/ibad-ullah-zuberi/) , Abdul Wasey (https://www.linkedin.com/in/abdul-wasey-ahmed-khawaja-070a71170/) Other Participants Xio https://github.com/EnaihoVFX/XIO (https://github.com/EnaihoVFX/XIO) Xio is a fast-paced, blockchain-powered arena game where players battle using NFT-based characters, trade assets in an on-chain marketplace, and compete on a transparent, tamper-proof leaderboard – redefining ownership and fairness in gaming. Team: Caymann Velingkar (https://www.linkedin.com/in/caymann-velingkar-975014207/) , Usman, Enaiho Uwas Paul (https://www.linkedin.com/in/enaiho-uwas-paul/) Cam Tech https://github.com/YadidyaM/radix (https://github.com/YadidyaM/radix) Cam Tech is a Radix blockchain-based intent escrow trading platform MVP. Team: Yadidya Medepalli (https://www.linkedin.com/in/yadidya-medepalli/) , Monica Jayakumar (https://www.linkedin.com/in/monicajayakumar/) , Amrin Asokan (https://www.linkedin.com/in/amrin-asokan/) Presentation: https://drive.google.com/open?id=1H30OUjjUt5JyyCHgWqzepZktgvSrWP1H (https://drive.google.com/open?id=1H30OUjjUt5JyyCHgWqzepZktgvSrWP1H) Demo Video: unavailable DApps Deployed One dApp reached Stokenet (/contents/tech/releases/stokenet) , committed in txid_tdx_2_1qzsd4k4h85yfwja6yhjy0kkz2vywctuajm773ftjnkn94zemnzsqyvp67l. The transaction can no longer be read. Stokenet (/contents/tech/releases/stokenet) was reset in August 2026 and restarted from epoch 1, so the ledger this work was committed to no longer exists. Read on 3 September 2026, the network's Gateway (https://babylon-stokenet-gateway.radixdlt.com) answers TransactionNotFoundError for the hash, and stokenet.radxplorer.com returns its own shell rather than a transaction page. The hash is kept here as the record. Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a “Submission”). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## Muan Protocol URL: https://radix.wiki/ecosystem/muan-protocol Updated: 2026-09-02 Summary: Muan Protocol is an on-chain DAO governance and decentralized voting framework built on Radix . Organizations use it to manage members, vote on propos… Type On-Chain Governance Framework Status In development (mainnet interface paused pending V2; both sites behind an expired certificate since 2 September 2026) Category DAO Governance / DeFi Network Radix Mainnet (+ Stokenet testnet) Builder Sentura Overview Muan Protocol (https://muanprotocol.com) is an on-chain DAO governance and decentralized voting framework built on Radix (/contents/tech/core-protocols/radix-engine) . Organizations use it to manage members, vote on proposals, and execute decisions directly on-ledger. Its distinguishing design is that a governance vault physically holds the authority badges (/contents/tech/core-concepts/badges) it controls, rather than that authority being wired into each individual contract – a pattern made possible by Radix's asset-oriented resource model. The framework is built by the studio Sentura. How It Works - Voting types – binary (For/Against) and ranked-choice voting, with Sentiment or Intent modes. Voting power can be measured in fungible tokens or Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) , with optional time-weighted multipliers. - Vote NFTs – a member deposits tokens once into a Vote NFT and can then participate in multiple proposals simultaneously, and delegate voting power while retaining token ownership. The announced V2 design replaces this deposit step with snapshot voting (see below). - On-ledger execution – Intent proposals can execute real on-ledger actions automatically once approved by the community. - Treasury – a built-in treasury supports payment streams and recurring instruction-set actions for scheduled on-chain operations. A separate Stokenet testnet instance (https://testnet.muanprotocol.com) lets teams trial governance setups before deploying to mainnet. V2 Rebuild and Mainnet Pause (2026) On 2 August 2026 the team announced in the main Radix Telegram channel (https://t.me/radix_dlt/997068) that the mainnet frontend was being paused until the next version of the protocol is ready, giving the reason as "basically no users" on the current version. Anyone who spent network fees creating a V1 Vote NFT is being reimbursed. The upgrade notice on the project's site (https://muanprotocol.com) states the same position in more detail: the app is offline while the next version is prepared for mainnet, and Vote NFTs, deposits, governances and proposals remain as they are on the Radix ledger, with only the interface paused. Everyone who created a Vote NFT or a governance is reimbursed for the creation cost, and no action is required from holders in the meantime. The Stokenet testnet instance (https://testnet.muanprotocol.com) stays available. The headline feature of the new version is snapshot voting: voting power is measured from the balance a member held at a fixed past instant, with nothing deposited, locked or moved, so tokens stay in the wallet and stay transferable. This removes the deposit step of the V1 design, in which a member deposits tokens into a Vote NFT before voting. The project states that full details follow at launch. Component-Level Execution Engine On 13 August 2026, Nicolai of Sentura described the framework’s execution layer (https://t.me/radix_dlt/998124) in the main Radix Telegram channel. A Muan component can execute arbitrary transactions from the component level, addressing any other component, account, validator node (/contents/tech/core-concepts/validator-nodes) or metadata setting; the stated exception is calls that publish new packages, which the engine cannot make. The capability rests on the same property as the governance vault described above — on Radix (/contents/tech/core-protocols/radix-engine) , the authority to make a call is a badge (/contents/tech/core-concepts/badges) a component can hold, so the component itself can be the actor rather than a key held by a person. Within Muan, this is what carries out an approved Intent proposal on-ledger. In the same message the builder said he is considering publishing the execution engine as a standalone component, and asked the channel for use cases beyond Muan’s own — which he summarised as democratizing access. No release date or repository was given. The certificate expired and both sites went behind a browser warning (2 September 2026) Read at 23:00 UTC on 2 September 2026, neither address this page points a reader at opens in a browser without a security warning. Both hosts are up and their content is unchanged: a request that skips certificate validation returns the same upgrade notice as before, 7,501 bytes from muanprotocol.com (https://muanprotocol.com) , and the application shell, 17,163 bytes from the Stokenet instance (https://testnet.muanprotocol.com) . A single Let's Encrypt (https://letsencrypt.org/docs/faq/) certificate covers both names. It was issued on 4 June 2026 and expired at 08:32:40 UTC on 2 September 2026, fourteen and a half hours before this reading. Let's Encrypt issues for ninety days and expects renewal at sixty, so a certificate that runs to its final day is one whose renewal has not completed for about a month. Nothing else about the deployment has changed and the project has announced nothing. Those two addresses are the only public surfaces Muan has, and since this morning both open an interstitial before a reader sees the page. External Links - Muan Protocol – Official Website (https://muanprotocol.com) - Muan Protocol – Documentation (https://muanprotocol.com/docs) - Muan Protocol – Stokenet Testnet (https://testnet.muanprotocol.com) - Muan Studio – X (Twitter) (https://x.com/muan_studio) See also - Caper (/ecosystem/caper) – on-chain DAO governance and treasury with a built-in exit right ## Academia Scrypto URL: https://radix.wiki/ecosystem/academia-scrypto Updated: 2026-09-02 Summary: Academia Scrypto was a community-run educational initiative that taught Scrypto , the asset-oriented smart-contract SDK developed by RadixDLT for the… Project Academia Scrypto Type Community education initiative Focus Scrypto (/contents/tech/core-protocols/scrypto-programming-language) smart-contract development Languages Spanish, Italian Network Radix (/ecosystem) Status 🔴 Closed (last repository push June 2022) Website academiascrypto.com (no DNS record) Source GitHub – AcademiaScrypto (https://github.com/AcademiaScrypto) Academia Scrypto was a community-run educational initiative that taught Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , the asset-oriented smart-contract SDK developed by RadixDLT (https://docs.radixdlt.com/docs) for the Radix (/ecosystem) network. It offered free lessons and resources aimed primarily at Spanish- and Italian-speaking developers, published on a project website and companion YouTube channel and mirrored as open content on GitHub (https://github.com/AcademiaScrypto) . What it offered The academy published a progressive, beginner-oriented path into Scrypto fundamentals (/developers/scrypto/01-fundamentals) , requiring no prior programming or blockchain experience. Its stated motivations for learning Scrypto mirrored the SDK’s own design goals – a lighter learning curve than other smart-contract DSLs, an asset-oriented model designed to reduce costly errors, reusable and composable "Components," and growing demand for Radix developers. Content was maintained in two localisations, the Spanish repository (https://github.com/AcademiaScrypto/Web-AccademiaScrypto-Espanol) and its Italian translation (https://github.com/AcademiaScrypto/Web-AccademiaScrypto-Italiano) , so that non-English speakers were not excluded from the ecosystem. Current status Academia Scrypto is no longer active. Its website, academiascrypto.com, no longer resolves, and its two GitHub repositories (https://github.com/AcademiaScrypto) have seen no updates since 2022: the Spanish content was last pushed on 19 May 2022 and the Italian translation on 1 June 2022. A second domain, aprendescrypto.com, still answers, but it serves an unconfigured website template titled "Home - Accessible Astro Starter" and carries nothing about Scrypto or the academy. The project belongs to Radix’s early Scrypto (/contents/tech/core-protocols/scrypto-programming-language) -education wave, and while its published material survives as static markdown on GitHub, it reflects Scrypto as it stood at that time and is not maintained against current Scrypto releases. Developers looking for an up-to-date learning path should use the officially maintained resources: the Radix documentation (https://docs.radixdlt.com/docs) , the interactive Scrypto 101 course (https://academy.radixdlt.com/course/scrypto101) , and this wiki’s own install guide (/developers/getting-started/01-install-scrypto) and Scrypto fundamentals (/developers/scrypto/01-fundamentals) tutorials. External Links - GitHub – AcademiaScrypto account (https://github.com/AcademiaScrypto) - Web-AccademiaScrypto-Espanol (Spanish content) (https://github.com/AcademiaScrypto/Web-AccademiaScrypto-Espanol) - Scrypto 101 – Radix Academy (https://academy.radixdlt.com/course/scrypto101) - Radix documentation (https://docs.radixdlt.com/docs) ## Impahla URL: https://radix.wiki/ecosystem/impahla Updated: 2026-09-02 Summary: Impahla was a smart contract-based digital asset platform , renowned for its specialization in both Primary Token Sales (including FT and NFT) via auc… Impahla was a smart contract-based digital asset platform (https://www.radixdlt.com/blog/runs-on-radix-q-a-impahla) , renowned for its specialization in both Primary Token Sales (including FT and NFT) via auctions and its secondary marketplace capabilities for NFTs. Besides its core functionalities, Impahla offered extended features including DAO governance tools, escrow services, and a unique lending app centered around NFT as collateral. Mission In an interview with RDX Works (https://youtu.be/kyNuXXFD6hg) , Jafaroff stated that mission was to usher in a new era of decentralized investment banking (https://www.radixdlt.com/blog/runs-on-radix-q-a-impahla) , unshackling projects from the confines of traditional finance mechanisms. This would be achieve by helping start-ups, associations, creators, and distributed ledger technology-related projects raise funds securely in return for various types of fungible and non-fungible tokens. The platform aimed to provide easy access to novice investors, who often find current tools complex to navigate and thus are excluded from such innovative opportunities. Impahla addressed many fundraising and security inefficiencies present in first-generation decentralized launchpads and traditional finance fundraising platforms. It provided a single platform that catered to end-to-end lifecycle management of both fungible and non-fungible tokens. The platform's algorithms for price discovery, fair access allocation, and aftermarket allocation utilized the latest DLT to create a better experience for all participants. Platform Impahla was designed to offer next-generation features that enabled founders, investors, and users to: - Raise funds. - Tokenize companies. - Invest in tokenized companies. - Govern tokenized companies. - Access a liquid secondary market for trading in and out of the portfolio of tokens created on the launchpad. - Enjoy a rich set of functionalities and services to support their investment experience. Fundraising and NFT Launches Impahla facilitated the fundraising and asset launching process for crypto-native enterprises and NFT projects, addressing the limitations of traditional fundraising, such as high fees, geographical restrictions, and excessive paperwork. The platform aimed to eliminate these hurdles by leveraging the power of Radix DLT technology, democratizing the capital raise process, and creating synergy between projects and communities in a legally secure environment. Impahla served as a decentralized NFT launchpad for the Radix ecosystem, offering a secure outlet for creators to launch and sell assets that may not have a market elsewhere. The platform enabled creators to mint and launch various types of NFT products, such as real-life collectibles, videos, car titles, event tickets, and more. The platform also had a long-term mission of bridging decentralized finance (DeFi) with the real economy by onboarding off-chain enterprises into the crypto economy and assisting them in integrating with decentralized communities. Impahla envisioned itself as a prominent fundraising platform not only for on-chain companies but also for real economy enterprises that wish to tokenize their equity or issue utility tokens and benefit from innovative decentralized governance tools. Auction Models Impahla offered multiple auction models, such as Dutch auction and second price auction, to ensure founders achieve fair valuations and targeted fundraising for their ventures and assets. Asset Types Impahla helped crypto-native enterprises and NFT creators with the issuance of various asset types, including: - Governance tokens: Allowing Crypto Native Enterprises (CNEs) to issue their governance tokens - Utility tokens: Granting rights related to products or services, such as participation in online games or decision-making within a project - Hybrid tokens: Combining governance and utility functions - NFTs: Any NFT product DAO Dynamics Impahla envisioned itself as a Decentralized Autonomous Organization (DAO), a community-led entity with no central authority that is fully autonomous and transparent. Smart contracts lay the foundational rules and execute agreed-upon decisions. Incentive alignment and successful collaboration among all stakeholders and participants are crucial for a successful DAO. Impahla DAO aimed to enable fluid collaboration and provide flexibility for high-quality talent to contribute to the Impahla ecosystem consistently. To attract and retain high-quality talent who add value to Impahla DAO, the platform had allocated 20% of its tokenomics to "DAO Incentives." These incentives would be distributed among participants based on their impact and contribution to the DAO. Community Focus Impahla aimed to build a robust and successful community within the Radix ecosystem, with a shared vision and passion. The platform sought to create a space where people with common interests can come together, learn, and grow around a shared vision. To achieve this, Impahla had allocated 15% of its tokenomics to Public sales and 15% to airdrop campaigns. Half of the airdrop allocation would go to Impahla NFT holders, while the other half would go to Radix Stakers, promoters of Impahla, active community members, and supporters. Team Impahla was conceived as a DAO, projecting a future dominated by community-led operations underpinned by code. The project's inception can be attributed to a synergic partnership formed within the Radix ecosystem in 2021. The core team members included: - Matt Croq: A veteran developer with a 12-year experience, Croq was integral to Impahla's technical framework. - Eric: With three years in the field, Eric specializes in front-end development and has a notable third place in the Scrypto Challenge. - Jafaroff: As a product development and marketing expert with 13 years of professional experience, Jafaroff played a pivotal role within Impahla. - Rachid: A seasoned finance professional, Rachid specializes in product strategy and business development. - Miro: Originally from the Radix community, Miro's expertise as a mobile app developer bolstered Impahla's aspirations in the mobile domain. Tokenomics Impahla tokenomics (https://medium.com/@impahla/impahla-tokenomics-95d879028bfe) was designed around two critical elements: DAO dynamics (incentive alignment) and the Community. Token Allocation - 20% - DAO Incentives - 15% - Public Sales - 15% - Airdrop Campaigns - 18% - DAO Reserve The DAO Reserve, comprising 18% of the token allocation, would be spent only through community voting. These reserve funds were allocated for the ecosystem's future growth, and the community would decide their usage. The platform had not yet decided on the timeline for private and public sales, as their primary focus was on building the initial version of the product. Allocation among public and private sales may change as Impahla evolved and grew with the community. Any modifications or decisions regarding private or public sales would be made through community consultation and voting. Choice of Radix Impahla's decision to build on Radix was multi-faceted: - Full Stack Approach: Radix's from-the-ground-up approach echoed Impahla's zeal for innovation. - Community Alignment: The shared ethos of fostering a genuine and engaged community bound the two platforms. - Tooling: Radix’s Scrypto SDK simplified the development process for Impahla. - Radix's Work Ethos: Radix's emphasis on technical accuracy and a product-centric approach resonated with Impahla's own philosophy. See also - Caper (/ecosystem/caper) – on-chain DAO formation, treasury, and exit rights Telegram Handle No Longer the Project's The Telegram handle @Impahla, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . ## Root Finance URL: https://radix.wiki/ecosystem/root-finance Updated: 2026-09-02 Summary: Root Finance is a decentralized Lending & Borrowing protocol operating on Radix. The platform enables users to participate as either depositors or bor… Root Finance Type Overcollateralised lending & borrowing protocol (money market) Network Radix (https://www.radixdlt.com/) (built in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) ) Status 🟠 Dormant (minimal on-chain activity) Peak TVL ≈ $1.67M (24 April 2025) – DeFiLlama (https://defillama.com/protocol/root-finance) TVL (Jul 2026) ≈ $2K – DeFiLlama (https://defillama.com/protocol/root-finance) Docs docs.rootfinance.xyz (https://docs.rootfinance.xyz/) Source GitHub (https://github.com/RootFinanceRadix) Social X (https://x.com/rootfinancexrd) · Telegram (https://t.me/ROOTfinanceradix) Root Finance is a decentralized Lending & Borrowing protocol (https://docs.rootfinance.xyz/) operating on Radix. The platform enables users to participate as either depositors or borrowers within an overcollateralized market environment. As a non-custodial liquidity protocol, Root Finance allows lenders to earn passive income by providing liquidity to the market, while borrowers can obtain funds in an overcollateralized manner. Protocol Status Root Finance's total value locked (TVL) peaked at roughly $1.67 million on 24 April 2025, then declined steeply over the following year. By July 2026, protocol TVL had fallen to around $2,000, according to DeFiLlama (https://defillama.com/protocol/root-finance) . The lending contracts and front-end remain live, but usage is now minimal, so the protocol is best regarded as dormant rather than actively growing. The sections below describe the protocol's design and mechanics as documented by the team. Key Features - Decentralized Operation: Root Finance operates on the Radix DLT, leveraging blockchain technology to ensure transparency and decentralization. - Non-custodial Design: The protocol is designed to be non-custodial (https://docs.rootfinance.xyz/introduction/security) , eliminating the need for intermediaries or custodial control of user assets. - Overcollateralization: Borrowers must provide collateral that exceeds the value of their loan, helping to secure the protocol against defaults. - Liquidity Provision: Users can supply various cryptocurrencies to the protocol, earning interest on their deposits. - Borrowing Facility: Users can borrow supported cryptocurrencies by using their deposited assets as collateral. - Root Receipts: Depositors receive Root Receipts (e.g., rtxETH, rtxUSDC) (https://docs.rootfinance.xyz/user-guide/supply-lend) representing their right to redeem supplied assets. - Dynamic Interest Rates: The protocol uses an interest rate model (https://docs.rootfinance.xyz/tecnical-guide/interest-rate-model-of-root-finance) that adjusts based on the utilization rate of the assets in the pool. - Liquidation Mechanism: To maintain the protocol's solvency, positions may be liquidated (https://docs.rootfinance.xyz/liquidations) if they fall below certain collateralization thresholds. - Flash Loans: The protocol offers a flash loan feature, allowing users to borrow without collateral for a single transaction, provided the loan is repaid within the same transaction. Root Finance aims to provide a user-centric platform for the Radix community, enhancing capital strategies through a simple yet comprehensive Lending & Borrowing Decentralized Application (Dapp). The protocol has undergone security audits (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) to ensure the integrity and safety of the system, with its smart contracts being open-source and publicly available for review. Protocol Overview Root Finance is a decentralized money market protocol that operates on the Radix DLT. The protocol facilitates lending and borrowing of cryptocurrencies within an overcollateralized environment. This section provides an overview of the core functionality, supported assets, and unique features of the Root Finance protocol. Core Functionality The Root Finance protocol centers around two primary functions: - Lending: Users can supply their assets (https://docs.rootfinance.xyz/user-guide/supply-lend) to the Root Finance platform, becoming liquidity providers. The protocol aggregates these supplied assets into pools governed by smart contracts. Lenders earn passive income through interest generated from borrowers using these pools. - Borrowing: Users can borrow supported cryptocurrencies (https://docs.rootfinance.xyz/user-guide/borrow) by leveraging their deposited assets as collateral. The protocol ensures that all loans are overcollateralized, meaning the value of the collateral must exceed the value of the borrowed assets. The protocol utilizes smart contracts to manage these functions, ensuring that all operations are transparent, secure, and automated. Supported Assets Root Finance supports a variety of cryptocurrencies for both lending and borrowing. As of the latest documentation, the supported assets include: For Supply (Lending): - $WBTC (Wrapped Bitcoin) - $ETH (Ethereum) - $XRD (Radix) - $USDC (USD Coin) - $USDT (Tether) - $HUG - $LSULP (upcoming) For Borrowing: - $WBTC - $ETH - $XRD - $USDC - $USDT - $LSULP (upcoming) Each asset has specific parameters (https://docs.rootfinance.xyz/tecnical-guide/money-market-parameters) such as maximum Loan to Value (LTV) ratios and Liquidation Thresholds, which govern how they can be used within the protocol. Root Receipts When users supply assets to the Root Finance protocol, they receive Root Receipts in return (https://docs.rootfinance.xyz/user-guide/supply-lend) . These receipts (e.g., $rtxETH for Ethereum, $rtxUSDC for USD Coin) represent the user's right to redeem their supplied assets in the future. Key features of Root Receipts include: - Appreciation: The value of Root Receipts grows over time, reflecting the interest earned on the supplied assets. - Fungibility: Root Receipts are fungible tokens, meaning they can be transferred or potentially used in other DeFi protocols. - Interest Accrual: The appreciation of Root Receipts is determined by the interest rates on deposits, which are in turn influenced by the supply and demand dynamics of the assets within the protocol. Interest Rate Model Root Finance employs a dynamic interest rate model (https://docs.rootfinance.xyz/tecnical-guide/interest-rate-model-of-root-finance) that adjusts based on the utilization rate of assets in the pool. This model aims to balance liquidity risk and maximize utilization: - When capital is plentiful (low utilization), interest rates are set low to encourage borrowing. - When capital is scarce (high utilization), interest rates increase to incentivize repayments and additional deposits. The interest rate curve is segmented into two phases around an optimal utilization rate, with a steeper increase in rates beyond this optimal point to manage liquidity risk. Liquidation Mechanism To maintain the protocol's solvency and protect lenders, Root Finance implements a liquidation mechanism (https://docs.rootfinance.xyz/liquidations) . Liquidations occur when an account's collateral value decreases or the borrowed amount increases relative to the collateral, causing the loan-to-value (LTV) ratio to meet or exceed the liquidation threshold. During a liquidation: - Up to 40% of the loan value can be liquidated. - Liquidators receive an incentive, which includes an 8% liquidation fee. - The liquidation process aims to restore the loan to a healthy level of collateralization. This mechanism ensures that the protocol remains solvent and can continue to function even in volatile market conditions. Key Features Root Finance offers several key features that distinguish it in the decentralized finance (DeFi) ecosystem. These features are designed to provide a secure, efficient, and user-friendly platform for lending and borrowing cryptocurrencies. Non-custodial Design Root Finance is designed as a non-custodial platform (https://docs.rootfinance.xyz/introduction/security) , which means that users retain control of their assets at all times. Key aspects of this non-custodial design include: - Users' assets are secured within immutable smart contracts. - There's no need for intermediaries or custodial control. - The smart contracts are open-source and publicly available for review, adhering to the principle of "don't trust, verify." This design enhances security and aligns with the decentralized ethos of blockchain technology. Decentralized Governance While the documentation doesn't explicitly mention a governance system, the protocol operates on the Radix DLT (https://docs.rootfinance.xyz/) , which suggests a degree of decentralization in its operation. The specific governance mechanisms, if any, are not detailed in the provided documents. Interest Rate Model Root Finance implements a sophisticated interest rate model (https://docs.rootfinance.xyz/tecnical-guide/interest-rate-model-of-root-finance) designed to balance liquidity risk and maximize utilization. Key features of this model include: - Dynamic adjustment based on the Utilization Rate (U) of the asset pool. - A two-phase interest rate curve centered around an optimal utilization rate (Uoptimal). - Gradual rate increase up to Uoptimal, followed by a significant increase beyond this point. - Separate formulas for calculating borrow rates and deposit rates. This model aims to incentivize optimal capital allocation within the protocol. Liquidation Mechanism To maintain the protocol's solvency, Root Finance employs a liquidation mechanism (https://docs.rootfinance.xyz/liquidations) . Key aspects of this mechanism include: - Liquidations are triggered when an account's loan-to-value (LTV) ratio meets or exceeds the liquidation threshold. - Up to 40% of the loan value can be liquidated in a single event. - Liquidators receive an incentive, including an 8% liquidation fee. - The process aims to restore loans to healthy collateralization levels. This mechanism helps protect lenders and maintain the overall health of the protocol. Flash Loans Root Finance offers a flash loan feature, as evidenced by the security audit report (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) . Flash loans allow users to borrow assets without collateral, provided the loan is repaid within the same transaction. Key points about flash loans: - They enable complex DeFi operations and arbitrage opportunities. - The audit identified a critical vulnerability in the flash loan mechanism, which was subsequently fixed. - The implementation details and current status of flash loans are not fully described in the provided documentation. Security Measures Root Finance places a strong emphasis on security, as evidenced by several measures: - The protocol has undergone rigorous audits (https://docs.rootfinance.xyz/introduction/security) by reputable third-party firms. - Smart contracts are open-source and publicly available (https://docs.rootfinance.xyz/introduction/security) for community review. - The team adheres to best practices in blockchain industry development. Root Points System Root Finance implements a Root Points system (https://docs.rootfinance.xyz/root-points/rules) to incentivize user engagement. Key features of this system include: - Users earn points for interacting with the platform, such as supplying or borrowing assets. - Additional points can be earned through specific quests, like following Root Finance on social media. - A referral program allows users to earn bonus points. - Points are calculated based on the value of assets supplied or borrowed, with different rates for different assets. - A leaderboard displays top wallets based on their Root Points. This system adds a gamification element to the protocol, potentially increasing user engagement and retention. Technical Details Root Finance is built on a complex technical infrastructure designed to ensure security, efficiency, and functionality. This section delves into the technical aspects of the protocol, including its smart contracts, security measures, and integration with the Radix DLT. Smart Contracts Root Finance's core functionality is implemented through a series of smart contracts. The main components, as identified in the audit report (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) , include: - Lending Market: The central contract managing lending and borrowing operations. - Single Resource Pool: Handles individual asset pools. - Internal Price Feed: Provides price data for assets within the system. Key smart contract files and their functions include: - lending_market.rs: Implements the main lending market functionalities. - resources.rs: Defines the resources used in the system. - modules/cdp_data.rs: Manages Collateralized Debt Position (CDP) data. - modules/cdp_health_checker.rs: Checks the health of CDPs. - modules/interest_strategy.rs: Implements the interest rate strategy. - modules/liquidation_threshold.rs: Defines liquidation thresholds. - modules/pool_config.rs: Configures individual asset pools. - modules/pool_state.rs: Manages the state of asset pools. These contracts are written in Scrypto, the Rust SDK for building on Radix DLT. Security Measures Root Finance implements several security measures to protect user funds and ensure the integrity of the system: - Non-custodial Design: User assets are secured (https://docs.rootfinance.xyz/introduction/security) within immutable smart contracts, eliminating the need for trust in intermediaries. - Open Source Code: The smart contracts are entirely open-source (https://docs.rootfinance.xyz/introduction/security) and publicly available, allowing for community review and verification. - Third-party Audits: The protocol has undergone rigorous audits by reputable third-party firms (https://docs.rootfinance.xyz/introduction/security) to ensure the integrity and safety of the system. - Access Control: The system implements access control mechanisms (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) to restrict certain functions to authorized users only. - Decimal Precision Handling: The system uses the Decimal type for financial calculations, though the audit report (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) notes that there's room for improvement in standardizing decimal precision handling. Audits and Vulnerabilities An independent security audit (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) of Root Finance identified several issues: - Critical: A vulnerability in the flashloan mechanism allowing unrestricted burning of TransientResData resources, which could be exploited to avoid repaying flashloans. This issue was fixed. - Medium: - Lack of a liquidator badge revocation mechanism. - Centralized price feed, introducing a single point of failure risk. - Low: - Potential for creation of empty Collateralized Debt Positions (CDPs). - Inconsistent handling of decimal precision in financial calculations. These issues were addressed or mitigated following the audit. The report was published by TriWei, a smart-contract auditing collective that described itself (https://web.archive.org/web/20251014071813/https://triwei.io/) as "a collective of three solo auditors" working across Solidity, Rust and Scrypto. Its domain triwei.io lapsed on 24 August 2026 and now serves a registrar parking page, so the citations above resolve to the Internet Archive's 28 May 2026 capture (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) of the PDF. The same report remains downloadable from Root Finance's own security page (https://docs.rootfinance.xyz/introduction/security) as "ROOT FINANCE RADIX REPORT.pdf". User Interaction Root Finance provides a platform for users to engage in lending and borrowing activities. This section details the primary ways users can interact with the protocol, including supplying assets, borrowing, repaying loans, and the liquidation process. Supplying Assets Users can supply their assets to Root Finance to become liquidity providers. The process works as follows: - Asset Selection: Users can supply various cryptocurrencies (https://docs.rootfinance.xyz/user-guide/supply-lend) , including $WBTC, $ETH, $XRD, $USDC, $USDT, and $HUG. - Deposit: Users deposit their chosen assets into the Root Finance protocol. - Root Receipts: In return for their supplied assets, users receive Root Receipts (https://docs.rootfinance.xyz/user-guide/supply-lend) (e.g., $rtxETH, $rtxUSDC). These receipts represent the user's right to redeem their supplied assets in the future. - Interest Accrual: The value of Root Receipts grows over time, reflecting the interest rates on deposits determined by the supply and demand dynamics of the assets. - Withdrawal: Users can withdraw their supplied assets at any time by redeeming their Root Receipts, subject to the available liquidity in the protocol. Borrowing Root Finance allows users to borrow assets by using their supplied assets as collateral. The borrowing process involves: - Collateral: Users must first supply assets to use as collateral (https://docs.rootfinance.xyz/user-guide/borrow) . - Loan-to-Value (LTV) Ratio: Each asset has a specific LTV ratio, which determines the maximum amount that can be borrowed against it. The overall borrowing capacity (https://docs.rootfinance.xyz/user-guide/borrow) is calculated based on the average of the LTV ratios of the supplied assets, weighted by their respective values. - Borrowing: Users can borrow any of the supported cryptocurrencies (https://docs.rootfinance.xyz/user-guide/borrow) up to their borrowing limit. Available assets for borrowing include $WBTC, $ETH, $XRD, $USDC, and $USDT. - Interest Accrual: The borrowed amount accrues interest over time, based on the protocol's dynamic interest rate model. - Risk Management: Users need to monitor the market value of their collateral and borrowed amount to maintain a healthy financial position and avoid liquidation. Repaying Loans Users can repay their borrowed funds at any time using the "Repay" feature. The repayment process includes: - Flexible Repayment: Users can choose to make partial or full repayments (https://docs.rootfinance.xyz/user-guide/repay-your-borrow-on-root) of their loans. - LTV Reduction: Repaying loans lowers the user's LTV ratio (https://docs.rootfinance.xyz/user-guide/repay-your-borrow-on-root) , which is crucial for avoiding liquidation. - Collateral Release: As users repay their loans and their LTV decreases, they can withdraw a portion of their collateral (https://docs.rootfinance.xyz/user-guide/repay-your-borrow-on-root) . Full repayment allows for complete collateral withdrawal. - Interest Savings: Prompt repayment helps users minimize interest accumulation, allowing for better debt management. Liquidations Liquidations are a crucial part of the Root Finance protocol, ensuring its overall solvency. The liquidation process works as follows: - Triggering Conditions: Liquidations occur when an account's collateral value decreases or the borrowed amount increases (https://docs.rootfinance.xyz/liquidations) relative to the collateral, causing the LTV ratio to meet or exceed the liquidation threshold. - Liquidation Threshold: This is set at 5% above the Maximum LTV (https://docs.rootfinance.xyz/liquidations) for each asset. For example, if an asset's Max LTV is 70%, its Liquidation Threshold would be 75%. - Liquidation Process: When a position is flagged for liquidation, the protocol allows liquidation of up to 40% of the Loan Value (https://docs.rootfinance.xyz/liquidations) . - Liquidator Incentive: Liquidators receive an incentive for performing the liquidation. This includes a liquidation fee of 8% of the liquidation value (https://docs.rootfinance.xyz/liquidations) . - User Impact: For the user being liquidated, the liquidation results in a reduction of their debt, but also a loss of a portion of their collateral. - Health Bar: Root Finance provides a Health Bar feature (https://docs.rootfinance.xyz/liquidations) to help users monitor their position's health and proximity to the liquidation threshold. Users are encouraged to actively manage their positions, monitor market conditions, and maintain healthy LTV ratios to avoid liquidation events. Root Points System The Root Points system is an incentive mechanism designed by Root Finance to reward users for interacting with the platform. This system encourages user engagement and loyalty by offering points for various activities within the protocol. Earning Mechanisms Users can earn Root Points (https://docs.rootfinance.xyz/root-points/rules) through several methods: - Asset Supply and Borrowing: For every $100 worth of assets supplied or borrowed, users automatically accumulate Root Points every 24 hours. - Quests: Users can complete specific tasks to earn additional points. - Referrals: Users can earn bonus points by referring new users to the platform. The accumulation of points is based on snapshots of user positions taken at random times throughout each 24-hour period. Quests and Bonuses Root Finance offers several quests and bonuses (https://docs.rootfinance.xyz/root-points/rules) for users to earn additional Root Points: - Social Media Engagement: - Follow Root Finance on X (formerly Twitter): +10 Root Points (one-time bonus) - Join the Root Finance Telegram: +10 Root Points daily - Asset Deposit: - Deposit at least $200 USD worth of assets: Earn Root Points daily based on the value deposited - Asset Borrowing: - Borrow at least $100 USD worth of assets: Accumulate Root Points daily based on the value borrowed - Referral Program: - Invite a friend to join Root Finance: Earn an additional 10% of the Root Points they accumulate every 24 hours Point Calculation The number of Root Points earned depends on the type and amount of assets supplied or borrowed: - Supply Bonus: - For every $100 worth of $XRD, $WBTC, $ETH and $LSU (https://docs.rootfinance.xyz/root-points/rules) : 1 Root Point every 24 hours - For every $100 worth of $USDC and $USDT (https://docs.rootfinance.xyz/root-points/rules) : 2 Root Points every 24 hours - For every $100 worth of $HUG (https://docs.rootfinance.xyz/root-points/rules) : 3 Root Points every 24 hours - Borrow Bonus: - For every $100 worth of $USDC, $USDT, $XRD, $WBTC, $ETH and $LSU (https://docs.rootfinance.xyz/root-points/rules) : 3 Root Points every 24 hours Verification Process To ensure fair distribution of points, Root Finance employs a verification process (https://docs.rootfinance.xyz/root-points/rules) : - Snapshots of users' positions are taken at random intervals throughout the 24-hour period. - Assets must remain in place during the day to ensure eligibility for the points earned. - If a user's balance changes or falls below the required threshold, their points for that day may be affected. Leaderboard Root Finance maintains a leaderboard (https://docs.rootfinance.xyz/root-points/rules) that displays the top wallets based on their Root Points. This feature adds a competitive element to the points system, potentially driving further engagement with the platform. Future Utility While the current documentation doesn't specify the future utility of Root Points, such point systems in DeFi protocols are often used for: - Governance participation - Access to exclusive features or products - Discounts on protocol fees - Potential token airdrops However, it's important to note that these are speculative uses and not confirmed features of the Root Points system. Risks and Challenges As with any decentralized finance (DeFi) protocol, Root Finance faces various risks and challenges. Understanding these is crucial for users, developers, and stakeholders involved with the platform. Smart Contract Risks Smart contract vulnerabilities pose significant risks to DeFi protocols. For Root Finance, several issues were identified in a security audit (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) : - Critical Vulnerability: A flaw in the flashloan mechanism was discovered that could allow unrestricted burning of TransientResData resources, potentially enabling users to avoid repaying flashloans. This issue was reported as fixed after the audit. - Access Control: The audit revealed a lack of a liquidator badge revocation mechanism (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) . This could potentially lead to security issues if a liquidator's rights need to be revoked. - Empty CDP Creation: The potential for creating empty Collateralized Debt Positions (CDPs) (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) was identified as a low-risk issue. - Decimal Precision: Inconsistent handling of decimal precision (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) in financial calculations was noted, which could lead to small discrepancies that may accumulate over time. While these issues were addressed or mitigated following the audit, the existence of such vulnerabilities highlights the ongoing challenge of maintaining secure smart contracts. Market Risks Market risks are inherent to any financial system, particularly in the volatile cryptocurrency market: - Price Volatility: Rapid price fluctuations in cryptocurrencies can lead to sudden changes in collateral values, potentially triggering liquidations (https://docs.rootfinance.xyz/liquidations) . - Liquidity Risk: In periods of high market stress, there might be insufficient liquidity for users to withdraw their assets or for liquidations to occur efficiently. - Interest Rate Fluctuations: The dynamic interest rate model (https://docs.rootfinance.xyz/tecnical-guide/interest-rate-model-of-root-finance) used by Root Finance, while designed to balance supply and demand, could lead to rapid changes in borrowing costs or lending yields. Operational Risks Several operational risks were identified or can be inferred from the provided documentation: - Centralized Price Feed: The audit report (https://web.archive.org/web/20260528021115/https://triwei.io/reports/root-finance-report.pdf) noted a centralized price feed as a medium-severity issue. This introduces a single point of failure risk, where inaccurate price data could potentially disrupt the entire system. - Radix DLT Dependence: As Root Finance is built on the Radix DLT (https://docs.rootfinance.xyz/) , it is exposed to any potential issues or limitations of this underlying blockchain platform. - Liquidation Mechanism: While designed to maintain system solvency, the liquidation process (https://docs.rootfinance.xyz/liquidations) could potentially lead to significant losses for users if not managed properly or if market conditions are extremely volatile. Regulatory Challenges While not explicitly mentioned in the provided documentation, DeFi protocols like Root Finance often face regulatory challenges: - Regulatory Uncertainty: The rapidly evolving nature of DeFi means that new regulations could potentially impact the operation of protocols like Root Finance. - Cross-border Transactions: As a decentralized platform, Root Finance may facilitate transactions across different jurisdictions, potentially raising complex legal and regulatory questions. - KYC/AML Compliance: The non-custodial and decentralized nature of the protocol may present challenges in complying with Know Your Customer (KYC) and Anti-Money Laundering (AML) regulations, which are increasingly being applied to cryptocurrency platforms. It's important to note that the specific regulatory challenges faced by Root Finance are not detailed in the provided documentation, and the actual impact of regulations may vary depending on the jurisdictions involved and the evolving regulatory landscape. ## bondefi URL: https://radix.wiki/ecosystem/bondefi Updated: 2026-09-02 Summary: BonDeFi is a decentralized crowdfunding platform and token launchpad built on Radix DLT , a distributed ledger technology designed for decentralized f… BonDeFi – Decentralized Crowdfunding Platform Type Decentralized crowdfunding platform and token launchpad Networks Listed on the project’s own homepage (https://bondefi.xyz/) (August 2026) as Ethereum, Binance, Polygon, Berachain and Radix DLT Pricing Model Batched bonding curve mechanism designed to reduce price volatility and bot exploitation Origin Scrypto Hackathon at the 10th European Blockchain Convention (https://eblockchainconvention.com/hackathon/) , Barcelona, Spain, 25–26 September 2024 Recognition One of five award-winning teams (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) at the Scrypto Hackathon Key Features Custom-priced pre-sales, guaranteed refunds if goals unmet, automatic DEX listing with locked liquidity, real-yield staking BonDeFi is a decentralized crowdfunding platform and token launchpad built on  Radix DLT (https://www.radixdlt.com/) , a distributed ledger technology designed for decentralized finance applications. The platform positions itself as providing " radically different decentralized crowdfunding (https://bondefi.xyz/) " and aims to offer an alternative fundraising mechanism that bypasses traditional venture capital involvement. Overview The platform's core functionality centres on improving the token launch process through several integrated mechanisms. According to coverage from the  European Blockchain Convention (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) , BonDeFi features a pre-sale phase with custom pricing using bonding curves, guaranteed pre-sale goals with full refunds if funding targets are not met, automatic decentralized exchange listing at the Token Generation Event with locked liquidity, and immediate token utility upon launch. Trading fees generated from locked liquidity are redistributed to participants through what the platform describes as a "real-yield" staking program. BonDeFi employs a  batched bonding curve model (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  as its primary pricing mechanism. Bonding curves are mathematical formulas that determine token prices based on supply, automatically adjusting prices as tokens are minted or sold. The platform's batched approach is designed to address common problems in token launches, including price volatility and exploitation by automated trading bots. By releasing tokens in batches rather than continuously, the system aims to provide guaranteed liquidity, reduce sudden price swings, and ensure fair access for all participants regardless of their technical capabilities or transaction speed. The platform provided project creators with a  dashboard interface (https://bondefi.xyz/)  for managing funding rounds, while offering investors tools to discover and participate in token pre-sales. BonDeFi describes its approach as creating "a transparent, efficient, and globally accessible funding ecosystem" that serves both builders seeking capital and investors looking for early-stage opportunities in the Radix ecosystem. History BonDeFi emerged as a project from the Scrypto Hackathon held during the  10th edition of the European Blockchain Convention (https://eblockchainconvention.com/hackathon/)  in Barcelona, Spain on 25–26 September 2024. The hackathon, sponsored by Radix DLT, brought together  over 150 developers (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  to build decentralized applications using Scrypto, Radix's Rust SDK for smart contracts. Many participants were writing Scrypto code for the first time during the event. BonDeFi was among  five teams that received awards (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  for their submissions at the conclusion of the hackathon. According to Radix DLT, four of the five winning teams, along with several other hackathon participants, opted to continue developing their projects with support from RDX Works, the primary contributor to the Radix protocol. The convention itself attracted over 6,000 attendees and featured participation from major financial institutions including Santander, ING Bank, Mastercard, Société Générale, and BNP Paribas. Following the hackathon, the BonDeFi team continued development of the platform. By March 2025, the project had published  technical documentation (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  detailing its batched bonding curve model and anti-sniping mechanisms, indicating ongoing work on the platform's core features beyond the initial hackathon prototype. Technology Bonding Curve Mechanism The platform employs bonding curves as its core pricing mechanism for token pre-sales. A bonding curve is a mathematical formula that establishes a  relationship between a token's price and its supply (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) , automatically adjusting prices as tokens are minted or sold. BonDeFi's documentation describes bonding curves as "revolutionizing DeFi by creating a  dynamic pricing mechanism (https://bondefi.xyz/)  for tokens" where "as more tokens are minted, the price changes along a predetermined curve, incentivizing early adoption and investment." Several mathematical models exist for bonding curves.  Linear bonding curves (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  increase price at a constant rate as supply grows, following the formula P = m⋅S+b, where P represents price, m is the slope, S is the current supply, and b is the initial price.  Exponential bonding curves (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  produce more rapid price appreciation, following the formula P = a⋅e^(b⋅S), where a represents the initial price multiplier and b controls the exponential growth rate. BonDeFi states that its platform allows builders to " incorporate different variables and conditions (https://bondefi.xyz/)  into the price model and create dynamic pricing based on factors like sale speed and demand." BonDeFi specifically implements what it calls a " batched bonding curve model (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) ," which releases tokens in discrete batches rather than continuously. The platform claims this approach offers several advantages including  reduced volatility (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  through the batched release of tokens,  guaranteed liquidity (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  ensuring investors can always buy or sell, and fair access giving all participants equal opportunity to acquire tokens. Anti-Sniping Innovation A significant technical feature of BonDeFi's design is its approach to preventing token sniping. In the context of decentralized exchanges and token launches, sniping refers to the practice of using automated trading bots to purchase tokens immediately upon listing, often within milliseconds of liquidity being added. These bots monitor blockchain mempools for pending liquidity transactions and execute buy orders faster than human traders can respond, allowing bot operators to acquire tokens at the lowest possible prices before selling at a profit once regular traders enter the market. BonDeFi addresses this problem through its batched bonding curve architecture. According to the project's documentation, the batching mechanism  makes sniping "impossible" (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  by eliminating the first-mover advantage that sniper bots exploit. Rather than allowing continuous purchasing where transaction speed determines who obtains the best prices, the batched system processes orders in groups, theoretically ensuring that  all participants have an equal opportunity (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  to acquire tokens at fair prices regardless of their technical capabilities or access to automated trading infrastructure. The platform positions this anti-sniping feature as a core differentiator, framing it as an " anti-sniping innovation (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) " that protects both project founders and retail investors from the extractive dynamics that can occur during token launches on other platforms. Features Pre-Sale Phase BonDeFi's pre-sale mechanism allows project creators to conduct token sales prior to public listing through its bonding curve pricing system. According to coverage from  Radix DLT (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) , the platform "features a pre-sale phase with custom pricing using bonding curves," enabling projects to establish their own pricing parameters rather than setting a fixed token price. The platform's website states that builders can " incorporate different variables and conditions (https://bondefi.xyz/)  into the price model and create dynamic pricing based on factors like sale speed and demand." A distinguishing aspect of BonDeFi's pre-sale design is its  guaranteed goal mechanism with refund protection (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) . If a project fails to reach its stated funding target, investors receive full refunds and the Token Generation Event does not proceed. This structure aims to protect investors from contributing to projects that fail to attract sufficient community support while ensuring that projects only launch when they have achieved a baseline level of capitalisation. For project creators, BonDeFi provides what it describes as " a single, intuitive dashboard (https://bondefi.xyz/)  to manage your funding rounds." The platform positions itself as enabling users to "start your global micro-funding round easier than ever" without requiring traditional venture capital involvement. For investors, the platform offers discovery tools to identify and evaluate pre-sale opportunities, with the stated goal of ensuring participants " never miss an investment opportunity (https://bondefi.xyz/) ." Token Generation Event The Token Generation Event represents the point at which a successfully funded project's tokens become publicly tradable. On BonDeFi, this process includes  automatic listing on a decentralized exchange (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  once the pre-sale funding goal has been met. This automated approach removes the need for project teams to manually coordinate exchange listings or negotiate with trading venues, theoretically reducing the time between successful fundraising and market availability. A key component of BonDeFi's TGE process is  locked liquidity (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) . When tokens are listed on the decentralized exchange, a portion of the raised funds is locked as liquidity to facilitate trading. Locking liquidity is a practice in decentralized finance intended to prevent project creators from withdrawing pooled funds immediately after listing, a practice sometimes referred to as a "rug pull." By automating this lock at the protocol level, BonDeFi aims to provide structural assurances to investors that trading liquidity will remain available. The platform also emphasizes  immediate token utility (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  at the point of generation. Rather than tokens existing solely as speculative instruments following their creation, BonDeFi's framework is designed to ensure that tokens can serve functional purposes within their respective project ecosystems from the moment they become available. Real-Yield Staking BonDeFi incorporates a staking programme tied to its locked liquidity mechanism. According to the Radix DLT blog, " trading fees from locked liquidity are redistributed (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  through a 'real-yield' staking program." This means that when users trade tokens on the decentralized exchange where a project has been listed, the transaction fees generated from that trading activity are not retained by the platform or discarded but instead distributed to participants who stake their tokens. The "real-yield" terminology distinguishes this model from staking programmes that distribute newly minted tokens as rewards. In many decentralized finance protocols, staking rewards come from token inflation–new tokens are created and given to stakers, which can dilute the value of existing holdings over time. By contrast, a real-yield model distributes value derived from actual economic activity, in this case trading fees, rather than from expanding the token supply. This approach aims to create sustainable returns tied to genuine platform usage rather than inflationary token emissions. The specific mechanics of BonDeFi's staking programme, including distribution schedules, eligibility requirements, and the proportion of fees allocated to stakers, are not detailed in the available documentation. Use Cases BonDeFi positions itself as a general-purpose decentralized crowdfunding platform designed to serve " a wide range of use cases (https://bondefi.xyz/) ." The platform states that " builders of the future can leverage these customizable curves (https://bondefi.xyz/)  to design innovative tokenomics and funding strategies" across different project types and industries. The primary use case articulated by the platform is enabling token launches for blockchain-based projects. The  Radix DLT blog (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  describes BonDeFi as "a launchpad designed to improve the token launch process," indicating its core function as infrastructure for projects seeking to issue and distribute tokens to investors and community members. BonDeFi explicitly frames itself as an alternative to traditional venture capital funding. The platform's messaging encourages users to " start your global micro-funding round easier than ever - no VCs (https://bondefi.xyz/) ," suggesting a target audience of project creators who wish to raise capital directly from a distributed investor base rather than through institutional funding rounds. This positioning aligns with broader trends in decentralized finance toward disintermediation of traditional financial gatekeepers. The platform's website displays example project categories to illustrate potential use cases, including decentralized finance projects focused on lending and borrowing, blockchain platforms for supply chain management, tokens providing liquidity solutions for decentralized exchanges, projects building decentralized social media platforms with privacy features, and marketplaces for digital art and NFTs. However, these appear as  illustrative examples (https://bondefi.xyz/) demonstrating the breadth of projects the platform could theoretically support rather than documentation of actual projects that have completed fundraising through BonDeFi. As a platform built on the Radix network, BonDeFi's use cases are inherently tied to the Radix ecosystem. Projects launching through BonDeFi would issue tokens compatible with Radix's infrastructure, meaning the platform serves as a mechanism for expanding the range of assets and applications available within the Radix DeFi ecosystem specifically, rather than as a blockchain-agnostic fundraising tool. The available documentation does not provide information about specific projects that have successfully completed fundraising campaigns through the platform, the total value raised through BonDeFi to date, or detailed case studies of how particular project types have utilised the platform's features. Tokenomics The available documentation provides limited information about BonDeFi's platform-level tokenomics. While the platform offers extensive tools for projects to design their own token economics, details about BonDeFi's own economic model remain largely undisclosed in public sources. Project-Level Token Design BonDeFi enables projects launching on the platform to create customised tokenomics through its bonding curve infrastructure. The platform states that " builders of the future can leverage these customizable curves (https://bondefi.xyz/)  to design innovative tokenomics and funding strategies for a wide range of use cases." Projects can " incorporate different variables and conditions (https://bondefi.xyz/)  into the price model and create dynamic pricing based on factors like sale speed and demand," allowing for tailored economic designs rather than requiring adherence to a standardised token structure. The platform emphasises " guaranteed liquidity (https://bondefi.xyz/) " as a core feature, marketing itself as enabling projects to " emit your token on a bonding curve (https://bondefi.xyz/)  and collect equity for your project in a fair, safe and transparent way" while enjoying "guaranteed liquidity" and avoiding "the bad reputation problem of ICOs." This guarantee is implemented through the bonding curve mechanism, which maintains a mathematical relationship between token price and supply, theoretically ensuring that tokens can always be bought or sold at prices determined by the curve. Liquidity Lock Mechanisms At the Token Generation Event, BonDeFi implements  automatic liquidity locking (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  as part of the decentralized exchange listing process. Locking liquidity prevents project creators from immediately withdrawing pooled funds after a token launches, a safeguard against exit scams. The specific parameters of these locks, including duration, percentage of funds locked, and conditions for release, are not detailed in the available documentation. Fee Distribution The platform operates a fee redistribution model in which  trading fees from locked liquidity (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  are channelled through a "real-yield" staking programme. This indicates that the platform generates revenue from trading activity on tokens launched through its infrastructure, with at least a portion of these fees being distributed to staking participants rather than being retained entirely by the platform. The specific fee percentages, the split between platform retention and staker distribution, and the mechanics of the staking programme are not specified in publicly available sources. Undisclosed Information The documentation does not provide information regarding whether BonDeFi operates its own native platform token, the fee structure charged to projects for using the launchpad, specific percentages or durations for liquidity locks, token supply parameters if a platform token exists, allocation or vesting schedules, or governance mechanisms. This lack of publicly documented tokenomics may reflect the project's early stage of development following its emergence from the September 2024 hackathon, or may indicate that such details are shared through other channels not captured in web-accessible sources. Comparison to Other Launchpads Centralized versus Decentralized Launchpads Token launchpads generally fall into two categories: centralized platforms operated by cryptocurrency exchanges, and decentralized platforms built on blockchain infrastructure. Centralized launchpads such as Binance Launchpad operate under regulated exchanges, offering project vetting, Know Your Customer procedures, and access to large existing user bases, but require projects to meet specific listing criteria and often involve significant fees or token allocations to the exchange. BonDeFi operates as a  decentralized crowdfunding platform (https://bondefi.xyz/) , positioning itself as enabling projects to " start your global micro-funding round easier than ever - no VCs (https://bondefi.xyz/) ," suggesting a model that bypasses both traditional venture capital and centralized exchange gatekeepers. The Radix Foundry Program, announced by Radix Publishing, identified launchpads as critical infrastructure for ecosystem growth, describing them as " a combination of dApp and organization (https://www.radixdlt.com/blog/introducing-radix-foundry-program)  that can help projects gain access to liquid capital, navigate the complex legal, compliance, and regulatory aspects of token launches, and support in marketing and distributing the token to thousands of new users." The programme cited  Seedify, DAOMaker, and Decubate (https://www.radixdlt.com/blog/introducing-radix-foundry-program)  as examples of launchpads that have achieved success on other networks, noting "there's an opportunity to be the prime launchpad in the Radix ecosystem." Comparison with Bonding Curve Platforms BonDeFi shares architectural similarities with other bonding curve-based launchpads that have emerged on various blockchain networks.  Pump.fun (https://www.solflare.com/ecosystem/pump-fun-where-memes-meet-markets-on-solana/) , a Solana-based platform launched in January 2024, utilizes a bonding curve mechanism where 800 million of each token's 1 billion supply is placed on the curve, with prices increasing as buyers purchase tokens. When tokens reach a market capitalization threshold, they automatically migrate to a decentralized exchange for continued trading. Both BonDeFi and Pump.fun employ bonding curves to provide guaranteed liquidity and automatic price discovery. However, BonDeFi's documentation emphasises its  batched bonding curve model (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) , which processes orders in discrete batches rather than continuously. The platform positions this batching mechanism as an  anti-sniping innovation (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc)  that prevents automated trading bots from exploiting first-mover advantages, a problem that continuous bonding curve platforms can be susceptible to. Another distinguishing feature is BonDeFi's  guaranteed pre-sale goals with refund protection (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) . If a project fails to reach its stated funding target, the Token Generation Event does not proceed and investors receive refunds. This contrasts with platforms where tokens begin trading immediately upon creation regardless of whether meaningful community support has been established. Position within the Radix Ecosystem BonDeFi was built for the Radix network and its mechanism is described throughout its documentation in Radix terms. Its own homepage no longer presents it that way: as of August 2026 it lists Ethereum, Binance, Polygon, Berachain and Radix DLT (https://bondefi.xyz/) as the networks it covers, which places it alongside multi-chain launchpads such as PinkSale and DxSale (https://slashdot.org/software/p/PinkSale/alternatives) rather than apart from them. No launch on any of those networks is claimed on the site, whose “Projects Launched” figure reads “-”. The  Radix Ecosystem Directory (https://www.radixdlt.com/ecosystem-directory)  lists multiple projects offering related functionality, including platforms for token creation with bonding curves and services providing token locking and vesting capabilities. Within this ecosystem, BonDeFi competes for the launchpad category that Radix has identified as strategically important for network growth. The platform's integration with Radix's technical infrastructure means projects launching through BonDeFi benefit from features specific to the Radix network, including  Scrypto's asset-oriented programming model (https://github.com/radixdlt/radixdlt-scrypto)  and the Radix Engine's approach to treating tokens as native platform resources rather than smart contract entries. However, this also means tokens launched through BonDeFi are limited to the Radix ecosystem unless separately bridged to other networks. Documented Differentiators Based on available documentation, BonDeFi emphasises several features as distinguishing it from other launchpad platforms. These include the batched bonding curve architecture designed to prevent sniping, guaranteed funding thresholds with automatic refunds, automatic decentralized exchange listing with  locked liquidity (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  at the Token Generation Event, and  real-yield staking (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights)  that distributes trading fees rather than inflationary token rewards. The platform also enables projects to design  customisable tokenomics (https://bondefi.xyz/)  with dynamic pricing variables, though the extent to which this differs from competitor offerings would require direct technical comparison not available in public documentation. Status and Chain Coverage (August 2026) As of 15 August 2026 the project’s site at bondefi.xyz (https://bondefi.xyz/) serves a single marketing landing page rather than the launchpad application described in the sections above. Every path other than the root returns the web framework’s standard 404 page, and the two API hosts the site’s own client bundle calls, api.bondefi.xyz and api.bondefi.dev, both return HTTP 502. The only working calls to action on the page are a Telegram link (https://t.me/bondefi) and a Google Form headed “Apply as a Project”. The same page states the project’s chain coverage, and it is no longer Radix-only. Under the heading “Blockchains” it lists Ethereum, Binance, Polygon, Berachain and Radix DLT (https://bondefi.xyz/) , in that order. The two figures beside it read “Projects Launched: -” and “Total Users: 964”. The user figure is not a stored metric: the page’s client-side JavaScript computes it as 66 plus two for every day elapsed since 23 May 2025, so it advances by two each day irrespective of activity. No launch on any of those networks is claimed by the project itself, no application is reachable, and Radix is listed last of the five networks, so the platform is recorded here as dormant on Radix. The description of its mechanism in the sections above reflects the material published between the September 2024 hackathon (https://www.radixdlt.com/blog/european-blockchain-convention-event-highlights) and the March 2025 bonding-curve write-up (https://medium.com/@bondefi/bonding-curves-anti-snipe-1cf47220d3bc) , and has not been superseded by later documentation. See also - Caper (/ecosystem/caper) – DAO formation where a group raises its treasury on a bonding curve ## Neutral Point of View URL: https://radix.wiki/policy/neutral-point-of-view Updated: 2026-09-02 Summary: Neutral point of view (NPOV) means representing a subject fairly, proportionately, and without editorial bias. [1] Facts are stated as facts; opinions… Policy Neutral point of view (NPOV) Type Content policy (core) Related Conflict of interest (/policy/conflict-of-interest) Applies to Every article; most often Ecosystem (/ecosystem) project pages Enforcement Written like an advertisement notice banner; attribution Adopted 31 July 2026 Neutral point of view (NPOV) means representing a subject fairly, proportionately, and without editorial bias. [1] (#ref-1) Facts are stated as facts; opinions are attributed to whoever holds them. Ecosystem and project pages NPOV matters most where a page describes a project whose own team may be editing it – a structural conflict of interest, covered in full by conflict of interest (/policy/conflict-of-interest) . Such pages must avoid promotional language ("revolutionary", "the best"), attribute claims about traction or performance to sources, and carry a Written like an advertisement notice banner when they drift into marketing. Neutrality also applies to what a page leaves out. A project page that records only launches and grants, and never a dormant product or a closed one, is not neutral – the status field and the prose should agree, and both should follow the evidence. Status is a measurement Every Ecosystem (/ecosystem) page carries a status field, and it is where neutrality is easiest to lose. A directory that records launches and grants but never a dormant product or a closed one describes an ecosystem in which nothing ever stops – an omission rather than a falsehood, and still not neutral. A status is therefore set from dated evidence a reader can repeat, and the prose is expected to agree with it. Radix Rolodex (/ecosystem/radix-rolodex) was moved from active to dormant on three readings rather than on a view about the project: its newest published card and deck are both dated 14 February 2026, its deployed bundle was last built on 10 February 2026, and the service is still up with every embed on this wiki still rendering. Nothing about it is broken. It has stopped changing, and the page says only that. The same discipline stops the field travelling too far the other way. Hermes Protocol (/ecosystem/hermes-protocol) reads dormant on four dated checks, and the page states in the same breath that no wind-down was ever announced – closed would be a stronger claim than the evidence carries. Where the evidence is thin, the neutral move is to name the check and its date, not to round the status to whichever end of the scale reads more decisively. Where a page has drifted into its subject’s own framing, add the Written like an advertisement banner rather than quietly rewriting it, and say in the revision message what was promotional about it – the banner is a request for review addressed to the next editor, and the revision history is public. When accounts conflict Status fields go wrong slowly. Contested events go wrong fast, and they are where neutrality is hardest to hold, because the pressure is not to flatter a subject but to settle a question the sources have not settled. The rule is the same one in a harder case: state as fact only what a reader can check for themselves, attribute everything else to whoever said it, and do not resolve a disagreement on the page that is unresolved off it. Three practices follow from that, and the August 2026 asset drain and network halt (/contents/history/hyperlane-asset-drain-2026) is the worked example for each, because it is being written here while it is still happening. Officialness is not evidence. A statement from the organisation closest to an event is a source, not an adjudication, and it carries no more weight than a source a reader can verify. On 2 September 2026 the Radix Foundation's own channel said that it and the Accountability Council (https://t.me/RadixAnnouncements/2778) have halted the Radix network. Three hours earlier, in a different channel, Astrolescent's Timan wrote (https://t.me/radix_dlt/1001292) that the node runners made that decision to protect the network. That was not a centralized decision. The ledger agrees with the second: rounds stopped when stake fell below the threshold, which is a thing node runners do individually and no organisation can do to them. The page records both statements, dated and attributed, and says which one the ledger supports. It does not delete the first for being wrong, and it does not adopt it for being official. Carry the hedge. Where a source qualifies a claim, the qualification travels with it. The first public technical accounts of that incident's root cause came from a protocol developer who twice asked to be taken with a pinch of salt and expected a more accurate write-up later. Repeating such a claim without its hedge converts a working hypothesis into a finding, which is a failure of neutrality as much as of accuracy, and it is a failure this wiki commits on the source's behalf rather than the source's own. Separate what is checkable from what is asserted. The same page states the mechanism of the flaw flatly, because it is read from published source at a named version and any reader can open the file; it attributes the accounts of that mechanism given in chat, because those rest on the standing of the people who gave them. Both belong on the page. Only the first is stated as fact. Where an event has no checkable layer at all, every account of it is attributed, and the page says plainly that nothing independent settles it. Neutrality here is not even-handedness for its own sake. Two accounts of an event are rarely equally supported, and saying so is part of the job; what is not part of the job is choosing between them on the strength of who is speaking, or quietly leaving out the version that is inconvenient for either party. See also verifiability (/policy/verifiability) , which governs what counts as checkable, and no original research (/policy/no-original-research) , which governs how far a page may reason from primary sources on its own. See also - Verifiability (/policy/verifiability) - No original research (/policy/no-original-research) - Notability (/policy/notability) - Freshness (/policy/freshness) - Conflict of interest (/policy/conflict-of-interest) - Editorial notices (/policy/editorial-notices) References: 1. Wikipedia – Wikipedia:Neutral point of view (https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view) ## Farbocoin URL: https://radix.wiki/ecosystem/farbocoin Updated: 2026-09-02 Summary: Farbocoin ($FARBO) was a cryptocurrency developed on the Radix Network. It aimed to offer a unique approach to crypto by prioritizing user-friendlines… Farbocoin ($FARBO) was a cryptocurrency developed on the Radix Network. It aimed to offer a unique approach to crypto by prioritizing user-friendliness and entertainment. The project video this page linked, youtu.be/-7CzzNjvA2o, was set to private by its owner and cannot be watched; checked 2 September 2026. Overview The project revolved around Farbo games, where users could participate and earn $FARBO tokens. The Farbo World game had already reached a significant milestone of over 10,000 downloads and had a growing fanbase.Farbocoin also planned to offer social media airdrops, tournaments, and betting on matches as additional ways to earn tokens. By focusing on fun and engagement, Farbocoin aimed to create a vibrant ecosystem where users could earn and utilize $FARBO tokens. The project recently announced a presale in collaboration with a trustee to ensure transparent handling of the token sale. Tokenomics Farbocoin was a decentralized digital currency designed to facilitate instant and secure transactions. Farbocoin's tokenomics included the following initial distribution plan: - Airdrops and Rewards: 50% (50,000,000 $FARBO) - Presale: 25% (25,000,000 $FARBO) - Team / Marketing / Development: 20% (20,000,000 $FARBO) - Advisers: 5% (5,000,000 FARBO) Farbocoin had a maximum supply of 100,000,000 $FARBO. The team aimed to develop a self-sustaining ecosystem where Farbocoin could be used as a means of payment for goods and services within the platform. It is crucial to keep in mind that tokenomics is a complex subject, and a token's value is determined by various factors such as demand and supply, adoption rate, network activity, and token utility. Product Farbocoin was a cryptocurrency that focused on bringing fun and user-friendliness to the world of crypto.It offered an engaging experience through participation in Farbo games and tournaments, allowing users to earn $FARBO. The project aimed to create an accessible platform for people to get involved in the crypto space, especially for those who may find other platforms intimidating or complex. One of the notable games associated with Farbocoin was Farbo World, which had surpassed the milestone of 10,000 downloads and had a growing fanbase. Farbo World was a colorful puzzle adventure game with a multiplayer mode that added a twist. In addition to playing games, users could also earn $FARBO through social media airdrops, participating in tournaments, and even betting on matches. The project aimed to create a vibrant ecosystem where users could engage with Farbocoin in various entertaining ways. Farbocoin was built on the Radix Network, which provides a highly scalable and secure platform for blockchain-based applications. The Radix platform supports smart contracts and features such as atomic swaps for precise execution of transactions Platform Farbocoin was built on the Radix Distributed Ledger, which is designed to offer a highly scalable, secure, and decentralized platform for building blockchain-based applications. Unlike traditional blockchain platforms like Bitcoin and Ethereum, which rely on a blockchain's linear structure, Radix uses a unique data structure called a "temporal graph" to enable parallel processing and near-instant transaction finality. The Radix platform also supports smart contract development, allowing developers to create and deploy complex decentralized applications (dApps). Additionally, it offers several features to address security concerns, such as atomic swaps to ensure precise execution of transactions. Farbocoin leveraged the Radix platform's features to provide a user-friendly cryptocurrency experience, centered around in-game activities that offered users a fun, engaging way to earn FARBO tokens. Security and Trust Regarding the security and trust of Farbocoin, it is important to note that the trust and security of any cryptocurrency project depend on various factors such as the underlying blockchain technology, network consensus mechanisms, and community engagement. Farbocoin was built on the Radix Network, which is designed to provide high scalability and security for blockchain-based applications.The Radix platform uses advanced technologies to ensure the integrity and security of transactions, including elements such as Merkle trees, distributed consensus algorithms, and cryptographic encryption. These features contribute to the overall security of Farbocoin transactions and the trustworthiness of the platform. Furthermore, being developed on the trusted Radix network provides a level of assurance in terms of reliability and stability. The Radix platform has a reputation for its focus on security and has undergone rigorous testing and auditing processes to ensure the robustness of its technology. To further enhance security, it is always recommended for users of Farbocoin or any cryptocurrency to follow best practices in securing their own wallets, such as using strong passwords, enabling two-factor authentication, and keeping their private keys offline and secure. It's worth mentioning that the trust and security of any digital asset can also be influenced by how well the project is governed and the transparency of its operations. As such, it is important for users to research and evaluate the Farbocoin project and its team to assess their commitment to security and trust. The Token After the Project farbo.me is gone at the root of DNS: the name returns NXDOMAIN, meaning the registration itself has lapsed rather than the site merely being unplugged. $FARBO is still on the Radix ledger, and it settles what the tokenomics above only proposed. Farbocoin (https://dashboard.radixdlt.com/resource/resource_rdx1thlrdezdr9hth2u8lghaykampztpmpemam84w76ah7u9nva9lnc4q4) ($FARBO), read at the Radix Gateway (https://radix-babylon-gateway-api.redoc.ly/) on 21 August 2026, at epoch 336,894: supply 100,000,000 $FARBO, all minted and none burned — exactly the maximum supply the distribution plan set out — and its minter, burner, freezer and recaller are each set to DenyAll, and so are all four of their updaters — nobody, including the account that issued the token, can mint, destroy, freeze or recall a single unit of it. The distribution itself did not happen. 357 accounts hold $FARBO, and a single one of them holds 82,416,955.18, or 82.4% of the entire supply. The second-largest balance is 7,133,681.23 (7.1%); below those, holdings drop to 1,666,667 and smaller. The plan allocated 50% of the supply to airdrops and rewards and a further 25% to a presale, which together would have put three-quarters of $FARBO into circulation. Four-fifths of it is in one wallet. Sources radixecosystem.com – Farbocoin (archived) (https://web.archive.org/web/20240716154007/https://radixecosystem.com/projects/farbocoin) https://www.reddit.com/user/Farbo_Official/comments/x6s36a/farbocoin_the_journey_begins/ (https://www.reddit.com/user/Farbo_Official/comments/x6s36a/farbocoin_the_journey_begins/) Farbo brochure (archived) (https://web.archive.org/web/20231209051816/https://farbo.me/Farbo_brochure.pdf) farbo.me (archived) (https://web.archive.org/web/20231209050021/http://farbo.me/) ## Ice URL: https://radix.wiki/ecosystem/ice Updated: 2026-09-02 Summary: Ice is an experimental non-fungible token (NFT) project implemented on the Radix blockchain using RRC-404 - an implementation of the ERC-404 standard… Ice Type Experimental NFT project using RRC-404 (/contents/tech/core-protocols/rrc-404) (an ERC-404-style hybrid token) on Radix Status 🟢 Active – site live at ice404.com, component live on mainnet, last used 7 August 2026 Founded 2024 Component Ice RRC-404 (https://dashboard.radixdlt.com/component/component_rdx1czscv9f2mv034hewjplej5ef4f2ecug2fxxelfpgxrsrhw4mglq2yp) – holds the freeze and melt methods and collects the royalty Token pair $ICE ("Water") (https://dashboard.radixdlt.com/resource/resource_rdx1t4h4396mukhpzdrr5sfvegjsxl8q7a34q2vkt4quxcxahna8fucuz4) , fungible, and Ice (https://dashboard.radixdlt.com/resource/resource_rdx1n2y299ekzx4au2v9yjmxzu650ulvk5ndx3u5tlevfclk0uvdgs30px) , non-fungible Supply 733 fungible + 267 non-fungible = 1,000, the cap held as an invariant rather than approached (epoch 339,054, 28 August 2026) Mechanic "Freeze" / "melt" to convert between fungible and NFT state; 1 XRD royalty per call Ice is an experimental non-fungible token (NFT) project implemented on the Radix blockchain using RRC-404 (/contents/tech/core-protocols/rrc-404) - an implementation of the ERC-404 standard built with Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , Radix's asset-oriented smart contract programming language. The demo video this page linked, youtu.be/T55DUn6QLgQ, was set to private by its owner and cannot be watched; checked 2 September 2026. Overview The key innovation of ICE is allowing tokens to transition between fungible and non-fungible states through "freeze" and "melt" operations. This enables combining the benefits of NFTs (unique digital artifacts) and fungible tokens (enabling fractional ownership and trading). The maximum combined supply of ICE across fungible and non-fungible tokens is capped at 1000. The proportions of different NFT rarities are dynamically maintained based on the current circulating supply of NFTs when new ones are minted or melted back into fungibles. Features - Maximum 1000 total tokens (NFTs + fungibles) - Convert between fungible and NFT via "freeze" and "melt" operations - Constant percentage of each NFT rarity maintained - 1 XRD royalty charged per freeze/melt operation Benefits - NFTs can provide liquidity to DEXs like Ociswap (/ecosystem/ociswap) via their linked fungible tokens - DEX liquidity increases overall market liquidity and price discovery - Fractional ownership enabled by holding fungible token amounts - Incentivizes NFT creators via royalty stream The ICE project demonstrates new possibilities opened up by Radix's unique asset-oriented programming model, aiming to enhance NFT liquidity, ownership models, and monetization for creators. On-Ledger State and Usage The 1,000-unit cap is not a ceiling the project has been minting towards. It is an invariant the component holds at every moment: a freeze burns fungible units and mints the same number of NFTs, a melt does the reverse, and the two sides always sum to the cap. Read live through the Radix Gateway (https://mainnet.radixdlt.com) at epoch 339,054 (28 August 2026, 23:07 UTC), the fungible $ICE ("Water") (https://dashboard.radixdlt.com/resource/resource_rdx1t4h4396mukhpzdrr5sfvegjsxl8q7a34q2vkt4quxcxahna8fucuz4) resource carried a total supply of 733 and the paired non-fungible Ice (https://dashboard.radixdlt.com/resource/resource_rdx1n2y299ekzx4au2v9yjmxzu650ulvk5ndx3u5tlevfclk0uvdgs30px) resource 267 – exactly 1,000 between them. An earlier reading of roughly 723 on this page measured only the fungible side, which is a share of the supply rather than the amount minted. Both resources are driven by one component, Ice RRC-404 (https://dashboard.radixdlt.com/component/component_rdx1czscv9f2mv034hewjplej5ef4f2ecug2fxxelfpgxrsrhw4mglq2yp) , whose on-ledger description reads "Easily convert RRC-404 tokens between fungible and nonfungible using the freeze and melt methods." The royalty is charged per call, not per unit. The most recent transaction to touch the pair, on 7 August 2026 (https://dashboard.radixdlt.com/transaction/txid_rdx15uv25zz4j8ak5487nye34q9zssrzmvpsaqhz8c4hlrq3d88lxs9qk5u9zt) , melted ten NFTs (#2935# through #2944#) into ten fungible ICE in a single melt call, and the Gateway receipt records a xrd_total_royalty_cost of exactly 1 XRD routed to the component, against 0.771 XRD of network execution, finalization and storage cost. That transaction is also what moved the split from the 723/277 this page previously recorded to today's 733/267. Use of the mechanic is sparse. The newest 100 transactions in the Gateway stream touching the component reach back to 26 July 2024, and only three of them fall in 2026: two on 1 March and the 7 August melt above. Activity concentrated in the two months after launch – 58 of those 100 transactions land in July and August 2024 – with a second cluster of 16 across June and July 2025. The site and the component both answer, so the mechanic is intact; what has thinned is the use of it. ## XRDegen URL: https://radix.wiki/ecosystem/xrdegen Updated: 2026-09-02 Summary: XRDegen is an NFT launchpad and marketplace built on Radix. The platform provides a comprehensive suite of tools for creators to launch, manage, and m… XRDegen is an  NFT launchpad and marketplace (https://xrdegen.gitbook.io/xrdegen)  built on Radix. The platform provides a comprehensive suite of tools for creators to launch, manage, and monetize their non-fungible token (NFT) collections while offering traders a secure environment for buying and selling digital assets. Developed in the United States, XRDegen offers a user-focused approach to NFT trading with features designed to benefit both creators and collectors. The platform's core infrastructure includes an NFT marketplace, Web3 portfolio tools, and a launchpad for new collections. The platform distinguishes itself through several key features, including a  randomized minting process (https://xrdegen.gitbook.io/xrdegen/artwork-reveal)  that ensures fairness during initial drops, a  creator-friendly royalty system (https://xrdegen.gitbook.io/xrdegen/royalties-for-creators)  that provides ongoing revenue from secondary sales, and a  transparent fee structure (https://xrdegen.gitbook.io/xrdegen/marketplace-fees)  with competitive rates compared to other major NFT marketplaces. XRDegen aims to serve as a central hub for Radix-based NFT activity, enabling creators to easily launch new collections through CSV file uploads and allowing collectors to discover, mint, and trade NFTs through an intuitive interface. The platform also supports  claiming pre-existing collections (https://xrdegen.gitbook.io/xrdegen/claiming-pre-existing-collections)  that were launched before XRDegen's creation, allowing those creators to benefit from the platform's features and royalty system. Platform Features XRDegen provides a comprehensive ecosystem for NFT creation and trading on the Radix blockchain, with three core components: the marketplace, launchpad, and creator dashboard. NFT Marketplace The XRDegen marketplace enables users to mint, buy, sell, and make offers on NFTs from any collection on the Radix blockchain. The platform maintains competitive pricing with a  2% fee on every trade (https://xrdegen.gitbook.io/xrdegen/marketplace-fees) , which is comparable to Magic Eden (2%) and lower than OpenSea (2.5%). This marketplace serves as the central trading hub where collectors can discover NFTs and creators can benefit from ongoing royalties from secondary sales. Launchpad The  XRDegen launchpad (https://xrdegen.gitbook.io/xrdegen/launch-your-collection/why-launch-with-xrdegen)  provides creators with tools to launch and manage NFT collections. Key features include: The launchpad facilitates  collection creation through CSV file uploads (https://xrdegen.gitbook.io/xrdegen/launch-your-collection/launch-your-collection/format-your-csv-file) , allowing creators to efficiently organize asset data including names, descriptions, image URLs, and metadata traits. Once launched, collections appear in the DROPS section for easy discovery by potential buyers. To ensure fairness during minting, XRDegen employs a  unique artwork reveal system (https://xrdegen.gitbook.io/xrdegen/artwork-reveal)  that only displays the NFT's metadata and artwork after a transaction is submitted. This prevents users from canceling transactions until they find a rare NFT, maintaining the element of surprise that is essential to fair NFT distribution. The platform charges an  initial collection setup fee of 2000 XRD and minting fees of 10% of the mint price (https://xrdegen.gitbook.io/xrdegen/launchpad-fees)  (or 25 XRD, whichever is greater) per NFT minted. For collections priced below 25 XRD, creators must pay minting costs upfront but retain 100% of funds raised from sales. Creator Dashboard The  Creator Dashboard (https://xrdegen.gitbook.io/xrdegen/launch-your-collection/the-dashboard)  serves as the control center for managing NFT collections. Through this interface, creators can: - Submit new collections with comprehensive details including visuals, descriptions, categories, and features - Edit existing collections to keep information current - Access analytics data on collection performance, including views, interactions, and transaction volumes - Manage their creator profile and connect social media accounts Each collection receives a  dedicated landing page (https://xrdegen.gitbook.io/xrdegen/your-collection-landing-page)  with a custom URI (XRDEGEN.com/collections/[custom-name]) that displays collection details, social links, and performance metrics such as floor price and all-time volume. Notably, XRDegen also supports  claiming pre-existing collections (https://xrdegen.gitbook.io/xrdegen/claiming-pre-existing-collections)  launched before the platform existed. Creators can verify ownership by connecting a wallet containing the project's Owner's Badge, then customize their collection's presence on XRDegen and begin earning royalties from secondary sales. Technical Details Minting Process The  minting process on XRDegen (https://xrdegen.gitbook.io/xrdegen/the-minting-process)  is designed to be straightforward for both creators and collectors. When a collection is launched, it appears in the DROPS section of the platform, making it discoverable to potential buyers. Users can mint directly from a collection's landing page by accessing the custom URI (XRDEGEN.com/collections/[custom-name]) or by searching for the policy ID. The platform supports efficient batch minting, allowing users to purchase up to 25 assets in a single transaction. Once a transaction is signed, NFTs are instantly minted on the Radix blockchain and transferred to the buyer's wallet. Artwork Reveal System XRDegen has implemented a  specialized artwork reveal system (https://xrdegen.gitbook.io/xrdegen/artwork-reveal)  to address a unique challenge with Radix's Transaction Manifest. While the Transaction Manifest provides transparency by letting users see exactly what they're getting in a transaction, this creates an issue for NFT minting where users might cancel and resubmit transactions until they secure the rarest piece in a collection. To maintain fairness, XRDegen only reveals artwork and metadata after a transaction is submitted. The reveal process completes within minutes of minting, ensuring that the minting experience remains unpredictable and equitable for all participants. CSV File Format Collections are launched through a  CSV (Comma-Separated Values) file (https://xrdegen.gitbook.io/xrdegen/launch-your-collection/launch-your-collection/format-your-csv-file)  that contains all necessary data for the NFTs. Creators can use spreadsheet applications like Google Sheets or Excel to prepare their data, with column headers exactly matching XRDegen's required format. The CSV must include essential information such as Asset Name, Description, and Image URL. Creators can add custom traits by creating additional columns with the prefix "metadata." (e.g., "metadata.background"). Capitalization is critical in the headers, and spaces should be avoided to prevent errors during the upload process. Royalty Implementation The  royalty system (https://xrdegen.gitbook.io/xrdegen/royalties-for-creators)  enables creators to earn ongoing revenue from secondary sales of their NFTs. When setting up a collection, creators specify their desired royalty percentage (up to a maximum of 10%) and designate a wallet address to receive payments. For example, with a 5% royalty rate set on a collection, if an NFT sells for 1000 XRD on the marketplace, the creator automatically receives 50 XRD from that transaction. Notably, XRDegen allows all Radix NFT creators to set up royalties for their collections, regardless of whether they originally launched through the platform or independently. The royalty percentage can be adjusted over time through the Creator Dashboard, providing flexibility as market conditions change or as collections mature. Website (30 July 2026): xrdegen.com has no DNS record at all. An unregistered domain can be bought by anyone – four defunct Radix projects' domains have already been re-registered as unrelated landing pages – so the link has been removed from this page's facts table. Video (2 September 2026): the platform walkthrough this page linked, youtu.be/FhSy_RZdyyY, has been removed from YouTube and answers “Video unavailable”. The link has been dropped. The project's GitBook documentation (https://xrdegen.gitbook.io/xrdegen) , which every citation above rests on, is still served. See also - Caper (/ecosystem/caper) – bonding-curve fundraising for DAO formation ## Instabridge URL: https://radix.wiki/ecosystem/instabridge Updated: 2026-09-02 Summary: Instabridge was a regulated cross-chain bridge service for moving digital assets between the Ethereum and Radix networks. It launched as a one-way bri… Instabridge was a regulated cross-chain bridge service for moving digital assets between the Ethereum and Radix networks. It launched as a one-way bridge for converting eXRD to XRD and grew into a two-way wrapping service covering a range of cryptocurrencies. The service is no longer operational; the description below is historical. https://youtu.be/srRWQP4aDXw (https://youtu.be/srRWQP4aDXw) Status (2026-09-02): the bridge is closed, and its infrastructure has now come apart host by host. instabridge.io and www.instabridge.io resolve to Cloudflare addresses and answer every request with a 301 to an unrelated online-gambling landing page, whose destination rotates – www.homesofjoy.org on 30 July 2026, rescuedandco.com on 1 August, the777.co on 2 September – which is characteristic of a parked domain being monetised rather than a one-off misconfiguration. The registry record (https://rdap.identitydigital.services/rdap/domain/instabridge.io) dates the domain to 21 May 2021, a transfer to 25 March 2025 and its most recent change to 11 August 2026, with an expiry of 21 May 2027. Three of the operator's own hosts – app.instabridge.io, assets.instabridge.io and learn.instabridge.io – now have no DNS record at all. instalabs.io is a narrower case than this page previously recorded: it still resolves, to two AWS Global Accelerator addresses, and its HTTPS listener refuses the connection, so it resolves without serving. The wiki's outbound links point at a July 2026 archived snapshot (https://web.archive.org/web/20260706005255/https://www.instabridge.io/) ; do not follow the live domain. The eXRD-to-XRD wrapping the bridge was built for concluded with the Radix Babylon migration; the service was developed by Instalabs (https://medium.com/instalabs-io) (Metapass (Radix) Ltd). One consequence outlives the service. The x-assets Instabridge minted are still listed by Radix trading venues, and those listings still fetch their token icons from the CDN that has gone: read on 2 September 2026, Astrolescent's price feed (https://api.astrolescent.com/prices) carries twenty-three entries – xUSDC, xUSDT, xwBTC, xETH, xDAI, xADA, xPEPE, xXRP, xBNB, xSHIB, xLINK, xMKR, xWLD, xUNI, xGRT, xIMX, xENA, xCRO, xETC, xAAVE, xPOL, xXLM and xTRX – whose iconUrl is on assets.instabridge.io, and Ociswap's token list (https://api.ociswap.com/tokens) does the same for xLINK. A dead bridge leaves its wrapped assets on the ledger; a dead CDN leaves them without a picture. These x-assets are a separate set from the Hyperlane-bridged h-assets: the asset table of the 31 August 2026 drain (/contents/history/hyperlane-asset-drain-2026) names hUSDC, hUSDT, hETH, hWBTC, hSOL and hBNB only. Overview Instabridge operated as a Virtual Asset Service Provider (VASP) and required users to complete Know Your Customer (KYC) verification through its integrated Instapass identity verification system. This regulatory compliance framework enables Instabridge to facilitate secure and compliant cross-chain transactions while maintaining user privacy and security standards. Instabridge's core functionality includes the ability to wrap various ERC-20 tokens from the Ethereum network into their equivalent "x-assets" on the Radix network at a 1:1 ratio, minus applicable fees. The platform integrates with popular wallet services, requiring the Metamask browser extension for Ethereum transactions and the Radix Wallet for Radix network operations. As of December 2024, Instabridge has processed over $100,000 in bridged assets (https://medium.com/instalabs-io/first-100k-of-xassets-bridged-onto-radix-01dc9fba13ca) including wrapped versions of major cryptocurrencies such as Bitcoin (xBTC), Ripple (xXRP), and Cardano (xADA). The platform employs a transaction status tracking system that provides users with real-time updates on their cross-chain transfers, including statuses such as "In Flight," "Completed," "Refunded," and "Failed." Recent platform upgrades have significantly improved (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) transaction processing speeds and reduced fees, with transactions into the Radix network becoming free of charge and outbound transactions incurring a fee of 15 basis points, capped at $500. The service has also expanded its token support to include 20 additional cryptocurrencies, with plans to introduce retail functionality for these new assets in phases during Q1 2025. History Instabridge was developed by Metapass (Radix) Ltd. as a solution for bridging assets between the Ethereum and Radix blockchain networks. The service was initially launched as a one-way bridge specifically designed to enable users to convert eXRD tokens to XRD at a 1:1 ratio. Following its initial release, the platform expanded its capabilities to become a two-way wrapping service, allowing users to bridge various digital assets between the two networks. This evolution included support for major cryptocurrencies such as ETH, wBTC, USDT, and USDC, with all conversions maintaining a 1:1 ratio minus applicable fees. In December 2024, Instabridge underwent significant upgrades (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) that transformed its operational capabilities. These improvements included a 5x increase in transaction processing speed and a substantial reduction in delayed transactions. The platform also implemented a new fee structure, eliminating charges for transactions into the Radix network and reducing fees for outbound transactions to 15 basis points. The platform achieved a notable milestone (https://medium.com/instalabs-io/first-100k-of-xassets-bridged-onto-radix-01dc9fba13ca) in December 2024 when it surpassed $100,000 in bridged assets for various x-assets on the Radix network, including wrapped versions of Bitcoin, Ripple, Cardano, Bitcoin Cash, Stellar, and Ethereum. This achievement marked significant progress in establishing liquidity for these assets on the Radix network. The expansion continued with the announcement of support for 20 additional tokens, including popular assets such as BNB, XRP, ADA, TRX, AVAX, XLM, and AAVE. These new additions were initially made available exclusively to business users, with plans for phased retail access implementation during Q1 2025, coinciding with the anticipated launch of the Anthic (/ecosystem/anthic) ecosystem. Features Instabridge's primary feature is its token wrapping and unwrapping capability, which enables users to convert between ERC-20 tokens and their Radix network equivalents. The platform designates wrapped assets on the Radix network with an "x" prefix, maintaining a 1:1 conversion ratio for all supported tokens. The platform integrates with multiple wallet systems, requiring users to have both the Radix Wallet app and the Metamask browser extension for full functionality. Users can manage multiple wallet addresses through their Instapass account, with the ability to set default addresses for both networks. Transaction monitoring is facilitated through a comprehensive status system that tracks transfers through various states: - "In Flight" status indicates active processing. - "Completed" confirms successful transaction completion. - "Refunded" signifies returned funds due to transaction issues. - "Failed" status indicates unsuccessful transactions with funds in holding. The platform implements strict security measures through its mandatory KYC verification system via Instapass, which requires users to complete identity verification before accessing bridging services. This system includes AML (Anti-Money Laundering) tiers that determine transaction limits, with users able to apply for tier upgrades to increase their trading capacity. As of December 2024, the service has enhanced its performance metrics (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) with a fivefold increase in transaction speed and significant reductions in processing delays. The platform maintains support for a growing list of digital assets, including major cryptocurrencies and stablecoins, with regular additions to its supported token list. Technical Architecture Instabridge's technical infrastructure is built around secure wallet integrations and automated transaction processing systems. The platform requires the Metamask browser extension for Ethereum-based operations, using it to facilitate secure login authentication and transaction signing. For Radix network interactions, users must install the Radix Wallet Connector browser extension and mobile app. The platform implements a QR code-based wallet linking system that enables secure connection between users' browser sessions and mobile wallet applications. This system allows users to verify and manage multiple wallet addresses while maintaining security through cryptographic signing processes. Transaction processing is handled through a multi-stage system that monitors and verifies transfers across both networks. The architecture includes automated refund mechanisms for failed transactions, with funds being returned to their originating addresses when issues occur. The platform's identity verification architecture is integrated with Instapass, which manages KYC verification and AML compliance. This integration enables automatic wallet address verification and ensures regulatory compliance across all transactions. Recent technical improvements have resulted in significant performance enhancements (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) , including optimizations that reduce transaction delays and improve processing speeds. The system architecture supports the platform's expanding token list while maintaining consistent 1:1 conversion ratios for all supported assets. Fees and Processing Instabridge employs a tiered fee structure based on transaction type and direction. The platform charges a 0.25% flat processing fee for all transactions, with an exception for eXRD to XRD conversions. Following platform upgrades in December 2024, the fee structure was revised (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) to eliminate fees for transactions into the Radix network, while outbound transactions incur a fee of 15 basis points, capped at $500. For Ethereum-originated transactions, users must maintain sufficient ETH in their accounts to cover Ethereum gas fees. Similarly, Radix-originated transactions require XRD for network fees, which are processed through the user's Radix Wallet. When unwrapping tokens from Radix to Ethereum, gas fees are deducted from the final ERC-20 token amount received. The platform's processing system has been optimized for speed and efficiency. Recent upgrades have achieved a fivefold increase in transaction speed (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) while significantly reducing the frequency of delayed transactions. The transaction monitoring system tracks all transfers in real-time, with status updates typically resolving within one business day. Processing limits are determined by user AML tiers, with higher tiers allowing for larger transaction volumes. Users can request tier upgrades through the Instapass system to increase their transaction limits. Regulatory Compliance Instabridge operates as a regulated Virtual Asset Service Provider (VASP), implementing comprehensive compliance measures through its integrated identity verification system. Users must complete KYC verification through Instapass before accessing the platform's services, ensuring compliance with international regulations. The platform employs a tiered AML system that determines transaction limits based on user verification levels. Users connecting to Instabridge for the first time must agree to terms and conditions and consent to personal data sharing for KYC and AML verification purposes. Transaction monitoring includes automatic compliance checks that prevent transfers exceeding user AML tier limits. The system automatically blocks transactions that would exceed these limits, requiring users to upgrade their AML tier through Instapass before proceeding with larger transfers. For institutional users, Instabridge maintains additional compliance measures (https://medium.com/instalabs-io/first-100k-of-xassets-bridged-onto-radix-01dc9fba13ca) , including exclusive access to certain token pairs. The platform's expansion of supported assets includes phased implementation approaches that prioritize regulatory compliance while gradually extending access to retail users. Integration with Anthic Instabridge serves as a foundational infrastructure component for the Anthic platform, an upcoming decentralized finance (DeFi) service. The integration aims to enable real-time trading with low slippage (https://medium.com/instalabs-io/first-100k-of-xassets-bridged-onto-radix-01dc9fba13ca) by leveraging Instabridge's cross-chain liquidity capabilities. The platform's expansion of supported tokens (https://medium.com/instalabs-io/announcing-major-upgrades-to-instabridge-faster-smoother-and-more-tokens-b74dc6967296) is strategically aligned with Anthic's planned launch in Q1 2025. This expansion includes the addition of various digital assets, including stablecoins, memecoins, and alternative Layer 1 tokens, designed to create diverse liquidity options for the Anthic ecosystem. The integration is intended to combine centralized exchange efficiency with decentralized trading capabilities, utilizing Instabridge's streamlined asset bridging system to facilitate rapid and cost-effective transactions within the Anthic platform. ## Addix URL: https://radix.wiki/ecosystem/addix Updated: 2026-09-01 Summary: Addix is a community-led meme coin project built on the Radix blockchain platform. The project was conceived during a period of low sentiment and pric… Addix – Radix Ecosystem Project Type Community-led meme coin Category Ecosystem (/ecosystem) (Token) Network Radix (/contents/tech/core-protocols/radix-engine) (mainnet) Founded March 2024 Founders Felix_xrd (founder), Haseeb (co-founder) Native Token $HIT (1,000,000,000,000 fixed, immutable supply) Token $HIT on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4v2jke9xkcrqra9sf3lzgpxwdr590npkt03vufty4pwuu205q03az) Key Features Rug-Proof staking, ADDIX-FOMO validator node, community initiatives (HIT SQUAD) X @addix_xrd (https://x.com/addix_xrd) Telegram addixanonymous (https://t.me/addixanonymous) Docs GitBook (https://addix-xrd.gitbook.io/usdhit-on-radix) Addix is a community-led meme coin project built on the Radix (https://www.radixdlt.com/) blockchain platform. The project was conceived during a period of low sentiment and price (https://addix-xrd.gitbook.io/usdhit-on-radix) in the Radix ecosystem, with the intention of giving back to the community and creating a fun addition to the platform. Addix's native token, $HIT (https://ociswap.com/resource_rdx1t4v2jke9xkcrqra9sf3lzgpxwdr590npkt03vufty4pwuu205q03az/) , was created to serve as a means for "Radix Addicts" to "get their fix" within the ecosystem. Introduction The project was founded by Felix_xrd, a long-term Radix supporter who discovered the platform through Dan Hughes' Tempo whitepaper (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) on the Bitcointalk forum. Addix aims to differentiate itself from other meme coins by implementing novel features such as Rug-Proof smart contracts (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) and focusing on community engagement and development within the Radix ecosystem. Unlike many speculative cryptocurrency projects, Addix emphasizes that $HIT is not designed as a tool for speculation (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) but rather as a fun and engaging way for community members to interact with the Radix ecosystem. The project's core values include transparency, community involvement, and contributing to the broader development of the Radix platform. As of 2024, Addix has implemented several key features, including a Rug-Proof staking mechanism (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) , partnerships with other Radix projects like FOMO, and ongoing community initiatives such as the HIT SQUAD (https://addix-xrd.gitbook.io/usdhit-on-radix/community-led/hit-squad) . The project continues to evolve, with plans for further development and integration within the Radix ecosystem. History Addix was founded by Felix_xrd (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) , a long-term Radix supporter and enthusiast. Felix's journey with Radix began when he discovered the Tempo whitepaper (https://www.radixdlt.com/blog/tempo-consensus-lessons-learned) written by Dan Hughes on the Bitcointalk forum. This discovery led Felix to become a dedicated Radix supporter, often referred to as a "Radix Maxi." The project was conceived during a period of low sentiment and price (https://addix-xrd.gitbook.io/usdhit-on-radix) in the Radix ecosystem, commonly referred to as an "ATL" (All-Time Low). The founders recognized that despite market conditions, there was a core group of supporters who remained committed to the Radix vision and community. This observation inspired the creation of Addix as a way to engage and reward these dedicated community members. Key milestones in Addix's history include: - Launch of the $HIT token (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) : The project's native token was created with a total supply of 1,000,000,000,000 (1,000 B) tokens. - Initial Liquidity Provision (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) : On March 24, 2024, Addix provided initial liquidity exclusively through Ociswap, a decision made to avoid the risks associated with distributed liquidity at the early stages of the project. - Collaboration with DogeCube (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) : On March 26, 2024, Addix donated 12.7 B HIT to the DogeCube Basket Index, marking an early collaboration within the Radix ecosystem. - Implementation of Rug-Proof Staking (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) : In April 2024, Addix successfully tested and implemented its novel Rug-Proof staking mechanism, locking 127.5 B HIT tokens in a smart contract for future staking rewards. - Tokenomics Revision (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) : In May 2024, following community feedback, Addix revised its tokenomics, reducing founder allocations and dedicating more tokens to validator rewards. - Partnership with FOMO (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) : On June 9, 2024, Addix announced a partnership with FOMO to run a Radix Network Validator Node, further integrating the project into the Radix ecosystem. - Validator Node Success (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) : As of July 31, 2024, the ADDIX-FOMO Validator Node entered the Top 100 validators on the Radix network, marking a significant achievement for the project. Throughout its history, Addix has demonstrated a commitment to community feedback, transparent operations, and contributing to the broader Radix ecosystem. The project continues to evolve, with ongoing initiatives aimed at enhancing user engagement and adding value to the Radix platform. Project Overview Addix is a community-led meme coin project (https://addix-xrd.gitbook.io/usdhit-on-radix) built on the Radix blockchain platform. The project's name, "Addix," is a playful reference to the notion that supporters are "addicted" to the Radix vision, community, and the prospect of solving the blockchain trilemma. The primary goals of Addix include: - Giving back to the Radix community (https://addix-xrd.gitbook.io/usdhit-on-radix) : Addix aims to reward and engage community members who have made significant contributions to the Radix ecosystem. - Adding fun and engagement (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) : As a meme coin, Addix is designed to be a fun addition to the Radix ecosystem, encouraging community interaction and engagement. - Promoting transparency and trust (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) : Through innovations like the Rug-Proof smart contracts, Addix aims to set new standards for transparency and trustworthiness in the cryptocurrency space. - Contributing to the Radix ecosystem (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) : Addix actively collaborates with other projects and contributes to the development of the Radix platform. The project's philosophy is rooted in the belief that community-driven initiatives can play a significant role in the growth and adoption of blockchain technology. Addix emphasizes that while it is a meme coin, it is not designed as a tool for speculation (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) . Instead, it focuses on creating value through community engagement, innovative features, and ecosystem contributions. Addix operates with a strong emphasis on community feedback and involvement. This is evident in their willingness to revise tokenomics (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) based on community input and their ongoing search for community members to join the HIT SQUAD (https://addix-xrd.gitbook.io/usdhit-on-radix/community-led/hit-squad) . The project leverages various aspects of the Radix platform, including its native token creation capabilities (https://docs.radixdlt.com/docs/resources) , smart contract functionality, and validator node system. By doing so, Addix not only benefits from the Radix infrastructure but also contributes to its ecosystem by demonstrating practical applications of these features. As with all cryptocurrency projects, Addix comes with risks, and the project explicitly disclaims (https://addix-xrd.gitbook.io/usdhit-on-radix) that nothing in their documentation should be considered financial advice. They encourage potential investors to conduct thorough research and exercise caution, reminding users that "it's just a $HIT Coin." Despite its playful nature, Addix aims to be a serious contributor to the Radix ecosystem, blending humor with genuine utility and community value. The project continues to evolve, with ongoing development and new initiatives aimed at enhancing its role within the Radix community. Technology 4.1 $HIT Token The $HIT token (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) is the native cryptocurrency of the Addix project. Key features of the token include: - Total supply (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) : 1,000,000,000,000 (1,000 B) tokens. - Resource Address (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) : resource_rdx1t4v2jke9xkcrqra9sf3lzgpxwdr590npkt03vufty4pwuu205q03az - No further minting or burning (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) capabilities. The token is designed to facilitate interactions within the Addix ecosystem, including staking and participation in community initiatives. 4.2 Rug-Proof Smart Contracts A key technological innovation of Addix is its Rug-Proof smart contract (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) for staking. This contract was developed by forking and modifying Astrolescent's Staking Contract (https://github.com/Astrolescent-Official/astrolescent-contracts-staking) , originally written by Timan. Key features of the Rug-Proof contract include: - Locking of staking rewards (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) in a contract that the founder cannot access. - Trustless distribution of rewards according to a predefined schedule. - Open-source code, encouraging transparency and adoption by other projects. The technical implementation involves: - Use of a OneResourcePool (https://github.com/nemster/astrolescent-contracts-staking/blob/main/src/lib.rs#L22) for user stakes. - A Vault for future rewards (https://github.com/nemster/astrolescent-contracts-staking/blob/main/src/lib.rs#L23) . - Restricted access (https://github.com/nemster/astrolescent-contracts-staking/blob/main/src/lib.rs#L13) to the deposit_rewards function. 4.3 Validator Node Addix operates a Radix Network Validator Node (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) in partnership with FOMO. The node's specifications include: - Hosting: IONOS cloud server. - Security: Firewall management, unlimited traffic, Wildcard SSL certificate. - Data center compliance: ISO-27001. - Hardware specifications (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) : - CPU: Intel® Xeon® E3-1230 v6 4 cores x 3.5 GHz (3.9 GHz Turbo Boost). - RAM: 32 GB DDR4 ECC. - Storage: 480 GB SSD (2 × 480 GB SSD) Software RAID 1. The validator node operates with specific parameters (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) : - 100% fee. - 15% of Addix tokens (150 B) allocated for node delegator airdrops over four years. - 2/3 of generated XRD used for Addix buybacks. - 1/3 of generated XRD used for FOMO buybacks. This technology stack demonstrates Addix's commitment to security, transparency, and active participation in the Radix network's consensus mechanism. By leveraging Radix's infrastructure and adding novel features like the Rug-Proof contract, Addix aims to provide a secure and engaging platform for its community while contributing to the broader Radix ecosystem. Tokenomics The tokenomics of Addix have undergone revisions based on community feedback, demonstrating the project's commitment to transparency and community-driven decision-making. Total Supply (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) : 1,000,000,000,000 (1,000 B) $HIT tokens. Initial Token Distribution (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) (April 2024): Revised Token Distribution (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) (May 2024): The revision in May 2024 was made in response to community feedback (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) , particularly regarding the reserve allocation. Key changes included: - Reducing founder and co-founder shares from 5% each to 2.5% each. - Allocating the former reserve to validator rewards. - Splitting the founder allocation between founder and co-founder. Liquidity Provisions (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) : - Initial liquidity was provided exclusively through Ociswap on March 24, 2024. - A donation of 12.7 B HIT (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) was made to the DogeCube Basket Index on March 26, 2024. - On May 27, 2024, 50 B HIT was added to a single-sided Liquidity Pool on DefiPlaza (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) to increase liquidity provision. Liquidity Strategies (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) : - The project has experimented with OciSwap "Splash as a Service" for liquidity pool rewards. - Plans to use RadLock for locking liquidity provider (LP) receipts once available. - Considering pulling out initial Founder LP provision on OciSwap and locking the remaining LP Receipt. - Intending to add substantial liquidity to DefiPlaza's single-sided Liquidity Pools and subsequently lock these LP Receipts. Founder Allocations (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/founder-allocations) : - Reduced from 5% each for Founder and Co-Founder to 2.5% each. - Plans to lock these allocations using RadLock once it becomes available. - Considering time-lock (e.g., 4 years) or value-lock (e.g., when Addix market cap reaches $100m) mechanisms. These tokenomics demonstrate Addix's commitment to fair distribution, community involvement, and long-term sustainability. The project's willingness to adjust its token allocation based on community feedback highlights its adaptability and focus on community-driven development within the Radix ecosystem. Features and Services 6.1 Rug-Proof Staking One of Addix's key innovations is its Rug-Proof staking mechanism (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) , which was implemented in April 2024. This feature aims to provide a trustless and transparent way for token holders to stake their $HIT tokens and earn rewards. Key aspects of the Rug-Proof staking include: - 12.75% of the total $HIT supply (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) (127.5 B tokens) locked in a Rug-Proof smart contract. - Rewards distributed according to a predefined schedule (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) . - Trustless distribution (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) of rewards, preventing the founder from accessing the locked tokens. The staking mechanism works similarly to Radix's native staking system (https://docs.radixdlt.com/docs/concepts-native-token-xrd) , using a concept of Liquid Staked Units (LSUs). When users stake $HIT, they receive StHIT tokens, which represent their stake in the pool. As rewards accumulate, the value of StHIT relative to $HIT increases, allowing stakers to benefit from their participation. Staking rewards (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) are distributed according to the following annual schedule: - Year 1: 5% - Year 2: 2.5% - Year 3: 1.25% - Year 4: 1.25% - Years 5-8: Decreasing percentages from 0.75% to 0.625% 6.2 Validator Node Rewards Addix operates a Radix Network Validator Node (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) in partnership with FOMO, which entered the Top 100 validators on July 31, 2024. This node plays a crucial role in the Radix network's consensus mechanism and provides an additional avenue for community participation and rewards. Key features of the Validator Node rewards include: - 15% of the total $HIT supply (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) (150 B tokens) allocated for validator rewards. - Rewards locked in a Rug-Proof smart contract (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) . - Emission schedule (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) starting from July 26, 2024. The validator node operates with the following parameters: - 100% fee (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) . - 2/3 of generated XRD (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) used for Addix buybacks. - 1/3 of generated XRD (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) used for FOMO buybacks. - Additional FOMO token airdrops (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) for delegators upon successful entry into the top 100 validators. The validator rewards emission schedule (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) for the first year is as follows: - Months 1-3: 20 B - Months 4-6: 15 B - Months 7-9: 12.5 B - Months 10-12: 12.5 B This dual reward system of Rug-Proof staking and validator node participation provides multiple ways for the Addix community to engage with the project and earn rewards. Both mechanisms are designed with transparency and community trust in mind, aligning with Addix's overall mission of contributing positively to the Radix ecosystem. Team and Collaborations The Addix project is built on a foundation of collaboration and community involvement, with a core team and various partnerships contributing to its development and growth within the Radix ecosystem. Core Team: - Founder: Felix (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Known as Felix_xrd. - Long-term Radix supporter and enthusiast. - Discovered Radix through Dan Hughes' Tempo whitepaper (https://www.radixdlt.com/blog/tempo-consensus-lessons-learned) on the Bitcointalk forum. - Described as a "Radix Maxi" due to his strong belief in the platform. - Co-Founder: Haseeb (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Experienced developer with a passion for coding. - Previously contributed to the Dexter project within the Radix ecosystem. - Brings technical expertise to the Addix project. Key Collaborators: - Validator Partner: Team FOMO (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Led by FOMO Jim - Collaborated on Staking and Airdrop Component - Joint operation of the ADDIX-FOMO Validator Node (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) - Technical Collaborator: Don Marco (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Contributed to the development of the Rug-Proof smart contract (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) - Forked and modified Astrolescent's Staking Contract for Addix's use - Art Collaborator: Endry Didier (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Contributes to the visual aspects of the Addix project - Marketing Collaborator: Team $NOW (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Assists with marketing strategies for Addix Other collaborations: - Bot builders (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Radix Degens (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) - Helpful Coders (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) The Addix team emphasizes the importance of decentralization in their approach to collaboration. They bring in collaborators and consult advisors (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) for specialized input as needed, reflecting their commitment to leveraging diverse expertise within the community. Community Involvement: Addix actively seeks community participation in various aspects of the project: - HIT SQUAD (https://addix-xrd.gitbook.io/usdhit-on-radix/community-led/hit-squad) : An initiative to recruit 1-2 outstanding community members as ambassadors, with the potential to join the team. - Ongoing search for collaborators (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) in different areas of expertise. The project's collaborative approach extends beyond its own boundaries, with a stated goal of contributing to the Radix ecosystem and community as a whole (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) . This is evident in their partnerships, open-source contributions, and active participation in the Radix validator network. By fostering these collaborations and maintaining an open approach to community involvement, Addix aims to position itself as an integral part of the Radix ecosystem while promoting the growth and adoption of the platform as a whole. Community Initiatives Addix places a strong emphasis on community engagement and involvement, recognizing the importance of a vibrant and active user base in the success of a decentralized project. Several key initiatives highlight Addix's commitment to fostering a strong community: 8.1 HIT SQUAD The HIT SQUAD (https://addix-xrd.gitbook.io/usdhit-on-radix/community-led/hit-squad) is a prominent community-focused initiative by Addix. Its main features include: - Recruiting 1-2 outstanding community members as ambassadors. - Potential for ambassadors to join the Addix team. - Focus on highly engaged and active individuals. - Emphasis on contributing to HIT's long-term success. This initiative demonstrates Addix's commitment to identifying and nurturing talent within its community, potentially creating a pipeline for future team members and project leaders. 8.2 Community-Driven Development Addix has shown a willingness to adapt based on community feedback, as evidenced by: - Revision of tokenomics (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) in May 2024 following community discussions. - Reduction of founder allocations from 5% to 2.5% each for founder and co-founder. - Introduction of a 15% allocation for validator rewards. These changes highlight Addix's responsiveness to community input and its commitment to transparent, community-driven development. 8.3 Open-Source Contributions Addix contributes to the broader Radix ecosystem through open-source development: - Rug-Proof smart contract (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) made available for other projects to adopt. - Collaboration on various community projects, including work with Team FOMO (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) on staking and airdrop components. 8.4 Community Engagement Events While specific details are not provided in the documentation, it's common for cryptocurrency projects like Addix to organize various community engagement events. These might include: - AMAs (Ask Me Anything) sessions (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/promotion-fun) with team members. - Community contests and giveaways. - Educational webinars about the Radix ecosystem and Addix's role within it. 8.5 Validator Node Participation The ADDIX-FOMO Validator Node (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) serves as a community engagement tool by: - Allowing community members to delegate their XRD to the node. - Providing rewards to delegators, including both $HIT and FOMO token airdrops. - Engaging the community in the broader Radix ecosystem through active participation in network validation. 8.6 Promotion and Fun Initiatives Addix has allocated 5% of its total token supply (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) (50 B $HIT) for promotion and fun activities. While specific details are not provided, this allocation suggests a commitment to: - Organizing giveaways (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/promotion-fun) . - Encouraging meme creation (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/promotion-fun) . - Fostering community discussions (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/promotion-fun) . - Other engagement activities that align with Addix's identity as a meme coin. These community initiatives reflect Addix's understanding of the importance of an engaged and active community in the success of a decentralized project. By fostering open communication, encouraging participation, and providing opportunities for community members to contribute meaningfully to the project, Addix aims to build a strong, loyal user base within the Radix ecosystem. Future Plans and Roadmap While Addix does not provide a formal, detailed roadmap in the available documentation, several future plans and ongoing initiatives can be inferred from the project's communications and current activities: 9.1 Continued Development of Rug-Proof Mechanisms Addix has demonstrated a commitment to developing Rug-Proof smart contracts (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-usdhit-staking) and intends to continue this work: - Potential expansion of Rug-Proof concepts to other aspects of the project. - Encouraging adoption of Rug-Proof contracts by other projects in the Radix ecosystem. 9.2 Enhanced Liquidity Strategies The project has outlined plans to improve its liquidity provision: - Utilization of RadLock (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) for securing liquidity once it becomes available. - Consideration of pulling out initial Founder LP provision on OciSwap (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) and locking the remaining LP Receipt. - Plans to add substantial liquidity to DefiPlaza's single-sided Liquidity Pools (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/initial-liquidity) and subsequently lock these LP Receipts. 9.3 Expansion of Validator Node Operations Following the success of entering the Top 100 validators on July 31, 2024 (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/rug-proof-validator-node) , Addix may look to: - Increase the node's ranking within the validator set. - Explore additional partnerships or node operations to further decentralize the Radix network. 9.4 Community Growth Initiatives Addix has shown a strong focus on community engagement and may expand these efforts: - Continued recruitment for the HIT SQUAD (https://addix-xrd.gitbook.io/usdhit-on-radix/community-led/hit-squad) . - Development of new community-driven initiatives and governance models. - Expansion of promotional and fun activities using the allocated 5% of tokens (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/tokenomics) . 9.5 Ecosystem Contributions As part of its commitment to the Radix ecosystem, Addix may: - Continue to collaborate with other projects (https://addix-xrd.gitbook.io/usdhit-on-radix/usdhit-team/team-and-collaborations) in the Radix space. - Develop new tools or services that benefit the broader Radix community. - Participate in ecosystem-wide initiatives to promote Radix adoption. 9.6 Token Utility Expansion While specific plans are not detailed, it's common for cryptocurrency projects to continually explore new use cases for their tokens. Addix may look to: - Develop new features or services that utilize the $HIT token (https://addix-xrd.gitbook.io/usdhit-on-radix/proof-of-usdhit/usdhit-token) . - Explore partnerships that could increase the utility of $HIT within and potentially beyond the Radix ecosystem. 9.7 Governance Implementation As the project matures, Addix may consider implementing more formal governance structures: - Potential introduction of a DAO (Decentralized Autonomous Organization) for community-driven decision-making. - Development of voting mechanisms using $HIT or StHIT tokens. It's important to note that as a "living document," (https://addix-xrd.gitbook.io/usdhit-on-radix) Addix's plans and roadmap are subject to change based on community feedback, market conditions, and developments within the Radix ecosystem. The project emphasizes adaptability and community involvement in its decision-making processes, suggesting that future plans will likely evolve with input from the Addix community. Token The $HIT token is live on Radix (/contents/tech/core-protocols/radix-engine) mainnet. Its supply and authorities are verifiable on-ledger: a fixed supply of 1,000,000,000,000 (1 trillion), with minting, burning, freezing and recall all permanently denied and the token’s rules locked ( $HIT on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4v2jke9xkcrqra9sf3lzgpxwdr590npkt03vufty4pwuu205q03az) ). It trades on Radix DEXs such as Ociswap (/ecosystem/ociswap) and DefiPlaza (/ecosystem/defiplaza) , and the project’s Rug-Proof staking contract was forked from Astrolescent (/ecosystem/astrolescent) ’s open-source staking code. Status note (July 2026): the $HIT resource remains live and its supply permanently fixed, but Addix’s most widely-documented milestones – the validator-node launch, tokenomics revision and Rug-Proof staking rollout – date to 2024; the roadmap items below should be read as historical intent rather than confirmed current activity. External Links - Addix website (https://addix.meme) - Addix documentation (GitBook) (https://addix-xrd.gitbook.io/usdhit-on-radix) - Addix on X (@addix_xrd) (https://x.com/addix_xrd) - Addix on Telegram (https://t.me/addixanonymous) - $HIT on Ociswap (https://ociswap.com/resource_rdx1t4v2jke9xkcrqra9sf3lzgpxwdr590npkt03vufty4pwuu205q03az) Related Radix ecosystem pages - Astrolescent (/ecosystem/astrolescent) – the open-source staking contract Addix forked for its Rug-Proof mechanism - Ociswap (/ecosystem/ociswap) – DEX where $HIT liquidity first launched - DefiPlaza (/ecosystem/defiplaza) – single-sided liquidity pool used by $HIT - DogeCube (/ecosystem/dogecube) – Basket Index that $HIT was donated to - RadLock (/ecosystem/radlock) – LP / founder-allocation locking planned by Addix - Dexter (/ecosystem/dexter) – earlier Radix project of co-founder Haseeb ## Treasury WG · Decide where the DAO stores XRD URL: https://radix.wiki/ideas/dao-xrd-custody Updated: 2026-09-01 Summary: The DAO needs a ratified custody model for its treasury: native on-ledger multisig vs. mixed custody, and a Treasury Risk & Diversification stance (ho… Working Group Treasury & Finance WG Governance Phase Phase 1 – active at launch Champion Austin Origin TC – Where should the DAO store $XRD? (https://radixtalk.com/t/tc-where-should-the-dao-store-xrd/2242) The DAO needs a ratified custody model for its treasury: native on-ledger multisig vs. mixed custody, and a Treasury Risk & Diversification stance (how much XRD vs. stablecoins to hold against a 6–12 month runway). Where it stands (August 2026) The Temp Check has not resolved, but the account it is about is now readable on the ledger. On 11 August 2026 the framework's On-Chain Identifiers & Verification Policy replaced its last placeholder with a deployed primary multi-signature treasury account (https://dashboard.radixdlt.com/account/account_rdx1c9l27suy4nte9ymge5c3eqqnnfepgf9p28d9lcsv3jvmd0f0z8j2fx) . Read on 16 August 2026 at epoch 335598, its owner rule is a CountOf(2) over three Ed25519 signature badges – the 2-of-3 threshold DAO Parameters §6A (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/parameters/dao-parameters-registry.md) specifies for this phase – and it holds 200 XRD, deposited on 10 August, plus one non-fungible. That non-fungible is the first thing the DAO has actually taken custody of. On 13 August 2026 at 15:24 UTC (https://dashboard.radixdlt.com/transaction/txid_rdx1kg65rh9spggn32h0cqj5d7jyn8n07euv98cmcj05xryn6rt5u4vqrgzjdg) the Consultations Master Badge moved out of a single-signature account and into the treasury account, satisfying the policy's custody rule before the policy itself is in force. So the account exists and is under a quorum; what has not arrived is a treasury. Nothing on the ledger yet speaks to this card's actual question – the ratio of XRD to stablecoins to hold against a 6–12 month runway – which waits on the Phase 2 Treasury Risk & Diversification Policy. The ledger reading is kept current on Radix Governance (/contents/tech/core-concepts/radix-governance#on-chain-register) . Deliverables - Resolve the Temp Check on primary XRD custody. - Adopt the Treasury Risk & Diversification Policy (Phase 2) target ratios. - Define stablecoin runway sizing for operating expenses. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Implemented by the treasury multisig (/ideas/dao-treasury-multisig-signers) . Sources - TC – Where should the DAO store $XRD? (https://radixtalk.com/t/tc-where-should-the-dao-store-xrd/2242) ## Marketing WG · Redesign & self-host the Radix website URL: https://radix.wiki/ideas/dao-website-redesign Updated: 2026-09-01 Summary: As the Foundation winds down, control of the primary web presence must move to the community. The RFC covers a new design, information structure, and… Working Group Marketing WG Governance Phase Phase 2 – activity-triggered Raised by Vlad, 19 February 2026 (https://radixtalk.com/t/rfc-radix-website-new-design-structure-hosting/2239) Carried by Timan (Astrolescent), on the Cloudflare proposal Origin RFC – Radix Website (https://radixtalk.com/t/rfc-radix-website-new-design-structure-hosting/2239) Latest 11 Aug 2026 – Governance Proposal 2 closed on 4 Aug with 56 ballots, all Approve, and no announced result. The redesign itself is still an RFC. As the Foundation winds down, control of the primary web presence must move to the community. The RFC covers a new design, information structure, and independent hosting so the DAO owns its top-of-funnel. Two tracks, and only one has moved (2 August 2026) The interim hosting migration has passed a temperature check. On 23 July 2026 Timan (Astrolescent) filed Proposal: Move the Radix Website to Cloudflare (https://radixtalk.com/t/proposal-move-the-radix-website-to-cloudflare/2318) : take a static copy of the existing Webflow site, host it on Cloudflare, review it for broken links and missing integrations, connect the existing domain once verified, and maintain it until the DAO exists and can decide the long-term direction – removing roughly $200 per month of Webflow hosting cost along the way. It is explicitly a preservation measure with a rollback path, not a redesign. The Council put it to the community as Temperature Check 5 (https://consultation.mountain-top.live/tc/5) on 25 July alongside Daffy's Stokenet proposal; both passed (https://t.me/RadixAccountabilityCouncil/906) , and on 28 July it was lifted to binding, XRD-weighted Governance Proposal 2 (https://consultation.mountain-top.live/proposal/2) . It closed on 4 August 2026 at 06:44 UTC with 56 ballots cast, every one of them Approve and none against, and the weight behind the voting accounts clears the 671,470,000 XRD quorum by roughly 40% – but as of 11 August no result had been announced, by the Council or by anyone else. The redesign itself is still an RFC. Vlad's RFC of 19 February 2026 (https://radixtalk.com/t/rfc-radix-website-new-design-structure-hosting/2239) – a new site built from scratch, merging the pages and subdomains scattered across the ecosystem rather than migrating them as they are – has had no temperature check and no vote. The two are complements, not rivals: if Proposal 2 passes it buys the time that RFC asks for, and it settles nothing the RFC proposes. Execution began (18 August 2026) The vote's result was never published; the work started anyway. On 18 August at 07:20 UTC the contributor carrying this workstream told the main Telegram channel they had a meeting that day about the website migration, "per the approved proposal" (https://t.me/radix_dlt/998599) , having cleared the DAO preparations that had held it up. It is the first public treatment of Governance Proposal 2 as carried — no tally has been announced by anyone, fourteen days after the ballot closed. The mechanism is a conversion, not a rebuild. At 10:49 UTC they reported the site being moved off its static export onto an Astro site hosted on Cloudflare (https://t.me/radix_dlt/998611) , generated with a coding agent from a requirements document. At 12:09 the first attempt was thrown away because it had produced a whole new design and forgotten it was meant to convert the existing static export (https://t.me/radix_dlt/998616) . That correction keeps the work inside what the ballots actually approved: Proposal 2 is a preservation measure, and the redesign above it remains an RFC nobody has voted on. Progress is to be reported publicly, with the community asked to check for errors at the 80/20 point (https://t.me/radix_dlt/998600) . A second site already exists, and it is not this one. radixdao.org (https://radixdao.org) — the interim official venue the DAO's on-chain register names — went up without an announcement; a member dated its appearance to Wednesday 12 August (https://t.me/radix_dlt/998623) and others said they had never heard of it. It serves the governance documents, the verification register (https://radixdao.org/verify/) and the voting entry point, and it is itself an Astro site. The division of labour was put to the contributors and confirmed (https://t.me/radix_dlt/998628) : radixdlt.com carries marketing, technology and commercial material; radixdao.org carries DAO documentation and governance. The requirement for a separate venue surfaced while the DAO's submission papers were being finalised (https://t.me/radix_dlt/998627) , which is why it arrived ahead of any announcement rather than after one. This RFC therefore governs one of two sites, and only the smaller question — what radixdlt.com becomes — is still open. The DNS move, and who is actually carrying this (28 August 2026) At 11:58 UTC on 28 August 2026 Timan (Astrolescent) told the main Telegram channel that he and Shambu would migrate radixdlt.com’s DNS from Webflow to Cloudflare at 3pm CET that day (https://t.me/radix_dlt/999821) , warning of short downtime. It did not happen on the day: at 13:19 UTC he reported a change of approach – hosting the worker on Radix’s own Cloudflare account, which is easier with DNS, with Shambu to do it in the coming days (https://t.me/radix_dlt/999829) . The DNS cutover is therefore still pending, and the migration has been at its last stage for a week. That is also the answer to who this card belongs to. It carried Vlad as champion and assignee because he wrote the redesign RFC (https://radixtalk.com/t/rfc-radix-website-new-design-structure-hosting/2239) on 19 February 2026, and that RFC has still never been put to a temperature check or a vote. The work described in the section above is a different proposal by a different person: Timan’s Cloudflare migration, which did pass. Reading this board on 28 August, Vlad said he had not dared commit to the website work while other work was outstanding (https://t.me/radix_dlt/999854) . The assignment has been removed; the RFC remains his and remains unvoted. Deliverables - Agree design, structure, and hosting ownership. - Migrate content and domains (ties to the Foundation asset transfer). - Stand up community-run hosting + maintenance. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Depends on domain/brand transfer (/ideas/dao-foundation-ip-asset-transfer) . Sources - RFC: Radix Website – New Design, Structure, Hosting (https://radixtalk.com/t/rfc-radix-website-new-design-structure-hosting/2239) ## Tooling WG · Vote delegation & governance notifications URL: https://radix.wiki/ideas/dao-vote-delegation-jazzer-bot Updated: 2026-09-01 Summary: Two tools sat on this card from July 2026: vote delegation, and the Jazzer bot as the way to push proposals into Telegram. Delegation now has a writte… Working Group Governance Tooling WG Governance Phase Phase 2 – activity-triggered Policy Token Delegation Policy (https://github.com/Shadaffy/radix-dao/blob/master/Governance-Processes/Core/Token-Delegation-Policy.md) , written and unimplemented On ledger No delegation in Governance v1.0.0, read at epoch 338,958 on 28 August 2026 Champion Peachy (delegation design) Origin Governance tools and processes needed (https://radixtalk.com/t/governance-tools-and-processes-needed/2119) · RFC: Jazzer bot (https://radixtalk.com/t/rfc-jazzer-bot/2228) Two tools sat on this card from July 2026: vote delegation, and the Jazzer bot as the way to push proposals into Telegram. Delegation now has a written policy and no code. The bot was switched off five months before this card was created. Vote delegation The design came out of Peachy's January 2026 thread on governance tools and processes (https://radixtalk.com/t/governance-tools-and-processes-needed/2119) . Voting weight is stake units on validators, converted to their XRD equivalent and counted at a snapshot taken before the vote opens, so a holder cannot see a proposal, stake into it and vote. Holders who have delegated elsewhere are excluded from that count. linuxx proposed a membership NFT minted against a staking minimum, delegable by whoever holds it. The DAO has since written the rule down. The Token Delegation Policy (https://github.com/Shadaffy/radix-dao/blob/master/Governance-Processes/Core/Token-Delegation-Policy.md) in the governance framework repository runs eleven sections: one delegate at a time, revocable at any point and effective from the next snapshot, self-delegation to take the vote back, delegated votes counting identically toward quorum, and a voluntary Public Delegate Registry that the Governance & Legal Working Group maintains. Where a single delegate approaches the constitutional quorum of 10% of circulating XRD, the Radix Accountability Council (/ecosystem/radix-accountability-council) may flag the concentration and ask delegators to review it. The policy calls that advisory and leaves hard caps to a governance vote. Two of its clauses describe a mechanism that does not exist yet. Section 3.1 records delegation on-chain; section 6.2 says every delegation relationship is visible there. The Radix DAO Consultations (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) component, the instance the framework's on-chain register names, runs blueprint Governance version 1.0.0. Its twenty entry points, one function and nineteen methods, include no way to delegate a vote. The three voting methods each take the voting account itself, and the component stores parameter sets, temperature checks, proposals and elections, with nowhere to record who votes for whom. Read at epoch 338,958 on 28 August 2026, all three of its counters still read zero. The DAO Parameters Registry (https://github.com/Shadaffy/radix-dao/blob/master/Parameters/DAO-Parameters-Registry.md) is the document that reconciles them. Section 8 lists delegation as "Allowed (Phase 2, when platform supports delegation)". The policy is finished. The platform it depends on is the governance app (/ideas/dao-governance-app-consultation-v2) , and delegation sits in that app's backlog. None of this is law yet. The policy sits in the reference library, and the DAO's operative repository (https://github.com/Shadaffy/radix-dao-governance) is the one that carries force: "if it's there, it's law". Read on 28 August 2026 its constitutional, governance, legal and parameters directories hold a .gitkeep and nothing else, with every document waiting in pending/, and the delegation policy is not among them. The library's own status table (https://github.com/Shadaffy/radix-dao/blob/master/PRECEDENCE-AND-STATUS.md) marks the Token Delegation Policy active on a trigger, "activates when delegation is supported on platform", which makes sections 3.1 and 6.2 dormant rather than contradicted. One word to keep apart. The operative set uses Delegate in a different sense: the Delegate Mandate (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/delegate-mandate.md) defines five Delegated Functions, execution agents the Radix Accountability Council (/ecosystem/radix-accountability-council) seats to carry out decisions it has no part in making. A delegate under the Token Delegation Policy receives a vote. A Delegate under the Mandate signs a transaction someone else authorised. The Jazzer bot is off This card listed deploying the Jazzer bot for proposal alerts, and cited a thread that asked for the opposite. Austin opened RFC: Jazzer bot (https://radixtalk.com/t/rfc-jazzer-bot/2228) on 8 February 2026 with one line: he proposed turning the bot off in the main Telegram channel, where it had been posting repeating introductory messages. James.xrd agreed and called for a vote. Peachy and VandyILL each ran a poll. SaucyNoodle proposed a middle path, a one-line reply pointing back at the original message and sent from a dedicated account, so the text stopped breaking up conversations. On 20 February the bot's operator, Jazzer_9F, closed the thread himself: the vibe was clear, he would deactivate it over the weekend, and the functionality stays available if good content ever arrives for it. That last clause is the open door. Proposal outcomes are published only inside the governance dApp today, and the person who ran the channel-side plumbing has said he can bring it back. Anyone who wants proposal alerts in Telegram has a working bot to ask for and a Working Group to ask in. Deliverables - Implement delegation in the governance component and expose it in the app, so sections 3.1 and 6.2 of the policy describe something real. - Stand up the Public Delegate Registry the policy assigns to the Governance & Legal Working Group. - Decide how proposals and elections reach Telegram now that the bot that did it is off. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Extends the governance app (/ideas/dao-governance-app-consultation-v2) , takes its snapshot rule from the Proposal & Voting Framework (/ideas/dao-proposal-voting-framework) , and is recorded in the Parameters Registry (/ideas/dao-parameters-registry) . - Delegate conduct falls under the conflict-of-interest policy and code of conduct (/ideas/dao-coi-code-of-conduct) . Sources - Token Delegation Policy (https://github.com/Shadaffy/radix-dao/blob/master/Governance-Processes/Core/Token-Delegation-Policy.md) (governance framework repository) - DAO Parameters Registry (https://github.com/Shadaffy/radix-dao/blob/master/Parameters/DAO-Parameters-Registry.md) , section 8, Identity & Participation Parameters - Governance tools and processes needed (https://radixtalk.com/t/governance-tools-and-processes-needed/2119) (delegation design, January 2026) - RFC: Jazzer bot (https://radixtalk.com/t/rfc-jazzer-bot/2228) (the shutdown thread, February 2026) - Radix DAO Consultations component (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) on the Radix Dashboard - Operative governance repository (https://github.com/Shadaffy/radix-dao-governance) and the reference library's precedence and document status (https://github.com/Shadaffy/radix-dao/blob/master/PRECEDENCE-AND-STATUS.md) - Radix DAO Delegate Mandate (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/delegate-mandate.md) v1.0.0, 25 August 2026 ## NetOps WG · Decide the validator subsidy future & pseudo-jailing URL: https://radix.wiki/ideas/dao-validator-subsidy-future Updated: 2026-09-01 Summary: The validator subsidy underwrites network liveness and is one of the DAO's most consequential early decisions. The RFC weighs ending it immediately, a… Working Group Network Operations WG Governance Phase Phase 1 – active at launch Champion Faraz Origin RFC – Validator Subsidy & Pseudo-Jailing (https://radixtalk.com/t/rfc-the-future-of-the-validator-subsidy-pseudo-jailing/2167) The validator subsidy underwrites network liveness and is one of the DAO's most consequential early decisions. The RFC weighs ending it immediately, a phased reduction, or continuing it, alongside an optional pseudo-jailing mechanism to enforce uptime. Where it stands (August 2026) Re-measured on 16 August 2026 at epoch 335598, the concentration figure in the RFC has moved, and against the target. The RFC weighs the decision on a top-50 share of roughly 85% and asks for a median around 1%. A whole read of the validator list returns 4,773,496,229 XRD staked, of which the top 50 validators hold 90.66%; the top 10 alone hold 39.94%, and the median of the 100-slot active set – the 50th validator, on 20,791,259 XRD – is 0.436% of stake, under half the target. The survey question the RFC poses therefore lands on a narrower base than it assumes. Only 89 validators hold a million XRD or more, and the bottom of the active set runs to tens of thousands: rank 100 holds 45,500 XRD. Those are the operators for whom ending the subsidy is a decision about whether to keep a node running at all, and they are the same operators the recruitment card (/ideas/dao-grow-validator-set) is trying to add to. Deliverables - Vote the subsidy timeline (immediate / phased to ~2-month transition / continue). - Decide whether to implement pseudo-jailing (committee votes, stake-weight thresholds, 70%+ opt-in). - Address validator-set concentration (top-50 hold ~85% of stake; target ~1% median). - Survey validators on how many would exit if the subsidy ends. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Funded from operating budgets (/ideas/dao-operating-budgets) . - Administered by a subsidy-administration entity (/ideas/dao-subsidy-admin-entity) . Sources - RFC: The Future of the Validator Subsidy & Pseudo Jailing (https://radixtalk.com/t/rfc-the-future-of-the-validator-subsidy-pseudo-jailing/2167) ## Treasury WG · Stand up the treasury multisig & Authorized Signers URL: https://radix.wiki/ideas/dao-treasury-multisig-signers Updated: 2026-09-01 Summary: Execution is separated from decision-making: an M-of-N multisig holds DAO funds and Authorized Signers move them only against an approved proposal – "… Working Group Treasury & Finance WG Governance Phase Phase 1 – active at launch Champion Peachy · StakingCoins Origin Governance tools thread (https://radixtalk.com/t/governance-tools-and-processes-needed/2119) · Authorized Signers Rules (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) Execution is separated from decision-making: an M-of-N multisig holds DAO funds and Authorized Signers move them only against an approved proposal – "No RFP = No Payment!". Signers are selected via RFC/RFP with fixed term limits; non-signers get read-only visibility. Where it stands (August 2026) The multisig is deployed, and it is 2-of-3. The primary multi-signature treasury account (https://dashboard.radixdlt.com/account/account_rdx1c9l27suy4nte9ymge5c3eqqnnfepgf9p28d9lcsv3jvmd0f0z8j2fx) recorded in the framework's On-Chain Identifiers & Verification Policy on 11 August 2026 carries an owner rule of CountOf(2) over three Ed25519 signature badges, read on 16 August 2026 at epoch 335598. That matches the document exactly: DAO Parameters §6A (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/parameters/dao-parameters-registry.md) specifies 2-of-3 for ordinary actions in this phase, rising to 3-of-5 standard and 4-of-5 high-risk on the Activation Date. It has moved something. On 13 August 2026 (https://dashboard.radixdlt.com/transaction/txid_rdx1kg65rh9spggn32h0cqj5d7jyn8n07euv98cmcj05xryn6rt5u4vqrgzjdg) the Consultations Master Badge was deposited into it, the first governance authority the account has held; it otherwise holds 200 XRD from a 10 August funding transaction. What the deployment does not yet carry is the process around it. The Authorized Signers Rules are unratified, so terms, rotation and revocation bind nobody; the mandatory RFP-reference field is a convention no on-ledger rule enforces, and the badge deposit carried no message; and the read-only visibility promised to non-signers is, for now, the public account address itself. Cross-referenced on Radix Governance (/contents/tech/core-concepts/radix-governance#on-chain-register) . Deliverables - Deploy an on-ledger M-of-N multisig (a shared Scrypto blueprint was offered by StakingCoins). - Ratify the Authorized Signers Rules (selection, 1-year terms, rotation, revocation). - Enforce a mandatory RFP-reference field on every outgoing transfer (XRD and USDC). - Provide read-only treasury dashboards for the community. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Depends on DUNA incorporation (/ideas/dao-incorporate-duna-llc) . - Spends against operating budgets (/ideas/dao-operating-budgets) ; stores assets per XRD custody (/ideas/dao-xrd-custody) . Sources - Governance tools and processes needed (Treasury/Multisig app) (https://radixtalk.com/t/governance-tools-and-processes-needed/2119) - Reference repo – Execution & Treasury Actions Policy (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) ## NetOps WG · Stand up a subsidy-administration entity with transparency reporting URL: https://radix.wiki/ideas/dao-subsidy-admin-entity Updated: 2026-09-01 Summary: Once the Foundation stops administering subsidy payouts, a community body must take over: computing uptime-adjusted payments, distributing them, and r… Working Group Network Operations WG Governance Phase Phase 2 – activity-triggered Champion Open Origin Subsidy RFC – Phase 2 (community entity) (https://radixtalk.com/t/rfc-the-future-of-the-validator-subsidy-pseudo-jailing/2167) Once the Foundation stops administering subsidy payouts, a community body must take over: computing uptime-adjusted payments, distributing them, and reporting transparently each month. Deliverables - Assign subsidy administration to a WG / Authorized Signers. - Implement uptime-adjusted payment computation from ledger data. - Publish monthly transparency reports. - Allocate a small admin stipend (amount via proposal). Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Executes the outcome of the subsidy decision (/ideas/dao-validator-subsidy-future) . - Pays via the treasury multisig (/ideas/dao-treasury-multisig-signers) . Sources - RFC: Validator Subsidy – Phase 2 community entity (https://radixtalk.com/t/rfc-the-future-of-the-validator-subsidy-pseudo-jailing/2167) ## Dev WG · Assume stewardship of the Radix Wallet & core stack URL: https://radix.wiki/ideas/dao-steward-radix-wallet Updated: 2026-09-01 Summary: In the Telegram thread the community suggested putting "the people who are working for Radix" in charge of each area – e.g. whoever maintains the Radi… Working Group Core Development WG Governance Phase Phase 2 – activity-triggered Champion Open (wallet maintainer) Origin TG msg 995036 – put the wallet maintainer in charge (https://t.me/radix_dlt/995033) Latest 7 Aug 2026 – wallet & Gateway in volunteer, bug-fix-only maintenance; the dApp Toolkit untouched since March In the Telegram thread the community suggested putting "the people who are working for Radix" in charge of each area – e.g. whoever maintains the Radix Wallet should lead wallet development. The DAO must formally assume stewardship and funding of the Wallet, Gateway, and dApp Toolkit that the ecosystem depends on. Where it stands (7 August 2026) The three components named in the deliverables below are not being held on the same terms, and none of them is funded. Asked in the Radix Developer Discussion group on 7 August 2026 whether further wallet releases were planned, a contributor answered that there are none: the wallet is being kept going on a volunteer basis with bug fixes only, and the same holds for the Gateway, "until a future direction is set by the community" (https://t.me/RadixDevelopers/65908) and decided by a proposal. The public repositories agree, read on 8 August 2026: Component Most recent commit Latest published release babylon-wallet-ios (https://github.com/radixdlt/babylon-wallet-ios) 30 July 2026 – a missing-mnemonic defect fix (https://github.com/radixdlt/babylon-wallet-ios/pull/1513) 1.18.4 (25 November 2025) babylon-wallet-android (https://github.com/radixdlt/babylon-wallet-android) 31 July 2026 – the same fix, a day later (https://github.com/radixdlt/babylon-wallet-android/pull/1447) 1.22.1 (9 June 2026) babylon-gateway (https://github.com/radixdlt/babylon-gateway) 20 May 2026 – documentation only (https://github.com/radixdlt/babylon-gateway/pull/840) v1.10.6 (7 April 2026) radix-dapp-toolkit (https://github.com/radixdlt/radix-dapp-toolkit) 2 March 2026 – the subintent-header release merge (https://github.com/radixdlt/radix-dapp-toolkit/pull/324) v2.3.0 (2 March 2026) The two wallet repositories are getting upkeep: a single defect fix, applied to iOS on 30 July and to Android a day later, is the only change on either since 9 June 2026. The Gateway (/contents/tech/core-protocols/radix-gateway-api) has taken no code change since May. The Radix dApp Toolkit — the third component this card names, and the library dApps use to connect to the Radix Wallet — has no volunteer holding it at all: no commit on main and no published release since 2 March 2026, with npm still serving 2.3.0 (https://www.npmjs.com/package/@radixdlt/radix-dapp-toolkit) from that date. None of the four repositories is archived, and both wallet apps remain published and installable. That leaves this card's status correct rather than stale. The route onward was described in the same thread as three stages (https://t.me/RadixDevelopers/65907) — a draft discussion on RadixTalk (/ecosystem/radixtalk) , a temperature check on the Radix Consultation app, then a governance proposal settling what is done and who does it — and at that date only draft discussions were open, with no proposal in flight. Fuller background at Radix Wallet (/contents/tech/core-protocols/radix-wallet) and Radix Governance (/contents/tech/core-concepts/radix-governance) . Deliverables - Confirm maintainers for Wallet, Gateway, and Radix dApp Toolkit. - Budget ongoing maintenance and support via RFP. - Publish support/SLA expectations for these core services. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Owner is an elected steward per the Working Group Framework (/ideas/dao-working-group-framework) . - Related client work: MetaMask Snap (/ideas/dao-protocol-dry-run-snap) . Sources - Radix DLT Official – "most important people in each area" (https://t.me/radix_dlt/995033) - Consultation v2 – Product Scope (https://radixtalk.com/t/consultation-v2-product-scope-document/2193) ## Community WG · Continue Radix Rewards (Mini Season 2) through the handover URL: https://radix.wiki/ideas/dao-radix-rewards-mini-season-2 Updated: 2026-09-01 Summary: Radix Rewards drives on-chain activity and retention. To avoid a gap during the Foundation handover, the community proposed a bridging Mini Season 2 –… Working Group Community WG Governance Phase Transition (pre-DAO) Champion Austin Origin RFC – Mini Season 2 of Radix Rewards (https://radixtalk.com/t/rfc-mini-season-2-of-radix-rewards-during-foundation-handover/2191) Radix Rewards drives on-chain activity and retention. To avoid a gap during the Foundation handover, the community proposed a bridging Mini Season 2 – a well-supported RFC (44 replies) the DAO should fund and run. Where it stands (August 2026) This card was listed as approved; it is not, and never was. The RFC (https://radixtalk.com/t/rfc-mini-season-2-of-radix-rewards-during-foundation-handover/2191) opened on 28 January 2026 and the thread ran out in February without a decision, split between funding a slimmed-down season to keep the ecosystem liquid and preserving capital until the DAO takes over. A poll put to the thread — a 10 million XRD pool over three months, against waiting for the DAO — is the furthest the proposal ever travelled. Under the three-stage route the DAO now uses — a draft discussion on RadixTalk (/ecosystem/radixtalk) , a temperature check on the Radix Consultation app (/ideas/dao-governance-app-consultation-v2) , then a binding governance proposal — it never left the first stage. The temperature checks the Radix Accountability Council (/ecosystem/radix-accountability-council) has put to that app cover Stokenet operations, the Radix website and CAIP/x402 registration; none of them concerns rewards. Six months on, incentives.radixdlt.com (https://incentives.radixdlt.com/) is still titled "Radix Rewards - Season 1", and no second season has been funded or run. Status corrected from Approved to Discussion on 8 August 2026. Deliverables - Finalize Mini Season 2 scope, budget, and duration. - Fund it from the treasury via RFP. - Operate and report on participation. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Funded via the treasury multisig (/ideas/dao-treasury-multisig-signers) . Sources - RFC: Mini Season 2 of Radix Rewards during Foundation Handover (https://radixtalk.com/t/rfc-mini-season-2-of-radix-rewards-during-foundation-handover/2191) ## Product WG · Own & maintain the product roadmap URL: https://radix.wiki/ideas/dao-product-roadmap-ownership Updated: 2026-09-01 Summary: With the Foundation stepping back, no accountable body owns product direction. The Strategic Council RFC proposes an elected Product lead to define an… Working Group Product WG Governance Phase Phase 2 – activity-triggered Champion Phil Gibson (proposed lead) Origin Strategic Council – Product area (https://radixtalk.com/t/rfc-radix-strategic-council/2266) · Product Scope (https://radixtalk.com/t/consultation-v2-product-scope-document/2193) With the Foundation stepping back, no accountable body owns product direction. The Strategic Council RFC proposes an elected Product lead to define and maintain the roadmap, prioritize development, and coordinate delivery across the development and tooling WGs. Deliverables - Elect a Product lead (6-month term, XRD-weighted vote). - Publish and maintain a prioritized roadmap. - Coordinate delivery with Core Development (/ideas/dao-xian-protocol-upgrade) and Tooling WGs. - Report fortnightly on RadixTalk. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Instance of the Working Group Framework (/ideas/dao-working-group-framework) . Sources - RFC: Radix Strategic Council (https://radixtalk.com/t/rfc-radix-strategic-council/2266) - Consultation v2 – Product Scope (https://radixtalk.com/t/consultation-v2-product-scope-document/2193) ## BizDev WG · Own ecosystem partnerships & integrations URL: https://radix.wiki/ideas/dao-partnerships-integrations Updated: 2026-09-01 Summary: The Strategic Council RFC assigns integrations, exchange listings, and ecosystem relationships to a Partnerships lead; Leonets proposed merging Market… Working Group BizDev & Partnerships WG Governance Phase Phase 2 – activity-triggered Champion Open (Leonets proposed consolidation) Origin Strategic Council – Partnerships / BizDev (https://radixtalk.com/t/rfc-radix-strategic-council/2266) The Strategic Council RFC assigns integrations, exchange listings, and ecosystem relationships to a Partnerships lead; Leonets proposed merging Marketing + Partnerships into one Business Development WG for efficiency. The DAO must decide the shape and give partnerships an accountable owner. Deliverables - Decide whether Marketing + Partnerships consolidate into one BizDev WG. - Elect a lead and set a partnerships pipeline. - Prioritize integrations that expand XRD utility and reach. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Consolidation decided in the WG Framework (/ideas/dao-working-group-framework) . - Overlaps Marketing (/ideas/dao-marketing-merch-revenue) . Sources - RFC: Radix Strategic Council (Partnerships) (https://radixtalk.com/t/rfc-radix-strategic-council/2266) ## Governance WG · Settle the DAO Parameters Registry URL: https://radix.wiki/ideas/dao-parameters-registry Updated: 2026-09-01 Summary: Every threshold the governance process depends on is centralised in one registry, so a parameter can be tuned by Governance Proposal without amending… Working Group Governance WG Governance Phase Phase 1 – active at launch Champion Daffy (Shadaffy) Origin Round 2 – §3–§9 parameters (https://radixtalk.com/t/rfc-dao-documents-round-2-proposal-voting-and-transition-framework/2273) Latest 23 Aug 2026 – the five parameter sets are live on the DAO governance component; quorums are fixed XRD struck against total supply, and §3.3A is not encoded Every threshold the governance process depends on is centralised in one registry, so a parameter can be tuned by Governance Proposal without amending the Charter. The card asked the community to settle the opening values. They are settled and published (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/parameters/dao-parameters-registry.md) — a single document of roughly 59,000 characters in the operative governance repository (https://github.com/Shadaffy/radix-dao-governance) , and one of the twenty-one documents GP-PRE-1 ratifies (/ideas/dao-adopt-phase1-governance-docs) . It sits in the operational-policy tier of the precedence stack, below the Operating Agreement and the Charter. The settled values Quorum (§3.2), measured as participation — YES + NO + ABSTAIN — against eligible voting power at the vote's snapshot: Constitutional 10%, Governance Process 7%, Treasury/Budget 7%, Executable 5%, Temperature Check 3%. Treasury and Budget proposals carry an additional absolute floor of 50 unique voting addresses, an abstention counting toward it, because the floor measures breadth rather than direction. Approval (§3.3), measured as the YES share of decisive votes — YES + NO, excluding ABSTAIN: Constitutional ≥66%, Governance Process ≥60%, Treasury/Budget ≥50%, Executable ≥50%, Temperature Check ≥50%. Minimum Affirmative Support (§3.3A) is the section with no counterpart in the Round 2 RFC this card was written from, and it closes a hole the two tests above leave open. Because ABSTAIN counts toward quorum but not toward approval, a proposal can in principle be carried over quorum largely by abstentions and then decided by a very small base of actual support. So a YES floor applies independently, as a share of eligible voting power: 3.5% Constitutional, 2% Governance Process, 1.5% Treasury/Budget, 1% Executable. Each figure is about half the YES share a zero-abstention vote clearing quorum at its approval threshold would produce, which is the same as saying abstentions may carry at most roughly half the participation burden. All three tests must pass. Durations (§3.1): ≥5 days of draft discussion, a 5–7 day Temperature Check, a 5–7 day binding vote, and a 5-business-day window in which a passed Temperature Check must be elevated or documented grounds for delay recorded with the RAC — elapse without either arms an elevation backstop. Cooldowns (§3.4): 7 days after a failed proposal, none for a minor fix, and one Treasury proposal per wallet per rolling 30 days. Eligible voting power (§8, §8A) answers the question a quorum percentage is meaningless without: a percentage of what. Liquid XRD and LSUs converted to their XRD equivalent at the snapshot are a constitutional floor, entrenched by Charter §12.1 item 4 and removable by nothing. A second tier the RAC can adjust on 30 days' notice holds LSULP, fungible LP pool units on Ociswap, CaviarNine (/ecosystem/caviarnine) and DefiPlaza (/ecosystem/defiplaza) , Ociswap precision pools and CaviarNine shape pools. Delegation is recognised by Charter §5 but the registry records it as not yet enabled, pending platform support — an implementation status, the document is careful to say, not a limit on the right. Activation parameters (§3A) govern the founding sequence itself. Framework ratification and the Activation Vote both run at ≥66% YES on a 10% quorum with the 3.5% affirmative floor; the Permanent RAC election must open within 90 days of ratification and seat at least five KYC-verified members before the Activation Statement; and an advisory outcome during the pre-activation period needs ≥7% participation and ≥50% YES to be "recognised" at all, which is what obliges the Transition RAC to respond to it. Deliverables - §3.1 voting durations · §3.2 quorum requirements · §3.3 approval thresholds · §3.4 cooldown periods. Published. - §4 veto parameters · §8 identity & participation parameters · §9 execution parameters. Published, alongside sections the RFC did not anticipate: §3A activation, §6A treasury signers, §6B elections, §6C dispute resolution, §9A continuity. - Classify each parameter as minor (patch) vs major (structural) for future amendments — §11 defers this to the Governance Maintenance & Upgrade Framework §4–6 rather than settling it in the registry. - Publish the registry as machine-readable config the governance app can read. Done on 12 August 2026, as five parameter sets on the DAO governance component – see below. The Markdown remains the normative text. Dependencies & cross-references - Ratified as part of GP-PRE-1 (/ideas/dao-adopt-phase1-governance-docs) ; values thereafter changed by Governance Proposal. - Feeds the Proposal & Voting Framework (/ideas/dao-proposal-voting-framework) , which defines how the measurements above are taken. - Sets the Working Group figures used by the Working Group Framework (/ideas/dao-working-group-framework) and the treasury figures used by the treasury signers (/ideas/dao-treasury-multisig-signers) . - Its §8A source list is what a recomputed quorum (/contents/tech/core-concepts/radix-governance) must be measured against; counting liquid XRD alone reads far short. Sources - DAO Parameters Registry (operative repo, pending/parameters/) (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/parameters/dao-parameters-registry.md) - pending/README.md – the ratified set and document precedence (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/README.md) - RFC Round 2 – the parameter sections as originally scoped (https://radixtalk.com/t/rfc-dao-documents-round-2-proposal-voting-and-transition-framework/2273) The registry reaches the ledger (12 August 2026) The last open deliverable on this card asked for the registry as machine-readable config the governance app can read, and noted that it remained prose in Markdown with nothing consuming it programmatically. That is no longer true. Between 17:23 and 17:33 UTC on 12 August 2026, five GovernanceParameterSet entries were written into the parameter_sets key-value store of the DAO's Radix DAO Consultations (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) component, each by an owner-gated add_governance_parameter_set or update_governance_parameter_set call. Read live at epoch 337,473 on 23 August, all five are present and none is retired. Parameter set Label Temperature check Binding stage dao-constitutional Constitutional 5 days · 405,249,777 XRD · 50% 7 days · 1,350,832,592 XRD · 66% dao-governance Governance Process 5 days · 405,249,777 XRD · 50% 7 days · 945,582,814 XRD · 60% dao-treasury Treasury or Budget 5 days · 405,249,777 XRD · 50% 7 days · 945,582,814 XRD · 50% default Standard Executable (version 2) 5 days · 405,249,777 XRD · 50% 7 days · 675,416,296 XRD · 50% dao-election Majority Judgement Election 3 days · 405,249,777 XRD · 50% 7 days · 945,582,814 XRD · median grade Good The durations and the approval thresholds are §3.1 and §3.3 exactly: 66, 60, 50, 50, 50, on a five-to-seven-day temperature check and a seven-day binding vote. The quorums are §3.2 exactly too, but expressed differently, and the difference matters. Each is a fixed quantity of XRD rather than a percentage the contract computes at the snapshot, and the four distinct figures stand in a clean 10 : 7 : 5 : 3 ratio to a single base of 13,508,325,920 XRD. That base is not eligible voting power. XRD total supply read at the state version of the first of those five writes was 13,508,342,408.66 – the same number to within about half an hour of issuance – so the percentages were struck against total supply, while §3.2 defines quorum as participation against eligible voting power at the vote's snapshot and §8A defines that as a strict subset of supply: liquid XRD, LSUs, LSULP and eligible pool positions. Against the smaller base the same absolute figure is a larger share, so each threshold as deployed is harder to clear than the registry's own percentage reads. Nothing in the contract updates it, either: supply inflates by roughly 300 million XRD a year, so an untouched figure drifts downward as a share of supply and can only be corrected by an owner-gated update_governance_parameter_set call. Two of the registry's tests are absent from the ledger entirely. StandardProposalParameters carries three fields – voting days, quorum, approval threshold – and has no room for the 50-unique-address floor on Treasury and Budget proposals, nor for §3.3A Minimum Affirmative Support, the independent YES floor of 3.5 / 2 / 1.5 / 1% that stops a proposal being carried over quorum by abstentions. Both remain off-ledger tests that whoever publishes a result must apply by hand, which is the same division of labour that already governs the tally itself: the ballots are on-ledger, the arithmetic that judges them is not. The dao-election set is the one entry with a different shape, and its terms are read out on the permanent RAC card (/ideas/dao-elect-permanent-rac) . ## Treasury WG · Set 6–12 month operating budgets for core functions URL: https://radix.wiki/ideas/dao-operating-budgets Updated: 2026-09-01 Summary: Community feedback argues the DAO should "think like a company" with a 6–12 month budget horizon: vote a single budget per core function (e.g. Network… Working Group Treasury & Finance WG Governance Phase Phase 1 – active at launch Champion Open (RAC to facilitate) Origin TG thread – budget-horizon model (https://t.me/radix_dlt/995033) Community feedback argues the DAO should "think like a company" with a 6–12 month budget horizon: vote a single budget per core function (e.g. Network Operation & liveness, Market Making) and let the operating body spend within it, rather than voting on every line item. The Permanent RAC must surface how much is needed to run the DAO's core functions. Deliverables - Publish a cost model for core functions (network liveness, market making, wallet/engine, governance ops). - Vote 6–12 month budgets per function via RFP. - Grant spend authority within budget to the relevant WG / Authorized Signers. - Report actuals against budget each period. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Sized by the transferred treasury (/ideas/dao-foundation-ip-asset-transfer) . - Funds network operations (/ideas/dao-validator-subsidy-future) and market making (/ideas/dao-market-making-listings) . Sources - Radix DLT Official – budget-horizon discussion (https://t.me/radix_dlt/995033) - Governance tools and processes needed (https://radixtalk.com/t/governance-tools-and-processes-needed/2119) ## Community WG · Migrate Radix developer documentation to radix.wiki URL: https://radix.wiki/ideas/dao-migrate-dev-docs-wiki Updated: 2026-09-01 Summary: Foundation-hosted developer documentation needs a durable, community-owned home. The RFC (25 replies) proposes migrating it to radix.wiki so docs surv… Working Group Community WG Governance Phase Phase 2 – activity-triggered Champion bayezien Origin RFC – Migrate Developer Docs to RADIX.wiki (https://radixtalk.com/t/rfc-migrate-radix-developer-documentation-to-radix-wiki/2175) Foundation-hosted developer documentation needs a durable, community-owned home. The RFC (25 replies) proposes migrating it to radix.wiki so docs survive the Foundation wind-down and can be maintained by the community. Deliverables - Agree scope and structure for the docs migration. - Port and cross-link developer documentation onto radix.wiki. - Assign ongoing maintainership. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Preserves resources at risk in the Foundation handover (/ideas/dao-foundation-ip-asset-transfer) . Sources - RFC: Migrate Radix Developer Documentation to RADIX.wiki (https://radixtalk.com/t/rfc-migrate-radix-developer-documentation-to-radix-wiki/2175) ## Marketing WG · Fund marketing narrative & the merch revenue-gap program URL: https://radix.wiki/ideas/dao-marketing-merch-revenue Updated: 2026-09-01 Summary: The Strategic Council RFC assigns positioning, narrative, and campaign coordination to a Marketing lead. A concrete early initiative is a merch progra… Working Group Marketing WG Governance Phase Phase 2 – activity-triggered Champion Phil Gibson Origin Strategic Council – Marketing (https://radixtalk.com/t/rfc-radix-strategic-council/2266) · Merch RFC (https://radixtalk.com/t/rfc-merch-to-mitigate-structural-revenue-gap/2169) The Strategic Council RFC assigns positioning, narrative, and campaign coordination to a Marketing lead. A concrete early initiative is a merch program proposed to help mitigate the DAO's structural revenue gap. Deliverables - Elect a Marketing lead and agree the narrative/positioning. - Launch the merch program as a small revenue stream. - Coordinate campaigns with BizDev and Community WGs. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - May merge with Partnerships (/ideas/dao-partnerships-integrations) into a BizDev WG. Sources - RFC: Radix Strategic Council (Marketing) (https://radixtalk.com/t/rfc-radix-strategic-council/2266) - RFC: Merch to mitigate Structural Revenue Gap (https://radixtalk.com/t/rfc-merch-to-mitigate-structural-revenue-gap/2169) ## BizDev WG · Secure market-making & exchange-listing agreements URL: https://radix.wiki/ideas/dao-market-making-listings Updated: 2026-09-01 Summary: Market making and exchange relationships were Foundation-managed and are named as a core DAO function to budget for (like network liveness). The DAO m… Working Group BizDev & Partnerships WG Governance Phase Phase 2 – activity-triggered Champion Open (RAC to contract) Origin TG thread – MM as core function (https://t.me/radix_dlt/995033) · Strategic Council – Partnerships (https://radixtalk.com/t/rfc-radix-strategic-council/2266) Market making and exchange relationships were Foundation-managed and are named as a core DAO function to budget for (like network liveness). The DAO must take over these commercial relationships and contract professional market makers. Deliverables - Inventory existing MM and exchange relationships inherited from the Foundation. - Vote a dedicated market-making budget (single-purpose, 6–12 month). - Contract market maker(s) through the DUNA's legal representation. - Report liquidity/listing outcomes to the community. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Contracts signed under the Legal Wrapper (/ideas/dao-legal-wrapper-representation) ; funded by operating budgets (/ideas/dao-operating-budgets) . Sources - Radix DLT Official – market-making as a budgeted function (https://t.me/radix_dlt/995033) - RFC: Radix Strategic Council (Partnerships) (https://radixtalk.com/t/rfc-radix-strategic-council/2266) ## Legal WG · Ratify the Legal Wrapper & Representation document URL: https://radix.wiki/ideas/dao-legal-wrapper-representation Updated: 2026-09-01 Summary: A Phase 1 document that bridges the on-chain DAO and the off-chain legal entity – defining who can sign contracts, hold accounts, and represent the DU… Working Group Legal & Formation WG Governance Phase Phase 1 – active at launch Champion Daffy (Shadaffy) Origin Legal/ – Wrapper & Representation (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) Instrument Operating Agreement (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/legal/operating-agreement.md) §9.2 (Legal Signatory), §9.9–§9.12 Latest 16 Aug 2026 – no standalone wrapper document; the function moved into the Operating Agreement, which is executed at formation rather than ratified A Phase 1 document that bridges the on-chain DAO and the off-chain legal entity – defining who can sign contracts, hold accounts, and represent the DUNA to third parties (exchanges, market makers, service providers, regulators). There is no Legal Wrapper & Representation document The document this card asks the community to ratify does not exist, and its absence is structural rather than an oversight. The framework was reorganised around the Operating Agreement in May 2026 – the commit message reads "Restructure framework: OA-first hierarchy" – and the wrapper function went into that instrument. The ratification set (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/README.md) lists twenty-one documents that GP-PRE-1 (/ideas/dao-adopt-phase1-governance-docs) puts to the community, and a legal wrapper policy is not among them. The distinction matters for how this card can ever be closed. The Operating Agreement (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/legal/operating-agreement.md) , the Certificate of Formation and the BOIR template are, in the framework's own words, "executed and filed by the Transition RAC at formation (not 'ratified' by the community vote)." The community's leverage over representation authority is therefore indirect: it ratifies the Charter and the policies the Operating Agreement recognises, and the Operating Agreement gives that framework legal effect from the transferor's side of the arrangement. Where the representation authority actually lives Article IX of the Operating Agreement creates the office this card describes. Clause 9.2 has the Transition RAC designate a Legal Signatory by written resolution, and after the Transition Period the office passes to whoever the Charter or a valid governance decision designates. The Legal Signatory may execute contracts, transfer documents, custody documents and regulatory filings on the Company's behalf, act as its legal representative for entity-maintenance and compliance, sign the notices and certifications needed to give effect to a governance decision or keep the Company in good standing, and conduct legal proceedings where authorised. The clause then does something the card's framing would not predict: it states that the Legal Signatory shall act only within the authority conferred by the agreement, the Charter and a valid governance decision, and shall not, merely by holding the office, be treated as a manager of the Company. The signature is a delegated act, not a seat of control – which is the point of the whole exercise for an entity that intends to end up algorithmically governed. Contracting limits sit alongside it rather than in a policy of their own. Clause 9.12 makes the transfer, assignment or exclusive licensing of core intellectual property, repositories, domains or critical web2 credentials a protected matter, together with the disposal of material treasury assets and any movement outside approved custody – each requiring unanimity of the seated Transition RAC signers where an ordinary treasury action clears at 2-of-3 (§9.11). Three documents in the ratified set carry the rest of the mapping: the Treasury Signers Rules, the RAC Mandate and the On-Chain Identifiers & Verification Policy, the last of which is the record Activation Condition 5 checks the governance component and official venues against. Deliverables - Ratify the Legal Wrapper & Representation policy – no such document; the wrapper is the Operating Agreement, executed and filed at formation. - Ratify the pieces that are in the GP-PRE-1 set: Treasury Signers Rules, RAC Mandate, On-Chain Identifiers & Verification Policy. - Designate the Legal Signatory by Transition RAC written resolution under §9.2, and publish the resolution. - Confirm the contracting-authority limits the community relies on are the §9.12 protected matters, and that nothing outside them binds the DAO without a governance reference. Dependencies & cross-references - Operative repository: Shadaffy/radix-dao-governance (https://github.com/Shadaffy/radix-dao-governance) . The reference library (https://github.com/Shadaffy/radix-dao) holds working drafts and activation history. - Nested under DUNA incorporation (/ideas/dao-incorporate-duna-llc) ; the Legal Signatory has nothing to sign for until the Company exists. - Enables market-making and listing agreements (/ideas/dao-market-making-listings) , and is the signing side of the Foundation asset transfer (/ideas/dao-foundation-ip-asset-transfer) . - Thresholds shared with the treasury multisig card (/ideas/dao-treasury-multisig-signers) . Sources - Operating Agreement – Article IX (Legal Signatory, signers, protected matters) (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/legal/operating-agreement.md) - Governance framework pending adoption – ratification set vs. formation instruments (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/README.md) - RFC – DAO Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) - Charter (governing law) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) ## NetOps WG · Recruit & support community validators URL: https://radix.wiki/ideas/dao-grow-validator-set Updated: 2026-09-01 Summary: Community members note the active validator set has fallen below ~100 and ask whether Radix needs more validators. Decentralization and liveness benef… Working Group Network Operations WG Governance Phase Phase 2 – activity-triggered Champion Open Origin TG thread – "we're less than 100 now" (https://t.me/radix_dlt/995033) Community members note the active validator set has fallen below ~100 and ask whether Radix needs more validators. Decentralization and liveness benefit from a larger, healthier set – but new operators hit friction (e.g. corrupt ledger snapshots, long sync-from-scratch times). Where it stands (August 2026) Read whole from the mainnet Gateway on 16 August 2026 at epoch 335598, the validator set does not support the premise that it has fallen below 100. There are 287 validator components on the ledger, 188 of them registered, and 179 of those carry stake – comfortably more than the 100 slots (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) the protocol fills each epoch by stake. The set is full. The thinness is further down. Of 4,773,496,229 XRD staked, ranks 101 to 179 hold 148,854 XRD between them – three thousandths of one percent – and the bottom of the active set is barely above that: rank 99 is a node whose own on-ledger name reads co:integrate Node Closing Jan 2025 – Please Unstake, with 56,171 XRD, and rank 100, betahk.io, holds 45,500. Only 89 validators hold a million XRD or more. So a slot is available to a new operator on almost no stake, and worth almost nothing when they get it. That reframes what recruitment has to deliver. Registered nodes are already in surplus; what a new operator lacks is enough delegated stake behind the slot to pay for the hardware. It also ties this card tightly to the subsidy decision (/ideas/dao-validator-subsidy-future) , since the subsidy is what currently makes a small slot viable at all. Deliverables - Assess target validator-set size and geographic distribution. - Fix onboarding friction: reliable ledger snapshots and clear sync guidance. - Stand up / point to a node-runner support channel. - Consider incentives for new independent operators (tie-in to subsidy design). Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Interacts with subsidy design (/ideas/dao-validator-subsidy-future) . Sources - Radix DLT Official – validator-count discussion (https://t.me/radix_dlt/995033) ## Legal WG · Execute IP & asset transfer from the Radix Foundation URL: https://radix.wiki/ideas/dao-foundation-ip-asset-transfer Updated: 2026-09-01 Summary: The Charter names the Foundation the "Founding Transferor." For the DAO to actually run Radix, brand, trademarks, code repositories, domains, and trea… Working Group Legal & Formation WG Governance Phase Transition (pre-DAO) Champion Open (with Radix Foundation) Origin Founding Transferor (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) · Questions to the Foundation (https://radixtalk.com/t/questions-to-the-foundation/2122) Instrument Operating Agreement (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/legal/operating-agreement.md) Art. IX · Sch. 5 conditions 8–9 Latest 16 Aug 2026 – the handover is written into the Activation Conditions, with a named safe harbour for Foundation-attributable delay The Charter names the Foundation the "Founding Transferor." For the DAO to actually run Radix, brand, trademarks, code repositories, domains, and treasury assets must be transferred from the Radix Foundation (/ecosystem/radix-foundation) to the DUNA. A recurring community concern is that the treasury size and asset inventory remain unknown. The handover is now an activation condition What was an open discussion in July has a written mechanism. The Operating Agreement (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/legal/operating-agreement.md) – the master legal instrument of Radix DAO LLC, filed by the Transition RAC at formation – makes the transfer two of the ten Activation Conditions in Schedule 5, the checklist that decides when the DAO stops being advisory and becomes binding: - Condition 8 – the Continuity Statement(s) required under Article IX have been executed. Evidence: the executed statements, recorded under clause 9.14. - Condition 9 – the principal asset-transfer steps have been completed or formally initiated by the Asset Transferor. Evidence: written confirmation from the Asset Transferor. Both are marked as depending on a third party, and that party is the Foundation. Six of the ten conditions carry an external dependency – the Registrar of Corporations for formation, the Registrar and registered agent for the BOIR filing, the KYC provider, the custody provider, and the Foundation twice. The remaining four, including the ratification vote (/ideas/dao-adopt-phase1-governance-docs) and the Permanent RAC election (/ideas/dao-elect-permanent-rac) , are the DAO's own to satisfy. Condition 9 is worth reading twice. The bar is not a completed handover but one formally initiated, evidenced by the Foundation's own written confirmation. Activation can therefore arrive with assets still in flight – which is a deliberate choice to stop an incomplete transfer from holding the whole DAO in transition indefinitely, and a reason the inventory question this card raises does not answer itself at activation. What may be transferred, and on whose word Article IX sets the receiving side. Clause 9.4 lists what the Company may take: crypto-assets, stablecoins, fiat, web2 credentials, repositories, domains, contractual rights, intellectual property rights, and other assets or control positions, all under approved transfer documentation. Clause 9.3 has the Legal Signatory execute a continuity statement "in substantially the form required by the Founding Transferor" – the transferor sets the form. Clause 9.5 states the diligence posture plainly: the Company receives assets in good-faith reliance on the transferring party's representations, without prejudice to its rights or remedies should those representations prove inaccurate or misleading. There is no independent verification step written into the agreement. On the inventory question this card asks, that is the answer as drafted – the DAO takes the Foundation's account of what it is receiving, and keeps its remedies. Once received, the assets are fenced. Clause 9.12 makes transfer or disposal of material treasury assets a protected matter, alongside movement outside approved custody, and transfer, assignment or exclusive licensing of core intellectual property, repositories, domains or critical web2 credentials – each requiring the unanimous signing threshold of the seated Transition RAC rather than the 2-of-3 that clears ordinary treasury actions. Clause 9.8 also anticipates that the custody arrangement and control structure may be documented on a confidential basis where the Founding Transferor requires it, which cuts directly against the published-balance deliverable below. The safe harbour, and the reporting duty attached to it Clause 8.7 is titled "Foundation-Dependency and External Delay – Safe Harbour", and it is the clearest statement in the framework of who is answerable for a slow handover. Delay attributable to the timing or progress of the Asset Transferor's process, to a regulatory requirement it imposes as a condition of transfer, or to anything else outside the Transition RAC's reasonable control, is not a breach by the RAC and does not affect its standing or authority while the delay lasts. The safe harbour is not free. Where it applies, the Transition RAC must publish a brief written explanation to the Official Venue within 14 days of becoming aware that the dependency is affecting the timeline, and must then update the community at intervals of not less than once every 30 days for as long as the dependency continues. That converts an open-ended wait into a dated, checkable obligation on the DAO's side of the table. Clause 8.5 fences the discretion from the other direction. Once the evidential proofs for all ten conditions are in the RAC's possession it has no discretion to delay publishing the Activation Statement, and no discretion to delay initiating the Activation Vote within 14 days of that publication; failure is expressly a breach. A condition can be waived only at the entrenched-provision amendment threshold, with the basis and the authorising decision recorded in the Activation Statement. Deliverables - Obtain a full inventory of Foundation-held assets (IP, trademarks, domains, code, XRD/stablecoin balances). Not provided for in the agreement, which relies on the transferor's representations (§9.5). - Execute the Continuity Statement and the transfer documentation – Activation Conditions 8 and 9. - Sequence the handover against the P3 Foundation Services (https://radixtalk.com/t/action-on-p3-foundation-services/2238) wind-down. - Publish the received treasury balance so the DAO can budget against real figures – subject to the confidentiality the Founding Transferor may require under §9.8. - Hold the 14-day and 30-day reporting duty under §8.7 to account once a dependency is live. Dependencies & cross-references - Operative repository: Shadaffy/radix-dao-governance (https://github.com/Shadaffy/radix-dao-governance) . The reference library (https://github.com/Shadaffy/radix-dao) holds working drafts and activation history. - Depends on DUNA incorporation (/ideas/dao-incorporate-duna-llc) – there is no transferee until the Certificate of Formation is filed. - Feeds operating budgets (/ideas/dao-operating-budgets) and XRD custody (/ideas/dao-xrd-custody) ; the protected-matter thresholds are the ones set in the treasury multisig card (/ideas/dao-treasury-multisig-signers) . Sources - Operating Agreement – Article VIII (activation), Article IX (asset transfer, treasury, custody), Schedule 5 (activation conditions) (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/legal/operating-agreement.md) - Governance framework pending adoption – the activation sequence (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/README.md) - Action on P3 Foundation Services (https://radixtalk.com/t/action-on-p3-foundation-services/2238) - Questions to the Foundation (https://radixtalk.com/t/questions-to-the-foundation/2122) ## Governance WG · Elect the Permanent RAC URL: https://radix.wiki/ideas/dao-elect-permanent-rac Updated: 2026-09-01 Summary: The current RAC is an explicitly time-bound Transition RAC . The DAO must elect a Permanent RAC to act as trustees who action the community's will – a… Working Group Governance WG Governance Phase Transition (pre-DAO) Champion Open (Transition RAC to facilitate) Origin Radix Accountability Council (/ecosystem/radix-accountability-council) · TG thread (https://t.me/radix_dlt/995033) Latest 26 Aug 2026 – the election has a proposal, GP-ELECT-1, still a draft scaffold. Five seated members is the activation floor, KYC before seating is mandatory, the ballot must open within 90 days of ratification, and the term is six months. Counters still 0 at epoch 338,336 The current RAC is an explicitly time-bound Transition RAC. The DAO must elect a Permanent RAC to act as trustees who action the community's will – appointing contributors and agreeing contracts for marketing, business development, market making, and wallet/engine development. Community discussion frames the role as high-level (like a company board on a 6–12 month budget horizon), initially unpaid, with paid roles requiring a separate community vote. Where it stands (August 2026) Nominations opened before the process did. On 15 July 2026 Timan Rebel posted an RFP self-nominating for the permanent RAC (https://radixtalk.com/t/rfp-self-nomination-for-the-permanent-radix-rac/2313) , and several other community members put themselves forward in that thread and in a parallel volunteer delegate-candidate RFP (https://radixtalk.com/t/rfp-volunteer-delegate-candidate-on-the-permanent-rac-of-the-radix-midao/2312) carrying a business and finance remit. Both threads were still drawing replies at the end of July. What did not exist was the machinery to hold the vote. The Consultation app instance in use through July handles temperature checks and proposals but not elections; the DAO-dedicated instance announced on 4 August (/ideas/dao-governance-app-consultation-v2) is the first build extended to support them, by the same Timan Rebel standing as a candidate. That places this card behind the Constitutional Proposal (/ideas/dao-adopt-phase1-governance-docs) in the queue, since the constitutional vote is the new instance's first job. The 13 August 2026 RAC update The Transition RAC's status update of 13 August 2026 (https://t.me/RadixAccountabilityCouncil/911) settled three of this card's open parameters and left the fourth – a date – open. The council will seat seven members. At least seven people have already declared a willingness to stand, there is no cap on candidates, and the council encourages more to come forward on the grounds that a contested field is the point. The election cannot open until the Charter (/ideas/radix-network-dao-charter) is ratified, because the Charter is where the election's process and conditions are set – so this card sits behind ratification, which in turn waits on Consultation V2 (/ideas/dao-governance-app-consultation-v2) . No date is attached to any of the three. The ballot will use Majority Judgment (https://en.wikipedia.org/wiki/Majority_judgment) , which the council confirms is being implemented into the Consultation dApp for this election. Every voter grades every candidate on one shared scale, and seats go by the strength of a candidate’s grade across the whole electorate rather than by who is named on the most ballots. Textbook Majority Judgment settles that grade at the median; the Radix implementation does not, and pins it instead to a stated fraction of turnout. Under Proposal & Voting Framework (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/proposal-and-voting-framework.md) §6.2.4 a candidate's grade is the highest one that three-fifths of the voting power cast placed them at or above, the same share-of-turnout test the framework's other mechanism applies at its approval threshold. The framework calls that point the Grade Quantile and says in terms that it is not the median. Most of the electorate will not have met the method before, and the council asks candidates and voters to raise doubts about how it works ahead of the ballot rather than during it. The mechanism is deployed and has never been run. The governance component (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) the framework routes through carries a majority_judgment_elections key-value store with its own counter, and read live at epoch 334782 on 14 August 2026 that majority_judgment_election_count is 0, as are proposal_count and temperature_check_count. See Radix governance (/contents/tech/core-concepts/radix-governance) for how that component relates to the earlier Consultation instance the transition votes have actually run on. The election's own parameters, read from the ledger (23 August 2026) The terms this election will run under are now on-chain, and they add two conditions the framework text does not state. Among the five parameter sets written into the governance component (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) on 12 August 2026 is one keyed dao-election and labelled Majority Judgement Election, and it is the only entry of the five that does not use the ordinary proposal shape. Its temperature-check stage runs 3 days rather than five, at the same 405,249,777 XRD quorum and 50% approval as everything else. The election itself runs 7 days at a quorum of 945,582,814 XRD – the Governance Process tier, not the constitutional one – and carries a minimum_median_grade of Good. That grade floor is the first addition. Seats go to the strongest qualifying grades; the deployed parameters also set an absolute bar, so a candidate whose qualifying grade lands below Good is not seated on the strength of being the best of a weak field. The second is what happens when the bar is not cleared: the set carries a 14-day rerun at the same quorum and the same minimum median grade, and a 90-day reserve list. A tie has an explicit path too – record_majority_judgment_tie_resolution takes an ordered list of candidates and writes it to the ledger, so a resolution is published rather than merely announced. Every step of the machinery is owner-gated. Opening an election, starting round one, starting a rerun and recording a tie resolution are all restricted to the holder of the Consultations Admin Badge, as set out on the Consultation v2 card (/ideas/dao-governance-app-consultation-v2) ; only vote_on_majority_judgment_election, which takes an account, an election, a round and a set of candidate grades, is public. Read live at epoch 337,473 on 23 August 2026, majority_judgment_election_count is still 0. The rules are set, the front end is live at vote.radixdao.org (https://vote.radixdao.org) , and the ballot has not opened, because the ratification this card sits behind has not been put. The election has a proposal now, and it is a scaffold (26 August 2026) The vote exists as a numbered document. GP-ELECT-1, Permanent RAC Election (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/GP-ELECT-1-Permanent-RAC-Election.md) sits in the DAO’s operative governance repository, and its own first line calls it a draft scaffold that is not ready for submission. It places itself third in a four-step founding sequence: framework ratification (/ideas/radix-network-dao-charter) , formation, this election, then the Activation Vote. Seating the council satisfies Activation Condition 7 of the Operating Agreement and is a precondition of the fourth step. It does not end the transition. The Transition Period ends on the Activation Date, when the Activation Vote passes, so a seated Permanent RAC will sit for a while alongside a company that is still member-managed and a governance process whose outcomes are still advisory. Two points in the document correct what this card said above. The mechanism is not a choice anyone makes: Majority Judgment is the default under the Elections and Role Governance Policy, the Transition RAC has no power to depart from it, and running the two-stage alternative instead would take a separate Governance Process proposal in force before the nomination window opens. And grades do not settle at a median. The framework names the settling point the Grade Quantile, fixes it at three-fifths of the voting power cast, and records it as counting mechanics rather than a threshold, so it cannot be tuned from one election to the next. The contract deployed to mainnet still names its floor minimum_median_grade; the rulebook that floor answers to calls the same quantity the MJ Minimum Qualifying Grade and sets it at Good. Four gates the rulebook puts on the seat The DAO Parameters Registry (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/parameters/dao-parameters-registry.md) §3A.5 attaches four conditions to this election, and not one of them is on the ballot. - Five seats, not seven, is the bar for activation. The council intends seven. §5.1 sets the Permanent RAC at between five and seven, fixed per election, with a floor of five, and §3A.5 requires five members duly elected and formally seated before the Activation Vote can be put. - KYC before seating is mandatory. Every elected member must complete Tier 1 verification before taking the seat, to satisfy the Operating Agreement’s definition of Seated and the §114(1)(d) natural-person-control requirement that comes with the DUNA wrapper (/ideas/dao-incorporate-duna-llc) . Winning the vote is not the same as holding the seat. - The election must open within 90 days of ratification. The registry gives the reason in its own description: so the election cannot be stalled. The clock starts when the framework is ratified, not when the council is ready. - Seating comes before the Activation Statement. Members must be seated before the Transition RAC publishes the document recording every Activation Condition as met. Two more numbers sit in §6B and bear on who will stand. The term is six months, renewed automatically unless challenged inside a 14-day window that opens 21 days before expiry, and a challenge can be filed by anyone holding 0.1% of eligible voting power. Continuous service in one role is capped at four consecutive terms, two years, after which a full election is mandatory. The counters have not moved. Read live at epoch 338,336 on 26 August 2026, the governance component (https://dashboard.radixdlt.com/component/component_rdx1cp90ys553uwxuckev249x5wezucqru0u4qr7qdxdc9tlpmnh93242k) still reports majority_judgment_election_count, proposal_count and temperature_check_count at 0. That is 3,554 epochs after this card’s first reading on 14 August and 863 after its second on 23 August, with nothing put to the component in between. Deliverables - Agree council size and mandate (build on the 5-member approval-vote precedent; some argue 7). - Run the election via the ratified RFC → TC → RFP process and the governance app. - Define the boundary between "community will at a high level" and RAC operational discretion within approved budgets. - Set conflict-of-interest and (un)paid-role rules before seating members. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Seats the body that holds interim RFP authority until Working Groups activate (/ideas/dao-working-group-framework) . - Governance context: Radix Governance hub (/contents/tech/core-concepts/radix-governance) . Sources - Radix DLT Official – DAO/RAC discussion (2026-07-11) (https://t.me/radix_dlt/995033) - RDD structure & no-confidence mechanics (https://radixtalk.com/t/proposed-initial-governance-structure-for-the-radixdlt-dao-duna-rdd/2127) ## Community WG · Appoint moderators across social channels URL: https://radix.wiki/ideas/dao-community-moderators Updated: 2026-09-01 Summary: The Telegram thread calls for "more robust modding of this channel to block personal abuse or trolling" and to keep the space positive and forward-loo… Working Group Community WG Governance Phase Phase 2 – activity-triggered Raised by Vlad, 21 January 2026 (https://radixtalk.com/t/community-mods-for-radix-social-channels-tg-discord-reddit-etc/2158) Owner Unclaimed Origin Community Mods RFC (https://radixtalk.com/t/community-mods-for-radix-social-channels-tg-discord-reddit-etc/2158) · TG thread – "more robust modding" (https://t.me/radix_dlt/995033) The Telegram thread calls for "more robust modding of this channel to block personal abuse or trolling" and to keep the space positive and forward-looking. The RFC proposes appointing community moderators across Telegram, Discord, Reddit, and other channels under DAO stewardship. Nobody has taken this on (28 August 2026) This card recorded Vlad as its champion and its assignee because he opened the RadixTalk thread (https://radixtalk.com/t/community-mods-for-radix-social-channels-tg-discord-reddit-etc/2158) on 21 January 2026. Opening it is the whole of what the source establishes. In his own third post, on 22 January, he asked the channel to “add more self nominations here” rather than nominating himself, and the thread drew one, from M.Ryland_Co, who offered to assist existing moderators through the transition. Reading this board in the Radix DLT Official Telegram (https://t.me/radix_dlt/999847) on 28 August 2026, Vlad said of this card that he did not know where it came from (https://t.me/radix_dlt/999854) . The assignment has been removed. The proposal stands; the role is open, and mapping the existing moderators – Vlad’s own suggestion for the transition period – is the cheapest first step in it. Deliverables - Define a moderation policy aligned with the Code of Conduct. - Appoint / elect moderators per channel. - Establish escalation and appeals. Dependencies & cross-references - Governed by Daffy's Radix DAO framework (https://github.com/Shadaffy/radix-dao) (repo Shadaffy/radix-dao); see the Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) and Charter (Round 1) (https://radixtalk.com/t/rfc-dao-documents-round1-the-charter/2269) . - Enforces the Code of Conduct (/ideas/dao-coi-code-of-conduct) . Sources - Community Mods for Radix Social Channels (https://radixtalk.com/t/community-mods-for-radix-social-channels-tg-discord-reddit-etc/2158) - Radix DLT Official – moderation discussion (https://t.me/radix_dlt/995033) ## Governance WG · Adopt Conflict-of-Interest Policy & Code of Conduct URL: https://radix.wiki/ideas/dao-coi-code-of-conduct Updated: 2026-09-01 Summary: Because contributors may be paid by the DAO for work they also vote on, integrity rules are Phase 1. In the Telegram thread a contributor stressed: "d… Working Group Governance WG Governance Phase Phase 1 – active at launch Champion Daffy · Saul Origin CoI §3.2 / §7 · Code of Conduct (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) Documents Conflict of Interest Policy (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/conflict-of-interest-policy.md) · Code of Conduct (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/code-of-conduct.md) Latest 5 Aug 2026 – both policies drafted and folded into the GP-PRE-1 ratification set; neither is voted on separately Because contributors may be paid by the DAO for work they also vote on, integrity rules are Phase 1. In the Telegram thread a contributor stressed: "document the conflict of interest and stay away from decisions or payment to yourself." Saul proposed mandatory disclosure for any entity controlling >10% of token supply. Both documents are written The two policies this card asks for are drafted and sitting in the ratification set. The Conflict of Interest Policy (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/conflict-of-interest-policy.md) (16,206 bytes) and the Code of Conduct (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/code-of-conduct.md) (13,068 bytes) both last took substantive edits on 5 August 2026, in a commit titled "close the workbook review findings for ratification." They live in Shadaffy/radix-dao-governance, the operative repository, not in Shadaffy/radix-dao, which the framework's own index (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/README.md) describes as the reference library of working drafts and activation history. Neither policy gets its own vote. Under the GP-PRE-1 constitutional ratification proposal (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/GP-PRE-1-Framework-Ratification.md) , the community ratifies the Charter, the DAO Parameters Registry and nineteen operational policies as one set – twenty-one documents, one YES. The Conflict of Interest Policy and the Code of Conduct are two rows in that table, which means this card is not a separate ballot item but part of the Phase 1 governance document set (/ideas/dao-adopt-phase1-governance-docs) . A YES on GP-PRE-1 satisfies Activation Condition 6 of the Operating Agreement; it does not form the entity and does not make governance binding, which happens only at the Permanent RAC election (/ideas/dao-elect-permanent-rac) and the Activation Vote that follow it. The >10% threshold was considered and refused The deliverable this card carried from the Telegram discussion – a disclosure mandate triggered at >10% of token supply – is not in the drafted policy, and its absence is deliberate. On what makes a financial interest material, §3.1 states that "there is no numeric threshold, and none is set in DAO Parameters," on the grounds that a figure would need calibrating against operating history the DAO does not have and against volatile token valuations, and would authorise non-disclosure beneath it. Disclosure is set wider still: §4.1 requires covered persons to declare all current financial interests in ecosystem entities, with no threshold at all. The policy separates the two bars on purpose. Everything is disclosable; only a material interest forces recusal. Its reasoning is that disclosure is cheap and reversible where recusal costs the DAO a decision-maker, so the expensive act carries the higher bar – and that an undisclosed interest is one nobody but its holder can ever raise. The scope is role-based rather than holdings-based: RAC members, Treasury Signers, Working Group stewards with budget or execution authority, and contractors acting in a decision-making capacity. Token holders casting ordinary votes are outside it entirely. Two provisions answer the transition directly. §3.5 treats consolidation of delegated functions – the same person elevating a proposal and then executing the treasury action it authorises – as a declaration duty rather than a recusal trigger, because a recusal reading would drop the RAC below its own non-recused floor and make routine oversight unperformable. §7 requires anyone who holds, or has held within three years, equity, a paid role or non-trivial token compensation from a predecessor entity with a material relationship to Radix to register that as a standing conflict, and to recuse from decisions that would benefit those entities or their former principals. Reporting and enforcement already have a path The enforcement route this card listed as undefined is set out in Code of Conduct §5 and §6. Reports go to the RAC through a designated channel, or to the Governance & Legal WG where the report concerns a RAC member; reporter identity is protected where disclosure would put them at risk, anonymous reports are accepted with the caveat that they limit what can be investigated, and retaliation against a good-faith reporter is itself prohibited conduct. On the Conflict of Interest side, §10 gives the RAC 30 days to investigate and issue a finding, with the accused heard before it is issued, and remedies that run from invalidating the tainted decision to a governance proposal to recover misappropriated funds. Sanctions are graded – warning, temporary suspension, recommendation of removal from role, permanent exclusion – and the thresholds are graded with them: a warning or suspension goes under the RAC's routine decision rule, while permanent exclusion and any interim suspension require the emergency threshold. Permanent exclusion carries an appeal whether or not one is brought: where nobody appeals within 14 days, the exclusion is still referred for determination under the Dispute Resolution & Arbitration Policy before it takes effect. No sanction reaches the vote The sharpest line in either document is a limit the Code of Conduct places on itself. §6.3 states that no finding, sanction or interim measure affects a governance participant's eligible voting power, their entitlement to cast a vote, or the counting of a vote already cast. Suspension covers forums, calls, working groups, repositories, grant and compensation processes and candidacy for role – not voting. The reason given is constitutional rather than charitable. Charter §12.1 entrenches XRD and LSU (/contents/tech/core-concepts/liquid-stake-units) as eligible sources of voting power for all DAO governance votes, and Charter §13 voids a conflicting policy provision to that extent – so a code-of-conduct sanction that tried to disenfranchise someone would be unenforceable rather than severe. A DAO whose franchise is defined on-ledger cannot take it away in a moderation decision, and this policy says so rather than leaving it to be discovered. Deliverables - Draft the Conflict of Interest Policy and the Code of Conduct – both written, last revised 5 August 2026. - Ratify both as part of the GP-PRE-1 document set (not as separate votes). - Add the >10% token-supply disclosure mandate – declined in §3.1 in favour of no threshold for materiality and no threshold for disclosure. - Define enforcement and the ethics-reporting path – Code of Conduct §5–§6 and CoI §10. - Stand up the machinery the documents assume: a designated reporting channel, a public record for conflicts disclosures, and the RAC seats that receive both. Dependencies & cross-references - Operative repository: Shadaffy/radix-dao-governance (https://github.com/Shadaffy/radix-dao-governance) , pending/governance/. The reference library (https://github.com/Shadaffy/radix-dao) holds working drafts and activation history. - Ratified inside the Phase 1 governance document set (/ideas/dao-adopt-phase1-governance-docs) ; gates paid roles referenced in the Permanent RAC (/ideas/dao-elect-permanent-rac) and WG stewardship (/ideas/dao-working-group-framework) . - Enforcement depends on the RAC existing to receive reports, so nothing here bites before the election (/ideas/dao-elect-permanent-rac) . Sources - Conflict of Interest Policy (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/conflict-of-interest-policy.md) · Code of Conduct (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/governance/code-of-conduct.md) - Governance framework pending adoption – ratification set and activation sequence (https://github.com/Shadaffy/radix-dao-governance/blob/master/pending/README.md) - RFC – DAO Governance Framework Reference Repo (https://radixtalk.com/t/rfc-dao-governance-framework-reference-repo/2268) - TG thread – conflict-of-interest guidance (https://t.me/radix_dlt/995033) ## World Cup Badge Arena URL: https://radix.wiki/ecosystem/world-cup-badge-arena Updated: 2026-09-01 Summary: World Cup Badge Arena was a free-to-play prediction and collectibles game built on Radix for the 2026 FIFA World Cup, played across the tournament's r… Type Prediction Game / NFT Collectibles Status 🟠 Dormant – season complete Season FIFA World Cup 2026 (11 June – 19 July 2026) Category Game / NFT Network Radix Mainnet Assets Passport NFT + sealed match-call cards Minted 42 Passports · 1,009 sealed cards Last on-ledger activity 19 July 2026 Overview World Cup Badge Arena (https://worldcupbadgearena.xyz) was a free-to-play prediction and collectibles game built on Radix (/contents/tech/core-protocols/radix-engine) for the 2026 FIFA World Cup, played across the tournament's run from 11 June to 19 July 2026. Its tagline captures the loop: "Pick the matches. Collect sealed cards. Reveal your World Cup story after the tournament." Players connect the official Radix Wallet (/contents/tech/core-protocols/radix-wallet) via Radix Connect (/contents/tech/core-protocols/radix-connect) , and their Passport NFT anchors their collection on-chain. Play closed with the tournament. The final sealed card was minted at 16:18 UTC on 19 July 2026, roughly three hours before kick-off in the final, and the game component has recorded no committed transaction since. How It Works - Mint a Passport – a Passport NFT anchors the player's collection on Radix. - Make match calls – one Passport can make a single "match call" per fixture before entry closes; each call mints one sealed collectible card. - Post-tournament reveal – final card artwork and ranking were to arrive in a planned v2 once results were complete. That release is still outstanding (see below). - Onboarding – a five-step flow guides new users to install the Radix Wallet, add a little XRD for network fees, connect, mint a Passport, and start calling matches; the app also surfaces a Leaderboard and Standings. Outcome and On-Ledger Record The tournament finalised on 19 July 2026 (https://en.wikipedia.org/wiki/2026_FIFA_World_Cup_final) , Spain beating Argentina 1–0 after extra time (https://www.npr.org/2026/07/19/nx-s1-5899071/2026-world-cup-fifa-argentina-spain-final-championship) . Badge Arena's season closed with it, and the size of that season is a matter of public record: the game runs as a single component, component_rdx1cquh22jqcfwqd0kwa7q06a9wxlpkqfwlp8d4xsq0s5l0qcw4efvs0h, instantiated from the WorldCupBadgeArena blueprint, and every Passport and every sealed card was minted through it. Read from mainnet on 7 August 2026 (epoch 332,911), the ledger totals are 42 Passports (https://dashboard.radixdlt.com/resource/resource_rdx1ng4x9n5jc2za2hcyxxyd8drqk3jp6lscu7lwkjylertxmmj3tszfhs) and 1,009 sealed cards (https://dashboard.radixdlt.com/resource/resource_rdx1n2enj96y6723angppay5jt73que46dglfzsmeygu7fhce3zhelvl2d) – about 24 match calls per player across the 104-fixture tournament. The last Passport, #42, was minted on 18 July 2026; the last card, #1009, the following afternoon. Match administration is gated by a single non-mintable admin badge (https://dashboard.radixdlt.com/resource/resource_rdx1t5w3ttsdnrp4gk559q0uwfvzkhlff47ulutzdazls0f8dmplx3g264) . The promised reveal has not shipped. As of 7 August 2026 the site still describes final artwork and ranking as arriving "in v2 after results are complete", and no transaction has touched the component in the nineteen days since the final. What holders keep is unaffected either way: both collectible resources were created with their burner, freezer and recaller rules (/contents/tech/core-concepts/resources) set to deny_all and locked, so nobody – the project included – can burn, freeze or claw back a card. A sealed card stays in the account that earned it whether or not a v2 ever arrives. External Links - World Cup Badge Arena – Official Website (https://worldcupbadgearena.xyz) - Radix Wallet – Download (https://www.radixdlt.com/wallet) - World Cup Badge Arena component – Radix Dashboard (https://dashboard.radixdlt.com/component/component_rdx1cquh22jqcfwqd0kwa7q06a9wxlpkqfwlp8d4xsq0s5l0qcw4efvs0h) ## WhyNot URL: https://radix.wiki/ecosystem/whynot Updated: 2026-09-01 Summary: WhyNot ($WHY) was a community-driven meme coin on the Radix network . It began from a simple prompt – "why don't you create your own meme coin?" – and… Project WhyNot ($WHY) Type Community meme coin Network Radix (https://www.radixdlt.com) Trading Ociswap (/ecosystem/ociswap) Staking DefiPlaza (/ecosystem/defiplaza) Links Linktree (https://linktr.ee/WhyNotXRD) Overview WhyNot ($WHY) was a community-driven meme coin on the Radix network (https://www.radixdlt.com) . It began from a simple prompt – "why don't you create your own meme coin?" – and grew into a community token with no formal team, launched during the wave of native Radix memecoins that followed the Babylon (/contents/tech/releases/radix-mainnet-babylon) smart-contract mainnet. The $WHY token trades on Ociswap (/ecosystem/ociswap) and has offered staking through DefiPlaza (/ecosystem/defiplaza) , with the on-ledger contract viewable via RadixScan (/ecosystem/radixscan) . Project links are aggregated on its Linktree (https://linktr.ee/WhyNotXRD) (X, Telegram, GitBook docs, and a JustLock liquidity lock). Status As of 2026 the project is dormant: its DeFi integrations remain live and most of its published links resolve – though not the Telegram handle, on which see below – but there is no clear sign of ongoing team or community activity. Trading infrastructure persists on-ledger while active development has lapsed. On-ledger status (17 August 2026) The $WHY resource resource_rdx1t4hz8agr8qtkfn7q8prtc0vk99hzmz4mkncewahsysud32220pts3c is intact and frozen in place. Read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 335,887 on 17 August 2026, it carries a fixed supply of 999,000,000, minting is denied, and its authority rules are locked – so no one can mint, freeze or recall it, including whoever created it. Nothing has moved for over a year. The most recent transaction to affect the resource is txid_rdx13s98epl74n5…wlf5q526zmq, committed 5 June 2025, a transfer of 1,000,000 $WHY out of a single account. Its Ociswap (/ecosystem/ociswap) pool held about $0.63 of liquidity on the same read, with an identical quoted price over 24 hours and 7 days – the signature of a pool no one is trading against. That is dormancy rather than closure as this wiki uses the terms: the contracts still respond and the website and link page still resolve, but nobody is answering for them – and one published link has decayed to a username nobody holds. The definitions are set out on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) . The Telegram handle in its metadata is unclaimed (30 August 2026) The $WHY resource publishes its own social links on the ledger, and one of them leads nowhere. Read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 339,535 on 30 August 2026, the resource carries social_urls = ["https://x.com/WhyNotXRD", "https://t.me/WhyNotXRD", "https://whynotxrd.gitbook.io"] and, separately, telegram_profile_url = "https://t.me/WhyNotXRD". Telegram answers a lookup of that username with USERNAME_NOT_OCCUPIED: it is not a dormant channel, not a private one, and not a renamed one. Nobody holds it. The web page at that address is the generic contact shell Telegram serves for any unheld name, with no title, no member count and no description. The project’s own Linktree (https://linktr.ee/WhyNotXRD) is still live and still lists the same handle, so a reader arriving from the ledger, from a wallet, from a token aggregator or from the project’s published link page is sent to the same free username. That is the state described in this wiki’s advisory on recycled Telegram handles (/contents/resources/recycled-telegram-handles) , one step before it happens: the ten handles recorded there had already been re-registered by someone else, and this one is still waiting to be. Claiming it costs nothing and would make the claimant the project’s Telegram presence everywhere the handle is cited. The record is correctable, and unlike the supply it is not sealed. metadata_setter on the resource resolves to Owner, the owner rule requires the WhyNot Dev badge (resource_rdx1nf8rqxpce…gun9e0emn4, a non-fungible of supply 1), and that badge, #1#, is unburned. It sits in account_rdx128cc34gfxntn89gh9t2w7m8ul9e33aehtek6yg7627kzwlhylrq3u5, where it has not moved since 6 April 2025, the day before the token was created. The same account is the one the token names in dapp_definitions, and its last transaction of any kind was committed on 13 June 2025. One metadata update from it would repoint or remove the link; the reason none has been made is the reason the page calls the project dormant. ## Weft Finance URL: https://radix.wiki/ecosystem/weft-finance Updated: 2026-09-01 Summary: Weft Finance is a decentralized lending and borrowing protocol built on Radix , written in Scrypto . At the heart of Weft lies the creation and manage… Weft Finance Protocol type DeFi lending & borrowing (money market) Status 🟢 Active – V2 live on Radix mainnet TVL (11 Aug 2026) ≈ $301K (V2 + V1); peak ≈ $14.06M on 29 Mar 2025 – DeFiLlama (https://defillama.com/protocol/weft-finance) Security Exploited 30 Aug 2026 – price feed carried HUG at about 10 million times market, releasing 71M XRD of debt against collateral bought for 70.6 XRD; 27.2M XRD bridged off Radix Positions Wefties – NFT-based collateralized debt positions Token $WEFT – 99,999,000 fixed supply, minting permanently disabled Founded 2022, by Yetinin Coulibaly & Atoumbré Kouassi Built on Radix (/contents/tech/core-protocols/radix-engine) ( Scrypto (/contents/tech/core-protocols/scrypto-programming-language) ) App app.weft.finance (https://app.weft.finance/market) Docs docs.weft.finance (https://docs.weft.finance) X @weft_finance (https://x.com/weft_finance) GitHub weftfinance (https://github.com/weftfinance) Analytics DefiLlama (https://defillama.com/protocol/weft-finance) Weft Finance is a decentralized lending and borrowing protocol built on Radix (/contents/tech/core-protocols/radix-engine) , written in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) . At the heart of Weft lies the creation and management of collateralized debt positions (CDPs) represented by NFTs, known as ‘Wefties.’ It is one of Radix's core money markets, alongside Root Finance (/ecosystem/root-finance) , and interoperates with DEXs such as Ociswap (/ecosystem/ociswap) and CaviarNine (/ecosystem/caviarnine) . Protocol status Weft is the largest lending market on Radix and one of the two largest deployments on the network of any kind. As of 11 August 2026 DeFiLlama (https://defillama.com/protocol/weft-finance) tracked about $296K in Weft V2 and a further $4.7K in the legacy V1 pools, a combined $301K against a Radix-wide DeFi total of roughly $1.07M (https://defillama.com/chain/Radix) — a little over a quarter of everything deposited on the network. Its own peak was $14.06M on 29 March 2025, so the protocol holds a far larger share of a far smaller market than it did a year ago. Its nearest documented peer, Root Finance (/ecosystem/root-finance) , has fallen to roughly $1.2K over the same period. The deposits are in active use rather than stranded: the V2 lending-pool component (https://dashboard.radixdlt.com/component/component_rdx1czmr02yl4da709ceftnm9dnmag7rthu0tu78wmtsn5us9j02d9d0xn) committed 70 transactions in the seven days to 11 August 2026, the most recent at 01:59 UTC that morning — supplies, borrows and repayments in XRD, LSULP and xUSDC. The $WEFT token's supply is settled on-ledger and cannot grow. Read at epoch 333918, the resource (https://dashboard.radixdlt.com/resource/resource_rdx1tk3fxrz75ghllrqhyq8e574rkf4lsq2x5a0vegxwlh3defv225cth3) carries a total supply of 99,999,000 WEFT with the minter rule set to deny_all and marked immutable, and the resource's rules locked; the burner rule is allow_all, so the supply can only ever fall. This is a fixed supply, not a cap the protocol is issuing towards. History Weft was founded by two Ivory Coast engineers, Yetinin Coulibaly and Atoumbré Kouassi. Living in different continents, with Coulibaly in Paris and Kouassi in Abidjan, they came together with a shared vision for financial innovation and economic development in Africa. Their collaboration began in 2021 when both became active members of the Radix Community. Despite having never met, the two engineers discovered a shared vision for the future and a strong alignment in values. After meeting in person in Abidjan in fall 2022, they decided to form a partnership and build their first decentralized application (dApp) for lending and borrowing financial services. This led to the creation of Weft, aiming to harness the transformative potential of RadixDLT for the future of DeFi. The platform is now developed by a team of seven individuals, collectively known as Weft'ers. Weft V2 In 2024 Weft shipped Weft V2, a ground-up rebuild focused on capital efficiency and scale ( announcement (https://medium.com/@weft_finance/announcing-weft-v2-9a7cfe1aa54c) ). V2 adds: - Efficiency Mode – higher borrowing power for correlated assets (e.g. stablecoin-to-stablecoin or XRD-to-LSU pairs). - Isolation Mode – risk-contained markets that let newer or more volatile assets be listed without endangering the core pools. - Advanced collateral – support for Liquid Stake Units (/contents/tech/core-concepts/liquid-stake-units) (LSUs), LSULP, and DEX LP tokens as collateral. - Configuration buffering – parameter changes are staged so existing loans stay stable through re-configuration. V2 lends and borrows XRD, LSULP, xUSDC, WEFT and other Radix ecosystem assets; live markets and rates are on the Weft V2 app (https://app.weft.finance/market) , with protocol metrics tracked on DefiLlama (https://defillama.com/protocol/weft-finance) . Features Weft offers several key features to facilitate lending and borrowing of digital assets: - Lending Pools: Weft utilizes lending pools that hold assets deposited by lenders. Each pool is designated for a specific asset type. Lenders receive deposit units representing their share of the pool. - Loan Units: Borrowed amounts are tracked using loan units, which reflect a borrower's share of debt obligation. Interest accrual is handled through the loan unit system. - Interest Rate Strategies: Interest rates are set dynamically based on lending pool usage through predefined interest rate strategies. This allows rates to adapt to market conditions. - Borrowing Power Delegation: Users can delegate their borrowing power by minting a linked "delegated Weftie" NFT and sending it to another user. The recipient can then borrow without needing collateral. - Liquidations: Loans with insufficient collateral can be liquidated by external entities or automatically. This sells collateral to repay loans and brings loan-to-value ratios back into a healthy range. - User Positions Operations: Weft supports position modifications like collateral swaps and direct loan repayment using collateral ("self-liquidation"). The system is designed to be flexible, secure, and capture the nuances of each loan through use of the non-fungible Wefties. Components Weft Finance relies on several key components to enable its lending and borrowing functionality: Lending Pools - Hold assets deposited by lenders and act as reserves for borrowers - Each pool is for a specific asset type (e.g. $XRD) - Mint deposit units to track lenders' shares - Manage accrued interest on loans - Provide flash loans Lending Market - Acts as the interface between lenders/borrowers and lending pools - Handles borrowing, repaying loans, liquidations, withdrawals - Ensures security through badges and access rules - Validates and extends Wefties to enable pool interactions Wefties - NFTs that contain users' collateral & loan positions - Secure metadata that stores deposit unit collateral amounts and loan unit borrowed amounts - Controls enforced by Lending Market badge $WEFT Token - Last resort protection against market volatility risks - Stakers can deposit $WEFT to mitigate potential insolvencies - Stakers earn a portion of collected fees as insurance premiums This modular architecture maximizes flexibility and security of lending operations. Operations Weft supports several key operations for lenders and borrowers: Lending - Users contribute assets to lending pools - They receive deposit units representing pool shares - Deposit units can be redeemed for assets Borrowing - Validates the Weftie NFT and extends it - Executes borrowing order through pool interactions - Performs health checks on loans and updates Weftie Interest Accrual - Interest rates set dynamically based on pool usage - Accrued by increasing total borrowed amount - Deposit and loan units remain constant Revenue - Collected from loan interest, flash loan fees, liquidation bonuses - Shared between operations costs and insurance module Insurance Module - Accepts staked WEFT tokens - Tokens sold to cover losses in extreme situations - Stakers earn portion of revenue as insurance premium Weft aims to make lending and borrowing as seamless as possible while keeping operations decentralized and secure. Roadmap Weft Finance has laid out a roadmap to drive the growth and adoption of its lending and borrowing platform: Q3 2023 - ✅ Launched validator node, distributing $WEFT tokens to stakers - ✅ Introduced Weft Alpha version on testnets for early feedback Q4 2023 - ✅ Initiated $WEFT token listing and liquidity mining incentives - ✅ Released Beta version on updated testnet after Babylon launch - ✅ Started auditing Scrypto code prior to mainnet - ✅ Launched mainnet MVP after completing audits - ✅ Introduced Weft staking and early adopter incentives 2024 - Planning interface upgrades and mobile app launch - Transitioning towards a DAO model by end of 2024 2024–2025 - ✅ Shipped Weft V2 (https://medium.com/@weft_finance/announcing-weft-v2-9a7cfe1aa54c) – Efficiency/Isolation modes and advanced collateral. - Scaling total value locked and expanding supported assets and liquidity incentives. - Continued progress toward decentralising the protocol into a DAO. The roadmap focuses on iterative community-driven development, testing, and upgrades to eventually decentralize Weft into a DAO. Live protocol metrics are published on DefiLlama (https://defillama.com/protocol/weft-finance) . Team Atoumbré Kouassi With a Master's degree in Applied Statistics and Economy, Kouassi has had a successful career in support service management in Abidjan. A dedicated professional, Kouassi has been following and experimenting with blockchain technology since 2013. His search for an efficient distributed ledger technology led him to discover Radix DLT, which would become the foundation for Weft. Yetinin Coulibaly A master in Embedded Electronics and Industrial Computing, Coulibaly is a lead developer based in Paris. He has a strong entrepreneurial spirit, having instigated a Senegal-based startup that provided digital ticketing solutions for transportation and event sectors. Coulibaly's drive and interest in blockchain technology eventually led him to join the Radix Community and embark on the journey of co-founding Weft. Zivile Community Manager Penifana Frontend Developer Roland Backend Developer Maxence Project Manager Amadou PhD Advisor providing research guidance External Links - Weft Finance – official website (https://weft.finance) - Weft V2 app (https://app.weft.finance/market) - Documentation (https://docs.weft.finance) - @weft_finance on X (https://x.com/weft_finance) - GitHub – weftfinance (https://github.com/weftfinance) - Meet the Project: Weft Finance (Radix blog) (https://www.radixdlt.com/blog/meet-the-project-weft-finance) - DefiLlama – Weft Finance (https://defillama.com/protocol/weft-finance) The 30 August 2026 exploit At 18:02:58 UTC on 30 August 2026 one transaction took 47,280,000 LSULP and 13,100,500 XRD out of the Weft V2 lending pool. The collateral posted against that debt was 539,703.17 HUG (/ecosystem/hug) , a Radix memecoin the same transaction had bought for 70.6 XRD. How it worked The manifest (https://dashboard.radixdlt.com/transaction/txid_rdx12lsyuggs587xt7m9uxjedtkdtz0lcnzh85g2w4x6wwdq3cuyhccs8ls3kc) reduces to seven steps: - Withdraw 70.6 XRD from the account. - Call create_cdp with a bucket holding zero XRD, minting an empty Weftie V2 position, #1138#. - Swap the 70.6 XRD for 539,703.17 HUG on an Ociswap (/ecosystem/ociswap) two-sided pool. - Call flash_remove_collateral on the new position with an empty map. It removes nothing and returns a transient receipt. - Call flash_add_collateral, handing back that receipt together with the whole worktop, which by then holds the HUG. - Call borrow for 47,280,000 LSULP and 13,100,500 XRD. - Deposit the proceeds to the account. The borrow passed Weft's health check. The position it left behind still reads on ledger: 539,703.17 HUG of collateral against 47,202,060.79 LSULP and 11,877,595.35 XRD of loan units. HUG has been a listed collateral on Weft since November 2024, so no unlisted asset was forced into the market. The valuation is what failed, and Weft’s own price cache records it. At the moment of the borrow the market held HUG at 1,330.41 XRD per token. HUG traded that day at 0.000131 XRD, the rate the attacker paid in step 3. On the cached figure the 539,703 HUG scanned as about 718 million XRD of collateral, so drawing 71 million XRD of debt against it cleared the health check at an apparent loan-to-value near 10 per cent. The flash-collateral pair in steps 4 and 5 is not incidental. Weft had disabled HUG as collateral fifteen months earlier, and that pair is the route that did not check. The price feed Weft reads HUG from the feed it registers as "Default PriceFeed" ( component (https://dashboard.radixdlt.com/component/component_rdx1czdvvanvdy6495phfgz8uv6n2semp2cpexcg6vvty6uaycc82adgyv) ), which carries 27 resources. Every other price checked against the market holds up. Read at 19:55 UTC on 30 August the same feed put hWBTC at 92,747,211 XRD, about $78,300 against a market of $79,200, hUSDC at 1,176.45 XRD, about $0.99, and LSULP at 1.2241 XRD. HUG alone sits at roughly $1.07, the band the feed uses for dollar stablecoins, against a real price of $0.000000108. The error is one asset wide and about ten million times deep. It is live rather than stale. The feed refreshed HUG at 19:55 UTC in the same batch as every other asset it carries, and published 1,271.80 XRD. Weft accepts a posted price for four hours after it lands, and CreateCDP was still enabled and unlocked when this was read at 20:00 UTC. It began on 28 August 2026 at 12:35:17 UTC, in an ordinary ten-minute refresh ( transaction (https://dashboard.radixdlt.com/transaction/txid_rdx17mgxz8dlmyzrrtppec9fer4lqfyl38j40skdql9f3xfyw2wvk88qfalnwp) , state version 556,254,628). In the update immediately before it the feed carried HUG at 0.000131085370299542 XRD; in this one it carried 1289.783156723014634465. That first figure is the same to the last digit in every batch sampled between 1 and 28 August, so HUG was a fixed entry rather than a quoted one until this update moved it into the band the feed uses for dollar assets, after which it drifted with them on each cycle. From that write to the borrow is 53 hours and 28 minutes, and 324 further transactions touched the component in between. Each carried a current timestamp, so a consumer checking only staleness would have accepted every one of them; the last, at 17:55:53 on 30 August, published 1,330.41 XRD. The general lesson for builders reading a feed is set out on Oracle Integration (/developers/scrypto/08-oracle-integration) . Where the money went The attacker sold the borrowed LSULP for XRD across a spread of pools in two trades, 47,000,000 LSULP at 18:16 and 277,000 at 18:45, realising 14,103,362 XRD. With the borrowed XRD that comes to 27,203,791 XRD, about $23,000 at the Ociswap spot price of $0.000844 that evening. Selling into thin liquidity cost about half the value. CaviarNine (/ecosystem/caviarnine) ’s LSULP traded at 0.905 XRD that evening, which puts the borrowed assets at roughly 55.9 million XRD, and the attacker realised 27.2 million by pushing 47 million LSULP through a book that could not absorb them. The proceeds left Radix through a Hyperlane Warp Route (https://dashboard.radixdlt.com/component/component_rdx1crrj42g0855jnpvfs6t9tff25vtq3lm292g3h07xrnz9l49mnsu3hy) in four transfers between 18:06 and 18:47: 13,000,000 XRD, then 133,000, then 14,000,000, then 102,000. Three further attempts to move 14,000,000 XRD failed on insufficient balance at 18:21. The account (https://dashboard.radixdlt.com/account/account_rdx129ttjjx95zlmqlcnwd4rvrepjz2lry4rhwsph5xjtjhk5ajzkczmxa) now holds 3,000 LSULP and 720 XRD. What it left The lending pool's LSULP fell from 51,051,122.67, the figure read here at epoch 336,462 on 19 August, to 3,624,492.41 at epoch 339,588 on 30 August. Seven positions belonging to other borrowers were liquidated in the 54 minutes after the exploit, against a baseline of about 70 transactions across the whole week to 11 August. Deposits kept arriving through the evening, including single supplies of 660,000 and 500,000 XRD after 19:00. Read at 19:40 UTC on 30 August there was no on-ledger remediation: no configuration change, no pause, no repayment, and Weft has published no statement. Anyone holding a Weft position can read its current state straight from the lending market component (https://dashboard.radixdlt.com/component/component_rdx1cpy6putj5p7937clqgcgutza7k53zpha039n9u5hkk0ahh4stdmq4w) , and the protocol's own account of what its risk model is meant to cover is in its risk documentation (https://docs.weft.finance/risks) . Five hours on Read again at 23:07 UTC on 30 August, epoch 339,630, nothing had yet been switched off. CreateCDP, UpdateCDP and BurnCDP all report enabled and unlocked on the lending market (https://dashboard.radixdlt.com/component/component_rdx1cpy6putj5p7937clqgcgutza7k53zpha039n9u5hkk0ahh4stdmq4w) , and can_borrow, can_create_cdp and can_flash_borrow are still allow_all. The market’s cdp_counter stands at 1,138, the position the exploit opened: no one has opened another in the five hours since. The feed had not been corrected at that hour, and it was still being written to. At 23:05:00 UTC the Default PriceFeed (https://dashboard.radixdlt.com/component/component_rdx1czdvvanvdy6495phfgz8uv6n2semp2cpexcg6vvty6uaycc82adgyv) refreshed HUG and published 1,275.05 XRD per token, two minutes before this reading. HUG traded at 0.000127565 XRD on Ociswap (/ecosystem/ociswap) at the same moment, so the published price is about ten million times the market. The market’s price_expiration_period is 14,400 seconds, so the posted price that released 71 million XRD of debt is current rather than expired. What has changed is the pool, and the change is lenders leaving. The Weft Lending Pool V2 (https://dashboard.radixdlt.com/component/component_rdx1czmr02yl4da709ceftnm9dnmag7rthu0tu78wmtsn5us9j02d9d0xn) held 3,624,492.41 LSULP at epoch 339,588 and 201,613.22 at epoch 339,630, alongside 774,245.75 XRD and 34.75 hUSDC. Eight transactions touched the market component between 19:40 and 23:07 UTC; every one moved assets out to a user account, and none changed a configuration. No statement had been published by 23:00 UTC. A search of the seven days to that reading returns nothing from @weft_finance (https://x.com/weft_finance) , and the project’s Telegram channel (https://t.me/WeftFinance) carries only questions from holders. The statement, and the disabled-collateral list Weft published its first account of the incident at 23:49 UTC on 30 August, in its Telegram channel (https://t.me/WeftFinance) , five hours and forty-six minutes after the borrow. It names three concurrent factors: that HUG collateral was “missing from the disabled-collateral list”, that one oracle source returned an incorrect price after the other sources failed, and that the protocol accepted that price. It commits to a two-week interest-free period and to setting all ecosystem token prices to 0.0000000001 XRD. The ledger does not support the first factor. The lending market (https://dashboard.radixdlt.com/component/component_rdx1cpy6putj5p7937clqgcgutza7k53zpha039n9u5hkk0ahh4stdmq4w) keeps four collateral services per resource – Add, Remove, FlashOperation and RemoveForLiquidation – each with its own enabled and locked flags. HUG’s Add service was set to enabled=false, locked=true by the protocol’s admin badge on 6 June 2025 at 08:40:27 UTC ( transaction (https://dashboard.radixdlt.com/transaction/txid_rdx173qp76fzq88c5ppegddl8aeqxh8fpfgxl8rkdxdcu99dts33d0msydt86g) ), at state version 303,390,813. Read back at 18:02 UTC on 30 August, the minute of the borrow, the entry still carried that write and no other. HUG was on the disabled list, and had been for 451 days. What was open is the neighbouring service. At that same instant HUG’s FlashOperation read enabled=true and unlocked, and steps 4 and 5 of the manifest are flash_remove_collateral and flash_add_collateral rather than add_collateral. The transaction committed while the Add entry read disabled and locked, so whatever the flash path checks, it is not that entry. The asset was listed and switched off; the door it came through was a different one. The same reading explains the size of the loss. An hour before the borrow only XRD and LSULP had their Borrow service enabled: xUSDC, xUSDT, xETH and xwBTC were disabled and locked, and the five Hyperlane assets were disabled. The attacker drew 47,280,000 LSULP and 13,100,500 XRD, which is everything the market would lend. The remediation, hour by hour - 23:23:32 UTC, 30 August. The admin badge calls admin_update_service_status on HUG’s collateral entry ( transaction (https://dashboard.radixdlt.com/transaction/txid_rdx1rvw2hv6g9fmfzf996c77lf25r4p45c70qy8phy6hn287vtnlmhssl8yrfw) ), setting Add to enabled=false with locked=false. The asset stays disabled and the entry, locked since June 2025, is now unlocked. FlashOperation was not touched, and still read enabled=true at 03:11 UTC on 31 August. - 23:25:00 UTC. The Default PriceFeed (https://dashboard.radixdlt.com/component/component_rdx1czdvvanvdy6495phfgz8uv6n2semp2cpexcg6vvty6uaycc82adgyv) publishes HUG at 0.000127565 XRD, the market rate. Its last overstated print was 1,275.83 XRD at 23:15:00, so the ten-million-fold error stood for five hours and twelve minutes after the borrow. - 23:49 UTC. The statement above. - 00:15:00 UTC, 31 August. The feed floors ten Radix-native tokens at 0.0000000001 XRD in one batch – HUG, OCI, CAVIAR, WEFT, EARLY, ASTRL, FLOOP, DFP2, MOX and SRG – the measure the statement had promised for “tomorrow”. It includes Weft’s own token. LSULP was left at 1.2242 XRD and HLP at 2.3340. - 03:05:29 UTC. The admin badge disables LSULP’s Borrow service and locks it ( transaction (https://dashboard.radixdlt.com/transaction/txid_rdx14qfwnsggcm72e0tnnacqr34vz4cl756zm268tyqjpvqx324kwygq9ul94e) ). XRD is now the only asset the market will lend. The pool the borrow drew from is empty. The Weft Lending Pool V2 (https://dashboard.radixdlt.com/component/component_rdx1czmr02yl4da709ceftnm9dnmag7rthu0tu78wmtsn5us9j02d9d0xn) held 774,245.75 XRD and 201,613.22 LSULP at 23:07 UTC on 30 August, 14,894.01 and 1,073.47 at 00:30, and 123.55 XRD, 1,073.47 LSULP and 0.21 hUSDC when read at 03:10 UTC on 31 August. Lenders withdrew what the attacker had not borrowed. Six liquidations ran against the market between 23:35 and 00:25 UTC, and the cdp_counter still stands at 1,138 – the position the exploit opened, and no other in the nine hours since. Figures read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 339,679. The second incident, thirteen hours later At 16:02 UTC on 31 August, thirteen hours after the last remediation transaction above, a separate attacker began emptying every Hyperlane-bridged asset held on Radix (/contents/history/hyperlane-asset-drain-2026) . Twenty-six transactions in under an hour took the whole supply of hUSDC, hUSDT, hETH, hWBTC, hSOL and hBNB out of accounts and pools across the network and bridged it away. The method has nothing in common with the exploit above: it needed no oracle, no price feed and no lending market, and it produced no borrow position. What the two share is the exit, since both attackers left over a Hyperlane (/ecosystem/hyperlane) warp route. Weft held 0.21 hUSDC in its lending pool when that pool was read at 03:10 UTC, so the second incident took effectively nothing further from the protocol. It removes the reserve currency the market would have restarted against: the four wrapped assets the page lists as disabled and locked collateral no longer exist on Radix in any quantity. LSULP exposure and the CaviarNine wind-down Weft's support for LSULP as collateral, listed under Weft V2 above, makes it the protocol most exposed to CaviarNine (/ecosystem/caviarnine) 's announced departure from Radix (/ecosystem/caviarnine) on 19 August 2026. LSULP is the pool unit of CaviarNine's LSU Pool, and the size of Weft's position in it is a ledger fact rather than an estimate. Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 336,462 (19 August 2026, 23:07 UTC), three Weft components hold LSULP: - Weft Lending Pool V2 (https://dashboard.radixdlt.com/component/component_rdx1czmr02yl4da709ceftnm9dnmag7rthu0tu78wmtsn5us9j02d9d0xn) — 51,051,122.67 LSULP - Weft Lending Market V2 (https://dashboard.radixdlt.com/component/component_rdx1cpy6putj5p7937clqgcgutza7k53zpha039n9u5hkk0ahh4stdmq4w) — 9,883,163.20 LSULP - C9 LSULP Pool (https://dashboard.radixdlt.com/component/component_rdx1cr5cnuzre63whe4yhnemeyvjj2yaq7tqg0j6q4xxtcyajf8rv0hw26) , described on ledger as the "Weft C9 LSULP Lending pool" — 1,476,638.10 LSULP That is 62,410,923.97 LSULP against a total supply of 263,942,458.90 — 23.6% of every LSU Pool unit in existence, held by one protocol, and LSULP (https://dashboard.radixdlt.com/resource/resource_rdx1thksg5ng70g9mmy9ne7wz0sc7auzrrwy7fmgcxzel2gvp8pj0xxfmf) has 940 holders. Weft is the single largest external holder of LSULP on the network; the next largest is the RSwap (/ecosystem/rswap) LSULP/DCKS pool at 17,293,134.15 (6.5%), and Stabilis (/ecosystem/stabilis) holds a further 1,053,413.26. The exposure is to the front end, not to the balances. LSULP's freezer and recaller rules are both deny_all and immutable, with the resource's rules locked, so a departing operator cannot freeze or claw back what Weft's pools hold, and the LSU Pool's contracts stay callable on ledger whatever happens to caviarnine.io. What a wind-down changes is the depth available to price and liquidate that collateral: Weft's liquidations rely on being able to move LSULP, and CaviarNine's own venues carried the great majority of Radix on-chain volume up to the announcement. As of that reading Weft had published no statement on the collateral listing. The exposure resolved eleven days later, by a route this section did not anticipate. The LSULP left in a single borrow on 30 August rather than through a collapse in the depth available to price it, and the balances above are now historical. See the exploit section above. ## WeAreMonstas URL: https://radix.wiki/ecosystem/wearemonstas Updated: 2026-09-01 Summary: WeAreMonstas was a community-driven project combining meme culture, hand-crafted NFT collections, and cross-chain gaming on Radix. Originally launched… Type NFT / Gaming / Community Symbol MXRD Website wearemonstas.com (https://web.archive.org/web/20250329182535/https://www.wearemonstas.com/) Category NFT Platform / Gaming Network Radix Mainnet (migrated from BSC) Founder AristotleArtichoke Overview WeAreMonstas (https://web.archive.org/web/20250329182535/https://www.wearemonstas.com/) was a community-driven project combining meme culture, hand-crafted NFT collections, and cross-chain gaming on Radix. Originally launched on Binance Smart Chain (BSC), the project migrated to Radix to leverage its scalability and developer-friendly architecture. The MXRD token served as the ecosystem currency, used for NFT staking rewards, game participation, and community governance. WeAreMonstas acted as a bridge between BSC meme culture and the Radix ecosystem. As of 2026 the project has wound down – wearemonstas.com (https://web.archive.org/web/20250329182535/https://www.wearemonstas.com/) no longer hosts the project (the domain now resolves to a parked hosting page); links here point to archived snapshots. NFT Collections WeAreMonstas produced hand-crafted NFT collections rather than algorithmically generated art: - Radix Tribes – community-themed tribal artwork - Heaven or Hell – narrative-driven collection - Fucking Embarrassing Mix Tapes – music-themed NFTs featuring community members NFT holders can stake their collections to earn passive MXRD rewards, with higher payouts for larger collections. Gaming - NFT Racers – a cross-community racing game where tokens become constructors in a Drivers Championship, bridging Radix and BSC communities - Radix Tribes (Strategy Game) – a planned Massive Asynchronous Multiplayer Strategy Game - MonstaMadness – seasonal festival events with multi-blockchain expansion External Links - WeAreMonstas – Official Website (https://web.archive.org/web/20250329182535/https://www.wearemonstas.com/) - WeAreMonstas – X (Twitter) (https://twitter.com/monsta_nft) - WeAreMonstas – Merchandise (https://www.redbubble.com/people/monstaxrp/shop) ## UniX URL: https://radix.wiki/ecosystem/unix Updated: 2026-09-01 Summary: UniX was a privacy-focused social media platform being built on Radix. In the rapidly evolving landscape of Web3, where decentralized applications (dA… [Notice: Written like an advertisement] Category Social / SocialFi Network Radix Announced August 2023 X @unixsocial (https://x.com/unixsocial) UniX was a privacy-focused social media platform being built on Radix. Introducing UniX: Bridging the Gap Between Social Connectivity and Web3 In the rapidly evolving landscape of Web3, where decentralized applications (dApps) are reshaping the way we interact with the digital world, UniX emerged as a trailblazing project that redefined social networking as we know it. UniX represented a bold step towards achieving a secure, user-centric, and innovative social platform that respected privacy and empowered individuals. Privacy-Centric Social Networking One of the standout features that set UniX apart from conventional social media platforms was its unwavering commitment to user privacy. In a world where personal data is often commodified, Radix introduces 'Persona,' a groundbreaking feature that allows users to share only the information that's truly necessary, without the need for email addresses or phone numbers. Your online identity remains truly yours, safeguarding your privacy in an unprecedented way. Empowering User Control UniX wasn't just a platform; it was a movement to put users back in control of their digital lives. Traditional social platforms often dictate how users interact and what they can or cannot do. UniX flipped the script, placing you firmly in the driver's seat. You decided who sees your content, who you connect with, and how you share your experiences. UniX empowered you to craft your online journey precisely the way you envision it. Built on Radix: Powering Innovation UniX's strong foundation was powered by Radix, a revolutionary technology stack that unlocks unprecedented possibilities. Radix's human-readable transactions simplify user interactions, making UniX exceptionally user-friendly. The wallet connect feature ensures secure and seamless transactions, fostering trust and usability. Transparency and Trust In a world where the inner workings of platforms are often shrouded in mystery, UniX stood as a beacon of transparency. We prioritized transparency, sharing our processes and much more with our community. Trust is built on transparency, and UniX was committed to fostering trust among its users. Versatility and More UniX aimed to be your all-in-one solution for your social presence. From blog posting to connecting with others to directly transferring assets and more, UniX provided every tool you need for a seamless and enriching online experience. We weren't just a social media platform; we were a comprehensive ecosystem that empowered you to express, connect, and transact. Join Us in Shaping the Future As we embarked on this transformative journey, we invited you to join us in shaping the future of social networking. UniX was more than just a dApp; it was a testament to the power of user-centric innovation. We were committed to building a secure, privacy-focused, and innovative platform where you were the master of your digital destiny. Stay tuned for exciting updates, collaborations, and the incredible experiences that await you in the UniX ecosystem. The future of social networking is here, and it's defined by you, for you. Welcome to UniX, where the future of social meets the decentralized web. Your journey begins now. Status UniX was announced in 2023 but never launched a public product, and its channels have gone quiet. The project is no longer active. ## Token Trek URL: https://radix.wiki/ecosystem/token-trek Updated: 2026-09-01 Summary: Token Trek is a gamified quest platform built by dmany that onboards new users into the Radix ecosystem through incentivized DeFi and community engage… Type Engagement Platform Symbol TREK Website tokentrek.io (https://www.radixdlt.com/blog/welcome-to-token-trek) Category Onboarding / Engagement Network Radix Mainnet Built by dmany Launched May 2024 Overview Token Trek (https://www.radixdlt.com/blog/welcome-to-token-trek) is a gamified quest platform built by dmany (https://medium.com/@dmanyio) that onboards new users into the Radix ecosystem through incentivized DeFi and community engagement. Users complete Web3 tasks (token swaps, liquidity provision) and Web2 tasks (content creation, meme competitions) to earn XP and share in reward pools. The platform was launched in May 2024 as part of the #Breakout2024 campaign (https://www.radixdlt.com/blog/welcome-to-token-trek) , with over $120,000 in XRD rewards distributed across participating projects. Impact Token Trek drove significant growth metrics for the Radix ecosystem during its initial campaign: - 12,000+ users signed up for the platform - 26,000+ quests completed across participating projects - Radix Wallet downloads reached 50,000 (a 41% increase) - Weekly transaction volume increased 99.96% to 77,207 transactions Participating ecosystem projects included CaviarNine (/ecosystem/caviarnine) , Ociswap (/ecosystem/ociswap) , DefiPlaza (/ecosystem/defiplaza) , XRD Domains (/ecosystem/xrd-domains) , Trove (/ecosystem/trove) , HUG (/ecosystem/hug) , and Xidar (/ecosystem/xidar) . How It Works - Quest System – users complete tasks like swapping tokens on a DEX, providing liquidity, or creating social content - XP & Leaderboards – completed quests earn experience points; top performers receive bonus rewards - Project Partnerships – ecosystem projects sponsor quests and reward pools, gaining new users in return - TREK Token – the Engage (TREK) token is associated with the platform and tradeable on Ociswap (/ecosystem/ociswap) External Links - Token Trek – Official Website (https://www.radixdlt.com/blog/welcome-to-token-trek) - Welcome to Token Trek – Radix Blog (https://www.radixdlt.com/blog/welcome-to-token-trek) - dmany – Social Infrastructure (https://medium.com/@dmanyio/token-trek-is-the-first-platform-powered-by-dmany-social-infrastructure-dmany-0a95a04baa26) ## Tāhuna URL: https://radix.wiki/ecosystem/tahuna Updated: 2026-09-01 Summary: Tāhuna is a decentralized prediction-market protocol in development on Radix mainnet. Anyone can list a market by posting a bond and writing the quest… Tāhuna Type Prediction-market protocol Category Ecosystem (/ecosystem) (Finance) Network Radix (/contents/tech/core-protocols/radix-engine) mainnet Status 🟠 In development (pre-launch) Quote asset xUSDC Pricing On-chain limit order book – 99 or 999 levels per market Fee model Taker pays, maker is paid back; peak 1.80% at 50¢ Listing Permissionless – free, or revenue-generating from a 10 xUSDC bond Resolution OTER (/ecosystem/oter) – optimistic proposer, beacon-drawn √stake jury on dispute Token None – no presale, no airdrop Testnet Q3 2026 (targeted) Mainnet Q4 2026 (targeted) X @tahuna_org (https://x.com/tahuna_org) GitHub Tahuna-Labs (https://github.com/Tahuna-Labs) Tāhuna is a decentralized prediction-market protocol (https://tahuna.org) in development on Radix (/contents/tech/core-protocols/radix-engine) mainnet. Anyone can list a market by posting a bond and writing the question; the listed creator then earns a share of every taker fee that market generates, creditable on the spot rather than at resolution. Markets are quoted in xUSDC and priced on an on-chain limit order book. Resolution is not performed by Tāhuna itself but handed to OTER (/ecosystem/oter) , the optimistic oracle on Radix, for which Tāhuna is the founding integration (https://oter.io) . The name is te reo Māori (https://tahuna.org) : tāhuna (TAH-hoo-nah) is a sandbank, beach or sandy shore – and the calm shallow water between the sand and the open sea. Market mechanics Tāhuna's stated design point is that the whole order book lives on the ledger. Every limit order, fill and cancellation is a Radix transaction and the matching engine runs in the contract, so there is no off-chain matching server, no custodial bridge and no settlement layer above the ledger (https://tahuna.org) – a design that leans on Radix's throughput and on the asset-oriented execution described in Scrypto fundamentals (/developers/scrypto/01-fundamentals) . Each market carries a price grid of 99 or 999 levels. An in-house indexing layer reads the on-chain state and republishes it live to the trading interface and over a public API, so integrators read the same feed as the frontend. Fees run in one direction: the taker pays and the maker is paid back through an on-chain rebate credited per fill, with the fee peaking at 1.80% at 50¢ and tapering toward the ends of the price range. Listing a market is permissionless and free, or revenue-generating in exchange for a 10 xUSDC bond; a curator – human or automated – verifies the wording before a market goes live, after which the listed creator stays attached to it for its lifetime. Creators register once and can list any number of markets under one identity, accruing a share of taker fees across all of them. Beyond the per-fill rebate the project describes a planned off-chain liquidity-rewards programme modelled on Polymarket's, scoring depth and time-on-touch each minute against the same indexed data, on the reasoning that cranking the book on-chain once a minute is not feasible. The protocol has no token, and the project states there is no presale and no airdrop. Resolution Tāhuna describes itself as the markets layer only; confirming an outcome is delegated to OTER (https://tahuna.org/resolution) , a separate project it depends on. When a market reaches its deadline a proposer submits a candidate outcome and posts a proposer bond, opening a four-hour challenge window – the default in OTER's own protocol specification (https://oter.io) , which marks it configurable per question. If nobody disputes it, the outcome finalizes, the market settles and the bond is returned – the path the project expects most markets with clear evidence to take, with no vote and no jury. A challenger who posts a counter-bond escalates the question to OTER (/ecosystem/oter) , where staked participants cast timelock-encrypted ballots. No ballot can be decrypted by anyone – including the juror who cast it – until the round closes and drand (https://drand.love) releases the decryption key, at which point every ballot is decrypted at once. Tāhuna contrasts this with UMA's commit–reveal cycle, which it says takes an extra round, and frames its own relationship to OTER as mirroring Polymarket's to UMA. The market creator posts a resolver reward when escalating, so jurors are paid by the market they are resolving. Two details of that vote are documented by OTER rather than by Tāhuna, and neither is visible from the markets side. The jury is not simply whoever staked: seats are drawn from OTER's own BLS randomness beacon after ballots lock, seating roughly 97 of every 100 revealed votes (https://oter.io) , so no stake buys a guaranteed seat. And voting power grows with the square root of stake rather than linearly with it, which the oracle publishes as cutting the top holder's share of voting weight from 24.1% to 3.6%. Where the two specifications disagree Both projects are pre-launch and both descriptions are their own documentation, so nothing below has been observed on-ledger. Where the two disagree about the same mechanism, this page records the disagreement rather than choosing between them. Tāhuna, "How resolution works" (https://tahuna.org/resolution) OTER, protocol specification rev. 2026-07 (https://oter.io) Winning threshold "the outcome with the higher stake-weighted total wins" 70% supermajority of revealed voting power, weighted by √stake; a round that misses it refunds bonds and re-enters the next cycle Deadlock "after five failed attempts on the same question, resolution can be lifted to an admin call" three tries, then a time-boxed close as invalid – "admin can expedite, never decide", and under Governance, "Admin never decides" Juror pay jurors "earn OTER tokens for participating and resolving correctly" voter rewards and the 15% share of the slashed bond are "paid in rUSDC stablecoins rather than a platform token" Cycle length "dispute resolution finishes in a single round" a single voting round inside a 48-hour cycle – 24 h sealed commit, 12 h reveal, 12 h to re-propose and dispute The deadlock row is the one that matters beyond wording. Tāhuna's page tells a trader that an ambiguous market ends in an administrator's decision; OTER's specification says an administrator can hurry a stuck question along but can never decide one, and that a question which cannot converge is closed as invalid instead. A market settling by admin call and a market voiding are different outcomes for whoever holds the position, and the two published documents do not agree on which one happens. Status and roadmap As of 29 August 2026 Tāhuna is pre-launch. Its published timeline targets a testnet in Q3 2026 and mainnet in Q4 2026 (https://tahuna.org) , and the site offers a waitlist rather than a live application. The Tahuna-Labs GitHub organisation (https://github.com/Tahuna-Labs) is registered but still publishes no public repositories – re-checked through the GitHub API on 29 August 2026, one month before the targeted testnet quarter closes – so the contracts are not open to inspection. The project states it is not available to residents of jurisdictions where prediction markets are prohibited. Tāhuna's dependency on OTER (/ecosystem/oter) means the two ship on linked timelines: OTER is likewise pre-launch, with its randomness beacon already live in production but the oracle itself not yet on mainnet. External Links - tahuna.org – official site and protocol specification (https://tahuna.org) - How resolution works – Tāhuna (https://tahuna.org/resolution) - Tāhuna on X (@tahuna_org) (https://x.com/tahuna_org) - Tahuna-Labs on GitHub (https://github.com/Tahuna-Labs) Related pages - OTER (/ecosystem/oter) – the optimistic oracle that settles Tāhuna's disputed markets - Religant (/ecosystem/religant) – the earlier oracle effort on Radix - Oracle Integration (/developers/scrypto/08-oracle-integration) – consuming an oracle from a Scrypto blueprint - Ociswap (/ecosystem/ociswap) – order-book and AMM trading venue on Radix ## Surge URL: https://radix.wiki/ecosystem/surge Updated: 2026-09-01 Summary: On 19 August 2026 CaviarNine , Surge's lead builder, announced that it is winding down its products and leaving Radix, and named Surge specifically. S… Type Perpetuals DEX Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Live — unwinding in stages, announced 19 August 2026 Pool (Aug 2026) 33,245.53 sUSD held; net ≈ $24.3K – read on-ledger 11 Aug 2026 Category Derivatives / perpetual futures Built by CaviarNine (/ecosystem/caviarnine) , Keyrock & Supra (https://supra.com) Token SRG Oracle Supra (https://supra.com) X @surge_trade (https://x.com/surge_trade) Wind-down announced (August 2026) On 19 August 2026 CaviarNine (/ecosystem/caviarnine) , Surge's lead builder, announced (https://t.me/radix_dlt/998739) that it is winding down its products and leaving Radix, and named Surge specifically. Surge is to unwind in stages: a date will be announced for the orderly closing of all open positions, and collateral left unclaimed after that date is to be bridged to Ethereum and held there for later claiming, so that no position is stranded. No date had been given when this page was updated, and the exchange was still trading — surge.trade (https://www.surge.trade) served its full interface on 19 August 2026 and the pool component below was still committing keeper transactions. Two things follow for anyone reading the sections underneath. The protocol facts recorded there — pool balance, SRG supply, the burn mechanism — describe a live exchange that has now been given an end date in principle; and the collateral set includes LSULP, the CaviarNine LSU Pool unit, whose issuer is the same company that is leaving. The pool unit itself is unaffected by that: read live at epoch 336,318 on 19 August 2026 its freezer and recaller rules are deny_all and immutable, so no operator can freeze or claw back margin denominated in it. Surge is a decentralized perpetuals exchange launched on the Radix network as a collaborative effort between companies CaviarNine (/ecosystem/caviarnine) , KeyRock, and Supra (https://supra.com) . It is the first perpetual DEX built on the Radix blockchain, designed to facilitate off-ledger trading in the decentralized finance (DeFi) ecosystem. As of 2026, Surge is live and trading on Radix mainnet (https://www.surge.trade) , offering leveraged long and short positions across major crypto markets with on-ledger settlement and price feeds from Supra (https://supra.com) oracles. The protocol is powered by its native SRG token ( @surge_trade (https://x.com/surge_trade) ). Protocol status Surge is still operating on mainnet, and the claim is checkable on-ledger rather than from the front end. Read at epoch 333919 on 11 August 2026, the liquidity-pool component (https://dashboard.radixdlt.com/component/component_rdx1crezrpxw9ypg6v2panqjqwevnwplg94yeej0rhqq9k7p4kgnltrc9g) held 33,245.53 sUSD — Surge's own wrapped dollar — in a single vault, against a virtual balance of −8,892.11, unrealised pool funding of −53.95 and a profit-and-loss snapshot of −43.72, for a net pool value of roughly $24.3K. The same component had committed a transaction at 03:06 UTC that morning, minutes before the read; its steady traffic is keeper transactions paying out SKR (Surge Keeper Reward) to the accounts that push oracle prices into the exchange. The SRG token has a total supply of 98,894,000 with its minter rule (https://dashboard.radixdlt.com/resource/resource_rdx1tka3kqqkjxcpddvcx0u300qt66z3tlzv7swqx9rklp60m5yqry6yzk) set to deny_all, so no more can currently be issued — though unlike some Radix tokens that rule is still mutable and the resource's rules are not locked. A note on third-party data. DeFiLlama (https://defillama.com/protocol/surge-trade) has reported zero TVL for Surge every day since 25 March 2026, its last non-zero reading being $27,844 on 24 March. The pool balance measured above is of the same order as that final figure, so the zero is best read as a broken tracking adapter rather than as a wind-down of the protocol. Overview Perpetual exchanges like Surge enable traders to take leveraged positions without being constrained by traditional expiry dates. This allows traders to hold positions indefinitely without the need to roll over contracts periodically. Additionally, perpetual contracts provide the ability to trade with leverage, enabling traders to potentially amplify their profits or losses. Surge aims to provide a comprehensive and secure trading platform tailored for these types of perpetual markets. It incorporates features from established protocols while introducing its own innovative elements. Surge was developed by leveraging the expertise of its founding companies in areas such as oracle technology and financial services. CaviarNine, KeyRock, and Supra contributed their respective specialties to create the perpetual DEX. As the first such platform on Radix, Surge represents a significant addition to the network's growing DeFi ecosystem. Key Features Surge's own documentation (https://docs.surge.trade/welcome-to-surge.md) describes a cross-margin venue denominated entirely in USD terms: every pair, account and settlement is measured in dollars, positions share a unified collateral pool, and a single central USD pool takes the other side of every trade and carries the resulting risk. - Markets. Eight pairs are listed against the dollar — BTC, ETH, SOL, XRD, SUI, DOGE, ADA and BNB. (The "over 100 trading instruments" figure that circulated before launch came from the 2024 announcement (https://surgetrade.medium.com/introducing-surge-496de2302f11) and does not describe the deployed exchange.) Leverage starts at up to 20x. - Collateral. sUSDC — Surge's wrapped xUSDC (/ecosystem/instabridge) — plus xWBTC, xETH, XRD (/contents/tech/core-protocols/xrd-token) and LSULP, the CaviarNine (/ecosystem/caviarnine) LSU pool unit, are accepted as margin. - Order types. Market, limit and stop-limit, with take-profit and stop-loss attached to a position. - Oracle and keepers. Prices come from Supra (https://supra.com) and are pushed on-ledger by keepers (https://docs.surge.trade/about-surge/keepers.md) — permissionless accounts that hold no protocol authority but are paid in SKR (Surge Keeper Reward) for the transactions that keep prices, liquidations and order execution current. Keeper traffic is what the component's steady on-ledger activity consists of. - Liquidity providers stake xUSDC into the single pool, earn a share of trading fees, and in exchange stand as counterparty to traders' aggregate position. - Scrypto. The exchange is written in Scrypto (/developers/scrypto) and settles on-ledger; the docs publish the transaction manifests (https://docs.surge.trade/technical/surge-manifests.md) a client builds to trade against it. The documentation still carries a prominent risk notice describing Surge as "an experimental perpetual DEX in its early stages of development" whose risk-management, liquidation and oracle systems "are being tested in live market conditions". $SRG Token SRG had its token generation event on 13 November 2024 with an initial supply of 100,000,000. Read live at epoch 334255 on 12 August 2026, the resource (https://dashboard.radixdlt.com/resource/resource_rdx1tka3kqqkjxcpddvcx0u300qt66z3tlzv7swqx9rklp60m5yqry6yzk) reports a total supply of 98,894,000. The difference — 1,106,000 SRG, or about 1.1% of the original supply — has been burned, which makes the token's one live mechanism measurable rather than promised. Buy-back and burn. Per Surge's documentation (https://docs.surge.trade/srg-governance-token/burning.md) , 20% of all opening and closing trade fees are routed to an SRG treasury component, and those fees are periodically used to buy SRG from the market and burn it. That component (component_rdx1czwd96pvxsuy2ydd25fulz242x36h257thn45tscp4rkxkrfy99958) is a FeeDistributor instance and held a treasury balance of 353.97 at the same read. The burn is community-triggerable: the site shows the treasury balance in real time and anyone may initiate the buy-back from the interface, which the ledger corroborates — the resource's burner rule is allow_all and, unusually, immutable, so the right to burn SRG cannot be withdrawn. The minter rule is deny_all, fixing supply, though that rule remains mutable and the resource's rules as a whole are not locked. Governance is still forward-looking, by Surge's own account. The token is named a governance token, but the documentation says only that "as the platform matures, the token will convey voting rights to holders to make governance decisions on a variety of issues, such as fee structures and burn rates". No voting mechanism has been announced as live. A staking model that would pay SRG holders a yield from collected fees is described as a possibility "in future, dependent on the preference as decided by a governance vote" — that is, contingent on the governance that does not yet exist. Community and status Surge is live and permissionless: there is no sign-up, no early-access list and no testnet phase — a trader connects a Radix Wallet (/contents/tech/core-protocols/radix-wallet) and opens a trading account directly. The project publishes updates through @surge_trade (https://x.com/surge_trade) . Its documented roadmap is short and unchanged from the launch-era list: additional trading pairs, higher leverage limits, interface work, a referral system, and bridge integrations. The referral programme in particular is still listed as planned rather than shipped, and no timeline is attached to any of it. Surge does not publish a public governance forum or a treasury report; the on-ledger components above are the only continuously verifiable record of the protocol's activity. External Links - Surge – official site and exchange (https://www.surge.trade) - Surge documentation (https://docs.surge.trade) - @surge_trade on X (https://x.com/surge_trade) - Liquidity-pool component on the Radix Dashboard (https://dashboard.radixdlt.com/component/component_rdx1crezrpxw9ypg6v2panqjqwevnwplg94yeej0rhqq9k7p4kgnltrc9g) - DeFiLlama – Surge Trade (https://defillama.com/protocol/surge-trade) ## Supreme Stake URL: https://radix.wiki/ecosystem/supreme-stake Updated: 2026-09-01 Summary: Supreme Stake is a Radix validator run by a partnership of infrastructure, networking, security and automation professionals. It has been validating s… Supreme Stake Type Radix validator node Status 🟢 Active – registered, accepting delegations Validating since Radix Betanet Validator address validator_rdx1svug…ut5mmz8 (https://dashboard.radixdlt.com/network-staking/validator_rdx1svug50cdlalm6plazajrmntf209j5azf57xeukuhx2hw7e7ut5mmz8) Total stake ≈66.0 million XRD (rank #27) Validator fee 5% (raised from an original 1.5%) Uptime (30d) 99.11% Infrastructure SOC 2–compliant public cloud with redundant colocation backups On-ledger Verified via the Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1svug50cdlalm6plazajrmntf209j5azf57xeukuhx2hw7e7ut5mmz8) (mainnet epoch 326286, 15 Jul 2026) Supreme Stake (https://supre.me) is a Radix validator (/contents/tech/core-concepts/validator-nodes) run by a partnership of infrastructure, networking, security and automation professionals. It has been validating since the Radix Betanet and is, on the numbers below, one of the thirty largest validators on the network. Operation The operators describe themselves as a mix of long-standing Radix holders and people who arrived from years elsewhere in crypto, and they present the node as an enterprise deployment rather than a hobby one: it runs in a SOC 2 compliant public cloud with backup nodes in redundant colocation facilities, 24/7 monitoring and DDoS protection. They also say they keep their node earnings staked rather than selling them to cover running costs, and that they have more than 750,000 XRD of their own delegated to it. That last figure is the operator’s own claim; the validator’s owner-locked vault holds 534,911.41 stake units, which measures something different and neither confirms nor contradicts it. Fee The validator fee is 5%, raised from the 1.5% it charged originally, so the large majority of staking emissions (/contents/tech/core-concepts/staking) still reaches delegators. Reading it takes some care: the stored validator_fee_factor on the component is still 0.015, and the 5% lives in a validator_fee_change_request whose epoch_effective passed long ago. The engine charges the request and leaves the stale field alone – the mechanism is described under Validator Nodes (/contents/tech/core-concepts/validator-nodes) , and it affects 64 of the network’s 187 registered validators at this epoch. 5% is the figure delegators actually pay. On-ledger status (14 August 2026) Read live from the Radix Gateway (https://mainnet.radixdlt.com/state/validators/list) at epoch 334878, the Supreme Stake validator – validator_rdx1svug50cdlalm6plazajrmntf209j5azf57xeukuhx2hw7e7ut5mmz8, whose on-ledger info_url is supre.me – is registered, accepts delegated stake, and holds 66,369,561.26 XRD: rank 30 of the 187 registered validators, well inside the top-100 active set. Over the trailing month it made 180,522 proposals and missed 70 while active in every one of 8,878 epochs – 99.96%. The high-uptime claim above is the part of this page the ledger corroborates. The public presentation has aged less well. supre.me (https://supre.me) is a Wix site footered “©2021 by Supreme Stake” that still displays the node’s Olympia-format address, rv1qt2mpw9j5av508e2f75q2pxhj04m5waerd5eafgrdvkapaxx3v0wxt36584, which has addressed nothing since the Babylon (/contents/tech/releases/radix-mainnet-babylon) migration re-derived every address on the network. The status page (https://supremestake.statuspage.io) it links reports “All Systems Operational” from a record last updated on 21 September 2021. Neither is evidence about the node, which is why the figures above come from the ledger instead. External Links - Supreme Stake – official website (https://supre.me) - Supreme Stake on the Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1svug50cdlalm6plazajrmntf209j5azf57xeukuhx2hw7e7ut5mmz8) - Supreme Stake – status page (https://supremestake.statuspage.io) (last updated September 2021) ## Stream Wallet URL: https://radix.wiki/ecosystem/stream-wallet Updated: 2026-09-01 Summary: Radix Stream is a self-custody mobile wallet for Radix, built by the team behind IdeoMaker and published as Ideomaker SDK BV. An early community walle… Radix Stream Type Self-custody mobile wallet (iOS / Android) for Radix Status 🟠 Dormant – last release v1.2.13 (24 April 2023); both app-store listings since removed Developer IdeoMaker (/ecosystem/ideomaker) (Ideomaker SDK BV) Security audit Code audited by Red4Sec (https://www.red4sec.com) Features Self-custody keys, wallet tracking, XRD staking, fiat valuations Radix Stream is a self-custody mobile wallet for Radix, built by the team behind IdeoMaker (/ecosystem/ideomaker) and published as Ideomaker SDK BV. An early community wallet that pre-dates the official Radix Wallet, it is no longer maintained: its published release history (https://radix.stream/download-stream-wallet) ends at v1.2.13 on 24 April 2023, and the site itself (https://radix.stream) carries a Webflow build stamp of the same day. Availability The wallet can no longer be installed. Checked on 23 August 2026, the App Store listing (https://apps.apple.com/ro/app/radix-stream/id1596583199) the download page links to returns HTTP 404, and Apple's own lookup service reports no such application in the Romanian, US, British, German or Dutch storefronts; the Google Play listing (https://play.google.com/store/apps/details?id=com.ideomaker.radixstream) for com.ideomaker.radixstream likewise returns 404. The download page (https://radix.stream/download-stream-wallet) still renders both buttons, so a reader arriving at the site has no way to tell before clicking. The project's feedback board at feedback.radix.stream also no longer resolves, while its Telegram (https://t.me/StreamWallet) and Discord (https://discord.gg/uZxMPvde9r) invites still do. The developer has not left Radix. IdeoMaker runs the Ideomaker Europe validator on mainnet and its status on this wiki is Active (/ecosystem/ideomaker) ; it is the wallet product, not the team, that stopped. Release history Four releases are published on the download page: - v1.0.0 — 23 May 2022, marked a beta. Full wallet functionality: create or add a wallet, send and receive, stake and unstake XRD, multiple wallets at once, a dual Tracker/Wallet mode, transaction history, address book, and Mainnet or Stokenet gateway selection. - v1.0.1 — 27 May 2022, also beta. Interface fixes, corrected handling of transfers above 999 and of decimal amounts, better validator information when choosing where to stake. - v1.2.12 — 16 April 2023. Domain-name support through .XRD Domains (/ecosystem/xrd-domains) and the Radix Name Service (/ecosystem/radix-namespace) , letting a user reserve a name in the app and send to one instead of an address, plus encrypted and plain transaction messages. - v1.2.13 — 24 April 2023, the last. A faster setup path for new users, support for 18- and 24-word seed phrases, fiat pricing for listed Radix tokens, and dApp login by QR code, described in the notes as a beta built for the then-upcoming Foton (/ecosystem/foton) marketplace. A "Stream Pro" tier was advertised but never shipped. Its roadmap — token creation and airdrop wizards, staking-reward tracking, biometric login, token swapping, NFT support, Ledger hardware-wallet support and CSV/PDF tax reports — is still listed on the download page as upcoming, three years after the last release. Overview Radix Stream provided a platform for storing, sending, and receiving tokens on the Radix decentralised ledger. The wallet could be used as a standalone wallet or as a wallet tracker, or both simultaneously. As a self-custody wallet, users of Radix Stream were the sole controllers of their Seed Phrase and login credentials. This means that the security and control of assets within the wallet are entirely in the hands of the user. Contact and Support Users can reach out to the Radix Stream team via Twitter or through the Telegram and Discord channels. These channels are also used for bug reporting and feature requests. Disclaimer Radix Stream, the Ideomaker SDK, and the developers are not to be held accountable for any loss of tokens or any other damage resulting from the usage of the app. Users are reminded that they are the only ones in control of their Seed Phrase and login credentials, and they bear full responsibility for the security of their assets. ## StakingCoins URL: https://radix.wiki/ecosystem/stakingcoins Updated: 2026-09-01 Summary: StakingCoins is a blockchain node and validator company founded by Marco Michelino, an experienced Italian Linux system administrator and member of th… Type Validator Node Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Active (registered) Operator Marco Michelino (Radix Ambassador) Validator validator_rdx1sva6…rqpx7z86 (https://dashboard.radixdlt.com/validator/validator_rdx1sva6pmkgm5yacumw4p6k0xsfnqg598xkj9p4e2a58dl6gcrqpx7z86) Validator fee 10% (effective since 9 Feb 2026; stored factor still reads 2%) Total stake 15,355,297.71 XRD (rank 61 of 188 registered, 10 Aug 2026) Uptime 99.97% (49,626 proposals made, 14 missed over 30 days) Founded 2021 X @Radix_SC (https://x.com/Radix_SC) StakingCoins (https://radixdlt.stakingcoins.eu) is a blockchain node and validator company founded by Marco Michelino, an experienced Italian Linux system administrator and member of the Radix DLT community. History Marco, the founder of StakingCoins, first began his journey into the world of cryptocurrencies in 2013 when he purchased his first Bitcoin. Over the years, he expanded his activities into running various blockchain nodes. His engagement with the Radix DLT community further deepened when he participated in testing the Radix DLT betanet with his own node. Marco also serves as a Radix Ambassador and runs the unofficial Radix DLT Italian Telegram group (@Radix_Italia). Infrastructure StakingCoins operates two physical validator nodes – each with 32 GB of RAM and 12 CPU cores – hosted in separate tier-4 data centers in France and Germany, providing geographic redundancy and DDoS protection. Validator Proposal StakingCoins charges its delegators a 10% validator fee, and has done since 9 February 2026 — not the 2% its stored fee factor reads, and not the 2% this page previously stated. The two numbers are both on the ledger and neither is wrong; see On-ledger status below. As of 10 August 2026 the StakingCoins validator (https://dashboard.radixdlt.com/validator/validator_rdx1sva6pmkgm5yacumw4p6k0xsfnqg598xkj9p4e2a58dl6gcrqpx7z86) (validator_rdx1sva6pmkgm5yacumw4p6k0xsfnqg598xkj9p4e2a58dl6gcrqpx7z86) is registered on the Radix mainnet with 15,355,297.71 XRD staked and a 99.97% 30-day proposal record. Communication For delegators of StakingCoins, there is a dedicated Telegram group (@Radix_StakingCoins), where a bot automatically informs members of any issues with the validator node. In addition to this, Marco can be contacted through Discord at rigel#5123 and is active on Twitter under the handle @Radix_SC. On-ledger status (August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) on 10 August 2026 at epoch 333630 (state version 548,029,458), the StakingCoins validator (https://dashboard.radixdlt.com/validator/validator_rdx1sva6pmkgm5yacumw4p6k0xsfnqg598xkj9p4e2a58dl6gcrqpx7z86) is registered, accepts delegated stake, and holds 15,355,297.71 XRD — rank 61 of the 188 registered validators by stake. Over the trailing 30 days (epochs 325,000–333,631) it made 49,626 proposals and missed 14, a 99.97% record. Stake units are issued as resource_rdx1t4p…m5aahap0 and unstake claims as resource_rdx1ntg…t96z4jfve. The fee needs stating carefully, because two different numbers are both true on the ledger. The stored validator_fee_factor is 0.02. Sitting beside it is a validator_fee_change_request for 0.1 with an effective epoch of 281,280 — a block finalized on 9 February 2026, 52,351 epochs and about 182 days before this reading. The engine resolves the fee it actually charges at emission time as “the request, if its effective epoch has passed; otherwise the stored field”, and only writes the request back into the stored field when the owner requests the next change. So the validator has charged 10% for six months while every tool that reads only the stored factor — including, until this edit, this page — reported 2%. StakingCoins is not unusual in this. At the same reading, 63 of the 188 registered validators were charging something other than their stored fee factor, 51 of them more, and between them they held 2,974,708,557 of the 4,739,857,777 XRD delegated to registered validators — 63% of all delegated stake. The mechanism, and the rule for reading a Radix validator fee correctly, are set out on Validator Nodes (/contents/tech/core-concepts/validator-nodes) . External Links - StakingCoins on the Radix Dashboard (https://dashboard.radixdlt.com/validator/validator_rdx1sva6pmkgm5yacumw4p6k0xsfnqg598xkj9p4e2a58dl6gcrqpx7z86) — live stake, fee and uptime - radixdlt.stakingcoins.eu (https://radixdlt.stakingcoins.eu/) — operator site - Validator blueprint (radixdlt-scrypto) (https://github.com/radixdlt/radixdlt-scrypto/blob/develop/radix-engine/src/blueprints/consensus_manager/validator.rs) — update_fee and apply_emission, where the two fee fields are reconciled - @Radix_SC (https://x.com/Radix_SC) ## SRWA URL: https://radix.wiki/ecosystem/srwa Updated: 2026-09-01 Summary: SRWA is a real-world asset (RWA) tokenization company that builds enterprise tooling for issuing, managing and financing tokenized assets. It originat… SRWA is a real-world asset (RWA) tokenization company that builds enterprise tooling for issuing, managing and financing tokenized assets. It originated in the Radix ecosystem – its first lending prototype came out of the Radix Scrypto DeFi Challenge – and has since grown into a blockchain-agnostic platform (https://srwa.io) , with the team shipping across Radix, Ethereum, Polygon and Solana. Its stack powers Ploughshare (https://ploughshare.nz/) , a registered financial service provider in New Zealand that brings tokenized finance to the dairy sector. On Radix the company is represented by two things a reader can check directly: the SRWA Lending market, an Lend component (https://dashboard.radixdlt.com/component/component_rdx1cps7jyr7vqrtm2uxj8d77a9fyjkv804nhqzvfn2u7m58tg3wdk2qky) live on mainnet and tracked by DeFiLlama (https://defillama.com/protocol/srwa-lending) since 18 November 2024, and the $SRWA token (https://dashboard.radixdlt.com/resource/resource_rdx1t4k6qmpv7krl9gxc5v7ss6fl4j7uuelkaftfz4p49ejd0zj0xs2pwn) (ledger symbol RWA), whose supply is fixed at 10,000 with minting, burning, freezing and recall all permanently denied. The lending market is described in measured terms below; the sections after it record the design the team set out when the project was introduced to the Radix community in 2023, much of which remains a statement of intent rather than shipped software. SRWA Lending on Radix SRWA Lending is an overcollateralized money market deployed on Radix mainnet as a single component (https://dashboard.radixdlt.com/component/component_rdx1cps7jyr7vqrtm2uxj8d77a9fyjkv804nhqzvfn2u7m58tg3wdk2qky) instantiated from the Lend blueprint v1.0.0 of this package (https://dashboard.radixdlt.com/package/package_rdx1p54zm4ty4yujh47n5zmy5kxxmnu4hltyt9gsf94dk2nxvsu9funnte) . It runs two markets: XRD and xUSDC (https://dashboard.radixdlt.com/resource/resource_rdx1t4upr78guuapv5ept7d7ptekk9mqhy605zgms33mcszen8l9fac8vf) (Instabridge Wrapped USDC) – not the $MOO pairing sketched in the original 2023 design. The same component address is the one DeFiLlama's adapter (https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/SRWAio/index.js) reads, so the wiki's figures and the dashboard's figures come from the same place. Measured state Read live from the ledger at epoch 334014, state version 548676006 (11 August 2026, 11:05:51 UTC): Field XRD market xUSDC market Deposits 286,444.999761 XRD 2,190.731601 xUSDC Borrows 166.713181 XRD 1,767.021882 xUSDC Loan-to-value 0.5 0.5 Pool deposit limit 60,000 XRD 20,000 xUSDC Liquidation bonus / max liquidation 10% / 50% 10% / 50% New deposits locked locked New borrows locked locked Withdrawals / repayments open open The component carries 102 user records, a minimum collateral ratio of 1, a maximum borrow of 10% of a pool per position, a utilisation kink at 0.7 and a reserve factor of zero on both assets. Deposit and borrow rates are not derived by the component when a position is opened; they are pushed in by the operator through an update_deposit_and_borrow_rates call, and the values standing at the read above were 0.917010 / 1.136899 on xUSDC and 0.00000059 / 0.001017 on XRD. Exit-only, and operator-gated Two facts about the deployment are worth stating plainly, because neither is visible from a TVL chart. First, the market is closed to new business. The blueprint's lock_pool(asset_address, deposit_locked, borrow_locked, withdraw_locked, repay_locked) method sets four independent flags, and on both assets the first two are set: new deposits and new borrows are locked, while withdrawals and repayments remain open. That is the posture of a market being wound down rather than one being run, and the transaction record agrees – the last committed transaction touching the component was on 17 April 2026 (a 11.426993 xUSDC withdrawal at 16:16:20 UTC, seconds after a 100.015388 XRD withdrawal), and the batch before it was on 1 March 2026. Every recent transaction moves value out of the component; none move value in. Second, a depositor cannot act on their own position. On the Lend blueprint, deposit, withdraw, borrow, repay, liquidate and create_new_user are all role-protected by the admin badge ( resource_rdx1nf4d…nx5s7n2h (https://dashboard.radixdlt.com/resource/resource_rdx1nf4dqmnx57skv6ug5umzly7y386st9hc7s46xy6lx05j50nx5s7n2h) , three ids currently approved); only the read methods such as get_user, get_parameters and get_lock_pool_states are public. Interaction therefore runs through SRWA's own front end and signing key, and the 286,445 XRD and 2,191 xUSDC standing in the pools are reachable only through the operator. This is a factual property of the deployment, not a judgement about the operator. Size over time DeFiLlama listed the protocol on 18 November 2024 at $23,496 and recorded its peak of $93,679 on 8 December 2024. On 11 August 2026 it reports $263 – about 286,273 XRD by the adapter's own accounting – which is roughly 0.3% of the peak and the smallest non-zero entry on DeFiLlama's Radix list. Products Ploughshare Ploughshare (https://ploughshare.nz/) is a registered New Zealand financial service provider that uses SRWA's tokenization stack to bring on-chain finance to the country's dairy sector. It is the company's flagship deployment and the reason its RWA tooling exists in the shape it does. The current suite SRWA has repositioned around an AI-assisted RWA tokenization suite (https://srwa.io) : a portfolio manager for onboarding customers and managing assets, tokenized company shares with shareholder tracking and reporting, and tokenized financial instruments for peer-to-peer and pool-based lending with compliance automation. A fourth product, decentralised lending and borrowing, is labelled sandbox on the company's own site – a separate, later effort from the Radix market described above. The company joined the Katapult (https://katapult.vc/) K24 accelerator cohort and completed a pre-seed round backed by co-investment grants. Real-world asset integration Central to SRWA's value proposition is the tokenization of RWAs, enabling users to collateralize assets such as farms or machinery. A Special Purpose Vehicle (SPV) is created to register and tokenize the asset, an NFT representing it is issued, and its owner can then demonstrate the collateral on-chain. The 2023 design The following is the design the founders described when SRWA was introduced to the Radix community, recorded here because it is the origin of the deployed market and because parts of it never shipped. It should be read as a statement of intent from 2023, not as a description of the protocol as it runs today. The lending protocol was to let users deposit selected tokens – $XRD and $MOO were named – and earn interest while others borrowed against them, with the accrued interest split between the Ploughshare project and depositors at a predefined rate, and both sides incentivised by $MOO distribution. NFT representation of real-world assets was planned for a later update. The deployed market runs XRD and xUSDC, carries no incentive token, and sets a reserve factor of zero on both assets. The design envisioned a two-fold ecosystem in which Ploughshare evolved into a DAO while SRWA contributed as the technology team, with anticipated partnerships spanning liquidity providers, DEXs, CEXs, asset originators, auditors, oracles, stablecoin protocols, identity and KYC providers, fiat on/off-ramps, bridges and multisig solutions. Decision-making was to move to decentralized governance, with an initial treasury for DAO operations established alongside a token launch. The $SRWA token exists on-ledger with a fixed 10,000 supply and locked authorities; no DAO or treasury component has been published. Initial capital denominated in XRD was earmarked for staking to support the Radix network, and the team floated running a dedicated full node as a learning exercise. History The inspiration for SRWA came from the Radix Scrypto DeFi Challenge. The team explored DeFi lending protocols in depth and arrived at a Compound-like mechanism in which assets serve both as a lending pool for borrowers and as collateral; their original demo ran under the resim simulator, and the design carried through to the mainnet Lend blueprint documented above. Nicola, one of the co-founders, came to blockchain around 2016–2017, drawn less by native assets such as Bitcoin and Ethereum than by the prospect of applying the technology to real-world assets; early experiments involved assets such as gold. The team's motivating comparison was credit issuance: four and a half months to raise a credit line through traditional channels against an hour and a half on-chain. The project took shape through 2022 and found Radix in December of that year, which the founders credited with solving the user-experience problem they had been fighting. Team - Nikola Sologub – an early enthusiast of blockchain and DLTs, pivotal in steering the direction of the project. - A university professor – a co-founder responsible for protocol development, with a team experienced on Cosmos and Polygon. - Further co-founders bringing DeFi and dApp development experience. SRWA endorses open-source methodologies, took an early interest in Radix royalty mechanics, and states a preference for integrating existing components over re-inventing them. External Links - srwa.io (https://srwa.io) – company site and product suite - Ploughshare (https://ploughshare.nz/) – the New Zealand dairy-finance deployment - SRWA Lending component on the Radix Dashboard (https://dashboard.radixdlt.com/component/component_rdx1cps7jyr7vqrtm2uxj8d77a9fyjkv804nhqzvfn2u7m58tg3wdk2qky) - $SRWA (RWA) resource on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4k6qmpv7krl9gxc5v7ss6fl4j7uuelkaftfz4p49ejd0zj0xs2pwn) - SRWA Lending on DeFiLlama (https://defillama.com/protocol/srwa-lending) - The DeFiLlama adapter (https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/SRWAio/index.js) – the component address it reads - @SRWAio (https://x.com/SRWAio) on X · Telegram (https://t.me/SRWAio) See also: Weft Finance (/ecosystem/weft-finance) and Root Finance (/ecosystem/root-finance) , the two other lending markets on Radix tracked by DeFiLlama. SRWA Type Real-world asset (RWA) tokenization platform Category Finance / RWA Networks Blockchain-agnostic – originated on Radix; team also ships on Ethereum, Polygon and Solana Notable app Ploughshare (https://ploughshare.nz/) (NZ dairy finance) Radix deployment SRWA Lending (https://dashboard.radixdlt.com/component/component_rdx1cps7jyr7vqrtm2uxj8d77a9fyjkv804nhqzvfn2u7m58tg3wdk2qky) – Lend v1.0.0, XRD + xUSDC markets Market state Exit-only: new deposits and borrows locked, withdrawals and repayments open (11 Aug 2026) Size $263 on DeFiLlama, against a $93,679 peak on 8 Dec 2024 Last on-ledger activity 17 April 2026 Token $SRWA (https://dashboard.radixdlt.com/resource/resource_rdx1t4k6qmpv7krl9gxc5v7ss6fl4j7uuelkaftfz4p49ejd0zj0xs2pwn) (symbol RWA) – 10,000 fixed supply, authorities locked Status 🟢 Active (company) · Radix lending market winding down Founded 2022 X @SRWAio (https://x.com/SRWAio) ## SoulStore URL: https://radix.wiki/ecosystem/soulstore Updated: 2026-09-01 Summary: Soulstore is a decentralized application (dApp) for virtual accounts (soulstores) that are eternally linked to and controlled by specific non-fungible… SoulStore Type NFT utility dApp (soul-bound NFT inventories) Network Radix DLT Status 🟠 Dormant (site live) Founded 2024 Team rippy.xrd (ripsource) (https://github.com/ripsource) Soulstore is a decentralized application (dApp) for virtual accounts (soulstores) that are eternally linked to and controlled by specific non-fungible tokens (NFTs). Soulstores serve as decentralized, soul-bound inventory spaces for NFTs, allowing them to hold and manage various digital assets, including tokens and other NFTs. Features - Permanent Association: Each soulstore is uniquely and permanently associated with a specific NFT, forming an inseparable bond between the two. - Asset Storage: Soulstores can securely store different types of digital assets, such as fungible tokens (e.g., cryptocurrencies) and non-fungible tokens (e.g., other NFTs). - Asset Management: Owners of an NFT can deposit, hold, and withdraw assets to and from its associated soulstore, providing a means for managing and transferring digital assets. - Ownership Control: Only the current owner of an NFT has exclusive access and control over the assets stored within its soulstore. - Transferability: When an NFT is traded or transferred to a new owner, the contents of its soulstore are automatically transferred as well, ensuring that the assets remain bound to the NFT. Use Cases Soulstores introduce a new dimension to the utility and value proposition of NFTs. By allowing NFTs to hold and manage digital assets, soulstores enable various use cases, including: - Tokenized Asset Management: Soulstores provide a way to tokenize and manage physical or digital assets by representing them as NFTs, with their associated soulstores holding related tokens or assets. - In-Game Asset Storage: In the realm of blockchain-based gaming, soulstores can serve as secure inventories for in-game assets, ensuring that players' hard-earned items are permanently bound to their NFT characters or collectibles. - Decentralized Finance (DeFi) Applications: Soulstores can facilitate the creation of new DeFi products and services by allowing NFTs to hold and manage various cryptocurrencies and tokens. - Digital Art and Collectibles: Artists and creators can leverage soulstores to enhance the value and utility of their digital art or collectible NFTs by including additional assets or tokens within the associated soulstores. How Soulstores Work Soulstores are designed to provide a seamless and secure way to manage digital assets associated with non-fungible tokens (NFTs). Here's how the process of creating, depositing, withdrawing, and transferring soulstores works: Creating a Soulstore - Identify the NFT for which you want to create a soulstore. - Visit the soulstore creation platform (e.g., soulstore.app (https://soulstore.app) ) and search for the specific NFT. - If a soulstore hasn't been created for that NFT yet, you can initiate the creation process. - Pay the required network transaction fees (e.g., on the Radix network) to create the soulstore. - Once created, the soulstore is permanently linked to the NFT, and its address is generated. Depositing Assets into a Soulstore - Obtain the soulstore address associated with the NFT you own. - Using a compatible cryptocurrency wallet (e.g., Radix wallet), send the desired digital assets (tokens or NFTs) to the soulstore address, just like sending to any other wallet address. - The assets will be securely stored within the soulstore, bound to the associated NFT. Withdrawing Assets from a Soulstore - Access the soulstore platform and locate the soulstore associated with your NFT. - Authenticate your ownership of the NFT, typically using your private key or wallet credentials. - Select the specific assets you want to withdraw from the soulstore. - Initiate the withdrawal process, specifying the destination address where you want to receive the assets. - Pay the required network transaction fees for the withdrawal. - The assets will be transferred from the soulstore to the specified destination address. Transferring Ownership of a Soulstore When an NFT with an associated soulstore is traded or transferred to a new owner, the ownership of the soulstore and all its contents are automatically transferred as well. This process is handled seamlessly by the underlying blockchain network and smart contracts, ensuring that the assets remain bound to the NFT throughout its lifecycle. It's important to note that once a soulstore is created for an NFT, it cannot be replaced or duplicated. The soulstore remains eternally linked to that specific NFT, regardless of ownership changes or other transitions. The soulstore ecosystem leverages the decentralized nature of blockchain technology, ensuring transparency, security, and immutability in the management and transfer of digital assets associated with NFTs. Technical Details Soulstores are built on top of the Radix blockchain network and leverage several key technical concepts and components. Understanding these details is crucial for developers and users alike to fully grasp the inner workings of soulstores. Non-Fungible Global ID (NFGID) Every NFT minted on the Radix network is assigned a unique Non-Fungible Global ID (NFGID). This identifier is a combination of the NFT's resource address and its specific ID within that resource. The NFGID serves as a globally unique and immutable identifier for each NFT, ensuring that soulstores can be accurately and permanently linked to their respective NFTs. Relationship between NFTs and Soulstores There is a one-to-one relationship between an NFT and its soulstore. Each NFT can have only one associated soulstore, and once a soulstore is created for an NFT, it cannot be replaced or duplicated. This permanent and exclusive binding ensures the integrity and continuity of the soulstore's contents throughout the lifecycle of the NFT. Cost and Fees Associated with Soulstores Creating a soulstore on the Radix network involves paying a one-time network transaction fee. As of writing, the cost to create a soulstore is approximately 0.45 $XRD (Radix's native cryptocurrency). This fee covers the computational resources required to execute the smart contract and establish the soulstore on the blockchain. Once a soulstore is created, there are no recurring fees for holding or managing assets within it. However, depositing or withdrawing assets from a soulstore will incur standard network transaction fees, just like any other blockchain transaction. It's important to note that the transaction fees mentioned above are subject to change based on network conditions and potential updates to the Radix blockchain. Integration with Other Platforms While soulstores are primarily built on the Radix network, they can potentially integrate with other blockchain platforms and technologies through the use of bridges or interoperability protocols. One such integration explored was the XRD Domains (/ecosystem/xrd-domains) project, which aimed to enable human-readable domain names (e.g., cakerobo.xrd) as aliases for NFT soulstore addresses; XRD Domains has since closed. ## Slightlyiffy URL: https://radix.wiki/ecosystem/slightlyiffy Updated: 2026-09-01 Summary: Slightlyiffy is a cryptocurrency consultancy and validator operation founded by Slightlyiffy. The company offers services and expertise to individuals… Type Validator node & crypto consultancy Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Active (validator registered; site erroring) Founder Slightlyiffy ( @TwitchyHippy (https://x.com/TwitchyHippy) ) Validator validator_rdx1sdh…lm9yu9q (https://dashboard.radixdlt.com/validator/validator_rdx1sdha45dw0sj2z8c3qdrzua237nycpmdrqfnn6hcrg4hquyhlm9yu9q) Stake 42,867,757.02 XRD (rank 35 of 188 registered, 6 Aug 2026) Fee 15% since epoch 289095 (was 2.5%) Uptime 99.99% (trailing month) Website slightlyiffy.com (HTTP 500) Slightlyiffy is a cryptocurrency consultancy and validator operation founded by Slightlyiffy. The company offers services and expertise to individuals and organizations seeking guidance and evaluations on various cryptocurrency projects. They aim to provide unbiased feedback and analysis to help clients make informed investment decisions. Overview The consultancy specializes in assessing the potential of different cryptocurrency projects, providing clients with a second opinion, deep dive reports, and feedback to validate their investment choices. Whether it's evaluating the feasibility of a new project, comparing alternative cryptocurrencies, or discussing industry developments, Slightlyiffy aims to support individuals and businesses in understanding the cryptocurrency landscape. Validator Status Slightlyiffy operates as a validator node and backup node for the Radix Distributed Ledger Technology (DLT) mainnet. The company actively participates in the delegated Proof-of-Stake (dPoS) (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) consensus mechanism, securing the Radix network. Users are welcome to stake their tokens with Slightlyiffy to support network security. The company also provides basic metric monitoring for its validator node, allowing stakeholders to track its performance and rewards generated. Services and Offerings Apart from their core consultancy services, Slightlyiffy aims to contribute to the cryptocurrency community through various activities. They leverage their spare time and resources to develop simple Radix-themed games for the community's enjoyment. This demonstrates the company's commitment to engaging with the community and fostering a thriving ecosystem. On-ledger status (August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) on 6 August 2026 at epoch 332670, the Slightlyiffy validator (https://dashboard.radixdlt.com/validator/validator_rdx1sdha45dw0sj2z8c3qdrzua237nycpmdrqfnn6hcrg4hquyhlm9yu9q) is registered, accepts delegated stake, holds 42,867,757.02 XRD — rank 35 of the 188 registered validators by stake — and recorded 99.99% uptime over the trailing month. Stake units are resource_rdx1tkq…kdu4g7th and unstake claims resource_rdx1ngm…edd3czf2. The page’s previous 🟠 Dormant status was read from the website, not the ledger. The fee has changed and the page had never recorded it. The stored fee factor is 0.025, but a fee-change request to 15% became effective at epoch 289095 — 8 March 2026 — so 15% is the fee applied to rewards today. The consultancy side is the part that has stopped. slightlyiffy.com/validator.php — the exact URL the validator advertises in its own on-ledger metadata — returns HTTP 500, so the monitoring and consultancy offerings described below cannot be confirmed as still available. The node itself is delegatable by address from any Radix wallet. ## ShardSpace URL: https://radix.wiki/ecosystem/shardspace Updated: 2026-09-01 Summary: ShardSpace is an asset and portfolio management platform designed to integrate with the Radix Wallet, extending its capabilities to desktop interfaces… Type Asset & portfolio management dApp Network Radix (/contents/tech/releases/radix-mainnet-babylon) Category Finance / Wallet tooling Founder Andrew Rankine ("avaunt") – founder of Avaunt (/ecosystem/avaunt-staking) Founded 2023 Docs docs.shardspace.app (https://docs.shardspace.app) App launch.shardspace.app (https://launch.shardspace.app) X @shardspaceapp (https://x.com/shardspaceapp) ShardSpace is an asset and portfolio management platform designed to integrate with the Radix Wallet, extending its capabilities to desktop interfaces. The project is aimed at simplifying asset management within the Radix ecosystem by offering a unified dashboard for executing various cryptocurrency transactions including buying, swapping, sending, and staking. Watch the ShardSpace demo (https://youtu.be/8Y4071ytnPQ) Overview ShardSpace was conceived with the objective of leveraging the technological prowess of the Radix stack to create a comprehensive tool catering to a diverse user base comprising individuals, businesses, and developers. The platform augments the Radix mobile wallet by offering an array of features such as seamless token transfers, swapping, and liquid staking options, accessible from desktop interfaces. History ShardSpace was founded by Andrew Rankine, founder of Avaunt (/ecosystem/avaunt-staking) . Initially involved in the Radix ecosystem as a Node Runner, Andrew envisioned ShardSpace as a tool to provide a better interface for asset management on Radix. With his background in IT infrastructure, Andrew gathered a team with diverse experiences to bring the ShardSpace vision to life. ShardSpace's initial focus was the Radix Dashboard, which provided data for validators. However, recognizing the demand for a more comprehensive tool led to the evolution of ShardSpace. Development The project has been under development with a focus on creating a user-friendly dashboard that would replace the original website Radix dashboard which was primarily a static informational analytics site. Unlike its predecessor, ShardSpace is engineered to empower users with the ability to perform a variety of transactions from the convenience of their desktops. The platform's development is being spearheaded by Andrew, known as Avant within the Radix community, who transitioned from being a node validator to taking on a more front-end and service-oriented role within the ecosystem. Features - Token Swapping: Users can easily swap between various Radix ecosystem tokens. - Token Management: ShardSpace facilitates easy management of Radix ecosystem tokens, enabling users to swap between different tokens using either Limit Orders or Market Orders. - Trading Features: In collaboration with AlphaDex and Astrolescent, ShardSpace has incorporated Limit Order and Market Order trading functionalities respectively. - Liquid Staking: Beyond asset management, ShardSpace offers Liquid Staking options, enabling users to choose between Validator Staking and Stake Pool opportunities. - Developer Tools: The platform provides tools for both simple and advanced token creation as well as an Airdrop feature to aid developers in their endeavors within the Radix ecosystem. Partnerships ShardSpace has partnered with AlphaDex (/ecosystem/alphadex) for Limit Order trading and with Astrolescent (/ecosystem/astrolescent) for Market Order trading features. These partnerships aim to enrich the trading experience on the platform by offering greater control and convenience to users. Community The ShardSpace community can be engaged through its Telegram channel, where enthusiasts and prospective users can interact and stay updated on the latest developments. Additionally, the community is also active on Radix's Discord and Telegram channels where Andrew (Avant) is a notable presence. Status as of August 2026 The MVP set out in the roadmap below has shipped. Read on 14 August 2026, the product site at shardspace.app (https://shardspace.app) , the dApp at launch.shardspace.app (https://launch.shardspace.app) and the documentation at docs.shardspace.app (https://docs.shardspace.app) all resolve, and the docs carry working instructions for connecting a Radix Wallet, quick staking and unstaking, the address book, limit-order trades on AlphaDEX (/ecosystem/alphadex) , market-order trades through Astrolescent (/ecosystem/astrolescent) , the token creator, the token manager and the airdrop tool. What has not moved is the project's own public record. The published roadmap (https://docs.shardspace.app/roadmap) still runs from "November 2023 – Babylon MVP Launch" through a Q3 2023 subscription-and-fees model and a Q1 2024 pair of Ecosystem Insights and Network Explorer features to an open-ended "Q2 2024 +", with nothing added since; the two Q1 2024 features have no public delivery announcement. Of the 47 pages indexed in the documentation index (https://docs.shardspace.app/llms.txt) , 11 are still COMING SOON! placeholders, among them the top-level guides for connecting a wallet, staking XRD, swapping assets and creating a token — in each case the sub-pages beneath them carry the actual instructions. The newest post on the project blog (https://shardspace.app/blog) is dated 17 June 2025, and its recent subjects are ecosystem topics rather than product releases. The newest of those posts, "Welcome to Notix" (https://shardspace.app/blog/post/mebv0a7uanwe7i5z9y82) , introduces Notix (/ecosystem/notix) , a real-time Radix notification service that points its own community link back at the ShardSpace Telegram group. The Telegram community (https://t.me/ShardSpace) stands at 311 members. The site, the dApp and the docs all answer, so the status here remains 🟢 Active; the roadmap below is recorded as published, not as pending. Roadmap as Published The roadmap the team published alongside the launch, unchanged on the documentation site since, set out four stages: - November 2023 – Babylon MVP launch: sending assets, staking XRD, swapping through AlphaDEX or Astrolescent, native token minting, the token manager, badge creation, an airdrop tool, a transaction shopping cart, XRD Domains (/ecosystem/xrd-domains) integration, transaction history, light and dark modes, and buying XRD. - Q3 2023 – subscription service and fees: a subscription for the core features plus a transaction fee on the more advanced ones. - Q1 2024 – Ecosystem Insights and a Network Explorer: dApp and asset search with performance and historical data, alongside validator, network and account explorers. - Q2 2024 onward: iteration on existing features and the team's backlog. External Links - shardspace.app (https://shardspace.app) – product site - launch.shardspace.app (https://launch.shardspace.app) – the dApp - docs.shardspace.app (https://docs.shardspace.app) – user guides, team and roadmap - ShardSpace blog (https://shardspace.app/blog) - @shardspaceapp on X (https://x.com/shardspaceapp) - ShardSpace on Telegram (https://t.me/ShardSpace) ## Run Fly URL: https://radix.wiki/ecosystem/runfly Updated: 2026-09-01 Summary: Run Fly is a promotional video service on Radix that takes one uploaded master and returns branded social cuts in 9:16, 1:1 and 16:9. Each render is q… Run Fly Type Promotional video rendering service, billed per render Network Radix (/contents/tech/core-protocols/radix-engine) Payment token $RUNFLY (RUN.FLY), resource_rdx1t5uyf7s9rpde7pezhthsuygl0sk3gj0e09zzsvsmga69zxdd8y4lvq Token supply 1,000,000,000 fixed; mint, burn, freeze and recall all DenyAll Listed on Ociswap 20 March 2025 – Ociswap (https://ociswap.com/) Render engine Vyrol (https://vyrol.io/) (third party) Origin rly.fun (/ecosystem/rly-fun) Social X (https://x.com/rundotfly) · Telegram (https://t.me/rundotfun) Run Fly is a promotional video service on Radix (https://runfly.app/) that takes one uploaded master and returns branded social cuts in 9:16, 1:1 and 16:9. Each render is quoted and paid in $RUNFLY through the Radix Wallet (/contents/tech/core-protocols/radix-wallet) , and the job only starts once that payment confirms on ledger. The project describes the token plainly as the meter rather than a security: "In Studio, $RUNFLY pays for GPU / render utility" (https://runfly.app/faq) , and the same page answers "Is $RUNFLY an investment product?" with "No". It is unusual in the Radix ecosystem for the direction it ran: not a token issued to fund a product, but a meme coin that acquired one. The project's own timeline reads meme → community → token → NFTs → Video Engine → game (https://runfly.app/about) , and it starts at the rly.fun (/ecosystem/rly-fun) launchpad. Origin on rly.fun The mascot, a fly named Pat, "flapped straight out of rly.fun" (https://runfly.app/about) rather than out of a funding round. The ledger corroborates the lineage: read on 24 August 2026, the $RUNFLY resource carries the metadata tag rlyfun and an info_url of https://rly.fun, and its supply is exactly 1,000,000,000 tokens, the fixed per-coin supply that rly.fun mints for every launch (/ecosystem/rly-fun) . Ociswap records its listing (https://api.ociswap.com/tokens/resource_rdx1t5uyf7s9rpde7pezhthsuygl0sk3gj0e09zzsvsmga69zxdd8y4lvq) on 20 March 2025, consistent with a bonding curve that graduated and migrated its liquidity there. What followed the token was merchandise rather than protocol: a meme archive, a sold-out run of 100 "Pat in a Box" NFTs, a Telegram bot, and a browser game. The Video Engine arrived last, and the About page dates the whole arc with a single line: "Then somebody gave the fly software." (https://runfly.app/about) How a render is paid for The published flow (https://runfly.app/guide) is six steps, and the payment sits in the middle of it rather than at signup: - Connect the Radix Wallet through the Radix Connector; the connected account must already hold $RUNFLY. - Upload a master (up to 3 GB or 60 minutes) and choose formats, brand pack, captions and optional face blur or voice masking. - Press Create video, which accepts the quote and opens a payment modal showing the $RUNFLY amount and an approximate USD figure. - Approve the transfer to the project's treasury account in the mobile wallet. - The render is submitted automatically once the transaction is confirmed on the Radix Gateway (https://runfly.app/guide) . - Download the cuts; cloud copies are purged after about seven days. There is no subscription and no invoice. The FAQ also documents the failure mode that a pay-per-job model creates: if the wallet pays and the site then errors, the user is told not to pay again (https://runfly.app/faq) but to use a recovery form with the transaction id. The token as a meter $RUNFLY was read on ledger on 24 August 2026 at state version 554,435,224 (epoch 337,903). It is a fungible resource of divisibility 18 with a total supply of 1,000,000,000 and DenyAll on minter, burner, freezer and recaller as well as on each of their updater roles, so the supply is fixed by construction and cannot be reopened. Only the metadata roles remain with the owner. That has a consequence worth stating plainly for anyone pricing a render. The float is the whole market, and the market is small. Read the same day, Ociswap reported (https://api.ociswap.com/tokens/resource_rdx1t5uyf7s9rpde7pezhthsuygl0sk3gj0e09zzsvsmga69zxdd8y4lvq) a fully-diluted market capitalisation of about 428,800 XRD (roughly $386), pool liquidity of about 282,400 XRD (roughly $263), and seven-day volume of 12,948 XRD (about $11.64). Cumulative volume since the March 2025 listing was about 1.29 million XRD. A business buying renders at any scale would be a material share of that book. The project lists three venues (https://runfly.app/buy) to acquire the token, Ociswap (/ecosystem/ociswap) as the primary pool, Astrolescent (/ecosystem/astrolescent) as an aggregator and DeFiPlaza (/ecosystem/defiplaza) , and runs a staking pool on DeFiPlaza that splits a fixed weekly stash of 1 million $RUNFLY (https://runfly.app/stake) pro rata among stakers. Because the supply is not mintable, that stash is a transfer out of existing holdings rather than an emission. Powered by Vyrol The rendering itself is not built on Radix. Every page of the site carries the footer line "Powered by Vyrol (https://vyrol.io/) ", and Vyrol is an independent business-to-business video product that describes itself as "B2B video software for sales and customer teams" (https://vyrol.io/) with its own pricing, templates and CRM campaign tooling. Run Fly is the Radix-facing front for that engine: the wallet connection, the per-render pricing in $RUNFLY and the on-ledger settlement are the parts that are native to this ecosystem, while the transcoding, captioning and reframing are bought in. The split is worth noting when assessing the project's dependencies. A change of terms at Vyrol would reach the product directly, and nothing about the token's fixed supply insulates it from that. External Links - runfly.app – Run Fly, the Video Engine for Radix (https://runfly.app/) - User guide – how a render is quoted, paid and delivered (https://runfly.app/guide) - FAQ – payments, wallets and what $RUNFLY is not (https://runfly.app/faq) - Buy $RUNFLY – listed venues and the resource address (https://runfly.app/buy) - Ociswap API – $RUNFLY market data and listing date (https://api.ociswap.com/tokens/resource_rdx1t5uyf7s9rpde7pezhthsuygl0sk3gj0e09zzsvsmga69zxdd8y4lvq) - Vyrol – the third-party engine behind the renders (https://vyrol.io/) ## rlyfun URL: https://radix.wiki/ecosystem/rly-fun Updated: 2026-09-01 Summary: rlyfun (styled rly.fun ) is a permissionless meme-coin launchpad on Radix . Anyone can mint a token against a bonding curve; if the token attracts eno… rlyfun Type Meme-coin launchpad (bonding curve) Network Radix (/contents/tech/core-protocols/radix-engine) Status 🟢 Active (self-described beta, "Alpha V0.01") Appeared Late 2024 Graduation target 690,000 XRD market cap Graduates to Ociswap (/ecosystem/ociswap) Bridge partner Astrolescent (/ecosystem/astrolescent) rlyfun (https://rly.fun) (styled rly.fun) is a permissionless meme-coin launchpad on Radix (/contents/tech/core-protocols/radix-engine) . Anyone can mint a token against a bonding curve; if the token attracts enough buying to reach a fixed market-cap threshold, its liquidity is migrated automatically to Ociswap (/ecosystem/ociswap) and permanently locked. The platform describes itself as being "in beta as features are being fine tuned" (https://rly.fun/about) and labels its own code "Alpha V0.01". It was already being singled out as a project to watch by the end of its first month: Shardspace (/ecosystem/shardspace) 's Breakout 2024 review (https://shardspace.app/blog/post/dhy4vaugpsukijgdxzv0) , published 30 December 2024, named "EarlyQuest and now rly.fun" as the community projects with breakout potential. Several tokens with their own pages on this wiki launched through it, including ASCENT (/ecosystem/ascent) , Reddicks (/ecosystem/reddicks) ' DCKS, and Radix $BlueBalls (/ecosystem/radix-blue-balls) . Bonding curve and graduation Every coin launched on the platform has a fixed supply of 1 billion tokens. Per the platform's own documentation (https://rly.fun/about) , 800 million are sold into the public bonding curve and 200 million are reserved for an Ociswap precision pool. Price on the curve "rises exponentially as the token supply available decreases". The curve completes — the platform's term is graduate — at a market capitalisation of 690,000 XRD, which the site states requires roughly 240,000 XRD of inflow. On graduation, liquidity migrates to Ociswap at a market cap of about 1.1 million XRD with 400,000 XRD of liquidity, and that liquidity is "perma-locked and can never be rugged" (https://rly.fun/about) . Creators can subsequently claim the LP fees their graduated pool earns from their account page. Fees and $EARLY buybacks The platform publishes its fee schedule directly: a 0.9% buy fee, a 1% sell fee, a 1% graduation fee and a 2.5% dev reward, with the caveat that fees "may adjust over time based on activity". Unusually for a launchpad, the proceeds are not retained: after covering servers, IPFS hosting and other running costs, all XRD profit is used to buy back (https://rly.fun/about) $EARLY (/ecosystem/early) on the open market. The site states these buybacks are performed manually and without prior announcement to avoid front-running, with an automated system listed as in development. The platform's bridge — for moving value in from Solana, Bitcoin and Ethereum — is operated by (https://astrolescent.com/bridge) Astrolescent (/ecosystem/astrolescent) rather than by rlyfun itself. Scale Read on 5 August 2026, the site's own header reported 1,195 coins launched, with total value locked of 26.6M and cumulative volume of 51.0M. The two aggregate figures carry no unit on the page; the platform quotes individual market caps, its graduation threshold and its live trade feed in XRD, so they are most plausibly XRD-denominated. Individual listings on the same snapshot ranged up to roughly 200k market cap, and the most-traded coins showed cumulative volumes near 1M. Risk and caveats The platform is explicit about its own maturity. Its documentation states the code is "alpha (v0.01) and not audited" (https://rly.fun/about) . Its anti-sniping measures are deliberately undisclosed — "not made public to prevent circumvention" — so their effectiveness cannot be independently assessed. Profit-and-loss figures shown to users account for bonding-curve pricing but not transaction fees, which the site says may skew displayed results by up to 1.9%. Each coin is reachable at a short URL derived from its ticker (for example rly.fun/WOOF); the platform warns that these are case-sensitive and that duplicate tickers are disambiguated by a numeric suffix (rly.fun/WOOF-2), both of which it flags as scam vectors. As with any permissionless launchpad, listing on rlyfun implies no vetting of the token or its creator. Graduates that outgrew the curve Most coins minted here stay coins. One did not. $RUNFLY (/ecosystem/runfly) , whose on-ledger metadata still carries the tag rlyfun and an info_url of https://rly.fun, graduated to Ociswap (/ecosystem/ociswap) on 20 March 2025 (https://api.ociswap.com/tokens/resource_rdx1t5uyf7s9rpde7pezhthsuygl0sk3gj0e09zzsvsmga69zxdd8y4lvq) and has since become the billing unit for a working product: Run Fly (https://runfly.app/) , a promotional video service that quotes each render in $RUNFLY and starts the job only once the payment confirms on ledger. Its supply is the platform's standard 1 billion, fixed by DenyAll on mint, burn, freeze and recall, read at state version 554,435,224 on 24 August 2026. The path is worth recording because it runs the opposite way to the usual one. The token was not issued to fund the product; the product was attached to a token the curve had already distributed. External Links - rly.fun — platform (https://rly.fun) - About rly.fun — mechanics, fees and buybacks (https://rly.fun/about) - Run Fly – a graduated rlyfun coin turned paid video service (https://runfly.app/) - Shardspace, "Breakout 2024: End of Year Review" (30 December 2024) (https://shardspace.app/blog/post/dhy4vaugpsukijgdxzv0) ## Religant URL: https://radix.wiki/ecosystem/religant Updated: 2026-09-01 Summary: Religant was a decentralized oracle service designed to provide accurate and up-to-date price data feeds on the Radix network. The Religant Oracle pro… Type Decentralized price oracle Network Radix Founded October 2023 Website religantoracles.com (offline) Source mlabs-haskell/religant-integration-example (https://github.com/mlabs-haskell/religant-integration-example) Religant was a decentralized oracle service designed to provide accurate and up-to-date price data feeds on the Radix network. Functionality The Religant Oracle protocol operated by aggregating data from various sources. A network of data nodes queried exchanges for current transaction data and submitted this information to a contract. This contract employed a consensus mechanism to determine the aggregate price. Data nodes, running the Religant node backend software, updated the feed at regular intervals or when the new aggregate price exceeded a specified divergence threshold, currently set at 2%. This threshold ensured that the rate from the Religant oracle's feed remained within 2% of actual transaction rates on exchanges. Component API The user-facing API of the Religant Oracle was straightforward, consisting of a single method, get_price, which returned a PriceData structure containing the current XRD/USD exchange rate and a timestamp. The Option wrapper in the return type ensured type safety, with the method usually returning a valid result after the initial round of Oracle feed aggregation. Integration Guide Integrating the Religant Oracle into an application required several steps: - Defining the PriceData structure outside of the application blueprint, using various traits and types like ScryptoSbor, USDValue, and POSIXTime. - Declaring the component's API within the blueprint module using an extern_blueprint! macro. - Instantiating a reference to the global Religant component within the blueprint. - Using the Religant component's methods within the application, such as retrieving the current exchange rate and minting tokens based on this rate. Status Religant is no longer operational – the project's website (religantoracles.com) no longer resolves and the oracle feed has been discontinued. The Scrypto integration example (https://github.com/mlabs-haskell/religant-integration-example) published by MLabs (https://github.com/mlabs-haskell) remains available as a reference. For active oracle infrastructure on Radix, see OTER (/ecosystem/oter) , an optimistic oracle launched on the network. External Links - Religant Integration Example – GitHub (MLabs) (https://github.com/mlabs-haskell/religant-integration-example) ## Reizor URL: https://radix.wiki/ecosystem/reizor Updated: 2026-09-01 Summary: Reizor was an innovative platform designed to revolutionize the way fans and artists connect and interact. The platform offered a range of features th… Category Music / Fan engagement Network Radix Founded February 2023 Token REI (Reizor Token) (https://dashboard.radixdlt.com/resource/resource_rdx1t5w44wm96zsqjq4a2s2qxxarlay9hdwvcm68fudscx3262yas2xm0e) Website reizor.com (domain reassigned; archived original (https://web.archive.org/web/20231129122504/https://reizor.com/) ) Reizor was an innovative platform designed to revolutionize the way fans and artists connect and interact. The platform offered a range of features that enabled fans to not only be spectators but to actively participate in and influence live performances, and even connect with artists on a personal level. Additionally, the platform provided a social environment for fans to connect with each other and stay engaged with their favorite artists continuously. Features - Reizor Tokens (https://web.archive.org/web/20231129122504/https://reizor.com/reizorexp) : By becoming an active member of the global music community with Reizor, users could unlock exclusive perks and experiences with just a few clicks and a small number of Reizor tokens. - Hunting (https://web.archive.org/web/20231129122504/https://reizor.com/hunting) : Reizor’s AR technology allowed users to ‘hunt’ for tokens anytime, anywhere. Users received notifications when they were near a token, and they could use their camera to hunt for it. With geolocation, users could search for tokens worldwide. The platform also offered a unique way for fans to connect and earn more tokens by meeting up with like-minded fans outside of venues. By signing up, users could start earning tokens based on their location. These tokens could be used to unlock badge levels or exchanged for concert tickets. The more a user hunted, the more rewards they earned, enhancing their loyalty and engagement with the platform. - Reizor Events (https://web.archive.org/web/20231129122504/https://reizor.com/reizorexp) : The platform offered events where users could feel the thrill of the hunt and get rewarded. By signing up and earning tokens based on their location, users could unlock badge levels or exchange them for concert tickets. - Reizor Rewards (https://web.archive.org/web/20231129122504/https://reizor.com/reward) : This feature allowed users to become active members of the global music community. With just a few clicks and a small number of Reizor tokens, users could unlock exclusive perks and experiences. - Reizor Badge System (https://web.archive.org/web/20231129122504/https://reizor.com/reizorexp) : The thrill of the hunt was amplified with the Reizor Badge System. Users could sign up, earn tokens based on their location, and use these tokens to unlock badge levels or exchange them for concert tickets. - Reizor Marketplace (https://web.archive.org/web/20231129122504/https://reizor.com/marketplace) : An integral part of the platform, the Reizor Marketplace allowed users to become active members of the global music community. With just a few clicks and a small number of Reizor tokens, users could unlock exclusive perks and experiences. Team The team behind Reizor comprised individuals with diverse expertise: - Shai S.: The founder of Reizor, Shai S. (https://web.archive.org/web/20231129122504/https://reizor.com/team) , is a serial entrepreneur in the real estate and tech field with over eighteen years of experience. - Erez Eisen: A world-renowned DJ (Infected Mushroom), Erez (https://web.archive.org/web/20231129122504/https://reizor.com/team) began classical music training at a young age. - Alon Mantsur - Cybrella: With over 20 years of experience in Cyber Security, Alon (https://web.archive.org/web/20231129122504/https://reizor.com/team) brings significant business value to companies by providing cybersecurity solutions. - Sam Bamuel: A VR/AR Specialist and Creative Producer of video and XR experiences based in New York City, Sam (https://web.archive.org/web/20231129122504/https://reizor.com/team) has over 15 years of experience helping various organizations and artists tell stories with new and traditional media. Advisory Board The advisory board of Reizor (https://web.archive.org/web/20231129122504/https://reizor.com/team) included individuals like Avi Sasson, the Head of Online Marketing, Avi Weber “Esq”, the Legal Compliance of Counsel, Cebric Lebeau, the Dev and Technical Advisor, and many more. Benefits Reizor was revolutionizing the way artists and fans interact by creating a genuine connection between them. The platform offered unparalleled engagement opportunities for fans with their favorite artists. Moreover, Reizor (https://web.archive.org/web/20231129122504/https://reizor.com/home) empowered artists to recognize and connect with their most dedicated fans, transforming passive fans into active ones through recognition and engagement. The platform also allowed users to experience concerts, parties, and festivals in a stunning 4k 360-degree view, all from the comfort of their homes. Reizor Experience Reizor (https://web.archive.org/web/20231129122504/https://reizor.com/reizorexp) offered a unique experience called "ReizorExp" that was designed to increase user engagement, reward users, grow the community, and boost online reputation. The platform turned user actions into valuable tokens, and the more tokens a user accumulated, the higher their "Reizor Badge Level" became. This unlocked access to special discounts, exclusive products, and parties. Status Reizor is no longer active. Its former domain, reizor.com, has since been reassigned to an unrelated music-ticketing business and no longer represents this project – the links on this page therefore point to archived captures (https://web.archive.org/web/20231129122504/https://reizor.com/) of the original Reizor site. The Reizor token ( $RZR (https://dashboard.radixdlt.com/resource/resource_rdx1t5w44wm96zsqjq4a2s2qxxarlay9hdwvcm68fudscx3262yas2xm0e) ) remains visible on the Radix ledger. On-ledger status (August 2026) Read at the Radix Gateway on 22 August 2026 (epoch 337,086, state version 553,058,752), the Reizor token is a fungible resource of divisibility 18 carrying the symbol rzr, not "REI": 525,000,000 minted, none burned, and every authority role — minter, burner, freezer, recaller — set to DenyAll along with all four updaters. It is held by 1,213 accounts. The largest holds 485,537,120 $RZR, 92.5% of supply, and has not moved since 26 December 2024. Many of the smaller balances were written at state version 207, inside the Babylon (/contents/tech/releases/radix-mainnet-babylon) genesis batch of 28 September 2023, and have never been touched since — the token's own name metadata was set at state version 53, which places its creation in that genesis rather than after it. Its market is what a wound-down token looks like when nobody is left to trade it. $RZR sits in two Ociswap (/ecosystem/ociswap) pools holding 2,741.41 XRD and 1,645.18 XRD — 4,386.60 XRD of depth in total — and the balances in both last changed on 14 February 2026. Two further pools pair it against another token; one of those has been drained to zero on the other side. The part worth recording is what cannot now be corrected. Reizor's on-ledger metadata still gives https://www.reizor.com/ as the token's website and https://reizor.com/cryptologo/logo.png as its icon, and that domain now belongs to an unrelated music-ticketing business. The icon URL answers HTTP 200 with 43,474 bytes of text/html — the new owner's single-page app, served in place of the logo — so any wallet rendering $RZR fetches a stranger's website where an image should be. None of those metadata entries is individually locked, but the resource's owner rule is DenyAll with its updater set to None, and the metadata setter resolves to that owner. No badge exists that can satisfy it. The pointers are permanent. ## Reddicks URL: https://radix.wiki/ecosystem/reddicks Updated: 2026-09-01 Summary: Reddicks (ticker DCKS ) is a community-driven, gamified DeFi memecoin project on Radix . Its on-ledger token description defines it as "a community-dr… Type Memecoin / DeFi Ecosystem Symbol DCKS Status Active DEX RSwap (dex.reddicks.meme) Category DeFi / DEX / Token Network Radix Mainnet (cross-chain to Base & Solana) Total Supply 1,000,000,000 DCKS (fixed) Overview Reddicks (https://www.reddicks.meme) (ticker DCKS) is a community-driven, gamified DeFi memecoin project on Radix (/contents/tech/core-protocols/radix-engine) . Its on-ledger token description defines it as "a community-driven cryptocurrency powering a gamified DeFi ecosystem featuring on-chain games, protocol-owned liquidity, and cross-chain expansion from Radix to Base and Solana." The DCKS token (https://dashboard.radixdlt.com/resource/resource_rdx1t42hpqvsk4t42l6aw09hwphd2axvetp6gvas9ztue0p30f4hzdwxrp) has a fixed total supply of one billion, with minting, burning, freezing, and recall all permanently denied on-chain. RSwap Reddicks operates its own decentralised exchange, RSwap (/ecosystem/rswap) , at dex.reddicks.meme (https://dex.reddicks.meme) . It is built on DefiPlaza (/ecosystem/defiplaza) 's CALM pair contracts, with swap routing worked on together with Astrolescent (/ecosystem/astrolescent) , and it lists 65 pairs of which DCKS quotes 37. The treasury takes a 1% fee on RSwap buys and sells. A secondary game and utility token, DCKSLAP, is minted on-chain by the project's dispenser component. The venue's own liquidity is the largest thing Reddicks controls. Its deepest pair, LSULP/DCKS, held 17,293,134.15 LSULP (https://dashboard.radixdlt.com/resource/resource_rdx1thksg5ng70g9mmy9ne7wz0sc7auzrrwy7fmgcxzel2gvp8pj0xxfmf) when read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 336,462 (19 August 2026, 23:07 UTC), which was 6.5% of all LSULP outstanding and the largest holding on the network after Weft Finance (/ecosystem/weft-finance) 's. That is a dependency on CaviarNine (/ecosystem/caviarnine) , whose departure from Radix RSwap answered on 19 August 2026 (https://t.me/radix_dlt/998767) by saying it was staying. LSULP cannot be frozen or recalled by its issuer and the LSU Pool's contracts stay callable on ledger, so the position is not at risk of seizure; what a wind-down removes is the venue that quotes it. RSwap's liquidity, the two incompatible measures of it, and what the Hyperlane asset drain (/contents/history/hyperlane-asset-drain-2026) of 31 August 2026 took out of its pools are covered on its own page (/ecosystem/rswap) . Treasury and acquisitions Reddicks runs a protocol-owned treasury that earns a 1% fee on RSwap buys and sells and recycles it into protocol-owned liquidity. DCKS was originally launched on the Radix launchpad rly.fun. In mid-2026 the project began acquiring other Radix meme coins outright: it announced the acquisition of DELIVER (/ecosystem/deliver) – at the time one of the largest meme coins on Radix – accumulating roughly 60 million DELIVER in the DCKS treasury together with the token’s Ociswap (/ecosystem/ociswap) pool badge, with the stated intent of pairing it against DCKS to expand liquidity on RSwap. External Links - Reddicks – Official Website (https://www.reddicks.meme) - RSwap – Reddicks DEX (https://dex.reddicks.meme) - $DCKS – Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t42hpqvsk4t42l6aw09hwphd2axvetp6gvas9ztue0p30f4hzdwxrp) - DELIVER – RADIX Wiki (/ecosystem/deliver) ## Radnode URL: https://radix.wiki/ecosystem/radnode Updated: 2026-09-01 Summary: Radnode is a first-class validator and staking platform for Radix DLT (Distributed Ledger Technology), providing professional-grade staking services f… Radnode Type Radix validator & staking platform Validator fee 0.75% KYC Verified by the Radix Foundation Since Radix Betanet Programme Status 🟠 Dormant – radnode.io offline, no public GitHub activity X @radnode (https://x.com/radnode) Radnode is a first-class validator and staking platform for Radix DLT (Distributed Ledger Technology), providing professional-grade staking services for cryptocurrency enthusiasts, institutional investors, and developers. The platform leverages over a decade of professional full stack software development and system administration experience to provide a secure and reliable platform for Radix DLT validation. History Radnode was selected as a node runner under the Radix Betanet Programme, an initiative aimed at testing and improving the performance of the Radix DLT. The selection was based on Radnode's technical competence, experience, and its dedication to serving the Radix DLT community. Services Radnode provides a suite of services to enhance the security, reliability, and profitability of Radix DLT staking. Node Operation Radnode operates hardened nodes, which consist of high-quality, bare-metal hardware that operates in multiple availability zones. These nodes are meticulously maintained with strict server maintenance, redundancy, and fallback protocols in place. They are monitored 24/7, with instant inconsistency and issue detection alerts ensuring maximum node availability. DDoS mitigation and multi-region server tenancy further enhance the security and reliability of the service. Communication Radnode maintains multiple channels of communication with regular updates to keep its users informed. As an active member of the Radix DLT community, the platform is committed to providing users with timely and relevant information. This includes updates about server maintenance, staking performance, industry news, and more. Stake Delegation Users can delegate their stake to Radnode at a low fee of 0.75%. Radnode also partners with other qualified and KYC'd node runners, encouraging a distributed staking environment that enhances the resilience and security of the Radix DLT. Reinvestment Radnode reinvests its earnings into the continuous optimization of its node service, the development of tools for its delegators, and contributions to the Radix community. KYC Verification Radnode is fully Know Your Customer (KYC) verified by the Radix Foundation. This is to ensure the security and trustworthiness of the platform. Roadmap Radnode has an outlined roadmap for the continuous development and improvement of its services. This includes the development of a delegator platform, upgrades to the Crankshaft GaaS, and the release of a Babylon node platform. Contact Radnode can be reached through various social media channels, including Twitter (@radnode), Instagram (@radnode), and Github (github.com/radnode). For direct contact, Radnode can be reached via Telegram (@radnode) or email ( contact@radnode.io (mailto:contact@radnode.io) ). ## Radlock URL: https://radix.wiki/ecosystem/radlock Updated: 2026-09-01 Summary: RadLock is a project in the Radix ecosystem building token and liquidity locking, vesting and market-insight tools. Its stated mission is "to provide… RadLock Type Token & liquidity locking / vesting infrastructure Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Active — radlock.io (https://radlock.io) , app.radlock.io (https://app.radlock.io) and docs.radlock.io (https://docs.radlock.io) all answered 200 on 25 August 2026 Category Infrastructure / investor safety Token None. A $RLOCK token was planned in 2022 and abandoned; the project's documentation states it "does not have a token and will never have one" ( docs.radlock.io (https://docs.radlock.io/radlock/introduction) , read 25 August 2026) Founders Snjak, Beem (https://github.com/beemdvp) and Slysmik (https://x.com/Slysmik) RadLock is a project in the Radix ecosystem (/ecosystem) building token and liquidity locking, vesting and market-insight tools. Its stated mission is "to provide safety and trust on Radix" by giving investors and project builders the evidence they need to judge a new project ( docs.radlock.io (https://docs.radlock.io/radlock/introduction) ). As of August 2026 the live product centres on liquidity locking and NFT locks — the latter enabling staggered release of NFTs for presales — alongside an insights toolset for traders. Team vesting is listed on the site as "soon", and multisig, vest management, NFT vesting, a token creator and advanced insight tools sit under "Future features" ( radlock.io (https://radlock.io) , read 25 August 2026). The $RLOCK token that was never issued RadLock has no token. Between 2022 and 2026 the project reversed a planned $RLOCK presale, and its documentation now answers the question directly. Asked "When will presale (ICO) start?", the introduction page (https://docs.radlock.io/radlock/introduction) replies: "We initially considered launching a token but decided to go against it. Radlock does not have a token and will never have one" (read 25 August 2026). The same page answered the same question differently in 2022. The Internet Archive capture of 25 September 2022 (https://web.archive.org/web/20220925171656/https://docs.radlock.io/radlock/introduction) reads: "There will be a RadLock presale for the public. The date is to be decided. We will give ample notice to investors so they have enough time to unstake." The presale was still undated when the plan was dropped, so it never ran, and there were no $RLOCK airdrops. The abandoned plan is nevertheless still published beside the retraction. The docs index continues to list $RLOCK (https://docs.radlock.io/token/usdrlock) , Tokenomics (https://docs.radlock.io/token/tokenomics) , Presale (https://docs.radlock.io/token/presale) and Wen Airdrop (https://docs.radlock.io/token/wen-airdrop) , all in the future tense and all written before the Babylon (/contents/tech/releases/radix-mainnet-babylon) release. Their allocation table — 15,000,000 team, 10,000,000 company resources, 20,000,000 liquidity, 18,000,000 community rewards, 35,000,000 pre-sale and 2,000,000 initial testers and advisors — sums to exactly 100,000,000, which is the figure earlier versions of this article reported as $RLOCK's circulating supply. It was a proposed distribution, not a minted one. Services Liquidity and token locking (live) Project builders lock tokens through RadLock and can show investors the percentage locked and the length of the lock, including the liquidity-provider tokens received for supplying liquidity on a DEX (/contents/tech/core-concepts/decentralized-finance-defi) . All locks are public, and RadLock assigns a "trust score" to a token from those parameters ( docs.radlock.io (https://docs.radlock.io/radlock/services) ). NFT locks (live) NFTs and presale investment can be locked and released in stages against milestones, so a collection cannot be released to the market in one block ( radlock.io (https://radlock.io) ). Insights (live) A trader-facing toolset covering project insights, leaderboards of projects that have locked liquidity with RadLock, and real-time updates on new projects ( radlock.io (https://radlock.io) ). Vesting and launchpad (not yet released) Vesting schedules — breaking token unlocks into smaller tranches, with a multi-signature mechanism for adding, removing and updating team shares — are documented but not live; the site marks team vesting "soon" and multisig a future feature. A "Launchpad ICO" is item five of the project's Longer Term Vision (https://docs.radlock.io/radlock/roadmap) , after token locking and vesting ship. The fees page (https://docs.radlock.io/radlock/fees) reads "Coming soon…". Team RadLock is built by three founders. Snjak has worked internationally in the travel and energy sectors. Beem (https://github.com/beemdvp) (Talesofbeem) is a software developer with a background in payments and trading platforms and an interest in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) ; his code is at github.com/beemstream (https://github.com/beemstream) . Slysmik (https://x.com/Slysmik) is a creative director with two decades of work for international clients in the private and public sectors. RadLock's own site links the latter two accounts from its footer ( radlock.io (https://radlock.io) ). The project publishes a standing warning that it will never contact users by direct message, and asks that no one ever share a seed phrase or private key ( docs.radlock.io (https://docs.radlock.io/contact-us) ). External links - radlock.io (https://radlock.io) — project site - app.radlock.io (https://app.radlock.io) — the dApp - docs.radlock.io (https://docs.radlock.io) — documentation - @RadLockio (https://x.com/RadLockio) on X - t.me/radlock (https://t.me/radlock) — Telegram - Towards the Storm: interview with Beem of RadLock (https://youtu.be/zA_i38A4agc) ## Radland URL: https://radix.wiki/ecosystem/radland Updated: 2026-09-01 Summary: RadLand was an NFT marketplace on the Radix network, formed by merging VikingLand – the first Radix NFT marketplace – with Radish Square. It offered m… Type NFT Marketplace Formed From VikingLand (/ecosystem/vikingland) + Radish Square Network Radix Babylon mainnet Funding $15,000 Babylon Booster Grant (https://www.radixdlt.com/blog/babylon-booster-grants-radland) Website app.radland.io – offline ( archived (https://web.archive.org/web/20240302095709/https://app.radland.io/) ) Domain radland.io re-registered; parked and unreachable (checked 29 August 2026) Overview RadLand was an NFT (/contents/tech/core-protocols/nfts-on-radix) marketplace on the Radix network, formed by merging VikingLand (/ecosystem/vikingland) – the first Radix NFT marketplace – with Radish Square. It offered minting and trading for NFT collections on Babylon (/contents/tech/releases/radix-mainnet-babylon) , and was one of the projects funded by the $15,000 Babylon Booster Grant (https://www.radixdlt.com/blog/babylon-booster-grants-radland) programme. The marketplace is no longer operating. Per the grant announcement, RadLand supported bulk minting of NFTs, a streamlined listing flow, and a direct route for creators to claim earnings (https://www.radixdlt.com/blog/babylon-booster-grants-radland) , and let projects list and allocate NFTs that had been claimed while Radix was still on the pre-smart-contract Olympia (/contents/tech/releases/radix-mainnet-olympia) network – migrating those Olympia collections to Babylon was the team's stated priority. Formation and Team RadLand was a merger rather than a new build. Mik, founder of Radish Square and Vortexpert, and Ancient, Chiggimps and Trond of VikingLand (https://www.radixdlt.com/blog/babylon-booster-grants-radland) combined the two products – Radish Square's interface with VikingLand's backend and dev-ops – into a single marketplace, joined by BCD on Scrypto (/developers/scrypto/01-fundamentals) and Kamil on front-end. The published roadmap covered creator royalty mechanisms, a user dashboard, random minting, an auction system, sniping and trading tools, and a public API (https://www.radixdlt.com/blog/babylon-booster-grants-radland) . Archived snapshots show the marketplace live at app.radland.io through March 2024 (https://web.archive.org/web/20240302095709/https://app.radland.io/) and the marketing site through April 2025 (https://web.archive.org/web/20250419080733/http://radland.io/) . Shutdown and Domain Status RadLand is closed, and its domain has since changed hands twice over. On 30 July 2026 app.radland.io had no DNS record at all while the re-registered apex radland.io answered HTTP 200 and issued a 301 to www.earnforex.com, an unrelated forex-affiliate page carrying a utm_campaign=radland.io tag. Re-checked on 29 August 2026, the redirect itself has now gone: both radland.io and app.radland.io resolve to 185.53.179.128 on the parking nameservers ns1.dyna-ns.net and ns2.dyna-ns.net, and that host accepts TCP on ports 80 and 443 while returning nothing on HTTP and failing the TLS handshake outright on HTTPS. The marketplace subdomain has its DNS back and still serves no marketplace. Nothing at either name is connected to the project or to Radix. This is worth stating explicitly because an automated link check cannot catch it – the redirect terminates in a healthy 200 response, so a dead-link audit passes the URL. Every RadLand link on this wiki points to an archived snapshot instead. The same has happened to several other retired Radix projects, including Instabridge (/ecosystem/instabridge) and Radixnode.io (/ecosystem/radixnodeio) . The month between those two readings is the useful part. A re-registered domain is not a fixed state that a page can record once: it moved from an affiliate redirect that a link checker scores as healthy, to a host that answers at the TCP level and nothing above it, which a checker scores as a timeout. Neither reading tells a reader anything about RadLand, and only a dated one tells them that. External Links - Babylon Booster Grants: RadLand – Radix Blog (https://www.radixdlt.com/blog/babylon-booster-grants-radland) - app.radland.io – archived snapshot (March 2024) (https://web.archive.org/web/20240302095709/https://app.radland.io/) - radland.io – archived snapshot (April 2025) (https://web.archive.org/web/20250419080733/http://radland.io/) - VikingLand – predecessor marketplace (/ecosystem/vikingland) ## RadixUID URL: https://radix.wiki/ecosystem/radixuid Updated: 2026-09-01 Summary: RadixUID – tagline "United In Diversity" – is a Bulgaria-based community project in the Radix ecosystem . Published bilingually in English and Bulgari… Status 🔴 Dormant – validator deregistered; blog inactive since March 2025 Category Community / Validator Location Sofia, Bulgaria Languages English / Bulgarian Validator RadixUID Sofia (2% fee) RadixUID – tagline "United In Diversity" – is a Bulgaria-based community project in the Radix ecosystem (/ecosystem) . Published bilingually in English and Bulgarian, it operated a validator node (/contents/tech/core-concepts/validator-nodes) , promoted staking to Radix newcomers, and issued a community token. The project has been inactive since 2025. Validator RadixUID ran a validator node marketed as the "Sofia Validator", described by the team as two servers hosted in a Sofia, Bulgaria data center and operated by a professional team, charging a 2% fee on staking rewards. The on-ledger validator that lists radixuid.wordpress.com (https://radixuid.wordpress.com/) as its website – validator_rdx1s0n6dyl8cmzalflynrnevz8c26jffemp7xrd0fnc7a33ttdyx4q33q – is currently unregistered (no longer part of the active validator set) and has since been renamed on-ledger (it now reads “Lauta Army”). At epoch 331662 (3 August 2026) it still held 1,345,074 XRD in delegated stake, which earns no emissions (/contents/tech/core-concepts/staking) while the validator is outside the active set (https://docs.radixdlt.com/docs/validator) ; its stake units and unstake-claim NFT remain live, so delegators can still withdraw. Its stake and status can be inspected on any Radix validator explorer (https://www.radixscan.io/validators) . Community and token The project blog covered staking guidance ("Stake to Blockshard"), Radix Wallet connection walkthroughs, a RadixUID community token, curated project listings, and energy-transition themes tied to the "United In Diversity" branding. Content was aimed at onboarding Bulgarian-speaking newcomers to Radix rather than at shipping a specific protocol or application. Status RadixUID appears dormant. The most recent post on the project blog dates to March 2025 (https://radixuid.wordpress.com/) , and its validator node is no longer registered on the network. The page is retained for historical reference within the ecosystem directory. External Links - radixuid.wordpress.com – project blog (https://radixuid.wordpress.com/) - RadixScan – validator explorer (https://www.radixscan.io/validators) ## RadixTalk URL: https://radix.wiki/ecosystem/radixtalk Updated: 2026-09-01 Summary: RadixTalk is a community-run Discourse forum about Radix , running at radixtalk.com since December 2021. It holds 700 topics and 6,206 posts from 633… RadixTalk Type Community discussion forum ( Discourse (https://www.discourse.org) ) Status 🟢 Active, low volume Founded 23 December 2021, by the forum member Stuart Revived 30 May 2022, by Mattia (/ecosystem/mattianode) after the original operator closed it Focus Radix development, validators, staking, and the DAO transition (/contents/tech/core-concepts/radix-governance) Size 700 topics · 6,206 posts · 633 registered accounts Last 30 days 3 new topics · 21 posts · 14 people posting Measured 26 August 2026, from the forum's public Discourse API (https://radixtalk.com/about.json) RadixTalk is a community-run Discourse (https://www.discourse.org) forum about Radix (/contents/tech/core-protocols/radix-engine) , running at radixtalk.com (https://radixtalk.com) since December 2021. It holds 700 topics and 6,206 posts from 633 registered accounts. Most of the ecosystem's day-to-day conversation happens on Telegram and Discord, where it scrolls away. RadixTalk is where the ecosystem writes things down: proposals, requests for comment, node-operator troubleshooting, and the long governance threads that a chat window cannot hold. Its largest single conversation is the Radix DAO transition (/contents/tech/core-concepts/radix-governance) , and the forum is named alongside the on-ledger consultation app as the venue where those proposals are debated before a binding vote opens. History The forum's own record dates it precisely. Its first topic, the automatic About the Site Feedback category (https://radixtalk.com/t/about-the-site-feedback-category/1) post that Discourse writes on installation, is stamped 23 December 2021. Six days later the operator, posting as Stuart, welcomed the first two moderators: Faraz of Radstakes (/ecosystem/radstakes) and Mattia of MattiaNode (/ecosystem/mattianode) , the latter credited for his validator experience and his HowTo guides (https://radixtalk.com/t/welcome-mattia-from-mattianode-as-a-moderator-on-radixtalk/150) . That places the forum's founding after Olympia (/contents/tech/releases/radix-mainnet-olympia) mainnet and after the Alexandria Preview Event (/contents/history/alexandria-preview-event) , not before either. It nearly did not survive its first summer. On 13 May 2022 a member opened a thread titled Thanks Stuart! (https://radixtalk.com/t/thanks-stuart/471) on learning the forum was shutting down. Seventeen days later Mattia reopened it under RadixTalk is back! (https://radixtalk.com/t/radixtalk-is-back/476) , with Faraz as an admin and Avaunt (/ecosystem/avaunt-staking) as a moderator, on the argument that a forum keeps what chat loses: "Lots of important and useful information is lost in some Telegram group or in a Discord channel where few will see it." A relaunch contest, a badge system and an Italian and German section (https://radixtalk.com/t/radixtalk-is-opening-to-international-communities/1708) followed over the next five months. The last piece of forum infrastructure it announced was Radix Connect login (https://radixtalk.com/t/radix-connect-login-sign-in-with-your-radix-wallet/2029) in December 2024, which lets a reader sign in with their Radix Wallet (/contents/tech/core-protocols/radix-wallet) rather than a password. Where the conversation actually is The forum has thirteen top-level categories, and their sizes are lopsided. General Chat / Discussion (https://radixtalk.com/c/chat-discussion/42) is the largest at 152 topics and 1,500 posts. Questions / Help (https://radixtalk.com/c/questions/35) holds 112 topics, Validators (https://radixtalk.com/c/validators/16) 56 and Developers (https://radixtalk.com/c/developers/24) 45. The two language sections opened in 2022 never took: Italian holds eight topics, German one. The number that describes the forum today sits one level down. Governance (https://radixtalk.com/c/governance/46) holds 30 topics and 261 posts in its own right, and carries two subcategories: Radix Community DAO (https://radixtalk.com/c/governance/radix-community-dao/52) at 32 topics and 575 posts, and ILIS DAO (https://radixtalk.com/c/governance/ilis-dao/51) at five and 39. Counting the subcategories, governance runs to 67 topics and 875 posts, more than half the volume of Chat / Discussion and the deepest per-topic discussion on the site. A general Radix forum has become, by volume, a governance forum. The recent threads read the same way. Of the dozen topics most recently posted to in August 2026, the majority sit under Governance: two requests for proposals for delegate seats on the permanent Radix Accountability Council (/ecosystem/radix-accountability-council) , a call to action on the Stokenet test network that ran to 35 posts, a proposal to move the Radix website to Cloudflare, and the Consultation v2 product scope document (https://radixtalk.com/t/consultation-v2-product-scope-document/2193) for the on-chain voting app the Charter (/ideas/radix-network-dao-charter) ratification vote depends on. The technical threads that remain are of the same kind: a native privacy system for Radix V2 (https://radixtalk.com/t/proposal-a-native-privacy-system-for-radix-v2/2291) , and the community proposal to register Radix in the x402 payment standard and the CAIP namespace registry (/developers/ai-agents/ai-agents-and-x402) . Activity RadixTalk is alive and slow. Over the 30 days to 26 August 2026 the forum recorded 3 new topics, 21 posts and 14 people posting; over the 7 days to that date, one post. The newest topic on the board, a validator reporting that node release v1.3.0.5 was not working (https://radixtalk.com/t/v1-3-0-5-not-working/2327) , dates from 17 August 2026 and has no replies. Set against 6,206 lifetime posts, roughly one post in 300 was written in the last month. That rate is a poor guide to the forum's importance, because governance runs on a slower clock than chat. A request for proposals stays open for weeks and draws its replies over that span: the delegate RFP opened on 15 July 2026 and was still collecting posts on 13 August. Anyone wanting to follow the DAO transition as it is argued, rather than as it is announced, reads this board. External Links - RadixTalk (https://radixtalk.com) - RadixTalk – Governance (https://radixtalk.com/c/governance/46) - RadixTalk – Radix Community DAO (https://radixtalk.com/c/governance/radix-community-dao/52) - RadixTalk – About and site statistics (https://radixtalk.com/about) - Radix Governance – RADIX Wiki (/contents/tech/core-concepts/radix-governance) ## RadixStake URL: https://radix.wiki/ecosystem/radixstake Updated: 2026-09-01 Summary: RadixStake is a validator node operator that lets holders stake their $XRD and earn emissions rewards. Active since 2021, it runs primary and backup n… Type Staking service / validator node (/contents/tech/core-concepts/validator-nodes) operator Founded March 2021 Validator fee 14.9% (effective since epoch 288573; stored factor still reads 1.49%) Validator validator_rdx1svl…4d4wqnmv (https://dashboard.radixdlt.com/validator/validator_rdx1svlpfx0kxp5yk7h8dqrd8uzqtm7dkd0mlmerq6xsy3rng84d4wqnmv) Stake 107,947,277.39 XRD (rank 12 of 188, 7 Aug 2026) Uptime 100% (trailing month) X @RadixStake (https://x.com/RadixStake) RadixStake is a validator node (/contents/tech/core-concepts/validator-nodes) operator that lets holders stake (/contents/tech/core-concepts/staking) their $XRD (/contents/tech/core-protocols/xrd-token) and earn emissions rewards. Active since 2021, it runs primary and backup nodes with 24/7 uptime monitoring on top-tier cloud infrastructure. Overview RadixStake runs a Radix mainnet validator that delegators can stake to under Radix's delegated proof-of-stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) model. It uses server uptime monitoring to keep the node highly available, and hosts primary and backup validators with providers such as DigitalOcean and Linode for constant network connectivity. By delegating to a validator like RadixStake, holders help secure the Radix ledger while earning a share of network emissions. Choosing a validator matters: uptime and fee directly affect a delegator's share of staking (/contents/tech/core-concepts/staking) rewards. In December 2021, eligible delegators who staked a qualifying amount of XRD with RadixStake were included in the final Radical airdrop, distributed pro-rata by staked amount. Benefits Radix mainnet validator RadixStake has run nodes across Radix mainnet, Betanet, Stokenet, and the Cassandra test network. Reliable node operations RadixStake provides 24/7 monitoring and alerting to keep validator performance and uptime high. Compounding rewards Emissions are minted pre-staked to the same validator, so rewards immediately begin earning further emissions without any manual restaking. See Liquid Stake Units (/contents/tech/core-concepts/liquid-stake-units) for how staked XRD is represented on-ledger. Validator fee RadixStake charged 1.49% for most of its history. Since epoch 288573 (6 March 2026) the validator has charged 14.9%, under a fee-change request that the ledger applies in place of the stored fee factor — see Validator Nodes (/contents/tech/core-concepts/validator-nodes) for why the two differ and how to read the current figure. Staking process - Acquire $XRD (/contents/resources/how-to-buy-xrd) via an exchange. - Select a validator to delegate to – RadixStake is one option. - Stake your XRD to the validator from your Radix Wallet. - Wait for the transaction to confirm on-ledger. - Begin earning emissions rewards, which auto-compound to the same validator. On-ledger status (August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) on 7 August 2026 at epoch 332768, the RadixStake validator (https://dashboard.radixdlt.com/validator/validator_rdx1svlpfx0kxp5yk7h8dqrd8uzqtm7dkd0mlmerq6xsy3rng84d4wqnmv) is registered, accepts delegated stake, holds 107,947,277.39 XRD — rank 12 of the 188 registered validators by stake — and recorded 100% uptime over the trailing month. The operation is running. Its fee is not what this page said until now. The stored validator_fee_factor is 0.0149, and that is the figure a tool reading the field alone reports — but the same validator carries a fee-change request to 0.149 with epoch_effective 288573, an epoch that began on 6 March 2026. Once a change's epoch has passed, the engine charges the request and leaves the stored field alone until the owner asks for the next change, so RadixStake has taken 14.9% of its delegators' emissions — ten times the advertised 1.49% — for five months. The mechanism, and the 62 registered validators it currently affects, are covered under Validator Nodes (/contents/tech/core-concepts/validator-nodes) . Nothing here suggests concealment: a fee increase is a public transaction, it served its mandatory ~4,032-epoch notice period (/contents/tech/core-concepts/validator-nodes) before taking effect, and 14.9% is unremarkable among the network's larger validators. What went wrong was on this side — the page repeated a number from a stale field instead of the one the ledger charges. External Links - RadixStake – official site (https://www.radixstake.com/) - Radix Staking and Incentive Rewards Guide (https://www.radixdlt.com/blog/radix-staking-and-incentive-rewards-guide) - RadixStake on X (https://x.com/RadixStake) ## RadixScan URL: https://radix.wiki/ecosystem/radixscan Updated: 2026-09-01 Summary: RadixScan is a community-run web service for the Radix network, started in February 2023 by two validator operators as an explorer and reporting tool.… RadixScan Type Community-run Radix (https://www.radixdlt.com) network explorer, staking interface, developer console and AI agent layer Operators Michael (Vorarlberg, Austria) and Leo (Rio de Janeiro, Brazil), who run the Emmoglu Stakery validator (/contents/tech/core-concepts/validator-nodes) Founded February 2023 Deployments dashboard (https://dashboard.radixscan.io) · console (https://console.radixscan.io) · sandbox (https://sandbox.radixscan.io) · agent layer (https://ai.radixscan.io) Hosts The Radix Dashboard, Developer Console and Sandbox – dashboard.radixdlt.com and console.radixdlt.com redirect here (verified 30 July 2026) Upstream radixdlt/dapps-monorepo (https://github.com/radixdlt/dapps-monorepo) (Apache-2.0) RadixScan is a community-run web service for the Radix (https://www.radixdlt.com) network, started in February 2023 by two validator operators as an explorer and reporting tool. As of 30 July 2026 it also hosts the deployments that Radix's own first-party web applications resolve to: dashboard.radixdlt.com and console.radixdlt.com both redirect to RadixScan-operated instances of the open-source dApps monorepo (https://github.com/radixdlt/dapps-monorepo) . That makes RadixScan the de-facto home of the network's Dashboard, Developer Console and Sandbox, following the Radix Foundation (/ecosystem/radix-foundation) 's move to maintenance mode (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) in April 2026. Hosting the Radix Dashboard, Console and Sandbox The three first-party Radix web dApps – the Dashboard (network explorer and staking interface), the Developer Console (package deployment, raw manifest submission, dApp-definition setup) and the Sandbox (a dApp frontend simulator for wallet requests) – are no longer served from radixdlt.com. Resolved with a browser user agent on 30 July 2026: Original hostname Result dashboard.radixdlt.com HTTP 302 → dashboard.radixscan.io (https://dashboard.radixscan.io) , path preserved console.radixdlt.com HTTP 302 → console.radixscan.io (https://console.radixscan.io) , path preserved sandbox.radixdlt.com No DNS record; sandbox.radixscan.io (https://sandbox.radixscan.io) serves the app stokenet-dashboard.radixdlt.com HTTP 302 → dashboard.radixscan.io/ – network and path dropped stokenet-console.radixdlt.com HTTP 530 (Cloudflare edge, no origin) stokenet-sandbox.radixdlt.com HTTP 530 radixscan.com HTTP 302 → dashboard.radixscan.io Deep links survive the mainnet redirects intact: a validator page, a resource page or a transaction summary under dashboard.radixdlt.com arrives at the same route on dashboard.radixscan.io, and console.radixdlt.com/deploy-package reaches console.radixscan.io/deploy-package. Nothing a reader clicks is broken – but the destination is a community deployment, not a Radix-operated one. The redirects are issued from radixdlt.com's own edge, which only the domain holder can configure, so the handover was made deliberately rather than through a lapsed domain. No public announcement of it has been found; the redirects themselves and the upstream commit record below are the evidence. How the handover was made possible All three apps live in radixdlt/dapps-monorepo (https://github.com/radixdlt/dapps-monorepo) (Apache-2.0, SvelteKit, one apps/ directory each for dashboard, console and sandbox). Three merged changes in the first quarter of 2026 turned it from something only RDX Works could deploy into something anyone can: - #1034 (https://github.com/radixdlt/dapps-monorepo/pull/1034) (11 February 2026) removed the PostgreSQL dependency and the bookmarked-validators feature that needed it, leaving the apps with no server-side database. - #1035 (https://github.com/radixdlt/dapps-monorepo/pull/1035) (11 March 2026) added a deployment guide to the README: environment variables, the default @sveltejs/adapter-node build, and step-by-step Vercel instructions. - #1036 (https://github.com/radixdlt/dapps-monorepo/pull/1036) (13 March 2026) made the dApp definition configurable, so an operator points an instance at their own on-ledger dApp definition instead of Radix's. The published configuration surface is four public environment variables – PUBLIC_NETWORK_NAME (for example mainnet or stokenet), PUBLIC_DAPP_DEFINITION_ADDRESS, PUBLIC_AMPLITUDE_API_KEY and PUBLIC_APP_ENV. packages/ui/src/network.ts reads the first two and, when a definition address is supplied, substitutes it for both the console and dashboard defaults; leaving it empty falls back to Radix's own addresses, which the README warns "do not point to your front-end and will cause errors". Gateway (/contents/tech/core-protocols/radix-gateway-api) endpoints for each network are carried in packages/ui/src/constants.ts, so no gateway of your own is required. The repository's last commit is 13 March 2026 and its README still lists the Stokenet URLs as if they were live. Stokenet has no hosted Dashboard or Console The redirects cover mainnet only. stokenet-console.radixdlt.com and stokenet-sandbox.radixdlt.com return HTTP 530 from the Cloudflare edge with no origin behind them, stokenet-dashboard.radixdlt.com lands on the mainnet dashboard homepage with both the network and the requested path discarded, and no stokenet- hostname resolves under radixscan.io. A developer working on Stokenet (/contents/tech/releases/stokenet) therefore has no hosted explorer or console. The documented substitute is to run one: clone the monorepo, set PUBLIC_NETWORK_NAME=stokenet and a Stokenet dApp definition address, then either npx turbo run build --filter=console and node apps/console/build (Node, port 3000), or deploy apps/console on Vercel after swapping @sveltejs/adapter-node for @sveltejs/adapter-vercel. The dApp Definition Setup guide (https://docs.radixdlt.com/docs/dapp-definition-setup) covers creating the definition account itself. RadixScan's own services Alongside the hosted dApps, RadixScan has run its own tooling since 2023: - Archive node. The Emmoglu Stakery archive node, opened for third-party queries as well as powering RadixScan's own reporting. - Stake exporter. A paid report (1 XRD at launch) analysing a staking address, with the result published to IPFS and the link returned to the requester in an encrypted message. - Transaction exporter. Bulk export of an account's transaction history, aimed at accounting and tax reporting. Data partnerships were announced with RadixCharts (/ecosystem/radixcharts) , Xidar (/ecosystem/xidar) , Radix List (/ecosystem/radix-list) , XRD Domains (/ecosystem/xrd-domains) , Hermes Protocol (/ecosystem/hermes-protocol) , Z3US (/ecosystem/z3us) , Radix Talk and this wiki. Several of those projects are now dormant or closed; the pages linked here record their status. Agent layer RadixScan also operates ai.radixscan.io (https://ai.radixscan.io) , a keyless Model Context Protocol (https://modelcontextprotocol.io) server at mcp.ai.radixscan.io that lets an AI agent read ledger state and build, validate and simulate transaction manifests (/contents/tech/core-protocols/transaction-manifests) , then request a signature from the user's wallet – the server holds no keys. It is covered in detail on AI Agents and x402 (/developers/ai-agents/ai-agents-and-x402) . History and operators RadixScan was started by Michael, from Vorarlberg in Austria, who followed crypto from 2015 and began the project on the strength of Radix's prospects. Leo, from Rio de Janeiro, joined after meeting him in the Radix community; the two took part in the Cassandra tests and went on to run the Emmoglu Stakery validator (/contents/tech/core-concepts/validator-nodes) together after the Betanet phase. The radixscan.com domain was gifted to them by Wylie of Radnode (/ecosystem/radnode) and XRD Domains (/ecosystem/xrd-domains) ; it now redirects to the RadixScan dashboard. External Links - RadixScan (https://radixscan.io) - RadixScan Dashboard – explorer and staking (https://dashboard.radixscan.io) - RadixScan Developer Console (https://console.radixscan.io) - RadixScan Sandbox (https://sandbox.radixscan.io) - RadixScan Agent Layer (https://ai.radixscan.io) - radixdlt/dapps-monorepo – the source of all three hosted dApps (https://github.com/radixdlt/dapps-monorepo) - @RadixScan on X (https://x.com/RadixScan) ## RadixPlanet URL: https://radix.wiki/ecosystem/radixplanet Updated: 2026-09-01 Summary: RadixPlanet is a decentralized cryptocurrency exchange (DEX) built on the Radix network. It was developed by the RadixPlanet team to provide a fast, s… RadixPlanet Type Decentralized exchange (AMM DEX) on Radix Status 🟠 Dormant – dApp still online but frozen (last activity dated Dec 2023; no live TVL or trades) Launched 2023 (project founded 2022) Pool types Full-range & multi-token pools; NFT liquidity positions; configurable fee rules Token $PLANET (https://dashboard.radixdlt.com/resource/resource_rdx1thn6xa5vjdh5zagqzvxkxpd70r6eadpzmzr83m20ayp3yhxrjavxz5) (RadixPlanet Token V2) – fixed supply 100,000,000, mint permanently disabled On-ledger PLANET V2 token facts verified via the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1thn6xa5vjdh5zagqzvxkxpd70r6eadpzmzr83m20ayp3yhxrjavxz5) (mainnet epoch 328062, 21 Jul 2026) RadixPlanet is a decentralized cryptocurrency exchange (DEX) built on the Radix network. It was developed by the RadixPlanet team to provide a fast, secure, and easy way to trade tokens on the Radix ledger. RadixPlanet demo video (https://youtu.be/fYNlQ0AHbAA) Introduction The RadixPlanet DEX launched in 2023 and utilizes the unique capabilities of the Radix protocol to offer features not found in other DEX platforms. Key highlights of RadixPlanet include: - Support for creating liquidity pools with flexible rules and incentives - Options for public and private liquidity pools - Liquidity mining rewards distributed based on trading volume to incentivize providing liquidity where it is most useful - Configurable swap fees and royalty fees to support development - An integrated treasury to fund future development through collected fees - A two-way Bitcoin bridge to allow wrapping Bitcoin for use on Radix The RadixPlanet DEX aims to leverage the scalability, security, and composability of the Radix network to create a next-generation DEX for trading tokens and providing liquidity. The project is led by the RadixPlanet team and supported by the Radix community. Features Full-Range Pools RadixPlanet utilizes full-range liquidity pools at launch. Full-range pools allow the price of tokens within the pool to fluctuate freely based on supply and demand, from zero to infinity. This helps ensure that liquidity does not completely dry up on one side of the trading pair. Full-range pools adhere to the standard formula: x * y = k, where x and y represent the available liquidity of the two tokens and k is a constant. This formula maintains the invariant relationship between the two sides of the pool as trades occur. Compared to concentrated liquidity models, full-range pools carry the risk of larger impermanent loss for liquidity providers due to higher price volatility. But they allow any price range to be supported. Multi-Token Pools RadixPlanet also supports multi-token liquidity pools at launch. Multi-token pools contain three or more tokens rather than the typical two tokens. When executing a trade, two tokens within the pool are selected. The smart contracts will handle the pricing and exchange between those two tokens based on their available liquidity in the pool, while the other tokens are unaffected. Multi-token pools provide flexibility in the trading pairs that can be supported. They also reduce the need for multiple two-token pools between a group of tokens. However, they can introduce additional complexity in valuing the underlying assets. Private/Public Liquidity RadixPlanet allows liquidity pool creators to configure pools as either public or private. This provides flexibility in how pools can be structured. Public pools allow anyone to provide liquidity. They offer full transparency to liquidity providers, as the parameters of the pool cannot be changed after creation. Public pools help attract liquidity by being open and non-exclusive. Private pools require approval to provide liquidity. Only addresses that have been granted a pool membership by the manager can add funds. Private pools give the creator more control over the liquidity sources and management. They can be useful when trying to limit access or create exclusive trading environments. Adding Liquidity Adding liquidity to pools on RadixPlanet is handled through Non-Fungible Tokens (NFTs) representing liquidity positions rather than typical fungible LP tokens. When first supplying assets to a pool, a new NFT “liquidity badge” is minted to uniquely represent the position. Users can later add to an existing position to increase the amount of liquidity represented by that NFT. This helps simplify tracking returns from a given liquidity amount over time. NFT liquidity positions integrate with other signature RadixPlanet features like withdrawable earnings. Owners can manage or move positions while retaining associated earnings claims from collected fees. Customizable Fee Rules RadixPlanet allows custom fee rules to be set on new liquidity pools. Creators can choose different fee types, collection methods, and beneficiary addresses to incentivize providing liquidity tailored to their use case. Available fee rule configurations include: - Fee Type - Percentage of trade amount - Fixed token amount - Collection Method - Add to liquidity - Route to fee address - Fee Token - Specify which token fee is collected in - Fee Amount - Percentage or fixed token quantity Multiple fee rules can be stacked to split fees between liquidity providers, pool creators, treasury deposits, etc. Flexible fee rules allow unique liquidity pool configurations and incentives. Automatic Re-Investing Fee rules on RadixPlanet can enable automatic re-investing of collected fees back into liquidity pools. By using an "Add to Liquidity" collection method, swap fees get routed directly back into the pools they came from rather than external addresses. This incrementally increases liquidity over time through usage without manual claiming needed. Automatic re-investing helps reduce impermanent loss, boosts liquidity depth, and can increase volume as fees fund further trades. Pools with active trading volume particularly benefit from compounding effects over time. Withdrawable Earnings RadixPlanet allows pool creators to configure fee rules with "Withdrawable Earnings" collection methods. This enables liquidity providers to claim fees without reducing their position sizes. Rather than going directly back into pools, fees sent to Withdrawable Earnings get routed to a separate vault. Liquidity providers can then periodically claim their pro-rata portion of fees based on their share of the pool, without impacting their underlying liquidity. By retaining principal while accessing returns, providers can compound gains over longer periods. This helps reduce impermanent loss risks from reducing positions after price volatility. Periodic withdrawals also give incremental income without needing to exit positions fully. Liquidity Mining Rewards RadixPlanet distributes volume-based liquidity mining rewards using unique NFT voucher tokens. These vouchers - Planet_LM - are minted on every trade and deposited to liquidity providers to later redeem for the native Planet token. 10x Planet_LM vouchers enter pools per trade while 1x goes to the trader. This incentivizes providing liquidity in active pools where rewards accrue more quickly from higher volumes. Periodically, vouchers can be redeemed for Planet tokens, similar to many "staking" mechanisms. Volume-based rewards promote network effects and compliment liquidity provision where it is most useful. As more activity occurs in a pool, providers earn greater rewards from the increased trades. This aligns incentives across traders and liquidity suppliers. Protocol Fees RadixPlanet charges protocol fees on trades to support ongoing development and sustainability of the DEX. These include: Swap Fees All pools have a 0.2% swap fee that gets split between the RadixPlanet team and the platform treasury. These small fees on every trade provide revenue to expand features, integrate partners, and improve the trading experience. Royalty Fees An additional royalty in XRD is levied based on the protocol version the pool resides on. This aligns incentives for users to upgrade to the latest contracts for better fees and features. - v1.0.0 pools: $0.02 per trade - v1.1.0 pools: $0.03 per trade - v1.1.1 pools: $0.03 per trade Royalty fees go to the RadixPlanet team and are used to fund ongoing development. Treasury The RadixPlanet treasury accumulates fees from protocol charges to fund community initiatives. Governance features will help determine allocation of treasury funds to grow the platform and ecosystem. Revenue directed to the treasury comes from: - 0.2% of Swap Fees from all pools - 100% of Royalty Fees from protocol upgrades - Any donations from partners/users The decentralized treasury will allow $PLANET holders to guide budget decisions. Transactions Manifests To interact with the RadixPlanet DEX protocol, wallet transactions require specialized manifests to encode instructions properly. Common manifests used include: - Create pool - Add liquidity - Remove liquidity - Swap tokens - Claim fees - Redeem vouchers These allow end users to access liquidity pools, supply assets, trade tokens, earn yields, and more. RadixPlanet provides template transaction manifests for these core functions that developers can use to build customized experiences via alternative frontends. Having ready-made manifests speeds up integration. For example, the add liquidity manifest encodes details like: - Pool ID - Token types & amounts - Whether to create a new position - Fee rules acceptance With template manifests available, developers can focus more on crafting compelling interfaces rather than low-level protocol interactions. Bitcoin Bridge RadixPlanet offers a two-way bridge for Bitcoin between the Radix network and other blockchains. This allows users to wrap their BTC for use directly in DeFi applications on Radix. The Bitcoin bridge locks up native BTC and mints a wrapped token (wBTC) to represent Bitcoin on Radix. The wBTC can then be traded in DEX pools, lent, used as collateral, and more - unlocking Bitcoin to work inside the Radix DeFi ecosystem. The process can also be reversed by burning wBTC in exchange for unlocking native BTC back to its original blockchain. This provides liquidity for Bitcoin holders to move between networks while accessing Radix-based financial transactions. Initially, the Bitcoin bridge only supported manual wrapping/unwrapping of BTC with assistance from the RadixPlanet team. Over time, features will expand for direct cross-chain interoperability, starting with public canisters to automate the minting/burning of wrapped tokens. Native support for major external assets like Bitcoin illustrates the flexibility and hybrid capabilities of the Radix protocol for connecting external blockchains to its DeFi platform. Status RadixPlanet is dormant. Its dApp (https://radixplanet.com) remains online but is frozen – the dashboard shows no live total value locked or trades and its most recent notice is dated December 2023. The $PLANET V2 token (https://dashboard.radixdlt.com/resource/resource_rdx1thn6xa5vjdh5zagqzvxkxpd70r6eadpzmzr83m20ayp3yhxrjavxz5) stays on-ledger with a fixed 100,000,000 supply and minting permanently disabled. Traders on Radix now use active DEXs such as Ociswap (/ecosystem/ociswap) and DefiPlaza (/ecosystem/defiplaza) . ## RADIX REVIEW URL: https://radix.wiki/ecosystem/radix-review Updated: 2026-09-01 Summary: Radix Review was a community-run podcast and livestream covering the Radix ecosystem, billed as “the #1 community podcast on Radix.” Episodes were rec… Radix Review was a community-run podcast and livestream covering the Radix (/contents/tech/releases/radix-mainnet-babylon) ecosystem, billed as “the #1 community podcast on Radix.” Episodes were recorded live every Friday at 7PM UTC on X and published to major podcast platforms. Overview The show highlighted Radix projects, protocol news and community developments in a conversational, entertainment-first format (episodes carried a “not financial advice” disclaimer). It was hosted by @FelixXRD (https://x.com/FelixXRD) alongside co-host @NFTMachinist. Status As of 2026 the show appears dormant: no new episodes have been published since late 2025 on its Spotify (https://open.spotify.com/show/1FuJLhPqhSg5HTU5ZRQuf2) and Apple Podcasts (https://podcasts.apple.com/us/podcast/radix-review/id1742273477) feeds, and co-host @NFTMachinist’s X account is no longer active. The back catalogue remains available across podcast platforms via linktr.ee/radixreview (https://linktr.ee/radixreview) . Radix Review Type Community podcast / livestream Host @FelixXRD (https://x.com/FelixXRD) (co-hosted by @NFTMachinist, account since removed) Format Recorded live Fridays 7PM UTC on X; audio on major podcast platforms Latest No new episodes published since late 2025 Listen Spotify (https://open.spotify.com/show/1FuJLhPqhSg5HTU5ZRQuf2) · Apple Podcasts (https://podcasts.apple.com/us/podcast/radix-review/id1742273477) · all links (https://linktr.ee/radixreview) ## Radix List URL: https://radix.wiki/ecosystem/radix-list Updated: 2026-09-01 Summary: Radix List is a community-run directory of projects built on Radix , running at radixlist.com . It was built by Chris of pica.finance and Kansuler, bo… Radix List Type Community project directory Status 🟠 Dormant – served and reachable, no new listing since February 2026 Created by Chris of pica.finance (https://pica.finance) and Kansuler Listings 272, read from the site on 26 August 2026 Last listing added 23 February 2026 (PokerXRD) Submissions Open, via a Google Form linked from every page Social Telegram (https://t.me/radixlist) · @Radix_List (https://x.com/Radix_List) Radix List is a community-run directory of projects built on Radix (/contents/tech/core-protocols/radix-engine) , running at radixlist.com (https://radixlist.com) . It was built by Chris of pica.finance (https://pica.finance) and Kansuler, both credited in the site's footer, and it held 272 entries when read on 26 August 2026. Each entry is a card: a name, a one-line description, and a handful of hashtags. The front page filters on nine of them – Babylon, Metaverse, NFT, Trading, Scrypto, Airdrop, Dashboard, Validator and Token – and sorts by newest, oldest or name. Anyone can propose a listing or correct an existing one through a Google Form linked from every page, and a separate promotion page sells a placement. The listings themselves come from a hosted content backend rather than the site's code, which is why the catalogue kept growing long after the front end was last rebuilt. What it lists Radix List sets a low bar on purpose, and that is what makes it useful and what limits it. A card costs its owner one form submission, so the directory reaches into corners a curated index does not: validator nodes, one-person NFT drops, Telegram giveaway bots, browser games, and a long tail of memecoins. Its recent additions overlap the projects this wiki covers in depth, among them PokerXRD (/ecosystem/pokerxrd) , Mox Studio (/ecosystem/mox-studio) , NFTwars (/ecosystem/nftwars) and WeAreMonstas (/ecosystem/wearemonstas) . The same low bar means the directory records what a project said about itself on the day it applied, and never revisits it. Entries stay up after their projects close, descriptions keep the tense they were written in, and nothing on a card tells a reader which of the two it is. Radix List is a submissions log, and it is best read as one. Activity The site is served, the form still answers, and the catalogue has stopped moving. Radix List announces every addition to its Telegram channel (https://t.me/radixlist) in a fixed format, one "New listing!" post per entry, which turns the channel into a dated record of the directory's growth. The newest post in that record announces PokerXRD (https://www.radixlist.com/item/pokerxrd) and is dated 23 February 2026. The shape of the tail matters more than the last date. Three listings arrived within five days in February 2026, and the one announced before them was NFTwars (/ecosystem/nftwars) on 28 July 2024, nineteen months earlier. Six months have passed since. Read the channel end to end and the directory announced three new entries in twenty-five months, which puts almost the whole catalogue on the far side of the ecosystem it describes. External Links - Radix List (https://radixlist.com) - Radix List – announcement channel (https://t.me/radixlist) - Radix List on X (https://x.com/Radix_List) - Radix Ecosystem directory – RADIX Wiki (/ecosystem) ## Radix Kingdoms URL: https://radix.wiki/ecosystem/radix-kingdoms Updated: 2026-09-01 Summary: Radix Kingdoms is an on-chain strategy game on Radix mainnet, tagged "Fight your crypto wars on the Radix Network." Players minting a Kingdoms obtain… Overview Radix Kingdoms (https://radixkingdoms.com) is an on-chain strategy game on Radix (/contents/tech/core-protocols/radix-engine) mainnet, tagged "Fight your crypto wars on the Radix Network." Players minting a Kingdoms obtain a NFTs (/contents/tech/core-protocols/nfts-on-radix) that grants control over the kingdom actions. Mine and wage war with other players to increase your $KGLD (https://dashboard.radixdlt.com/resource/resource_rdx1t49stmluppglp8ul6tv4cncs5qzvytkmvfjmmq3jkncf6dyj3qxvsu) wealth. On-Chain Design - Kingdoms as NFTs – a "Kingdom key" NFT (KDMKEY) grants ownership of a kingdom component; andd is needed to authorize actions, with a total supply of 598 minted. - Kingdom Gold (KGLD) – a utility token (https://dashboard.radixdlt.com/resource/resource_rdx1t49stmluppglp8ul6tv4cncs5qzvytkmvfjmmq3jkncf6dyj3qxvsu) minted and burned by gameplay through the game's manager component, with a total supply of 21,713,817.35 as of 6 August 2026 (see below). - Randomness – a "Random service" NFT (KRND) is created for time delayed actions, mostly conflict handling between kingdoms. This NFT is created on the initiation of the action and burned on event handling. The fee for the handling is paid out of a prepaid account that is part of each kingdom, so the oracle acount does not run out of funds. - Real Randomness – the action that initiates a random action is directly bound to the transaction performed by the orcale, and is totally outside of the players influence. On-Ledger Reading (6 August 2026) Read live from the ledger at epoch 332574, Kingdom Gold (https://dashboard.radixdlt.com/resource/resource_rdx1t49stmluppglp8ul6tv4cncs5qzvytkmvfjmmq3jkncf6dyj3qxvsu) has a total supply of 21,713,817.35 KGLD at 18 decimal places. That is roughly 1.19 million lower than the ~22.9 million this page recorded on 8 July 2026, and the direction matters more than the figure. KGLD can only be minted by a specific badge and can be burned by that badge or by the game's own component, so supply falls when gameplay consumes gold faster than it is issued — net burning over a 29-day window is direct evidence the game is being played, which a website returning HTTP 200 is not. The authorities (/developers/scrypto/03-authorization-and-badges) on the resource are worth stating precisely, because they describe the game's trust model: - Minting requires one unit of the badge resource resource_rdx1ng3x…uzj0jk2w, and that rule is immutable — the mint condition can never be changed or widened. - Burning is satisfied by either that same badge or a specific non-fungible, (https://dashboard.radixdlt.com/resource/resource_rdx1ntjxf4xrtmslncf8a8dqt55txhd5n3e6yk2egjtnsrzf0e5s0m5fyw) , held in the CLAVIS (https://dashboard.radixdlt.com/resource/resource_rdx1ntjxf4xrtmslncf8a8dqt55txhd5n3e6yk2egjtnsrzf0e5s0m5fyw) collection. The burn rule remains mutable. - Freezing and recall are both deny_all and immutable, so no party — developer included — can seize or lock a player's gold. Withdraw and deposit are unrestricted. CLAVIS is described on-ledger as an “NFT to be used for Radix Manifest Games” and had a supply of nine at the time of reading, which places Radix Kingdoms inside a small shared badge collection rather than as a standalone deployment. External Links - Radix Kingdoms – Official Website (https://radixkingdoms.com) - $KGLD – Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t49stmluppglp8ul6tv4cncs5qzvytkmvfjmmq3jkncf6dyj3qxvsu) - Radix Kingdoms – Telegram Channel (https://t.me/radixkingdoms) Type On-Chain Strategy Game Symbol KGLD (Kingdom Gold) Status Active Category Game Network Radix Mainnet Kingdoms Minted ~598 ## Radix $BlueBalls URL: https://radix.wiki/ecosystem/radix-blue-balls Updated: 2026-09-01 Summary: Radix $BlueBalls is a grassroots meme coin on Radix . The project states it has "no mission other than to become the most awesome grassroots meme coin… Radix $BlueBalls Type Grassroots meme coin Network Radix DLT Team RadixBlueBalls community Website sites.google.com/view/radix-blueballs (https://sites.google.com/view/radix-blueballs/home) Radix $BlueBalls (https://sites.google.com/view/radix-blueballs/home) is a grassroots meme coin on Radix (/contents/tech/core-protocols/radix-engine) . The project states it has "no mission other than to become the most awesome grassroots meme coin on Radix" and to "support every other Radix project, regardless of what it is." The name riffs on the community in-joke of "Radix blue balls" – the recurring anticipation of Radix's potential that never quite arrives. Community The project runs community channels on Telegram (https://t.me/RadixBlueBallsXRD) , X, Instagram and Quack Space (/ecosystem/quackspace) , and publishes a directory of other Radix ecosystem projects and communities – surfaced below through an embedded Radix Rolodex (/ecosystem/radix-rolodex) Deck. The $BlueBalls token on-ledger $BlueBalls is a fungible resource with a fixed supply of 1,000,000,000 and 18 decimal places. Every authority on the resource (https://dashboard.radixdlt.com/resource/resource_rdx1t5kfjyyysxj7z0tjvhur48mjfff26knyj3hzajr6u0ld3wya0mxglz) — minter, burner, freezer and recaller — is set to deny_all, and the rule set is locked, so no party can mint, burn, freeze or claw back the token or grant themselves the ability to later. The on-ledger description restates the project's premise: the feeling of "get[ting] all excited about Radix about to explode, only for it to not happen". The token was launched through rlyfun (/ecosystem/rly-fun) , the Radix meme-coin launchpad, which remains the project link carried in its Ociswap (/ecosystem/ociswap) listing. It has been listed there since 11 December 2025. As of 5 August 2026 it traded near US$0.000002 against a pool of roughly US$676, with about US$5,125 of cumulative volume since listing and US$3.73 in the preceding seven days. ## Radical Staking URL: https://radix.wiki/ecosystem/radical-staking Updated: 2026-09-01 Summary: Radical Staking is a validator node on the Radix public network. It has run since the Olympia Betanet launch on 28 April 2021, making it one of the ne… Radical Staking Type Validator node on Radix (/contents/tech/core-protocols/radix-engine) mainnet Status 🟢 Active — registered, accepting delegated stake Founded 28 April 2021 (Olympia Betanet) Operator Wilson Verardi, Jason Lee, John Buell Validator address validator_rdx1sdzyh7reza3k7y9cyu93ghnak2n89uhugwc072kxrl7unsxgsacx8j Total stake 148,990,076 XRD (rank 8 of 188, epoch 338766, 27 Aug 2026) Validator fee 1% Uptime 100% (one month to 27 Aug 2026) Stake-unit holders 8,700 accounts Radical Staking is a validator node on the Radix (/contents/tech/core-protocols/radix-engine) public network. It has run since the Olympia Betanet launch on 28 April 2021, making it one of the network's original operators, and it is currently the eighth-largest validator by delegated stake. Like every Radix validator it earns emissions in proportion to the stake delegated to it, keeps a declared percentage as a fee, and distributes the remainder to its delegators through the stake units they hold. What distinguishes one validator from another is its fee, its uptime, and how much of the network's stake it has attracted; all three are readable from the ledger, and the figures below were taken from it rather than from the operator. On-ledger position Measured against Radix mainnet at epoch 338766 (https://radixscan.io/validator/validator_rdx1sdzyh7reza3k7y9cyu93ghnak2n89uhugwc072kxrl7unsxgsacx8j) (27 August 2026): - Total stake — 148,990,075.76 XRD, ranking it 8th of the 188 registered validators, behind SRWA, Astrolescent (/ecosystem/astrolescent) , Reddicks Node, Weft (/ecosystem/weft-finance) , Ocinode, Jazzer9F and the DefiPlaza (/ecosystem/defiplaza) investment node. - Validator fee — 1%, charged on emissions before they reach delegators. That is at the low end of the active set, where declared fees run from 0% to 100%. - Uptime — 100% over the month to 27 August 2026, with no missed proposals recorded in that window. - Stake units — the validator's stake-unit resource resource_rdx1t5zggncc2k5qcq26rlw9l9fr7whdar2l9ytugwy9gsvmsd6aeecrcj is held by 8,700 accounts. These figures do not match the ones the operator publishes. radicalstaking.com (https://www.radicalstaking.com/) states 125,245,039 XRD in active stake and 8,753 delegations — a stake figure roughly 19% below the ledger, and a participant count 53 above the closest on-ledger measure. The site carries no date, so the divergence most likely reflects a page that has not been refreshed rather than a dispute about the numbers. The "#1 by delegators" claim The operator describes the node as the "#1 Radix validator node by number of delegators" (https://www.radicalstaking.com/) . The ledger does not record a delegator count directly. What it records is who holds the validator's stake units, and because stake units are ordinary transferable fungible tokens, that count is a proxy rather than the figure itself — an account can hold stake units it never staked for, and a delegator who moves them keeps the delegation while losing the holding. Read as that proxy, the claim is defensible but narrow. Across the twelve largest validators by stake, Radical Staking's 8,700 stake-unit holders is the highest of the actively-marketed nodes, ahead of Jazzer9F on 8,654 — a margin of 46 accounts, well inside the range a week of ordinary staking activity can move. Every other node in that group is an order of magnitude behind: SRWA 3,051, Weft 1,423, CaviarNine-1 1,608, Ociswap's Ocinode 2,176, XSEED 982, Astrolescent 939. One validator sits far above all of them and illustrates why the proxy needs care. Radstakes' stake unit is held by 121,414 accounts against 93.1M XRD of stake, an average of 766 XRD each; the holdings are dominated by dust positions last touched at state versions 9 and 10, which is to say at the genesis of the Babylon ledger, when Olympia stake was migrated wholesale. Those are historical balances, not people choosing a validator today. Operators The node is run by a named team rather than anonymously, which is unusual enough among Radix validators to be worth recording. Per the operator's own site (https://www.radicalstaking.com/) : Wilson Verardi (chief executive and enterprise architect), who took the node into the Olympia Betanet and previously ran a Cardano stake pool; Jason Lee (system administrator), a UC Berkeley computer science graduate working in IT since 1994; and John Buell (senior adviser), with a long background in UNIX and Linux administration. The validator's owner badge is held by account_rdx169ycp5uvsm7wd4cs5xwzzxrw6ykk3v9mnjdrrzuezmcl6gkm37j9cz, the account with authority to change the node's fee, registration and metadata. Ecosystem support Alongside running the node the operator sponsors and works with other Radix projects. The partners it currently names are Ociswap (/ecosystem/ociswap) , Radix Collection, Delphibets (/ecosystem/delphibets) , Cerby, Arcane Labyrinth (/ecosystem/arcane-labyrinth) and SRWA (/ecosystem/srwa) . The node also states that it assists smaller validators in the ecosystem, which it frames as a decentralisation measure — a large validator has an interest in stake not concentrating further, since Radix consensus weights a validator's influence by the stake delegated to it. Earlier versions of this page also listed XSEED (/ecosystem/xseed) and Maya Protocol as partners. Neither appears on the operator's current partner list, and the description previously given for Maya Protocol — a stablecoin platform — was wrong in any case: Maya Protocol (/ecosystem/maya-protocol) is a cross-chain liquidity network. External links - radicalstaking.com (https://www.radicalstaking.com/) — the operator's site - Radical Staking on RadixScan (https://radixscan.io/validator/validator_rdx1sdzyh7reza3k7y9cyu93ghnak2n89uhugwc072kxrl7unsxgsacx8j) — live stake, fee and uptime See also - Validator Nodes (/contents/tech/core-concepts/validator-nodes) — what a Radix validator does and how the active set is chosen - Liquid Stake Units (LSUs) (/contents/tech/core-concepts/liquid-stake-units) — the transferable token a delegator receives, and why its holder count is not a delegator count - Staking (/contents/tech/core-concepts/staking) — delegation, emissions and validator fees ## Project $Now URL: https://radix.wiki/ecosystem/project-now Updated: 2026-09-01 Summary: Project $NOW was a specialized marketing agency focused on the Radix blockchain ecosystem . The company positioned itself as a pioneer in organic cont… Project $NOW Type Marketing agency (Radix ecosystem) Status 🔴 Inactive (dormant since 2025) Founded 2024 Token $NOW (https://dashboard.radixdlt.com/resource/resource_rdx1th42ay5yjg6ujak3ygnc6yerzx0ld622chz5tlnwjr7elcp3u48l2q) (fixed supply 1,000,000,000) Related DefiPlaza (/ecosystem/defiplaza) · OciSwap (/ecosystem/ociswap) Project $NOW was a  specialized marketing agency focused on the Radix blockchain ecosystem (https://projectnow.io/) . The company positioned itself as a pioneer in organic content marketing for cryptocurrency projects, particularly those built on the Radix Chain.  Project $NOW distinguished itself from traditional agencies by eschewing conventional approaches like flashy advertisements or expensive influencer partnerships (https://projectnow.io/) , instead concentrating on what they termed "real powerful marketing." Status: Project $NOW is no longer active. Its public channels have been dormant since 2025 – the last substantive team activity on its Telegram group (https://t.me/projectnowxrd) dates to early 2025, after which it went quiet – and the agency no longer takes on new work. The $NOW token (https://dashboard.radixdlt.com/resource/resource_rdx1th42ay5yjg6ujak3ygnc6yerzx0ld622chz5tlnwjr7elcp3u48l2q) remains on the Radix ledger as a fixed-supply (1,000,000,000) legacy asset with immutable mint/burn authorities, but is no longer actively developed. The description below is retained for historical reference and reflects the project at its peak of activity. https://youtu.be/R920rS2fotU?si=e-VAP29ELviB8gdM (https://youtu.be/R920rS2fotU?si=e-VAP29ELviB8gdM) Introduction The agency offered a comprehensive suite of services designed to support and promote projects within the Radix ecosystem. These services included  social media management, branding, design, video production, and community engagement strategies (https://projectnow.io/services/) . Project $NOW emphasized its expertise in creating and managing organic content marketing campaigns, leveraging its network and experience to elevate projects in the competitive cryptocurrency space. A key feature of Project $NOW's business model was its  native cryptocurrency token, $NOW (https://projectnow.io/token/) . This token served multiple purposes within the Project $NOW ecosystem, including providing utility for accessing services and participating in the platform's economy. The company committed to  reinvesting 10% of its revenue back into the $NOW token or allocating it for active marketing campaigns (https://projectnow.io/) , aiming to create a sustainable and growing ecosystem. Project $NOW also collaborated with the  Radix Community Council to offer marketing grants to selected projects on the Radix Network (https://projectnow.io/rcc/) , further cementing its role as a central player in the Radix ecosystem's growth and development. At its peak in 2024, Project $NOW served as a marketing resource for projects seeking to establish and grow their presence within the Radix ecosystem and the wider world of decentralized finance (DeFi). It wound down its operations over the course of 2025. Background The specific founding date and detailed history of Project $NOW are not explicitly stated in the available information. However, the company's mission and vision were clearly articulated through its various services and approaches to marketing in the cryptocurrency space. Project $NOW was established with the primary goal of rewriting the rules of cryptocurrency marketing, specifically for projects on the Radix Chain (https://projectnow.io/) . The company's founders recognized a gap in the market for effective, organic marketing strategies tailored to the unique needs of blockchain and cryptocurrency projects. The vision of Project $NOW was rooted in the belief that traditional marketing approaches, such as flashy advertisements and expensive influencer deals, are not the most effective ways to promote cryptocurrency projects. Instead, the company focused on pioneering organic content marketing strategies (https://projectnow.io/) , leveraging its expertise and network to help projects grow and thrive in the dynamic world of cryptocurrency. Project $NOW's approach was built on a foundation of over 20 years of combined experience in the field (https://projectnow.io/) , although the specific backgrounds of the founding team members are not detailed in the available information. This extensive experience informed their strategy of creating meaningful, engaging content that resonates with the cryptocurrency community. The company's mission extended beyond mere promotion. Project $NOW aimed to be a central hub for Radix projects, fostering community engagement and facilitating growth within the ecosystem (https://projectnow.io/) . This was evidenced by their development of the $NOW token, which served as both a utility token for accessing services and a means of community engagement through features like giveaways and staking rewards. Furthermore, Project $NOW demonstrated a commitment to the broader Radix ecosystem through its partnership with the Radix Community Council to provide marketing grants to promising projects (https://projectnow.io/rcc/) . This initiative underscored the company's dedication to nurturing the growth of the entire Radix network, not just individual clients. In summary, while the specific historical details of Project $NOW's founding are not available, the company's background was characterized by a strong vision for revolutionizing cryptocurrency marketing, a wealth of industry experience, and a commitment to fostering growth within the Radix ecosystem. Services Project $NOW offered a comprehensive suite of marketing and promotional services tailored specifically for projects on the Radix blockchain. These services were designed to help cryptocurrency projects gain visibility, engage with their community, and grow their presence in the competitive digital asset space. 3.1 Marketing Services Project $NOW provided a range of specialized marketing services (https://projectnow.io/services/) for cryptocurrency projects: - Video Production: The agency brought projects to life through captivating visuals and storytelling (https://projectnow.io/services/) . This service included creating promotional videos, explainer content, and other video materials to help projects communicate their value proposition effectively. - Social Media Management: Project $NOW developed and implemented social media strategies to enhance visibility for new projects on the Radix Chain (https://projectnow.io/services/) . This service included content creation, community management, and strategic posting across various social media platforms. - Branding: The company offered branding services to help elevate new projects, creating appealing visual identities (https://projectnow.io/services/) . This service aimed to create unique brand identities that capture the essence of each project and resonate with its target audience. - Design: Specializing in design for Radix crypto projects (https://projectnow.io/services/) , Project $NOW crafted visuals that engage communities. This service covered various design needs, from logos and graphics to user interface elements for decentralized applications (dApps). - Giveaway Campaigns: To boost engagement, Project $NOW offered a Giveaway Campaign Service, expertly crafting hype around projects (https://projectnow.io/services/) . This service helped projects attract attention and grow their community through strategic giveaways. - BuyBOT and Twitter Alerts: The agency provided a Radix BuyBOT and Twitter service to elevate hype by instantly alerting a project's community (https://projectnow.io/services/) about important updates or trading activity. 3.2 Platform Features In addition to its marketing services, Project $NOW had developed a platform with several features designed to support projects and engage the Radix community: - Central Hub for Radix Projects: The platform served as a focal point for projects built on the Radix blockchain (https://projectnow.io/) , providing a space for discovery and interaction. - Community Engagement Tools: Project $NOW offered tools and strategies to help projects build and maintain active communities around their tokens or applications. - Giveaway Management: The platform included features for managing giveaways, which can help projects boost engagement and attract new users (https://projectnow.io/) . - $NOW Token Integration: The platform leveraged the $NOW token to provide additional benefits and engagement opportunities for users and projects alike. 3.3 Additional Services Project $NOW also offered specialized services in collaboration with other entities: - Marketing Grants: In partnership with the Radix Community Council, Project $NOW provided marketing grants to selected projects on the Radix Network (https://projectnow.io/rcc/) . This initiative aimed to support and promote promising projects within the ecosystem. - Token Trek Services: For projects listed on Token Trek, Project $NOW offered management services, including quest creation and thumbnail design (https://projectnow.io/rcc/) , to help projects maximize their visibility on the platform. $NOW Token The $NOW token was an integral part of the Project $NOW ecosystem, serving multiple purposes within the platform and for the broader Radix community. 4.1 Overview The $NOW token was described as "the best-designed coin on the Radix Ecosystem" (https://projectnow.io/token/) by Project $NOW. While this claim is subjective, it highlighted the emphasis the project placed on the token's design and utility. Key features of the $NOW token included: - Utility: The $NOW token served as a key to unlocking marketing potential for projects on the Radix Chain (https://projectnow.io/) . - Platform Integration: The token was integrated into the Project $NOW platform, which served as a central hub for Radix projects, community engagement, and giveaways (https://projectnow.io/) . Token holders may have preferential access or additional benefits within this ecosystem. - Reward Mechanism: The platform implemented a "hold-to-win" mechanism, where the more $NOW tokens a user holds, the more they can potentially win (https://projectnow.io/) in platform-related activities or giveaways. 4.2 Token Economics The $NOW token incorporated several economic mechanisms designed to support its value and utility: - Revenue Sharing: Project $NOW committed to reinvesting 10% of the revenue from the $NOW agency back into the coin or allocating it for active marketing campaigns (https://projectnow.io/) . This mechanism aimed to create a positive feedback loop between the success of the agency and the value of the token. - Staking: The $NOW token can be staked on DefiPlaza (https://projectnow.io/token/) , a decentralized finance platform on the Radix network. Staking provided additional benefits to token holders: - A distribution of 350,000 NOW tokens was made each week to stakers. - Stakers also received a share of "Bonus Box Rewards," although the specifics of these rewards are not detailed in the available information. 4.3 Acquisition and Trading The $NOW token was primarily available through the Radix ecosystem: - Purchase Process: Users could buy $NOW tokens on OciSwap (https://projectnow.io/token/) , a decentralized exchange on the Radix network. - Wallet Compatibility: The token was compatible with the official Radix wallet, which users needed to set up before purchasing $NOW (https://projectnow.io/token/) . 5. Partnerships and Collaborations Project $NOW had established various partnerships and collaborations within the Radix ecosystem, demonstrating its commitment to fostering growth and innovation in the blockchain space. 5.1 Partner Projects Project $NOW's portfolio (https://projectnow.io/services/) showcased a range of partner projects, indicating the diversity of its client base within the Radix ecosystem. Some of the notable partner projects included: - $HUG - NFTwars - $STAB - $DFP - $WEFT (/ecosystem/weft-finance) - $ASTRL (/ecosystem/astrolescent) - $WOWO - $PHOENIX - $HIT - $FOMO 5.2 Radix Community Council Collaboration One of the most significant collaborations for Project $NOW was its partnership with the Radix Community Council. This collaboration focused on providing marketing support to projects within the Radix ecosystem: - Marketing Grants Program: Project $NOW and the Radix Community Council had partnered to offer marketing grants to selected Radix projects (https://projectnow.io/rcc/) . This initiative aimed to support and promote promising projects within the Radix ecosystem. - Grant Structure: At the end of each month, the Radix Community Council sponsored marketing grants to four Radix projects (https://projectnow.io/rcc/) . The grants were distributed as follows: - 1 grant for a meme project. - 1 grant for an NFT project. - 2 grants for Radix projects from various categories. - Grant Benefits: Each selected project received 25 hours of marketing services from Project $NOW (https://projectnow.io/rcc/) . These services can include: - Telegram engagement strategies. - UI/UX design. - Social media campaigns and design. - Token Trek services (management of project listings on the Token Trek platform). 5.3 Technology Partnerships While not explicitly detailed in the available information, Project $NOW's services and token ecosystem suggested implicit technological partnerships or integrations: - OCISwap: The $NOW token was available for purchase on OCISwap (https://projectnow.io/token/) , indicating a partnership or at least a working relationship with this decentralized exchange on the Radix network. - DefiPlaza: The $NOW token can be staked on DefiPlaza (https://projectnow.io/token/) , suggesting a collaboration or integration with this DeFi platform. Business Model Project $NOW operated with a multifaceted business model that combined traditional agency services with innovative tokenomics and community-driven initiatives. This approach allowed them to generate revenue while also fostering growth within the Radix ecosystem. 6.1 Agency Services The primary source of revenue for Project $NOW appeared to be its comprehensive suite of marketing and promotional services (https://projectnow.io/services/) tailored for projects on the Radix blockchain. These services included: - Video production. - Social media management. - Branding. - Design. - Giveaway campaigns. - BuyBOT and Twitter alerts. 6.2 Revenue Sharing A unique aspect of Project $NOW's business model was its commitment to reinvesting a portion of its revenue back into its ecosystem: - 10% of the revenue from the $NOW agency was reinvested into the $NOW coin or allocated for active marketing campaigns (https://projectnow.io/) . This approach served multiple purposes: - It potentially increased the value of the $NOW token, benefiting token holders. - It provided funding for marketing initiatives, which could attract more clients and partners to the ecosystem. - It demonstrated a long-term commitment to the growth of the Project $NOW ecosystem. 6.3 Token Economy The $NOW token played a significant role in the company's business model: - Utility: The token served as a key to unlocking marketing potential for projects on the Radix Chain (https://projectnow.io/) , suggesting that holding or spending $NOW tokens might be required to access certain services or receive preferential treatment. - Staking Rewards: Users can stake $NOW tokens on DefiPlaza to earn additional tokens and other rewards (https://projectnow.io/token/) . This mechanism encouraged users to hold $NOW tokens, potentially increasing demand and value. - Platform Integration: The more $NOW tokens a user holds, the more they can potentially win in platform-related activities or giveaways (https://projectnow.io/) . This incentivized users to acquire and hold $NOW tokens. 6.4 Community Grants While not a direct revenue generator, Project $NOW's collaboration with the Radix Community Council to provide marketing grants (https://projectnow.io/rcc/) was an important part of its business model: - This initiative helped Project $NOW establish itself as a key player in the Radix ecosystem. - It provided exposure to new projects that may become paying clients in the future. - It demonstrated Project $NOW's expertise and capabilities to the broader Radix community. 6.5 Partnerships Project $NOW's partnerships with various projects in the Radix ecosystem (https://projectnow.io/services/) contributed to its business model, potentially through: - Revenue from services provided to partner projects. - Cross-promotion opportunities. - Increased visibility and credibility within the Radix ecosystem. Project $NOW's business model combined traditional agency services with innovative blockchain-based elements, creating a unique value proposition in the cryptocurrency marketing space. By aligning its success with that of its token holders and the broader Radix ecosystem, Project $NOW aimed to create a sustainable and growing business within the blockchain industry. On-ledger status (August 2026) The agency stopped taking work, but its token did not stop existing. Read at the Radix Gateway on 22 August 2026 (epoch 337,086, state version 553,058,752), $NOW (https://dashboard.radixdlt.com/resource/resource_rdx1th42ay5yjg6ujak3ygnc6yerzx0ld622chz5tlnwjr7elcp3u48l2q) is a fungible resource of divisibility 18 with 1,000,000,000 minted, none burned, and a supply that therefore still matches the published maximum exactly. Its minter, burner, freezer and recaller roles are all DenyAll, and so are all four of their updaters, so the supply is fixed permanently rather than by policy. The token is held by 833 accounts; the largest holds 348,759,188.52 $NOW, 34.9% of supply, and that balance has not moved since 11 October 2024. Two things the token's own metadata still points at are live. The first is a market. $NOW trades in a single native two-resource pool operated by Ociswap (/ecosystem/ociswap) , pool_rdx1c5vzrppel06hw4hf529x4x2f2n7838gd6hqysmzzhjq9tdpflypu6r, which holds 119,764,938.30 $NOW against 5,169.995 XRD. That 5,170 XRD is the entire XRD side of the market for the token — and the pool's balance last changed on 8 August 2026, a fortnight before this reading, so somebody is still trading it. The second is the staking product this page describes in the past tense. The stake_component entry in $NOW's metadata resolves to component_rdx1cz2t6hl052220kstttnzwq6c8wjg9xa2j2nd9y9ydtwdudvr0t92d8, a component named "NOW Staking" running the PlazaStaking blueprint — the DeFiPlaza (/ecosystem/defiplaza) staking package — whose on-ledger description still advertises that "350,000 will be distributed each week". Its one-resource pool holds 41,291,785.74 $NOW, 4.1% of supply, and that balance has not changed since 16 February 2026: the deposits are still there, and nobody has added to or withdrawn from them in six months. Unlike the supply, the metadata is not frozen. $NOW's owner role is a protected rule requiring a specific badge resource, and only name and symbol are individually locked, so whoever holds that badge can still change the token's website, icon and dApp-definition pointers. ## Project Elysium URL: https://radix.wiki/ecosystem/project-elysium Updated: 2026-09-01 Summary: Project Elysium was an NFT and storytelling project announced for Radix in April 2023. Its stated ambition was a community-owned science-fantasy saga… Category NFT / Storytelling Network Radix Announced April 2023 Website tapas.io/series/ProjectElysium (https://tapas.io/series/ProjectElysium) (archived) X @ProjElysium (https://x.com/ProjElysium) Project Elysium was an NFT (/contents/tech/core-protocols/nfts-on-radix) and storytelling project announced for Radix in April 2023. Its stated ambition was a community-owned science-fantasy saga – intellectual property that readers could contribute to and share in rather than only consume – to be delivered first as a graphic novel and a tabletop role-playing game. One trailer episode was published. Nothing else was. Announcement The project was announced on 20 April 2023 as an attempt to build a decentralised story for a decentralised metaverse. Its framing treated Web3 as an ideology and an ownership model rather than a technology: decentralisation, community involvement in governance, and rewards weighted toward the most active contributors. Two initiatives were named – a story-rich graphic novel and a Dungeons & Dragons (https://en.wikipedia.org/wiki/Dungeons_%26_Dragons) -style tabletop RPG – on the argument that comics and tabletop games have a low barrier to entry and generate intellectual property that fans can meaningfully co-own. Announced Plans Four deliverables were promised, all of them described at the time as weeks away: details of the graphic novel and the RPG, a revised website, a whitepaper, and the NFT drop itself. None of the four was ever published. Outcome What exists is a single episode. A trailer titled Project Elysium Trailer was posted to the project's Tapas series (https://tapas.io/series/ProjectElysium) on 29 October 2023 by the account jandrsn317, and as of August 2026 the series still carries that one episode – 499 views, one subscriber, no comments. The graphic novel, the tabletop RPG, the revised website, the whitepaper and the NFT drop were never released. The project is dormant. ## PokerXRD URL: https://radix.wiki/ecosystem/pokerxrd Updated: 2026-09-01 Summary: PokerXRD is a decentralized poker tournament platform built on the Radix DLT network. It uses Radix for payment processing, ticket management, and rew… Type Decentralized Poker Platform Network Stokenet (Radix testnet) – mainnet pending Status 🟠 Dormant – Season 0 ran 8 May to 29 June 2025; no tournament scheduled since Native Token $poker Prize Tokens $poker, XRD, FETH, FBTC, WHY Overview PokerXRD is a decentralized poker tournament platform built on the Radix DLT (/contents/tech/releases/radix-mainnet-babylon) network. It uses Radix for payment processing, ticket management, and rewards distribution – replacing traditional poker room infrastructure with on-chain primitives. The platform runs on Stokenet (/contents/tech/releases/stokenet) , Radix's persistent testnet, and has never migrated to mainnet. Its published tournament schedule has been empty since June 2025 (see Season 0 and the stopped schedule (#season-zero) ). The platform pitches itself as an alternative to traditional online poker rooms, where withdrawals can require identity checks, multi-day waits, and high commissions (https://pokerxrd.com) ; by settling buy-ins and payouts directly on the Radix ledger, PokerXRD aims for instant on-chain settlement and low fees. During the beta the platform uses its native $poker token, migrating to XRD and other Radix-native assets once the room is fully tested. Players must claim a badge via the Radix Wallet to access the dApp. Badges gate participation in tournaments, ticket purchases, and reward claims – serving as an on-chain membership credential managed through Radix's native role-based access control. Tournament System PokerXRD offers multiple tournament formats including standard tournaments, hyper-fast variants, and newcomer-focused events. Tournaments can split into multiple simultaneous rooms, each with its own leaderboard – allowing larger player pools without creating a single-table bottleneck. Prize pools are distributed in a variety of tokens to give players exposure to the broader Radix ecosystem: - $poker – the platform's native token - XRD – Radix's native currency - FETH, FBTC, WHY – Radix ecosystem project tokens Players buy entry tickets on-chain, compete across multiple rounds, and receive rewards automatically on the ledger based on final placement. $poker Token and Mainnet Migration The $poker token is PokerXRD's native reward currency. During the Stokenet beta phase, $poker earned through tournament winnings is tracked by the platform. When the Stokenet phase concludes and the platform migrates to mainnet, all $poker rewards accumulated during the beta will be replicated 1:1 on the Radix mainnet – provided players have saved their mainnet account address. This migration incentive rewards early adopters who participate during the testing phase, before the platform reaches its full audience on mainnet. It also provides PokerXRD with an engaged user base at mainnet launch rather than starting cold. Radix Integration PokerXRD demonstrates a practical application of Radix's asset model for gaming and competition. Key integration points include: - Badge-based access control – players hold an on-chain badge (a Radix non-fungible resource) that gates dApp access, using Radix Engine (/contents/tech/core-protocols/radix-engine) 's native role-based auth rather than a centralised allowlist - On-chain ticket management – tournament entry tickets are issued and redeemed on the Radix ledger - Multi-token prize distribution – winnings are paid out directly to player wallets via ledger transactions, removing the need for a centralised payout system The platform uses Stokenet during its beta phase to test the full token flow without risking real assets, then will deploy the same contracts to mainnet when ready. Season 0 and the stopped schedule The dApp publishes its own tournament history, and it is the clearest available reading of whether the room is running. Checked on 29 August 2026, the tournament page (https://pokerxrd.com/tourney.php) lists eight events – S0T3 Crazy Blinds, S0T4 Cheers to Prophet, S0T5 Newcomers, S0T6 WhyNot, S0T7 Hyper Fast, S0T9 Tokens and S0T10 Final among them – all belonging to Season 0, all played between 8 May and 29 June 2025, and all marked Finish. Nothing is scheduled after the Season 0 final, a gap of fourteen months at the time of writing. The roadmap (https://pokerxrd.com/roadmap.php) agrees. Stage 0 – site, token, socials and the game itself – is marked Done in 2024. Stage 1, "Stokenet Launch / First season Start!", is still marked Now. Stage 2, which is where mainnet launch, an ICO, a DEX listing and token distribution live, is still marked Next. The mainnet migration this page previously described as being prepared has therefore not begun, and the $poker 1:1 replication it promises to Season 0 players remains contingent on a mainnet launch with no date attached. The site itself is not abandoned: pokerxrd.com and the dApp both answer, the badge-claim flow is live, and the Telegram group (https://t.me/pokerxrd) (110 members when checked) still describes the project as being "on alpha release". On the evidence of its own schedule, though, the room is not running games, and this page records its status as Dormant rather than Active. External Links - PokerXRD Website (https://pokerxrd.com) - PokerXRD on Telegram (https://t.me/pokerxrd) - PokerXRD on X (https://twitter.com/pokerxrd) - PokerXRD on Radix List (https://www.radixlist.com/item/pokerxrd) ## Phoenix URL: https://radix.wiki/ecosystem/phoenix Updated: 2026-09-01 Summary: Phoenix is a deflationary token on Radix built around a multi-layered burn mechanism. Unlike typical memecoins, Phoenix generates revenue through a pr… Type Deflationary Token Symbol PHNX Status 🟠 Dormant (validator unregistered, no updates since February 2025 – see below) Category DeFi / Token Network Radix Mainnet Initial Supply 699,296,180 PHNX Supply (1 Aug 2026) 529,758,843.55 PHNX – 24.2% burned, minting permanently disabled Launched April 2024 Overview Phoenix (https://www.phoenixradix.com/) is a deflationary token on Radix built around a multi-layered burn mechanism. Unlike typical memecoins, Phoenix generates revenue through a professional validator node (https://dashboard.radixdlt.com/network-staking/validator_rdx1sde3jp4g6ldh2mg4af0v0sq3c8en4agk3p7p63zcv58l5h05sej4kh) , an external investment fund, and LP trading fees – all of which feed into continuous buyback-and-burn cycles that reduce the circulating supply over time. The project aims to create a self-sustaining value engine where multiple independent revenue streams drive permanent supply reduction, distinguishing it from tokens that rely solely on transaction taxes or manual burns. PHNX is available across Radix decentralized exchanges – including Ociswap (/ecosystem/ociswap) , CaviarNine (/ecosystem/caviarnine) and DefiPlaza (/ecosystem/defiplaza) , and via the Astrolescent (/ecosystem/astrolescent) aggregator. Burn Mechanisms Phoenix employs four distinct mechanisms to reduce token supply: - Voluntary Burns – community members can burn PHNX tokens at any time, permanently removing them from circulation - LP Trading Fee Burns – a portion of fees from PHNX liquidity pools on Ociswap (/ecosystem/ociswap) , CaviarNine (/ecosystem/caviarnine) , and DefiPlaza (/ecosystem/defiplaza) is used to buy and burn PHNX - Trading Profit Burns – profits from the project's active trading operations fund periodic buyback-and-burn events - Validator Reward Burns – staking rewards earned by the Phoenix validator node are used to buy PHNX on the open market and burn it These four pillars operate independently, ensuring that supply reduction continues even if one revenue stream underperforms. The team initially seeded LP pools with $10,000. Investment Fund A distinguishing feature of Phoenix is its external investment fund, which brings capital from outside the Radix ecosystem. Profits from external market trades are converted to XRD, used to purchase PHNX tokens, and burned. This creates a net inflow of value into the Radix ecosystem rather than simply redistributing existing liquidity. Team Phoenix is run by a pseudonymous team distributed across Vietnam, London, and other locations: - The Cador – Co-founder, lead trader - Corsican Emperor – Co-founder, ambassador and community relations (London) - Asa – Developer and treasury manager - Cowboy Bebop – Education and innovation lead - Tyrex – NFT creation and trading Status on Ledger (as of 1 August 2026) This page recorded Phoenix as active. Read against the ledger and the public market on 1 August 2026, the project is better described as dormant, and the evidence sits in three places. The validator is unregistered while still holding stake. PHOENIX NODE (https://dashboard.radixdlt.com/network-staking/validator_rdx1sde3jp4g6ldh2mg4af0v0sq3c8en4agk3p7p63zcv58l5h05sej4kh) reads registered: false at epoch 331231 with 7,807,033 XRD still delegated to it. An unregistered validator is outside the active set: it proposes nothing, and the XRD delegated to it earns no staking emissions (/contents/tech/core-concepts/staking) until its owner re-registers it or the delegators unstake. The stake-buyback mechanism this page describes – node earnings used to buy $PHNX on the open market – has no earnings to draw on in that state. The burn is real and, as of 1 August, had stalled. The $PHNX resource (https://dashboard.radixdlt.com/resource/resource_rdx1t5z0jeyg2k9746kyvgcvg6pqsc0zhg0hjnvtsq03j77ezylv9pyljk) shows a total supply of 529,758,843.55 PHNX against the 699,296,180 issued at launch – 169,537,336 tokens burned, or 24.2% of the initial supply. Minting is set to deny_all and is not mutable, so the supply is permanently capped and can only fall further; the deflationary claim in the section above is, on this evidence, accurate. The burn totals have not moved the market: on Ociswap the token quoted about $0.0000038 with roughly $800 of pool liquidity, a circulating market capitalisation near $1,940, and no trades in the preceding 24 hours. The public presence has stopped. The newest dated commitment on phoenixradix.com (https://www.phoenixradix.com/) is "Phase 1: The Great Burn", scheduled for completion by February 2025, and the site publishes no burn statistics or updates after it. The project's Telegram handle has since been recycled by an unrelated party (see the section below). The status in the infobox has been changed to 🟠 Dormant on this basis. Anyone still delegating to PHOENIX NODE should check its registration state before assuming they are earning. Ledger Re-Read, 14 August 2026 The section above was written from a 1 August reading. Re-read at epoch 334974 on 14 August 2026, one of its conclusions no longer holds and the other two have a trend attached. The burn is not finished. The $PHNX resource (https://dashboard.radixdlt.com/resource/resource_rdx1t5z0jeyg2k9746kyvgcvg6pqsc0zhg0hjnvtsq03j77ezylv9pyljk) now reports a total supply of 529,508,843.548 PHNX, down from 529,758,843.55 a fortnight earlier: 250,000 PHNX burned between 1 and 14 August 2026, with no public announcement accompanying it. Cumulative destruction is 169,787,336.45 tokens, 24.3% of the 699,296,180 issued at launch. Minting remains deny_all and immutable, so the supply can still only fall. The stake is draining. PHOENIX NODE (https://dashboard.radixdlt.com/network-staking/validator_rdx1sde3jp4g6ldh2mg4af0v0sq3c8en4agk3p7p63zcv58l5h05sej4kh) still reads registered: false, and the XRD delegated to it has fallen from 7,807,033 on 1 August to 7,595,958.86 XRD — 211,074 XRD withdrawn in thirteen days from a validator that has been outside the active set, and therefore earning nothing, throughout. A 100% fee is queued behind re-registration. The validator carries an unexecuted validator_fee_change_request of new_fee_factor: 1 — a 100% validator fee — effective from epoch 297632, against a current validator_fee_factor of 0.1. The request is inert while the node is unregistered, but it takes effect the moment the owner re-registers, at which point every emission earned on delegated stake would go to the validator owner rather than the delegators. Anyone still delegating here should read the fee before assuming a re-registration would pay them. Telegram Handle No Longer the Project's The Telegram handle @phoenix_xrd, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . External Links - Phoenix – Official Website (https://www.phoenixradix.com/) - Phoenix Validator – Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1sde3jp4g6ldh2mg4af0v0sq3c8en4agk3p7p63zcv58l5h05sej4kh) - Phoenix – RadixList (https://www.radixlist.com/item/phoenix) ## Notix URL: https://radix.wiki/ecosystem/notix Updated: 2026-09-01 Summary: Notix is a real-time notification and monitoring service for Radix accounts. A user connects a Radix Wallet , selects the accounts to watch, and defin… Notix Type Real-time notification and account monitoring service Network Radix (/contents/tech/core-protocols/radix-engine) Category Infrastructure / Tooling Announced 17 June 2025, on the ShardSpace (/ecosystem/shardspace) blog Delivery In-app, browser push, Telegram Webhooks Hookah (/developers/tools/hookah) X @NotixOnRadix (https://x.com/NotixOnRadix) Introduction Notix (https://notix.live) is a real-time notification and monitoring service for Radix (/contents/tech/core-protocols/radix-engine) accounts. A user connects a Radix Wallet (https://www.radixdlt.com/wallet) , selects the accounts to watch, and defines trigger rules; matching on-ledger events are then delivered as alerts rather than having to be discovered by checking a dashboard. It was announced on 17 June 2025 (https://shardspace.app/blog/post/mebv0a7uanwe7i5z9y82) on the blog of ShardSpace (/ecosystem/shardspace) , the Radix portfolio manager, and the service points its community link at the same Telegram group (https://t.me/ShardSpace) . The category it occupies is narrow but real: a Radix account's activity is visible on-ledger to anyone who queries for it, and services such as the Radix Dashboard (https://dashboard.radixdlt.com) render that state, but reading it is a pull. Notix is the push half — a watcher that turns ledger events into messages. What It Monitors The product site (https://notix.live) lists the event classes a trigger can fire on: deposits, withdrawals, stake and unstake (/contents/tech/core-concepts/staking) events, fungible and non-fungible resource movements, pool liquidity additions and removals, and custom events configured against any component (/contents/tech/core-concepts/components) . Triggers carry conditions and thresholds, so a rule can be scoped to an amount, a resource or a counterparty rather than firing on all activity. The announcement (https://shardspace.app/blog/post/mebv0a7uanwe7i5z9y82) adds the delivery side: notifications reach the user in-app, as browser push, or through a Telegram integration, and the interface is built as a Progressive Web App so it can be installed on a phone or desktop. It also describes validator (/contents/tech/core-concepts/validator-nodes) monitoring — stake changes, reward distribution and validator status — as a distinct feature for node operators and delegators. Infrastructure Notix does not run its own webhook plumbing. Its footer credits Hookah (https://app.hookah.ing/) — the open-source Radix webhook service documented at Hookah (/developers/tools/hookah) — as the provider of webhook services, which places Notix downstream of it: Hookah watches the ledger and emits events, Notix applies the user's rules and delivers the message. The same footer carries a 2026 copyright line, the most recent dated marker the service publishes about itself. Beyond that, the project publishes little: no team page, no roadmap, no changelog and no public repository are linked from the site, and the announcement post is the only long-form description of the product. The status recorded here reflects a live, wallet-connectable service, not a claim about the size or activity of the team behind it. External Links - notix.live (https://notix.live) – the service - "Welcome to Notix" (https://shardspace.app/blog/post/mebv0a7uanwe7i5z9y82) – announcement, ShardSpace blog, 17 June 2025 - @NotixOnRadix on X (https://x.com/NotixOnRadix) - Hookah (https://app.hookah.ing/) – the webhook service Notix credits ## Nerds Republic URL: https://radix.wiki/ecosystem/nerds-republic Updated: 2026-09-01 Summary: Nerds Republic is an NFT project launched by the team behind Foton . The collection consists of 10,000 unique characters. Launched as the first NFT in… Nerds Republic Type NFT collection – 10,000 unique on-ledger SVG avatars; the first NFT project on Radix Status 🟠 Dormant – full supply reserved, reservations closed; site last published 12 March 2022 Founded 2021 (reservations opened 7 Aug 2021) Team Built by the Foton (/ecosystem/foton) team Tokens $GNRD (https://dashboard.radixdlt.com/resource/resource_rdx1tkf56rwzta4qemw5vrrwgf5xlkvdg5huxp26zsfrt6mm3x5frnvzeh) (Genesis Nerds – 10,000 fixed supply, swappable for the final NFTs) + Foton, the in-world currency (1B supply) Mint price 150 XRD per Nerd On-ledger Genesis Nerds supply verified via the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1tkf56rwzta4qemw5vrrwgf5xlkvdg5huxp26zsfrt6mm3x5frnvzeh) (mainnet epoch 338,430, 26 Aug 2026) Nerds Republic is an NFT project launched by the team behind Foton (/ecosystem/foton) . The collection consists of 10,000 unique characters. Launched as the first NFT initiative on Radix, each Nerd in the collection represents a unique identity, granting its owner full access within the Republic. The project aims to create a virtual space for the exploration of habitable planets and the research of alien life forms. Concept Set in a fictional universe, the base for these digital characters is the 'TinCan', a space station orbiting Earth. The overarching goal of the Republic is to search for habitable planets and study extraterrestrial life, emphasizing the need for skilled and unique individuals. Features - Artwork as Token: The NFTs are implemented as SVG files, ensuring that the artwork is compact and directly stored on the Radix Ledger. This feature guarantees that the artwork is inseparable from its proof of authenticity and allows for interactive elements or animations. - High-Resolution Graphics: Regardless of the display size, the artworks retain their sharpness and accuracy, thanks to vector graphics. - Commercial Rights: Owners have the liberty to use their Nerd artwork commercially, such as for merchandise. - Efficient Transactions: Hosted on the Radix Ledger, these NFTs benefit from low transaction fees and high energy efficiency. Tokenomics Each Nerd initially comes with a 10k allowance of Foton tokens, the Republic's currency. These tokens can be used for various activities within the Republic, like trading, supporting research, or even teaching newcomers about cryptocurrency. The total supply of Foton tokens is set at 1 Billion. Reservation and Distribution Starting from August 7, 2021, Nerds could be reserved by sending $XRD to the Republic's wallet. Each Nerd was priced at 150 $XRD. The project employed a system of Genesis Nerd Tokens ($GNRD), which were later swappable for the final NFTs upon the launch of smart contracts on Radix. Roadmap The Nerds Republic has a dynamic roadmap, with milestones based on the percentage of Nerds reserved. Achievements include the introduction of alien species, the opening of a Mars base, and the eventual goal of transforming the Republic into a Metaverse game. Further ambitions involve the creation of a platform for NFTs on Radix and even the production of a movie. Status The project stopped where it stood. nerdsrepublic.net (https://nerdsrepublic.net) still answers on 26 August 2026, and the site is the reason the date can be given exactly: it is a Webflow build, and the build comment in its source reads Last Published: Sat Mar 12 2022 10:34:11 GMT+0000. Nothing has been published to it in the four and a half years since, through the whole of the Babylon (/contents/tech/releases/radix-mainnet-babylon) upgrade that finally brought smart contracts and native non-fungible resources to Radix mainnet in September 2023. The ledger says the same. Genesis Nerds ($GNRD) (https://dashboard.radixdlt.com/resource/resource_rdx1tkf56rwzta4qemw5vrrwgf5xlkvdg5huxp26zsfrt6mm3x5frnvzeh) was read live on mainnet at epoch 338,430 on 26 August 2026: a supply of exactly 10,000, divisibility 18, with minter, burner, freezer and recaller all DenyAll and the rules locked. It remains a fungible resource, which is to say it is still the reservation receipt described under Reservation and Distribution above, and not the collection of 10,000 individual avatars it was to be swapped for. The reservations therefore sit where they were left: fully subscribed, permanently uncancellable and permanently unexpandable, against a swap that the project has not published since. The Foton (/ecosystem/foton) team behind it has kept building on Radix, so the description above should be read as a record of the 2021 project rather than a live roadmap. External Links - nerdsrepublic.net – the Nerds Republic site, last published 12 March 2022 (https://nerdsrepublic.net) - Genesis Nerds ($GNRD) – Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1tkf56rwzta4qemw5vrrwgf5xlkvdg5huxp26zsfrt6mm3x5frnvzeh) - Nerds Republic – project video (https://www.youtube.com/watch?v=QsKNRHfkX7A) ## Lucky8 🍀 URL: https://radix.wiki/ecosystem/lucky8 Updated: 2026-09-01 Summary: Lucky8 is a lossless lottery built on the Radix network. Players stake a minimum of 1,000 XRD to the Lucky8 validator node , farm the project's native… Lucky8 Type Radix validator node · lossless lottery (GameFi) Status 🟢 Active – website live, validator registered and accepting delegations Native token $LUCK Validator address validator_rdx1sw…ey6g7zam (https://dashboard.radixdlt.com/network-staking/validator_rdx1sw2qt9k0placmjgwku2kvk66c2v8v0f9ny2fkvzhsh7wwzey6g7zam) Total stake ≈7.97 million XRD (rank #81 of 188 registered validators) Validator fee 100% – all staking rewards fund the prize pool Uptime (30d) 75.15% (Radix Dashboard, 17 July 2026) Social X (https://x.com/lucky8xrd) · Telegram (https://t.me/Lucky8xrd) On-ledger Validator substate read at the Gateway API (https://docs.radixdlt.com/docs/network-apis) , mainnet epoch 335,551 (16 August 2026) Lucky8 is a lossless lottery (https://lucky8xrd.com) built on the Radix (/contents/tech/core-protocols/radix-engine) network. Players stake a minimum of 1,000 XRD (/contents/tech/core-protocols/xrd-token) to the Lucky8 validator node (https://dashboard.radixdlt.com/network-staking/validator_rdx1sw2qt9k0placmjgwku2kvk66c2v8v0f9ny2fkvzhsh7wwzey6g7zam) , farm the project's native $LUCK token while staked, and become eligible for recurring XRD prize draws. Because the stake is never spent, participants can unstake their principal at any time – the "lossless" model – while their chance to win comes from the pooled staking rewards rather than from a ticket purchase. How the lossless lottery works Lucky8 funds its jackpots through its validator's fee (https://dashboard.radixdlt.com/network-staking/validator_rdx1sw2qt9k0placmjgwku2kvk66c2v8v0f9ny2fkvzhsh7wwzey6g7zam) : the node runs a 100% validator fee, so the emissions that would normally flow to stakers are instead directed into the Lucky8 prize pool. Delegators forgo ordinary staking yield and receive $LUCK tokens plus lottery entries in its place. On-ledger the validator holds 7,972,823.82 XRD at mainnet epoch 335,551 (16 August 2026), ranking 81st of the 188 registered validators and sitting inside the 100-strong active set with 0.167% of active stake; its recorded 30-day uptime was 75.15% when the Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1sw2qt9k0placmjgwku2kvk66c2v8v0f9ny2fkvzhsh7wwzey6g7zam) was read on 17 July 2026. The validator is registered, accepts delegated stake, and its validator_fee_factor reads 1 – the full 100%, with no fee-change request pending. The route from that fee to the prize pool is visible in the same substate. A validator fee is paid to the owner as stake units (/contents/tech/core-concepts/liquid-stake-units) held in a locked owner vault, and Lucky8’s carries 1,116.43 of them against 26 queued withdrawals of roughly 1,400 units each – one requested about every 288 epochs, or once a day, and each unlocking some four weeks later, so that the queue runs out to epoch 343,385. A further 186,287.25 XRD sits in the validator’s pending withdrawal vault. The emissions a delegator gives up are not accumulating on the node; they are being unstaked in daily instalments. $LUCK token $LUCK is Lucky8's native token, farmed continuously by anyone staking XRD to the validator. $LUCK is spent to enter the larger periodic draws; the monthly draw advertises a minimum jackpot of 20,000 XRD and the yearly draw a minimum of 120,000 XRD, both paid in XRD. Prizes and partners Beyond the XRD jackpots, Lucky8 has partnered with a range of Radix NFT and community projects that contribute tokens and NFTs as supplementary prizes – including VikingLand (/ecosystem/vikingland) , Radical Penguins, Radix Panda, RadHeads, Mutant Cat Society and Radix Frogz Society, among others. How to play Staking to Lucky8 uses the standard Radix flow: open the Radix Wallet (https://wallet.radixdlt.com) , go to Stake, paste the Lucky8 validator address (validator_rdx1sw…ey6g7zam), delegate at least 1,000 XRD and confirm the transaction. Staked XRD immediately begins farming $LUCK and earning lottery entries; principal can be unstaked at any time subject to the network's unstaking delay. Related - Supreme Stake (/ecosystem/supreme-stake) – a conventional Radix validator - Cobra Stakes (/ecosystem/cobra-stakes) – Radix validator - Radix Ecosystem directory (/ecosystem) ## Liquify URL: https://radix.wiki/ecosystem/liquify Updated: 2026-09-01 Summary: Liquify is a Radix dApp that buys liquid stake units from holders who want out of a stake before the network's unstaking delay has run. Its on-ledger… Liquify Type Unstaking marketplace for Radix liquid stake units Status 🟢 Active – component enabled on mainnet Component component_rdx1czv…sl5deuk8 (https://dashboard.radixdlt.com/component/component_rdx1czvsx3kq5j4yfz8d0keq5328txwctmsq2fllqr6rqpn000sl5deuk8) Blueprint Liquify, package package_rdx1p5s…33drcku0n First on-ledger activity 10 October 2025 Lifetime volume 27,122,770.95 XRD Platform fee 0.05% (platform_fee 0.0005) On-ledger Read at mainnet epoch 334,351 (12 August 2026) Liquify is a Radix dApp that buys liquid stake units (/contents/tech/core-concepts/liquid-stake-units) from holders who want out of a stake (/contents/tech/core-concepts/staking) before the network's unstaking delay has run. Its on-ledger metadata describes it as an "Unstaking platform for native Radix liquid stake units", and the component has settled 27,122,770.95 XRD of volume since October 2025. This page is written from component state rather than from the product, because www.liquifyxrd.app (https://www.liquifyxrd.app/) answers automated requests with a 403 page and could not be read when this page was written. Every figure below is a field of the Liquify component (https://dashboard.radixdlt.com/component/component_rdx1czvsx3kq5j4yfz8d0keq5328txwctmsq2fllqr6rqpn000sl5deuk8) at mainnet epoch 334,351, 12 August 2026. How the component is arranged The component (https://dashboard.radixdlt.com/component/component_rdx1czvsx3kq5j4yfz8d0keq5328txwctmsq2fllqr6rqpn000sl5deuk8) is an instance of a Liquify blueprint published in package package_rdx1p5sanzez67tsmghv6ug0zadps29h4sx2g4d5l922d7pge33drcku0n. Its state describes a two-sided book rather than a pool: liquidity providers deposit XRD and receive a Liquify Liquidity Receipt non-fungible (295 issued to date), and their standing bids sit in a buy_list and an order_fill_tree with per-provider discounts. Separate indexes hold positions that have automatic unstaking switched on and off, and an automated_liquidity store drives the automated side, which carries its own automation_fee. The parameters are modest and explicit: a platform_fee of 0.0005 (5 basis points), a minimum_liquidity and minimum_refill_threshold of 10,000 XRD each, and unstake sizes bounded above at 10,000,000 XRD. component_status reads true, so the component is enabled and accepting calls. Activity and the DeFiLlama zero Lifetime counters at epoch 334,351: total_xrd_volume 27,122,770.95 XRD across 1,071 order fills (order_fill_counter), 689 positions (avl_position_counter) and 295 liquidity receipts. The component's first transaction was on 10 October 2025 (https://dashboard.radixdlt.com/transaction/txid_rdx1llt9xxxtm357w9eukada62jffj97mnx9jdhth9y6syxqq5acj6qshghju4) and its most recent on 24 July 2026 (https://dashboard.radixdlt.com/transaction/txid_rdx1u5ccduaw68d4wgax6qw3q7lvwssess892s2x0g7nfc5xd4c8wkds44a04h) . DeFiLlama lists Liquify Protocol with a Radix TVL of roughly $0.49 (https://api.llama.fi/protocol/liquify-protocol) , which reads as a wound-down protocol and is not one. Its adapter (https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/liquify-protocol/index.js) measures exactly one thing — the XRD sitting in the component's xrd_liquidity vault — and that vault held 501.90613412483554811 XRD when this page was written. The component's fee vault held a further 13,561.39 XRD. A near-zero TVL here means the book is thin, not that the protocol is gone; the same distinction applied in reverse to Surge (/ecosystem/surge) , whose $0 was a broken adapter over a live protocol, and did not apply to Maya Protocol (/ecosystem/maya-protocol) , whose $0 is a pool that no longer exists. Why the site cannot be read here Requests to www.liquifyxrd.app (https://www.liquifyxrd.app/) come back as HTTP 403 with a 59-byte body reading "Forbidden". The response carries x-vercel-mitigated: deny, which is the Vercel firewall refusing the request on a rule rather than the application failing. The site is up; it declines to serve non-browser clients, so this page is written from the component instead. That header is worth naming because the alternative looks the same from outside. Leaf Node (/ecosystem/leafnode) is also hosted on Vercel and also answers a short text body, but its response is HTTP 503 with x-vercel-error: DEPLOYMENT_PAUSED – the deployment has been switched off, and that site really is gone. A link checker reports both as failures. The header says which is which: x-vercel-error names an outage, x-vercel-mitigated names a block. Both were re-read on 18 August 2026. External links - liquifyxrd.app (https://www.liquifyxrd.app/) – the dApp (blocks automated requests) - Liquify component on the Radix Dashboard (https://dashboard.radixdlt.com/component/component_rdx1czvsx3kq5j4yfz8d0keq5328txwctmsq2fllqr6rqpn000sl5deuk8) - DeFiLlama: Liquify Protocol (https://api.llama.fi/protocol/liquify-protocol) - DeFiLlama TVL adapter source (https://github.com/DefiLlama/DefiLlama-Adapters/blob/main/projects/liquify-protocol/index.js) - Radix ecosystem directory (/ecosystem) ## Juicy Stake URL: https://radix.wiki/ecosystem/juicy-stake Updated: 2026-09-01 Summary: Juicy Stake was a validator staking service operating on several proof-of-stake networks, including Radix , through which holders could delegate token… Project Juicy Stake Type Validator staking service Network Radix (/ecosystem) (and other proof-of-stake networks) Status 🟠 Dormant — validator unregistered on-ledger; delegated stake now falling; website still live and still advertising the node Founded 2021 Founder Knox Trades Validator Juicy Stake (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0tkjt8mureaw3kkfl3900law5tnrlg3wte9f4vlaruxe4nfjzdam7) — not registered, 12,087,329.82 XRD still delegated and now falling, 2% fee (read on-ledger 17 August 2026, epoch 335,694, state version 550,831,708) Fee split 2% to the operator, 98% to stakers (as documented while operating) Website www.juicystake.org (https://www.juicystake.org/) (the apex juicystake.org now redirects to plain HTTP; the older juicystake.io returns HTTP 502) Juicy Stake was a validator staking service operating on several proof-of-stake networks, including Radix (/ecosystem) , through which holders could delegate tokens to its nodes rather than run their own. Status Re-verified 17 August 2026. The service changed domains rather than disappearing: juicystake.io returns HTTP 502, while www.juicystake.org (https://www.juicystake.org/) is live and is the website recorded in the validator’s own on-ledger metadata. That site still presents the node as running – “19,726,201 XRD Staked”, a 6.77% current APY and 99.99% uptime – and still invites new delegation. The apex domain recorded in that on-ledger metadata, juicystake.org, now answers with a 301 to http://www.juicystake.org/ and so drops HTTPS on the way; the www host serves the same site over HTTPS and is what this page links. The ledger reads differently. The Juicy Stake validator, validator_rdx1s0tkjt8mureaw3kkfl3900law5tnrlg3wte9f4vlaruxe4nfjzdam7, is no longer registered: its registration flag read false at epoch 331087 (1 August 2026) read false again at epoch 332527 (6 August 2026), and still reads false at epoch 335,694 (17 August 2026, state version 550,831,708). The active validator set is drawn from registered validators only (https://docs.radixdlt.com/docs/validator) , ordered by stake, top 100 per epoch, and emissions are paid only to stakers delegated to a validator inside that set (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-penalties-are-calculated-general) – so the XRD delegated here is earning nothing. Delegators have now started to leave. The stake vault held 12,610,520.465017496855168922 XRD on 1 August and the identical figure on 6 August – over those five days nobody withdrew a single token. At epoch 335,694 (17 August 2026, state version 550,831,708) it holds 12,087,329.820082095715034029 XRD: 523,190.644935401140134893 XRD has left the stake vault in the eleven days since. A further 661,871.150645647908576531 XRD sits in the validator’s pending withdraw vault, which is stake already unbonding on its way to unstake claims rather than stake lost; the earlier readings recorded only the stake vault, so how much of that queue predates them cannot be settled from a single read. The node’s fee remains 2%, and its stake-unit resource (resource_rdx1t5d8gv6fmwv40sreuypwrwh2mmknr4vf7fdtyrmfr7upjmschwczn0) and unstake-claim NFT are live, so the stake that remains can still be withdrawn in the normal way. The site has not changed the figure it advertises, so the gap between it and the ledger has widened from roughly 7.1 to roughly 7.6 million XRD. The documentation at docs.juicystake.org has gone further than the empty GitBook shell recorded in August: read on 17 August 2026 it returns a 163-byte cPanel default page – a meta-refresh to /cgi-sys/defaultwebpage.cgi, what an unconfigured hosting vhost serves – so the sources below point to archived snapshots. The service as operated Juicy Stake was founded by Knox Trades, described in the operator’s own documentation as a systems, networking and cloud architect. Its published offer on Radix was a conventional one: delegators kept 98% of staking rewards and the operator retained 2% as a node-maintenance fee. The staking guide (https://web.archive.org/web/20250217102904/https://docs.juicystake.org/how-to/staking-guide) , archived on 17 February 2025 and the last version of the documentation still readable, also advertised a monthly lottery paying additional rewards to delegators, and stated that the node followed the Radix validators’ code of conduct and disclosed its location. Delegation itself was never operator-specific. Staking XRD is a wallet-level action – a holder selects a validator in the Radix Wallet (/contents/tech/core-protocols/radix-wallet) and delegates to it, and unstaking returns the XRD after the network’s unbonding period – so nothing about the mechanics described on the Juicy Stake site was particular to Juicy Stake. What an operator competes on is fee, uptime, and whether it stays registered. Beyond the fee split, the lottery and the founder’s stated background, the claims the site made about itself – the security of its infrastructure, the experience of its team, its reputation among users – were never independently sourced, and are not repeated here. What can be checked is on the ledger, and it is in the section above. Telegram Handle No Longer the Project's The Telegram handle @juicystake, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . External links - Juicy Stake – current site (https://www.juicystake.org/) - Juicy Stake validator on the Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0tkjt8mureaw3kkfl3900law5tnrlg3wte9f4vlaruxe4nfjzdam7) - Juicy Stake staking guide (https://web.archive.org/web/20250217102904/https://docs.juicystake.org/how-to/staking-guide) – archived snapshot, 17 February 2025 - juicystake.io (https://web.archive.org/web/20250506113003/https://www.juicystake.io/) – archived snapshot, 6 May 2025 - Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) ## Infinite Labs URL: https://radix.wiki/ecosystem/infinite-labs Updated: 2026-09-01 Summary: Infinite Labs was a Web3 gaming studio building a 3D multiplayer game on the Radix network, with in-game NFT assets that players owned and used direct… Type Web3 Gaming Studio Product Dimensions – 3D multiplayer game Engine Unreal Engine Network Radix (Olympia & Babylon) Grant $15,000 Babylon Booster Grant (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) Founders Blake & Ron Website inflabs.net (offline) Infinite Labs was a Web3 gaming studio building a 3D multiplayer game on the Radix (https://www.radixdlt.com) network, with in-game NFT assets that players owned and used directly in gameplay. The studio was founded by Blake and Ron (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) and received a $15,000 Babylon Booster Grant (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) to develop its flagship title, Dimensions. Overview Infinite Labs set out to merge competitive gaming with on-ledger asset ownership, targeting both gamers and creators. The team's stated goal was a 3D game with an engaging core loop, multiple game modes, and NFT items – such as limited-edition weapons and gear carrying stat bonuses – usable across a planned in-game marketplace. As the founders put it (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) , "Building on Radix has simplified the Web3 integration process when developing our game." Technology Infinite Labs connected the Unreal Engine (https://www.unrealengine.com) to both the Olympia and Babylon (/contents/tech/releases/radix-mainnet-babylon) networks, and achieved minting of its "Companion" NFTs (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) on each. The studio used Scrypto (https://github.com/radixdlt/radixdlt-scrypto) to model tokenized in-game assets, and had a roadmap that included on-ledger asset minting, a PvP technical demo, a first PvE level, an adventure mode, and creator tools. Status Infinite Labs appears dormant. Its website (inflabs.net) no longer resolves (DNS lookup fails, verified July 2026), and no public game launch or further milestones have followed the December 2023 Babylon integration. Infinite Labs remains a record of a Radix Babylon Booster Grant (https://www.radixdlt.com/blog/babylon-booster-grants-infinitelabs) project that reached working Unreal Engine ↔ Radix integration but did not carry through to a shipped public title. The domain is still gone and nothing else has changed: inflabs.net returned no DNS record when re-verified 17 August 2026. That is why this page reads 🟠 Dormant and not closed – no wind-down announcement from the studio is on record, and a lapsed domain is not a shutdown notice. The distinction, and the rest of the ecosystem measured against it, is on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) . ## HydraSwap URL: https://radix.wiki/ecosystem/hydraswap Updated: 2026-09-01 Summary: HydraSwap is a decentralized application (dApp) for token swapping built natively for the Radix DLT platform, part of the HYDRA ecosystem – a communit… Project HydraSwap Type Swap front-end routed through the Astrolescent (/ecosystem/astrolescent) DEX aggregator Network Radix (/ecosystem) Launched February 2026 Native token $HYDR (https://dashboard.radixdlt.com/resource/resource_rdx1t4kc2yjdcqprwu70tahua3p8uwvjej9q3rktpxdr8p5pmcp4almd6r) — 965,821,366 supply, minting permanently denied, burning open to every holder (read on-ledger 6 August 2026, epoch 332526, state version 546295971) X @HYDRAXRD (https://x.com/HYDRAXRD) HydraSwap: Native Swap Platform in the Radix DLT Ecosystem HydraSwap (https://hydraxrd.com/swap) is a decentralized application (dApp) for token swapping built natively for the Radix DLT (/contents/tech/core-protocols/radix-engine) platform, part of the HYDRA ecosystem – a community project associated with the $HYDR (https://dashboard.radixdlt.com/resource/resource_rdx1t4kc2yjdcqprwu70tahua3p8uwvjej9q3rktpxdr8p5pmcp4almd6r) memecoin. Designed to facilitate accessible and efficient digital-asset exchanges, HydraSwap routes trades through the Astrolescent (/ecosystem/astrolescent) DEX aggregator (https://astrolescent.com/) , which optimizes swap routes across liquidity pools from multiple protocols (such as Astro_Multi and OciSimple) to minimize price impact and fees. Technical Integration with the Astrolescent API Integrating the Astrolescent (https://astrolescent.com/) aggregator API lets HydraSwap calculate optimal swap routes, accepting parameters such as inputToken, outputToken, inputAmount, and fromAddress via POST requests and generating executable manifests for the Radix Engine (/contents/tech/core-protocols/radix-engine) . The API returns data such as estimated outputTokens, priceImpact, and detailed routes with specific pools, ensuring permissionless execution compatible with Scrypto (/developers/scrypto/01-fundamentals) , the Radix smart-contract language focused on digital assets. The $HYDR Token The HYDRA ecosystem's native token, $HYDR (https://dashboard.radixdlt.com/resource/resource_rdx1t4kc2yjdcqprwu70tahua3p8uwvjej9q3rktpxdr8p5pmcp4almd6r) , is a Radix-native memecoin described on-ledger as symbolizing "Radix's rebirth and its shift toward community-led ownership." Minting is permanently denied and the rule is locked, so no more $HYDR can ever be created; burning, by contrast, is open to every holder, which makes the supply a figure that only falls. It does: 966.8 million on 26 July 2026 and 965,821,366 on 6 August, roughly a million tokens burned in eleven days. Both the authorities and the live total are readable on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4kc2yjdcqprwu70tahua3p8uwvjej9q3rktpxdr8p5pmcp4almd6r) (epoch 332526, state version 546295971). Main Features and Benefits • Optimized swaps: liquidity aggregation across Radix DEXs for better rates and lower slippage, with manifest support for transactions via the Radix Wallet (/contents/tech/core-protocols/radix-wallet) or dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) . • Native asset security: built on Radix's asset-oriented model, in which tokens are ledger-level resources rather than balances in a contract, reducing a class of custody and approval bugs common on account-based chains. • Accessibility: an intuitive interface for buying and selling native Radix tokens (e.g., $XRD, $HYDR), promoting community adoption across the HYDRA ecosystem. External Links - HydraSwap dApp (https://hydraxrd.com/swap) - $HYDR resource on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t4kc2yjdcqprwu70tahua3p8uwvjej9q3rktpxdr8p5pmcp4almd6r) - Astrolescent DEX aggregator (https://astrolescent.com/) - HYDRA on X (https://x.com/HYDRAXRD) - HYDRA on Telegram (https://t.me/hydraxrd) ## Hug URL: https://radix.wiki/ecosystem/hug Updated: 2026-09-01 Summary: Hug ($HUG) is a meme coin launched on the Radix network by the community. Their mission is to bring peace and happiness to everyone. HUG was founded a… Hug ($HUG) is a meme coin launched on the Radix network by the community. Their mission is to bring peace and happiness to everyone. In memoriam HUG was founded and led by a community member known as Zombie ( @zombieXRD (https://x.com/zombieXRD) ). In 2026 the Radix community mourned his passing. He is remembered for creating HUG – a deliberately feel-good, fair-launched meme coin that grew into one of the largest community tokens on Radix by market capitalisation – and for remaining a warm and well-liked presence across the ecosystem’s meme-coin community, where members have paid tribute to him. Status HUG is dormant. The project’s website, hug.meme, no longer resolves, and most of the planned features in its original roadmap (below) were never delivered. The $HUG token itself remains live on-ledger – a fixed supply of 100 billion, with minting, burning, freezing and recall all permanently denied – and can still be held and traded on Radix DEXs such as Ociswap (/ecosystem/ociswap) and CaviarNine (/ecosystem/caviarnine) . How to buy $HUG Ociswap - https://ociswap.com/ (https://ociswap.com/) Caviarnine - https://www.caviarnine.com (https://www.caviarnine.com) Roadmap (historical) The community’s original roadmap is preserved below for reference. As the project went dormant, most of the “coming soon” items were never delivered. - Token launch / DEX listings (complete) $HUG token was fairly launched on the 30th of December 2023 on Ociswap and then Caviarnine. No presale, no ICO, same price for all. - Website launch (complete) Every self-respecting meme should have its own website. Now it's done with this great place where the $hug fam can find all the info they need about the project. - Coingecko listings Because our mission is to hug the world, the world needs to find $HUG. - HUGfunding (coming soon) A decentralized protocol that allows users to contribute to an NFT fundraiser. If the fund goal is met the funds are locked and sent to the desired recipient. If the goal is not met funds are redistributed back to the original funders. - Hug bot (coming soon) We believe not only that everyone needs a hug, but that everyone should give a hug. Even robots. That’s why we want to program one that can be used to give hugs in an efficient and friendly way on telegram. Beep boop. - Proof-of-Hug Our unique, and never before seen distribution method. Community members and people of the world alike will be rewarded for simply deserving a hug. It’s truly a revolution. - HalveHUGgening The amount of HUG distrubuted will be cut by 50% each year. Although the number of yearly hugs being distributed will decrease, it’s rumored that each one will be jam packed with more love too. Wow. Much Hug. So love. - NFT Collection While we are not ready to publicly announce any of the details about our NFT collection, one thing has been made abundantly clear. Our community demands cute and cuddly NFTs; and they hug really hard. We are scared of them. - Hug tales A collaborative story project, about the origins and life of HUG - Hug the world ❤️ There’s a great big world out there, and our goal is to HUG and help as many people as we possibly can. ➕ Much more to come... As the project is young and driven by the community, much more features and phases are planned (marketing, listings ...) but not indicated on the roadmap. Please note that the roadmap is subject to change. Collateral in the Weft exploit On 30 August 2026 HUG was the collateral in the largest exploit yet recorded on Radix. At 18:02:58 UTC a single transaction (https://dashboard.radixdlt.com/transaction/txid_rdx12lsyuggs587xt7m9uxjedtkdtz0lcnzh85g2w4x6wwdq3cuyhccs8ls3kc) bought 539,703.17 HUG for 70.6 XRD on Ociswap (/ecosystem/ociswap) , posted it as collateral at Weft Finance (/ecosystem/weft-finance) , and borrowed 47,280,000 LSULP and 13,100,500 XRD against it. Weft’s price feed carried HUG at 1,330.41 XRD a token at that moment, about ten million times the rate the same transaction had just paid, so the borrow cleared the protocol’s health check on arithmetic that was correct and an input that was not. The token itself did nothing. HUG has been a listed collateral resource on Weft since November 2024, and its Add collateral service there was switched off and locked on 6 June 2025 – 451 days before the exploit – while the neighbouring FlashOperation service stayed open, which is the route the transaction used. The full reading is on the Weft Finance (/ecosystem/weft-finance) page. Since the 00:15:00 UTC batch on 31 August, Weft’s Default PriceFeed (https://dashboard.radixdlt.com/component/component_rdx1czdvvanvdy6495phfgz8uv6n2semp2cpexcg6vvty6uaycc82adgyv) has published HUG at 0.0000000001 XRD, alongside nine other Radix-native tokens. The scale of the mispricing is easiest to see against the token’s real market. Read from the Ociswap API (https://api.ociswap.com/tokens/resource_rdx1t5kmyj54jt85malva7fxdrnpvgfgs623yt7ywdaval25vrdlmnwe97) at 03:17 UTC on 31 August 2026, HUG traded at 0.00012752730451 XRD ($0.000000105), with about $1,258 of pooled liquidity across its Ociswap pools and $11.50 of volume in the preceding 24 hours. Its on-ledger facts are unchanged: a fixed supply of 100,000,000,000 HUG (https://dashboard.radixdlt.com/resource/resource_rdx1t5kmyj54jt85malva7fxdrnpvgfgs623yt7ywdaval25vrdlmnwe97) at divisibility 18, read at mainnet epoch 339,680. Hug ($HUG) Type Community meme coin Symbol $HUG Founder Zombie ( @zombieXRD (https://x.com/zombieXRD) ) Launched 30 December 2023 – fair launch, no presale, no ICO Network Radix (/contents/tech/core-protocols/radix-engine) mainnet Total supply 100,000,000,000 HUG (fixed) Token authorities Mint, burn, freeze & recall all permanently denied Token $HUG on Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t5kmyj54jt85malva7fxdrnpvgfgs623yt7ywdaval25vrdlmnwe97) X @Hug_Radix (https://x.com/Hug_Radix) Website hug.meme (offline) ## Foton URL: https://radix.wiki/ecosystem/foton Updated: 2026-09-01 Summary: Foton is a Radix-native Non-Fungible Token (NFT) marketplace designed to facilitate a user-friendly experience for creators and traders in the NFT eco… Foton Type NFT marketplace & SDK on Radix (/contents/tech/releases/radix-mainnet-babylon) Focus Game-oriented, interoperable NFTs; creator storefronts, enforced royalties, community tooling Founders Rares (CTO) & Vlad (CEO) Social @FotonSDK (https://x.com/FotonSDK) Foton is a Radix-native Non-Fungible Token (NFT) marketplace designed to facilitate a user-friendly experience for creators and traders in the NFT ecosystem. Co-founders Rares and Vlad developed Foton with the aim of combining effective features from various market-leading websites, such as OpenSea, Discord, Shopify, and Amazon, to create a comprehensive NFT marketplace. Overview Foton is a modular NFT marketplace that focuses on the creation, management, and trading of tokenized digital assets for users. The platform supports creators from various backgrounds, including artists, designers, entrepreneurs, influencers, and brands of different sizes. Foton enables these creators to monetize their creations as NFTs and establish connections with their audience or customers. Key Features - Supporting a wide range of creators - Offering an end-to-end solution for launching NFT collections - Functioning as an individual store aggregator - Providing various NFT types - Enhancing the experience for creators and traders Founders Rares Rares, the co-founder and CTO of Foton, has a background in web development, programming, and blockchain technology. His passion for technology and learning contributed to the development of Foton, an NFT marketplace on the Radix Network. Vlad Vlad, the co-founder and CEO of Foton, has a strong background in mathematics, physics, and design. His diverse experiences and problem-solving skills have been instrumental in shaping Foton into a comprehensive platform in the NFT marketplace. Project History Foton traces its origins to Ideomaker, an end-to-end supply chain platform. The decision to create a separate platform specifically for digital assets emerged towards the end of 2021. Identifying pain points in the NFT industry and recognizing the opportunity to address these issues, Vlad and his team decided to develop Foton. The choice to build Foton on Radix was influenced by the Radix team's vision, determination, and ability to address the Trilemma and create a scalable, modern, decentralized form of money. Building Foton on Radix allows for a more efficient development cycle without the complexities often associated with the crypto industry, enabling Foton to focus on providing utility to its users through a comprehensive set of tools and an improved experience. Status check (20 August 2026) foton.is (https://foton.is) still answered HTTP 200 with 18,330 bytes on 20 August 2026, and the Discord (https://discord.gg/WggGWQdJXn) the site advertises still reported 358 members with 18 online. Three further checks made the same day are why this page now reads 🟠 Dormant rather than active. - The site has not been rebuilt since April 2023. foton.is is a Webflow export, and Webflow writes a build stamp into the top of every page it publishes. Foton's reads Last Published: Tue Apr 25 2023 12:00:02 GMT+0000 — three years and four months before this check. - It declares no Radix dApp. A dApp on Radix identifies itself to wallets by serving a dApp definition (/developers/frontend/04-dapp-definition-and-verification) at /.well-known/radix.json. foton.is returns its Webflow 404 page for that path, so there is no marketplace application behind the brochure for a wallet to connect to. - The Telegram handle on the site is no longer Foton's — the section below. None of this is a shutdown, and Foton has announced none: the entity is reachable, the Discord is populated, and the contracts it deployed are still on ledger. What is missing is anyone answering for it. That is the wiki's definition of dormant rather than closed; the full status vocabulary, and where every project sits in it, is on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) . The Telegram handle on foton.is is no longer Foton's foton.is links a Telegram channel at the handle @FotonMarketplace. That handle no longer belongs to the project. The channel standing behind it on 20 August 2026 was created on 18 August 2026 at 07:11:55 UTC, holds one subscriber, and posted its only message ten seconds later, at 07:12:05: a token gate styled as Collab.Land (https://collab.land) , reading "This community is now protected by Collab.Land … Click below to verify your wallet and gain access". The button beneath it leads to a bot named @Collabslands_bot, which is not @collablandbot (https://t.me/collablandbot) — the one handle Collab.Land's documentation names as genuinely theirs (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . This wiki has catalogued the pattern before: nine Radix project handles were found re-registered the same way on 1 August 2026, at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . Foton is the first case where the project was still listed here as operating, and the first where the project's own live website still points at the handle — a visitor who follows the Telegram link from foton.is today arrives at the gate rather than at Foton. It is written above as text rather than as a link for that reason. Nothing legitimate asks you to connect or "verify" a wallet in an empty channel, whoever it appears to be. ## Fidenaro URL: https://radix.wiki/ecosystem/fidenaro Updated: 2026-09-01 Summary: Fidenaro is a decentralized social trading platform developed on the Radix network that allows users to follow and copy the positions of experienced c… Fidenaro Type Decentralized social / copy-trading platform on Radix Status 🟠 Dormant – site online ( fidenaro.com (https://fidenaro.com) ) but full "real-money" launch (planned Q1 2024) not shipped Founded Late 2022 Category DeFi – social / copy trading Links X (https://x.com/fidenaro) Fidenaro is a decentralized social trading platform developed on the Radix network that allows users to follow and copy the positions of experienced cryptocurrency traders. Etymology ‘Fidenaro’ is a neologism but could be roughly translated as ‘A place of trust’ in Latin. History Fidenaro was founded in late 2022. The full launch of the platform is planned for the first quarter of 2024, at which point traders and investors will be able to use the platform to its full extent and with real money. Founders - Andreas: (https://twitter.com/ThanosOfCrypto) Founder | Development - Erik: Founder | Marketing and Communications - Jan: (https://twitter.com/non___system) Process and Automation - Tobias: (https://twitter.com/Toby_XOXO_XRD) Founder | Marketing and Organization Features - Profit from Expertise: Users can harness the knowledge and time of expert traders. - Mutual Benefits: Fidenaro’s design ensures that both traders and investors derive benefits. While traders share their expertise to potentially boost investor profits, they, in turn, receive a portion of the gains. - Smart Leveraging: The platform offers tools that may help enhance user profits through informed leveraging decisions. - Security: The platform provides a transparent, controlled environment bolstered with the latest technological advancements for utmost security. - Scalability: Fidenaro's underlying foundation, the Radix network, ensures that even during peak usage, transaction fees remain affordable. - Transparency: The platform bolsters trust by making traders' trading histories and performances public. This aids investors in making informed decisions. For Traders: Proficient traders have the facility to augment their profits using margin. By sharing their trading strategies and outcomes, they can attract other Fidenaro users. If their strategies are convincing and their performance commendable, they might attract capital from other users to trade with. In this partnership, traders earn a fraction of the returns made on these investments. For Investors: Investors can navigate market volatility by banking on the expertise of Fidenaro's traders. The platform assists in monitoring each trader's strategy and success, creating the necessary transparency for investment decisions. Barring the trader's fee, profits are directly transferred to the investor's wallet upon selling. $FDN Token In 2024, Fidenaro plans to launch the $FDN Token. This will give users the opportunity to invest in Fidenaro and benefit from the platform's development. Users will also be able to earn $FDN Tokens through various actions in which they support Fidenaro. Roadmap - Q4, 2023 | Beta Launch - SAPPHIRE: The open beta launch will enable users to acquaint themselves with Fidenaro's features, all while using virtual money to ensure risk-free testing. - Q2, 2024 | Fidenaro Launch - EMERALD: With the platform's official launch, both traders and investors can fully utilize Fidenaro with actual money. - 2024 | FDN Token Launch - DIAMOND: The introduction of the FDN token will present users with investment opportunities in Fidenaro. Additionally, users will have the chance to earn FDN tokens through various supportive actions towards Fidenaro. See also - Astrolescent (/ecosystem/astrolescent) – Radix DeFi aggregator & trading front-end - Radix Engine (/contents/tech/core-protocols/radix-engine) – the transaction model underpinning on-ledger copy trading ## $EARLY URL: https://radix.wiki/ecosystem/early Updated: 2026-09-01 Summary: $EARLY is a cryptocurrency token operating on the Radix distributed ledger technology (DLT) . It is primarily designed for use within the Radix ecosys… Type Token (community / utility) Network Radix (/contents/tech/core-protocols/radix-engine) Launched January 2024 Supply 1,000,000,000 EARLY (https://dashboard.radixdlt.com/resource/resource_rdx1t5xv44c0u99z096q00mv74emwmxwjw26m98lwlzq6ddlpe9f5cuc7s) (fixed; non-mintable) X @early_radix (https://x.com/early_radix) Telegram early_xrd (https://t.me/early_xrd) $EARLY is a cryptocurrency token operating on the Radix distributed ledger technology (DLT) (/contents/tech/core-protocols/radix-engine) . It is primarily designed for use within the Radix ecosystem, with a focus on providing utility for early adopters and enthusiasts. The token's name and branding revolve around the concept of being "early" to a potentially transformative technology, which is a commonly shared feeling in the Radix community (https://stillearly.tech/) . Overview As of 25 July 2026, $EARLY trades at approximately 0.0259 XRD (about US$0.0000326) per token (https://ociswap.com/) , for a market capitalisation of roughly US$32,000 and a 7-day on-ledger trading volume near US$160, per Ociswap (https://ociswap.com/) market data. These figures sit far below the token's 2024 peak – around US$1.1 million market cap and US$53.6k weekly volume at an October 2024 snapshot – reflecting both the broad decline in XRD-denominated ecosystem token values and thin recent trading. Of a fixed one-billion-token supply, about 980 million (98%) is in circulation (https://dashboard.radixdlt.com/resource/resource_rdx1t5xv44c0u99z096q00mv74emwmxwjw26m98lwlzq6ddlpe9f5cuc7s) , and the resource is non-mintable and non-burnable. The token's price is denominated in XRD (/contents/tech/core-protocols/xrd-token) , the native asset of the Radix network (/contents/tech/core-protocols/radix-engine) . $EARLY is associated with a suite of technologies and services collectively known as earlyTech (https://stillearly.tech/) . These include trading tools like earlyBot, information services such as earlyAlerts and earlyGPT, and community engagement features like earlyIntern. A significant component of the $EARLY ecosystem is earlyStudios (https://stillearly.tech/studios/about) , a platform for distributing unique art and launching experimental projects for $EARLY token holders. The token's community emphasizes the idea of being "early" to the Radix technology, with the tagline "You're still $EARLY ...but not for long" (https://stillearly.tech/) frequently used in their messaging. This philosophy underpins much of the token's branding and community culture. It's important to note that while $EARLY operates within the Radix ecosystem, it is a separate entity from Radix (XRD) itself. As with all cryptocurrencies, potential users and investors should be aware of the volatility and risks associated with such digital assets. History The precise launch date and detailed history of $EARLY are not explicitly stated in the provided documentation. However, we can infer some information about its development and context within the Radix ecosystem. $EARLY is closely associated with the Radix distributed ledger technology (DLT), which forms the foundation of its operation. The token appears to have been created to serve the Radix community (https://stillearly.tech/) , particularly focusing on early adopters and enthusiasts of the Radix technology. The development of $EARLY seems to have been accompanied by the creation of several associated technologies and services, collectively known as earlyTech (https://stillearly.tech/) . These include trading tools, information services, and community engagement features, suggesting a planned ecosystem around the token. A significant milestone in the history of $EARLY was the launch of earlyStudios (https://stillearly.tech/studios/about) , a platform for distributing unique art and launching experimental projects for $EARLY token holders. The exact date of this launch is not provided in the available documentation. The token's history is closely tied to its community, which has developed a unique culture around the concept of being "early" to a potentially transformative technology. This is reflected in the token's name and the tagline "You're still $EARLY ...but not for long" (https://stillearly.tech/) , which has become a central theme in the token's messaging and community engagement. As of October 5, 2024, $EARLY has established itself within the Radix ecosystem, with a market capitalization of approximately US$1.1 million (https://stillearly.tech/) . However, it's important to note that this represents a snapshot in time, and the token's value and market presence may have fluctuated significantly since its inception. The history of $EARLY also includes the development of the Studio Pass system (https://stillearly.tech/studios/studio-pass) , which was implemented to manage access to earlyStudios drops. The initial distribution of these passes involved an airdrop to holders of 50k+ $EARLY tokens, marking a significant event in the token's history. It's worth noting that the full history of $EARLY, including its inception, major developmental milestones, and any significant events or changes in its ecosystem, would require additional sources beyond the provided documentation for a comprehensive account. Technology The technology behind $EARLY is closely tied to the Radix distributed ledger technology (DLT) and a suite of associated tools and services known as earlyTech. This section outlines the key technological components of the $EARLY ecosystem. earlyTech earlyTech refers to a suite of technological tools and services associated with $EARLY. These include: - earlyBot: This is described as enabling "#1 Fastest trading on Radix" (https://stillearly.tech/) . earlyBot allows users to "Trade anywhere, anytime" (https://stillearly.tech/) . As of the documentation date, 6.66m XRD had already been traded (https://stillearly.tech/) using earlyBot. - earlyAlerts: This tool is designed to help users "Snipe new pools, Spot the rugs, Avoid DEX lag" (https://stillearly.tech/) . It appears to be an information service to assist traders in making timely decisions. - earlyIntern: This feature allows users to "Tip other users" (https://stillearly.tech/) and supports "20+ supported tokens" (https://stillearly.tech/) . It also enables users to "Earn for content" (https://stillearly.tech/) , suggesting a content creation and reward system. - earlyGPT: Described as a "propetieteary(?) algorithm LLM chat experience" (https://stillearly.tech/) , earlyGPT appears to be an AI-powered chat interface, though the exact capabilities are not detailed. - Studios: This is a "Creative launch pad and drop house" (https://stillearly.tech/) within the $EARLY ecosystem. It includes features like "Shitcoin Russian Roulette" and "Shitcoin Transformer" (https://stillearly.tech/) , though the specifics of these features are not explained in the documentation. Studio Pass Technology The Studio Pass (https://stillearly.tech/studios/studio-pass) is a key technological component of the $EARLY ecosystem. It's an NFT (Non-Fungible Token) that gives holders permission to mint particular drops from earlyStudios. The Studio Pass implements dynamic metadata, which is updated after each snapshot to reflect whether the holder met the threshold for a particular drop. Features and Utility $EARLY offers a range of features and utilities within the Radix ecosystem, primarily centered around trading, information services, community engagement, and creative content. These features are largely provided through the earlyTech suite of tools and services. Trading - earlyBot: - Described as the "#1 Fastest trading on Radix" (https://stillearly.tech/) - Allows users to "Trade anywhere, anytime" (https://stillearly.tech/) - As of the documentation date, 6.66m XRD had been traded using earlyBot (https://stillearly.tech/) - Fast Transactions: - The $EARLY ecosystem emphasizes speed, with claims of being the "#1 Fastest trading on Radix" (https://stillearly.tech/) Information and Alerts - earlyAlerts: - Designed to help users "Snipe new pools, Spot the rugs, Avoid DEX lag" (https://stillearly.tech/) - Provides timely information to assist traders in decision-making - earlyGPT: - Described as a "propetieteary(?) algorithm LLM chat experience" (https://stillearly.tech/) - Allows users to "Check if you're still early" (https://stillearly.tech/) using an AI-powered chat interface Community Engagement - earlyIntern: - Enables users to "Tip other users" (https://stillearly.tech/) - Supports "20+ supported tokens" (https://stillearly.tech/) for tipping - Allows users to "Earn for content" (https://stillearly.tech/) , suggesting a content creation and reward system - Community Roles: - The $EARLY community has various roles and titles, including "Daddy Shill", "Karma Collector", "Corporate Priest" (https://stillearly.tech/) , among others - Community Activities: - Free Taco Tuesdays (https://stillearly.tech/) are mentioned as a community event earlyStudios - Creative Platform: - Described as a "Creative launch pad and drop house" (https://stillearly.tech/studios/about) - Facilitates the distribution of unique art from curated artists (https://stillearly.tech/studios/about) and the launch of experimental projects - Studio Pass: - An NFT that gives holders permission to mint particular drops (https://stillearly.tech/studios/studio-pass) from earlyStudios - Features dynamic metadata that updates after each snapshot to reflect eligibility for drops - Artist Collaboration: - earlyStudios provides a platform for artists to feature their work (https://stillearly.tech/studios/apply) and create limited edition collections - Collections: - Various types of collections are mentioned, including "Art", "Collectible", and "Experimental" (https://stillearly.tech/studios/collections) Experimental Features - Shitcoin Russian Roulette: - Mentioned as a feature, but details are not provided (https://stillearly.tech/) - Shitcoin Transformer: - Listed as a feature with a "6.9" rating (https://stillearly.tech/) , but specifics are not explained Token Utility - Access to Drops: - Holding a certain amount of $EARLY tokens makes users eligible for various drops and features (https://stillearly.tech/studios/about) within the ecosystem - Staking: - While mentioned in the navigation menu (https://stillearly.tech/studios/collections) , details about staking mechanisms or rewards are not provided in the available documentation It's important to note that while these features and utilities are described in the $EARLY documentation, the specific mechanisms of how they function or their effectiveness are not detailed. As with any cryptocurrency project, potential users should conduct their own research and consider the associated risks. Token Economics The token economics of $EARLY are characterized by its market metrics, supply dynamics, and utility within the Radix ecosystem. However, it's important to note that the available documentation provides limited information on the comprehensive tokenomics of $EARLY. Market Metrics The metrics below are an October 2024 snapshot (see the Overview above for current, dated figures): - Market Capitalization: - US$ 1.1m (https://stillearly.tech/) - This figure represents the total market value of the circulating supply of $EARLY tokens. - Trading Volume: - 7d Volume US$ 53.6k (https://stillearly.tech/) - This indicates the total value of $EARLY traded over a 7-day period. - Price: - 0.0681 XRD (https://stillearly.tech/) - The price of $EARLY is denominated in XRD, the native token of the Radix network. Supply Dynamics The supply characteristics of $EARLY are partially described in the documentation: - Circulating Supply: - 100% (https://stillearly.tech/) - This suggests that all minted $EARLY tokens are in circulation and available in the market. - Total Supply: - Not explicitly stated in the provided documentation. - Max Supply: - Not mentioned in the available information. Token Utility and Value Drivers Several factors contribute to the utility and potential value of $EARLY tokens: - Access to earlyStudios Drops: - Holding a certain amount of $EARLY tokens makes users eligible for various drops (https://stillearly.tech/studios/about) within the earlyStudios ecosystem. - Studio Pass Eligibility: - The amount of $EARLY held determines eligibility for minting drops (https://stillearly.tech/studios/studio-pass) through the Studio Pass system. - Community Engagement: - $EARLY can be used for tipping other users and earning rewards for content creation (https://stillearly.tech/) through the earlyIntern system. - Trading Utility: - While not explicitly stated, the existence of earlyBot for fast trading (https://stillearly.tech/) suggests that $EARLY may have utility in trading activities within the Radix ecosystem. Token Distribution The documentation does not provide specific information about the initial token distribution, token sale events, or allocation to different stakeholders (e.g., team, advisors, community fund). Staking and Rewards While staking is mentioned in the navigation menu (https://stillearly.tech/studios/collections) , the documentation does not provide details about staking mechanisms, rewards, or how staking might affect the token supply and value. Trading Pairs and Liquidity The documentation mentions trading volumes but does not provide specific information about trading pairs or liquidity pools involving $EARLY. It's important to note that the token economics of cryptocurrencies can be complex and subject to change. The information provided here is based on the available documentation at the time of writing. Potential investors and users should conduct their own research and consider the volatility and risks associated with cryptocurrency markets. Community and Culture The $EARLY token has fostered a unique community and culture within the Radix ecosystem, characterized by a shared philosophy, engagement features, and a distinct set of cultural elements. "Still Early" Philosophy The core philosophy of the $EARLY community revolves around the concept of being early adopters of potentially transformative technology: - Tagline: - The community frequently uses the tagline "You're still $EARLY ...but not for long" (https://stillearly.tech/) , emphasizing the perceived opportunity in the project. - Community Sentiment: - Being early is described as a "commonly shared feeling in the Radix community" (https://stillearly.tech/) and is portrayed as both an opportunity and a source of potential doubt. - Future Outlook: - The community expresses strong belief in the potential of Radix, describing it as "the most promising opportunity to take DeFi mainstream" (https://stillearly.tech/) . Community Engagement Features The $EARLY ecosystem includes several features designed to foster community engagement: - earlyIntern: - This system allows users to "Tip other users" (https://stillearly.tech/) and "Earn for content" (https://stillearly.tech/) , promoting active participation and content creation within the community. - earlyStudios: - Described as a "Creative launch pad and drop house" (https://stillearly.tech/studios/about) , this platform encourages community engagement through art and experimental projects. - Studio Pass: - This NFT-based system (https://stillearly.tech/studios/studio-pass) creates a sense of exclusivity and encourages continued engagement with the platform. Community Roles and Titles The $EARLY community has established a variety of unique roles and titles for its members, including: - "Daddy Shill" (https://stillearly.tech/) - "Tom Newton Quant ॐ" (https://stillearly.tech/) - "Robo Cock R&D" (https://stillearly.tech/) - "Woopty Tik Tok Jock" (https://stillearly.tech/) - "Karma Collector" (https://stillearly.tech/) - "Dr Pickle" (https://stillearly.tech/) - "Buzz Ambassador" (https://stillearly.tech/) - "Soundie Lead Integrator" (https://stillearly.tech/) - "Corporate Priest" (https://stillearly.tech/) These titles appear to be a mix of humorous and functional roles within the community, although their specific responsibilities or how they are assigned is not detailed in the documentation. Community Activities The community engages in various activities, although details are limited in the provided documentation: - Free Taco Tuesdays: - Mentioned as a regular community event (https://stillearly.tech/) , although specifics are not provided. - Content Creation: - The community encourages content creation, with the ability to "Earn for content" (https://stillearly.tech/) through the earlyIntern system. - Artist Collaboration: - The community supports artists featuring their work (https://stillearly.tech/studios/apply) through earlyStudios. Community Humor and Language The community appears to have developed its own style of humor and language: - Unconventional Spelling: - The use of terms like "earlyAdoptoors" (https://stillearly.tech/) suggests a playful approach to language within the community. - Self-Deprecating Humor: - Features like "Shitcoin Russian Roulette" and "Shitcoin Transformer" (https://stillearly.tech/) indicate a self-aware, humorous approach to cryptocurrency culture. It's important to note that while these community and cultural elements are mentioned in the $EARLY documentation, the depth of community engagement, the effectiveness of these features, and the overall health of the community are not quantified or independently verified in the available materials. rlyfun buybacks $EARLY is the buyback target of rlyfun (/ecosystem/rly-fun) , the Radix meme-coin launchpad. The platform states that after covering servers, IPFS hosting and other running costs, all remaining XRD profit is used to buy $EARLY on the open market (https://rly.fun/about) , executed manually and without prior announcement to avoid front-running, with an automated system described as in development. The buybacks are funded by the launchpad's 0.9% buy, 1% sell, 1% graduation and 2.5% dev-reward fees. The token itself (https://dashboard.radixdlt.com/resource/resource_rdx1t5xv44c0u99z096q00mv74emwmxwjw26m98lwlzq6ddlpe9f5cuc7s) is non-mintable with a fixed one-billion supply, so a buyback removes tokens from the float rather than offsetting new issuance. ## Doubt/it! URL: https://radix.wiki/ecosystem/doubt-it Updated: 2026-09-01 Summary: Doubt It (styled "Doubt/it!" ) is a trivia game "where you call the bluff", made by VandyILL . It exists as an original physical board game and as a f… Doubt It Type Bluff-calling trivia game (board + digital) Network Radix DLT Token $DOUBT Doubt It (https://doubtit.digital) (styled "Doubt/it!") is a trivia game "where you call the bluff", made by VandyILL. It exists as an original physical board game and as a free-to-play, browser-based, multiplayer/multi-device digital version at doubtit.digital (https://doubtit.digital) . $DOUBT and Quack Space Players earn $DOUBT tips and other tokens by answering polls on Quack Space (/ecosystem/quackspace) , with gameplay and poll integration rolling out on doubtit.digital (https://doubtit.digital) . The board game was sold at doubtitgame.com, a Shopify storefront whose TLS certificate expired on 15 November 2025 and which now answers Shopify's "domain not connected" response – the domain is registered until November 2026, but the store no longer loads in any browser (checked 12 August 2026). doubtit.digital (https://doubtit.digital) still carries a "buy the original boardgame" link to it. The digital game and the token are unaffected. The $DOUBT token on-ledger $DOUBT is a fungible resource on the Radix ledger with a fixed supply of 100,000,000 and 18 decimal places. Its on-ledger authorities (https://dashboard.radixdlt.com/resource/resource_rdx1tkjd8w6wcm3suwtumaffd2fxeqsdgzq4ruempfnyuk98dkehwxtpq2) are all set to deny_all and the rule set is locked: the token cannot be minted, burned, frozen or recalled by anyone, and those permissions can no longer be changed. The supply is therefore fixed for the life of the resource rather than fixed by policy. The resource metadata also carries an attribution the game's public branding does not: the description reads "A game by Rook & Board Games LLC. (C) 2024", placing a registered company behind the VandyILL name. $DOUBT has been listed on Ociswap (/ecosystem/ociswap) since 9 July 2024. As of 5 August 2026 the token traded at about US$0.000042, against a pool of roughly US$981; cumulative volume since listing was near US$23,900, of which about US$1.92 fell in the preceding seven days. The market is live but effectively untraded — a distinction worth keeping separate from whether the game itself is being played. ## DeXian Protocol URL: https://radix.wiki/ecosystem/dexian-protocol Updated: 2026-09-01 Summary: Status note (July 2026): DeXian's website and documentation (dexian.io) are offline and the project appears dormant on Radix. Its KaiYuan Epoch valida… Project DeXian Protocol (formerly DeXian Staking Earning, DSE) Type Liquid staking and lending protocol Network Radix (/ecosystem) Status 🔴 Closed — dexian.io no longer resolves (NXDOMAIN, checked 6 August 2026) Active from 2022 (team involved with Radix since 2018) Founders Dust and Martin Validator --KaiYuan Epoch-- (https://dashboard.radixdlt.com/network-staking/validator_rdx1sweyknyzw9lzh6hdjeq2avh9gg5g6l7dd8he77khnv76ac8ut84hq4) — still registered, ~3.76M XRD staked, 1% fee, 0% uptime over the trailing week and month (read on-ledger 6 August 2026, epoch 332526, state version 546295971) Category Finance / DeFi X @DeXianProtocol (https://x.com/DeXianProtocol) GitHub dexianProtocol (https://github.com/dexianProtocol) Status note (July 2026): DeXian's website and documentation (dexian.io) are offline and the project appears dormant on Radix. Its KaiYuan Epoch validator (https://dashboard.radixdlt.com/network-staking/validator_rdx1sweyknyzw9lzh6hdjeq2avh9gg5g6l7dd8he77khnv76ac8ut84hq4) remains registered on-ledger. Links to the defunct site and a removed founder interview have been unwrapped. DeXian Protocol, formally known as DeXian Staking Earning (DSE), was a liquid staking protocol based on Radix. The protocol offered users a unique opportunity to join a liquid staking pool and earn stable proceeds through the DeXian service. Notably, users can immediately redeem their $XRD investments without the typical waiting period associated with the Radix unstaking delay. Background Developed by the technical team of KaiYuan Epoch Validator (https://dashboard.radixdlt.com/network-staking/validator_rdx1sweyknyzw9lzh6hdjeq2avh9gg5g6l7dd8he77khnv76ac8ut84hq4) , DeXian had been actively involved with Radix since 2018. The team participated in early Betanet network testing in 2021 and had been operating validators on Olympia (/contents/tech/releases/radix-mainnet-olympia) and Alexandria (/contents/tech/releases/radix-developer-environment-alexandria) . DeXian also contributed to a series of Radix Scrypto-Challenges and played a pivotal role in promoting Radix within the Chinese community by translating key white papers, including those on Radix DeFi and the Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus. Features DeXian Protocol operated as a platform that offered various services for users to participate in staking and lending on the Radix network. Here are some key features and components of the DeXian Protocol platform: Liquid Staking DeXian Protocol provided a liquid staking service that allowed users to stake their tokens on the Radix network while maintaining liquidity. This meant that users can stake their tokens and still have the flexibility to use or trade them without waiting for the typical unstaking period. Fast Unstake The platform offered a fast unstaking feature, enabling users to redeem their staked tokens quickly. This allowed users to access and use their tokens without having to wait for the standard unstaking period, which can range from 10 to 15 days on the Radix network. Stable Returns DeXian Staking Earning (DSE) platform offered users stable returns on their staked assets. By participating in the liquid staking pool, users can earn rewards without sacrificing liquidity or waiting for the unstaking period DeXian Lending Protocol (DLP) DeXian Protocol included its own decentralized lending protocol called the DeXian Lending Protocol (DLP). DLP utilized RadixDLT's Scrypto technology and implemented algorithmic lending models to determine interest rates and provide efficient and flexible lending options. This feature allowed users to lend their assets and earn returns on their holdings. Delegation Services The platform offered delegation services, allowing users to delegate their tokens to validators on the Radix network. By delegating their tokens, users can actively participate in the consensus mechanism of the network and contribute to its security and operation. These features and components of the DeXian Protocol platform provided users with a comprehensive ecosystem for staking, lending, and active participation on the Radix network. Team The DeXian team comprised two main founders and five members, all of whom hail from the realms of computer technology and finance. The founders, Dust and Martin, brought a wealth of experience to the table. Dust, an early BTC enthusiast, has over a decade of experience in software development and has been deeply involved with projects like MakerDAO. Martin, on the other hand, holds an MSc in Finance from King's College London and has over three years of experience in the cryptocurrency and blockchain domain. Unique Selling Proposition While there were similarities between DSE and other platforms like Lido in terms of staking router, staking rewards distribution, and liquidity enhancement, DSE stood out due to its unique application scenarios and the differences between Radix and $ETH in terms of network mechanisms. Future Prospects Looking ahead, once Babylon and the native liquid stake go live, DSE planned to reimplement its services using Scrypto. This would allow any user to provide liquidity to the pool through the DSE protocol. Additionally, DeXian aimed to further integrate the funding pool with the Lending Protocol, thereby diversifying the DeFi ecosystem and expanding the practical application scenarios of $XRD. Security DeXian Protocol emphasized security and trust as crucial aspects of its platform. Here are some points highlighting the security measures and trustworthiness of DeXian Protocol: Audits DeXian Protocol underwent thorough security audits conducted by reputable and independent third-party audit firms. These audits aimed to identify vulnerabilities, ensure the platform's code quality, and enhance security measures. Code Transparency DeXian Protocol promoted code transparency by making its smart contracts and codebase publicly accessible. This allowed the community and security experts to review and verify the code, increasing trust and contributing to a more secure platform. Secure Infrastructure DeXian Protocol employed robust security measures and followed best practices to secure its infrastructure. This included implementing encryption, multi-factor authentication, and regular security updates to protect user assets and data. Community Trust and Reputation DeXian Protocol valued its community and strove to build trust through transparent communication, regular updates, and by being responsive to user feedback and concerns. The platform's reputation among users and the wider crypto community was an important factor in establishing trust. Decentralization The platform operated on decentralized networks like the Radix network, which is designed to ensure security through distributed consensus mechanisms. The decentralized nature reduces the risk associated with a single point of failure and increases resilience against attacks. ## DELIVER URL: https://radix.wiki/ecosystem/deliver Updated: 2026-09-01 Summary: DELIVER is a satirical community meme coin on Radix . Its on-ledger token description reads “…FOR WHEN RADIX ACTUALLY DELIVERS. 💚” – a tongue-in-chee… DELIVER Type Satirical community meme coin Symbol DELIVER Network Radix (/contents/tech/core-protocols/radix-engine) mainnet Total supply 1,000,000,000 DELIVER (fixed) Token authorities Mint, burn, freeze & recall all permanently denied Ledger description “…FOR WHEN RADIX ACTUALLY DELIVERS. 💚” Steward Reddicks (/ecosystem/reddicks) (DCKS) community Token DELIVER on Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t466mhd2l2jmmzxr8cg3mkwjqhs7zmjgtder2utnh0ue5msxrhyk3t) Traded on Ociswap (/ecosystem/ociswap) , RSwap (/ecosystem/rswap) Overview DELIVER is a satirical community meme coin (/ecosystem) on Radix (/contents/tech/core-protocols/radix-engine) . Its on-ledger token description reads “…FOR WHEN RADIX ACTUALLY DELIVERS. 💚” – a tongue-in-cheek reference to the community’s long wait for Radix to ship its scalability roadmap, from the original sharded-consensus vision through hyperscale-rs (/contents/tech/research/hyperscale-rs) and the “Xi’an” release. The DELIVER token (https://dashboard.radixdlt.com/resource/resource_rdx1t466mhd2l2jmmzxr8cg3mkwjqhs7zmjgtder2utnh0ue5msxrhyk3t) has a fixed total supply of one billion, with minting, burning, freezing and recall all permanently denied on-chain. Growth and Reddicks acquisition Through the first half of 2026 DELIVER grew into one of the largest meme coins on Radix; members of the Reddicks (/ecosystem/reddicks) community described it as the second-largest by market capitalisation. In mid-2026 the Reddicks project – which operates a protocol-owned treasury and its own DEX, RSwap – announced that it had acquired DELIVER, accumulating roughly 60 million DELIVER in the DCKS treasury along with the token’s Ociswap (/ecosystem/ociswap) pool badge. Reddicks stated its intent to pair the holdings against DCKS and use them to deepen liquidity on RSwap, framing the move as bringing DELIVER “under one community.” Reception As with many meme coins, DELIVER has drawn a mix of enthusiasm and caution. After large sell-offs by early holders and an apparent shift of the original developer’s attention toward other chains, some community members questioned whether an active project still stood behind the token, treating it primarily as a traded community asset. Reddicks’ acquisition was presented by its team as a way to steward the token and its liquidity going forward. Prospective holders are encouraged to verify the token’s on-ledger facts directly on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t466mhd2l2jmmzxr8cg3mkwjqhs7zmjgtder2utnh0ue5msxrhyk3t) . On-ledger facts DELIVER's terms are fixed, and were re-read at mainnet epoch 336,751 on 20 August 2026. The resource (https://dashboard.radixdlt.com/resource/resource_rdx1t466mhd2l2jmmzxr8cg3mkwjqhs7zmjgtder2utnh0ue5msxrhyk3t) carries a total supply of 1,000,000,000 at eighteen decimal places, with the minter, burner, freezer and recaller roles all set to DenyAll. So are the four updater roles that would otherwise let the owner switch any of them back on, which is what makes the supply fixed rather than merely unminted. The token's own metadata points at a site that has gone. Its info_url reads https://deliverxrd.com, and on 20 August 2026 that domain answers HTTP 404 from Wix nameservers. The metadata also publishes two social links, t.me/DELIVER_XRD and x.com/DELIVER_XRD. The Telegram handle no longer belongs to the project: the channel answering there was created on 1 June 2026, sixteen months after the token, and holds nothing but a fake Collab.Land token gate (/contents/resources/recycled-telegram-handles) pointing at a lookalike verification bot. The record is correctable even though the supply is not, because the token’s metadata roles resolve to its owner rather than to DenyAll and the owner badge is unburned; as of 30 August 2026 nobody has repointed it. Trading and liquidity have moved to the Reddicks (/ecosystem/reddicks) venues described above, and the token contract is unaffected by any of it, because none of its economic terms can be changed. External Links - DELIVER – Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t466mhd2l2jmmzxr8cg3mkwjqhs7zmjgtder2utnh0ue5msxrhyk3t) - Ociswap – Radix DEX (https://ociswap.com) - Reddicks (DCKS) – RADIX Wiki (/ecosystem/reddicks) ## CrumbsUp URL: https://radix.wiki/ecosystem/crumbsup Updated: 2026-09-01 Summary: CrumbsUp is an end-to-end platform designed to address the needs of Decentralized Autonomous Organizations (DAOs) built on Radix. The team also runs C… CrumbsUp – Radix Ecosystem Project Type End-to-end DAO management platform Category Ecosystem (/ecosystem) Blockchain Radix Status 🟠 Dormant – site live, platform idle on-ledger since April 2026 On-ledger record 21 DAOs, 11 proposals, 19 votes (30 August 2026) Native Token $CRUMB (1,000,000,000 fixed supply) Related Projects CrumbsNode (/ecosystem/crumbsnode) (validator node) Key Features DAO creation & management, proposal submission, governance voting, data analytics, automated processes X @crumbs_up (https://x.com/crumbs_up) Token $CRUMB on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t5xg95m0mhnat0wv59ed4tzmevd7unaezzm04f337djkp8wghz2z7e) Video YouTube Introduction (https://youtu.be/_KVVsLpFiDw?si=asDjJPA8WqnQQjhw) CrumbsUp is an end-to-end platform designed to address the needs of Decentralized Autonomous Organizations (DAOs) built on Radix. The team also runs CrumbsNode (/ecosystem/crumbsnode) . Introduction CrumbsUp aims to provide easy initiation and rapid scalability for DAOs without requiring technical expertise. The platform offers customizable features like proposal and voting mechanisms using a DAO's own governance token. CrumbsUp follows a Minimum Viable Product (MVP) approach with gradual enhancements to ensure quick time-to-market. The native $CRUMB token and CrumbsNode validator are also key components of the overall Crumbs ecosystem. Purpose DAOs represent a novel approach to organizational structures and governance. As decentralized organizations, DAOs operate through smart contracts on blockchain networks to distribute decision-making power amongst participants. DAOs promise to reshape organizational dynamics by promoting transparency, democracy and autonomy. However, DAOs face challenges like complex technology, lack of participation, scalability issues and legal uncertainty. They require suitable tools and infrastructure to launch and operate effectively. CrumbsUp aims to fill this gap by providing an intuitive end-to-end solution. The platform enables easy DAO initiation and management. Users can access DAO spaces, connect wallets, submit proposals, review, vote and monitor activity. CrumbsUp automates processes like voting and coordinates decision-making across large, diverse groups. The $CRUMB token also facilitates ecosystem growth through structured distribution and utility. By tackling key DAO challenges, CrumbsUp seeks to revolutionize the DAO landscape and unlock their disruptive potential. The platform's comprehensive features focus on simplifying DAO adoption and empowering their success. Platform The CrumbsUp platform provides end-to-end functionality for DAOs to manage their operations. Users can access a customized DAO space and connect their crypto wallets to participate. DAOs can configure their governance rules, structure types, voting timelines and member permissions. Key features include: - DAO Access and Management: Admins can setup and customize their DAO's space. Users can view info like guidelines, members and raise proposals. - Proposals, Review & Voting: Users submit proposals which admins can review and approve. Community members can view, discuss and vote on active proposals. - Intuitive Interface: The platform offers a user-friendly interface for members to participate in DAO activities. Customizable UI for personalized experience. - Automated Processes: CrumbsUp automates manual tasks like voting, streamlining operations as DAOs scale. - Data Analytics: Dashboards and reports provide insights into DAO activities and voting results. API access enables data retrieval. Governance Types CrumbsUp allows DAOs to choose different governance models based on their needs: - Token-based: Voting power based on token holdings. Aligns influence with economic stake. - Reputation-based: Members earn reputation through contributions. Rewards active participation. - Liquid Democracy: Delegate votes to others with more expertise on specific topics. - Futarchy: Use prediction markets to choose proposals with highest expected value. - Quadratic Voting: Allocate votes non-linearly to better reflect preference intensities. DAO governance has various approaches and CrumbsUp aims to provide options for customization aligned with a DAO's values and community. Service Offering CrumbsUp utilizes a token-based model with the native $CRUMB token on the Radix DLT. Key aspects include: - Free Platform Access: Users can access CrumbsUp without fees, only network transaction costs apply. - DAO Onboarding: Free to onboard DAOs, but minimum $CRUMB holdings required to create a DAO. - Proposal Development: Free to create ideas, but $CRUMB "fuel" needed to release proposals. Aligns with $XRD price. - Community Voting: Free for communities to vote on proposals. Encourages participation. - Service Upgrades: DAOs can upgrade features for a defined $CRUMB fee, catering to diverse needs. $CRUMB facilitates ecosystem growth by aligning incentives for usage without imposing excessive fees. Tokenomics The $CRUMB token has a fixed supply of 1 billion. Distribution: - 52% for liquidity and ecosystem development. - 10% for initial DEX listing. - 10% distributed over 24 months to CrumbsNode stakers. - 8% allocated to CrumbsUp founders, locked for 2 years. - 20% burned. Public sale enables broad access. Locked token portions ensure incentives aligned for growth. Distribution strategy fosters community ownership and engagement. Team CrumbsUp was founded by a team of 5 DLT enthusiasts based in Germany: - Vinny - Leads NFT creation, designs, networking and steering for CrumbsUp. Organized first German Radix meetup. - Nils - Key role in strategic decisions and utility development. Meetup co-organizer. - Timo - Drives marketing initiatives to increase visibility and community engagement. - Martin - Responsible for frontend development of CrumbsUp platform and solutions. - Stephan - Leads backend development of core CrumbsUp platform and components. The team aims to bring value to the Radix ecosystem, having been involved as investors and community members. Their ambition evolved into building CrumbsUp to address key DAO needs. Vinny and Nils provide leadership, strategic direction and business development. Timo, Martin and Stephan contribute specialized skills in marketing, design and engineering. Together, the team combines a strong understanding of blockchain and passion for empowering the DAO space. Token The $CRUMB token is live on Radix (/contents/tech/core-protocols/radix-engine) mainnet. Its supply and authorities are verifiable on-ledger: a fixed supply of 1,000,000,000, with minting and burning permanently denied and the token’s rules locked ( $CRUMB on the Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t5xg95m0mhnat0wv59ed4tzmevd7unaezzm04f337djkp8wghz2z7e) ). It trades on Radix DEXs and aggregators such as Ociswap (/ecosystem/ociswap) and Astrolescent (/ecosystem/astrolescent) . Website (30 July 2026): crumbsup.net now redirects to crumbsup.io (https://www.crumbsup.io) , the same project on a new top-level domain. The facts table has been repointed at the current address. On-ledger record The sections above describe what CrumbsUp set out to build. What it has recorded is separately verifiable, because a DAO platform mints its objects on the ledger, and CrumbsUp mints four kinds of them. The resource addresses below were taken from the platform's own front-end bundle and read at the Gateway (/contents/tech/core-protocols/radix-gateway-api) on 30 August 2026, epoch 339,390. Registry Current supply Most recent transaction CrumbsUp DAOs (https://dashboard.radixdlt.com/resource/resource_rdx1nfrc5swndv3dhntzzc2zfzpttmx57y9sfk3ajmldqpey5trvwm8p8z) 21 3 April 2026 CrumbsUp DAO Admin Badges (https://dashboard.radixdlt.com/resource/resource_rdx1n2dp5tgpqvtdu3keznue70fh8wcgmn40t5tz3er84cwm5fum38jrt3) 22 – CrumbsUp Proposals (https://dashboard.radixdlt.com/resource/resource_rdx1n2drsjp9fagqhn90jz2lwfy72wa00ka77a8fufk06udltqcykxtz0r) 11 14 January 2026 CrumbsUp Votes (https://dashboard.radixdlt.com/resource/resource_rdx1ntra9m8nevh0njvaqfrkvy6erzdwclzqjnnjzvvc3swvufv6y27lwy) 19 14 January 2026 Twenty-one DAOs have been created on the platform and, between them, they have produced eleven proposals and nineteen votes in the platform's lifetime. Nothing has been proposed or voted on since 14 January 2026. The platform component itself, component_rdx1cpupsxrv4y36n46d0d9elev9qwjw8p4up58h6ll6yff5p8sh20qckm, last appeared in a committed transaction on 3 April 2026, which is also when the most recent DAO was minted; the team's operating account last moved on 5 May 2026. The dApp definition account (https://dashboard.radixdlt.com/account/account_rdx168s540r23fg9yl64rhtqn668k52arur7wpxe6ysx9gy5urvkj9geak) still claims crumbsup.io and the site still serves, so the deployment is intact rather than abandoned. The token side agrees. On Ociswap (https://ociswap.com/resource_rdx1t5xg95m0mhnat0wv59ed4tzmevd7unaezzm04f337djkp8wghz2z7e) , read the same day, $CRUMB shows zero volume over one hour, twenty-four hours and seven days, an unchanged price across all three windows, roughly 85 USD of liquidity and a circulating market capitalisation near 133 USD, against about 19,400 USD of lifetime volume. On that record this directory lists CrumbsUp as 🟠 Dormant rather than Active. The judgement is about the product's own record and not about the team, which continues to run CrumbsNode (/ecosystem/crumbsnode) . Two limits are worth stating: the supplies above are what the registries hold now rather than everything ever minted, so a burned proposal would not be counted; and a DAO that was created here could have moved its day-to-day governance to a channel this measurement cannot see. What the ledger does establish is that the platform's own governance objects stopped being created seven months ago. External Links - CrumbsUp website (https://www.crumbsup.io/) - CrumbsUp on X (@crumbs_up) (https://x.com/crumbs_up) - $CRUMB on Ociswap (https://ociswap.com/resource_rdx1t5xg95m0mhnat0wv59ed4tzmevd7unaezzm04f337djkp8wghz2z7e) - CrumbsNode (/ecosystem/crumbsnode) – the team’s validator node - CrumbsUp introduction (YouTube) (https://youtu.be/_KVVsLpFiDw) ## Blockshard URL: https://radix.wiki/ecosystem/blockshard Updated: 2026-09-01 Summary: Blockshard is a Switzerland-based, non-custodial Web3 staking and validator provider that operates a validator node on the Radix network. Headquartere… Blockshard Type Validator & staking infrastructure Headquarters Zug, Switzerland Formerly LetzBake Radix role Validator node operator Other networks Tezos, Ethereum, Moonbeam, Moonriver, EigenLayer, SSV Network, Avail Affiliation UnitedBloc DAO (https://unitedbloc.com/) (founding member) Radix validator Blockshard 🇨🇭|🇧🇬 RadixUID (https://dashboard.radixdlt.com/network-staking/validator_rdx1svudtxxkegaeg6ks0qgjujfp8g80de2f63ygvfqug6zv987e99jk3q) — registered, 12,252,454.55 XRD staked, 1% fee (read on-ledger 17 August 2026, epoch 335,694) X / Twitter @blockshard1 (https://twitter.com/blockshard1) Blockshard is a Switzerland-based, non-custodial Web3 staking and validator provider that operates a validator node on the Radix (/contents/tech/core-protocols/radix-engine) network. Headquartered in Zug (registry CHE-140.033.377) and formerly known as LetzBake, Blockshard is a founding member of the UnitedBloc DAO (https://unitedbloc.com/) , an alliance of professional validator organisations. Overview Blockshard runs professional, enterprise-grade validator infrastructure across a range of proof-of-stake networks, prioritising high uptime, security, and a fully non-custodial (https://blockshard.io/) model in which delegators retain ownership of their assets at all times. Through its membership in UnitedBloc (https://unitedbloc.com/) , Blockshard also contributes to shared RPC endpoints, white-label nodes, and custom infrastructure for the wider validator community. Radix validator On Radix, Blockshard operates a validator node that secures the network under its delegated proof-of-stake consensus (/contents/tech/core-concepts/radix-governance) . Because staking on Radix is non-custodial, holders keep custody of their tokens and delegate XRD (/contents/tech/core-protocols/xrd-token) to a validator directly from the Radix Wallet (https://wallet.radixdlt.com/) – there is no account to create and no deposit to Blockshard. Validators and their fees can be browsed on the Radix Dashboard (https://dashboard.radixdlt.com/network-staking) , and stakers earn a share of network emissions proportional to the XRD delegated. Supported networks Alongside Radix ( XRD (/contents/tech/core-protocols/xrd-token) ), Blockshard's current network coverage (https://blockshard.io/) includes: - Tezos (XTZ) - Ethereum (ETH) - Moonbeam (GLMR) and Moonriver (MOVR) - EigenLayer - SSV Network (SSV) - Avail (AVAIL) For the definitive, up-to-date list of supported networks and validator addresses, refer to the Blockshard website (https://blockshard.io/) . Validator on the ledger Blockshard's Radix node is validator_rdx1svudtxxkegaeg6ks0qgjujfp8g80de2f63ygvfqug6zv987e99jk3q, and on the ledger it does not carry Blockshard's name alone. Its name metadata reads Blockshard 🇨🇭|🇧🇬 RadixUID and its description metadata describes it as a collaboration between Blockshard and RadixUID. RadixUID (/ecosystem/radixuid) is the Sofia-based Bulgarian community project already covered on this wiki, whose blog published “Stake to Blockshard” staking guides — the two flags in the node's name are Blockshard's Zug and RadixUID's Sofia. RadixUID's own validator is no longer registered and has since been renamed on-ledger, so this joint node is the part of that collaboration still running. Read at epoch 335,694 (state version 550,831,708, 17 August 2026), the validator is registered and sitting inside the active set with 12,252,454.55 XRD of delegated stake — 66th of the 188 registered validators by stake, and 0.257% of the XRD staked to registered validators network-wide. The active set is the top 100 registered validators by stake each epoch (https://docs.radixdlt.com/docs/validator) , and only stake delegated inside it earns emissions (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-penalties-are-calculated-general) , so delegators here are being paid. The node's fee is 1%, and the fee it charges matches the fee stored in its own substate with no pending fee-change request — worth checking rather than assuming, because the two diverge on a substantial minority of Radix validators. A further 313,400.04 XRD sits in the validator's pending withdraw vault (stake unbonding, in flight to unstake claims rather than lost), and 14,756.44 of the operator's own stake units are held in its locked owner-stake vault. Current figures for stake, fee and registration can be read at any time from the validator's page on the Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1svudtxxkegaeg6ks0qgjujfp8g80de2f63ygvfqug6zv987e99jk3q) . External links - Official website (https://blockshard.io/) - X / Twitter (@blockshard1) (https://twitter.com/blockshard1) - Telegram (https://t.me/blockshard) - Blog (Medium) (https://medium.com/blockshard) - UnitedBloc DAO (https://unitedbloc.com/) ## Bardix URL: https://radix.wiki/ecosystem/bardix Updated: 2026-09-01 Summary: Bardix is a bartending and cocktail-crafting game dApp on Radix mainnet. Players buy drinks and ingredients as NFTs using XRD, experiment to discover… Type Crafting Game (Cocktails) Status Active Category Game / NFT Network Radix Mainnet Assets Cocktail & ingredient NFTs + achievement badges Overview Bardix (https://bardix.pages.dev) is a bartending and cocktail-crafting game dApp on Radix (/contents/tech/core-protocols/radix-engine) mainnet. Players buy drinks and ingredients as NFTs (/contents/tech/core-protocols/nfts-on-radix) using XRD, experiment to discover cocktail recipes, and earn achievement badges. The dApp is built with the standard Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) and connects to the Radix Wallet. Gameplay - Craft & discover – mix spirits and ingredients to craft cocktails and unlock entries in a "Bar Encyclopedia" through recipe discovery. - Achievements – earn tiered achievement NFTs in Gold, Silver, and Bronze grades as milestones are reached. - Progression – advance through bartender ranks from "Apprentice Bartender" toward "Master Bartender," tracked by cocktail and recipe counters and crafting streaks. - Social – tip drinks to other players ("Tip the bartender"). External Links - Bardix – Play (https://bardix.pages.dev) ## AlphaDEX URL: https://radix.wiki/ecosystem/alphadex Updated: 2026-09-01 Summary: AlphaDEX is a decentralized order book exchange being built on Radix. The platform was founded by Fred Liebenberg and was part of the Radix Grants Pro… AlphaDEX Type On-ledger order book matching engine on Radix (/contents/tech/releases/radix-mainnet-babylon) Status 🟠 Dormant – engine live on-ledger, alphadex.net still up; its main front-end DeXter was retired in March 2026 Founder Fred Liebenberg Origin Radix Grants Program, Cohort 1 (https://www.radixdlt.com/blog/radix-grants-program-cohort-1-update-1) Front-end DeXter (/ecosystem/dexter) – community-built order book UI, retired March 2026 Fees Max 0.5% (volume-scaled); up to 90% returned to participants AlphaDEX is a decentralized order book exchange being built on Radix. The platform was founded by Fred Liebenberg and was part of the Radix Grants Program Cohort 1 (https://www.radixdlt.com/blog/radix-grants-program-cohort-1-update-1) . AlphaDEX launched on Radix as a scalable on-ledger order book matching engine, and powered the community-built DeXter (/ecosystem/dexter) front-end until DeXter’s contributors retired that project in March 2026 (https://t.me/dexter_discussion/27603) . The matching engine itself remains live on-ledger – the DeXter treasury’s wind-down buy-back order was placed on it. History Liebenberg first became interested in building traditional finance products on a decentralized network upon recognizing the potential and value of Web3. However, he acknowledged that Web3 could not compete with the simplicity of use that traditional finance offered to millions of daily users worldwide. After discovering Radix in 2018, Liebenberg decided to combine his love for programming and knowledge of the financial world to rebuild traditional financial products on Radix. In 2022, he quit his job to become a full-time Radix developer. In March 2023, Liebenburg participated in a Twitter space about AlphaDEX (https://twitter.com/i/spaces/1DXxyvypBBvKM) . Features AlphaDEX allows users to trade on an order book exchange in a non-custodial way and offers advanced trading strategies not possible or easy to implement on automated market maker (AMM) exchanges. The majority of fees earned on the exchange, up to 90%, are returned to users who contribute to its success. The platform is designed for other builders to build decentralized applications (dApps) on and share in the liquidity and efficiency generated by their combined users. AlphaDEX consists of three layers: - Direct on-ledger interaction with Scrypto components - A REST API and WebSocket server - A JavaScript SDK AlphaDEX ensures low fees to maintain efficiency, with a max trading fee of 0.5% that automatically reduces the higher the trading volume on a pair. Liquidity providers share in the majority of the fee earned when their order is matched. Founders Fred Liebenberg, a South Africa-based finance professional with 25 years of experience in traditional finance, founded AlphaDEX. Liebenberg has a strong background in designing derivative products, managing institutional investments, and analyzing portfolio manager strategies. Towards the Storm, Episode 9: AlphaDEX featuring Fred Liebenberg. (https://youtu.be/Ov5q1C_8hNw?si=OeTN-If1cHLfzJp5) Towards the Storm, Episode 9: AlphaDEX featuring Fred Liebenberg. Inspired by the potential of Web3 and programmable money through smart contracts, Liebenberg aims to bring the simplicity and security of traditional finance products to Web3 and empower the world to leverage the real opportunity that decentralized finance (DeFi) has to offer. ## Allnodes URL: https://radix.wiki/ecosystem/allnodes Updated: 2026-09-01 Summary: Allnodes is a non-custodial platform that offers hosting services for various types of nodes, including Masternodes, Validator Nodes, Super Nodes, Sen… Type Non-custodial node hosting & staking platform Founded 2018 Networks 90+ protocols Radix validator validator_rdx1s0v38ep… (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0v38ep79xx6y7cv86afuqw3z2sd074sldcvrld4lefw3fagvjdhnm) (registered) Validator fee 5% Delegated stake 12,111,117.60 XRD — rank 68 of 188 registered (epoch 337,230, 22 Aug 2026) Staking rate ~6.4% gross network-wide, ~6.1% after the 5% fee (see Network Emissions (/contents/tech/core-concepts/network-emissions) ); Allnodes advertises 14.00% Hosting uptime (vendor claim) 99.99% X @allnodes (https://x.com/allnodes) Allnodes is a non-custodial platform that offers hosting services for various types of nodes, including Masternodes, Validator Nodes, Super Nodes, Sentry Nodes, Full Nodes, and also supports staking in over 90 protocols. They provide reliable infrastructure for users to participate in blockchain networks and earn rewards. Overview Allnodes is a trusted partner for Radix, providing services related to hosting masternodes, validator nodes, super nodes, sentry nodes, full nodes, and staking[1]. Allnodes offers a non-custodial platform that allows users to easily host nodes, stake coins, and monitor blockchain addresses. They provide a secure and automated process with competitive prices and even offer a free trial. Allnodes supports Radix (XRD) staking, and they provide instructions on how to stake Radix on their platform Mission Allnodes' mission as a Radix Blockchain partner is to empower users to easily and securely participate in the Radix ecosystem. They aim to simplify the process of running nodes and staking for Radix (XRD) by providing a user-friendly platform with robust security measures. Allnodes takes a non-custodial approach to hosting and staking, meaning users retain full control over their assets while leveraging their platform's infrastructure to support the Radix network. They achieve this by automating the setup and maintenance of nodes and providing a straightforward interface for managing them. Overall, Allnodes' main goal is to help users join and contribute to the Radix network without the technical overhead. They strive to provide a reliable and trustworthy service to support the growth of the Radix ecosystem and make it accessible to a wider audience. Product and Services AllNodes is a platform that offers a range of products and services related to hosting and running masternodes and staking nodes. Here are some of the key products and services offered by AllNodes: Masternode Hosting AllNodes offers masternode hosting on a variety of networks. This includes hosting services for popular masternode coins like Dash, PIVX, and Zcoin. Users can set up and run a masternode on the AllNodes platform, which provides a reliable and secure hosting environment. Shared Masternode Hosting In addition to dedicated masternode hosting, AllNodes also offers shared masternode hosting for some coins. This allows users to pool their resources and run a masternode together, which can be a more affordable option with lower barriers to entry. Staking Node Hosting AllNodes also offers hosting services for staking nodes on a variety of networks. This includes popular staking coins like Cosmos, Tezos, and VeChain. Hosting your staking node on AllNodes provides a secure and reliable environment for staking activities. Dedicated Servers For users who require more customization, AllNodes offers dedicated server hosting. This allows users to set up and configure their own server environment, supporting a wider range of use cases beyond masternode and staking hosting. Node Monitoring AllNodes provides comprehensive node monitoring tools, which help users keep an eye on the health and performance of their masternodes and staking nodes. This includes real-time monitoring, alerts, and other diagnostics and troubleshooting tools. Benefits Joining Allnodes offers several benefits, including: Node Hosting Allnodes offers a secure non-custodial hosting service for various types of nodes, including Masternodes, Validator Nodes, Super Nodes, Sentry Nodes, Full Nodes. This service enables users to participate in blockchain networks and earn rewards without worrying about server maintenance or setup. Easy to Use The Allnodes platform is user-friendly, and users can easily launch a node within a few minutes by following simple instructions. Automatic Updates Allnodes ensures that users nodes are up-to-date with the required software updates, ensuring that the nodes are secure and free from vulnerabilities. Competitive Fees Allnodes charges competitive fees for its hosting services, and users can choose to pay in over 30 cryptocurrencies, including BTC, ETH, LTC, and more. High Uptime Allnodes provides 99.99% uptime for its node hosting services, ensuring that users' nodes are accessible and earning rewards when connected to the blockchain network Excellent Customer Support Allnodes provides excellent customer support to its users, with 24/7 availability through their support desk. They also have live chat support where users can ask any questions they may have about their hosting services. Wide Range of Blockchains Allnodes supports staking and hosting services in over 90 protocols, including notable protocols such as Ethereum, Cardano, Cosmos, Avalanche, and more. In summary, joining Allnodes offers users a secure and reliable platform to participate in various blockchain networks and earn rewards without worrying about server maintenance or setup. The platform is easy to use, and users can access competitive fees, high uptime, and excellent customer support. Sources: Allnodes Review - cult of money (https://www.cultofmoney.com/allnodes-review/) About Allnodes (https://www.allnodes.com/about) Allnodes – Radix (XRD) staking (https://www.allnodes.com/xrd) (current APR and instructions) Security and Trust Allnodes is considered a trusted partner in the Radix ecosystem and is known for providing secure hosting and staking services. They prioritize the security and reliability of their platform to ensure the safety of user funds and data. Allnodes utilizes advanced security measures to protect user assets and information. They implement encryption protocols, secure connections, and follow best practices for server and infrastructure security. Additionally, they employ monitoring systems and automated backups to ensure data integrity. As a non-custodial platform, Allnodes does not require users to transfer their funds to their control. Instead, users retain full control over their Radix coins, while Allnodes facilitates the hosting and staking process. On the Radix ledger Allnodes runs one registered Radix mainnet validator (/contents/tech/core-concepts/validator-nodes) , validator_rdx1s0v38ep… (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0v38ep79xx6y7cv86afuqw3z2sd074sldcvrld4lefw3fagvjdhnm) , which declares allnodes.com/xrd/staking (https://www.allnodes.com/xrd/staking) as its on-ledger info_url. Read from the Radix Gateway (https://mainnet.radixdlt.com/state/validators/list) at epoch 337,230 (22 August 2026, 15:06 UTC), it holds 12,111,117.60 XRD of delegated stake, ranking 68th of the 188 registered validators, accepts delegated stake, and charges a 5% validator fee with no fee change queued. That fee is double the 2–2.5% charged by most of the larger Radix validators, including Staatenlos Node (/ecosystem/staatenlos-node) at rank 15. The advertised rate and the emission schedule Allnodes' own protocols table lists Radix at 14.00% APR (read 22 August 2026), and earlier versions of this page repeated that figure. The ledger cannot pay it. Radix mints roughly 300 million XRD a year (/contents/tech/core-concepts/network-emissions) in staking emissions (/contents/tech/core-concepts/staking) , split pro-rata across the 100-validator active set, which held 4,685,788,128.24 XRD at the same epoch — a gross rate of 6.40%, or about 6.08% to a delegator after Allnodes' 5% fee. Two independent readings agree: Staatenlos Node tells its own readers to expect 6% a year (https://staatenlos.ch/staatenlos/radix-staatenlos-node/) at a 2.5% fee, and Staking Rewards publishes 6.01% (https://www.stakingrewards.com/earn/radix/trading-view/) for XRD. Treat the 14% as a headline figure that has not tracked the emission schedule, not as a rate available on Radix. ## AI Ventures URL: https://radix.wiki/ecosystem/ai-ventures Updated: 2026-09-01 Summary: AI Ventures is an experimental AI-agent dApp where AI agents run on-chain "companies." Its model is summarized on-site as "AI agents run off-chain. Th… Type AI Agent dApp Status Demo (Stokenet) Category AI / Agents Network Radix Stokenet (testnet) Builder linuxx_xrd Overview AI Ventures (https://ai-venture-radix.github.io) is an experimental AI-agent (/contents/tech/core-concepts/radix-for-ai-agents) dApp where AI agents run on-chain "companies." Its model is summarized on-site as "AI agents run off-chain. The company economy lives on Radix" – agent logic executes off-chain, while the treasury, permission badges, and revenue splits are enforced on-ledger. It runs as a demo on Radix Stokenet (/contents/tech/releases/stokenet) and is built by the same developer (linuxx_xrd) behind the AgentWallet for Radix (/developers/ai-agents/agent-wallet-ai) SDK. How It Works - Founder Badge – deploying a company mints a Founder Badge badge (/contents/tech/core-concepts/badges) to the creator's wallet, granting administrative control. - Agent Badges – the Founder mints Agent Badges with defined roles, spending limits, and daily caps, and can revoke them at any time. - Revenue splits – payments to a company are automatically split (a default 60/25/10/5) via smart contract, reconfigurable through an "Update Splits" function. - Controls – a "My Pending Actions" approval queue and emergency freeze/unfreeze/withdraw controls give the human owner oversight of agent activity. External Links - AI Ventures – Demo (https://ai-venture-radix.github.io) - Wallet-Agent-AI – Telegram (https://t.me/agent_wallet_ai_radix) ## AcuiQ URL: https://radix.wiki/ecosystem/acuiq Updated: 2026-09-01 Summary: AcuiQ is a privacy-first Traditional Chinese Medicine (TCM) protocol matcher. Users enter symptoms anonymously and receive acupuncture treatment proto… Category Healthcare / Decentralised Science (DeSci) Launched March 2026 On-ledger No – conventional web application; no Radix component, token or wallet integration Overview AcuiQ is a privacy-first Traditional Chinese Medicine (TCM) protocol matcher. Users enter symptoms anonymously and receive acupuncture treatment protocols matched from published case studies – no login, no account and no cookies. The project does not claim to store nothing: its own agent-discovery document states that searches are tallied by symptom with no visitor attached ( acuiq.com/llms.txt (https://acuiq.com/llms.txt) ), which is a per-symptom counter rather than a per-person record. The platform resolves a query to symptom concepts, expands it over synonyms and narrower terms, and matches by text similarity. The corpus is published as an exact census rather than a round number: as of 30 August 2026 the project's About & Method (https://acuiq.com/about) page records 5,242 entries linking symptoms to points, drawn from 773 catalogued points across 14,237 indexed symptom terms. Each entry is labelled with the kind of evidence behind it, and the split matters more than the total: 3,842 are study-reported and carry a DOI or article link, 1,066 come from clinical texts, compiled prescription sets or individual case reports, 332 are taken from acupuncture websites rather than the literature, and 2 lost their source in extraction. The page says the last two classes rank below the first and are being pruned. Acupoint entries carry muscular, dermal and skeletal views with cun measurement overlays. The public site exposes four browse surfaces – Symptoms (https://acuiq.com/symptoms) , Meridians (https://acuiq.com/meridians) , Treatments and an Atlas – plus a Research index. It carries a standing medical disclaimer: the site states it provides educational information about acupoints and self-treatment techniques, is not medical advice, and that users should consult qualified healthcare professionals before starting any treatment. Products Hot Spots™ Press Needles – $19.99 Tiny (~1.5mm) acupuncture needles on 3M backing tape, worn discreetly for extended periods. Safe for home use and designed for the press-needle protocols recommended by AcuiQ. Sold via Stripe checkout. Self-Treatment Guide – $12.99 (digital download) Comprehensive guide to self-acupuncture using press needles. Covers technique, safety, the cun measurement system, and protocol application for common conditions. Over 108 acupoint illustrations, 6.8MB PDF. Both are sold through Stripe and have their own pages – /buy/press-needles (https://acuiq.com/buy/press-needles) and /buy/treatment-guide (https://acuiq.com/buy/treatment-guide) – and are also reachable from symptom and protocol pages. The project states it does not recommend a product for a symptom. Research Output Alongside the matcher, AcuiQ publishes findings from its own extraction pipeline about the state of the acupuncture literature, at acuiq.com/research (https://acuiq.com/research) . Two essays are published. "TF4 Is Not a Point" documents that acupuncture point codes are published without a namespace, so a code written under one standard and read under another resolves to a different location: across 48,579 point references extracted from the literature, 37 resolved silently to the wrong point ( acuiq.com/research/codes-are-not-identifiers (https://acuiq.com/research/codes-are-not-identifiers) ). "Nothing in This Literature Ever Fails" audits the evidence base the matcher is built on and reports against its own database: 541 protocols derived from animal research, 1,034 more that cannot be verified at all, and 31 point pages that forbade the condition they treated ( acuiq.com/research/nothing-ever-fails (https://acuiq.com/research/nothing-ever-fails) ). An index and an RSS feed are published at acuiq.com/research (https://acuiq.com/research) . This dataset-first posture – treating the corpus itself as the object of study rather than only as a lookup table – is what places the project in the decentralised science (/contents/tech/core-concepts/decentralized-science-desci) category rather than the consumer-health one. Relationship to Radix AcuiQ is listed in this directory as a project of a Radix-ecosystem team, not as a deployed Radix application. The finding is unchanged on a re-check of 30 August 2026: it runs entirely on conventional web infrastructure, there is no Radix component, no token and no wallet integration, and the words Radix, blockchain, wallet and crypto do not appear on either the home page or the About page. Its only machine-facing payment path is a Stripe checkout link returned by an agent tool, which the project is explicit is opened by a human. The structural affinity is with the category rather than the current build. An anonymous, non-custodial health-knowledge service maps onto Radix's asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) model in the same way other DeSci (/contents/tech/core-concepts/decentralized-science-desci) datasets do – attestation of a curated corpus, community curation of contributions, and access tiers expressed as badges (/contents/tech/core-concepts/badges) rather than accounts. None of that is built; it is noted here to explain the listing, not to describe shipped functionality. Agent surface Since the July 2026 entry above, AcuiQ has published a machine-facing layer alongside the human site, and it is the part of the project most likely to interest a Radix developer. The pattern is the one this wiki documents under AI agents (/developers/ai-agents/radix-context) : a discovery document, a spec-correct Model Context Protocol (/developers/ai-agents/ai-agents-and-x402) server, and a parallel machine-readable copy of every page. All of the endpoints below were probed on 30 August 2026 and returned 200. - MCP server – JSON-RPC 2.0 over streamable HTTP at acuiq.com/api/mcp (https://acuiq.com/api/mcp) , announcing itself as acuiq 1.1.0 on protocol version 2025-03-26, rate-limited to 200 requests per minute per IP and requiring no key. It exposes six tools: search_symptoms, search_protocols, get_meridians, get_symptom_detail, get_point and create_checkout. The first five are annotated read-only; the sixth returns a Stripe Checkout URL for a person to open, so the agent never handles payment data. - Discovery documents – an llms.txt (https://acuiq.com/llms.txt) index and a full-content llms-full.txt (https://acuiq.com/llms-full.txt) export, an A2A agent card (https://acuiq.com/.well-known/agent-card.json) , an OpenAPI 3.1 specification (https://acuiq.com/.well-known/openapi.json) and an MCP manifest (https://acuiq.com/.well-known/mcp.json) . - Markdown twins – every symptom and acupoint page serves the same data as markdown at /symptoms/{slug}.md and /points/{code}.md. - Image and data endpoints – the acupoint atlas is served as IIIF Image API 3 (https://iiif.io/api/image/3.0/) level-0 tiles, and an ISO/WFAS auricular code crosswalk is published as a standalone JSON file under CC BY 4.0 (https://acuiq.com/data/auricular-crosswalk-v1.json) . The licence is declared in the discovery document rather than left implicit: AcuiQ-authored content – the compilation, the prose, the research essays and the ear and scalp-line plates – is released under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) and may be ingested into retrieval and training corpora, with attribution at dataset level. The body diagrams are excluded from the grant, and the grant is stated to cover the compilation rather than the underlying findings, which remain the cited sources' claims. External Links - acuiq.com – live application (https://acuiq.com) - Browse all symptoms (A–Z) (https://acuiq.com/symptoms) - Explore meridians (https://acuiq.com/meridians) - Research index (https://acuiq.com/research) - About & Method – what the database holds, and how results rank (https://acuiq.com/about) - llms.txt – AI agent discovery document (https://acuiq.com/llms.txt) - OpenAPI 3.1 specification (https://acuiq.com/.well-known/openapi.json) - A2A agent card (https://acuiq.com/.well-known/agent-card.json) ## 3Syde URL: https://radix.wiki/ecosystem/3syde Updated: 2026-09-01 Summary: 3Syde is a decentralized platform designed to enhance the user experience and navigation within the Radix ecosystem. It provides a suite of tools and… Type Trading & social-trading toolkit Founded 2020 Native token $3SYDE (1B supply) Validator EDGE CLUB Status 🟠 Dormant (pre-launch) Docs GitBook (https://3syde.gitbook.io/3syde) X @3SydedApp (https://x.com/3SydedApp) 3Syde is a decentralized platform designed to enhance the user experience and navigation (https://3syde.gitbook.io/3syde) within the Radix ecosystem. It provides a suite of tools and features aimed at simplifying trading, social interaction, and asset management for users interacting with the Radix network. Status (August 2026): 3Syde remains pre-launch, and a re-check on 25 August 2026 found nothing that had moved since July. Its landing page (https://3syde.com) still answers 200 and still renders a "SOON" placeholder over the same feature copy, the platform has not moved beyond its Stokenet beta phases, and the public pre-sale date is still unannounced. Two further measurements date the quiet. The project's GitHub account, @3SydeApp (https://github.com/3SydeApp) , is live but holds no public repositories. The official Telegram group, t.me/ofc3syde (https://t.me/ofc3syde) , yields 261 retrievable messages spanning 10 October 2024 to 23 August 2026 and not one of them is an announcement from the team; the newest posts are Chinese-language data-broker spam from 23 August, left in place. The site, the token plan and the validator all still exist. What is missing is anyone shipping against them. Platform 3Syde's platform offers several key features (https://3syde.gitbook.io/3syde/overview/what-we-do) and services to enhance the user experience within the Radix ecosystem: Virtual Wallets Users can create and manage virtual wallets directly through the 3Syde platform, eliminating the need for separate wallet applications. These virtual wallets streamline crypto dealings and transactions across devices. Trade Bots 3Syde provides advanced trade bots to automate trading strategies and optimize outcomes: - Buy/Sell Bot: This intelligent bot automates the buying and selling of tokens based on predefined criteria set by the user. It also includes a liquidity pool feature for purchasing newly launched tokens. - Binguard Bot (Planned): 3Syde is developing a specialized bot called the Binguard Bot, aimed at providing advanced trading capabilities (details to be announced). Social Trading 3Syde facilitates social trading and community engagement through the following features (https://3syde.gitbook.io/3syde) : - Follow and Copy Trading: Users can mirror the trading strategies of successful traders on the platform, allowing beginners to learn from experienced traders and experienced traders to diversify their approaches. - Leaderboard: A real-time leaderboard ranks traders based on their performance, consistency, and profitability, helping users identify top traders easily[2]. - Community-Driven Portfolios: Users can participate in portfolios curated based on the collective insights and voting of the community, potentially increasing returns and mitigating risks through a diversified approach. Security 3Syde places a strong emphasis on security and privacy when it comes to managing users' cryptographic keys and digital assets. The platform employs several security measures (https://3syde.gitbook.io/3syde/overview/security) to ensure the safety of user funds: Mnemonic Phrase Generation Upon registration, 3Syde generates a mnemonic phrase (a sequence of words) for each user in a deterministic fashion. This mnemonic phrase serves as the source from which the user's private key is derived. Private Key Derivation Using the mnemonic phrase, 3Syde derives the user's private key, which is then used to generate a master key. Master Key Encryption The master key, central to the user's cryptographic activities, is encrypted using Advanced Encryption Standard (AES) technology. The master key is encrypted directly on the user's device using their password as a seed, providing robust protection against unauthorized access. Ed25519 Algorithm for Key Derivation From the encrypted master key, 3Syde employs the Ed25519 algorithm, known for its strong security and efficiency in generating digital signatures, to derive subsequent keys used for creating and managing the user's wallets. Ed25519 utilizes elliptic curve cryptography, optimizing the process of generating secure and fast signatures for transactions. Client-Side Cryptographic Operations Importantly, all cryptographic operations, from mnemonic phrase generation to key derivation, occur client-side on the user's device. No sensitive data, such as the mnemonic, private key, or master key, is ever transmitted or stored externally, ensuring maximum security and privacy of the user's digital assets. Roadmap 3Syde has outlined a roadmap for the development and release of its platform, with the initial focus being on beta testing phases: Version 0.5 (https://3syde.gitbook.io/3syde/roadmap/0.5-beta) (Stokenet Beta Testing) In this initial beta testing phase, a limited number of 10 beta testers will have access to the first usable version of the 3Syde platform. Key features (https://3syde.gitbook.io/3syde/roadmap) and goals for this version include: - Creating and testing virtual wallets - Testing the Buy/Sell Bot and a Trade Bot for real-time ecosystem trading - Testing real-time notification systems (e.g., notifications for bot activities) - Identifying and addressing bugs and inconsistencies in wallet creation, management, and recovery - Testing social trading features (public wallets, leaderboard, copy trading) - Testing the community ranking system for users to follow and copy Version 0.6 (https://3syde.gitbook.io/3syde/roadmap/0.6-beta) (Stokenet Beta Testing) Building upon the previous version, an additional 15 beta testers will be invited to join the testing phase for Version 0.6. This version will focus on bug fixes and improvements from Version 0.5, as well as introducing new features (https://3syde.gitbook.io/3syde/roadmap/0.6-beta) such as: - Community-driven portfolios - Group creation functionality - Rewards system (recognizing active community users with platform rewards and prominence) By conducting these beta testing phases, 3Syde aims to thoroughly test and refine its platform, identify and address potential issues, and gather user feedback before a wider public release. Tokenomics 3Syde has introduced its native $3SYDE token, with a total supply of 1 billion tokens. The token allocation and distribution (https://3syde.gitbook.io/3syde/governance/tokenomics) are as follows: - Pre-sale: 41% of the total supply (410 million tokens) - Token pool: 35% of the total supply (340 million tokens) - Team and Developers: 6% of the total supply (60 million tokens), with 60% of this reserve having a vesting period of 3 years - EDGE CLUB Holder Airdrop: 3% (30 million tokens) - Surprise airdrop: 1% (details to be announced on Discord) - Reward system (for bot users and community recognition): 5% of the total supply (50 million tokens) - year 1 - Token Staking Rewards: 5% of the total supply (50 million tokens) - year 1 - Marketing/Promotions: 4% of the total supply (40 million tokens) Liquidity To ensure community trust and transparency, 100% of the funds raised during the pre-sale will be added to liquidity (https://3syde.gitbook.io/3syde/governance/tokenomics/liquidity) , with $EDG Club holding all pre-sale investors' capital. Transparency 3Syde has implemented various measures (https://3syde.gitbook.io/3syde/governance/tokenomics/transparency) to promote transparency and utility for the $3SYDE token: - Token holders will have access to premium features of the 3Syde platform - Active users will receive periodic airdrops of the token as an incentive - A buyback system will use 80% of the fees collected from dApp usage to buy back tokens from the market - Token staking will be launched immediately, with 5% of the supply locked in, providing an incentive for pre-sale investors to hold their tokens[3] Pre-sale 3Syde has outlined details for the pre-sale (https://3syde.gitbook.io/3syde/governance/pre-sale) of the $3SYDE token, providing various options for potential investors to secure their spot in the initial investment round: - Pre-sale window: 24 hours - Date: To be announced (TBA) - Pre-sale spots: 300 - Minimum/Maximum bid range: 700-10,000 XRD per spot (maximum of 40,000 XRD for 4 spots) - Pre-sale price: 0.001372 XRD per $3SYDE - Launch price: 0.001607 XRD per $3SYDE - Minimum funds required for launch: 562,500 XRD (if not reached, pre-sale will extend for another 24 hours) Participation Options - Raffle via Staking - Spots Available: 5 - Requirements: Stake a minimum of 50,000 XRD on the EDGE CLUB validator (each 50,000 XRD grants one raffle entry) - Snapshot and Raffle Dates: June 4 (details TBA) - Raffle via $EDG Token - Spots Available: 46 (subject to increase) - Requirements: Send 50 million $EDG per entry to a designated account - Raffle Date: June 6 at 2 PM EST - Special Spot (Entity TBA) - Spots Available: 1 - Details to be announced - Special Spot (Entity TBA) - Spots Available: 1 - Details to be announced Governance While specific details about 3Syde's governance model are not provided in the available information, some insights can be gathered from the tokenomics and pre-sale sections: Decision Making Process - The allocation of tokens for the team and developers (6% of the total supply) suggests that this group plays a significant role in the decision-making process and governance of the project, at least initially. - The vesting period of 3 years for 60% of the team and developer tokens indicates a long-term commitment and incentive alignment with the success of the project. Community Involvement - The inclusion of community-driven portfolios as a planned feature highlights the intention to involve the community in decision-making processes related to portfolio curation and trading strategies. - The rewards system, which recognizes active community users and provides them with platform rewards and prominence, incentivizes community participation and engagement. - The surprise airdrop (1% of the total supply) and the allocation for token airdrops to active users suggest a mechanism to incentivize and reward community members. ## CaviarNine URL: https://radix.wiki/ecosystem/caviarnine Updated: 2026-09-01 Summary: On 19 August 2026 CaviarNine announced that it is winding down its products and leaving the Radix network. Co-founder Oliver Scott-Simons (Tronn) post… CaviarNine Type DeFi ecosystem & DEX suite on Radix (/contents/tech/releases/radix-mainnet-babylon) Status 🟢 Active — winding down on Radix, announced 19 August 2026 Products Aggregator (https://docs.caviarnine.com/products-floop/aggregator) , Shape Liquidity (https://docs.caviarnine.com/products-floop/shape-liquidity/overview) , Order Book, LSU Pool (https://docs.caviarnine.com/products-floop/lsu-pool/lsu-pool-overview) , HyperStake (https://docs.caviarnine.com/products-caviar/hyperstake) Tokens $FLOOP (governance) & $CAVIAR Founders Oliver Scott Simons (Tronn) & Chris Colman Entities CaviarNine Limited (https://docs.caviarnine.com/introduction/terms-and-conditions) (British Virgin Islands) and Caviar Labs (Singapore) Website caviarnine.com (https://www.caviarnine.com) · docs (https://docs.caviarnine.com) Social @caviarnine (https://x.com/caviarnine) · Telegram (https://t.me/caviarxrd) Departure from Radix (August 2026) On 19 August 2026 CaviarNine announced that it is winding down its products and leaving the Radix network. Co-founder Oliver Scott-Simons (Tronn) posted the announcement at 08:23 UTC in the main Radix Telegram channel (https://t.me/radix_dlt/998739) , dating it to the fifth birthday of $FLOOP — by CaviarNine's account the first utility token on Radix, minted two years before smart contracts existed on the network. A longer retrospective was published the same morning at medium.com/caviarnine (https://medium.com/caviarnine/caviarnine-our-story-299ff73c5ffa) . What happens to each product - The CaviarNine DEX moves to withdraw-only mode. Trading and new liquidity positions end on the site, the smart contracts remain on ledger, and liquidity providers are asked to plan on removing their positions. The change had not been made on the day of the announcement, and it had not been made twelve days later either: caviarnine.io (https://www.caviarnine.io) was serving the full trading interface on 19 August 2026 and again on 31 August 2026, measured in Twelve days on below. - Surge (/ecosystem/surge) unwinds in stages. A date is to be announced for the orderly closing of all open positions, after which unclaimed collateral is to be bridged to Ethereum and held for later claiming. - JustLock (https://www.justlock.io) is unaffected, because it runs entirely on ledger: locking and unlocking continue to work as they always have. No deadline was set on the day and no immediate action was required of users, but withdrawals will be needed over the coming months, with notice promised before each step and a pinned FAQ in the project's channel. "We are not switching the DEX off": a sunset page, not a switch-off (21 August 2026) Two days after the announcement, co-founder Oliver Scott-Simons (Tronn) corrected the reading many people were taking from it (https://t.me/caviarxrd/70246) , in CaviarNine's own Telegram channel at 12:41 UTC on 21 August 2026: "We are not switching the DEX off. The smart contracts stay live on ledger. What changes is our website: it will be replaced with a simple sunset page, no backend, supporting remove LP only." The distinction is the one this page's self-custody section measures at the ledger, stated by the operator in its own words. What is being retired is a front end, not a set of components (/contents/tech/core-concepts/components) : "anyone can build and run their own front end to any of the components, today or in a year. The contracts are there, the liquidity mechanics are there and nothing we do to our website affects that." Practically, that means existing liquidity stays callable and tradeable by anything that can address the components, while the operator's own site will only support removing positions. That is not hypothetical. Astrolescent (/ecosystem/astrolescent) 's Timan confirmed in the main Radix channel the same afternoon that "Astrolescent will also still consider those pools when offering trades" (https://t.me/radix_dlt/999003) — an aggregator routing through CaviarNine's pools keeps them reachable to traders after the site goes — while noting that adding liquidity will need a new interface: "People won't be able to add to the pools without a new UI. The rest should still work." The admin badges, and an open request The one thing a third-party front end does not inherit is configuration. Earlier the same day a community member asked CaviarNine to hand the admin badges of the live components (https://t.me/radix_dlt/998982) to the Radix Accountability Council (/ecosystem/radix-accountability-council) , arguing that the components, the liquidity and the track record are all still there and that the badges — which touch fees and configuration — should at least sit in trustworthy hands. The council has somewhere to put them: it already operates a multisig account (https://t.me/radix_dlt/998989) holding initial treasury badges, currently including the Consultations Master Badge. CaviarNine has not answered. Tronn treated it as a separate question from front ends "since badges touch fees and configuration", and said the team would "take it away and come back with a considered answer rather than a quick one". At the time of writing no handover has been announced or recorded on ledger. The self-custody claim, read on the ledger CaviarNine's assurance that "everything is self-custodial" is checkable rather than promised, and the ledger corroborates it. LSULP, the LSU Pool unit that Surge (/ecosystem/surge) and other protocols accept as collateral, was read live at epoch 336,318 on 19 August 2026: total supply 267,774,125.70, with freezer and recaller both set to deny_all and mint and burn gated behind a component badge — and every one of those rules immutable. A departing operator has no lever over the balances users hold: it cannot freeze, recall or unilaterally reissue the pool unit, and the pool's contracts stay callable on ledger whatever the front end does. The unwind is visible at the ledger before it is visible on the front end. Re-read twelve hours after the announcement, at epoch 336,462 (19 August 2026, 23:08 UTC), LSULP's total supply had fallen from 267,774,125.70 to 263,942,458.90 — 3,831,666.80 units redeemed, about 1.4%, in a single day — while caviarnine.io (https://www.caviarnine.io) still served the full trading interface, byte for byte the page it served that morning. The remaining supply is concentrated: Weft Finance (/ecosystem/weft-finance) holds 62,410,923.97 LSULP across three components (23.6%), the RSwap (/ecosystem/rswap) LSULP/DCKS pool 17,293,134.15 (6.5%), CaviarNine's own HyperStake LSULP/XRD pool 9,783,770.32 (3.7%) and Stabilis (/ecosystem/stabilis) 1,053,413.26, out of 940 holders in all. Twelve days on: what actually changed (31 August 2026) The sunset page has not appeared. On 31 August 2026, twelve days after the announcement and ten after the correction that promised a front end "supporting remove LP only", caviarnine.io (https://www.caviarnine.io) was serving the complete application: a navigation bar of Trade, Earn, Tokens, Portfolio, Charts and Ignition, a trade card offering Swap, Limit and Liquidity with a live quote of 1 XRD to 0.00084051 hUSDC, a cross-chain swap entry labelled NEW, and no notice of the wind-down anywhere on the page. The Shape Liquidity page was still soliciting new positions in its own words: "Choose your pool below with the tokens you would like to be exposed to. If that pool of tokens doesn't exist you can create one." It is also still trading. The operator's own pool table listed 36 main pools holding $78,150 and carrying $144,759 of volume over the preceding seven days, led by XRD/hUSDC at $36,585, hWBTC/hUSDC at $35,374 and hETH/hUSDC at $25,469. Those are the site's own figures rather than a third party's, and they describe a venue in operation rather than one closing. What has moved is the liquidity. LSULP's total supply, read live at epoch 339,774 (31 August 2026, 11:06 UTC), stood at 235,758,772.06, against the 267,774,125.70 read at epoch 336,318 on the day of the announcement: 32,015,353.64 units redeemed in twelve days, 12.0%, or about one per cent of the pool a day, sustained. The front end is inviting deposits and the pool is draining at the same time, which is the practical shape of a wind-down announced but not yet carried out. The validators have not followed. At epoch 339,775 both CaviarNine validators were registered and charging a zero fee, with CaviarNine-2 at 115,634,605.92 XRD and CaviarNine-1 at 113,591,258.13. CaviarNine-2 had shed 4,022,122 XRD between 25 and 30 August; over the day to 31 August it gained 24,508 while CaviarNine-1 gave up 110,474, so the pair moved by less than a tenth of a per cent between them. The outflow that followed the announcement has stopped rather than accelerated: delegated stake is not leaving with the pool liquidity. Why, and the numbers behind it The stated reason is economic: CaviarNine says the economics of operating on Radix no longer work and that the network is far from what the team signed up for in the early years, and that it would rather wind down with notice than fade out quietly. The scale of the fall is measurable. DefiLlama (https://defillama.com/protocol/caviarnine) puts CaviarNine's total value locked at a peak of $42,087,970 on 9 April 2024 and at $452,231 on 19 August 2026 — a decline of about 99% over 28 months. What leaves with it is most of the network's on-chain trading. Over the 30 days to 19 August 2026, DefiLlama's Radix DEX aggregate (https://defillama.com/chain/radix) recorded $691,078 of volume, of which CaviarNine's Shape Liquidity accounted for $433,640 and its LSU Pool a further $43,874 — 69% of the network total before counting the CaviarNine Aggregator's $48,946. The venue announcing its exit is still the largest one on the network. Where the team goes CaviarNine is not dissolving. Its website at caviarnine.com (https://www.caviarnine.com) was rewritten as "A New Chapter" no later than 18 August 2026, the day before the announcement rather than the same day as it: the build served on 31 August 2026 came back from Vercel's London edge with an age of 1,144,107 seconds, which places the deployment that produced it at or before 05:20 UTC on 18 August. It describes a team that now builds Cantex (https://www.cantex.io) — a Canton-native AMM — and runs CaviarLabs (https://www.caviarlabs.io) as a Web3 software house. The roster that page printed on 31 August 2026 runs to eight items in four states: Cantex on the Canton Network; three Radix products carried as live, Surge (/ecosystem/surge) , JustLock (https://www.justlock.io) and the CaviarNine DEX itself; QubitSwap marked in development; and DSOR and Radit (/ecosystem/radit) marked decommissioned. A company that has said goodbye to Radix still lists three Radix products among the five it is not decommissioning. The announcement's closing line draws the distinction plainly: "This is goodbye to Radix, not CaviarNine." CaviarNine was the largest DeFi ecosystem on Radix by total value locked and by trading volume, and announced on 19 August 2026 that it is winding those products down and leaving the network — the terms and the timetable are set out in the section above. The product descriptions below describe the suite as operated up to that announcement. The CaviarNine suite of products is also referred to as the FLOOP DeFi Ecosystem (https://blog.caviarnine.com/floop-tokenomics-part-1-72e2a4c1fc62) after its native $FLOOP token. Background The platform is owned and operated by CaviarNine Limited BVI (https://docs.caviarnine.com/introduction/terms-and-conditions) , a company incorporated in the British Virgin Islands. The CaviarNine ecosystem includes various services, such as The Aggregator and liquidity provisioning tools, developed by Caviar Labs (https://docs.caviarnine.com/introduction/terms-and-conditions) , a Singapore registered software development house and subsidiary of Invariance Pte Limited (https://www.linkedin.com/company/invarianceptelimited/about/) . Products Aggregator The Aggregator (https://docs.caviarnine.com/products-floop/aggregator) is a unified front-end gateway to all liquidity on the Radix network. Initially known as DSOR (https://DSOR.io) (Decentralised Smart Order Router), it has been revamped and rebranded under the CaviarNine umbrella. The Aggregator's primary function is to ensure traders get the best possible price by aggregating liquidity from various sources. It searches all known DeFi smart contracts for liquidity, ensuring users get the best trade across all liquidity sources on Radix. The Aggregator connects to DEXs, order books, token bridges, validators, and other liquidity sources, ensuring traders don't have to rely on a single DEX for the best price. Fee Structure A minimal fixed fee is charged by the Aggregator, which is waived when routing to any CaviarNine liquidity. All fees accrued are directed to the FLOOP Treasury, controlled by the FLOOP DAO. These fees can potentially be converted into $FLOOP and either burned or used for long-term liquidity rewards. Index Pools Index Pools are multi-token pools that allow for bespoke liquidity provision (https://blog.caviarnine.com/product-preview-index-pools-e126966e3dfd) , each characterized by different constituents, weights, and risk profiles. Pools can comprise between 2 and 9 distinct tokens. Fee Structure Index Pools incorporate a minor fixed fee component along with a dynamic liquidity fee meaning that in volatile market scenarios, liquidity providers receive increased fees as a buffer against impermanent loss. Liquidity providers (LPs) receive a portion of the liquidity fee proceeds. As per FLOOP Tokenomics part 1, the fixed fees are directed to the FLOOP Treasury, which is overseen by the FLOOP DAO. These fees might be converted into FLOOP and either burned or allocated for extended liquidity rewards. Order Book Order Book is low-fee market and limit order system, which stands as an alternative to CaviarNine’s standard Automated Market Maker (AMMs). The Order Book also provides options for immediate execution or cancelation on partial fills. While Order Books allow traders to specify exact prices for transactions, they don't guarantee order fulfillment. AMMs, on the other hand, guarantee trade execution but can vary in price based on pool liquidity and trade size. Fee Structure A nominal fee is charged by the Order Book and directed to the FLOOP Treasury, which is overseen by the FLOOP DAO. Shape Liquidity Shape Liquidity (https://docs.caviarnine.com/products-floop/shape-liquidity/overview) is an Automatic Market Maker (AMM) that allows liquidity providers (LPs) to focus their positions on active trading zones within specific price ranges, using a variety of concentrations. This is more capital efficient and enables LPs to generate higher fees from their available capital. Shape Liquidity provides various shapes for liquidity concentration, such as: - Constant Height Range: Maintains a steady concentration of liquidity over the desired price range. - Center-Peaked Curve: Liquidity peaks at the center of the range and tapers off towards the edges. - Bar-Bell Shape: Ideal for providers who anticipate significant trading activity around two specific regions. Fee Structure Shape Liquidity features both a fixed fee and a dynamic liquidity fee that auto-compounds to the underlying position, acting as a cushion against impermanent loss. Liquidity providers share the proceeds of the liquidity fee, while fixed fees are sent to the FLOOP Treasury. LSU Pool The LSU Pool (https://docs.caviarnine.com/products-floop/lsu-pool/lsu-pool-overview) is a multi-token pool for Radix’s Liquid Staking Units (LSUs) that represent shares of the staking pool. Each LSU is associated with specific validators, who may offer bespoke rewards for staking with them. The LSU Pool offers multiple ways for users to utilize their LSU tokens, such as moving between validators, facilitating Instant Unstaking, and providing additional yield to LSU Pool liquidity providers. Instant XRD Unstaking (https://docs.caviarnine.com/instant-xrd-unstaking/overview) allows users to send an LSU and receive XRD instantly, albeit at a slightly reduced amount compared to waiting the standard 7-day unstaking period. This feature provides flexibility and immediate liquidity to users. Fee Structure In line with FLOOP Tokenomics part 1, fixed fees are directed to the FLOOP Treasury, controlled by the FLOOP DAO. Perpetual $XRD Perpetual XRD (pXRD), is a Market-Driven Liquid Staking Derivative on Radix. Initially set at a 1:1 ratio with XRD, pXRD's future price is determined by an on-chain oracle that takes into account the yields of active validators. This ensures that pXRD's growth rate is in line with the performance of top-tier validators. Users can deposit eligible collateral into a vault, and pXRD is automatically minted against it. They can receive up to 95% of the value of their collateral as pXRD. The system offers high leverage opportunities due to the low volatility of pXRD and its eligible collateral. If the eligible collateral drops below a certain threshold (e.g., 102% of the pXRD value), liquidation occurs. Anyone can claim the collateral by supplying pXRD and earn the difference. The main types of collateral include XRD (Radix's native token), LSUs (any validator token), LSU-NFTs (claim token receipts obtained after unstaking from a validator), and LSU-LP (Liquidity Pool tokens from CaviarNine's LSU Pool). The consistent increase in Perpetual XRD's price offers a systematic, yield-based valuation process, eliminating sudden price-driven liquidations. Users can earn above-average yields, unlock the potential of their XRD, and benefit from a staked XRD derivative designed for DeFi protocols. The system also offers arbitrage opportunities and charges a nominal protocol fee. Perpetual XRD is perfect for those seeking stable growth, risk managers, and yield hunters. Fee Structure Similar to FLOOP Tokenomics part 1, the protocol fees are directed to the CAVIAR Treasury, which is overseen by the CAVIAR DAO. Radit Radit.io (https://www.radit.io) was an on-chain messaging service but has been discontinued. Team The CaviarNine team (https://web.archive.org/web/20260514230817/https://docs.caviarnine.com/introduction/team) is diverse and spread across Thailand, Singapore, Canada, and Australia, with its headquarters in Bangkok. The founders, Oliver Scott Simons (https://web.archive.org/web/20260514230817/https://docs.caviarnine.com/introduction/team) (aka Tronn) and Chris Colman, have extensive backgrounds in finance and technology. Their mission is to provide users with seamless access to professional-grade innovative DeFi products and unlock the full potential of DeFi. The docs team page these facts come from was removed from docs.caviarnine.com (https://docs.caviarnine.com) at some point before 31 August 2026, and the links above resolve to its last capture, taken 14 May 2026. Tokens CaviarNine has introduced two primary tokens: $FLOOP and $CAVIAR (https://docs.caviarnine.com/tokens/overview) . These tokens are associated with the platform's DeFi products and serve as utility and DAO tokens. They were minted prior to the Babylon upgrade and the start of dApps on Radix. Holders of these legacy tokens can bridge them to the Babylon (https://blog.caviarnine.com/floop-tokenomics-part-1-72e2a4c1fc62) versions that power CaviarNine's products. Floop ($FLOOP) Babylon $FLOOP tokens (https://blog.caviarnine.com/floop-tokenomics-part-2-effbfc3fb3bd) will power the expanding ecosystem and serve as governance tokens for the nascent FLOOP DAO. Users will have the option to transition their existing Olympia $FLOOP into Babylon FLOOP via a one-way bridge. Distribution Around 55% of the original $FLOOP tokens were distributed via airdrops. Following the Babylon upgrade, the distribution of the original $FLOOP tokens is anticipated as follows: - Core Team: 200 FLOOP (20%) - Company Reserve: 200 FLOOP (20%) - Airdrops to LPs active within the FLOOP ecosystem (5%) Caviar ($CAVIAR) Babylon $CAVIAR, akin to $FLOOP, will be a newly bridged token that will power future DeFi structured products that CaviarNine intends to develop. FLOOP DAO The FLOOP Decentralized Autonomous Organization (DAO) is the cornerstone of the vision for a decentralized and community-driven ecosystem. Babylon $FLOOP tokens will be the backbone of the DAO, enabling decentralized decision-making that shapes the ecosystem's direction. Recent Developments (2025–2026) HyperStake HyperStake (https://docs.caviarnine.com/products-caviar/hyperstake) is an automated LSULP/XRD concentrated liquidity pool that generates yield from three sources: instant unstakers who pay premiums to bypass the standard 7-day unstaking period, 7-day depositors, and traders swapping between the two assets. The pool is configured at -1.5% to 0% of the NAV price of LSULP to XRD, concentrating capital in the most active trading zone. It features auto-rebalancing – the pool automatically adjusts its liquidity range based on market conditions – and a no-loss guarantee that protects deposited principal even in volatile conditions. Fee distribution is 80% to liquidity providers, 10% to CAVIAR token supply reduction via fee vaults, and 10% to treasury reserves. THORSwap Integration & Cross-Chain Swaps CaviarNine is one of 11 decentralized exchanges integrated with THORSwap (https://www.radixdlt.com/blog/thorswap-integrates-radix) , unlocking cross-chain swaps between Radix and over 27 assets across six blockchains including Bitcoin and Ethereum. This integration enables anyone outside the Radix ecosystem to swap directly into Radix-native tokens such as $HUG, $EARLY, $CAVIAR, and $OCI via liquidity on CaviarNine, with THORSwap supporting 788+ tokens. Radix Rewards Campaign CaviarNine is a key participant in the Radix Rewards campaign (https://www.radixdlt.com/blog/how-to-provide-liquidity-on-caviarnine-to-earn-points-in-the-radix-rewards-campaign) , a 1 billion XRD incentive programme designed to reward genuine DeFi participation with anti-Sybil mechanisms. Liquidity providers on CaviarNine earn Activity Points proportional to their position size and duration, which convert weekly into Season Points with multipliers (0.5x to 3x) based on XRD/LSU holdings. CaviarNine offers exclusive opportunities unavailable on other DEXs, including LSULP and HyperStaking pools. SuperStaking CaviarNine launched a $14 million liquidity staking initiative (https://www.radixdlt.com/blog/introducing-superstaking-14m-liquidity-staking-initiative) called SuperStaking, further cementing its position as the primary liquid staking infrastructure on Radix. External Links - CaviarNine (https://www.caviarnine.com) – Official website - Documentation (https://docs.caviarnine.com) - @CaviarNine on X (https://x.com/caviarnine) - Telegram (https://t.me/caviarxrd) - CaviarNine HyperStake on DefiLlama (https://defillama.com/protocol/caviarnine-hyperstake) ## Partnerships URL: https://radix.wiki/contents/history/partnerships Updated: 2026-09-01 Summary: This page archives the Radix Foundation 's partnership announcements from the pre-mainnet and Olympia eras (2020–2022). The list is preserved here for… Topic Ecosystem partnerships Period 2020–2022 Era Pre-mainnet & Olympia (/contents/tech/releases/radix-mainnet-olympia) Parent article History of Radix (/contents/history) This page archives the Radix Foundation (/ecosystem/radix-foundation) 's partnership announcements from the pre-mainnet and Olympia (/contents/tech/releases/radix-mainnet-olympia) eras (2020–2022). The list is preserved here for historical reference. 2022 Partner(s) Announcement 2022/03/25 Staking Rewards (https://www.stakingrewards.com/) 🔗 (https://www.radixdlt.com/blog/staking-rewards-x-radix) 2021 2021/02/11 GoodFi (https://www.radixdlt.com/blog/radix-launches-goodfi-alliance-with-chainlink-aave-messari-mstable-more) 🔗 (https://www.radixdlt.com/blog/radix-launches-goodfi-alliance-with-chainlink-aave-messari-mstable-more) 2020 2020/10/19 Quantstamp (https://quantstamp.com/) 🔗 (https://www.radixdlt.com/blog/radix-quantstamp-partner) 2020/08/26 Argent (https://www.argent.xyz/) 🔗 (https://web.archive.org/web/20251008090415/https://www.radixdlt.com/blog/radix-partners-with-argent-the-worlds-easiest-to-use-defi-wallet) 2020/08/24 Object Computing (https://objectcomputing.com/) , Noether 🔗 (https://www.radixdlt.com/blog/object-computing-and-noether-dlt-develop-ethereum-based-smart-contract-platform-for-the-radix-ledger) 2020/08/18 Ren Protocol 🔗 (https://www.radixdlt.com/blog/radix-partners-with-ren-protocol-to-bring-fully-decentralized-wrapping-to-the-radix-defi-ecosystem) 2020/08/05 Copper (https://copper.co/) 🔗 (https://www.radixdlt.com/blog/radix-and-copper-bring-a-tokenized-world-to-the-radix-network) 2020/07/15 ExpoLab (https://expolab.org/) 🔗 (https://www.radixdlt.com/blog/expolab-partners-with-radix-to-develop-fast-and-secure-financial-blockchain-system) After 2022 The cadence of headline partnership announcements above belongs to Radix’s pre-mainnet and Olympia (/contents/tech/releases/radix-mainnet-olympia) years. Following the Babylon (/contents/tech/releases/radix-mainnet-babylon) upgrade, ecosystem growth has been tracked project-by-project rather than through Foundation press releases; the current live projects are catalogued in the Radix ecosystem directory (/ecosystem) . On 28 April 2026 the Radix Foundation (/ecosystem/radix-foundation) announced it was moving to a maintenance-only posture (https://www.radixdlt.com/blog/foundation-update-moving-to-maintenance-mode) – pre-funding critical infrastructure through 2026 while handing operational responsibility to the community and a new DAO entity, formally closing the era of Foundation-led partnership announcements archived on this page. Where the partners are now An archive of announcements is only as useful as the reader’s ability to tell which of the parties still exists. Every domain this page links was read on 29 August 2026. Five answer normally under the same name: Quantstamp (https://quantstamp.com) , Object Computing (https://objectcomputing.com) , Copper (https://copper.co) – which also appears in this wiki’s record of the Radix Endowment Fund (/contents/history/radix-ecosystem-funding) – the ExpoLab (https://expolab.org) research group, and Staking Rewards (https://www.stakingrewards.com) . Two do not. Argent, the wallet named in the August 2020 announcement, no longer answers under that name: www.argent.xyz returns an HTTP 301 to ready.co, and so does its blog path, so the link in the table above lands on a differently-named product. Ren Protocol is the one entry on this page with no link at all, and that is now the accurate state of it: renproject.io still resolves in DNS – to 162.255.119.181, on registrar nameservers – but returns nothing at all over HTTP, timing out twice at thirty seconds. A domain that resolves without answering is parked rather than served. Neither is a dead link on this page, and neither changes what was announced at the time. They are recorded here because a partnership archive that quietly implies all its counterparties are still trading is misleading in a way no link checker will catch. ## Blockchain Trilemma URL: https://radix.wiki/contents/tech/core-concepts/blockchain-trilemma Updated: 2026-08-31 Summary: The blockchain trilemma , popularized by Ethereum 's Vitalik Buterin, states that a blockchain can only optimize for two of three properties: scalabil… Category Theoretical Concept Coined By Vitalik Buterin Radix Solution Cerberus Consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) Overview The blockchain trilemma, popularized by Ethereum (https://ethereum.org) 's Vitalik Buterin, states that a blockchain can only optimize for two of three properties: scalability, security, and decentralization. Most chains make explicit tradeoffs: Ethereum prioritizes security and decentralization (low throughput). Solana (https://solana.com) prioritizes scalability and security (high hardware requirements reduce decentralization). Rollups prioritize scalability and decentralization (sequencer centralization challenges). Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) 's Approach, and what has actually been tested Radix's Cerberus consensus (/contents/tech/core-protocols/cerberus-consensus-protocol) argues the trilemma is a limitation of specific consensus designs rather than a fundamental law. The Cerberus whitepaper (https://arxiv.org/pdf/2008.04450) proposes to get there by braiding consensus across shards, so that a transaction involves only the shards it touches, which would give: - Scalability – throughput scaling with shard count rather than with per-node capacity - Security – full BFT (https://en.wikipedia.org/wiki/Byzantine_fault) security per shard, with braiding supplying the cross-shard guarantee - Decentralization – commodity hardware nodes, with capacity added by adding nodes That is a design, not a deployment. Braiding has never run in production: not on Radix Babylon (/contents/tech/releases/radix-mainnet-babylon) , which runs Cerberus unsharded and so has nothing to braid, and not in the Radix Foundation's Hyperscale reference implementation either. The trilemma claim above should therefore be read as the protocol's argument rather than as a demonstrated result. The Hyperscale 500k TPS test (/contents/tech/research/hyperscale-500k-tps) is frequently offered as that demonstration, and it is not one. It sustained over 500,000 TPS and peaked above 700,000 on commodity AWS instances (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) , with more than 590 community nodes in the public phase, but what it measured was the Foundation's Hyperscale implementation, which the lead developer of the Xi'an production candidate (/contents/tech/research/hyperscale-rs) states "never really used Cerberus" (https://t.me/hyperscale_rs) . The figures are a property of the software that was tested, not evidence about the protocol specified in the whitepaper. A sharded network that answers the trilemma on Radix is still forthcoming work, and the current candidate is hyperscale-rs (/contents/tech/research/hyperscale-rs) , whose per-shard consensus is HotStuff-2 derived rather than Cerberus. ## Recycled Telegram Handles URL: https://radix.wiki/contents/resources/recycled-telegram-handles Updated: 2026-08-30 Summary: A recycled Telegram handle is a username that once belonged to a project's own channel and has since been re-registered by someone else. The handle su… Recycled Telegram Handles Type Reader advisory Affects Telegram handles previously used by Radix ecosystem projects Handles observed 11, swept 1, 20 and 30 August 2026 Signature A near-empty channel, no description, a single Collab.Land-branded token-gate post Lure "Click below to verify your wallet and gain access" Legitimate Collab.Land bot @collablandbot (https://t.me/collablandbot) – and only that handle (https://docs.collab.land/help-docs/FAQ/join-tg-group/) On-ledger handles swept 12, from the metadata of the 72 tokens cited on the ecosystem directory (/ecosystem) – 1 recycled, 1 unregistered Observed 1, 20 and 30 August 2026 A recycled Telegram handle is a username that once belonged to a project's own channel and has since been re-registered by someone else. The handle survives the project; every link that ever pointed at it – wiki entries, old tweets, exchange listings, documentation, search results – now points at whoever holds it today. For a Radix ecosystem that has accumulated several years of wound-down projects, that makes abandoned handles a standing supply of pre-trusted traffic. On 1 August 2026 a sweep of every Telegram handle cited under this wiki's ecosystem directory (/ecosystem) found nine that no longer belong to the projects named beside them. All nine share one signature: a channel with a single subscriber, no description, and exactly two posts – the automatic "Channel created" notice, and a message styled as a Collab.Land (https://collab.land) token gate reading "This community is now protected by Collab.Land … Click below to verify your wallet and gain access." The button beneath it leads to a bot whose name imitates Collab.Land's without matching it. This page records what was observed, so that the citations elsewhere on the wiki can be read for what they are: dead handles, not project channels. It is not an allegation about any of the projects listed – in most cases the project simply ended, and the handle outlived it. The handles observed Creation timestamps and subscriber counts below were read from each channel's public t.me/s/ preview on 1 August 2026. Seven of the nine channels were created inside a thirty-second window on 29 June 2026 – the fingerprint of one batch registration rather than nine unrelated events. Handle Project it is cited for Channel created (UTC) "Verify" button target @RadLandNFT VikingLand (/ecosystem/vikingland) 29 Jun 2026, 20:06:08 @CollabLandlBot @phoenix_xrd Phoenix (/ecosystem/phoenix) 29 Jun 2026, 20:06:16 @CollabLandlBot @backeum_news Backeum (/ecosystem/backeum) 29 Jun 2026, 20:06:17 @CollabLandlBot @hardmoneyproject The Hard Money Project (/ecosystem/the-hard-money-project) 29 Jun 2026, 20:06:17 @CollabLandlBot @juicystake Juicy Stake (/ecosystem/juicy-stake) 29 Jun 2026, 20:06:18 @CollabLandlBot @stabilislabs Stabilis (/ecosystem/stabilis) 29 Jun 2026, 20:06:26 @CollabLandlBot @Impahla Impahla (/ecosystem/impahla) 29 Jun 2026, 20:06:38 @CollabLandlBot @fibonaccifi Fibonacci Finance (/ecosystem/fibonacci-finance) 19 Mar 2026, 10:26:06 @collab_land_accessbot @Radixnode RadixNode.io (/ecosystem/radixnodeio) 30 Jul 2026, 03:13:02 @coIIab_Iands_bot Every one of these projects is recorded on this wiki as closed, dormant, or long inactive, or was found in this sweep to be operating far below the scale its page implied. That is the population being farmed: handles whose owners are no longer around to reclaim them, attached to pages that readers still arrive at. A tenth handle, and a live one: 18 August 2026 The nine handles above were swept on 1 August 2026. The same sweep was re-run on 20 August 2026 across every Telegram handle cited on the 146 pages of the ecosystem directory (/ecosystem) — 56 distinct handles, all of which resolved. The original nine had been corrected on their pages. One new handle matched the signature: @FotonMarketplace, cited for Foton (/ecosystem/foton) . It fits the pattern exactly, and dates itself precisely. The channel was created on 18 August 2026 at 07:11:55 UTC. Ten seconds later, at 07:12:05, it posted the Collab.Land token gate. It has one subscriber, no description, and no other posts. The verify button leads to @Collabslands_bot — a fourth spelling of the imitation, and the first that does not play on letterforms at all. It simply pluralises the brand, which reads as a typo rather than a substitution. Two things separate this case from the other nine. The first is that Foton had not been written off: it was listed on this wiki as operational until this handle was found, and the finding is part of why that page (/ecosystem/foton) now reads dormant. A recycled handle is evidence about a project as well as a hazard beside it — a team still answering for its work notices when its channel changes hands, and fixes the link. The second is that the project's own website still links the handle. foton.is has not been rebuilt since April 2023, and the Telegram link on it now delivers visitors straight to the gate. The other nine were reachable only through stale citations; this one is reachable through the front door. The practical consequence for reading this wiki is that a handle checked clean is checked clean on a date. Three weeks separated the two sweeps, and one handle turned over inside them. An eleventh handle, published by the ledger: 30 August 2026 The sweep was re-run on 30 August 2026 across every Telegram handle cited on the 148 pages of the ecosystem directory (/ecosystem) – 62 distinct handles, six more than the August sweep found, all of which resolved. One matched the signature, and it reaches the reader by a route none of the first ten used. @DELIVER_XRD is cited for DELIVER (/ecosystem/deliver) , a meme token whose trading moved on and whose own website has gone. The channel now answering at that handle was created on 1 June 2026 at 00:09:52 UTC and posted the Collab.Land token gate four seconds later, at 00:09:56. It has four subscribers, one photo, no description and exactly two posts, the “Channel created” notice and the gate. The verify button leads to @collabland_access_bot, a fifth spelling of the imitation and the most plausible-looking yet: it is the real brand, an underscore, and a word Collab.Land does not use. What is different is where the citation comes from. The first nine were reached through stale links on this wiki, the tenth through the project’s own abandoned website; this one is published on the ledger. The DELIVER token’s own metadata carries social_urls = ["https://t.me/DELIVER_XRD", "https://x.com/DELIVER_XRD"], read at mainnet epoch 339,487 on 30 August 2026. The token was created on 29 January 2025, sixteen months before the channel that now answers there, so the metadata is original and the channel behind it is not. This wiki cites the handle because the ledger does, and so will any wallet, explorer or token aggregator that renders a resource’s socials. That record is correctable, and not by this wiki. The token’s supply is sealed – burner, minter, freezer and recaller, and every one of their updaters, are DenyAll – but its metadata is not: metadata_setter resolves to Owner, and the owner badge {eb1f07d8…} of resource_rdx1ng362xkr… is unburned and sits in account_rdx128jcfayxelltc45l7u676pxxr8hhdx8wlkmme93fea47jeg4ep592w, where it has not moved since 20 December 2025. One metadata update from that account would repoint the record. Nothing prevents it except that nobody is watching. The 20 August sweep did not miss this handle. It was not cited then: it entered this wiki at 22:11 UTC on 20 August, hours after that day’s sweep ran, in the revision that read the token’s on-ledger facts and copied its socials across. A sweep covers the citations that exist while it runs, and a page that gains a citation afterwards inherits none of its assurance. The handles the ledger publishes: 30 August 2026 Every sweep above began with a citation on this wiki. That is the wrong starting point for a handle a token carries in its own metadata, because the wallet, the explorer and the aggregator will render it whether or not any wiki ever cited it. So the sweep was run again from the ledger instead. The 148 pages of the ecosystem directory (/ecosystem) name 72 distinct resource addresses; all 72 were read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) on 30 August 2026, and twelve of them publish a Telegram handle in social_urls or telegram_profile_url. Each of the twelve was then resolved against Telegram itself rather than read off a web page. Handle in the token’s metadata Token What answers Created @defiplaza DFP2 Group, “DefiPlaza: Turning IL into Profit” 10 May 2021 @xrdSingularityX SINX Group, “Space Cafe (SINX)” 25 Aug 2022 @astrolescent_official ASTRL Group, “Astrolescent Official” 30 Sep 2023 @chugchugchugchug ANTH Group, “CHUG” 6 Feb 2024 @WeAreMonstas MXRD Group, “WeAreMonstas” 21 Mar 2024 @addixanonymous HIT Group, “$HIT Zone” 22 Mar 2024 @radixreview RR Channel, “RADIX REVIEW” 4 Oct 2024 @HugZone HUG Group, “Hug Zone” 9 May 2025 @hydraxrd HYDR Group, “HYDRA” 7 Feb 2026 @ascent_xrd ASCENT Group, “Ascent” 4 Jun 2026 @DELIVER_XRD DELIVER Recycled – channel “deliver_xrd”, four subscribers, Collab.Land gate 1 Jun 2026 @WhyNotXRD WHY Held by nobody – USERNAME_NOT_OCCUPIED – Ten of the twelve are what the page beside them says they are. The eleventh is the recycled channel recorded above (/ecosystem/deliver) . The twelfth is a state this advisory had not seen before, and it is the one worth naming: WhyNot (/ecosystem/whynot) ’s $WHY token publishes https://t.me/WhyNotXRD in two metadata fields, the project’s Linktree publishes it too, and Telegram reports the username as unregistered. It is not a dead channel. It is an empty slot, and it is the precondition for every other row in the tables above: the recycled handles were all in this state first, for as long as it took someone to notice. The creation dates are the reason the resolution has to be done at Telegram rather than at a web page. A channel that answers at the right handle can still be younger than the token that cites it, and only the creation date shows it: @DELIVER_XRD answers, looks ordinary from a link, and postdates the token’s metadata by sixteen months. Two of the twelve are legitimately recent for the same reason and are not suspect at all – @hydraxrd and @ascent_xrd belong to projects that started in 2026. A date does not decide the question; it is what makes the question askable. Telling the real Collab.Land bot from a fake Collab.Land is a real and widely used token-gating service, which is exactly why it is worth imitating. Its documentation is unambiguous about the only handle that is genuinely theirs: "The true Collab.Land bot is named @collablandbot … Make sure you are interacting with the correct bot @collablandbot. There are many imposters with similar names." (https://docs.collab.land/help-docs/FAQ/join-tg-group/) The imitations found across the three sweeps work by substituting or adding a character that is hard to see in a sans-serif font, or by simply reading as plausible: - @CollabLandlBot – an extra l before "Bot" (seven of the nine channels). - @collab_land_accessbot – a plausible-sounding suffix that Collab.Land does not use. - @coIIab_Iands_bot – capital I standing in for lowercase l, three times over. - @Collabslands_bot – the brand pluralised, which reads as a typo rather than a substitution. - @collabland_access_bot – the brand spelled correctly, with a suffix Collab.Land does not use. The last is the classic form of the attack: in most interface fonts a capital I and a lowercase l are the same vertical stroke. Collab.Land publishes security guidance (https://collab.land/security) on this and accepts reports of impersonating bots (https://dev.collab.land/help-docs/FAQ/report-scams/) . What a reader should do - Never connect or "verify" a wallet from an unsolicited token gate. A verification prompt is only meaningful if you went looking for the community first – a gate that greets you in an empty channel is the whole attack, not a step in it. - Read the channel, not the handle. One subscriber, no description, a creation date measured in weeks, and a single pinned prompt are all visible before you click anything. A real project channel has history. - Get handles from the project's own site, or from a source you can date. A Telegram link in an article from 2023 says only where the project was in 2023. - Compare the bot handle character by character against @collablandbot (https://t.me/collablandbot) . Copy it into a monospaced field if the letters look alike. - Nothing legitimate needs your seed phrase, and very little needs a signature to prove you hold a token. Treat any signing request from a verification flow as the point to stop. - Check whether the project is still running at all. A handle is most worth doubting when it belongs to a project that has stopped, and the ecosystem operational status index (/contents/resources/radix-ecosystem-operational-status) lists which Radix projects are operating, dormant or closed. The same reasoning applies to domains as well as handles. A wound-down project's website can be re-registered exactly as its Telegram handle can – the Instabridge (/ecosystem/instabridge) domain now redirects to rotating gambling pages, and this wiki's guide to buying XRD (/contents/resources/how-to-buy-xrd) was itself routing readers through it until 1 August 2026. An old link is a claim about the past, not the present. External Links - Collab.Land – Joining a Telegram Token Permission Group (https://docs.collab.land/help-docs/FAQ/join-tg-group/) (names @collablandbot as the only legitimate bot) - Collab.Land – Security (https://collab.land/security) - Collab.Land – Report Scams (https://dev.collab.land/help-docs/FAQ/report-scams/) - @collablandbot on Telegram (https://t.me/collablandbot) - Radix ecosystem directory (/ecosystem) – where the affected citations were found ## Radit URL: https://radix.wiki/ecosystem/radit Updated: 2026-08-29 Summary: Radit.io was a community-owned investment message board that operated on the Radix network. It presented a unique concept where users can invest in me… Radit.io was a community-owned investment message board that operated on the Radix network. It presented a unique concept where users can invest in messages and earn a yield based on their investments. The platform was known as the first community-owned investable message board powered by Radix. It was created by CaviarLabs (/ecosystem/caviarnine) , a technology company focused on blockchain and decentralized finance (DeFi) solutions. https://youtu.be/3DDR41WD7p4 (https://youtu.be/3DDR41WD7p4) Operation Users on Radit.io can post new messages by sending them to a special gazette wallet along with any amount of Radix tokens ($XRD). The posted messages were owned, similar to how a Non-Fungible Token (NFT) is owned. When other users invested in these messages by sending $XRD, the original poster earned a yield. Every message investment gave the investor some ownership of that message, and they can earn $XRD whenever anyone else invested in a message they own a part of. As of mid-2023, Radit.io (https://www.radit.io) had seen an investment of 5249K $XRD, with 24,513 messages posted by 1,095 unique users. Governance Radit.io also had its own governance token, $RADIT. Owners of $RADIT tokens possessed 30% ownership of every message posted on the platform and had a say in the future of Radit.io. The platform ensured that 100% of $XRD sent to Radit.io were distributed back as rewards at the end of each day, emphasizing its commitment to community ownership and participation. Notable Features One of the unique features of Radit.io was the concept of "100k XRD Message". When any message on the platform reached an investment of 100k XRD, a message token got minted on the Radix network. This newly minted token would have a supply of 100k units, which were distributed to the message owners proportionally to their percentage ownership at the point the message was worth 100k XRD. The token included all the details of the original message and was immortalised onto the Radix Ledger. Status today Radit closed as an Olympia (/contents/tech/releases/radix-mainnet-olympia) -era product and never reopened on Babylon (/contents/tech/releases/radix-mainnet-babylon) , but the domain did not go dark. Read on 29 August 2026, radit.io answers HTTP 200 – hosted on Vercel and redirecting to www.radit.io – and serves a single farewell card: “Bye bye, hope to see you after Babylon!”, followed by “Something interesting is going on over there, tho? 👀” and one link, to CaviarNine (/ecosystem/caviarnine) . The board handed its visitors to the team’s surviving project rather than expiring into a parked-domain lander, which is the more common end for a retired Radix front-end. The consequence is that the $RADIT token still resolves properly everywhere it appears. The resource (https://dashboard.radixdlt.com/resource/resource_rdx1th7jrjlpfz5dxtpa6v2thsxarqa5mgygcqm8qgm37ntyy6dj7l7dxs) carries a fixed 100,000,000 supply, and its on-ledger metadata (/contents/tech/core-concepts/metadata-module) still points at a live host on both counts: info_url at radit.io and icon_url at radit.io/radit32.png, which returns a 2,555-byte PNG. That is the opposite outcome to DeXter (/ecosystem/dexter) , whose token metadata points at an icon host and an IPFS gateway that have no DNS record left, so wallets render it broken. Whether a closed project’s token still looks like anything is decided by whether somebody kept one small web host alive. The token is also still traded. Ociswap, which listed RADIT on 6 October 2023 (https://ociswap.com/radit) , showed 148,279.64 XRD against 3,489,171.29 RADIT in liquidity on 29 August 2026 – roughly $130 – with 1,583 XRD of volume in the previous 24 hours and 4,114 XRD over the previous week, against a lifetime 3,107,062 XRD. Three and a half years after the board stopped taking messages, its governance token turns over a few thousand XRD a week. ## DeXter URL: https://radix.wiki/ecosystem/dexter Updated: 2026-08-29 Summary: DeXter (formerly ProjectX) was a community-built, decentralized order-book exchange on the Radix network – the first order-book DEX on Radix built ent… Type Order-book DEX Status 🔴 Closed – retired March 2026 Network Radix (Babylon) Token DEXTR (contributor / governance) – total supply 4,739,465.13 Launched 2023 (post-Babylon) Retired 8 March 2026 (https://t.me/dexter_discussion/27603) Website dexteronradix.com – offline; the domain now serves a parked-domain lander (checked 28 July 2026) GitHub DeXter-on-Radix (https://github.com/DeXter-on-Radix) (last commit March 2025) X @DexterOnRadix (https://x.com/DexterOnRadix) Telegram dexter_discussion (https://t.me/dexter_discussion) DeXter (formerly ProjectX) was a community-built, decentralized order-book (https://en.wikipedia.org/wiki/Order_book) exchange on the Radix (/contents/tech/core-protocols/radix-engine) network – the first order-book DEX on Radix built entirely by volunteers from the community. It offered a centralized-exchange-style trading experience with market and limit orders, live price charts, an on-chain order book, and historical trade data, all settled on Radix mainnet (/contents/tech/releases/radix-mainnet-babylon) , and its front-end was open source (https://github.com/DeXter-on-Radix/website) . Contributors proposed formally retiring the project in February 2026 (https://t.me/dexter_discussion/27547) and confirmed the wind-down on 8 March 2026 (https://t.me/dexter_discussion/27603) ; the exchange front-end is no longer online. History DeXter grew out of a Medium post (https://medium.com/alphadex-xrd/can-a-community-build-an-app-680cfbb06f1b) by Fred Liebenberg – founder of AlphaDEX (/ecosystem/alphadex) – which asked whether the Radix community could collectively build a full-featured exchange app in the spirit of Web3. The post drew in contributors from across the ecosystem, including Faraz Abulhawa, founder of Radstakes (/ecosystem/radstakes) , who joined alongside developers, designers, testers, and community managers. The project shipped its first order-book functionality around the Babylon (/contents/tech/releases/radix-mainnet-babylon) mainnet upgrade in September 2023 and ran as a live exchange until the community retired it in early 2026. Trading DeXter provided a decentralized trading experience modelled on centralized exchanges: market and limit orders, live price graphs, order-book depth, user order history, and downloadable historical trade reports. Radix's asset-oriented model (/contents/tech/core-concepts/asset-oriented-programming) let the order book and settlement run natively on-ledger. The Radix Foundation published a walkthrough (https://www.radixdlt.com/blog/navigating-the-dexter-order-book-exchange-an-easy-walkthrough) of the exchange for new users. The interface itself is gone: as of 28 July 2026 dexteronradix.com resolves to a parked-domain lander rather than the exchange, and the project's GitBook documentation returns a 404, so the front-end survives only in archived snapshots (https://web.archive.org/web/2025/https://dexteronradix.com/) . The underlying AlphaDEX (/ecosystem/alphadex) matching engine that DeXter traded against remains live on-ledger. DEXTR Token & Governance DEXTR was DeXter's contributor and governance token: trading fees collected by the exchange were distributed to holders to reward their contributions. Roughly 100,000 DEXTR were minted biweekly against a planned maximum supply of 14.5 million (https://www.livecoinwatch.com/price/DeXter-DEXTR) , with emissions set to decrease linearly until they ended in 2032. Allocation was community-driven: contributors were nominated for each distribution period, and the final split was set by the share of allocation points assigned to each nominee. Emissions stopped six years early. The validator staking-rewards programme was halted with the February 2026 retirement proposal, and the token has been static since: the 8 March 2026 buy-back order was sized at 4,739,465.1 DEXTR – the entire supply at that date – and an on-ledger read of the resource on 28 July 2026 returns the same 4,739,465.13 total supply ( resource_rdx1t…9pcj0c (https://dashboard.radixdlt.com/resource/resource_rdx1tkktjr0ew96se7wpsqxxvhp2vr67jc8anq04r5xkgxq3f0rg9pcj0c) ), roughly a third of the planned cap. No burn has been executed against it. Retirement (2026) On 18 February 2026 (https://t.me/dexter_discussion/27547) a project lead opened a public discussion in the DeXter Telegram proposing that the project be formally retired, citing the lack of activity on the exchange, the tapering of the validator emission subsidy, and uncertainty around the Radix Foundation's move to maintenance mode (/contents/history/partnerships) . The proposal had four parts: cease the validator staking-rewards programme immediately, auction off the validator owner badge, spend the treasury's XRD reserves buying back all circulating DEXTR, and burn whatever DEXTR remained in the treasury. The community backed it. On 8 March 2026 (https://t.me/dexter_discussion/27603) the team confirmed that all DeXter assets had been converted to XRD and a limit order placed to buy back the circulating supply. That order is verifiable on-ledger: transaction txid_rdx1ppaz0…7vaydx (https://dashboard.radixdlt.com/transaction/txid_rdx1ppaz0ttj0cpus5rqtfq5qnar7gd535d228nm40fcekukjyf7qwkq7vaydx/summary) withdrew 1,210,222.41 XRD from the DeXter treasury account (https://dashboard.radixdlt.com/account/account_rdx168qrzyngejus9nazhp7rw9z3qn2r7uk3ny89m5lwvl299ayv87vpn5/tokens) and placed a limit buy for 4,739,465.1 DEXTR at 0.25535 XRD each on the AlphaDEX order book. A read of that account on 28 July 2026 shows 1,213,497.76 DEXTR – about a quarter of the supply – repurchased so far, with the balance of the XRD still resting in the open order. The validator was kept running rather than sold: its operator lowered the fee from 100% to 10% so existing delegators continue to earn XRD rewards, with no further DEXTR incentives. Development had already stopped – the last commit to the DeXter-on-Radix (https://github.com/DeXter-on-Radix) GitHub organisation landed in March 2025. What the project left on the ledger A closed Radix project does not disappear from the ledger; it stops being maintained on it. Read live at epoch 339,247 on 29 August 2026, the DEXTR resource (https://dashboard.radixdlt.com/resource/resource_rdx1tkktjr0ew96se7wpsqxxvhp2vr67jc8anq04r5xkgxq3f0rg9pcj0c) still holds the same 4,739,465.133049414416099876 supply recorded a month earlier, and no burn has touched it. Queried at the resource itself the token looks dead – the last event the Gateway returns against it is dated 26 February 2026, ten days before the wind-down was confirmed. That view is misleading, and the pools are where to look instead. What the ledger does still carry is a set of pointers to infrastructure that no longer exists. The resource’s own metadata (/contents/tech/core-concepts/metadata-module) gives icon_url as content.dexteronradix.com/dextricon.png, ico_url as an ipfs.dexteronradix.com gateway path, and info_url as the GitBook documentation. The GitBook returns 404, and neither subdomain has any DNS record at all – the apex is parked on GoDaddy nameservers and the asset hosts were never re-pointed. Because that metadata is what wallets and explorers read, every surface that displays DEXTR renders a broken icon and links to a dead page. Radix resource metadata is mutable by whoever holds the metadata-setter role, so this is a task nobody was left to do rather than something the ledger has locked in. DEXTR is still traded, by machines. The token sits in three XRD pools on Ociswap (https://ociswap.com/dextr) , first listed on 19 January 2024 and together holding 80,950.50 DEXTR against 30,492.85 XRD – about $27.71 of liquidity by Ociswap’s own reckoning, at a quoted 0.2592 XRD per DEXTR – against a lifetime 4,089,422 DEXTR and 3,279,923 XRD traded. The largest of the three, a PrecisionPool opened on 27 August 2024, recorded ten transactions between 29 July and 19 August 2026, moving between roughly 817 and 16,420 DEXTR apiece across five different accounts, in the multi-hop shape of routed arbitrage rather than anyone trading the project. Nothing has touched it in the ten days since. A retired token with a shallow pool and a stale price is a standing invitation to a router, and that is what the remaining volume is. Method note: a resource-level query is the wrong instrument here. The Gateway’s entity filter on a fungible resource returns the events that act on the resource itself – minting, burning, metadata – and not the swaps that move it between vaults, so a token can look untouched for six months while its pool trades weekly. The pool components are the ones to query. Community & Impact DeXter was run as an open community project, welcoming UI/UX designers, front-end and full-stack developers, project managers, and marketers as contributors. Decision-making – including token distribution and, in the end, the decision to wind down – was made in public in the project's Telegram channel, which makes DeXter one of the clearest examples on Radix of an application both built and owned by its community, and one of the few to close down on the same terms. External Links - Archived exchange – dexteronradix.com (Wayback Machine) (https://web.archive.org/web/2025/https://dexteronradix.com/) - Retirement proposal – DeXter Telegram, 18 February 2026 (https://t.me/dexter_discussion/27547) - Wind-down confirmation – DeXter Telegram, 8 March 2026 (https://t.me/dexter_discussion/27603) - DEXTR resource – Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1tkktjr0ew96se7wpsqxxvhp2vr67jc8anq04r5xkgxq3f0rg9pcj0c) - GitHub – DeXter-on-Radix (https://github.com/DeXter-on-Radix) - X – @DexterOnRadix (https://x.com/DexterOnRadix) - Radix Blog – Navigating the DeXter Order Book Exchange (https://www.radixdlt.com/blog/navigating-the-dexter-order-book-exchange-an-easy-walkthrough) ## Atomix URL: https://radix.wiki/ecosystem/atomix Updated: 2026-08-28 Summary: Atomix is a peer-to-peer trading dApp on Radix that settles trustless swaps of tokens and NFTs directly between two wallets, under the tagline "Trade… Atomix is a peer-to-peer trading dApp on Radix that settles trustless swaps of tokens and NFTs directly between two wallets, under the tagline "Trade Any Asset, With Anyone, At Anytime" (https://atomix.trade) . It was built by Avaunt (/ecosystem/avaunt-staking) , the community developer behind the ShardSpace product family, and launched on mainnet on 30 October 2025 (https://t.me/ShardSpace/4171) after a two-month public beta on Stokenet. Each trade pairs two subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) – one signed by the buyer, one by the seller – so both legs of the swap finalize in a single atomic transaction or not at all. The platform's terms (https://atomix.trade/terms) describe it as a "community-developed interface to pre-authorizations, commonly called sub-intents, a native feature on the Radix DLT network": Atomix never takes custody of user funds, and every settlement happens on-ledger from the user's own wallet. As of August 2026 the interface still carries a beta notice reminding users that real mainnet assets are at stake. How it works Over-the-counter trades normally force one side to move first and trust the other to follow. Atomix removes that ordering: the buyer's offer and the seller's acceptance are each expressed as a subintent, both parties sign in the Radix Wallet, and the ledger composes the two into one transaction. The assets are withdrawn and deposited simultaneously – if either leg cannot execute, nothing moves. The launch announcement (https://t.me/ShardSpace/4171) summarized the guarantee as "assets exchange simultaneously or not at all", with no escrow component and no intermediary holding either side's tokens. Discovery starts from any account address: a user can browse the assets held by any wallet (https://t.me/ShardSpace/3851) and send the owner an offer to buy one of them, or pre-agree terms with a known counterparty and use Atomix purely as the settlement engine. There is deliberately no public order book – the developer has kept offers private and person-to-person (https://t.me/ShardSpace/4230) so that OTC deals cannot be front-run or observed, positioning the open-auction use case in the sibling dApp Bullring (/ecosystem/bullring) instead. Since a November 2025 manifest update (https://t.me/ShardSpace/4223) , the transaction preview in the Radix Wallet shows the withdrawal and the deposit for both parties, so each signer sees the full result of the trade before approving it. The interface also flags recallable and freezable assets (https://t.me/ShardSpace/4153) with safety warnings before a trade is signed. Notifications and interface An offer is only useful if the counterparty learns about it. Atomix delivers offers through Notix (/ecosystem/notix) , Avaunt's Radix notification service, and through a dedicated Telegram bot for trade-offer notifications (https://t.me/ShardSpace/4730) : if the recipient is a registered Atomix or Notix user, they are notified that someone wants to trade (https://t.me/ShardSpace/4346) even when the offer arrives cold. Accepting works directly from Telegram (https://t.me/ShardSpace/3890) – the accept button opens Atomix, the Radix Wallet opens to sign the subintent, and the trade executes. The interface supports QR-code scanning (https://t.me/ShardSpace/4265) for in-person swaps – scanning a counterparty's Radix Wallet account QR replaces copying addresses between devices – and multi-account support (https://t.me/ShardSpace/4572) , with Telegram notification settings configurable per account. Developer API Atomix exposes its trade engine to third-party sites. A developer registers an app in the My Apps (https://atomix.trade/my-apps) section, generates an embeddable widget with the widget generator (https://atomix.trade/my-apps/widget-generator) , and follows the bundled integration guide (https://t.me/ShardSpace/3879) . The integration POSTs the trade details to the Atomix API (https://t.me/ShardSpace/3877) , which returns the composed transaction manifest for the user's wallet to sign – letting any site sell digital assets from its own front end while Atomix handles subintent construction and settlement. The developer built a demonstration third-party dApp (https://t.me/ShardSpace/4029) against the API as part of internal testing. Fees and settlement on ledger Atomix charges 3% of the trade price, and it charges it on ledger. Every settlement routes the fee to component_rdx1cq94mg7…y9050mvz, a component whose on-ledger metadata names it "Atomix Fee Collection", tags it atomix, sub-intents and OTC, and points back at the Atomix dApp definition (/developers/frontend/04-dapp-definition-and-verification) account. The rate is visible in the amounts themselves: 0.3 XRD on a 10 XRD trade, 3 on 100, 30 on 1,000. That makes the component a public meter of the dApp's use, which no status code and no front end can give you. Walked in full on 28 August 2026, it holds 52 transactions reaching back to 24 October 2025, a week before the mainnet launch. Across 40 fee events from that date to 17 January 2026 it collected 208.38 XRD in total, the largest single fee being 30.6 XRD, on a trade of about 1,020 XRD. Then it went quiet for seven months. It came back on 21 August 2026 with three transactions in forty minutes, and the middle one is the largest trade Atomix has settled: the sale of the Avaunt Staking (/ecosystem/avaunt-staking) validator's owner badge for 1,456,311 XRD, on which the fee was 43,689.33 XRD. That one fee is 210 times everything the platform had earned in the ten months before it. Twenty minutes later the operator swept the component's whole balance, 43,693.83 XRD, in a single withdrawal. Avaunt built Atomix, and when Avaunt sold its validator it used Atomix to do it. History Atomix surfaced on 1 September 2025 (https://t.me/ShardSpace/3851) , when Avaunt announced the Stokenet beta at atomix.fly.dev (https://atomix.fly.dev) and invited the ShardSpace community to test it. The two months that followed were a public hardening pass: - 2 September 2025 – the API, widget generator and integration guide (https://t.me/ShardSpace/3879) opened for third-party testing. - 6 September 2025 – a 20,000 XRD bug bounty (https://t.me/ShardSpace/3925) for anyone who could trick Atomix into processing a transaction either signer had not knowingly approved. No successful attack was reported in the channel. - 22 October 2025 – new logo, branding and safety warnings (https://t.me/ShardSpace/4153) for recallable and freezable assets. - 30 October 2025 – mainnet launch (https://t.me/ShardSpace/4171) at atomix.trade. - 4 November 2025 – mainnet manifest update (https://t.me/ShardSpace/4223) showing both sides of the trade to both signers. - 16 November 2025 – QR-code scanning (https://t.me/ShardSpace/4265) for in-person trades. - 28 November 2025 – multi-account support (https://t.me/ShardSpace/4572) and per-account Telegram notification settings. Developer and related projects Atomix is one of four products (https://t.me/ShardSpace/4257) built by Avaunt, the operator of the Avaunt Staking (/ecosystem/avaunt-staking) validator: ShardSpace (/ecosystem/shardspace) (portfolio management), Notix (/ecosystem/notix) (notifications), Atomix (peer-to-peer OTC trading) and Bullring (/ecosystem/bullring) (peer-to-peer auctions). Atomix and Bullring both build on subintents – Atomix for private direct offers, Bullring for open listings with reserve prices. Support and development discussion for the whole family runs through the shared ShardSpace | Notix Community (https://t.me/ShardSpace) Telegram group. External Links - atomix.trade (https://atomix.trade) – mainnet dApp - atomix.fly.dev (https://atomix.fly.dev) – Stokenet test instance - Terms and conditions (https://atomix.trade/terms) - ShardSpace | Notix Community (https://t.me/ShardSpace) – Telegram support group - Mainnet launch announcement (https://t.me/ShardSpace/4171) – 30 October 2025 ## Avaunt Staking URL: https://radix.wiki/ecosystem/avaunt-staking Updated: 2026-08-28 Summary: On 21 August 2026 at 15:47 UTC Avaunt announced in the main Radix Telegram channel that it is closing its validator operations: "After six incredible… Wind-down and sale to StakeSafe (August 2026) On 21 August 2026 at 15:47 UTC Avaunt announced in the main Radix Telegram channel (https://t.me/radix_dlt/998993) that it is closing its validator operations: "After six incredible years of running the Avaunt Staking validator, the time has come for us to close down operations." The post dates the company's involvement to the Olympia (/contents/tech/releases/radix-mainnet-olympia) betanet and sets a handover date: on 28 August 2026 all services migrate to StakeSafe (/ecosystem/stakesafe) , with delegators encouraged to keep their delegation in place. Avaunt is not leaving the ecosystem; the announcement says it is "just focussing on our non-Validator activities". Two follow-up messages from the same account, minutes later, set out what delegators have to do, which is nothing: "No action required from any delegators, your stake will remain delegated to the validator and in your complete control" (https://t.me/radix_dlt/998997) , and "We're just transferring the Validator to StakeSafe" (https://t.me/radix_dlt/998998) . The node changes operator rather than the delegations changing node: the validator (/contents/tech/core-concepts/validator-nodes) component and the stake (/contents/tech/core-concepts/staking) delegated to it stay where they are, and what changes hands is control of the component, which on Radix means its owner badge. The transfer had already finalized, thirteen minutes before the announcement An earlier version of this page read the validator from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 336,990 on the evening of 21 August, found its name, its info_url and its 2% fee all unchanged, and concluded that nothing about the transfer had been executed on ledger. That was wrong, and the reason is worth naming: a validator does not change hands by changing its own fields. It changes hands when its owner badge moves, and that badge is an ordinary non-fungible sitting in an ordinary account, so the evidence lives in the badge's location and in the transactions that present it, not in anything the validator displays. Read that way, the whole handover fits inside one afternoon. - 14:31:47 UTC (state version 552,803,398) – Avaunt's operating account account_rdx169ldq…yp8j8f5w4 presents the owner badge [834bcbdc…24a2beb0] and calls update_key, rotating the validator's consensus key. That account had exercised this badge continuously since 28 September 2023, across thirty owner transactions, and this was its last act as owner. - 14:36:18 UTC (552,804,042) – the same account withdraws the badge and sends it to a second Avaunt-controlled account. - 15:34:27 UTC (552,824,072, txid_rdx1g52wlj5np7zgf3a… (https://dashboard.radixdlt.com/transaction/txid_rdx1g52wlj5np7zgf3a07ash9wdnyej86gucvhz3dzc3psqs3q7q696ssj9u34) ) – the sale. One atomic transaction composed from two subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) : the badge leaves the Avaunt account and 1,456,311 XRD arrive in it, a further 43,689.33 XRD goes to the fee component of Atomix (/ecosystem/atomix) , and a third account pays the 0.84 XRD network fee. The buyer's side of the ledger reads 1,500,000.33 XRD out, badge in. - 15:47 UTC – the Telegram announcement above. Two things follow from the accounts involved. The buyer's account is the same one that holds and exercises StakeSafe Amsterdam's owner badge, which it used on 16 August 2026 to queue that node's own fee rise and to begin unlocking its owner stake, so the counterparty is StakeSafe's operating account rather than an unidentified buyer. And the venue is Atomix, the peer-to-peer subintent trading dApp Avaunt itself built and launched in October 2025 (/ecosystem/atomix) : the company sold its validator through its own product, and the 3% platform fee that trade paid is 210 times everything Atomix had collected in fees up to that point (/ecosystem/atomix) . What the new owner has done since Both acts fall on 26 August 2026 and both are signed from the buyer's account with the badge it now holds: - 20:47:04 UTC – update_fee at 0.25. The validator fee goes from 2% to 25%, effective at epoch 342,482. - 20:48:52 UTC – start_unlock_owner_stake_units for 294,848 stake units, released at epoch 346,514. Read at epoch 338,910 (28 August 2026, 11:06 UTC) the validator is still registered, still accepting delegated stake, still charging 2%, and still carries the name "⏩ Avaunt Staking ⏩ ShardSpace.app" with info_url pointing at avaunt-staking.com and an icon served from that domain. It holds 142,149,029.36 XRD at rank 9 of the 188 registered validators, down from 148,936,095 XRD and rank 8 at the announcement: 6.79 million XRD, 4.6% of the delegation, withdrawn in the week since. At the network's measured pace of roughly 288 epochs a day, the fee rise lands around 9–10 September 2026 and the owner-stake release around 23–24 September. Delegators who do as the announcement asked and leave their stake in place therefore move from one of the cheapest large nodes on the network to a 25% fee in mid-September. StakeSafe's own two validators have the identical 25% queued at epochs 339,608 and 339,609, days away; the detail is on the StakeSafe (/ecosystem/stakesafe) page. Nothing about the fee rise was in the announcement, and nothing on the validator's public face says it is coming. The rest of this page The history section below reflects the company's own website, which has not been updated since 2023 and still advertises "$5M+ staked, 400+ delegators". The node has been co-branded with ShardSpace (/ecosystem/shardspace) , the Radix staking and portfolio dashboard, which is where the validator's presentation to delegators has lived; the avaunt-staking.com (https://avaunt-staking.com) site is still online but is a 2023 artefact, its footer reading "Copyright © 2023" and its Radix section still announcing that "Radix is now LIVE". What becomes of the ShardSpace co-branding now that the badge has moved has not been stated. The Radix Dashboard product described below is gone: radixdashboard.com no longer serves it. The domain resolves and answers over plain HTTP with a parking page (last modified 2 June 2026) and times out entirely over HTTPS, so the section below is cited to an archived snapshot rather than the live host. Avaunt Staking Services is a company that specializes in cryptocurrency staking services, facilitating the operation of validator nodes on a variety of blockchain projects. As a validator operator, Avaunt Staking Services enables token holders, also known as delegators, to delegate their tokens to the company's nodes. In return, these delegators receive a portion of the network rewards. As of 2023, Avaunt Staking Services manages validator nodes on several networks including Avalanche, Radix, and the SSV Network. https://youtu.be/BJLWzqqWzFM (https://youtu.be/BJLWzqqWzFM) Overview Avaunt Staking Services was established to cater to the shift from Proof-of-Work (PoW) to Proof-of-Stake (PoS) consensus mechanisms in the blockchain industry. PoS, unlike PoW, relies on a network of validator nodes and staked collateral to secure the network, rather than computational energy. Avaunt Staking Services provides a platform where individuals and entities can delegate their staking tokens to a validator, earning a percentage of the validator's revenue in return. In addition to their primary staking service, Avaunt also offers IT and AV consultancy, with over 20 years of experience in IT infrastructure project delivery, and web design & development services, encompassing branding, design & build, hosting & domain registration, social media, SEO, and marketing. History As of 2023 (https://avaunt-staking.com) , Avaunt Staking Services is accepting delegations on the Avalanche Network and Radix. They have over $5 million staked across more than 400 delegators and are active on three networks, with plans for expansion. Mission Avaunt Staking is community-focused, with a mission to help each and every project grow and provide transparency to the delegator community (https://avaunt-staking.com) . Products & Services Avaunt Staking The company provides secure infrastructure, high availability cloud hosted infrastructure, secured in multiple data centres across the globe and monitored 24/7. They are also a trusted validator on some of the biggest Proof of Stake networks. Delegators play a critical role in the system, as they show support for reputable validators. Running a Validator Node requires a high level of technical knowledge and commitment to ensure that a consistent quality of service is maintained. Radix Dashboard https://www.radixdashboard.com (https://web.archive.org/web/20260519103614/http://radixdashboard.com/) Consultancy In addition to staking services, Avaunt offers IT and AV consultancy with 20+ years of experience, specializing in IT Infrastructure project delivery. They also provide web design and development services including branding, design & build, hosting & domain registration, social media, SEO & marketing. Supported Networks As of 2023, Avaunt Staking Services supports the following networks: Avalanche Avalanche is an open-source platform that facilitates the launch of highly decentralized applications, new financial primitives, and interoperable blockchains. Radix Radix is a decentralized network designed to provide developers with a platform where they can build rapidly without the threat of exploits and hacks, and without scaling being a bottleneck. SSV Network SSV.network is a decentralized staking infrastructure that enables the distributed operation of an Ethereum validator, providing simple and scalable access to decentralized ETH staking. Staking Process For token holders interested in becoming delegators with Avaunt Staking Services, the process generally follows these steps: - Token holders delegate their staking tokens to a validator node managed by Avaunt Staking Services. - Once the tokens are delegated, they are added to the validator's staking pool. - Rewards, which are paid in the native network token, are distributed to the delegator's wallet at the end of each epoch (a fixed period of time unique to each network). Delegators share both the revenue and the performance risk of their validator. The specific penalty differs by network, and the generic description of slashing — a proportion of delegated stake destroyed — does not apply on Radix, which uses emissions-based penalties instead (/contents/tech/core-concepts/staking) : an underperforming validator and its delegators earn fewer rewards, but staked XRD is never destroyed. Slashing does apply on the other networks Avaunt operates on. Security and Trust To maintain a high level of service, Avaunt Staking Services operates high availability cloud-hosted infrastructure, secured in multiple data centers across the globe and monitored 24/7. The company prides itself on its commitment to the delegator community, providing transparency and actively contributing to the growth of each project. ## Acceptable Use Policy URL: https://radix.wiki/contents/resources/legal/acceptable-use-policy Updated: 2026-08-28 Summary: This Acceptable Use Policy sets out the terms between you and us under which you may access our website ( our site ). This acceptab… This Acceptable Use Policy sets out the terms between you and us under which you may access our website https://RADIX.wiki (https://RADIX.wiki) (our site). This acceptable use policy applies to all users of, and visitors to, our site. Your use of our site means that you accept, and agree to abide by, all the policies in this acceptable use policy, which supplement our Terms of Use (/contents/resources/legal/terms-of-use) . RADIX.wiki (https://radix.wiki) is operated by the RADIX.wiki (https://radix.wiki) DAO (we or us). Prohibited Uses You may use our site only for lawful purposes. You may not use our site: - In any way that breaches any applicable local, national or international law or regulation. - In any way that is unlawful or fraudulent, or has any unlawful or fraudulent purpose or effect. - For the purpose of harming or attempting to harm minors in any way. - To send, knowingly receive, upload, download, use or re-use any material which does not comply with our content standards. - To transmit, or procure the sending of, any unsolicited or unauthorised advertising or promotional material or any other form of similar solicitation (spam). - To knowingly transmit any data, send or upload any material that contains viruses, Trojan horses, worms, time-bombs, keystroke loggers, spyware, adware or any other harmful programs or similar computer code designed to adversely affect the operation of any computer software or hardware. You also agree: - Not to reproduce, duplicate, copy or re-sell any part of our site in contravention of the provisions of our Terms of Use (/contents/resources/legal/terms-of-use) . - Not to access without authority, interfere with, damage or disrupt: - any part of our site; - any equipment or network on which our site is stored; - any software used in the provision of our site; or - any equipment or network or software owned or used by any third party. Interactive Services Our site provides the interactive services below, and this section is the information about them that we undertake to give you: - Article editing. Signed-in contributors may create and edit articles. Some areas additionally require a minimum XRD balance or are restricted to their author, and a small number of pages are locked and cannot be edited at all. Every change is recorded as a revision against the account that made it, and any earlier revision can be restored from the page’s history by anyone who can edit that page. - Discussion. Each article carries a threaded comment section, open to signed-in contributors. A comment can be deleted by the contributor who wrote it, and by no one else. - The blog. Long-form posts, held to the same editorial policy (/policy) as articles. - Image upload. A signed-in contributor may attach images to an article. We accept JPEG, PNG, GIF, WebP and AVIF files up to 25 MB; SVG is refused, because it is executable markup. Every accepted file is re-encoded to WebP at no more than 1,600 pixels wide and stored at a public address on our content-delivery host, which serves it independently of the article it was uploaded for. None of these services is pre-moderated, whether by a person or by a filter: a contribution is live from the moment it is submitted. Moderation here is retrospective, and it is structural rather than editorial — the revision history is the mechanism, in that an inaccurate or non-compliant edit is corrected by the next edit and every version remains on the record. Where we act ourselves, we act after the fact and under Suspension and Termination below. Two limits on that mechanism decide what you can take back. An uploaded file is not withdrawn by the edit that removes it from an article: the article stops showing it, and the file stays reachable at the address it was given. Withdrawing it is an action we take off the site, at our discretion and under Suspension and Termination below. And the record survives every edit but not the deletion of the page itself: a page can be deleted outright by the contributor who created it, and deleting it takes its revision history and its comments away with it, including comments written by other people. Treat what you upload, and what you write under someone else’s article, as published rather than as recoverable. We will do our best to assess any possible risks for users (and in particular, for children) from third parties when they use any interactive service provided on our site, and we will decide in each case whether it is appropriate to use moderation of the relevant service (including what kind of moderation to use) in the light of those risks. However, we are under no obligation to oversee, monitor or moderate any interactive service we provide on our site, and we expressly exclude our liability for any loss or damage arising from the use of any interactive service by a user in contravention of our content standards, whether the service is moderated or not. The use of any of our interactive services by a minor is subject to the consent of their parent or guardian. We advise parents who permit their children to use an interactive service that it is important that they communicate with their children about their safety online, as moderation is not foolproof. Minors who are using any interactive service should be made aware of the potential risks to them. Where we do moderate an interactive service, we will normally provide you with a means of contacting the moderator, should a concern or difficulty arise. Content Standards These content standards apply to any and all material which you contribute to our site (contributions), and to any interactive services associated with it. You must comply with the spirit and the letter of the following standards. The standards apply to each part of any contribution as well as to its whole. Contributions must: - Be accurate (where they state facts). - Be genuinely held (where they state opinions). - Comply with applicable law in the UK and in any country from which they are posted. Contributions must not: - Contain any material which is defamatory of any person. - Contain any material which is obscene, offensive, hateful or inflammatory. - Promote sexually explicit material. - Promote violence. - Promote discrimination based on race, sex, religion, nationality, disability, sexual orientation or age. - Infringe any copyright, database right or trade mark of any other person. - Be likely to deceive any person. - Be made in breach of any legal duty owed to a third party, such as a contractual duty or a duty of confidence. - Promote any illegal activity. - Be threatening, abuse or invade another’s privacy, or cause annoyance, inconvenience or needless anxiety. - Be likely to harass, upset, embarrass, alarm or annoy any other person. - Be used to impersonate any person, or to misrepresent your identity or affiliation with any person. - Give the impression that they emanate from us, if this is not the case. - Advocate, promote or assist any unlawful act such as (by way of example only) copyright infringement or computer misuse. Suspension and Termination We will determine, in our discretion, whether there has been a breach of this acceptable use policy through your use of our site. When a breach of this policy has occurred, we may take such action as we deem appropriate. Failure to comply with this acceptable use policy constitutes a material breach of the Terms of Use (/contents/resources/legal/terms-of-use) upon which you are permitted to use our site, and may result in our taking all or any of the following actions: - Immediate, temporary or permanent withdrawal of your right to use our site. - Immediate, temporary or permanent removal of any posting or material uploaded by you to our site. - Issue of a warning to you. - Legal proceedings against you for reimbursement of all costs on an indemnity basis (including, but not limited to, reasonable administrative and legal costs) resulting from the breach. - Further legal action against you. - Disclosure of such information to law enforcement authorities as we reasonably feel is necessary. We exclude liability for actions taken in response to breaches of this acceptable use policy. The responses described in this policy are not limited, and we may take any other action we reasonably deem appropriate. Changes to the Acceptable Use Policy We may revise this acceptable use policy at any time by amending this page. You are expected to check this page from time to time to take notice of any changes we make, as they are legally binding on you. Some of the provisions contained in this acceptable use policy may also be superseded by provisions or notices published elsewhere on our site. ## RGH2024 Debrief URL: https://radix.wiki/blog/rgh2024-debrief Updated: 2026-08-28 Summary: 5 min read Over the April 20th weekend, while most of crypto was literally treading water in Dubai, we brought ~60 people for a next-gen hackathon on… Format Event debrief (5 min read) Event Radix Global Hackathon 2024 (/contents/history/radix-wiki-hackathon-1) — ArtSect Gallery, London, weekend of 20 April 2024, ~60 participants Thesis tested Protocol revolutions are followed by publishing revolutions, and at this stage of Web3 developers are the customer — so facilitating collaboration compounds faster than any other ecosystem activity Follow-on Building Radix’s Developer Pipeline: Nine Events and Counting (/blog/building-radixs-developer-pipeline-nine-events-and-counting) RGH2024 Debrief 5 min read Over the April 20th weekend, while most of crypto was literally treading water in Dubai, we brought ~60 people for a next-gen hackathon on the Radix stack. Here’s the background, what was built, and what we learned. Protocol Revolution → Publishing Revolution Before we get to event, here’s a bit of context. Throughout history, protocol revolutions have been reliably followed by publishing revolutions. From the 20m books that rolled off of Gutenberg’s 1440 printing press, to the ~50bn web pages enabled by TCP/IP, HTTPS, and APIs. Radix is likewise a protocol revolution: Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , the Radix Engine (/contents/tech/core-protocols/radix-engine) , Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , and the numerous other protocols (/contents/tech/core-protocols) that constitute Radix are leading to a publishing revolution where anyone around the world is able to build and launch a performant Web3 application. At this stage of the Web3 publishing revolution, developers are the main customers of blockchains and distributed ledgers. And like any customer thinking about a long-term commitment of capital or resources, they want to kick the tires before they start the long process of building an application. Usually held over a weekend, hackathons are an ideal vehicle to expedite this process. They give developers a chance to build a Minimum Viable Product (MVP) with help from mentors, while being fed and watered in the company of like-minded collaborators with whom they can explore the potential of a technology. During such events, developers are able to ask vital questions such as: “Is this technology viable”? “Is it future-proof?” “Is there adequate documentation?” “How quickly will I be able to take a product to market?” Radix is a Web3 infrastructure layer that has been built with these questions in mind. For example: - Assets on Radix can only exist in a small number of permitted states, freeing developers from the stressful, time-consuming task of trying to specifically exclude undesirable states. - Like a physics engine in the gaming world, Radix’s execution layer - the Radix Engine (/contents/tech/core-protocols/radix-engine) - abstracts away the logic and behavior of assets, leaving developers free to focus on application and business logic. In contrast, developers on the Turing-complete Ethereum (https://ethereum.org) blockchain spend ~90% of their time (https://x.com/PiersRidyard/status/1360651370676838403) on security. RADIX.wiki (/) 🤝 ArtSect With a mission to accelerate the Web3 publishing revolution and building on the success of our Babylon Launch Party (/blog/a-year-in-review-2023) , we organized a Radix Global Hackathon in collaboration with the East London Decentralized Art Organization, ArtSect (https://www.artsect.xyz/) . The primary objective was to introduce developers to the Radix stack but also to strategically raise the visibility of Radix within one of the most vibrant and prolific Web3 art communities in the world. The event began on Saturday April 20th at 10am and continued throughout the night until around 6pm on the Sunday. Over the two days we had around 60 people through the door, ranging from experienced full-stack developers to absolute beginners. Experience 🤝 Learnings Aside from the logistical challenges of creating a harmonious happening of space, wifi, and food, here are a few things we learned during the event: - The Scrypto (/contents/tech/core-protocols/scrypto-programming-language) effect is real. Nearly all of the developers commented on how quickly they were able to build and a few - having never touched Scrypto (/contents/tech/core-protocols/scrypto-programming-language) before - were up to speed within a couple of hours. Richard Jarram (https://www.linkedin.com/in/richardjarram/) , GeoChain - A thorough presentation and a slice of pizza are enough to red-pill new developers. Doing this at scale would have the highest ROI of any marketing initiative we can think of. - The prize money is way less important than we realized. Most participants signed up before the prizes were announced and hardly any of them mentioned it during the event. Building something cool was their primary objective. - University blockchain societies are hosting events every week and always on the lookout for interesting developments to showcase. - Beyond Bitcoin (https://bitcoin.org) , the valence of networks and loyalty of participants is much weaker. Several participants wearing Solana (https://solana.com) t-shirts simultaneously said how difficult it is to develop on! - Huge industries are still actively looking for where to build in Web3. We spoke to founders of gaming, fashion, and art businesses all waiting for the right infrastructure to deploy on. In the end we had 7 great submissions. Here are the results and presentation videos: 🏆 Results 🥇 Beginners’ Track Winner - 🗺️ Geochain geochain (https://github.com/metalogica/geochain) Geochain securely tracks and manages shipments in real-time using Radix for a transparent and efficient supply chain. Team: Richard Jarram (https://www.linkedin.com/in/richardjarram/) , Mariana Oka (https://www.linkedin.com/in/mariana-oka/) Presentation: https://docs.google.com/presentation/d/1NHJWIptTSpNwz4_rQeq7qeKeIL7GeEcEXz9H9wb7EwI/edit#slide=id.g26f1ee450e0_0_322 (https://docs.google.com/presentation/d/1NHJWIptTSpNwz4_rQeq7qeKeIL7GeEcEXz9H9wb7EwI/edit#slide=id.g26f1ee450e0_0_322) 🥈 Beginners’ Track Silver - 📊 Radix Stats radixstats (https://github.com/dcts/radixstats) Radix Stats provides free and open token analytics for Radix, enhancing transparency and credibility. Team: Thomas Starzynski (https://www.linkedin.com/in/thomas-starzynski/) , Mauro Jose (https://www.linkedin.com/in/maurojose) RadixStats-slides.pdf4028.5KB (https://web.archive.org/web/20241211211027/https://assets.super.so/2a0d12a5-9454-4417-b17e-d51617137fb6/files/35b8e60c-0557-4bcb-afe6-9c6b2a913525/RadixStats-slides.pdf) Radix Dashboard (https://radixstats.web.app/?resource=resource_rdx1t5xv44c0u99z096q00mv74emwmxwjw26m98lwlzq6ddlpe9f5cuc7s) Explore token stats on Radix (https://radixstats.web.app/?resource=resource_rdx1t5xv44c0u99z096q00mv74emwmxwjw26m98lwlzq6ddlpe9f5cuc7s) radixstats.web.app (https://radixstats.web.app) 🥉 Beginners’ Track Bronze - 🕺 Jouna-Wyliometer jouna-wyliometer (https://github.com/jameswylie/jouna-wyliometer) The Jouna-Wyliometer is a price sentiment tool that uses a 3D avatar who, via the Astrolescent (/ecosystem/astrolescent) API, reacts according to the current $XRD price. Team: Jouna Lansman (https://twitter.com/JounaLansman) Wyliometer - Price Sentiment Tool (https://jouna-wyliometer.pages.dev/) 🥇 Advanced Track Winner - ∞ InfiniX RadixScryptoChallenge---InfiniX (https://github.com/AbdurRazzak01/RadixHack) AbdurRazzak01 ⋅ 2 years ago (https://github.com/AbdurRazzak01/RadixHack) InfiniX offers customizable loss limits, instant fund settlements, and parametric insurance integration for DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) investments. Team: MD Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAADmcRukBZBWcEc42TGiCbxkH1K0Tn9QAK0k&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BHakxM5kLQl6Ta%2FV2gp3MvQ%3D%3D) , Kishan Marsonia (https://www.linkedin.com/in/kishan-marsonia) InfiniX (https://www.canva.com/design/DAGDCJiRn0g/jvYaaVqe4WQasc20wUjRYw/edit?utm_content=DAGDCJiRn0g&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton) 🥈 Advanced Track Silver - 🤖 AI Invest aiin (repository no longer public) AI Invest provides an accessible chatbot interface with real-time stock and crypto data, guided purchases, and engaging UI for simplified trading. Team: Jetnor Muhaj (https://www.linkedin.com/in/jetnormuhaj/) AI Invest Radix Chat bot (https://www.canva.com/design/DAGCX1Ol78M/MXBVmGt_t_ucxpUkPbISPw/view?utm_content=DAGCX1Ol78M&utm_campaign=designshare&utm_medium=link&utm_source=editor) Check out this Presentation designed by Jetnor Muhaj. (https://www.canva.com/design/DAGCX1Ol78M/MXBVmGt_t_ucxpUkPbISPw/view?utm_content=DAGCX1Ol78M&utm_campaign=designshare&utm_medium=link&utm_source=editor) 🥉 Advanced Track Bronze - 🥊 Top Scorer / FitClash fitclashdemo (https://github.com/fitclash/fitclashdemo) 2 years ago (https://github.com/fitclash/fitclashdemo) Top Scorer / FitClash is a fitness app that allows friends to wager each other with $XRD in various physical activities with real-time AI tracking and leaderboards. Team: Justin Grierson (https://www.linkedin.com/in/justin-grierson) Advanced Track Runner Up - 🎨 PiciX PiciX is a daily AI art challenge inspired by Wordle, where participants create image prompts to match a provided AI-generated image, with the winning creation minted as an NFT and sent to the winner's Radix wallet (/contents/tech/core-protocols/radix-wallet) . Team: MD Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAADmcRukBZBWcEc42TGiCbxkH1K0Tn9QAK0k&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BHakxM5kLQl6Ta%2FV2gp3MvQ%3D%3D) , Kishan Marsonia (https://www.linkedin.com/in/kishan-marsonia) In the end, this event validated our thesis that facilitating collaborations is one of the most valuable activities we can do for the Radix ecosystem, and the faster we can do it, the more it will compound. A huge thanks to everyone who participated and helped out, especially @a_vaunt (https://twitter.com/a_vaunt) , James Wylie (https://github.com/jameswylie) , beemdvp (https://github.com/beemdvp) , @Radstakes (https://twitter.com/Radstakes) and David Cuellar for the red-pilling and bug fixing, @ArtSectDAO (https://twitter.com/ArtSectDAO) for their 36hr straight technical support, and @JustEatBusiness (https://twitter.com/JustEatBusiness) , Dorothy's Deli and PAUL ( http://instagram.com/dorothysdeli (https://www.instagram.com/dorothysdeli/) / http://instagram.com/paul_bakeryuk (https://www.instagram.com/paul_bakeryuk/) ) for the food. Check out the event page here for more details, and see you all next year! RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) ## Pillar Hackathon #1 URL: https://radix.wiki/contents/history/pillar-hackathon-1 Updated: 2026-08-27 Summary: Pillar Hackathon #1 was a two-day developer hackathon held on 17–18 January 2019 , hosted by the Pillar Project as the soft launch of its developer co… Event – Hackathon Title Pillar Hackathon #1 Category History / Community Event Dates 17–18 January 2019 Format Three-track integration hackathon Status Completed Organiser Pillar Project (https://www.pillar.fi) Video Recording Watch on YouTube (https://youtu.be/hLrbQAmWV0w) Post-Event Write-up Medium Article (https://medium.com/pillarproject/after-the-pillar-hackathon-1-a0c74ef8c0f) | Pillar Blog (https://www.pillar.fi/blog/after-the-pillar-hackathon-1/) Related Project Pillar Project Official Site (https://www.pillar.fi) Overview Pillar Hackathon #1 was a two-day developer hackathon held on 17–18 January 2019, hosted by the Pillar Project (https://www.pillar.fi) as the soft launch of its developer community. Rather than a competitive prize event, it was structured as a set of integration challenges: teams from partner blockchain networks worked alongside Pillar's engineers to connect their protocols to the Pillar wallet, and Pillar opened its GitHub repositories (https://github.com/pillarwallet) to the wider developer community during the event. The hackathon is part of Radix's history (/contents/history) because Radix DLT (/contents/history) – then an early-stage distributed ledger project – took part as one of the three integration tracks, marking one of its early cross-project developer collaborations. Pillar and Radix had worked together once before, the previous summer, at the Pillar Unconference (/contents/history/pillar-unconference) of 15–22 July 2018, where Radix ran its first hackathon. The Three Integration Tracks According to Pillar's post-event write-up (https://www.pillar.fi/blog/after-the-pillar-hackathon-1/) , three partner projects each pursued a distinct integration track: - NEM (https://nem.io) – worked on integrating the NEM network into Pillar's blockchain explorer, in the process surfacing limitations in the existing architecture that a multi-chain wallet would need to address. - DigiByte (https://www.digibyte.org) – developed an approach for wallet integration and laid foundations for adding additional blockchain forks to Pillar. - Radix (/contents/history) – built a bridge between the two projects (see below). Radix Integration The Radix track produced a working bridge between Radix and the Pillar wallet. Per Pillar's write-up, the integration enabled wallet generation in the Radix address format and balance retrieval from the Radix ledger – an early demonstration of Radix account handling inside a third-party consumer wallet, years before the Babylon (/contents/tech/releases/radix-mainnet-babylon) network and the official Radix Wallet. It stands as a small but concrete milestone in Radix's early developer-outreach efforts. Gallery External Links - Event video recording (YouTube) (https://youtu.be/hLrbQAmWV0w) - "After the Pillar Hackathon #1" – Pillar Blog (https://www.pillar.fi/blog/after-the-pillar-hackathon-1/) - "After the Pillar Hackathon #1" – Medium (https://medium.com/pillarproject/after-the-pillar-hackathon-1-a0c74ef8c0f) ## Gable Finance URL: https://radix.wiki/ecosystem/gable-finance Updated: 2026-08-27 Summary: Gable Finance (previously: Sundae Finance) was a decentralized liquidity market protocol on Radix, dormant since April 2024. It was founded by Joost D… Gable Finance Type Decentralized liquidity market and flash-loan protocol on Radix (formerly Sundae Finance) Status 🟠 Dormant since April 2024. gable.finance (https://gable.finance) still answers, but its homepage has not been republished since 23 April 2024 and the dApp definition it publishes has been idle since 22 April 2024 Founded 2023, Amsterdam (Netherlands) by Joost Delaere Category DeFi, liquidity, flash loans, validator staking Funding Radix Babylon Booster Grant (https://www.radixdlt.com/blog/babylon-booster-grants-gable) , announced 21 November 2023 Links X (https://x.com/Gable_Finance) · GitHub (https://github.com/gable-finance) · Telegram (https://t.me/gable_finance) Gable Finance (previously: Sundae Finance) was a decentralized liquidity market protocol on Radix, dormant since April 2024. It was founded by Joost Delaere (https://www.linkedin.com/in/joostdelaere123/) in Amsterdam, Netherlands in 2023. The protocol offered flash loans, allowing users to borrow funds without collateral if the borrowed funds are returned within the same transaction. This feature serves a wide variety of purposes including trading, arbitrage, and others. See the Gable Finance introduction video (https://youtu.be/NEtdvqDkWss?si=ayftgDxrJ99TjrbF) . Etymology In a Medium post (https://gablefinance.medium.com/gable-cddeaeed139c) , Joost Delaere wrote that the name ‘Gable’ was inspired by the steeped gables that are characteristic of the architecture in Amsterdam, his native home. History Gable was conceived in early 2023 by Joost Delaere, a software developer with a background in quantitative finance and credit risk model implementation. Drawing from his personal interest in cryptocurrency and decentralized finance, Delaere aimed to build a platform where traders and investors could meet and bring liquidity to the forefront of decentralized finance. The first iteration shipped after the launch of Radix Babylon (/contents/tech/releases/radix-mainnet-babylon) in 2023, offering a validator node, a liquidity pool, and flash loans. Features Gable allows users to participate as borrowers or suppliers. For suppliers, it involves staking $XRD at Gable's validator node, depositing Liquid Staking Units (LSU's) into the liquidity pool, earning interest, and finally, claiming resources. A unique Non-Fungible Token (NFT) serves as proof of the supply, allowing the protocol to keep track of the user's entitled amount of LSU and earnings. For borrowers, the protocol offers flash loans - a feature that enables users to access liquidity instantly at low interest rates, thus facilitating profitable trades and taking advantage of market inefficiencies. This has made it possible for anyone to participate in DeFi markets in a more accessible and cost-effective way. Security The protocol is non-custodial and operates under the governance of smart contracts, offering transparency, security, and trust among all participants. Only the rightful owner can claim their portion of the pool's liquidity. Status Gable has shown no sign of activity since April 2024, on three independent measures read on 27 August 2026. - The website. gable.finance (https://gable.finance) is served and returns HTTP 200, but its homepage carries a Last-Modified date of 23 April 2024, so the published site has not changed in over two years. - The ledger. The site declares its dApp definition (/developers/frontend/04-dapp-definition-and-verification) at /.well-known/radix.json, and that account is registered on ledger under the name "Gable Finance" with the description "Gable is a decentralized liquidity market protocol". Its most recent committed transaction is dated 22 April 2024. - The code. The github.com/gable-finance (https://github.com/gable-finance) organisation holds two public repositories, neither archived. The last push to either was 13 December 2023. A site that answers is not a protocol that runs. Nothing here says the protocol was withdrawn or that deposited funds moved, only that the team stopped publishing, stopped committing, and stopped transacting within a day of each other in April 2024. Plans of record When the Radix Foundation announced Gable's Babylon Booster Grant on 21 November 2023 (https://www.radixdlt.com/blog/babylon-booster-grants-gable) , the team set out dated targets: stake volume at its validator reaching 30 million XRD (/contents/tech/core-protocols/xrd-token) by the end of February 2024, flash-loan usage above 20 transactions a day by the first quarter, distribution of the GAB token widened to roughly 1,000 holders, an airdrop campaign, a new web app, and a Gable V2 adding a stablecoin and collateralised lending. None of that can be checked against a later Gable statement, because there is none. The record of the project ends five months after the post. External links - gable.finance (https://gable.finance) , the protocol's site - Babylon Booster Grants: Gable (https://www.radixdlt.com/blog/babylon-booster-grants-gable) , the Radix blog, 21 November 2023 - github.com/gable-finance (https://github.com/gable-finance) - Gable on Telegram (https://t.me/gable_finance) See also - Radix ecosystem funding (/contents/history/radix-ecosystem-funding) , the grant programme Gable was funded under - Root Finance (/ecosystem/root-finance) , Radix lending market - Weft Finance (/ecosystem/weft-finance) , Radix lending and borrowing - Radix Engine (/contents/tech/core-protocols/radix-engine) , the asset-oriented layer flash loans build on ## Emberflow URL: https://radix.wiki/ecosystem/emberflow Updated: 2026-08-27 Summary: Emberflow is a healthcare technology company founded by Nathan Loranca, Danny Toro, and Peter Kim, and the creator of LifeBand , a protocol for exchan… Emberflow Type Healthcare technology company; creator of the LifeBand Protocol, a consent-driven patient-data exchange layer Status 🟠 Dormant as a Radix project. The company is trading and its site ( emberflow.org (https://www.emberflow.org) ) is actively maintained, but no page of it has mentioned Radix since at least August 2025 Founded 2022 Team Nathan Loranca (CEO), Peter Kim (CTO), Danny Toro (CFO) Category Infrastructure, health-data exchange Links Website (https://www.emberflow.org) · X (https://x.com/LifeBand_Tech) · Telegram (https://t.me/LifeBandProtocol) Emberflow is a healthcare technology company founded by Nathan Loranca, Danny Toro, and Peter Kim, and the creator of LifeBand, a protocol for exchanging patient health data between providers. It appeared in the Radix ecosystem (/ecosystem) during 2023, when it described itself as building decentralized applications on Radix. That framing is no longer present anywhere on the company's own site, and this page records both the Radix-era claims and what replaced them. Status Read on 27 August 2026, seven pages of emberflow.org (https://www.emberflow.org) (the homepage, About, Contact, Team, Blog, FAQ and LifeBand) total 3,943,265 bytes and contain the word Radix zero times, along with zero occurrences of "XRD", "Scrypto" and "blockchain". The site serves no /.well-known/radix.json, the file a Radix dApp publishes to claim its on-ledger identity, so nothing links the company to a dApp definition (/developers/frontend/04-dapp-definition-and-verification) on the network. Archived copies date the change. The homepage of 23 July 2023 (https://web.archive.org/web/20230723040334/http://emberflow.org/) names Radix twice and uses "decentralized" six times. The homepage of 31 August 2025 (https://web.archive.org/web/20250831172323/https://www.emberflow.org/) names Radix not at all, while still using "decentralized" five times. By 11 March 2026 (https://web.archive.org/web/20260311200415/https://www.emberflow.org/) the second word has gone as well. The company is not dormant; its Radix presence is. The status field on this page reads 🟠 Dormant because that is the closest of the four values this wiki's ecosystem directory offers. None of them means "still trading, no longer on Radix", which is what the evidence supports. LifeBand LifeBand is Emberflow's single product. As the company presents it in 2026, LifeBand Protocol is "a secure communication layer that integrates with existing EHR systems", designed to let healthcare providers exchange patient records in real time without replacing the electronic health record software they already run. The pitch is addressed to providers, EHR vendors, and interoperability partners, and rests on reducing administrative overhead, which the company puts at 15 to 25 per cent of healthcare spending, and on giving patients control over who may read their records. The 2023 presentation of the same product was different in kind. The archived homepage of 23 July 2023 (https://web.archive.org/web/20230723040334/http://emberflow.org/) described Emberflow as specialising in "developing decentralized applications (dApps) and web applications using the advanced Radix Distributed Ledger Technology (DLT)" and placed the company in the decentralized science (/contents/tech/core-concepts/decentralized-science-desci) movement. LifeBand was then described as anchoring medical records with smart contracts. Founding and Leadership Emberflow lists three founders: Nathan Loranca as CEO, Peter Kim as CTO, and Danny Toro as CFO. The company describes Loranca as having worked as a medical professional before moving into technology in 2020, Kim as a three-time winner of the Radix Scrypto Challenges (https://github.com/radixdlt/scrypto-challenges) , and Toro as bringing a finance background to the team. These biographical details come from the company's own material and this wiki has found no independent source for any of them. They are recorded here as claims made by Emberflow, not as verified fact, in line with this wiki's verifiability policy (/policy/verifiability) . External links - emberflow.org (https://www.emberflow.org) , the company's site - emberflow.org as archived on 23 July 2023 (https://web.archive.org/web/20230723040334/http://emberflow.org/) , the Radix-era homepage - Emberflow's LifeBand on Telegram (https://t.me/LifeBandProtocol) - @LifeBand_Tech on X (https://x.com/LifeBand_Tech) See also - Radix ecosystem (/ecosystem) , the project directory this page belongs to - dApp Definition and Wallet Verification (/developers/frontend/04-dapp-definition-and-verification) , the on-ledger identity a Radix project registers - Verifiability (/policy/verifiability) , the policy this page's unsourced claims are marked against ## DELPHIBETS URL: https://radix.wiki/ecosystem/delphibets Updated: 2026-08-26 Summary: DelphiBets is a decentralized prediction market interface built on Radix , billed as the first prediction market protocol exclusively on the network.… Type Decentralized prediction market Status 🟠 Dormant – app served at v1.5, no open markets (26 Aug 2026) Token $DPH Max supply 99,999,999 DPH Built on Radix (Babylon) (/contents/tech/releases/radix-mainnet-babylon) Website delphibets.com (https://delphibets.com/) X @delphibets (https://x.com/delphibets) DelphiBets is a decentralized prediction market (https://delphibets.com/) interface built on Radix (/contents/tech/core-protocols/xrd-token) , billed as the first prediction market protocol exclusively on the network. It uses a native token, $DPH, and rewards user participation and prediction accuracy. Status as measured Read on 26 August 2026, the app at delphibets.com (https://delphibets.com/) is still served and still reports itself as v1.5 in the footer, but its market book is empty: the Open filter returns "There are no Open bets", and the only route past the landing page is a wallet connection. The same page reports a lifetime volume of 6,964,221 XRD across all bets ever settled, which is the clearest single measure of how far the protocol got. The token tells the same story from the other side. $DPH was read on ledger the same day at epoch 338,430: a fungible resource of divisibility 18 with a total supply of exactly 99,999,999, and minter, burner, freezer and recaller all set to DenyAll with the rules locked. The cap in the tokenomics section below is therefore enforced by the resource itself: the full supply was minted at creation, and no one, the team included, can add to it, burn it or claw it back. DelphiBets UI showcase (video) (https://youtu.be/gAanVoK37CM) Etymology The name derives from the ancient city of Delphi, renowned in Greek mythology as the seat of the Oracle who made prophecies about the future. History DelphiBets was conceived as a platform where users could measure their predictive ability against others, with on-chain proof of successful predictions. It progressed through ideation, prototyping, community engagement, and Scrypto smart-contract development, launching alongside the Babylon (/contents/tech/releases/radix-mainnet-babylon) upgrade of Radix. In January 2024 the project secured the $15,000 Babylon Booster Grant (https://x.com/radixdlt/status/1750897102299754984) , one of the launch-stage awards from the Radix Booster Grants (/contents/history/radix-ecosystem-funding) program that funded the first wave of Babylon dApps. Tokenomics The native token, DPH, is used for participating in predictions, staking, and governance. Total supply is capped at 99,999,999 DPH, distributed as: - 40% – Incentives & Rewards - 24% – Airdrops & Sales - 24% – Team & Development - 8% – Marketing & Other - 4% – Advisors & Consultants DPH has been listed on Radix DEXes including Ociswap (/ecosystem/ociswap) , Astrolescent (/ecosystem/astrolescent) , CaviarSwap, and RadixPlanet. Staking and Governance Holders can stake DPH on DelphiNode to help secure the Radix network and receive regular DPH airdrops – larger during prediction events – and can participate in protocol governance. Team DelphiBets is built by a team spanning banking, Scrypto development, UX design, and law, advised by Ociswap co-founders Florian Pieper and Marco, both prominent figures in the German Radix community. Roadmap The roadmap – contingent on Radix's technical progress – targets oracle-service integration, participation incentives, expanded betting options, and community voting. External Links - DelphiBets – official app (https://delphibets.com/) - DelphiBets on X (https://x.com/delphibets) ## ASCENT URL: https://radix.wiki/ecosystem/ascent Updated: 2026-08-25 Summary: ASCENT is a token-based arcade game built around the Radix ecosystem. Players control a luminous orb that climbs through a live chart-inspired environ… OVERVIEW ASCENT (https://ascent.xrd.workers.dev) is a token-based arcade game built around the Radix ecosystem. Players control a luminous orb that climbs through a live chart-inspired environment, timing jumps, bounces, and movement to reach higher scores. The project connects gameplay with the on-ledger ASCENT token. As the token progresses, more of the game’s content and features can unlock. The game also supports Radix wallet connection for score saving, cosmetic ownership, and token-based interactions. Gameplay ASCENT is designed as a skill-based chart-riding game. The core loop is simple: climb as high as possible, avoid hazards, use momentum, and compete for leaderboard positions. The game includes free play and competitive modes. While wallet-connected players can access profile features, saved scores, inventory, and cosmetic customization. The game also includes live chart mechanics: ASCENT market activity is reflected visually in the game, and qualifying ASCENT buys, whether made in-game or on-chain, can trigger live boost effects that temporarily influence the gameplay experience for everyone playing live. In-Game Cosmetics, Burns & Rewards ASCENT includes wallet-linked cosmetics and achievement items. Most visual cosmetics, such as orb skins, trails, auras, and satellites, can be purchased with ASCENT through the in-game shop, while badges and some special orbs are earned through gameplay, events, achievements, or milestones. Cosmetic purchases act as token sinks: when ASCENT is spent in the shop, a portion is burned and permanently removed from circulation. These items personalize the player’s orb and profile but do not provide competitive advantages in ranked play. Token & Liquidity The $ASCENT token (https://dashboard.radixdlt.com/resource/resource_rdx1t46jpmzf97s7q5h4tv42hcjyalhq84znevngtsul5wcumxfdprnlp3) is the native token of the ASCENT game economy on Radix. ASCENT has graduated on RLY.fun (https://rly.fun) and trades through Radix ecosystem liquidity venues, including Ociswap (https://ociswap.com/resource_rdx1t46jpmzf97s7q5h4tv42hcjyalhq84znevngtsul5wcumxfdprnlp3) and Astrolescent (https://astrolescent.com/token/resource_rdx1t46jpmzf97s7q5h4tv42hcjyalhq84znevngtsul5wcumxfdprnlp3) , allowing users to swap assets for ASCENT from inside the game interface. Supply and the burn sink The token's authorities are locked: minting is permanently denied and can never be re-enabled, while burning is open to any holder, which is what lets the in-game shop destroy tokens when cosmetics are bought. Read from the ledger at epoch 338142 (25 August 2026, 19:07:04 UTC), total supply stands at 888,312,759.484262 ASCENT. That is the same number to the last decimal place as the epoch 334014 read taken on 11 August, so nothing was burned in the fourteen days between the two reads, a fortnight that covered the close of the OVERRIDE event and the opening of the ZENITH contest. The 72,376 tokens destroyed in the eight days to 11 August (down from the ~888,385,136 recorded here on 3 August, about 0.008% of supply) remain the only burn this page has measured. The sink works, and at present almost nothing is going into it. Events OVERRIDE (11–21 August 2026) On 11 August 2026 the developer announced OVERRIDE, a limited-time competitive mode described as a shoot-em-up crossed with a roguelike, opening the same day at 12:00 UTC ( project Telegram (https://t.me/ascent_xrd) , announcement on X (https://x.com/ASCENT_xrd/status/2087078635081511069) ). It runs for 10 days, split into five 48-hour rounds the announcement calls firmware. - Entry: a single 1,000 XRD pass buys ranked entry to the whole event. The developer states that 100% of the pass price is swapped for ASCENT and added to the prize pool. - Prize pool: starts at 3,000,000 ASCENT and grows with every additional participant. - Scoring: points scored in each 48-hour round stack into a single final leaderboard; the top 10 split the pool. The pass mechanic makes the event a second demand sink alongside the cosmetics burn – XRD in, ASCENT bought off the market and locked into the pool – though unlike the shop the pooled tokens are redistributed to players rather than destroyed. Result. OVERRIDE settled on 21 August 2026, and the payout was published in full to the project Telegram (https://t.me/ascent_xrd) and on X (https://x.com/ASCENT_xrd/status/2090783535611191532) . The pool finished at 6,000,000 ASCENT, double its announced starting size. Of that, 4.1M was paid out and 1.9M stayed in the rewards vault because ranks five to ten were never occupied: four players finished ranked against a prize table written for ten. SKRUTEK took 1.5M ASCENT, VIBES 1.1M and AL 845,700, with fourth place unnamed in the announcement. A further 1.5M ASCENT was returned to a player who had bought the 1,000 XRD pass more than once. A paid competitive mode that pays out two thirds of its pool and refunds a quarter of it is the clearest published measure of how many people the mode actually reached. ZENITH (24–30 August 2026) On 24 August 2026 the developer opened a second contest, announced in the project Telegram (https://t.me/ascent_xrd) as TIER 2 · ZENITH and closing on 30 August at 12:00 UTC. It runs in Classic mode and, unlike OVERRIDE, has no entry pass and no announced player contribution to the pool: the prizes are fixed at 500,000 ASCENT for first place, 250,000 for second and 100,000 for third. The lead changed hands three times in the first 48 hours; at the 25 August standing the leader was SKRUTEK on 11,951 points, ahead of BESTPLAY on 6,601 and PLAYER67 on 6,578. The three names at the top are the same three that placed in OVERRIDE, which is worth reading alongside the burn figure above. External Links - ASCENT : Play (https://ascent.xrd.workers.dev) - ASCENT : Telegram (https://t.me/ascent_xrd) - $ASCENT : Radix Dashboard (https://dashboard.radixdlt.com/resource/resource_rdx1t46jpmzf97s7q5h4tv42hcjyalhq84znevngtsul5wcumxfdprnlp3) - $ASCENT on Ociswap (https://ociswap.com/resource_rdx1t46jpmzf97s7q5h4tv42hcjyalhq84znevngtsul5wcumxfdprnlp3) - $ASCENT on Astrolescent (https://astrolescent.com/token/resource_rdx1t46jpmzf97s7q5h4tv42hcjyalhq84znevngtsul5wcumxfdprnlp3) Type Token-Based Arcade Game Symbol ASCENT Status Active (graduated) Website ascent.xrd.workers.dev (https://ascent.xrd.workers.dev) Category GameFi Network Radix Mainnet Total Supply 888,312,759.48 ASCENT (unchanged 11 Aug to 25 Aug 2026; minting permanently denied, burn open) Launchpad rly.fun (https://rly.fun) ## Radstakes URL: https://radix.wiki/ecosystem/radstakes Updated: 2026-08-25 Summary: Status note (August 2026): this page previously said Radstakes was closed, on the strength of its offline website. The validator is registered and pro… Type XRD staking validator node Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Active (validator registered; website offline) Founded 2021 Validator validator_rdx1sw5…ukjegy8 (https://dashboard.radixdlt.com/validator/validator_rdx1sw5zkx2h6hp6k0js6dqaaxpz4580awncmm0rlzv7ufcf97cukjegy8) Stake 99,768,918.19 XRD (rank 14 of 188 registered, 10 Aug 2026) Fee 15%, rising to 25% at epoch 335294 — about 16 August 2026 Uptime 100% (trailing month) Token $rst — fixed supply 1,000,000 Website radstakes.com (offline) Status note (August 2026): this page previously said Radstakes was closed, on the strength of its offline website. The validator is registered and producing (https://dashboard.radixdlt.com/validator/validator_rdx1sw5zkx2h6hp6k0js6dqaaxpz4580awncmm0rlzv7ufcf97cukjegy8) , as the On-ledger status section records. The website and the delegation platform described in the historical sections are what have gone; the node has not. Radstakes was a staking service founded by Faraz Abulhawa. The service offered a secure and reliable infrastructure for users to delegate their Radix native token $XRD and participate in the staking process. Overview Radstakes had been operating a validator node in the top 100 since the mainnet launch, with prior testing on Betanet and Stokenet. Radstakes emphasized the importance of security, decentralization, and performance in their validator operations. They strove to contribute to the security and decentralization of the Radix network by encouraging users to delegate their $XRD tokens to their validator node. Staking with Radstakes offered benefits such as potential staking rewards and participation in securing the Radix network. By staking with Radstakes, users could actively support the operation and growth of the Radix ecosystem while earning rewards for their contributions Source: Radstakes Blog - Radstakes Partners with Radix Planet Product The products offered by Radstakes included stake delegation services, secure infrastructure with high uptime and dedicated servers, high availability and DDoS protection, as well as backup validator nodes to ensure maximum uptime and staking rewards. Mission The mission of Radstakes was to provide a trustworthy and secure staking service to the Radix network, allowing users to participate in the network's consensus protocol and earn staking rewards. Radstakes aimed to contribute to the security and decentralization of the Radix network by operating as a reliable validator and promoting community engagement. Benefits Using Radstakes offered several benefits. By delegating tokens to a reliable validator, users can participate in the staking process without the need for technical expertise or setting up their own infrastructure. Stakers also have the opportunity to earn staking rewards, which can be a passive income stream from holding and delegating their $XRD tokens. Additionally, by participating in staking, users contribute to the security and decentralization of the Radix network. Staking Process The staking process with Radstakes typically involved the following steps: Connect your Wallet Begin by connecting your wallet that holds your Radix native token ($XRD). Radstakes supported various wallets, and you would need to connect your preferred wallet to the Radstakes platform. Delegate your $XRD Tokens Delegation was done through the Radstakes platform. Monitor Staking Rewards As you delegated your $XRD tokens to Radstakes, you became eligible to receive staking rewards. These rewards are typically distributed based on factors such as the number of tokens you have delegated and the duration of the delegation. You could monitor your staking rewards through the Radstakes platform or your connected wallet. Manage Delegation Radstakes provided tools to manage your delegation. You may have the flexibility to adjust your delegation amount, claim staking rewards, or withdraw your delegated tokens if needed. These management functions may vary based on the specific features offered by Radstakes. Security and Trust In terms of security, Radstakes aimed to provide a secure infrastructure for staking operations. They utilized high uptime secure dedicated servers with DDoS protection and backup validator nodes to ensure maximum uptime and security. However, it's important for users to exercise caution and conduct their own due diligence when choosing a validator and participating in staking activities. On-ledger status (August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) on 6 August 2026 at epoch 332670, the Radstakes validator (https://dashboard.radixdlt.com/validator/validator_rdx1sw5zkx2h6hp6k0js6dqaaxpz4580awncmm0rlzv7ufcf97cukjegy8) is registered, accepts delegated stake, holds 99,875,144.75 XRD — rank 14 of the 188 registered validators by stake — and recorded 100% uptime over the trailing month. Its on-ledger metadata still carries the description “Official Radstakes validator est. 2021”. Stake units are issued as resource_rdx1t49…lv5qajv and unstake claims as resource_rdx1nfw…u3dfzjl. The ledger also records something an offline website cannot: a pending fee change. The stored fee factor is 15%, and a fee-change request raising it to 25% takes effect at epoch 335294 — roughly nine days after this reading, at the ledger’s recent pace of about 288 epochs a day. Registering that request requires a transaction signed with the validator’s owner badge, which is held by a component rather than a plain account. The $rst token named in this page’s metadata ( resource_rdx1t56…28knul (https://dashboard.radixdlt.com/resource/resource_rdx1t56e5z78yxa5shrhu352pk9uczkwj2zqe6fdhy9hgj9058a028knul) , described on-ledger as “Official token of the Radstakes validator”) is a fungible resource with 18 decimals and a fixed total supply of 1,000,000. Its mint, burn, freeze and recall authorities are every one deny_all and the rule set is locked, so the supply can never change and no authority can later be granted. What has genuinely gone is the web presence: radstakes.com returns a Wix “ConnectYourDomain” error page (HTTP 404) rather than a site, so the delegation platform and blog described in the sections below no longer exist. Delegating to the node does not need them — a validator (/contents/tech/core-concepts/staking) is reachable from any Radix wallet by address. Re-read at epoch 333630 (10 August 2026) Four days on, the request is still pending and unchanged: stored fee factor 0.15, requested factor 0.25, effective epoch 335294. Stake has moved only slightly, to 99,768,918.19 XRD, holding rank 14 of the 188 registered validators; the trailing-30-day proposal record is 271,069 made against 2 missed. The gap to the effective epoch is 1,663 epochs. Measured over the preceding month — epoch 325,000 at 11 July 03:54 UTC to epoch 333,630 at 10 August 03:04 UTC — mainnet has run at exactly 288.0 epochs a day, which puts the increase at about 16 August 2026. The request is also, at this reading, the only pending fee-change request on the entire register. Of the 188 registered validators, 63 carry a fee-change request whose effective epoch has already passed — they are charging a fee different from their stored factor — and exactly one, Radstakes, carries a request that has not yet taken effect. That asymmetry is the point of the delay: a fee increase cannot apply for num_fee_increase_delay_epochs = 4,032 epochs, about two weeks, so this request must have been registered around epoch 331,262, near the start of August. A decrease applies at the beginning of the next epoch, with no notice at all. The two weeks are the window delegators are given to leave, and roughly six days of it remain. ## Scrypto Developer Event URL: https://radix.wiki/contents/history/scrypto-developer-event Updated: 2026-08-25 Summary: The Scrypto Developer Event was the first Radix event given over wholly to Scrypto developers, and the first held in Europe, announced on 16 March 202… Scrypto Developer Event Type In-person developer workshop Organizer RDX Works (Builders Team) Date 9 April 2022 Venue Sud Hall, Lisbon, Portugal Focus Scrypto (/contents/tech/core-protocols/scrypto-programming-language) blueprints & components Category History (/contents/history) Media YouTube recording (https://www.youtube.com/watch?v=bo5LQW5hATQ) The Scrypto Developer Event was the first Radix event given over wholly to Scrypto developers, and the first held in Europe, announced on 16 March 2022 (https://www.radixdlt.com/blog/scrypto-developer-event-lisbon) and held by RDX Works at Sud Hall in Lisbon, Portugal, on 9 April 2022. It was not the first in-person Scrypto workshop: that was the Alexandria Preview Event (/contents/history/alexandria-preview-event) in New York five months earlier, where Scrypto was first shown hands-on and its first release published the same afternoon. It introduced developers to Scrypto (/contents/tech/core-protocols/scrypto-programming-language) and Radix’s asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) approach to building smart contracts. Format The programme below is the one published in advance, the announcement being the only detailed record of the day this wiki can cite. It ran from registration and breakfast at 09.00 through an opening “Why DeFi is the Future” talk, two hands-on workshop sessions either side of lunch, a 16.00 closing talk billed as “Inspire Devs to keep building”, and an open Q&A from 17.00 to 18.00. The workshops were run by the RDX Works Builders Team, taking attendees through the basics of Scrypto and on to writing simple blueprints (/contents/tech/core-concepts/blueprints-and-packages) and components (/contents/tech/core-concepts/components) in the afternoon. Each participant took home a Scrypto developer box, prizes were awarded for completing workshop tasks, and – for those who could not attend in person – the event was live-streamed and recorded (https://www.youtube.com/watch?v=bo5LQW5hATQ) , with questions for the closing Q&A submitted by smartphone from home. The day closed with a social gathering at the venue, hosted by the Radix community in Lisbon and RSVP'd separately from the workshops themselves. Significance Attendees worked with Scrypto v0.3.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v0.3.0) , released on 16 February 2022 and current on the day; v0.4.0 (https://github.com/radixdlt/radixdlt-scrypto/releases/tag/v0.4.0) followed eighteen days after the event, on 27 April. That was still more than a year before Scrypto reached production with the Babylon mainnet (/contents/tech/releases/radix-mainnet-babylon) , but it was released software rather than the preview build handed out in New York. The Lisbon event carried forward a template the Alexandria Preview Event (/contents/history/alexandria-preview-event) had set, and it runs on through the Austin Developer Event (/contents/history/austin-developer-event) , the university DApp In a Day (/contents/history/dapp-in-a-day-workshop-1) workshop series, and remote hackathons such as the Scrypto DeFi Challenge (/contents/history/scrypto-defi-challenge) . External links - Scrypto Developer Event – Lisbon (Radix Blog) (https://www.radixdlt.com/blog/scrypto-developer-event-lisbon) - Lisbon Scrypto Event 2022 Highlights – YouTube (https://www.youtube.com/watch?v=bo5LQW5hATQ) ## Decentralized Finance (DeFi) URL: https://radix.wiki/contents/tech/core-concepts/decentralized-finance-defi Updated: 2026-08-24 Summary: Decentralized Finance , commonly referred to as DeFi is an umbrella term for a variety of financial applications in blockchain or cryptocurrency geare… Decentralized Finance, commonly referred to as DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) is an umbrella term for a variety of financial applications in blockchain or cryptocurrency geared towards disrupting traditional financial intermediaries. Overview Unlike the traditional finance sector, which operates through centralized systems governed by institutions such as banks and governments, DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) is built on blockchain technology, ensuring operations are decentralized, transparent, and resistant to censorship. The inception of DeFi is rooted in the philosophy of eliminating the control that banks and governmental institutions have over money, financial products, and financial services. In traditional finance, these entities can influence the economy by printing more money, regulating transactions, and even denying individuals access to financial services. This centralized control not only poses a risk of censorship but also introduces a layer of trust and potential failure that DeFi aims to mitigate. DeFi operates on the premise that individuals should have unrestricted access to their funds and financial services without the need for intermediaries, based purely on transparent and immutable code. DeFi leverages smart contract networks such as Ethereum (/contents/tech/comparisons/radix-vs-ethereum) or Radix, to execute financial transactions and services. These smart contracts are self-executing contracts with the terms of the agreement between buyer and seller being directly written into lines of code. This automation not only reduces the need for traditional financial intermediaries but also offers a higher degree of security and trust, as the outcomes are not controlled by any single entity and can be audited by anyone. Moreover, DeFi promises to make financial services more accessible and affordable. Traditional financial systems are known for their high fees, from the cost of borrowing to transaction fees. DeFi, on the other hand, operates with minimal fees as it removes the overhead associated with financial institutions. This democratization of finance has the potential to include unbanked populations worldwide by offering them access to a full spectrum of financial services. In essence, DeFi is not just a new set of tools and technologies but a bold reimagining of finance. It challenges the centralized financial system by offering a decentralized, transparent, and inclusive alternative. While it's still in its early stages, DeFi has already begun to show how it can transform financial services by making them more accessible, less expensive, and more equitable for everyone. Foundations of DeFi DeFi is built upon a trio of foundational technologies: cryptography, blockchain technology, and smart contracts. Each plays a crucial role in ensuring that DeFi applications are secure, transparent, and operate without the need for centralized intermediaries. Understanding these foundations is essential for grasping how DeFi works and appreciates its potential to revolutionize the financial sector. Cryptography Cryptography is the practice of secure communication in the presence of third parties. In the context of DeFi, it is used to ensure the security and privacy of transactions on the blockchain. Cryptography enables the creation of cryptographic keys, digital signatures, and encryption, providing the means for secure peer-to-peer transactions without the need for a trusted third party. It ensures that transactions are tamper-proof and that participants can transact securely and anonymously, if they choose. Blockchain Technology Blockchain technology is the backbone of DeFi. It is a distributed ledger technology that allows data to be stored across a network of computers worldwide, making it decentralized and resistant to censorship. Each block in the chain contains a number of transactions, and once a block is added to the chain, the information it contains is immutable. This ensures the integrity and transparency of financial transactions. Blockchain's decentralized nature means that it operates on a peer-to-peer network, eliminating the need for central authorities like banks and governments, thus fostering a new era of financial transactions that are open, transparent, and accessible to anyone with an internet connection. Smart Contracts Smart contracts are self-executing contracts with the terms of the agreement directly written into code. They run on blockchain networks, with Ethereum (https://ethereum.org) being the most prominent platform for DeFi applications. Smart contracts automatically execute transactions when predetermined conditions are met, without the need for intermediaries. This automation reduces the potential for human error and fraud, significantly lowering transaction costs and execution times. Smart contracts are the mechanism through which DeFi applications offer services such as lending, borrowing, trading, and insurance, all without the need for traditional financial institutions. Importance The combination of cryptography, blockchain technology, and smart contracts forms the technological bedrock upon which DeFi is built. These technologies together provide a secure, transparent, and efficient framework for conducting financial transactions and services. By leveraging these foundations, DeFi applications can offer a wide range of financial services that are accessible to anyone, anywhere, at any time, without the barriers and costs associated with the traditional financial system. In summary, the foundations of DeFi represent a paradigm shift in how financial services can be designed, deployed, and used. By understanding these underlying technologies, one can better appreciate the transformative potential of DeFi to create a more inclusive, efficient, and secure financial system. Stablecoins Stablecoins occupy a pivotal role in the ecosystem of DeFi, acting as a crucial bridge between the volatile cryptocurrency markets and the predictable value of traditional fiat currencies. They are designed to maintain a stable value over time, typically pegged to a specific fiat currency like the US dollar, or to other assets such as gold. This stability is essential for facilitating everyday transactions, lending, borrowing, and other financial activities within the DeFi space without the wild price fluctuations associated with typical cryptocurrencies. Definition and Mechanism Stablecoins are a type of cryptocurrency that aims to offer price stability by being pegged to a reserve asset. The most common approach is to tie the value of a stablecoin to a widely recognized fiat currency, such as the US dollar, at a 1:1 ratio. This peg is maintained through various mechanisms, including fiat-collateralized reserves, crypto-collateralized reserves, or algorithmic formulas that automatically adjust supply based on changes in demand. Examples of Stablecoins - $DAI: An Ethereum-based stablecoin that maintains its value close to one US dollar through overcollateralization with other cryptocurrencies. It is governed by the MakerDAO (https://makerdao.com) protocol. - Tether ($USDT): One of the first and most widely used stablecoins, Tether claims to be backed by US dollars held in reserve, offering a stable medium for transactions. - USD Coin ($USDC): A fully fiat-collateralized stablecoin, $USDC is managed by the Centre consortium, co-founded by Circle and Coinbase, providing a transparent and regulated entity that ensures every $USDC is backed by a dollar held in reserve. Importance in DeFi Stablecoins serve several critical functions in the DeFi ecosystem: - Medium of Exchange: They provide a stable and predictable medium of exchange for trading, lending, and other financial transactions, mitigating the risk of volatility associated with traditional cryptocurrencies. - Bridge to Traditional Finance: Stablecoins offer a direct connection between DeFi and the traditional financial system, allowing for the seamless transfer of value between the two worlds. - Liquidity and Accessibility: By offering a stable value, they encourage greater participation in the DeFi space, providing liquidity and making it more accessible to users unfamiliar with or wary of the volatility in the crypto market. - Enabler of Financial Services: Stablecoins enable a wide range of financial services within DeFi, including lending, borrowing, yield farming, and insurance, by providing a reliable unit of account and store of value. Use Cases and Benefits One of the key benefits of stablecoins is the facilitation of quick and inexpensive international transfers, bypassing traditional banking fees and exchange rates. They also enable users to lock in profits from trading activities without needing to convert assets back to fiat currency, maintaining their holdings within the crypto ecosystem. Furthermore, in regions with unstable currencies or restrictive financial systems, stablecoins offer a secure and stable means of preserving value. In summary, stablecoins are an essential component of the DeFi ecosystem, providing stability, security, and connectivity between the volatile world of cryptocurrencies and the more stable realm of traditional fiat currencies. Their role in enabling a broad array of financial services underscores the transformative potential of DeFi to offer accessible, efficient, and inclusive financial solutions. Borrowing and Lending Borrowing and lending represent fundamental pillars of the financial ecosystem, and in the realm of DeFi, these activities have been reimagined to leverage the transparency, security, and efficiency afforded by blockchain technology. DeFi platforms facilitate peer-to-peer lending and borrowing, eliminating traditional financial intermediaries and offering new opportunities for yield generation, liquidity, and financial management. Mechanism In DeFi, borrowing and lending are primarily facilitated through smart contracts on blockchain platforms. These contracts automate the terms and conditions of financial transactions, ensuring that they are executed exactly as agreed upon by the parties involved. This setup introduces a high degree of transparency and trust, as all transactions are recorded on the blockchain and are verifiable by anyone. Over-Collateralization A distinctive feature of DeFi lending and borrowing is the requirement for over-collateralization. Due to the volatility of cryptocurrencies and the anonymity of transactions, borrowers must usually deposit collateral exceeding the value of their loan. This mechanism protects lenders against default and market fluctuations, ensuring that the loan can be recovered even if the borrower fails to repay. Platforms and Protocols Several platforms and protocols have emerged as leaders in the DeFi borrowing and lending space, including: - Compound: A decentralized protocol that allows users to earn interest on deposits and borrow assets against collateral. - Aave: Another popular platform that offers innovative features like flash loans (https://aave.com/docs/aave-v3/guides/flash-loans) – instant, uncollateralized loans that must be repaid in the same transaction. - MakerDAO: Known for its stablecoin, DAI, MakerDAO enables users to generate DAI against their cryptocurrency collateral, effectively taking out a loan. Benefits - Accessibility: DeFi lending and borrowing platforms are accessible to anyone with an internet connection, regardless of geographic location or financial status. - Transparency: All transactions are recorded on the blockchain, providing a transparent record of lending terms, interest rates, and repayments. - Efficiency: Smart contracts automate the lending and borrowing processes, reducing the time and cost associated with these transactions. - Yield Opportunities: Lenders can earn passive income on their cryptocurrency holdings, often at rates higher than those offered by traditional banks. Flash Loans Flash loans are a unique and innovative DeFi feature allowing borrowers to access substantial liquidity without collateral, under the condition that the loan is repaid within the same transaction block. This mechanism enables sophisticated arbitrage, market making, and self-liquidation strategies that were previously impossible in traditional finance. Risks and Considerations While DeFi lending and borrowing offer significant advantages, they also come with risks, including smart contract vulnerabilities, market volatility, and the potential for liquidation if collateral values drop. Users must conduct thorough research and exercise caution when participating in these activities. Decentralized Exchanges (DEXes) Decentralized Exchanges (DEXes) are a cornerstone of the DeFi ecosystem, facilitating the permissionless trading of cryptocurrencies without the need for a centralized authority. Unlike traditional exchanges, which act as intermediaries between buyers and sellers, DEXes operate on blockchain technology, leveraging smart contracts to enable direct peer-to-peer transactions. Functionality and Operation DEXes utilize liquidity pools rather than traditional order books to facilitate trading. In a liquidity pool, users lock assets into a smart contract to provide market liquidity. Traders then buy and sell cryptocurrencies directly from these pools. Prices in a DEX are determined algorithmically, based on the ratio of assets in the liquidity pool, ensuring that the market remains liquid and trading can occur at any time without the need for a matching buyer or seller. Advantages of DEXes - Decentralization: By operating on a decentralized network, DEXes eliminate the risk of a single point of failure and reduce susceptibility to hacking, fraud, and regulatory interference. - Anonymity: Users can trade directly from their cryptocurrency wallets without needing to disclose their identity, offering greater privacy. - Accessibility: DEXes are accessible to anyone with an internet connection, removing barriers to entry for users worldwide. - Innovation: The open and permissionless nature of DEXes fosters innovation, allowing for the listing of a wide range of tokens, including those from emerging projects. Popular Decentralized Exchanges - Uniswap (https://uniswap.org) : One of the most popular DEXes on the Ethereum blockchain, Uniswap uses an automated market maker (AMM) model to provide liquidity and facilitate trading. - PancakeSwap: A leading DEX on the Binance Smart Chain, offering similar functionalities to Uniswap but with lower transaction fees. - SushiSwap: Initially a fork of Uniswap, SushiSwap has introduced additional features and incentives for liquidity providers and traders. Challenges and Considerations While DEXes offer numerous benefits over their centralized counterparts, there are also challenges to consider: - User Experience: The interface and trading experience on DEXes can be less intuitive for users accustomed to traditional exchanges, potentially deterring mainstream adoption. - Slippage: In markets with low liquidity, large orders can significantly impact prices, leading to slippage and less favorable trade executions. - Smart Contract Risks: As DEXes operate on smart contracts, any vulnerabilities in the contract code can be exploited, posing a risk to users' funds. The Role of DEXes in DeFi DEXes play a crucial role in the DeFi ecosystem by enabling decentralized trading, fostering financial inclusion, and promoting a new era of financial sovereignty. They serve as a testament to the power of blockchain technology in creating more open, transparent, and equitable financial systems. As the DeFi space continues to evolve, DEXes are likely to see further innovation and adoption, challenging traditional financial markets and paving the way for a decentralized financial future. Insurance In the traditional financial world, insurance is a key component of risk management, providing a safety net against unexpected losses. DeFi brings this concept into the blockchain, offering decentralized insurance solutions that leverage smart contracts to automate claims and payouts. This innovation aims to increase transparency, reduce costs, and expand accessibility to insurance products. Mechanism and Benefits DeFi insurance utilizes blockchain technology to manage and execute insurance policies without the need for centralized insurance companies. Smart contracts automatically enforce policy conditions, execute claims, and manage payouts based on predefined rules and triggers. This automation reduces administrative costs and the potential for human error or bias, making the claims process faster and more efficient. The transparency inherent in blockchain technology also plays a crucial role. Policy terms, conditions, and transactions are recorded on a public ledger, providing clear, indisputable records of agreements and transactions. This transparency builds trust among participants and can significantly streamline dispute resolution. Key Features of DeFi Insurance - Customizable Coverage: Users can tailor coverage to their specific needs, choosing from a variety of risks and parameters. - Immediate Payouts: Smart contracts can trigger automatic payouts upon the occurrence of a predefined event, eliminating the waiting period associated with traditional insurance claims. - Access to Underserved Markets: DeFi insurance can provide coverage for risks that are underserved or ignored by traditional insurers, including smart contract failures, exchange hacks, and crypto wallet thefts. Examples of DeFi Insurance Platforms - Nexus Mutual: A decentralized insurance protocol that allows members to pool and share risk. It offers coverage against smart contract failures, which is a significant concern in the blockchain space. - Etherisc: A platform that aims to decentralize insurance applications, allowing developers to build their own insurance products on the blockchain. - Opyn: Provides options-based insurance, allowing DeFi users to hedge against $ETH price drops and other DeFi risks. Challenges and Future Prospects While DeFi insurance holds promising potential, it also faces several challenges, including regulatory uncertainty, the complexity of assessing and pricing blockchain-based risks, and the need for more widespread understanding and adoption. Additionally, the nascent state of DeFi insurance means the market is still developing, with limited data on risk assessment and claims history. Despite these challenges, DeFi insurance represents a significant step forward in democratizing access to financial services. By leveraging blockchain technology, DeFi insurance can offer more transparent, efficient, and inclusive alternatives to traditional insurance, potentially transforming how we manage risk. As the DeFi ecosystem continues to mature, it is expected that DeFi insurance will evolve to address a broader range of risks, attract more users, and integrate more deeply with other DeFi services. This evolution will likely include more sophisticated risk assessment models, enhanced regulatory clarity, and innovative insurance products that further leverage the benefits of DeFi. Margin Trading Margin trading is a critical financial tool that allows traders to leverage their positions, amplifying both potential profits and risks. Within the context of DeFi, margin trading has been redefined to operate on blockchain technology, offering a decentralized approach to leverage and short selling without the need for traditional brokerage houses. Overview In DeFi, margin trading involves borrowing funds to increase the size of a trading position beyond what would be possible with one's own capital alone. This mechanism allows traders to amplify their exposure to market movements, potentially increasing their profits from successful trades. However, it also increases the potential for significant losses, making it a high-risk strategy. How DeFi Margin Trading Works DeFi platforms facilitate margin trading through smart contracts, which automate the borrowing, trading, and settlement processes. Traders can leverage their positions by using cryptocurrencies as collateral to borrow additional funds. This process is typically done in a decentralized manner, with the terms of the leverage, interest rates, and liquidation thresholds all encoded within smart contracts. Key Components of DeFi Margin Trading - Leverage: The ratio of borrowed funds to the trader's own investment. Higher leverage increases potential returns but also risks. - Collateral: The assets deposited by the trader to secure the borrowed funds. In DeFi, collateral is often in the form of cryptocurrency. - Liquidation: If the value of the collateral falls below a certain threshold due to adverse market movements, the position may be automatically liquidated to repay the borrowed funds. Advantages of DeFi Margin Trading - Accessibility: DeFi platforms offer global access to margin trading without the need for traditional brokerage accounts, making it easier for individuals to participate. - Transparency: The use of blockchain technology ensures that all transactions and positions are recorded transparently, providing clear visibility into market operations. - Autonomy: Traders retain control over their funds until the point of trade execution, reducing the risk of third-party mismanagement or interference. Risks and Considerations Margin trading in DeFi, while offering significant opportunities, comes with substantial risks, particularly due to the volatility of cryptocurrency markets. The possibility of rapid price movements can lead to swift liquidation of leveraged positions, resulting in significant losses. Moreover, the complexity of smart contracts and the potential for bugs or vulnerabilities add another layer of risk. Future Outlook As the DeFi ecosystem continues to evolve, margin trading platforms are becoming more sophisticated, offering advanced features such as isolated margin accounts, cross-margin trading, and more diverse lending pools. These developments could attract a wider range of traders and investors, further integrating DeFi margin trading into the broader financial landscape. Advantages of DeFi DeFi offers a suite of advantages over traditional financial systems. These benefits stem from DeFi's foundational use of blockchain technology, which enables more open, transparent, and accessible financial services. Here are some of the key advantages of DeFi: Accessibility and Inclusivity - Global Access: DeFi services are available to anyone with an internet connection, removing geographical barriers to financial services. This global accessibility ensures that individuals in underserved or unbanked regions can participate in the financial ecosystem. - 24/7 Availability: Unlike traditional financial institutions that operate during business hours, DeFi platforms are available around the clock, providing continuous access to financial services. Transparency and Security - Transparent Operations: All transactions and smart contract rules in DeFi are recorded on the blockchain, providing a transparent ledger that anyone can inspect. This openness fosters trust among users and makes the system more resistant to fraud. - Enhanced Security: By distributing data across a blockchain network, DeFi reduces the risk of hacking and fraud associated with centralized databases. The cryptographic security of blockchain further ensures the safety of assets and transactions. Censorship Resistance and Control - Censorship Resistance: DeFi operates without central control, making it difficult for any single entity to freeze accounts or block transactions. This ensures that users retain complete control over their assets. - User Sovereignty: DeFi gives users full control over their financial activities, from trading and lending to borrowing and saving. This autonomy contrasts sharply with the traditional financial system, where institutions often have the final say. Reduced Costs and Efficiency - Lower Fees: By eliminating intermediaries, DeFi significantly reduces the fees associated with financial transactions. This cost efficiency is particularly beneficial for small transactions that would be otherwise uneconomical in the traditional banking system. - Efficient Markets: DeFi platforms facilitate faster transactions and settlements than traditional financial systems, thanks to the automation provided by smart contracts. This efficiency can lead to more dynamic and responsive financial markets. Innovation and Financial Democratization - Rapid Innovation: The open-source nature of DeFi platforms encourages continuous innovation, with developers freely building on existing protocols to create new financial products and services. - Financial Democratization: DeFi levels the playing field, allowing retail investors to access financial instruments and opportunities that were previously available only to institutions or high-net-worth individuals. Disadvantages of DeFi While DeFi offers numerous advantages that challenge the traditional financial system, it also comes with its set of disadvantages and challenges. Understanding these drawbacks is crucial for users and developers alike to navigate the DeFi space responsibly and to work towards mitigating these issues. Technical Complexity and Usability - Steep Learning Curve: DeFi platforms often have complex interfaces and require a good understanding of blockchain technology, which can be daunting for newcomers. - Usability: The user experience (UX) in many DeFi platforms can be less intuitive compared to traditional financial services, potentially hindering wider adoption. Security Risks - Smart Contract Vulnerabilities: Despite the security benefits of blockchain, DeFi is still prone to risks associated with bugs or exploits in smart contract code, leading to significant losses. - Lack of Regulation: The largely unregulated nature of DeFi can expose users to scams, frauds, and other malicious activities without the safeguard of regulatory protection. Market Volatility and Liquidity Issues - High Volatility: The DeFi market is known for its high volatility, which can lead to significant price swings and liquidity issues, affecting the stability and predictability of investments. - Liquidity Concerns: Some DeFi platforms and tokens may suffer from low liquidity, making it difficult to execute large transactions without impacting the market price. Scalability and Performance - Network Congestion: Popular blockchain networks that host DeFi services, like Ethereum, can become congested, leading to slow transaction times and high fees, especially during peak usage. - Scalability Challenges: Current blockchain technology may struggle to scale efficiently to meet the demands of global finance, potentially limiting DeFi's growth and adoption. Regulatory and Legal Uncertainty - Regulatory Ambiguity: The rapidly evolving nature of DeFi and its innovative financial products often outpace current regulatory frameworks, leading to uncertainty and potential future crackdowns. - Compliance Risks: Users and service providers may inadvertently violate financial regulations due to the cross-jurisdictional nature of blockchain, posing legal risks. Interoperability and Integration - Limited Interoperability: While strides are being made, DeFi protocols and platforms still face challenges in interoperability, making it difficult for various services to work seamlessly together. - Integration with Traditional Finance: The integration of DeFi with traditional financial systems remains complex, limiting the potential for broader financial inclusion and efficiency gains. Future Outlook of DeFi The future of DeFi is at the intersection of innovation, regulatory evolution, and increasing mainstream adoption. As DeFi continues to mature, it faces both opportunities for exponential growth and challenges that must be navigated carefully. Here's an exploration of what the future may hold for DeFi: Continued Growth and Innovation - Innovative Financial Products: The DeFi ecosystem is likely to continue its trajectory of rapid innovation, introducing more sophisticated financial instruments that mimic and improve upon traditional finance, including more complex derivatives and insurance products. - Cross-chain and Layer 2 Solutions: To address scalability and interoperability issues, DeFi is expected to increasingly adopt cross-chain technologies and Layer 2 solutions, enabling faster transactions, reduced fees, and seamless interaction between different blockchains. Integration with Traditional Finance - Institutional Adoption: As DeFi proves its value proposition, more institutional investors are expected to enter the space, bringing in significant capital and potentially stabilizing the market. - Hybrid Models: There may be a rise in hybrid finance (HyFi) models that blend the best aspects of traditional finance (TradFi) and DeFi, offering users the advantages of both worlds. Regulatory Clarity and Compliance - Regulatory Frameworks: The development of clear regulatory frameworks tailored to DeFi's unique characteristics is crucial. Regulatory clarity will likely lead to greater adoption by reducing the risks associated with legal uncertainties. - Self-Regulation and Compliance Tools: The DeFi community may develop more robust self-regulatory practices and compliance tools, making it easier for DeFi projects to adhere to global financial regulations. Enhanced Security Measures - Improved Security Protocols: Ongoing efforts to enhance the security of smart contracts and DeFi platforms will be critical in minimizing risks associated with hacks and exploits. - Insurance Mechanisms: The expansion of DeFi insurance products will provide users with protection against potential losses, increasing trust in the ecosystem. User Experience and Accessibility - Simplified User Interfaces: Efforts to improve the user experience (UX) of DeFi platforms will be key in making DeFi more accessible to a broader audience, including those less familiar with blockchain technology. - Education and Awareness: Increased educational initiatives will play a vital role in bridging the knowledge gap, enabling more users to safely navigate the DeFi space. Global Financial Inclusion - Expanding Access: By continuing to lower barriers to entry, DeFi has the potential to further enhance global financial inclusion, providing underserved populations with access to financial services previously out of reach. Radix: The Full Stack for DeFi Radix is a groundbreaking approach to DeFi, which is designed for a future where DeFi becomes a part of everyone's daily life. Through a decade of diligent research, testing, and development, Radix has introduced a suite of custom technologies that seamlessly integrates a wallet, a unique programming language, an efficient execution environment, and a novel consensus algorithm. This comprehensive integration, known as the "Radix Full Stack," sets Radix apart as a radically innovative platform in the DeFi space. The Radix Wallet (/contents/tech/core-protocols/radix-wallet) : Enhancing User Experience The Radix Wallet (/contents/tech/core-protocols/radix-wallet) introduces a paradigm shift in how users interact with DeFi transactions. It aims to address the common issue of complex and confusing transaction approvals in the Web3 ecosystem by providing a user-friendly, understandable preview of transactions. This feature, powered by the Radix Transaction Manifest (https://docs.radixdlt.com/docs/manifest) , ensures that users are fully informed about the actions they approve, significantly reducing the risk of unintended asset losses. Furthermore, Radix revolutionizes account control through Smart Accounts (/contents/tech/core-protocols/smart-accounts) , eliminating the need for traditional seed phrases and offering a secure, non-custodial crypto experience that is as intuitive as using any standard app. The wallet's mobile-first design facilitates seamless interaction with smart contracts and dApps across devices, enhancing accessibility and security for the everyday user. Scrypto (/contents/tech/core-protocols/scrypto-programming-language) : Simplifying DeFi Development At the core of Radix's innovation is Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , an asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) programming language designed to democratize the creation of digital assets and DeFi applications. Scrypto (/contents/tech/core-protocols/scrypto-programming-language) and the Radix Engine (/contents/tech/core-protocols/radix-engine) together place assets, accounts, and permissions at the forefront, making asset security intuitive and straightforward for developers. This approach has already attracted over 12,000 developers worldwide, leading to the creation of diverse DeFi solutions, including decentralized exchanges, oracles, and DAOs. With the Babylon (/contents/tech/releases/radix-mainnet-babylon) upgrade, Radix has enabled smart contracts to be deployed on the Radix Mainnet, further expanding the possibilities for developers to innovate within the Web3 space. Radix Engine (/contents/tech/core-protocols/radix-engine) : Streamlining DeFi Development The Radix Engine (/contents/tech/core-protocols/radix-engine) introduces a concept similar to that of game engines in the video game industry, by handling the standardizable, low-level aspects of DeFi applications. This "DeFi Engine" allows developers to focus more on the unique features and functionalities that enhance user experiences rather than getting bogged down by underlying technical details. By making DeFi development more accessible and efficient, the Radix Engine (/contents/tech/core-protocols/radix-engine) encourages the creation of secure, intuitive, and powerful dApps, ensuring a safer ecosystem for users. Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) : A New Standard in Consensus Algorithms Completing the Radix Full Stack is Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) , a consensus algorithm designed to address the scalability and efficiency challenges faced by existing blockchain networks. Born from extensive research, Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) uniquely enables parallel transaction execution while maintaining atomic composability (/contents/tech/core-concepts/atomic-composability) , promising to scale linearly with demand. This innovative approach ensures that the Radix Network (https://www.radixdlt.com) can support a high volume of transactions without compromising on speed, cost, or user experience. ## RadixRadio URL: https://radix.wiki/ecosystem/radixradio Updated: 2026-08-23 Summary: RadixRadio was one of the earliest community podcasts in the Radix ecosystem , founded and hosted by long-time community member Kilovoltage alongside… RadixRadio Type Community podcast / media Focus Radix ecosystem projects & community Founder / host Kilovoltage (https://twitter.com/realKilovoltage) Co-host Jimmy Humania Launched Late 2022 Format Live Twitter/X Spaces, reposted to YouTube & podcast platforms Status 🔴 Inactive X @RadixRadio (https://x.com/RadixRadio) YouTube @radixradioontwitter1761 (https://youtube.com/@radixradioontwitter1761) RadixRadio was one of the earliest community podcasts in the Radix ecosystem (/ecosystem) , founded and hosted by long-time community member Kilovoltage (https://twitter.com/realKilovoltage) alongside co-host Jimmy Humania. Launched in late 2022, it highlighted new projects being built on Radix and interviewed influential figures within the community. It sat alongside other Radix community media such as RadixTalk (/ecosystem/radixtalk) , Radix Review (/ecosystem/radix-review) and Quack Space (/ecosystem/quackspace) . The podcast was most active through 2022–2023 and is no longer producing new episodes. Overview New episodes of RadixRadio were released on a weekly basis, with most following an interview format. Kilovoltage would typically speak in-depth with founders of Radix-based projects or other important voices in the community. There was also audience participation during the live recording of episodes, with listeners able to join the discussion and ask questions. The podcast aimed to provide a unique opportunity for community engagement within the Radix ecosystem. By interviewing project leaders and discussing the latest developments, it helped keep the community informed and connected. RadixRadio also served as an educational resource, with discussions exploring the technical workings of Radix and its advantages over other blockchains. Since its launch, RadixRadio developed a following within the Radix community, though its size is now hard to establish: Twitter Spaces publishes no retrospective audience figure and the recordings expired after 30 days. In the run-up to the Babylon (/contents/tech/releases/radix-mainnet-babylon) smart-contract launch in 2023, RadixRadio served as a go-to source for staying up to date on ecosystem developments. Format RadixRadio recordings took place via the Twitter Spaces feature. This allowed kilovoltage to host live voice conversations focused around a particular topic or guest. Listeners could tune into the Twitter Space live and participate in the discussion. After the initial recording, the audio from the Twitter Space was extracted and uploaded onto other platforms like YouTube, Spotify, Apple Podcasts etc. This allowed the episodes to remain available after the 30-day expiration period for Twitter Spaces. The majority of RadixRadio episodes followed an interview format, with kilovoltage speaking one-on-one with a guest. These guests were typically founders of projects built on Radix or influential voices within the Radix community. In addition to the interview content, listener participation and questions were a key component of the podcast. Those tuning into the Twitter Space recordings were able to raise their hand and be brought on air by kilovoltage to ask questions or share perspectives. This interactivity was a core part of what made RadixRadio unique. The free-flowing discussion format enabled by Twitter Spaces gave RadixRadio a conversational tone. Kilovoltage aimed to make guests feel comfortable opening up, while still extracting key insights about their projects and Radix involvement. This casual yet informative style resonated with listeners. Episodes RadixRadio featured interviews with a diverse range of guests from across the Radix ecosystem since launching in late 2022. Some notable episodes included: - Episode 1: Interview with Radish Eco founder "Mik" about his NFT project, plans for future roadmap and utilities, rights for NFT holders, and journey into the Radix community. - Episode 2: Interview with Robo Creator about his Radical Robos generative NFT collection. Discussed original 3D art process, community-focused approach, plans to incorporate robo characters into future metaverse and gaming concepts. - Episode 3: Interview with founders of Radical Penguins NFT project Ice Penguin and Pengu Creator. Talked about being first 3D NFT on Radix, plans for NFT marketplace, charity donations, roadmap. - Episode 4: Interview with Vlad B about his projects Nerds Republic and Foton NFT marketplace. Discussed origins of nerd avatars, plans to integrate related metaverse concepts, early stages of Radix involvement. - Episode 5: Interview with founders of Bobcat Society NFT project Baron and Lynx. Discussed decision to switch from Solana blockchain to Radix, community differences, project roadmap and vision. - Episode 6: Interview with founder of Roidboiz NFT project Radix Enigma. Discussed generative art process, roadmap, traits, plans to collaborate with other Radix projects. - Episode 7: Roundtable discussion with Radix community leaders B Like Water, Bobby Sizemore, Jordan T Jones, and Squidward XRD. Talked history in Radix, approach to community building, outlook on future growth. The wide range of projects and personalities covered demonstrated the expanding diversity of the Radix ecosystem. Hosts Jimmy Humania Jimmy Humania co-hosted RadixRadio alongside Kilovoltage. Kilovoltage RadixRadio was founded and hosted by @kilovoltage (https://twitter.com/realKilovoltage) . He has been an active member of the Radix community for over a year, joining in late 2021. Kilovoltage is based in the southwestern United States. His interest in Radix began after learning about it on Reddit and joining the early Telegram community. He was attracted by the technical ambitions of the project and the helpfulness of early supporters. In addition to hosting RadixRadio, kilovoltage serves as a volunteer ambassador for Radix. He aims to help grow the ecosystem by promoting projects and organizing real-world events. His passion for the community and networked nature of Radix are what motivated him to start the podcast. Reception Since launching in late 2022, RadixRadio was well-received within the Radix community. It became a popular medium for projects to reach the community and build connections between different ecosystem participants. The size of that audience cannot be established from the surviving record. Live Spaces attendance was never published and the recordings expired after 30 days, so the only countable trace is the YouTube channel (https://youtube.com/@radixradioontwitter1761) , which on 23 August 2026 holds 8 uploads, 30 subscribers and 441 views in total across every episode, the best-viewed of them at 96. Those eight uploads are not the whole show — episode numbering on the channel reaches #24 — so the figures set a floor on the reposted archive rather than measuring the live audience. The interactive live format did provide a form of community engagement uncommon among blockchain podcasts at the time. Through the ecosystem's early growth in 2022–2023, RadixRadio was a leading source for community discussion and updates, helping onboard new members and promote cohesion during a formative period for Radix. External Links - @RadixRadio on X (https://x.com/RadixRadio) - RadixRadio on YouTube (https://youtube.com/@radixradioontwitter1761) - Kilovoltage (host) on X (https://twitter.com/realKilovoltage) ## Staatenlos Node URL: https://radix.wiki/ecosystem/staatenlos-node Updated: 2026-08-22 Summary: Staatenlos Node is an active Radix mainnet validator operated by the team behind Staatenlos , a German-language community focused on financial privacy… Type Validator Node Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Status 🟢 Active (registered) Validator validator_rdx1svpqafv… (https://dashboard.radixdlt.com/network-staking/validator_rdx1svpqafv4te3qtfhux5yxv2vyv95mp866dp9xpe28v0pvvwzhrk4vyz) Operators Christoph Heuermann & Lukas ( Ociswap (/ecosystem/ociswap) co-founders) Validator fee 2.5% Total stake 95,607,237.03 XRD — rank 15 of 188 registered (epoch 337,230, 22 Aug 2026) Website staatenlos.ch (https://staatenlos.ch/staatenlos/radix-staatenlos-node/) Overview Staatenlos Node is an active Radix (/contents/tech/releases/radix-mainnet-babylon) mainnet validator (/contents/tech/core-concepts/radix-governance) operated by the team behind Staatenlos (https://staatenlos.ch) , a German-language community focused on financial privacy and location independence. The node was set up by Christoph Heuermann together with Lukas – the two co-founders of the Radix DEX Ociswap (/ecosystem/ociswap) – to help decentralise the network and introduce the Staatenlos community to Radix. Read from the Radix Gateway (https://mainnet.radixdlt.com/state/validators/list) at epoch 337,230 (22 August 2026, 15:06 UTC), validator_rdx1svpqafv… is registered, accepting delegated stake, and carries 95,607,237.03 XRD — rank 15 of the 188 registered validators — at a 2.5% validator fee with no fee change queued. The operator quotes delegators about 6% a year (https://staatenlos.ch/staatenlos/radix-staatenlos-node/) , which is what the network's ~300M XRD annual emission (/contents/tech/core-concepts/network-emissions) pays across an active set holding 4.69 billion XRD, and does not advertise a rate the emission schedule cannot fund. The node's on-ledger info_url points at node.staatenlos.ch, which has answered HTTP 526 (an origin TLS failure at Cloudflare) since at least 22 August 2026; the maintained page is the one linked above, on the main Staatenlos site. Operations & reliability The Staatenlos Node team runs monitoring and backup systems to keep the validator highly available through hardware or network failures. Staatenlos is also part of a mutual-support alliance with fellow node runner Radical Staking (/ecosystem/radical-staking) , in which the two operators back up each other's node operations in an emergency. Staking XRD holders can delegate to Staatenlos Node directly from the Radix Wallet (https://wallet.radixdlt.com) : open the staking view, search for "Staatenlos Node", and stake any amount of XRD. Delegated stake earns network emissions minus the validator fee, and can be unstaked subject to the network's unbonding period. Staking never transfers custody – delegated XRD remains in the holder's account as stake units. External Links - Staatenlos – official community site (https://staatenlos.ch/) - Staatenlos – Radix node & staking guide (https://staatenlos.ch/staatenlos/radix-staatenlos-node/) - Staatenlos Node on the Radix Ecosystem directory (https://radixecosystem.com/projects/staatenlos-node) ## Token Unlock URL: https://radix.wiki/contents/history/token-unlock Updated: 2026-08-22 Summary: The Radix Token Unlock was a transition from the price-vesting of $XRD to freely transferrable tokens, enacted on September 15th, 2021. Token Unlock – Historical Event Category Tokenomics / Network Governance Status Completed Key Date September 15, 2021 (14:00–17:00 UTC) – final unlock of all remaining locked $XRD tokens. Key Entity RDX Works (/ecosystem/rdx-works) (Radix), proposing and enacting the unlock. Community Surveys Two surveys held Aug 23–29 and Sep 1–5, 2021; 74.6% of eligible $XRD supply voted in favor of immediate unlock. Token Supply at Unlock 9.6B $XRD circulating; 12B total; 24B maximum supply over 40+ years via annual emission. External Reference Token Unlock Video (YouTube) (https://youtu.be/RvZRPs_rOgg?si=1oAnx3vUYCbHtGbL) Related Topics $XRD Token (/contents/tech/core-protocols/xrd-token) · Network Emissions (/contents/tech/core-concepts/network-emissions) · Staking (/contents/tech/core-concepts/staking) The Radix Token Unlock was a transition from the price-vesting of $XRD (/contents/tech/core-protocols/xrd-token) to freely transferrable tokens, enacted on September 15th, 2021. Background In August 2021 Radix proposed changing to an immediate full unlock (https://www.radixdlt.com/blog/update-on-the-token-unlock-community-survey) of all tokens that were subject to a price-vesting mechanism, and conducted community surveys (https://www.radixdlt.com/blog/update-on-the-token-unlock-community-survey) to gauge sentiment on this proposal. Originally, a significant portion of the $XRD supply was subject to a price-based unlocking mechanism, whereby tokens would become available based on (e)XRD reaching certain price thresholds (https://www.radixdlt.com/blog/community-survey-radix-token-unlock) over time. Community Surveys In the initial community survey, conducted from August 23-29, 2021, Radix asked participants via a single yes/no question whether all locked $XRD tokens should be unlocked immediately or remain on the existing unlock schedule. The survey required a verified Instapass account and email address to participate. Out of the responses, 66.8% voted in favor of the immediate unlock (https://www.radixdlt.com/blog/results-unlock-survey-2) . Given the results of the first survey, Radix then announced a second survey weighted by the number of $XRD held in Radix wallet addresses linked to verified Instapass accounts. This second survey ran from September 1-5, 2021. Overall 72.34% of respondents (https://www.radixdlt.com/blog/results-unlock-survey-2) , controlling 74.6% of the eligible $XRD supply, voted for the immediate unlock. Reasons for Unlocking There were several factors (https://www.radixdlt.com/blog/update-on-the-token-unlock-community-survey) that motivated Radix to propose the immediate full unlock of all remaining locked $XRD tokens, despite the original staged price-based unlock schedule. First, within two weeks of the Olympia mainnet launch (/contents/tech/releases/radix-mainnet-olympia) on July 28, 2021, over 48% of the circulating $XRD supply was already staked (https://www.radixdlt.com/blog/token-unlock-september-15th) across more than 130 validator nodes, indicating a high degree of decentralization and security. In addition, development was progressing rapidly on the Alexandria network upgrade (/contents/tech/releases/radix-developer-environment-alexandria) , which the team felt would benefit from the simplified tokenomics (https://www.radixdlt.com/blog/update-on-the-token-unlock-community-survey) and further distribution enabled by the unlock. Finally, with the majority of survey respondents in favor, RDX Works agreed that fully unlocking the tokens was one of the most effective ways to accelerate overall adoption (https://www.radixdlt.com/blog/token-unlock-september-15th) and decentralization of the network in line with their long-term goals. The Unlock Radix proceeded with the final unlock of all remaining locked $XRD tokens on September 15, 2021 (https://www.radixdlt.com/blog/final-token-unlock-complete) , with the process completing between 14:00-17:00 UTC. At the time of the unlock, the tokenomics of $XRD were: - 9.6 billion $XRD circulating supply. - 12 billion $XRD total supply. - 24 billion $XRD maximum supply to be reached via an annual emission (/contents/tech/core-concepts/network-emissions) rate over at least 40 years - ~48% of the supply locked via staking - 15,000 $XRD in network fees had been burnt at the time of the final unlock (https://www.radixdlt.com/blog/final-token-unlock-complete) . Impact The unlocking of all remaining $XRD tokens had an immediate impact on trading activity and network growth. In the first 24 hours after the unlock, over $65 million in daily trading volume of $XRD was recorded across exchanges (https://www.radixdlt.com/blog/radix-report-16th-september) . The increased liquidity and simplified tokenomics contributed to continuing growth in awareness and staking participation on the network. By the next weekly update on September 16th, over 1.5 billion $XRD (https://www.radixdlt.com/blog/radix-report-16th-september) - representing over 15% of the total supply - was staked across validator nodes. Radix also saw a surge in social media followers, up over 10% in the two weeks following the unlock (https://www.radixdlt.com/blog/radix-report-16th-september) . This indicated an expanding community beyond just those holding unlocked tokens. Legacy The September 2021 unlock left all $XRD freely transferable well ahead of the network's later milestones, including the Babylon (/contents/tech/releases/radix-mainnet-babylon) smart-contract mainnet in 2023. The protocol network emission (/contents/tech/core-concepts/network-emissions) referenced at the unlock still carries circulating supply toward the 24 billion $XRD maximum, while the separate Foundation-run validator subsidy that supplemented early staking rewards was later wound down (see Validator Subsidy Sunset (/contents/history/validator-subsidy-sunset) ). For current tokenomics, see the $XRD Token (/contents/tech/core-protocols/xrd-token) page. ## NFTwars URL: https://radix.wiki/ecosystem/nftwars Updated: 2026-08-21 Summary: NFTwars was the first idle RPG built on the Radix Babylon network. The game let players use their existing Radix NFTs as playable heroes – fighting th… Overview NFTwars was the first idle RPG built on the Radix Babylon (/contents/tech/releases/radix-mainnet-babylon) network. The game let players use their existing Radix NFTs as playable heroes – fighting through PvE campaigns and competing against other players in the arena. It was built to unite multiple Radix NFT communities on a single platform, giving NFT holders a new utility for their assets beyond trading. NFTwars received backing from the Radix 250M XRD Ecosystem Fund, securing both an MVP Booster and a Launch Booster grant to support development and launch. Gameplay Modes Campaign Mode (PvE) Players progressed through five distinct areas, each containing four dungeons of increasing difficulty. Each dungeon presented themed enemy teams that must be defeated to unlock the next stage. Campaign mode was the primary path for levelling up NFT heroes – as they gained experience, they became stronger and more effective in arena combat. Arena Mode (PvP) In arena mode, players assembled a team of three heroes and battled against squads from other players. Wins advanced the player through ranked leagues – Bronze, Silver, Gold, Platinum – with larger rewards at higher divisions. Arena provided ongoing competition and a leaderboard-driven incentive to keep playing. Persistent Progress One of the notable design decisions in NFTwars was that hero experience was stored on the NFT itself. A levelled-up hero retained its stats even when transferred or sold – meaning experienced heroes carried added value in secondary markets, and buyers acquired the hero's battle history along with the asset. Integrated NFT Collections NFTwars integrated seven Radix NFT collections as playable heroes: - Radorables - Pyros World - Radical Penguins - Radical Robos - Abandoned Scorpions - Radish Harvests - Water Bears Each collection contributed a distinct visual identity and hero class to the roster. Players who held NFTs from any of these collections could connect their Radix wallet and immediately begin playing without any additional purchase. Radix Integration NFTwars used the Radix Engine (/contents/tech/core-protocols/radix-engine) 's native asset model to read and modify NFT data directly on-chain. Because Radix NFTs are first-class ledger objects – not EVM-style mappings – the game could attach experience data to each token and query it without relying on centralised indexing. This was a direct application of Radix's asset-oriented programming model to gaming. Wallet connection was handled through the Radix Wallet (/developers/frontend/01-radix-dapp-toolkit) , which displayed the player's NFT holdings and surfaced them as selectable heroes in-game. Ecosystem Impact As of the time of writing, NFTwars had recorded over 55,000 in-game NFT battles, with more than 200 unique Radix wallets connected and over 500 Radix NFTs actively used as heroes. These metrics represented one of the most active real-usage deployments of NFT utility on the Radix network. The game's selection as a Launch Booster winner (https://www.radixdlt.com/blog/mvp-booster-winners-root-finance-selfi-social-and-nft-wars) alongside Root Finance and Selfi Social reflected its standing as one of the ecosystem's high-potential projects during the Babylon launch window. The Token After the Project nftwars.app returns NXDOMAIN — the domain registration is gone, not merely dark — and the game's own token records how little of it ever left the issuer. NFTwars (https://dashboard.radixdlt.com/resource/resource_rdx1tk450x27ztccvuq2cj2jygv8ug84smxn5n9gsl6cwsn2wd893rz64x) ($WARS), read at the Radix Gateway (https://radix-babylon-gateway-api.redoc.ly/) on 21 August 2026, at epoch 336,894: supply 1,000,000,000 $WARS, all minted and none burned, and its minter, burner, freezer and recaller are each set to DenyAll, and so are all four of their updaters — nobody, including the account that issued the token, can mint, destroy, freeze or recall a single unit of it. It has exactly two holders. One account holds 999,999,999.999999995 $WARS — the whole supply to nine decimal places. The other is not a person but a native two-resource pool (https://dashboard.radixdlt.com/component/pool_rdx1ch4zq4kj78xsrml7jfps05s76a3my7hcj550qr06zvft6lagl3vzl8) paired against XRD, and it is empty on both sides: 0.000000005 $WARS against 0.000000000000043 XRD. A $WARS/XRD market was opened and then drained to dust. This does not contradict the usage figures above, which the game earned through Radix NFTs rather than through $WARS — heroes were the NFT collections listed on this page, and play did not require the token. It does mean the token described here never circulated, and that a reader holding a $WARS balance is holding something with no counterparty and no market. External Links - NFTwars Website (https://web.archive.org/web/20251205014628/https://www.nftwars.app/) - NFTwars on Google Play (https://play.google.com/store/apps/details?id=com.korsoste.NFTWars) - @nftwars_x on X (https://x.com/nftwars_x) - NFTwars Whitepaper (https://web.archive.org/web/20251211071050/https://whitepaper.nftwars.app/untitled/) - Radix Blog: Meet the Project – NFTwars (https://www.radixdlt.com/blog/meet-the-project-nftwars) Mobile Google Play (https://play.google.com/store/apps/details?id=com.korsoste.NFTWars) ## Abandoned Arena URL: https://radix.wiki/ecosystem/abandoned-arena Updated: 2026-08-21 Summary: Status note (July 2026): Abandoned Arena never publicly launched and its website is unreachable — abandonedarena.com still has a live DNS zone delegat… Status note (July 2026): Abandoned Arena never publicly launched and its website is unreachable — abandonedarena.com still has a live DNS zone delegated to DigitalOcean nameservers, but no A record, and www.abandonedarena.com returns NXDOMAIN (checked 21 August 2026). The source link below is repointed to the Internet Archive (https://web.archive.org/web/20250323084437/https://abandonedarena.com/) . Abandoned Arena was an upcoming competitive game that would integrate with non-fungible tokens (NFTs) on the Radix DLT[1]. Players would be able to use Abandoned Scorpions NFTs to compete with others, with other NFTs being supported in the future. Overview Abandoned Arena was built on the Radix network, leveraging its decentralized infrastructure and NFT capabilities. With Radix as the underlying technology, Abandoned Arena benefited from the scalability, security, and consensus mechanisms provided by the Radix network. In this game, players could use Abandoned Scorpions NFTs to compete with others. Abandoned Scorpions were a specific type of NFT associated with the game. The game allowed players to bet a certain amount of XRD tokens (the native token on the Radix network) while playing, with a minimum bet requirement. Source: Abandoned Arena (https://web.archive.org/web/20250323084437/https://abandonedarena.com/) Mission Abandoned Arena's mission was to offer a competitive gaming platform that utilized non-fungible tokens (NFTs) and the Radix DLT (Decentralized Ledger Technology) network, creating a new dimension in the world of online gaming. And their vision was to revolutionize the gaming industry and reshape it using blockchain gaming to create a new dimension in the esports industry. Abandoned Arena aimed to provide players with an immersive and engaging gaming experience that was transparent, secure, and efficient. The platform was built on the principles of decentralization, offering players the opportunity to compete in a fair and transparent manner. Product and Service Abandoned Arena was an upcoming competitive gaming platform that utilized non-fungible tokens (NFTs) and the Radix DLT (Decentralized Ledger Technology) network. Here are some key aspects of the product and services associated with Abandoned Arena: Competitive Gameplay Abandoned Arena offered competitive gameplay where players could engage in battles using NFTs. Players would be able to compete against each other and demonstrate their skills to win matches. Non-Fungible Tokens (NFTs) The game integrated NFTs, which are unique and indivisible digital assets. Abandoned Arena would feature specific NFTs called "Abandoned Scorpions" that players could collect, own, and use within the game. XRD Cryptocurrency Abandoned Arena employed the Radix cryptocurrency known as $XRD. Players would use $XRD to place bets and participate in the game. Rewards and Achievements The game would offer a rewards system where players could earn and win various rewards such as collectible NFTs, $XRD, special in-game items, and unlockable features. Radix DLT Network Abandoned Arena was built on the Radix DLT network, a decentralized and scalable platform for developing and deploying dApps. The Radix DLT network provides secure and efficient transactions, making it suitable for gaming applications Rewards As per the official website of Abandoned Arena, players would be able to earn and win various rewards while playing the game. These rewards would include: Collectible NFTs Players could win and collect non-fungible token (NFT) game items that would showcase their achievements and progression in the game. $XRD Players would be able to earn $XRD by competing in the game. Special game items Players could win special weapons, armors, and other in-game items by competing and winning matches. Unique game features The game would offer unique features that players could unlock by playing the game and achieve a higher rank. Token Economics Abandoned Arena game integrated with non-fungible tokens (NFTs) on the Radix DLT (Decentralized Ledger Technology) platform. The specific token used in the game was XRD (Radix cryptocurrency). Players would need to use XRD to place bets and participate in the game. Additionally, players would be able to obtain and use Abandoned Scorpions NFTs within the game. These NFTs may represent unique characters, items, or other assets. When playing the game, you bet a certain amount of $XRD, with a minimum bet. Battles on the network would have a fee. (10%, subject to change or adjustments with price fluctuation) The winner would receive the sum of both bets, minus the fee, e.g. for a 100 $XRD bet, 200 * 0.9 = 180 $XRD would go to the winner. The fee went entirely to $ARENA holders (e.g, hold 10% of supply, earn 2 $XRD from the aforementioned battle) Networks Abandoned Arena game was built on the Radix DLT (Decentralized Ledger Technology) platform, which is a decentralized network for building, deploying, and scaling decentralized applications (dApps). Radix DLT is designed to be a highly scalable and efficient protocol that can handle a large number of transactions per second (TPS) with no competition for resources, which makes it suitable for gaming and other high-throughput applications. It also provides decentralized trust and security properties, which are crucial for gaming platforms. The Token After the Project The website went away; the token did not. Abandoned Arena Token (https://dashboard.radixdlt.com/resource/resource_rdx1thwqzplv7nfyq5aaf7sc8yhv44ps44ga4k90v3n6zwf5ad3yqycgna) ($ARENA), described in its own on-ledger metadata as the "Yield token for Abandoned Arena", was read at the Radix Gateway (https://radix-babylon-gateway-api.redoc.ly/) on 21 August 2026, at epoch 336,894. Supply is 100,000 $ARENA, every unit minted and none burned, and its minter, burner, freezer and recaller are each set to DenyAll, and so are all four of their updaters — nobody, including the account that issued the token, can mint, destroy, freeze or recall a single unit of it. It is also still held. 2,266 accounts carry a balance. The largest holds 47,425.64 $ARENA — 47.4% of the supply — the second 14,539.44, and the distribution tails away from there. This is the practical consequence of Radix's asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) model rather than anything the team arranged: a token is ledger state held in accounts, not a contract the issuer has to keep running, so it outlives the project that minted it without anyone maintaining it. One artefact of the project is still being served, from somebody else's domain. The token's on-ledger icon_url does not point at abandonedarena.com; it points at radstrike.com/scorpions/img/8151_large.png (https://radstrike.com/scorpions/img/8151_large.png) , which answers with a genuine 320×320 PNG last modified on 28 November 2021. radstrike.com (https://radstrike.com/) today serves Radical Strikers, a separate Radix NFT shooter; neither site states a relationship with Abandoned Arena, and the Radical Strikers page does not mention the Scorpions collection. That site is frozen rather than active: its Webflow build stamp reads Last Published: Sat Aug 13 2022, its footer is copyright 2021, and it still advertises the game as "coming soon". ## Bullring URL: https://radix.wiki/ecosystem/bullring Updated: 2026-08-20 Summary: Bullring is a gamified peer-to-peer auction platform on Radix where sellers list tokens, NFTs or asset bundles and bidders compete in real time, pitch… Bullring is a gamified peer-to-peer auction platform on Radix where sellers list tokens, NFTs or asset bundles and bidders compete in real time, pitched on its landing page as "the ultimate Web3 auction arena on Radix" (https://bullring.auction) . It was built by Avaunt (/ecosystem/avaunt-staking) , the community developer behind the ShardSpace product family, and launched on mainnet on 18 November 2025 (https://t.me/ShardSpace/4272) after a two-month public beta on Stokenet. Bullring is the open-market sibling of Atomix (/ecosystem/atomix) : where Atomix keeps trades private and person-to-person, Bullring puts every listing on a shared dashboard (https://t.me/ShardSpace/4230) for anyone to bid on. Both platforms settle through subintents (/contents/tech/core-concepts/subintents-and-pre-authorizations) , so a winning bid and the auctioned asset change hands in one atomic transaction. How it works A seller lists a single asset or a bundle of assets (https://t.me/ShardSpace/4061) from their wallet, sets a reserve price and an auction duration, and can attach an optional Buy It Now price (https://t.me/ShardSpace/4557) – anyone can complete the auction early at that price, and the option disables itself once a bid meets it (https://t.me/ShardSpace/4518) . Active auctions appear in the Arena, the platform's shared feed of open listings. Each bid is a subintent signed in the Radix Wallet, and since a pre-launch manifest update (https://t.me/ShardSpace/4240) the transaction preview shows both assets moving in and out of both wallets before either party approves. When an auction finalizes, the asset and the winning bid settle within seconds (https://bullring.auction) with no escrow held by the platform. A Quick Bid button (https://t.me/ShardSpace/4465) allows instant bids from the live auction page, and incremental auto-bidding (https://t.me/ShardSpace/4680) – the system bidding on a user's behalf up to a set maximum – entered testing on Stokenet in December 2025. The Arena and the points system The platform's namesake is its live auction arena: bidders enter the Bullring and bid against each other in real time, watching the asset move between bidders (https://t.me/ShardSpace/4030) with each higher bid, with the page showing who is in the ring, who is winning and who has exited. The real-time service went live two days after launch (https://t.me/ShardSpace/4457) . Identity and progression are on-ledger. Visitors can browse auctions as guests, but bidding requires minting a Bullring Profile NFT (https://t.me/ShardSpace/4067) , which updates as its owner earns points and progresses through 30 levels of achievements and milestones (https://t.me/ShardSpace/4240) . Points reward selling, bidding, referrals – both referrer and referral earn (https://t.me/ShardSpace/4475) – and daily claims, with users maintaining unbroken streaks (https://t.me/ShardSpace/5215) running to months. Notifications Bullring is integrated with Notix (https://t.me/ShardSpace/4108) , Avaunt's notification service (/ecosystem/notix) : bid updates arrive through Notix or Telegram, and new bids can be placed directly from either. A community-built listing bot (https://t.me/ShardSpace/4722) by ArthurQuantize also posts new Bullring listings and sales into the ShardSpace Telegram group, where auction announcements have run continuously since launch. History Avaunt shipped the Stokenet beta on 12 September 2025 (https://t.me/ShardSpace/4030) , ten days after Atomix's, and the community test cycle ran through the autumn: - 13 September 2025 – live demo on the Radix Review podcast (https://open.spotify.com/episode/5DzuwYi3ah0CLL2fEWCtyQ) . - 6 October 2025 – Notix integration (https://t.me/ShardSpace/4108) for auction updates and bidding from Telegram. - 9 November 2025 – Profile NFTs, the 30-level points system and referrals (https://t.me/ShardSpace/4240) landed on Stokenet. - 18 November 2025 – mainnet launch (https://t.me/ShardSpace/4272) at bullring.auction, with three known issues declared: an iOS transaction-memo bug, a pre-authorization signing issue on Olympia-era Ledger accounts, and the real-time service being down. - 20 November 2025 – the real-time arena went live (https://t.me/ShardSpace/4457) and Quick Bid (https://t.me/ShardSpace/4465) was added. - 26 November 2025 – Buy It Now reached mainnet (https://t.me/ShardSpace/4557) , alongside pagination and login fixes; two days later the platform was managing 26 simultaneous auctions (https://t.me/ShardSpace/4575) . - 6 January 2026 – the channel marked Bullring's first real-world-asset auction (https://t.me/ShardSpace/4953) . Developer and related projects Bullring is one of four products (https://t.me/ShardSpace/4257) built by Avaunt, the operator of the Avaunt Staking (/ecosystem/avaunt-staking) validator: ShardSpace (/ecosystem/shardspace) (portfolio management), Notix (/ecosystem/notix) (notifications), Atomix (/ecosystem/atomix) (peer-to-peer OTC trading) and Bullring (peer-to-peer auctions). Support and development discussion for the whole family runs through the shared ShardSpace | Notix Community (https://t.me/ShardSpace) Telegram group. Activity on ledger (20 August 2026) Bullring charges a fee on every settled auction and collects it through a component of its own, a BullringFeeCollection instance at component_rdx1cqwqdtcv3pakggnyzguzweuc9drytqe3snkrse87h8jckjcz6gfdht, gated by the same Bullring admin badge the platform's dApp definition (/developers/frontend/04-dapp-definition-and-verification) account holds. Its stored state is public, and it is the closest thing the platform has to a published set of books. Read on 20 August 2026, nine months after the mainnet launch: Field Value fee_rate 0.03 — three percent of the settled price auction_count 108 total_collected 4,924.2609 XRD Because the fee is a fixed proportion, those two numbers give the volume that passed through the platform: 4,924.2609 XRD at three percent implies roughly 164,100 XRD of auctions settled since the 18 November 2025 launch (https://t.me/ShardSpace/4272) , across 108 sales, averaging about 1,520 XRD each. The individual settlements are legible in the same place — a DELIVERNFTs NFT at 110 XRD paying a 3.3 XRD fee, a bundle at 5,500 XRD paying 165 XRD. The date on the most recent one is the part worth knowing: the last fee deposited into this component was on 24 March 2026. No auction has settled through it in the five months since. The Atomix (/ecosystem/atomix) dApp definition account's last on-ledger activity falls in the same week, on 23 March 2026. This page still reads 🟢 Active, and deliberately: bullring.auction answered HTTP 200 on 20 August 2026, the contracts remain on ledger, and no wind-down has been announced. What the ledger adds is the distinction between reachable and busy. When the main Radix Telegram asked on 20 August 2026 whether any NFT marketplace was left for secondary trading (https://t.me/radix_dlt/998843) , and a second member replied that Bullring showed no active listings (https://t.me/radix_dlt/998847) , this is the record behind that impression. A fee component counts settlements, not open listings, so it cannot confirm what is listed right now — but it can say that nothing has sold here since March. External Links - bullring.auction (https://bullring.auction) – mainnet dApp - bullring-frontend.fly.dev (https://bullring-frontend.fly.dev) – Stokenet test instance - ShardSpace | Notix Community (https://t.me/ShardSpace) – Telegram support group - Mainnet launch announcement (https://t.me/ShardSpace/4272) – 18 November 2025 - Radix Review live demo (https://open.spotify.com/episode/5DzuwYi3ah0CLL2fEWCtyQ) – 13 September 2025 ## Trove URL: https://radix.wiki/ecosystem/trove Updated: 2026-08-20 Summary: Trove was a digital asset trade management tool on Radix that let two people swap NFTs and tokens directly, with no intermediary and no escrow process… Trove was a digital asset trade management tool on Radix (/contents/tech/core-protocols/radix-engine) that let two people swap NFTs and tokens directly, with no intermediary and no escrow process. It is dormant, and what follows describes the platform as it operated. Runs on Radix Q&A: Trove (https://youtu.be/vf5b8llQERI?si=RwbS-yw7e6-_Zypu) Status Trove's front end has been unreachable since at least 30 July 2026. On 20 August 2026 both trove.tools and www.trove.tools answer HTTP 404 with a 50-byte body, so nothing is served at either address. The registration tells a different story from the front end, and it is why this page reads dormant rather than closed. The domain's registry record (https://rdap.identitydigital.services/rdap/domain/trove.tools) , read on 20 August 2026, shows trove.tools registered through NameCheap on 4 July 2023 and paid through 4 July 2027, carrying the client transfer prohibited lock, still delegated to Cloudflare nameservers, and last changed on 12 August 2026 – eight days before this check. A project nobody is left to close does not renew its domain and touch the record. On the ledger the token sits untouched. The TROVE resource (https://dashboard.radixdlt.com/resource/resource_rdx1tkl09e0ahgrxpwm4t5frseadp80thu5hm6n0zlzrn6ztddlm60wex8) , read at mainnet epoch 336,750 on 20 August 2026, carries a fixed total supply of 500,000,000 and still names https://trove.tools as its info_url. It has one transaction in its entire ledger history, committed on 10 February 2025. The public repository ripsource/TROVE (https://github.com/ripsource/TROVE) was created on 4 June 2023 and pushed once, minutes later; it describes itself as an application for a Radix Booster Grant and has never been archived. Overview Building Trove on Radix offers benefits like fewer deal size constraints, clear transaction manifests, low transaction fees, and inherent scalability. The platform emphasizes secure and direct user-to-user trades and eliminates the need for intermediaries or drawn-out escrow processes. Trove is noted for its simplicity and efficiency, being built with less than 300 lines of Scrypto code. Key features of Trove include: - Platform for Managing and Advertising Digital Assets Trades: Offers an effortless and secure medium for managing swaps of digital assets. - Scalable and Efficient: Crafted with less than 300 lines of Scrypto code, unparalleled if built on platforms like Ethereum or Polygon. - Reduced Deal Size Constraints, Minimal Gas Fees, Transaction Manifest, and More: Allows users to potentially transact hundreds or even thousands of assets in one go, with low transaction fees and unparalleled clarity and assurance. History Early Experiments on Olympia Mainnet The Olympia mainnet on Radix was the initial platform of choice for @ripsource's experiments. The first project, named "Rippy", was a parody of the Radix assistant, hosted on a rudimentary website designed with basic HTML, CSS, and segments of copied JavaScript. This early iteration was plagued by slow load times, with pages often taking up to 15 seconds to load. Recognition at RadFi2022 Creative Competition Transitioning from a personal hobby, @ripsource's work began to gain external acknowledgment. This recognition was highlighted by the win at the RadFi2022 Creative Competition held by @radixdlt. The victory resulted in increased attention, leading to a larger audience discovering the project. Collaborative Projects The post-competition period saw @ripsource collaborating with other teams within the decentralized application community. One notable partnership was the development of a collection website for @PenguinsXRD, available at http://collection.radicalpenguins.com (https://collection.radicalpenguins.com/) . Diving into Smart Contracts with Scrypto 101 A pivotal phase in @ripsource's journey was enrollment in Radix’s Scrypto 101 course. The structured modules within this course enabled @ripsource to transition from having no knowledge of smart contract creation to launching an NFT-based retro arcade game on RCNet V1. Introduction of Trove Utilizing the skills and knowledge accumulated, @ripsource conceptualized Trove. The primary objective of Trove was to offer a solution to the Radix community, allowing for a secure and trustless mechanism for users to manage and swap assets. Role of Radix in Web3 Development The development and success of Trove highlighted Radix's potential in simplifying the traditionally complex aspects of dApp and smart contract creation. With its user-friendly tools and platforms, Radix aims to make #web3 more accessible to a broader range of users and potential developers. Features - Singular or Bundle Trades: Trade NFTs, a bundle of NFTs, or various tokens in consolidated deals. - Scalable and Efficient: Crafted with less than 300 lines of Scrypto code, outperforming similar platforms like Ethereum or Polygon. Why build on Radix? Radix's native asset handling and inherent scalability enable Trove to offer reduced deal size constraints, minimal gas fees, and transaction manifests, making trades on Trove frictionless. Benefits of Building on Radix - Reduced Deal Size Constraints: Potentially transact hundreds or thousands of assets in one go. - Minimal Gas Fees: Low transaction fees as compared to networks like Ethereum. - Inherent Scalability: Managed effortlessly by the Radix Engine. Trove in Action: A User's Guide The platform’s usability can be summarized through a scenario of Alice and Bob trading NFTs: Trade Proposal Creation - Alice sets up a Trade Proposal on Trove. - Specifies the NFTs and tokens to be traded. - Trade proposal is created, and Alice receives an NFT badge with details. Trade Acceptance - Bob joins the trade using Alice's code. - Verifies and accepts the trade. Trade Completion - Alice authorizes the release of new NFTs and tokens. - Trade is completed in a single transaction. Founder: Ripsource Ripsource is Trove's sole founder and developer. He transitioned into dApp development on Radix and designed Trove to foster Radix's unique bartering culture. Background - Finance and Renewable Energy Engineering: Ripsource's original background. - Radix Development: A significant creative outlet, growing expertise in Scrypto. - Future Prospects: Driven by opportunities in the Radix community, Ripsource hopes to commit full-time. ## RadQuest URL: https://radix.wiki/ecosystem/radquest Updated: 2026-08-20 Summary: RadQuest was the Radix Foundation ’s guided onboarding dApp: a gamified tour that walked a newcomer through installing the Radix Wallet and using the… RadQuest Type Guided onboarding dApp for the Radix Wallet (/contents/tech/core-protocols/radix-wallet) Status 🔴 Closed – last quest settled on ledger 27 April 2026; radquest.io registration expired 10 August 2026 Operated by Radix Foundation (/ecosystem/radix-foundation) – a Priority 3 (/ecosystem/radix-accountability-council) service in the 2026 transition Launched 30 July 2024 (https://www.radixdlt.com/blog/radquest-redefining-web3-onboarding) , relaunched 4 September 2024 (https://www.radixdlt.com/blog/update-radquest-relaunch) Source code github.com/radixdlt/radquest (https://github.com/radixdlt/radquest) – public, TypeScript, eight Scrypto (/developers/scrypto) packages, no licence file Hero Badges 200,158 minted (resource_rdx1n2mvky7na57d832lypd9xy5ftxt7lynu3flyn084gfncayshmmdwga) RadMorphs 10,984 forged (resource_rdx1nt2q2rks2xgus6etcpeq4c8ysuj0l5pwhs9r3cxw6qtly5kxqddp2e) Ledger read Epoch 336,703 / state version 552,583,231, 20 August 2026 Verified 20 August 2026 RadQuest was the Radix Foundation (/ecosystem/radix-foundation) ’s guided onboarding dApp: a gamified tour that walked a newcomer through installing the Radix Wallet (/contents/tech/core-protocols/radix-wallet) and using the network’s distinguishing features – native assets (/contents/tech/core-concepts/native-assets-vs-token-approvals) , Smart Accounts (/contents/tech/core-protocols/smart-accounts) , Personas (/contents/tech/core-protocols/personas) and readable transaction manifests (/contents/tech/core-protocols/transaction-manifests) – by having them do it rather than read about it, and paid them in on-chain collectibles for finishing. It launched on 30 July 2024, was reworked that September, and stopped. The last quest it settled on mainnet was on 27 April 2026; three days after the last Hero Badge was minted its repository had its build pipelines switched off; and on 10 August 2026 the radquest.io registration expired, leaving the address on a registrar parking page. No closure announcement was published – the four RadQuest posts on the Radix blog all date from 2024 – so what follows is the sequence the artefacts themselves record. The onboarding pitch, 2024 The launch post, RadQuest: Redefining Web3 Onboarding (https://www.radixdlt.com/blog/radquest-redefining-web3-onboarding) of 30 July 2024, framed the problem as one of confidence rather than information: newcomers are held back by jargon, unfamiliar interfaces and the fear of an irreversible mistake. RadQuest’s answer was a guide character, Jetty, who led users through wallet setup and a sequence of quests, rewarding each with XRD (/contents/tech/core-protocols/xrd-token) and with gift boxes whose contents could be combined into collectible NFTs. The first week was, by the Foundation’s own account, larger than expected. The relaunch post (https://www.radixdlt.com/blog/update-radquest-relaunch) of 4 September 2024 records over four million transactions processed by the network in that week, 60,000 Radix Wallet downloads across iOS and Android, and more than 1.15 million XRD of RadMorph trade volume on the Trove (/ecosystem/trove) NFT marketplace. It also records why that was a problem. The XRD rewards drew farming at a scale the Sybil defences did not absorb, and the transactional load degraded the experience for everyone else. The relaunch, timed for Token2049 Singapore, removed XRD rewards outright and replaced them with a “golden ticket” system – the post notes that a KYC gate was considered and rejected as disproportionate for an onboarding tool. RadQuest ran in that second form for the remaining nineteen months. The asset system RadQuest’s rewards were real on-ledger resources, documented for third parties in Tech Talk: Using RadQuest Assets With Your dApp (https://www.radixdlt.com/blog/tech-talk-using-radquest-assets-with-your-dapp) (29 July 2024) so that other dApps could recognise a RadQuest graduate and tailor what they showed them. - Hero Badge – one non-fungible badge per quester, tracking progress and presented on every interaction. Because it is issued once per user, its supply is a headcount. - Gift Boxes – earned by completing quests, in four grades (Starter, Simple, Fancy, Elite), each opening into ingredient assets. - Elements – a fungible crafting material; five Elements fuse into one RadGem. - RadGems and Morph Energy Cards – non-fungible ingredients with randomly generated colour, material and rarity traits. - RadMorphs – the final collectible, forged from RadGems and a Morph Energy Card, with over 3,000 possible combinations. - Ottercoin and Clams – two fungible tokens with no crafting role, kept as tradeable curiosities to teach the idea of a resource. Each step of that chain was its own Scrypto (/developers/scrypto) package rather than one monolith. The repository (https://github.com/radixdlt/radquest/tree/main/scrypto-packages) carries eight: radquest, hero-badge-forge-v2, gift-box-opener-v2, card-forge-v2, radgem-forge-v2, quest-rewards-v2, ticket-machine and clam-dex. Their mainnet addresses are committed in the repository’s shared constants file (https://github.com/radixdlt/radquest/blob/main/packages/common/src/constants.ts) , which is why the system remains readable now that the front end is gone. What the ledger records Read at epoch 336,703 / state version 552,583,231 on 20 August 2026, the two resources that count RadQuest’s reach are still there and still hold their totals: Resource Address Supply RadQuest Hero Badges resource_rdx1n2mvky7na57d832lypd9xy5ftxt7lynu3flyn084gfncayshmmdwga 200,158 RadMorphs resource_rdx1nt2q2rks2xgus6etcpeq4c8ysuj0l5pwhs9r3cxw6qtly5kxqddp2e 10,984 Two hundred thousand badges is the number RadQuest is best measured by: one per person who started it, minted by the protocol rather than counted by an analytics script, and unaffected by the domain lapsing. Against that, 10,984 RadMorphs is the count of users who went far enough to forge the end-of-chain collectible – roughly one in eighteen. The same records date the ending precisely. The last transaction to mint a RadMorph was committed at 06:24:15 UTC on 27 April 2026, burning two RadGems and a Morph Energy Card; the last transaction against the quest-rewards component component_rdx1cpklwp2zr6padewcxdkvnqydwp6mlzquyuuvlsztm8agdjdpmfzkxc followed fourteen minutes later at 06:38 UTC the same morning. The Hero Badge resource saw one further transaction, on 1 May 2026, and nothing since. How it wound down RadQuest was named in the Foundation’s operational stack map (https://www.radixdlt.com/blog/the-foundation-operational-stack-mapping-the-2026-transition) of 26 January 2026 as a Priority 3 service – “non-critical but maintained” – described there as a guided onboarding dApp whose front end and “essential backend/on-chain services” were both run by the Foundation. Priority 3 was the tier explicitly offered to the community to take over, open-source, or shut down. On 17 February 2026 the Foundation opened Action on P3 Foundation Services (https://radixtalk.com/t/action-on-p3-foundation-services/2238) on RadixTalk, asking for input on each service by name. RadQuest is the one the post singles out as carrying “ongoing monthly costs”, and the stated case for switching it off was to reduce recurring operating expense and maximise the assets transferred to the community. The thread drew seven posts and stopped on 22 February 2026. The repository shows what happened next. On 4 May 2026 – three days after the last Hero Badge transaction – three commits landed together: a deployment guide covering local development and a production Kubernetes setup, a README link to it, and a change that renamed both GitHub Actions workflows to ci.yaml.disabled and helm-changes.yml.disabled. That is the shape of a handover rather than a deletion: turn the pipelines off, write down how someone else could stand it back up. Nothing has been committed since, and the repository is public but carries no licence file, so the code is readable rather than open source in the formal sense. The last visible step was passive. The radquest.io registration expired on 10 August 2026 at 10:36 UTC; the domain’s nameservers are now ns1.lander.d.parity.domains and it serves Namecheap’s expired-domain page, headed “Domain registration has expired”. A P3 service that ran for twenty-one months and issued two hundred thousand badges left the network by not being renewed. External links - github.com/radixdlt/radquest (https://github.com/radixdlt/radquest) – the full source, front end, backend and Scrypto packages - RadQuest: Redefining Web3 Onboarding (https://www.radixdlt.com/blog/radquest-redefining-web3-onboarding) – the Radix Blog, 30 July 2024 - Tech Talk: Using RadQuest Assets With Your dApp (https://www.radixdlt.com/blog/tech-talk-using-radquest-assets-with-your-dapp) – the Radix Blog, 29 July 2024 - Update: RadQuest Relaunch (https://www.radixdlt.com/blog/update-radquest-relaunch) – the Radix Blog, 4 September 2024 - The Foundation Operational Stack: Mapping the 2026 Transition (https://www.radixdlt.com/blog/the-foundation-operational-stack-mapping-the-2026-transition) – the Radix Blog, 26 January 2026 - Action on P3 Foundation Services (https://radixtalk.com/t/action-on-p3-foundation-services/2238) – RadixTalk, 17 February 2026 ## Money, Wealth, and Volcanos URL: https://radix.wiki/blog/money-wealth-volcanos Updated: 2026-08-20 Summary: 4 min read Crypto is an exciting new frontier but to understand it you first need to understand money. This is how the world works: Look at the crumbl… Format Editorial / explainer (4 min read) Central idea Money is a measurement of wealth, not wealth itself Key references Dan Robinson (https://twitter.com/danrobinson) (volcano thought experiment), Peter Thiel, Per Bylund, US M2 (FRED) (https://fred.stlouisfed.org/series/M2SL) Companion piece PoW vs PoS: The Next Industrial Revolution (/blog/pow-vs-pos-the-next-industrial-revolution) Related Network Emissions (/contents/tech/core-concepts/network-emissions) · Staking (/contents/tech/core-concepts/staking) Money, Wealth & Volcanos 4 min read Crypto is an exciting new frontier but to understand it you first need to understand money. This is how the world works: FIRST, LOOK AROUND YOU: Look at the crumbling brickwork, potholes, shuttered stores, brownfield sites, peeling wallpaper and threadbare carpets. There’s no shortage of work. But there’s no money. WHERE HAS ALL THE MONEY GONE? The financial district looks like it has plenty of money. The Forex markets swap $5.1tn worth of currencies every day. But it’s a shell game. To quote Peter Thiel: “Finance is the only way to make money when you have no idea how to create wealth.” We don’t lack money, we lack wealth. Money is not wealth. Wealth is peace, love; and yes, private jets, caviar, and pothole-free roads. SO, WHAT IS MONEY? Money is a measurement of wealth. Just like centimeters, kilograms, and mph. Consider this thought experiment from Dan Robinson: - Throw $1000 into a volcano. - ➡️ Every remaining dollar measures fractionally more. - Throw a cow into a volcano. - ➡️ The world has lost a productive asset. MONEY IS NOT A REAL ASSET The value of wealth never changes: a cow is a cow; a house is a house. USD, Euros, gold, and Bitcoin (https://bitcoin.org) are all the same: not assets, just different ways to measure wealth. Throwing $1000 into a volcano simply transfers their value to the remaining dollars. No wealth is lost. Dan’s purchasing power is just transferred to other dollar holders. THIS ALSO WORKS IN REVERSE! If the Federal Reserve prints $1,000,000,000,000, purchasing power is transferred away from other dollar holders… Printing money doesn’t increase real resources any more than printing theatre tickets increases the number of seats. OK… ONE QUESTION: “If money is like centimeters and kilograms, shouldn’t we all use the same measurement and make sure those dimensions don’t change?” The obvious answer is “Yes!” THE DIMENSIONS OF MONEY ARE ITS SUPPLY Say a house measures $100,000. Double the supply of dollars (i.e. halve the measurement size) and the house now measures $200,000. HOW MUCH ARE THE DIMENSIONS CHANGING? Since 1990, the dollars we use to measure wealth have increased 560%. HOW?! Commercial banks, moderated by the Federal Reserve, create new money whenever they issue loans. WHAT DOES THIS MEAN? Most people don’t know how to measure wealth accurately. Those who do know can take advantage of those who don’t: Step 1: Borrow money. Step 2: Swap for real wealth (houses, etc) before the owners realize the new measurement. IS THERE A NAME FOR THIS PROCESS? Take your pick: - Theft. - Fraud. - Abomination. - Monetary Policy… - Arbitrage… WHAT ABOUT THE POTHOLES? Borrowing money to flip assets is just too darn easy. Why study potholes when finance is rigged to win? Interest rate and currency arbitrage are so lucrative that they have bewitched the brightest minds and drawn enormous amounts of capital away from the difficult task of making the world a better place; i.e. creating wealth. A PATH FORWARD: So, we've diagnosed the illness. But what's the cure? 1. ASK THE RIGHT QUESTION “What causes poverty? Nothing. It’s the original state, the default and starting point. The real question is, What causes #prosperity?” - Per Bylund 2. FINANCIAL LITERACY: Ignorance is the enemy. We can't change the game if we don't know the rules. Understand how money, finance, and economics work. Then share what you’ve learned! "Knowledge itself is power." - Francis Bacon 3. INVEST IN REAL WEALTH: Invest in health, education, sustainable technology, infrastructure, arts. These are real sources of wealth. They make our lives better and contribute to the long-term wellbeing of our planet. 4. INNOVATE: What if we rethink money? New forms of money like Bitcoin, Ethereum (https://ethereum.org) and Radix are already challenging the status quo. They're not perfect yet, but they're a start. Let's experiment, innovate, and find better ways to measure and exchange wealth. 5. FAIR DISTRIBUTION: Wealth isn't just about accumulation. It's about distribution. A society where wealth is concentrated in the hands of a few is a society on the brink. Let's strive for a broad distribution of wealth. A FINAL THOUGHT: Money isn't evil, but debasing it is. Money is a tool. A tool we've created. And if we've created it, we can make it better. RADIX.wiki (/) is a knowledge and community hub for the Radix ecosystem. Follow us on Twitter (https://twitter.com/RadixWiki) for updates. Contents (/contents) | Ecosystem (/ecosystem) ## Radix Infrastructure RFPs URL: https://radix.wiki/contents/history/infrastructure-rfps Updated: 2026-08-20 Summary: In February 2026, the Radix Foundation issued three Requests for Proposals (RFPs) to hand off the operation of core network infrastructure to communit… Published February 3, 2026 RFPs Babylon Gateway, Signalling Server, Connect Relay Goal Decentralize Foundation-operated core services Submission RadixTalk (proposals forum) Specs Google Drive (linked via RadixTalk) Commercialization Operators may monetize heavy-user access Related Xi'an (/contents/tech/releases/radix-mainnet-xian) , Radix Foundation (/ecosystem/radix-foundation) Proposals 4 (Michael RFC, Foundation DevOps team, mountaintop, LinkPool) Status (Aug 2026) Undecided — forum thread silent since 28 Apr 2026, no operator selected Overview In February 2026, the Radix Foundation issued three Requests for Proposals (RFPs) to hand off the operation of core network infrastructure to community operators. The three services – the Babylon Gateway, the Signalling Server, and the Connect Relay – have been operated centrally by the Foundation and are now being decentralized as part of the broader drive to reduce single points of failure in the Radix ecosystem. Operators who submit successful proposals gain the right to run these services commercially, with the ability to charge heavy users while subsidizing or providing free access for public goods such as the Radix Wallet and Dashboard. Babylon Gateway The Babylon Gateway is the primary API endpoint used by wallets, dashboards, dApps, and developer tooling to query ledger state. It indexes the Radix ledger into a PostgreSQL database and exposes a REST API. Technical requirements per the RFP: - 2 TB PostgreSQL database (current size); ~60 GB/month growth rate - Query latency under 1 second for 99th percentile - 99.9% uptime SLA - Full indexing from genesis to current ledger tip - Public API endpoint accessible to all Radix ecosystem participants Operators may charge enterprise or heavy-volume users for access while providing free-tier access for the Radix Wallet, Radix Dashboard, and other public infrastructure. Proposals are submitted via RadixTalk with technical specs provided on Google Drive. Signalling Server The Signalling Server facilitates WebRTC peer-to-peer connection establishment between the Radix Wallet and dApps (the Radix Connect protocol). It is stateless except for in-memory session state held briefly during handshake. Technical requirements per the RFP: - Global latency under 300 ms (P95) - Stateless architecture with Redis for ephemeral state - ~6,000 concurrent connections at peak - No payload inspection – the server relays encrypted messages only - DDoS mitigation at the network layer The Signalling Server handles no user data beyond ephemeral session tokens and encrypted payloads it cannot read. This makes it a suitable service for community operators to run with minimal privacy risk. Connect Relay The Connect Relay provides persistent message delivery for the Radix Connect protocol when direct WebRTC connections cannot be established (e.g., strict NAT environments). Messages are encrypted end-to-end and stored temporarily until delivered. Technical requirements per the RFP: - Encrypted payload storage with 600-second TTL - DDoS mitigation - Message delivery guarantees with retry logic - No ability to read message contents (end-to-end encrypted) Like the Signalling Server, the Connect Relay processes only encrypted payloads. Operators gain no access to transaction contents or user identity – making this infrastructure suitable for trustless community operation. Proposals and Status The RFPs were posted to the RadixTalk governance forum (https://radixtalk.com/t/foundation-rfp-babylon-gateway/2202) on 3 February 2026 by Foundation representative Adam_XRD, alongside a blog announcement (https://www.radixdlt.com/blog/the-next-phase-of-decentralization-rfps-for-gateway-and-relay-services) the same day. On 18 March 2026 the three individual service threads were merged into a single P1-architecture discussion, reflecting a decision to evaluate the services together as one operational stack rather than awarding them piecemeal. Four proposals were tabled across that discussion and its companion RFC, spanning a wide range of scale and cost: - Community takeover (Michael, 9 February 2026) — an RFC (https://radixtalk.com/t/rfc-community-takeover-of-the-babylon-gateway/2229) rather than a bid, sketching a decentralized, community-led operation in which no single entity holds the whole stack: pools of gateway servers all serving traffic at once, rotated out of the active pool one at a time for upgrades so that maintenance never takes the service down. - Shambu Pujar and Marek Karwacki (27 February 2026) — the Radix Foundation (/ecosystem/radix-foundation) DevOps team who already run the services, proposing to operate all three as a standalone operation: the PostgreSQL database and Kubernetes cluster on AWS, the Radix full nodes on OVH, blue/green deployment so that upgrades and full ledger resyncs happen with no user-visible downtime, and the relay and signalling server as add-on workloads on the same infrastructure. Production-ready within five to eight weeks of a project start. - mountaintop (1 March 2026) — the low-cost end: around €300–400 per month for the full Gateway and roughly €100 for the relay and signalling server, about €500 per month for the entire P1 stack, charging nothing beyond server costs and funding them by asking the community to stake to and donate from his validator (https://dashboard.radixdlt.com/network-staking/validator_rdx1sv9gp89vf89dmlr5uuhquvggyrrsew5mjfykyf868ja70ukst3jsug) . The design is Hetzner bare metal — two AX42-U servers for a primary and standby PostgreSQL instance with Patroni failover, plus a storage box for continuous backup — with maintenance handled by a volunteer on-call rotation. - LinkPool (23 and 28 April 2026) — the only commercial infrastructure operator to bid, running Web3 infrastructure since 2017 from a cluster across three availability zones in Manchester, with Chainlink, Lido DVT and several foundation delegations as existing clients. It offered a 99.99% target SLA against the RFP's 99.9% floor, with blue/green and canary rollouts and offsite backup included in an operating retainer. What the discussion did not produce is a decision, and the reason is that the body meant to make it does not exist yet. Adam_XRD stated at the outset that proposals would be voted on by the community; by the time LinkPool arrived in April, Magal36 told it that "the foundation won't be your customer, as it's dismantling, the community DAO is", named the sitting members of the Radix Accountability Council (/contents/tech/core-concepts/radix-governance) as the people to coordinate with, and described the position as a limbo in which "these kinds of decisions are being taken very slowly". Several participants had raised the same concern in February — that a multi-year infrastructure contract signed before the DAO exists binds a community that never chose the operator, and that any award should carry break clauses for the eventual Xi'an (/contents/tech/releases/radix-mainnet-xian) rebuild. The thread has been silent since 28 April 2026. No operator has been selected, no contract has been awarded, and the Foundation continues to run all three services in the meantime — which is the third of the three outcomes Adam_XRD set out in February, and the one that delays the handover. Why Decentralize Infrastructure? Centralised infrastructure creates single points of failure and trust. If the Foundation's Gateway goes offline, the Radix Wallet and all Foundation-operated dApps lose ledger access. If the Signalling Server is unavailable, wallet-to-dApp connections cannot be established. By distributing these services to multiple independent operators, the ecosystem gains resilience. Multiple Gateway operators mean no single downtime affects all users. Community operators have commercial incentives to maintain high availability – failure costs them revenue from enterprise customers. The RFP model gives operators clear technical requirements and commercial rights while giving the Foundation a structured way to evaluate proposals against security, reliability, and decentralization standards. External Links - The Next Phase of Decentralization: RFPs for Gateway and Relay Services – Radix Blog (3 Feb 2026) (https://www.radixdlt.com/blog/the-next-phase-of-decentralization-rfps-for-gateway-and-relay-services) - RadixTalk – Foundation RFP: Babylon Gateway (the merged P1 thread) (https://radixtalk.com/t/foundation-rfp-babylon-gateway/2202) - RadixTalk – RFC: Community Takeover of the Babylon Gateway (https://radixtalk.com/t/rfc-community-takeover-of-the-babylon-gateway/2229) - Radix Foundation (/ecosystem/radix-foundation) ## Radix Wiki Hackathon #1 URL: https://radix.wiki/contents/history/radix-wiki-hackathon-1 Updated: 2026-08-20 Summary: The Radix Wiki Hackathon #1 was held at the ArtSect Gallery in London on the 20-21st April, 2024. TELEGRAM → “I woke up ha… The Radix Wiki Hackathon #1 was held at the ArtSect Gallery (https://maps.app.goo.gl/webQjmqK4RfKtv1dA) in London on the 20-21st April, 2024. TELEGRAM → https://t.me/RadixHackathon (https://t.me/RadixHackathon) Testimonials “I woke up having never programmed in rust before or ever dealing with the Radix ecosystem but somehow managed to deploy my first NFT contract in test-net a few hours ago. Coding in solidity feels like working in a strait jacket compared to scrypto! Never going back.” - Richard Jarram, Geochain “Can’t believe we learnt Scrypto and built Smart Contract for InfiniX just in 2 days! Thanks to all the mentors and judges. It was an amazing experience to be there and learn from all of you!” - MD Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAADmcRukBZBWcEc42TGiCbxkH1K0Tn9QAK0k&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BHakxM5kLQl6Ta%2FV2gp3MvQ%3D%3D) , InfiniX “The experience was both challenging and fulfilling. The concentrated learning over the course of two days surpassed what I had learned over several months and the sense of community and the cooperative spirit were outstanding.” - Jetnor Muhaj (https://www.linkedin.com/in/jetnormuhaj/) , AI Invest. Tracks - Each selected winner had to use at least one of the following resources in their project: Scrypto (https://github.com/radixdlt/radixdlt-scrypto) , the Radix dApp Toolkit (https://docs.radixdlt.com/docs/dapp-toolkit) , the Radix Engine ToolKit (https://docs.radixdlt.com/docs/radix-engine-toolkit) (TS, python, swift, C#, Kotlin) the Network API (https://docs.radixdlt.com/docs/network-apis) (Core API, Gateway API, System API), the Radix Off Ledger Authentication (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) (ROLA). TRACK TRACK RUNNER PRIZE POOL ($XRD) RESOURCES IDEAS 🛤️ ADVANCED: Domains, Data, Finance XRD Domains / RadixCharts (https://radixcharts.com) **🥇 $3000 🥈 $1500 🥉 $500 - Can also be submitted to the Scrypto challenges (https://www.radixdlt.com/blog/scrypto-yield-derivatives-challenge-is-live) .** | ● Radix Name Service SDK (https://github.com/radixnameservice) ● Telegram bots tutorial (https://core.telegram.org/bots/tutorial) ● Python telegram bot library (https://python-telegram-bot.org/) ● Ociswap Tokens API (https://api.ociswap.com/tokens) ● Ociswap Ignition Rewards API (https://ociswap.com/ignition) ● Scrypto Lending Challenge ~v0.4.0 (Current v1.1.1) (https://github.com/radixdlt/scrypto-challenges/tree/main/3-lending) ● Scrypto Exchanges Challenge ~v0.3.0 (Current v1.1.1) (https://github.com/radixdlt/scrypto-challenges/tree/main/1-exchanges) ● OrangeFinance docs (site withdrawn) ● Banana Gun docs (https://docs.bananagun.io/) | 💡 Telegram clone that uses Domains for handshakes & account discovery. 💡 Sentiment analysis of domain transactions. 💡 Visualize top token holder accounts. 💡 Transaction root analysis tool: who is creating the most transactions. 💡 Telegram bot for stake and unstake actions. 💡 AI trading bot. 💡 Token rankings per USD transfer volumes. 💡 NFT trading statistics. 💡 An ‘Airnode’ plugin for first party oracles similar to API3 (https://api3.org) . 💡 Cross-shard DEX pool to eliminate trading hotspots. 💡 Automated liquidity management tool / OrangeFinance. 💡 **Banana Gun (https://bananagun.io) style auto-sniping. 💡 Dopex / Stryke (https://www.stryke.xyz) style options exchange.** 💡 A lending protocol that uses future staking rewards as collateral. | | 🛤️ BEGINNERS: Front-end Toolkit / Tx Manifest / NFTs | Shardspace | **🥇 $3000 🥈 $1500 🥉 $500 - Can also be submitted to the Scrypto challenges (https://www.radixdlt.com/blog/scrypto-yield-derivatives-challenge-is-live) .** | ● Transaction Manifest (https://docs.radixdlt.com/docs/manifest) ● Rust Manifest Builder (https://docs.radixdlt.com/docs/radix-engine-toolkit-manifest-builder) ● Gumball Machine Frontend dApp (https://docs.radixdlt.com/docs/learning-to-run-the-gumball-machine-front-end-dapp) ● Simple token transfer (https://docs.radixdlt.com/docs/simple-token-transfer) ● Token Gating (Coingecko) (https://www.coingecko.com/learn/token-gating) ● Token gating tools (other networks) (https://www.alchemy.com/best/token-gating-tools) ● Instruct Manifest Builder (https://instruct.radixbillboard.com) ● Radix Desktop Tool (https://github.com/atlantis-l/Radix-Desktop-Tool) | 💡 Token launch sniping. 💡 Wallet following. 💡 Automated dollar-cost averaging. 💡 Conditional / time delayed transfers (e.g. after period of inactivity / birthday gifts). 💡 Publishing platform for Decentralized Science papers. 💡 NFT-gating for Discord groups. 💡 NFT collection gallery with rankings. | Results 🥇 Beginners’ Track Winner - 🗺️ Geochain https://github.com/metalogica/geochain (https://github.com/metalogica/geochain) Geochain securely tracks and manages shipments in real-time using Radix for a transparent and efficient supply chain. Team: Richard Jarram, Mariana Oka (https://www.linkedin.com/in/mariana-oka/) Presentation: https://docs.google.com/presentation/d/1NHJWIptTSpNwz4_rQeq7qeKeIL7GeEcEXz9H9wb7EwI/edit#slide=id.g26f1ee450e0_0_322 (https://docs.google.com/presentation/d/1NHJWIptTSpNwz4_rQeq7qeKeIL7GeEcEXz9H9wb7EwI/edit#slide=id.g26f1ee450e0_0_322) 🥈 Beginners’ Track Silver - 📊 Radix Stats https://github.com/dcts/radixstats (https://github.com/dcts/radixstats) Radix Stats provides free and open token analytics for Radix, enhancing transparency and credibility. Team: Thomas Starzynski (https://www.linkedin.com/in/thomas-starzynski/) , Mauro Jose (https://www.linkedin.com/in/maurojose) RadixStats-slides.pdf (Radix%20Wiki%20Hackathon%20#1/RadixStats-slides.pdf) Radix Dashboard (https://radixstats.web.app/?resource=resource_rdx1t5xv44c0u99z096q00mv74emwmxwjw26m98lwlzq6ddlpe9f5cuc7s) 🥉 Beginners’ Track Bronze - 🕺 Jouna-Wyliometer https://github.com/jameswylie/jouna-wyliometer (https://github.com/jameswylie/jouna-wyliometer) The Jouna-Wyliometer is a price sentiment tool that uses a 3D avatar who, via the Astrolescent API, reacts according to the current $XRD price. Team: Jouna Lansman (https://twitter.com/JounaLansman) Wyliometer - Price Sentiment Tool (https://jouna-wyliometer.pages.dev/) 🥇 Advanced Track Winner - ∞ InfiniX https://github.com/AbdurRazzak01/RadixHack (https://github.com/AbdurRazzak01/RadixHack) InfiniX offers customizable loss limits, instant fund settlements, and parametric insurance integration for DeFi investments. Team: MD Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAADmcRukBZBWcEc42TGiCbxkH1K0Tn9QAK0k&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BHakxM5kLQl6Ta%2FV2gp3MvQ%3D%3D) , Kishan Marsonia (https://www.linkedin.com/in/kishan-marsonia) InfiniX (https://www.canva.com/design/DAGDCJiRn0g/jvYaaVqe4WQasc20wUjRYw/edit?utm_content=DAGDCJiRn0g&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton) 🥈 Advanced Track Silver - 🤖 AI Invest https://github.com/muhaj/aiin (repository no longer public) AI Invest provides an accessible chatbot interface with real-time stock and crypto data, guided purchases, and engaging UI for simplified trading. Team: Jetnor Muhaj (https://www.linkedin.com/in/jetnormuhaj/) AI Invest Radix Chat bot (https://www.canva.com/design/DAGCX1Ol78M/MXBVmGt_t_ucxpUkPbISPw/view?utm_content=DAGCX1Ol78M&utm_campaign=designshare&utm_medium=link&utm_source=editor) 🥉 Advanced Track Bronze - 🥊 Top Scorer / FitClash https://github.com/fitclash/fitclashdemo (https://github.com/fitclash/fitclashdemo) Top Scorer / FitClash is a fitness app that allows friends to wager each other with $XRD in various physical activities with real-time AI tracking and leaderboards. Team: Justin Grierson (https://www.linkedin.com/in/justin-grierson) Advanced Track Runner Up - 🎨 PiciX https://github.com/AbdurRazzak01/Picix (https://github.com/AbdurRazzak01/Picix) PiciX is a daily AI art challenge inspired by Wordle, where participants create image prompts to match a provided AI-generated image, with the winning creation minted as an NFT and sent to the winner's Radix wallet. Team: MD Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak?miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAADmcRukBZBWcEc42TGiCbxkH1K0Tn9QAK0k&lipi=urn%3Ali%3Apage%3Ad_flagship3_search_srp_all%3BHakxM5kLQl6Ta%2FV2gp3MvQ%3D%3D) , Kishan Marsonia (https://www.linkedin.com/in/kishan-marsonia) Data Engineer Eli Lilly & Company (https://www.canva.com/design/DAGDD_xD-Gg/tGjN5rHKAb7rjzud4QyFSw/edit?utm_content=DAGDD_xD-Gg&utm_campaign=designshare&utm_medium=link2&utm_source=sharebutton) ## FooHack URL: https://radix.wiki/contents/history/foohack Updated: 2026-08-20 Summary: FooHack was a three-day hackathon hosted in June 2022 by the multi-platinum musician RedFoo at his "Party Rock Mansion" in the Malibu mountains, organ… Hackathon Event Name FooHack Category History (/contents/history) Status Completed Date 14 June 2022 Organizers RDX Works in collaboration with musician RedFoo Media "Smooth as Vegan Butter" – The FooHack Documentary (https://youtu.be/EtRAt3_CHks) · Radix Blog Post (https://www.radixdlt.com/blog/scrypto-is-as-smooth-as-vegan-butter) FooHack was a three-day hackathon hosted in June 2022 by the multi-platinum musician RedFoo (https://en.wikipedia.org/wiki/Redfoo) at his "Party Rock Mansion" in the Malibu mountains, organised in collaboration with RDX Works (https://www.radixdlt.com) . It was fuelled, in RDX Works' telling, by vegan food and raw cacao. Background RedFoo – a Grammy-nominated, multi-platinum artist – had by 2022 become a Web3 coder and an enthusiast for Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , Radix's asset-oriented smart-contract language. He had been introduced to Scrypto only three months before the hackathon (https://www.radixdlt.com/blog/scrypto-is-as-smooth-as-vegan-butter) , which RDX Works presented as the point of the exercise: a beginner in the language climbing the learning curve in public. For FooHack he handpicked three competition-winning programmers, and the four of them — dubbed the FooCrew — had, on RDX Works' account, been strangers the week before. What Was Built Over three days the FooCrew built a chess engine that runs on a public ledger: it enforced the full rules of chess, supported player-versus-player games, and minted each final board state as an on-ledger asset (/contents/tech/core-concepts/asset-oriented-programming) – an NFT put up for auction. The work was split into five streams — the front end, the chess engine, the auction components, NFT minting, and one person to stitch the pieces together — with RedFoo himself taking the auction components. The same "chess on the ledger" idea had first appeared as an internal experiment at the Radix Team Hackathon (/contents/history/radix-team-hackathon) in 2019, though that build enforced the rules through board and move Particles on the pre-Babylon ledger and had no resource model with which to mint the result. Scrypto Significance RedFoo praised the Rust-based, asset-oriented language, coining the line that gave the accompanying blog post its title: "Coding in Scrypto is as smooth as vegan butter." (https://www.radixdlt.com/blog/scrypto-is-as-smooth-as-vegan-butter) RDX Works contrasted the FooCrew's three-day build against a student project at the Technical University of Berlin (https://www.tu.berlin/en/) , which it said had spent an entire semester attempting a chess game in Solidity on Ethereum without finishing it – attributing the difference to Scrypto's buckets-and-vaults model (/contents/tech/core-concepts/asset-oriented-programming) for handling resources natively. FooHack sat alongside the Scrypto Developer Event (/contents/history/scrypto-developer-event) and Scrypto DeFi Challenge (/contents/history/scrypto-defi-challenge) in Radix's push to grow the Scrypto developer community. Media https://youtu.be/EtRAt3_CHks (https://youtu.be/EtRAt3_CHks) https://www.radixdlt.com/blog/scrypto-is-as-smooth-as-vegan-butter (https://www.radixdlt.com/blog/scrypto-is-as-smooth-as-vegan-butter) ## Radix Team Hackathon URL: https://radix.wiki/contents/history/radix-team-hackathon Updated: 2026-08-20 Summary: The Radix Team Hackathon was the first internal hackathon organised by RDX Works (then Radix DLT). It was held during the first week of April 2019, wh… Internal Hackathon Event Type Internal Team Hackathon Category History (/contents/history) Status Completed Date First week of April, 2019 Location Peak District, England Organizer RDX Works External Link Official Blog Post (https://www.radixdlt.com/blog/the-first-radix-team-hackaton) The Radix Team Hackathon was the first internal hackathon organised by RDX Works (https://www.radixdlt.com) (then Radix DLT). It was held during the first week of April 2019, when the team gathered in the Peak District of northern England for its quarterly planning week and set aside one full day to build on the ledger, with project presentations and a team vote the following morning. Format Staff were split into six teams, each deliberately balanced with both technical and non-technical members so that the competition turned on ideas and execution rather than raw engineering firepower. Each team had 24 hours to design, build and demo a working prototype on the pre-Babylon Radix ledger, and several worked into the night to have something to show; the following morning was given over to presentations, questions and the vote. Projects The six prototypes spanned payments, identity, tooling and games. Three of them were later given their own write-up on the Radix blog; the descriptions below draw on those where they exist. POS Card System A point-of-sale and loyalty concept, and the one the team itself called a favourite. The pitch was a single card or app combining credit, charge and loyalty functions, settling almost instantly and at minimal fees, with the cardholder rather than a payment processor holding the record of their own spending. RDX Works described what was built in a day as "quite staggering" (https://www.radixdlt.com/blog/the-first-radix-team-hackaton) and promised a dedicated post and the code; neither appears in the site's blog index today. DecentraSign Document signing and verification anchored to the ledger — a decentralised counterpart to DocuSign, built by a four-person team over one working day. Signing a document meant committing its cryptographic hash and a ledger timestamp, so that who signed what, and exactly when, could be proved without a central e-signature provider, and the signature could not be forged or backdated afterwards. The team demonstrated sending and verifying document hashes between two people. It received the first of the follow-up posts, "Timestamping on Radix – The DecentraSign Experiment" (https://www.radixdlt.com/blog/timestamping-on-radix-the-decentrasign-experiment) (2 May 2019). Radix Universe Visualizer A real-time browser view of network activity, written in JavaScript against the Radix JavaScript client library by two team members — one of whom had written that library. The design brief was to show atoms — the unit of ledger state before Olympia (/contents/tech/releases/radix-mainnet-olympia) — moving across the network as they were stored, with sound effects layered over the graphics; the authors describe discarding more ambitious spherical-display and VR versions for want of the hardware, and settling on the metaphor of a giant pinball table with atoms rattling between the nodes. Its limitation was the network itself: with few nodes running at the time there was little to draw. Written up as "Radix Universe Visualizer" (https://www.radixdlt.com/blog/radix-universe-visualizer) (6 June 2019). Chess on the Ledger The prototype with the longest afterlife, and the one whose mechanism the follow-up post records in most detail. The goal was to test how far application-level rules could be pushed onto the ledger itself, so that every node could act as a chess service and no third party was needed to referee a game. The team implemented the rules as ledger logic in the pre- Babylon (/contents/tech/releases/radix-mainnet-babylon) application stack: two new Particles, one for the board and one for a move, evaluated by the Constraint Machine. A player moved by consuming the last board particle and submitting a new board state alongside their signed move, which the ledger then checked for legality against the referenced board — enforcing per-piece movement (pawns one square, bishops diagonally, knights in their L-shape), white to move first, no two consecutive moves by the same player, and no taking a move back once made. Because the board lived on the ledger rather than in a session, players could abandon a game and return to it later with the state preserved exactly, and anyone could watch. Written up as "Building Decentralized Chess On The Radix Ledger" (https://www.radixdlt.com/blog/building-decentralized-chess-on-the-radix-ledger) (30 May 2019). Three years later the same idea was rebuilt from scratch at FooHack (/contents/history/foohack) — this time in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , with the final board state minted as an NFT and auctioned, which the 2019 build had no resource model to do. Radix Planner Immutable polls and surveys on the ledger, with the parameters of a vote fixed at creation so that a result could not be quietly re-scoped after the fact. The team also sketched it as an upvoted notice board — a company bulletin, a way of tracking wagers, a general consensus-gathering tool. Command Line Interface — winner Another way to talk to the ledger: check the balances and messages of a given address, and send both tokens and messages. It won the most votes of any hack, on the strength of a live demonstration of an automated payment chain — the worked example was a wallet instructed to forward 10% of every incoming payment to a savings address, so that a £10 payment moved £1 across without any further action by the owner. RDX Works pointed at charitable giving and automated distribution for trading syndicates as the obvious extensions. RDX Works framed the day as evidence that building on Radix would be straightforward (https://www.radixdlt.com/blog/the-first-radix-team-hackaton) – a thesis later carried into public developer events such as the Scrypto Developer Event (/contents/history/scrypto-developer-event) , the Scrypto DeFi Challenge (/contents/history/scrypto-defi-challenge) , and the DApp in a Day (/contents/history/dapp-in-a-day-workshop-1) university workshops. The follow-up trail The announcement post promised, six times over, that the code and a dedicated write-up for each project would follow "in the coming weeks". Three arrived, between two and seven weeks later: DecentraSign on 2 May 2019, Chess on the Ledger on 30 May, and the Universe Visualizer on 6 June. All three remain published. No dedicated post for the POS card system, the Radix Planner, or the winning CLI appears in radixdlt.com's sitemap (https://www.radixdlt.com/sitemap.xml) as of August 2026 — so the hack the team voted best is the one with the least public record. The code fared worse. Only one of the three posts named a repository, github.com/radixdlt/DecentraSign, and it returns 404 today. The prototypes were built on the atom-and-particle ledger that Olympia (/contents/tech/releases/radix-mainnet-olympia) and then Babylon replaced, so none of them would run against the network as it now stands; what survives is the write-ups. Media https://www.radixdlt.com/blog/the-first-radix-team-hackaton (https://www.radixdlt.com/blog/the-first-radix-team-hackaton) ## Transactions Per Second (TPS) URL: https://radix.wiki/contents/tech/core-concepts/transactions-per-second-tps Updated: 2026-08-19 Summary: Transactions per second (TPS) is a key metric of the speed and scalability of payment and distributed ledger (DLT) networks. High TPS enables networks… Transactions per second (TPS) is a key metric of the speed and scalability of payment and distributed ledger (DLT) networks. High TPS enables networks to support demanding real-world transactional loads without congestion. Overview Transactions per second (TPS) refers to the number of transactions a network can process each second. It is the most common measurement used to benchmark the performance and scalability of payment and DLT networks. However, TPS is not the only way to measure transaction throughput. Other metrics include: - Transactions per minute (TPM) - Used when transactions are complex and take longer than a second to process. - Peak throughput - The maximum TPS achieved under ideal conditions. Gives insight into potential capacity. - Sustained throughput - The average TPS maintained over time under real-world conditions. Measures actual performance. - Latency - The time for a transaction to be processed and confirmed. Faster latency allows higher TPS. - Concurrency - The number of transactions processed in parallel. Higher concurrency can increase TPS. - Scalability - How throughput changes with increased load. Linear scalability means doubling nodes doubles TPS. TPS can be measured by benchmarks and tests that simulate transaction loads. Common benchmarks for blockchains involve transferring assets between accounts or executing smart contract functions. The transactions sizes, complexity, and submission rates are parameterized to evaluate different scenarios. When comparing TPS across networks, it is important to understand the assumptions and conditions of each test. Results can vary significantly based on factors like network size, geography, hardware, latency, consensus mechanism, transaction types, and concurrency. As with any benchmark, real-world performance may differ. TPS Limits of Early Blockchains Early blockchain networks like Bitcoin (https://bitcoin.org) and Ethereum (https://ethereum.org) had limitations in transactions per second due to their consensus mechanisms and network configurations. Bitcoin uses a proof-of-work consensus based on mining, which allows a maximum of around 7 TPS. This is far below the volume of transactions handled by mainstream payments networks. Ethereum improved on Bitcoin's performance through shorter block times, achieving around 15 TPS. However, as usage increased, the Ethereum network became congested and transaction fees spiked. These limitations of early blockchains stem from tradeoffs that favored decentralization and security over scalability. However, poor TPS presents challenges for adoption, especially for decentralized finance applications with high transaction volumes. Radix TPS Radix is a layer 1 decentralized network designed to achieve extremely high transaction speeds. It utilizes a sharded consensus protocol called Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) to enable linearly scalable transaction throughput. Tests of Radix under various conditions have achieved over 1.4 million TPS (https://www.radixdlt.com/blog/replaying-bitcoin) , significantly faster than other blockchain networks like Ethereum or Solana (https://solana.com) . Radix aims to support DeFi (https://en.wikipedia.org/wiki/Decentralized_finance) applications with transaction loads comparable to mainstream payment processors like Visa or PayPal. Those figures came from controlled benchmarks; delivering the same linearly-scalable throughput on a live, permissionless network is the goal of the ongoing Hyperscale (/contents/tech/research/hyperscale-rs) program, whose 500,000+ TPS public test (https://www.radixdlt.com/blog/hyperscale-update-500k-public-test-done) is the most recent milestone toward that goal. ## Shard Groups URL: https://radix.wiki/contents/tech/core-concepts/shard-groups Updated: 2026-08-19 Summary: Shard groups [ /ʃɑrd grups/ ] or Validator Sets on Radix are groups of validators responsible for storing and validating the ledger state on subsets o… Shard groups [ /ʃɑrd grups/ ] or Validator Sets on Radix are groups of validators responsible for storing and validating the ledger state on subsets of the Radix shardspace (/contents/tech/core-concepts/sharding) . Unlike the shardspace itself, which is fixed at 2^256 shards, shard groups are dynamic and can adjust their shard coverage according to demand (https://youtu.be/FZWT3j9XHMI) . Overview Rather than fully replicating state and execution across all validators, shard groups handle validation and consensus for subsets of shards to facilitate scaling while retaining security. Validators within these groups participate in the Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus protocol to validate transactions on their shards. By reaching consensus amongst themselves, they can commit shard state while resisting various failure scenarios. The composition of validators in these sets is determined algorithmically, aiming to balance factors like security, stake distribution, and maximizing decentralization. For example, no single validator should make up more than 33% of the total stake in a set, as this would allow them to potentially compromise consensus. Shard groups Organization One of the key security mechanisms in Radix is the periodic shuffling of validators between different shard groups. This shuffling involves removing validators from their current set that is responsible for a shard subset, and reassigning them to a different shard group handling another shard subset. It works to constantly vary the composition of validators across the different parts of the network. Shuffling serves two main purposes: - Preventing attacks - By shuffling validators, it makes it much more difficult for malicious actors to target specific shards over longer timescales. Even if a shard group was compromised at one point, shuffling ensures that group would get moved across shards over time. This raises the cost and complexity for attackers. - Enhancing decentralization - Randomly reassigning validators also allows stake and participation to be distributed more evenly across all areas of the network. If validators remained static in sets, concentration of stake could occur making certain sets larger targets. The shuffling process creates some overhead, mainly for the validators that get reassigned. These validators need to resynchronize state with the new shard group responsible for those shards. So there is some redundancy and bootstrapping work required. However, this is an acceptable tradeoff to gain the security benefits. Additionally, the quantity of validators shuffled per epoch is limited to keep disruption minimal. For example, only 10-20% might rotate each epoch. This allows the majority of validators to remain in place, so resyncing overhead does not become excessive. Finding an optimal shuffling frequency, quantity of validators to shuffle, and assignment algorithms are still active research questions. The goals are to balance security with performance. Configuration The algorithms and mechanisms for determining shard group composition and assignments represent one of the most complex facets of the Radix network (https://www.radixdlt.com) . Managing 2^256 shards requires strategic placement of validators to maximize decentralization and security. Some key areas of focus include: - Quantity of validators per set - Ideal stake distribution per set - Minimum thresholds for preventing collusion - Shuffling cadence between sets - Automated assignment of validators to balance stake distribution Ideally, shard group configurations guarantee sufficient collective stake within each set to make attacks infeasible. However, maximum decentralization is also crucial to avoid concentration of power. Finding optimal formulations to address these sometimes competing priorities is an iterative, ongoing process as the network grows. Utilizing extensive simulations and tests, the Radix research team continues tuning configurations to balance performance needs with security guarantees. Research Ongoing research (/contents/tech/research) focuses on optimizing configurations for shard groups related to size, quantity, and shuffling cadence, with a view to find an ideal balance between security, performance, and decentralization as the network evolves. Since 2024 that research has moved into engineering: the sharded consensus described here – including the automatic detection, re-staffing, and recovery of a halted shard group without losing or duplicating cross-shard transactions – is being implemented in Rust as Hyperscale (/contents/tech/research/hyperscale-rs) , the open-source client (https://github.com/hyperscalers/hyperscale-rs) targeting a linearly-scalable production network. Shard Groups in the Xi'an Candidate The description above reflects the original Radix design. The Xi'an production candidate (/contents/tech/research/hyperscale-rs) specifies the same role differently, and the differences are worth noting for anyone reading forward. Composition. Each shard is served by a committee on the n = 3f+1 model with a strict two-thirds quorum – around 100 validators in project discussion, 128 seats at the operating point its security analysis prices. Voting is one seat, one vote: stake decides who may hold a seat at all, but never weights the vote, so the concern about a single validator holding more than a third of a set's stake becomes a question of how many seats a stake pool can hold rather than of stake concentration within a committee. Assignment. Committee membership is not negotiated between validators but derived: a leaderless beacon chain (/contents/tech/research/hyperscale-rs) records which shards exist and which committee serves each, and every node computes the same assignment by folding the beacon's committed blocks. Schedules freeze one epoch ahead. Shuffling. Rotation is a trickle rather than a periodic reshuffle: once per shuffle interval each shard draws a single replacement, seated make before break, with the outgoing member keeping its seat and vote until the entrant has synced. The member rotated out is the longest-tenured rather than a random draw – deliberately, so that an adversary able to grind the randomness cannot steer eviction away from its own seats. Coverage. Shard coverage adjusts by splitting and merging the shards themselves rather than by groups widening their range: a shard splits when its committed substate byte total crosses a governed threshold, live and without halting. ## Nest Finance URL: https://radix.wiki/ecosystem/nest-finance Updated: 2026-08-18 Summary: Nest Finance was an announced DeFi protocol for Radix that was to combine lending, automated liquidity and leverage in one product suite. It was annou… Nest Finance Type Announced lending, liquidity and leverage protocol for Radix (/contents/tech/releases/radix-mainnet-babylon) Status 🔴 Closed – announced 4 March 2024, never launched, silent since 6 March 2024 Announced 4 March 2024 (https://x.com/NestFinance_) Last public activity 6 March 2024, a beta-tester sign-up form Product website None ever published Documentation nest-finance.gitbook.io (https://nest-finance.gitbook.io/nest-finance) – online, 10 of its 19 pages read "Coming soon" X @NestFinance_ (https://x.com/NestFinance_) – 32 followers, 5 posts Telegram t.me/NestFinancee (https://t.me/NestFinancee) – 13 members On-ledger No component, package or resource address was ever published Verified 18 August 2026 Nest Finance was an announced DeFi (/contents/tech/core-concepts/decentralized-finance-defi) protocol for Radix that was to combine lending, automated liquidity and leverage in one product suite. It was announced on 4 March 2024, recruited beta testers on 6 March 2024, and has published nothing since. No product ever opened, and no address for it exists on mainnet. This page previously described that product suite in the past tense, as a service that had run and closed. It had not. What follows is the record the project itself left, which is small enough to set out in full. Three days in March 2024 The @NestFinance_ (https://x.com/NestFinance_) account on X opened in March 2024 and posted five times over three days. On 4 March it published a four-part introduction, "What is Nest Finance?", opening with the line the project used everywhere: the protocol was created "to offer users the easiest possible way of providing liquidity and earning yield on-chain". On 5 March it greeted the Radix community, announced its Gitbook documentation (https://nest-finance.gitbook.io/nest-finance) , and posted a picture captioned "We got 'em!" on acquiring an XRD Domains (/ecosystem/xrd-domains) name. On 6 March it asked for beta testers through a Google Form. The account has 32 followers and has not posted in the 29 months since. The project's Telegram (https://t.me/NestFinancee) has 13 members and shows no posts. Its channel description is the same paragraph as the X introduction, and it is also, word for word, the text this wiki page carried until August 2026. Nothing else survives. The project never published a product URL, and the domain nestfinance.xyz is unrelated: the Internet Archive's earliest capture of it, from 22 February 2025 (http://web.archive.org/web/20250222031730/http://www.nestfinance.xyz/) , is a registrar parking lander, and the domain today serves a business-banking venture with no connection to Radix. The documentation, and what it borrowed The Gitbook is the one artefact still online, and it reads as a project stopped early. Its own index (https://nest-finance.gitbook.io/nest-finance/llms.txt) lists 19 pages and 10 of them say only "Coming soon": the litepaper, every "How To", the Risks page, the referral and rates pages, the smart contracts page and the developer documentation. The liquidity page (https://nest-finance.gitbook.io/nest-finance/products/liquidity.md) is one sentence, still in the future tense: "Automated liquidity vaults will be Nest Finance first product, estimated launch in late Q2." What the pages do describe is a design lifted from Kamino Finance (https://kamino.com/docs) , the Solana lending and leverage protocol, with the names changed. Multiply vaults, Long/Short vaults, elevation mode for higher loan-to-value ratios between price-pegged assets, a points programme with per-asset boosts: the architecture is Kamino's, and Kamino's K-Lend and kToken become N-Lend and nToken. Two substitutions were missed, and they are still in the published text. The heading on the points overview (https://nest-finance.gitbook.io/nest-finance/nest-finance-points/overview.md) is "Nest Finance Points", but the anchor beneath it is id="kamino-points". The borrow and lend page (https://nest-finance.gitbook.io/nest-finance/products/borrow-lend.md) describes N-Lend in its prose and then heads its next section K-Lend Overview. Reusing a competitor's documentation as a starting draft is common and says nothing on its own about what a team can build. It is recorded here because those two anchors are the only hard evidence of how far the work got, and the answer is that the docs were the work. No trace on mainnet Nest Finance published no component, package or resource address, and none has been found. It does not appear among the 25 Radix protocols tracked by DeFiLlama (https://api.llama.fi/protocols) , which lists every Radix lending market that did ship, including Root Finance (/ecosystem/root-finance) and both versions of Weft Finance (/ecosystem/weft-finance) . A protocol leaves a ledger record the moment it deploys, whether or not anyone uses it; there is no such record here. The ecosystem directory (/ecosystem) keeps pages for projects that shut down, because a reader who meets the name needs to know what happened to it. This is a narrower case: a project that was announced and then abandoned before it ran. It is listed as Closed on that basis. External links - Nest Finance documentation (https://nest-finance.gitbook.io/nest-finance) – the surviving Gitbook - @NestFinance_ on X (https://x.com/NestFinance_) – five posts, 4 to 6 March 2024 - Nest Finance on Telegram (https://t.me/NestFinancee) - Kamino Finance documentation (https://kamino.com/docs) – the doc set the Gitbook derives from - Radix ecosystem directory (/ecosystem) ## Proof of Work URL: https://radix.wiki/contents/resources/python-scripts/proof-of-work Updated: 2026-08-18 Summary: A basic implementation of the Proof of Work (PoW) algorithm used as Sybil prevention by Bitcoin and other PoW networks. A deeper comparison between Po… Proof of Work Type Python script · worked example Demonstrates SHA-256 hash mining as Sybil prevention Language Python 3 Dependencies None – hashlib (https://docs.python.org/3/library/hashlib.html) and datetime (https://docs.python.org/3/library/datetime.html) ship with Python Difficulty Tunable via leading-zero count (5 ≈ 1 second) Related PoW vs PoS (/blog/pow-vs-pos-the-next-industrial-revolution) · Delegated Proof of Stake (/contents/tech/core-concepts/delegated-proof-of-stake-dpos) · DLT Efficiency Metric (/contents/resources/python-scripts/dlt-efficiency-metric) A basic implementation of the Proof of Work (PoW) algorithm used as Sybil prevention by Bitcoin (https://bitcoin.org) and other PoW networks. A deeper comparison between PoW and Proof of Stake (PoS) can be found in our article PoW vs PoS: The Next Industrial Revolution (/blog/pow-vs-pos-the-next-industrial-revolution) . Method & Python Script - Install VS Code: https://code.visualstudio.com (https://code.visualstudio.com) or similar application. - In VS Code open a new terminal window by navigating to Terminal > New Terminal. - Install Homebrew (https://brew.sh/) by pasting the following code into the terminal and pressing Enter: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" - Install Python in the same way: brew install python - There are no dependencies to install. The script uses only hashlib (https://docs.python.org/3/library/hashlib.html) and datetime (https://docs.python.org/3/library/datetime.html) , both of which are part of the Python standard library and are already available once Python is installed. Do not try to pip install them: the packages published on PyPI under those names are an obsolete Python 2 backport of hashlib and an unrelated Zope date type (https://pypi.org/project/DateTime/) , so the command will either fail to build or shadow the standard library. - Now, create a project folder and navigate to it in VS Code via File > Open Folder. - Create a new Python file in VS Code via File > New File. Name it something like pow.py - This script calculates the hash for the text “hello” with five leading zeros. Copy and paste it into pow.py and save it. # v.0.1 from hashlib import sha256 from datetime import datetime def pow(data, zeros, nonce): data = str(data).encode("utf-8") zeros = zeros * "0" t1 = datetime.now() while True: combo = data + f"{nonce}".encode("utf-8") hash_ = sha256(combo).hexdigest() if hash_.startswith(zeros): t2 = datetime.now() return nonce, hash_, t2-t1 else: nonce += 1 output = pow("hello", 5, 0) # 5 = ~ 1 second print(output)- Run the script from the terminal with: python3 pow.py How long it takes Each additional leading zero multiplies the expected work by sixteen. A hexadecimal digit carries four bits, so a hash with z leading zeros turns up once in 16z attempts on average – about 1.05 million at five zeros, 16.8 million at six, 268 million at seven. This loop sustains roughly 1.8 million hashes per second on a single core of a 2026 laptop under CPython 3.13, which puts five zeros at about 0.6 seconds, six at about ten seconds and seven at two and a half minutes. Slower hardware, an older interpreter or a longer input shift those numbers but not the factor of sixteen between them. Individual runs scatter much further than the averages suggest, because the search is memoryless: every nonce is an independent trial with probability 16−z of succeeding, so the number of attempts is geometrically distributed and its standard deviation is essentially equal to its mean. Two runs of the script above make the point – five zeros finished at nonce 156,056, a seventh of the expected work, while six zeros needed 33,290,382, about twice it. A single fast or slow run says nothing about the difficulty. That spread is why proof of work is a rate limiter rather than a clock, and why Bitcoin (https://bitcoin.org) only averages it out at network scale: the protocol recalculates the target every 2,016 blocks (https://developer.bitcoin.org/devguide/block_chain.html) from the time those blocks actually took, against an ideal of 1,209,600 seconds – two weeks, or ten minutes a block – so the difficulty tracks whatever hash rate the network is currently pointing at it. The same arithmetic sits behind the energy comparison in PoW vs PoS (/blog/pow-vs-pos-the-next-industrial-revolution) : raising the zero count costs nothing to verify and everything to produce. ## DLT Efficiency Metric URL: https://radix.wiki/contents/resources/python-scripts/dlt-efficiency-metric Updated: 2026-08-18 Summary: This script treats DLTs like Radix and Ethereum like engines and attempts to measure their efficiency in creating utility. Mechanical efficiency is me… DLT Efficiency Metric Type Python script · experimental metric Measures Ecosystem output (GitHub repos) per unit of attention (Google Trends) Language Python 3 Dependencies requests, pytrends, tqdm Data sources GitHub Search API (https://docs.github.com/en/rest/search/search#search-repositories) · Google Trends (https://trends.google.com) Sample 14 July 2023 snapshot (Ethereum, Solana, Avalanche, Cardano, Radix) Related Radix vs Ethereum (/contents/tech/comparisons/radix-vs-ethereum) · Scrypto (/contents/tech/core-protocols/scrypto-programming-language) · Proof of Work (/contents/resources/python-scripts/proof-of-work) This script treats DLTs like Radix and Ethereum (https://ethereum.org) like engines and attempts to measure their efficiency in creating utility. Introduction Mechanical efficiency is measured by dividing Work or Power Output by Power Input: η = W / I = Work (or Power) Output ÷ Power Input The following method substitutes Github repos for Work and Google Trends volume as a measure of Power Input. The assumption is that amount of ecosystem activity will be roughly reflected in the search volume. In this version, the number of Github repos for Radix and Ethereum is determined using the comparable search terms “ Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Radix” and “ Solidity (https://soliditylang.org) Ethereum”. The search volumes for “ Scrypto (/contents/tech/core-protocols/scrypto-programming-language) Radix” are not large enough to register so instead we have used “XRD Radix” and “ETH Ethereum” to maintain equivalence and eliminate searches for other uses of the term ‘Radix’. Results The figures below are a single snapshot taken on 14 July 2023 and are preserved as a record of that run. Both inputs move continuously – GitHub repository counts grow and Google Trends rebases its scores against whatever window is queried – so re-running the script today will produce different absolute numbers and ratios. As of August 2026 it also produces no Radix row at all: the section Status of the method, below, records a re-run of the script and what broke. DLT Repos Efficiency (η) (23/07/14) Vs Ethereum Search terms (Github) Search terms (Google Trends) Ethereum (/contents/tech/comparisons/radix-vs-ethereum) 12461 8.45 1 “Solidity Ethereum” “ETH Ethereum” Solana (https://solana.com) 1076 0.79 11x “Rust Solana” “SOL Solana” Avalanche 88 0.09 91x “Solidity Avalanche” “AVAX Avalanche” Cardano 176 0.09 97x “Plutus Cardano” “ADA Cardano” Radix 21 0.07 123x “Scrypto Radix” “XRD Radix” Method & Python Script - Install VS Code: https://code.visualstudio.com (https://code.visualstudio.com) or another IDE. - In VS Code open a new terminal window by navigating to Terminal > New Terminal. - Install Homebrew by pasting the following code into the terminal and pressing Enter: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" - Install Python in the same way: brew install python - Next, install the modules that the script needs (dependencies). The script imports tqdm for its progress bar as well as requests and pytrends, so all three go in: pip3 install requests pytrends tqdm - Now, create a project folder and navigate to it in VS Code via File > Open Folder. - Create a new Python file in VS Code via File > New File. Name it something like DLTefficiency.py - Copy and paste the following script into DLTefficiency.py and save it. # v.0.0.3 import requests from pytrends.request import TrendReq from concurrent.futures import ThreadPoolExecutor from tqdm import tqdm # Function to get the number of Github repositories for a search query def get_github_repo_count(session, search_query): url = f"https://api.github.com/search/repositories?q={search_query}" try: response = session.get(url) response.raise_for_status() return (search_query, response.json()['total_count']) except requests.exceptions.HTTPError: return (search_query, None) # Function to get the worldwide popularity score from Google Trends for a search query def get_google_trends_score(pytrends, search_query): pytrends.build_payload([search_query], timeframe='today 1-m') interest_over_time_df = pytrends.interest_over_time() if not interest_over_time_df.empty: return (search_query, interest_over_time_df[search_query].sum()) else: return (search_query, None) # Function to calculate efficiency score for a search query def calculate_efficiency_score(session, pytrends, search_query_pair): github_search_query, google_trends_search_query = search_query_pair with ThreadPoolExecutor(max_workers=2) as executor: github_future = executor.submit(get_github_repo_count, session, github_search_query) google_future = executor.submit(get_google_trends_score, pytrends, google_trends_search_query) github_repo_result, google_trends_result = github_future.result(), google_future.result() if github_repo_result[1] is not None and google_trends_result[1] is not None: return (search_query_pair, github_repo_result[1] / google_trends_result[1]) else: return (search_query_pair, None) # Main program to calculate efficiency scores for different search queries search_queries = [("Rust Solana", "SOL Solana"), ("Plutus Cardano", "ADA Cardano"), ("Solidity Avalanche", "AVAX Avalanche"), ("Scrypto Radix", "XRD Radix"), # ("wasm polkadot (https://polkadot.com) ", "DOT polkadot") # Github seems to only allow 4 queries. ] baseline_search_query = ("Solidity Ethereum", "ETH Ethereum") with requests.Session() as session: pytrends = TrendReq(hl='en-US', tz=360) github_results, google_results, efficiency_scores = [], [], [] for query in tqdm([baseline_search_query] + search_queries, desc='Calculating Efficiency Scores'): github_result = get_github_repo_count(session, query[0]) google_result = get_google_trends_score(pytrends, query[1]) efficiency_score = calculate_efficiency_score(session, pytrends, query) github_results.append(github_result) google_results.append(google_result) efficiency_scores.append(efficiency_score) print("Github Repository Counts:\n") for query, count in github_results: print(f"{query}: {count}") print("\nGoogle Trends Scores:\n") for query, score in google_results: print(f"{query}: {score}") print("\nEfficiency Scores:\n") baseline_efficiency_score = efficiency_scores[0][1] # Get baseline efficiency score for query, score in efficiency_scores: if score is not None: value_metric = baseline_efficiency_score / score print(f"{query[0].split(' ')[1]}: {score:.2f} (Ethereum = {value_metric:.0f}x {query[0].split(' ')[1]})") else: print(f"Error calculating efficiency score for '{query[0]}' and '{query[1]}'.") - Run the script from the terminal with: python3 DLTefficiency.py Status of the method (August 2026) The script above was re-run in full on 13 August 2026, in a clean virtual environment, to check whether it still works. It does – with one exception, and the exception is Radix. The Radix search term has expired Google Trends returns nothing for "XRD Radix". The query falls below the threshold at which Trends will report a series at all, so interest_over_time() hands back an empty frame, get_google_trends_score() returns None, and the script prints Error calculating efficiency score for 'Scrypto Radix' and 'XRD Radix' – the one row this page exists to produce. It is not rate limiting: in the same session, over the same one-month window, Radix returned 1,441, XRD 1,623, ETH Ethereum 895 and SOL Solana 1,229, and only the two-word Radix conjunctions came back empty. This is the same failure the 2023 run had already worked around one step earlier. That run found "Scrypto Radix" too small to register and substituted "XRD Radix" to keep the comparison equivalent; three years on, the substitute has gone the same way. "Radix DLT" still registers – 100 over the same window – and preserves the disambiguation the original pairing was chosen for, so it is the term the script needs today. A 2026 reading With that single substitution the script completes. Run on 13 August 2026, GitHub counts read from the Search API (https://docs.github.com/en/rest/search/search#search-repositories) and Trends scores summed over a one-month window: DLT Repos (2026) Repos (2023) Trends score Efficiency (η) Vs Ethereum (2026) Vs Ethereum (2023) Ethereum 18,275 12,461 895 20.42 1 1 Solana 4,553 1,076 1,229 3.70 6x 11x Cardano 268 176 1,239 0.22 94x 97x Avalanche 201 88 972 0.21 99x 91x Radix 40 21 100 0.40 51x 123x Read the Radix row with care: it is the only one whose Trends term changed between the two runs, so its 2023 and 2026 figures are not measuring the same thing and the move from 123x to 51x is not a like-for-like improvement. The other four rows kept both of their search terms. What is directly comparable across the two runs is the GitHub side, which uses fixed queries: repositories matching “Scrypto Radix” went from 21 to 40, against Ethereum’s 12,461 to 18,275. What the metric can and cannot carry Two limits are worth stating plainly, because they bound how much weight any version of this table will bear. The first is in the method: build_payload is called with a single keyword at a time, and Google Trends scales every series to 100 at its own peak (https://support.google.com/trends/answer/4365533) for the window queried. Each score is therefore normalised against that term’s own maximum, not against the others, so the denominator compares the shape of each chain’s attention rather than its volume. The second is the failure documented above: a term small enough to fall under the reporting threshold returns nothing rather than a small number, so the metric stops working precisely where the answer would be most interesting. pytrends is no longer maintained The Google Trends dependency is a community reverse-engineering of an endpoint Google does not publish, and it has stopped being maintained. GeneralMills/pytrends (https://github.com/GeneralMills/pytrends) is archived and read-only: its last code commit landed 22 April 2023, its README asks for maintainers, and 152 issues are open behind the freeze. The latest release on PyPI (https://pypi.org/project/pytrends/) is 4.9.2, published 13 April 2023. It installed and ran cleanly for the figures above, but nothing will fix it the next time Google changes the endpoint – the README says as much. ## Terms of Use URL: https://radix.wiki/contents/resources/legal/terms-of-use Updated: 2026-08-18 Summary: Please read these terms and conditions carefully before using this site. This terms of use (together with the documents referred to in it) tells you t… Please read these terms and conditions carefully before using this site. ALL USERS Terms of website use This terms of use (together with the documents referred to in it) tells you the terms of use on which you may make use of our website https://RADIX.wiki (https://RADIX.wiki) (our site), whether as a guest or a registered user. Use of our site includes accessing, browsing, or registering to use our site. Please read these terms of use carefully before you start to use our site, as these will apply to your use of our site. We recommend that you print a copy of this for future reference. By using our site, you confirm that you accept these terms of use and that you agree to comply with them. If you do not agree to these terms of use, you must not use our site. You may print off one copy, and may download extracts, of any page(s) from our site for your personal use and you may draw the attention of others within your organisation to content posted on our site. You must not modify the paper or digital copies of any materials you have printed off or downloaded in any way, and you must not use any illustrations, photographs, video or audio sequences or any graphics separately from any accompanying text. Our status (and that of any identified contributors) as the authors of content on our site must always be acknowledged. You must not use any part of the content on our site for commercial purposes without obtaining a licence to do so from us or our licensors. If you print off, copy or download any part of our site in breach of these terms of use, your right to use our site will cease immediately and you must, at our option, return or destroy any copies of the materials you have made. Other applicable terms The following additional terms also apply to your use of our site: - Our Privacy Policy (/contents/resources/legal/privacy-policy) , which sets out the terms on which we process any personal data we collect from you, or that you provide to us. By using our site, you warrant that all data provided by you is accurate. Information about us https://RADIX.wiki (https://RADIX.wiki) is a site owned and operated by the RADIX.wiki (https://radix.wiki) DAO ("We"). Changes to these terms We may revise these terms of use at any time by amending this page. Please check this page from time to time to take notice of any changes we made, as they are binding on you. Changes to our site We may update our site from time to time, and may change the content at any time. However, please note that any of the content on our site may be out of date at any given time, and we are under no obligation to update it. We do not guarantee that our site, or any content on it, will be free from errors or omissions. Accessing our site Our site is made available free of charge although the provision of the some of the services accessible through it may not be. We do not guarantee that our site, or any content on it, will always be available or be uninterrupted. Access to our site is permitted on a temporary basis. We may suspend, withdraw, discontinue or change all or any part of our site without notice. We will not be liable to you if for any reason our site is unavailable at any time or for any period. You are responsible for making all arrangements necessary for you to have access to our site. You are also responsible for ensuring that all persons who access our site through your internet connection are aware of these terms of use and other applicable terms and conditions, and that they comply with them. Our site is directed to people residing in the United Kingdom. We do not represent that content available on or through our site is appropriate in other locations. If you choose to access our site from outside the United Kingdom, you do so at your own risk. No reliance on information The Site has not been developed to meet your individual requirements and it is therefore your responsibility to ensure that the facilities and functions of the site meet your requirements. We make no representations, warranties or guarantees, whether express or implied, that the content on our site is accurate, complete or up-to-date. The materials are not exhaustive and may not always reflect the most up to date research in all areas. Information on the site presents the more commonly found aspects and for editorial reasons may not include certain substantive and commonly found phenomena. We make no warranty or representation that - the Site will meet your particular requirements; - the results that may be obtained from the use of the Site will be as stated; and - the quality of advice and information will meet your needs or expectations. Limitation of our liability Nothing in these terms of use excludes or limits our liability for death or personal injury arising from our negligence, or our fraud or fraudulent misrepresentation, or any other liability that cannot be excluded or limited by English law. To the extent permitted by law, we exclude all conditions, warranties, representations or other terms which may apply to our site or any content on it, whether express or implied. We will not be liable to any user for any loss or damage, whether in contract, tort (including negligence), breach of statutory duty, or otherwise, even if foreseeable, arising under or in connection with: - use of, or inability to use, our site; or - use of or reliance on any content displayed on our site. If you are a business user, please note that in particular, we will not be liable for: - loss of profits, sales, business, or revenue; - business interruption; - loss of anticipated savings; - loss of business opportunity, goodwill or reputation; or - any indirect or consequential loss or damage. If you are a consumer user, please note that we only provide our site for domestic and private use. You agree not to use our site for any commercial or business purposes, and we have no liability to you for any loss of profit, loss of business, business interruption, or loss of business opportunity. We will not be liable for any loss or damage caused by a virus, distributed denial-of-service attack, or other technologically harmful material that may infect your computer equipment, computer programs, data or other proprietary material due to your use of our site or to your downloading of any content on it, or on any website linked to it. We assume no responsibility for the content of websites linked on our site. Such links should not be interpreted as endorsement by us of those linked websites. We will not be liable for any loss or damage that may arise from your use of them. Viruses We do not guarantee that our site will be secure or free from bugs or viruses. You are responsible for configuring your information technology, computer programmes and platform in order to access our site. You should use your own virus protection software. You must not misuse our site by knowingly introducing viruses, trojans, worms, logic bombs or other material which is malicious or technologically harmful. You must not attempt to gain unauthorised access to our site, the server on which our site is stored or any server, computer or database connected to our site. You must not attack our site via a denial-of-service attack or a distributed denial-of service attack. By breaching this provision, you would commit a criminal offence under the Computer Misuse Act 1990. We will report any such breach to the relevant law enforcement authorities and we will co-operate with those authorities by disclosing your identity to them. In the event of such a breach, your right to use our site will cease immediately. Linking to our site You may link to any page on our site provided you do so in a way that is fair and legal and does not damage our reputation or take advantage of it. You must not establish a link in such a way as to suggest any form of association, approval or endorsement on our part where none exists. You must not establish a link to our site in any website that is not owned by you. Our site must not be framed on any other site. We reserve the right to withdraw linking permission without notice. The website in which you are linking must comply in all respects with the content standards set out in our Acceptable Use Policy. Third party links and resources in our site Where our site contains links to other sites and resources provided by third parties, these links are provided for your information only. We have no control over the contents of those sites or resources. Applicable law If you are a consumer, please note that these terms of use, its subject matter and its formation, are governed by English law. You and we both agree to that the courts of England and Wales will have non-exclusive jurisdiction. However, if you are a resident of Northern Ireland you may also bring proceedings in Northern Ireland, and if you are resident of Scotland, you may also bring proceedings in Scotland. If you are a business, these terms of use, its subject matter and its formation (and any non-contractual disputes or claims) are governed by English law. We both agree to the exclusive jurisdiction of the courts of England and Wales. CONTRIBUTORS Your account and sign-in Our site does not issue passwords and does not operate a user identification code. Contributors sign in with a Radix Wallet (https://wallet.radixdlt.com/) under ROLA (Radix Off-Ledger Authentication) (https://docs.radixdlt.com/docs/rola-radix-off-ledger-auth) : our server issues a short-lived random challenge, your wallet signs it, and we verify that signature against the public key of the account or persona you present. A successful verification creates a session that expires after seven days. Your account is identified by its Radix address; we never receive, hold or store a private key, a seed phrase or a password. Because the credential is a key you hold rather than a secret we issue, we cannot reset it, recover it, or reverse anything signed with it. Keeping your seed phrase and your device secure is your responsibility. If you believe your account has been compromised, secure it in the wallet itself — for example by securifying the account (https://docs.radixdlt.com/docs/account/#account-securification) , which changes the factors that control it — and tell us at x.com/RadixWiki (https://x.com/RadixWiki) so that contributions made from it can be suspended. We have the right to end any session, and to withdraw the right to contribute from any account, at any time, if in our reasonable opinion you have failed to comply with any of the provisions of these terms of use. Intellectual property rights and copyright We recognise that copyright is the backbone of our site. While we are the owner or the licensee of all intellectual property rights in our site The text of our articles is copyrighted by its contributors who formally and completely release all rights to the work as soon as it is uploaded to our site. Once this irrevocable act is complete they no longer have any power over how the work is used since it is then owned by the public as a whole. RADIX.wiki (https://radix.wiki) content can be copied, modified, and redistributed if and only if the copied version is made available on the same terms to others and acknowledgment of the authors of the RADIX.wiki (https://radix.wiki) used is included. When you merge or split an article, or otherwise move text from one page to another within RADIX.wiki (https://radix.wiki) , the page history functionality cannot by itself determine where the content originally came from. If you are copying text within RADIX.wiki (https://radix.wiki) , you must put a link to the source page in an edit summary at the destination page. It is encouraged to do the same thing at the source page, and to add notices at the talk pages of both. If you reuse text which you created yourself, the above may still be a good idea to avoid confusion, but it isn't mandatory. Uploading content to our site Whenever you make use of a feature that allows you to upload content to our site, you must comply with the content standards set out in our Acceptable Use Policy (/contents/resources/legal/acceptable-use-policy) . You warrant that any such contribution does comply with those standards, and you will be liable to us and indemnify us for any breach of that warranty. If you are a consumer user, this means you will be responsible for any loss or damage we suffer as a result of your breach of warranty. You retain all of your ownership rights in your content, but you are required to grant us and other users of the site a limited licence to use, store and copy that content and to distribute and make it available to third parties. The rights you license to us are described in the next paragraph (Rights you licence). We also have the right to disclose your identity to any third party who is claiming that any content posted or uploaded by you to our site constitutes a violation of their intellectual property rights, or of their right to privacy. We will not be responsible, or liable to any third party, for the content or accuracy of any content posted by you or any other user of our site. We have the right to remove any posting you make on our site if, in our opinion, your post does not comply with these terms or the content standards set out in our Acceptable Use Policy. The views expressed by other users on our site do not represent our views or values. You are solely responsible for securing and backing up your content. Rights you licence When you upload or post content to our site, you grant the following licenses: - A worldwide, non-exclusive, royalty-free, transferable license to use, reproduce, amend, distribute, prepare derivative works of, display, and perform that content in connection with the services provided by our site and across different media and to promote the site or services; and - A worldwide, non-exclusive, royalty-free, transferable licence to allow third parties to use the content for their purposes. Contact us To contact us, please message us at https://twitter.com/RadixWiki (https://twitter.com/RadixWiki) Thank you for visiting our site. ## Privacy Policy URL: https://radix.wiki/contents/resources/legal/privacy-policy Updated: 2026-08-18 Summary: The RADIX.wiki DAO ("We") are committed to protecting and respecting your privacy. This policy (together with our Terms of Use and any other documents… The RADIX.wiki (https://radix.wiki) DAO ("We") are committed to protecting and respecting your privacy. This policy (together with our Terms of Use (/contents/resources/legal/terms-of-use) and any other documents referred to on it) sets out the basis on which any personal data we collect from you, or that you provide to us, will be processed by us. Please read the following carefully to understand our views and practices regarding your personal data and how we will treat it. By visiting RADIX.wiki (https://radix.wiki) you are accepting and consenting to the practices described in this policy. For the purpose of the Data Protection Act 2018 (https://www.legislation.gov.uk/ukpga/2018/12/contents) and the UK GDPR (https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/) , the data controller is the RADIX.wiki (https://radix.wiki) DAO. Information we may collect from you We may collect and process the following data about you: Information you give us You may give us information about you by filling in forms on our site or by communicating with us by phone, e-mail or otherwise. This includes information you provide when, for example, search for information, request a downloadable document, participate in social media functions on our site, enter a competition, promotion or survey and when you report a problem with our site. The information you give us may include your name, e-mail address and phone number, personal description and photograph, and other personal sensitive confidential information. Information we collect about you With regard to each of your visits to our site we may automatically collect the following information: - technical information, including the Internet protocol (IP) address used to connect your computer to the Internet, your login information, browser type and version, time zone setting, browser plug-in types and versions, operating system and platform; - information about your visit, including the full Uniform Resource Locators (URL) clickstream to, through and from our site (including date and time); products you viewed or searched for; page response times, download errors, length of visits to certain pages, page interaction information (such as scrolling, clicks, and mouse-overs), and methods used to browse away from the page and any phone number used to call our customer service number. Information we receive from other sources We may receive information about you if you use any of the other websites we operate or the other services we provide. In this case we will have informed you when we collected that data that it may be shared internally and combined with data collected on this site. We are also working closely with third parties (including, for example, business partners, sub-contractors in technical, payment and delivery services, advertising networks, analytics providers, search information providers, credit reference agencies) and may receive information about you from them. Cookies Our website uses cookies to distinguish you from other users of our website. This helps us to provide you with a good experience when you browse our website and also allows us to improve our site. Uses made of the information We use information held about you in the following ways: Information you give to us We will use this information: - to carry out our obligations arising from any contracts entered into between you and us and to provide you with the information, products and services that you request from us; - to provide you with information about other goods and services we offer that are similar to those that you have already purchased or enquired about; - to provide you, or permit selected third parties to provide you, with information about goods or services we feel may interest you. If you are an existing client, we will only contact you by electronic means (e-mail or SMS) with information about goods and services similar to those which were the subject of a previous sale or negotiations of a sale to you. If you are a new client, and where we permit selected third parties to use your data, we (or they) will contact you by electronic means only if you have consented to this. If you do not want us to use your data in this way, or to pass your details on to third parties for marketing purposes, please tick the relevant box situated on the form on which we collect your data (the registration form); - to notify you about changes to our service; - to ensure that content from our site is presented in the most effective manner for you and for your computer. Information we collect about you We will use this information: - to administer our site and for internal operations, including troubleshooting, data analysis, testing, research, statistical and survey purposes; - to improve our site to ensure that content is presented in the most effective manner for you and for your computer; - to allow you to participate in interactive features of our service, when you choose to do so; - as part of our efforts to keep our site safe and secure; - to measure or understand the effectiveness of advertising we serve to you and others, and to deliver relevant advertising to you; - to make suggestions and recommendations to you and other users of our site about goods or services that may interest you or them. Information we receive from other sources We may combine this information with information you give to us and information we collect about you. We may use this information and the combined information for the purposes set out above (depending on the types of information we receive). Disclosure of your information We may share your personal information with any member of our group, which means our subsidiaries, our ultimate holding company and its subsidiaries, as defined in section 1159 of the UK Companies Act 2006. We may share your information with selected third parties including: - Business partners, suppliers and sub-contractors for the performance of any contract we enter into with them or you. - Analytics and search engine providers that assist us in the improvement and optimisation of our site. We may disclose your personal information to third parties: - In the event that we sell or buy any business or assets, in which case we may disclose your personal data to the prospective seller or buyer of such business or assets. - If the RADIX.wiki (https://radix.wiki) DAO or substantially all of its assets are acquired by a third party, in which case personal data held by it about its clients will be one of the transferred assets. - If we are under a duty to disclose or share your personal data in order to comply with any legal obligation, or in order to enforce or apply our Terms of Use (/contents/resources/legal/terms-of-use) and other agreements; or to protect the rights, property, or safety of the RADIX.wiki (https://radix.wiki) DAO, our clients, customers, or others. This includes exchanging information with other companies and organisations for the purposes of fraud protection and credit risk reduction. Where we store your personal data The data that we collect from you may be transferred to, and stored at, a destination outside the European Economic Area ("EEA"). It may also be processed by staff operating outside the EEA who work for us or for one of our suppliers. Such staff maybe engaged in, among other things, the fulfilment of your order, the processing of your payment details and the provision of support services. By submitting your personal data, you agree to this transfer, storing or processing. We will take all steps reasonably necessary to ensure that your data is treated securely and in accordance with this privacy policy. All information you provide to us is stored on our secure servers. Any payment transactions will be encrypted using SSL technology. Where we have given you (or where you have chosen) a password which enables you to access certain parts of our site, you are responsible for keeping this password confidential. We ask you not to share a password with anyone. Unfortunately, the transmission of information via the internet is not completely secure. Although we will do our best to protect your personal data, we cannot guarantee the security of your data transmitted to our site; any transmission is at your own risk. Once we have received your information, we will use strict procedures and security features to try to prevent unauthorised access. Your rights You have the right to ask us not to process your personal data for marketing purposes. You can exercise your right to prevent such processing by checking certain boxes on the forms we use to collect your data. You can also exercise the right at any time by messaging us at https://twitter.com/RadixWiki (https://twitter.com/RadixWiki) Our site may, from time to time, contain links to and from the websites of our partner networks, advertisers and affiliates. If you follow a link to any of these websites, please note that these websites have their own privacy policies and that we do not accept any responsibility or liability for these policies. Please check these policies before you submit any personal data to these websites. Access to information You have the right of access (https://ico.org.uk/for-the-public/getting-copies-of-your-information-subject-access-request/) to the personal data we hold about you. There is no charge for this and we will respond within one month; the £10 subject-access fee payable under the Data Protection Act 1998 was abolished when the current regime took effect on 25 May 2018. A fee may be charged only where a request is manifestly unfounded or excessive. Changes to our privacy policy Any changes we may make to our privacy policy in the future will be posted on this page. Please check back frequently to see any updates or changes to our privacy policy. Contact Questions, comments and requests regarding this privacy policy are welcomed and should be messaged to us at https://twitter.com/RadixWiki (https://twitter.com/RadixWiki) ## Topradixnode URL: https://radix.wiki/ecosystem/topradixnode Updated: 2026-08-18 Summary: TopRadixNode was a London-based validator node and staking service on the Radix network, operated as an official partner node of Impahla DAO . It allo… TopRadixNode Type Validator node / staking service Network Radix (mainnet) Affiliation Impahla DAO official partner node Validator validator_rdx1svvnmmgd… (https://dashboard.radixscan.io/network-staking/validator_rdx1svvnmmgdr6sl7llxc8sdu32ys7tn8v6k8quh7e6m6ec83fr3pf6d04) Status Dormant – deregistered from the active validator set (2026) TopRadixNode was a London-based validator node (/contents/tech/core-concepts/validator-nodes) and staking service on the Radix network, operated as an official partner node of Impahla DAO (/ecosystem/impahla) . It allowed XRD holders to delegate stake to a maintained validator and earn network emissions in return. Current status As of mid-2026, TopRadixNode has wound down. On-ledger the validator (https://dashboard.radixscan.io/network-staking/validator_rdx1svvnmmgdr6sl7llxc8sdu32ys7tn8v6k8quh7e6m6ec83fr3pf6d04) is no longer registered in the active validator set, its validator fee has been raised to 25% (from a former ~2%), and its former website (topradixnode.com) is offline. At epoch 331662 (3 August 2026) 25,392,103 XRD remained delegated to it. The active validator set is drawn from registered validators only (https://docs.radixdlt.com/docs/validator) , and emissions are paid only to stake delegated inside that set (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-penalties-are-calculated-general) , so that stake is currently earning nothing – the largest such position on any validator this wiki documents, and roughly twice the amount stranded on Juicy Stake (/ecosystem/juicy-stake) . The stake units and unstake-claim NFT remain live, so existing stake can still be withdrawn in the normal way. Delegators who still hold its stake units can inspect or unstake via any Radix validator explorer (https://dashboard.radixscan.io/) . Overview While active, TopRadixNode ran validator infrastructure for the Radix network, offering delegated staking (/contents/tech/core-concepts/staking) to XRD holders. Rewards on Radix are funded by network emissions (/contents/tech/core-concepts/network-emissions) and distributed to validators and their delegators in proportion to stake, less the validator's fee. Stakers delegate through the Radix Wallet by selecting one or more validators and delegating XRD; unstaking is subject to the network unstaking delay. Impahla DAO partnership TopRadixNode operated as an official partner node of Impahla DAO (/ecosystem/impahla) , a community project in the Radix ecosystem. The node's on-ledger metadata still carries the "Impahla DAO official partner" label. External Links - Validator on RadixScan (on-ledger status, fee, and stake) (https://dashboard.radixscan.io/network-staking/validator_rdx1svvnmmgdr6sl7llxc8sdu32ys7tn8v6k8quh7e6m6ec83fr3pf6d04) - TopRadixNode on RadixList (https://www.radixlist.com/item/topradixnode) ## Parabox URL: https://radix.wiki/ecosystem/parabox Updated: 2026-08-18 Summary: Parabox was the first metaverse built on Radix, developed by Parabox Studios and since disbanded. It was announced in 2022 as a traversable virtual wo… Project Parabox ($PARA) Type Metaverse / virtual world Developer Parabox Studios Network Radix (/contents/tech/releases/radix-mainnet-babylon) Founded 2022 Status 🔴 Closed – disbanded; token contract still on-ledger Token $PARA (https://dashboard.radixscan.io/resource/resource_rdx1tkvnqnrukez9nldufuvgl2ehv84gu4qk0wa67j8666zsuvgysh3wla) – fixed supply 2,500,000,000 Website parabox.io – lapsed, now a parked domain Overview Parabox was the first metaverse built on Radix, developed by Parabox Studios and since disbanded. It was announced in 2022 (https://www.esports.net/news/paradox-metaverse-announced/) as a traversable virtual world, free to play, in which players could bring digital assets they already owned into a 3D environment. An early walkthrough of the build survives as a community video, Parabox Genesis Plaza first look (https://www.youtube.com/watch?v=Mcq1bjEZOgc) . The stated ambition was a self-sustaining Web3 virtual world owned, operated and extended by its own community, with the world’s assets held on a distributed ledger so that no single operator could switch a player’s holdings off. Both the world and the studio behind it are gone; what follows records what was built and what remains readable on-ledger. Genesis Avatars and $PARA Parabox opened with 10,000 Genesis Avatars (GAT), voxel avatars intended as the first playable NFT (/contents/tech/core-protocols/nfts-on-radix) characters on Radix and usable across every Parabox experience. Reserving one cost 300 XRD. Because the sale ran before Babylon (/contents/tech/releases/radix-mainnet-babylon) brought smart contracts to Radix, buyers received a fungible placeholder token, GENAV, that was to be redeemed for the avatar NFTs afterwards. GAT was to be split 80% to the community that bought in and 20% to the project’s developers. This wiki has not established that the redemption ever ran, and records no resource address for a Genesis Avatar collection. $PARA was the in-world currency, described by the project as a shared treasury token across several Parabox DAOs and as the unit for trading, prize pools, galleries and events. The distribution this page has carried since 2022 – 80% to initial GAT holders, 0.5% seeded to Ociswap (/ecosystem/ociswap) alongside 50,000 XRD of liquidity, and just under 40% to developers – does not reconcile: those shares total more than 120% of the supply. The source they were taken from is no longer reachable, so the error cannot be traced back and the figures should not be relied on. On-ledger status (18 August 2026) The $PARA resource resource_rdx1tkvnqnrukez9nldufuvgl2ehv84gu4qk0wa67j8666zsuvgysh3wla outlived its studio, and it will keep doing so. Read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at epoch 336,030 on 18 August 2026, it holds a fixed supply of 2,500,000,000; minting, burning, freezing and recall are all denied, and the authority rules are locked. Nobody can change any of it, the studio included. Nothing has moved for over nine months. The most recent transaction referencing the resource is txid_rdx1zehh5yt7nj8j…t70cz9dqyrtq08, committed 7 November 2025 – a purchase of roughly 667,000 $PARA for 20 XRD against the token’s pool. The Ociswap (/ecosystem/ociswap) listing, live since 6 October 2023, showed about $2.85 of liquidity on the same read, with zero volume over both 24 hours and 7 days. That is what a closed project looks like from the ledger side: the contract answers, the market does not, and no one is left to speak for either. The distinction between this and dormancy is set out on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) . External links - $PARA on RadixScan (https://dashboard.radixscan.io/resource/resource_rdx1tkvnqnrukez9nldufuvgl2ehv84gu4qk0wa67j8666zsuvgysh3wla) – the live resource - Parabox metaverse announced (https://www.esports.net/news/paradox-metaverse-announced/) – Esports.net, 2022 - Parabox Genesis Plaza first look (https://www.youtube.com/watch?v=Mcq1bjEZOgc) – community walkthrough video ## StakeBros URL: https://radix.wiki/ecosystem/stakebros Updated: 2026-08-18 Summary: StakeBros , also written StakeBroz, was a validator node and delegated staking service on Radix, run by two brothers who described a combined 30 years… Project StakeBros (also written StakeBroz) Type Validator node (/contents/tech/core-concepts/validator-nodes) / staking service Network Radix (/contents/tech/releases/radix-mainnet-olympia) Operators Two brothers, unnamed publicly Founded 2022 Status 🔴 Closed Website stakebros.info – offline; last archived 13 December 2025 (https://web.archive.org/web/20251213221758/https://stakebros.info/) Overview StakeBros, also written StakeBroz, was a validator node (/contents/tech/core-concepts/validator-nodes) and delegated staking (/contents/tech/core-concepts/staking) service on Radix, run by two brothers who described a combined 30 years of IT and DevOps experience between them. Delegators earned a share of network emissions (/contents/tech/core-concepts/network-emissions) in return for stake pointed at the node. The operators published a short pitch (https://web.archive.org/web/20251213221758/https://stakebros.info/) for the node: second-generation AMD EPYC processors, 64 GB of RAM and enterprise NVMe storage; a full backup node kept ready for failover; DevSecOps practice for operations and monitoring; and hosting with Stratode in Germany, chosen on the grounds that no other top-100 Radix validator used that provider, so running there added to the spread of the validator set (/contents/tech/core-concepts/validator-nodes) . Those are the operators’ own claims, recorded here as they were made; none of them was independently verified while the node was running. Status check (18 August 2026) Three readings, all taken on 18 August 2026, put the project past dormancy and into closure as this wiki uses the terms on Radix Ecosystem Operational Status (/contents/resources/radix-ecosystem-operational-status) . The domain has lapsed. stakebros.info publishes no address record and its nameservers are now delegated to park.io (https://park.io) , a service that registers domain names as they expire and resells them. Nothing loads there. The Internet Archive’s last capture of a working site (https://web.archive.org/web/20251213221758/https://stakebros.info/) is dated 13 December 2025, and there is no capture after it. No validator carries the name. Reading the mainnet validator set at epoch 336,030 returns 287 records – 188 currently registered, plus unregistered validators that still hold delegated stake – and none of them publishes StakeBros or StakeBroz as its on-ledger name. The address on this page predates the current network. See below. Why the published staking instructions no longer work Until this revision, the page reproduced StakeBros’ four-step guide: open the Radix Desktop Wallet, go to the Stake/Unstake tab, enter the validator address rv1q087r7c4fhzhvjgq665jc8re9lwjvgamx6qrdl436r92wfuw3hz6x4lp06u, and confirm. Both halves of that instruction belong to Olympia (/contents/tech/releases/radix-mainnet-olympia) , the network Radix ran before Babylon (/contents/tech/releases/radix-mainnet-babylon) . The rv1q… prefix is the Olympia validator address format. Every validator on the network today is addressed as validator_rdx1…, as the 287 records read above all are. The Radix Olympia Desktop Wallet was likewise superseded: its accounts were exported once into the Radix Wallet mobile app, after which, per the migration guide (https://www.radixdlt.com/articles-learn/migrating-accounts-from-the-radix-olympia-desktop-wallet) , “the Olympia account addresses will cease to function and will be flagged as ‘Obsolete’”. The steps are kept above as a record of what the service published, not as instructions to follow. A reader looking for a live validator to delegate to should pick one from the current set instead. External links - stakebros.info (https://web.archive.org/web/20251213221758/https://stakebros.info/) – archived 13 December 2025, the last working capture - How XRD staking emissions, rewards and penalties are calculated (https://learn.radixdlt.com/article/how-xrd-staking-emissions-rewards-penalties-are-calculated-general) – Radix Knowledge Base - Migrating accounts from the Radix Olympia Desktop Wallet (https://www.radixdlt.com/articles-learn/migrating-accounts-from-the-radix-olympia-desktop-wallet) – Radix Knowledge Base ## Scrypto DeFi Challenge URL: https://radix.wiki/contents/history/scrypto-defi-challenge Updated: 2026-08-18 Summary: The Scrypto DeFi Challenge was a five-week remote hackathon organised by RDX Works and hosted on Devpost , running from 20 February to 24 March 2023.… Scrypto DeFi Challenge Type Remote hackathon (Devpost) Organizer RDX Works Dates 20 February – 24 March 2023 (5 weeks) Prize pool $50,000 in XRD Registered 434 participants Submissions 17 Built with Scrypto (/contents/tech/core-protocols/scrypto-programming-language) v0.8+ Status Concluded Category History (/contents/history) Links Devpost (https://scryptodefi.devpost.com/) · Results (https://www.radixdlt.com/blog/scrypto-devpost-defi-challenge-results) The Scrypto DeFi Challenge was a five-week remote hackathon organised by RDX Works and hosted on Devpost (https://scryptodefi.devpost.com/) , running from 20 February to 24 March 2023. It challenged developers to build decentralized finance (/contents/tech/core-concepts/decentralized-finance-defi) applications in Scrypto (/contents/tech/core-protocols/scrypto-programming-language) , Radix’s asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) smart-contract language. The event drew 434 registered participants (https://scryptodefi.devpost.com/) and closed with 17 submissions competing for a $50,000 XRD prize pool. Format and prizes Entries had to be written in Scrypto v0.8 or later and submitted as a pull request to the scrypto-challenges (https://github.com/radixdlt/scrypto-challenges) GitHub repository, with a frontend built using the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) and the then-current Radix Wallet developer preview. Judges scored submissions on the quality and “asset-oriented-ness” of the code, breadth of functionality, creativity of the concept, documentation, and frontend integration. The $50,000 pool was split across overall placings and two category awards: $11,500 for first, $9,500 for second, $7,500 for third, $5,500 each for the best perpetuals and best lending dApps, and $3,500 for each of three honorable mentions. Winners The results (https://www.radixdlt.com/blog/scrypto-devpost-defi-challenge-results) were announced in April 2023: - 1st – FlashyFi by backyard-coder ($11,500), a flash-loan protocol. - 2nd – Stoichiometric by avincigu, Théodore and Guillaume ($9,500), a stablecoin and concentrated-liquidity DEX. - 3rd – ScrillaLending by aus87 and errollgnargnar ($7,500), a Liquity-style lending and stablecoin platform. - Best Perpetuals – Cup Perps by zygomeb ($5,500). - Best Lending – KL Protocol by Atoumbré ($5,500). - Honorable mentions ($3,500 each): MojitoSwap, Kaupa and DefiFunds. The full field All 17 submissions remain public in the 7-defi-devpost (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost) directory of the radixdlt/scrypto-challenges (https://github.com/radixdlt/scrypto-challenges) repository, one folder per entry, and they are the closest thing to a census of what developers reached for first when handed an asset-oriented (/contents/tech/core-concepts/asset-oriented-programming) language. Lending dominates: alongside the placing ScrillaLending (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/scrilla_lending) and KL Protocol (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/kl_protocol) sit Optlend (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/Optlend) , Scrypto Lend Marketplace (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/scrypto-lend-marketplace) (built against Betanet V2 with the Radix dApp Toolkit (/developers/frontend/01-radix-dapp-toolkit) and the developer-preview Android wallet), a real-world-asset lending entry (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/%5BSRWA_lending%5D) , and fleet-vehicle-lending (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/fleet-vehicle-lending) , which applies the same machinery to financing commercial vehicles. The rest of the field went wider than DeFi primitives. RadInsurance (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/RadInsurance) is a decentralized insurance protocol in which insurers stake into a policy and are paid out in proportion to their contribution. AlkyneFi (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/AlkyneFi) pairs investors into a joint contract under an "equally collateralised trade", Tokenvest (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/Tokenvest) is an investment platform where products themselves are on-ledger and funded by other users, investor_companion (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/investor_companion) is a portfolio-side tool, and coupon (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/coupon) is the outlier — a proof of concept issuing e-commerce coupons through the wallet SDK rather than a financial protocol at all. The submissions are prototypes rather than products, and the repository preserves them as filed: Optlend (https://github.com/radixdlt/scrypto-challenges/tree/main/7-defi-devpost/Optlend) opens with its author explaining that they realised the design was wrong two days before the deadline, rewrote it in the time left, and shipped without withdrawal for lending or borrowing positions. That is the texture of a hackathon at the edge of a new language, and it is why the code was judged on "asset-oriented-ness" as much as on completeness. None of the 17 went on to become a production dApp under its challenge name; the ecosystem that followed Babylon (/contents/tech/releases/radix-mainnet-babylon) was built by later teams. Significance The challenge was one of several Scrypto hackathons RDX Works ran to build a developer base ahead of the Babylon mainnet (/contents/tech/releases/radix-mainnet-babylon) launch, which brought Scrypto to production in September 2023. The submissions were experimental prototypes published to the scrypto-challenges (https://github.com/radixdlt/scrypto-challenges) repository – early explorations of lending, perpetuals, stablecoins and DEX designs in an asset-oriented model – rather than production dApps. It followed the network’s earlier in-person developer outreach such as the Scrypto Developer Event (/contents/history/scrypto-developer-event) in Lisbon. External links - Scrypto DeFi Challenge – Devpost (https://scryptodefi.devpost.com/) - Scrypto Devpost DeFi Challenge Results – Radix Blog (https://www.radixdlt.com/blog/scrypto-devpost-defi-challenge-results) - radixdlt/scrypto-challenges – GitHub (https://github.com/radixdlt/scrypto-challenges) ## RADIATOR URL: https://radix.wiki/ecosystem/radiator Updated: 2026-08-17 Summary: Animated Banner V1 (1).mp4 RADIATOR was an organization whose primary focus was on creating and managing the $RDT token, a Web3 cashback utility token… Animated Banner V1 (1).mp4 (Animated_Banner_V1_(1).mp4) RADIATOR was an organization whose primary focus was on creating and managing the $RDT token, a Web3 cashback utility token that rewarded users for participating in the Radix Network. The RADIATOR project established a cashback system and incentive structure for holders of the $RDT token, encouraging users to stake $XRD on their node and engage with the ecosystem's partners. Utility Incentives & Rewards RADIATOR and its partners offered various incentives and rewards to those who participate in their ecosystem. For example, when purchasing a cashback-eligible product, users received not only $XRD cashback but also an $RDT reward based on the amount of spent $XRD. In addition, a portion of every paid incentive and reward was burned, helping to regulate the overall supply. Cashbacks $RDT's cashback system rewarded holders with $XRD when they purchase or use specific products from partnering companies. This created an incentive for users to support the Radix Network while benefiting from the rewards offered by the cashback system. As the first cashback utility token on Radix DLT, $RDT offered supporters airdrops for staking on the RADIATOR node or completing tasks under specific conditions (such as participating in giveaways). Stakers were also eligible for bonuses when completing tasks. Requirements During Olympia the requirements to be eligible for the cashbacks were mostly linked to a specific amount of $RDT on the wallet (with a holding duration over at least 7 days). These amounts variated between 150 and 666 $RDT. Tokenomics $RDT was RADIATOR’s cashback utility token. It aimed to provide a reward ecosystem within the Radix Network through the implementation of a cashback system. Users can earn passive income by staking $XRD on the RADIATOR node and participating in the reward ecosystem. RADIATOR Tokenomics. $RDT Cycle (Market Mechanisms) The $RDT Cycle illustrated the equilibrium of the value via the enabled burnmechanism which was relative to the amount of distributed incentives. The Project itself also invested a percentage of profit - besides the regular Liquidity Providing - in a buyback of $RDT in order to create buypressure. .jpg) $RDT Cycle Burn Mechanism 25% of the total supply was reserved for pure Incentives. The equal amount of incentives would steadily be burned to provide an equilibrium of value for our token. Buyback Mechanism We had implemented a buyback system where a certain percentage of profit was used to buy back $RDT from the market in order to help creating some buypressure. After the 5% Liquidity Providing was finished the percentage of buyback would increase noticeably. Liquidity Provision We steadily provided own liquidity until we reached 5m $RDT which equals 5% Supply according to our Tokenomics Marketing & Development Funds allocated for marketing and development were used for exchange listing fees, marketing collaborations, and commissioned work, promoting the growth and adoption of the $RDT token. Founders + Vesting RADIATOR's founders have extensive experience in project management, customer relations, marketing, sales, and software development. Founder tokens were fully unlocked after three years, with distribution starting one year after the initial token listing date and at 25% intervals every six months. RADIATOR Vesting Schedule RADIATOR Node By staking $XRD on the RADIATOR node, users could earn passive income through staking rewards in $XRD and frequent $RDT airdrops. This encouraged participation and investment in the RADIATOR ecosystem. While RADIATOR operated the node its nominal fee was 1.99%, which the project described as an effective 0.16% at 8% APY. That figure no longer describes the validator – see On-ledger status below. The project published a single Babylon validator address, validator_rdx1s0k2g57…zh09n24s. That validator is still registered and still taking stake, but it has not been RADIATOR’s node for some years; the section below records what the ledger says about it now. How to stake on the RADIATOR node. (https://youtu.be/FFyDrXObz6U) How to stake on the RADIATOR node. Staking Airdrops Delegators who staked $XRD on the RADIATOR node received regular airdrops. Additional irregular airdrops may be available for special participation in the RADIATOR and partner ecosystem. RADIATOR Staking Airdrop Diagram Staking Airdrops were currently on a monthly decrease of 10.000 $RDT until we reached 100.000 $RDT in order to stabilize the price and reduce sellpressure but still attract people to stake on our node. These terms can be adjusted at any time by the team. Website (30 July 2026): radiator.run has no DNS record at all. An unregistered domain can be bought by anyone – four defunct Radix projects' domains have already been re-registered as unrelated landing pages – so the link has been removed from this page's facts table. On-ledger status (17 August 2026) Read live from the Radix Gateway (https://mainnet.radixdlt.com/state/entity/details) at epoch 335790, the address this page publishes as RADIATOR’s Babylon validator – validator_rdx1s0k2g57gxld3nydl8535e2tkp6tduh6pmynd3mf2a3q428zh09n24s – carries the on-ledger name BobbyStake, an info_url of bobby.win (https://www.bobby.win/) and a description giving @XRDBOBBY (https://x.com/xrdbobby) and t.me/bobbyxrd as contacts. None of those belong to RADIATOR. The validator’s name, description and icon_url were all last written at state version 106,564,011, in a transaction stamped 19 July 2024, so the node stopped presenting as RADIATOR more than two years ago and this page has carried the stale identity since. The node itself is healthy and busy: registered, accepting delegated stake, holding 29,106,519.02 XRD – rank 39 of the 188 registered validators (/contents/tech/core-concepts/validator-nodes) – with a further 492,081.47 XRD in its pending-withdrawal vault. The fee is the part a reader arriving from this page would get most wrong. Its stored validator_fee_factor is 0, but a validator_fee_change_request of 0.5 carries an epoch_effective of 310,355, which passed long ago; the Gateway’s own effective_fee_factor reads 0.5. The node charges 50% of staking emissions, not the 1.99% quoted above – the same stored-versus-charged divergence documented at Supreme Stake (/ecosystem/supreme-stake) and Cobra Stakes (/ecosystem/cobra-stakes) . The $RDT resource itself (resource_rdx1t4xkx270sg2hs397dzetux64c3q0gzpa2kjepetrf6mqkz3k35hm9j, total supply 100,000,000) still carries RADIATOR’s original metadata – name “Radiator”, description “Native Radiator Token”, and an info_url and icon_url pointing at radiator.run, which has had no DNS record since at least July 2026. Token metadata is written once and outlives the project that wrote it. ## Maya Protocol URL: https://radix.wiki/ecosystem/maya-protocol Updated: 2026-08-16 Summary: Maya Protocol is a decentralized cryptocurrency exchange ecosystem that enables cross-chain asset trading without relying on wrapped tokens or traditi… Maya Protocol is a decentralized cryptocurrency exchange ecosystem (https://docs.mayaprotocol.com/introduction/readme/getting-started) that enables cross-chain asset trading without relying on wrapped tokens or traditional bridge infrastructure. Launched in 2024, the protocol consists of two main components: MAYAChain, which is currently operational, and AZTECChain, which is under development. https://youtu.be/f8k2tx2NFi4 (https://youtu.be/f8k2tx2NFi4) Radix integration Radix support shipped in September 2024 (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) and its liquidity was withdrawn in full in the spring of 2026. The XRD liquidity pool no longer exists, no swap has touched it since March 2026, and by 16 August 2026 MAYAChain no longer carried the Radix chain client either. The history below is read from Maya's own node and indexer and from the Radix ledger, most recently at 19:09 UTC on 16 August 2026 (mainnet epoch 335,551). The pool, September 2024 to April 2026 Maya's Midgard depth history (https://midgard.mayachain.info/v2/history/depths/XRD.XRD?interval=day&from=1725148800&count=32) records the pool opening on 1 September 2024 with 421,381 XRD from 22 liquidity providers, reaching 11.3 million XRD within a week and 28 providers by 1 October 2024. Its deepest reading came late: 25,416,220 XRD on 12 January 2026 (https://midgard.mayachain.info/v2/history/depths/XRD.XRD?interval=day&from=1759622400&count=120) , ten weeks before it was emptied. Swap activity peaked much earlier. Monthly swap counts (https://midgard.mayachain.info/v2/history/swaps?pool=XRD.XRD&interval=month&count=24) run 7,934 in September 2024 and 24,736 in November 2024, then fall away through 2025 — 4,765 in May, 996 in November — to 509 in February 2026 and 304 in March. The pool recorded 159,415 swaps in total, and none at all in any month from April 2026 onwards. The withdrawal itself was abrupt. Between 23 and 24 March 2026 the daily depth series (https://midgard.mayachain.info/v2/history/depths/XRD.XRD?interval=day&from=1769904000&count=62) falls from 17,055,780 XRD to 629,220 XRD and the provider count from 18 to 16 — roughly 96% of the pool leaving in a single day. A further withdrawal on 25 April took it to 158,476 XRD across 15 providers, and on 29 April 2026 the pool read zero, leaving one nominal member holding a residual 14,044,291,688 liquidity units. Delisted, then disconnected MAYAChain no longer carries the pool at all: the node API (https://mayanode.mayachain.info/mayachain/pool/XRD.XRD) answers pool: XRD.XRD doesn't exist, and XRD is absent from the 26 pools (https://mayanode.mayachain.info/mayachain/pools) the network currently lists. That is the documented consequence of the withdrawal rather than a decision against Radix — under Maya's governance rules (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) an asset is delisted when its providers withdraw completely or its depth falls below the network minimum, and re-listing is permissionless: anyone can seed a new bootstrap pool. The chain client has since been retired as well. As at 16 August 2026 (MAYAChain node v1.132.3) Radix is absent from every part of the network's state that would show it: Maya's inbound addresses (https://mayanode.mayachain.info/mayachain/inbound_addresses) list seven chains — ADA, ARB, BTC, DASH, ETH, THOR and ZEC — and no XRD entry; the four Asgard vaults (https://mayanode.mayachain.info/mayachain/vaults/asgard) , two active and two retiring, each cover ADA, ARB, BTC, DASH, ETH, MAYA, THOR and ZEC, and none holds an XRD address or an XRD balance; and the last-block table (https://mayanode.mayachain.info/mayachain/lastblock) shows no Radix block being observed at all. This page recorded the opposite on 12 August 2026, when the same endpoint still listed XRD with halted: false, so the removal falls between those two dates. The manner of the removal is legible in Maya's Mimir parameters (https://mayanode.mayachain.info/mayachain/mimir) , which still carry the Radix keys: RAGNAROK-XRD-XRD is set to 1 while HALTXRDCHAIN, HALTXRDTRADING and HALTSIGNINGXRD all remain 0. Ragnarok is the wind-down path a THORChain-derived network uses to unwind a pool and return what is left to its providers; the chain was retired through it rather than halted in an emergency. The Radix ledger shows the same standstill from the other side. At epoch 335,551 the inbound vault account (https://dashboard.radixdlt.com/account/account_rdx16ypcqr4eytpx0ly5tgxsgc8xj475y3ncsvpgtel5xguq28jcvam6xp) holds no fungible resources at all and its last transaction was on 30 April 2026; the router component (https://dashboard.radixdlt.com/component/component_rdx1cp7hrk7k0pjavnpt5h6dsel096kzlj96r8ukw2ywqgdc5tlvpvn0as) still holds 791,820.9 XRD and 2.5 xUSDC, and has not been touched since the same day. DeFiLlama (https://api.llama.fi/protocol/maya-protocol) reports Maya's Radix TVL as $0 while its Bitcoin, Ethereum and Zcash chains read in the millions; unlike the $0 it reports for Surge (/ecosystem/surge) , which is an adapter fault, this zero is the ledger. Overview MAYAChain functions as an Automated Market Maker (AMM) (https://docs.mayaprotocol.com/) similar to Uniswap, but with the distinctive capability to utilize cross-chain liquidity. This approach differs from conventional cross-chain exchanges that typically rely on wrapping assets and bridging, methods that have proven vulnerable to security breaches. According to Chainalysis data cited in the protocol's documentation, bridge hacks accounted for $2 billion in losses in 2022, representing 69% of all DeFi hacks. The protocol is a friendly fork of THORChain and employs a unique security model that manages funds directly in on-chain vaults, protected through economic security mechanisms. This is achieved through the implementation of three core technologies: the Tendermint consensus engine, Cosmos-SDK state machine, and GG20 Threshold Signature Scheme (TSS). As of September 2024, Maya Protocol has successfully integrated with multiple major blockchain networks (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) , including Ethereum, Arbitrum, and most recently, the Radix network. At the time of that announcement the protocol was averaging approximately $4 million in daily trading volume, providing a significant gateway for users to move assets between different blockchain ecosystems. Technical Foundation Maya Protocol's architecture is built on the principle of trustless cross-chain trading. Instead of using wrapped tokens or traditional bridges (https://docs.mayaprotocol.com/introduction/readme/getting-started) , the protocol implements a sophisticated system of continuous liquidity pools that enable direct asset exchanges across different blockchains. This approach minimizes counterparty risk and reduces the potential points of failure often associated with cross-chain bridges. The protocol utilizes a three-token system to facilitate its operations: - $CACAO serves as the primary token (https://docs.mayaprotocol.com/introduction/readme/cacao) of the ecosystem, used for transaction fees and as the settlement asset in liquidity pools. All $CACAO was allocated through a fair liquidity auction, with no team allocation. - MAYA functions as a revenue share token (https://docs.mayaprotocol.com/introduction/readme/cacao) , with holders receiving 10% of all swap and transaction fees on MAYAChain in the form of daily $CACAO rewards. - AZTEC is planned as a revenue share token (https://docs.mayaprotocol.com/introduction/readme/cacao) for the upcoming AZTECChain, designed to distribute 10% of all transaction fees to token holders. Recent Developments A significant milestone in Maya Protocol's evolution was the implementation of Streaming Swaps (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) , a feature that improves price execution by breaking large trades into smaller components. This mechanism operates similarly to Time Weighted Average Price (TWAP) trades but with a 24-hour time limit, allowing for better price discovery and reduced slippage. The protocol has also introduced innovative features such as Impermanent Loss Protection (https://docs.mayaprotocol.com/deep-dive/how-it-works/impermanent-loss-protection-ilp) for liquidity providers and a sophisticated economic model (https://docs.mayaprotocol.com/deep-dive/how-it-works/dynamic-inflation) that includes dynamic inflation mechanisms to maintain system stability. Maya Protocol represents a significant advancement in decentralized cross-chain trading infrastructure, offering solutions to many of the security and efficiency challenges that have historically plagued cross-chain asset transfers in the cryptocurrency ecosystem. Architecture Maya Protocol's technical architecture is built on several interconnected components that enable secure cross-chain asset trading. At its core, the protocol utilizes three fundamental technologies: the Tendermint consensus engine, Cosmos-SDK state machine, and GG20 Threshold Signature Scheme (TSS). Bifröst Protocol The Bifröst Protocol serves as the foundation for cross-chain communication (https://docs.mayaprotocol.com/deep-dive/how-it-works/technology) , implementing a system of one-way state pegs. Each node operates a "Bifröst" service that manages chain-specific transactions and converts them into standardized witness transactions for the MAYAChain network. This process ensures that transactions maintain consistent parameters across different blockchain architectures, whether they originate from UTXO-based chains like Bitcoin or account-based chains like Ethereum. State Machine The MAYAChain state machine (https://docs.mayaprotocol.com/deep-dive/how-it-works/technology) coordinates asset exchange logic and manages outgoing transactions. It processes finalized transactions through several stages: - Transaction ordering - State change computation - Delegation to appropriate outbound vaults - Creation and storage of transaction output items in the Key-Value store Threshold Signature Scheme (TSS) The TSS implementation (https://docs.mayaprotocol.com/deep-dive/how-it-works/eli5/what-is-threshold-signature-scheme-tss) represents a significant advancement over traditional multisig approaches. Rather than requiring multiple signatures on a single transaction, TSS enables nodes to collectively forge a vault's lock through a modular process where each node shapes a part of the lock corresponding to its key. This approach offers several advantages: - Lower transaction costs - Blockchain-agnostic implementation - Enhanced privacy as TSS transactions are indistinguishable from standard transactions Vault System Maya Protocol employs two types of vaults (https://docs.mayaprotocol.com/deep-dive/how-it-works/technology) to manage assets: - Asgard TSS Vaults: These serve as primary inbound vaults, operated by large committees (27-of-40 nodes). - Yggdrasil Vaults: Operating as secondary vaults, these handle outgoing transactions and are managed by individual nodes. The system implements a sharding mechanism for Asgard vaults when the network exceeds 40 nodes, allowing for horizontal scaling while maintaining security. Continuous Liquidity Pools The protocol's Continuous Liquidity Pools (CLP) (https://docs.mayaprotocol.com/deep-dive/mayachain-finance/continuous-liquidity-pools) represent a sophisticated evolution of the traditional automated market maker model. The CLP implements a slip-based fee model that responds dynamically to liquidity demand, calculated using the formula: y = (xYX)/(x+X)² Where: - x represents the input amount - X represents the input balance - Y represents the output balance - y represents the output amount This model offers several key benefits: - Always-available liquidity for all supported assets - Transparent, fair pricing without centralized intermediaries - On-chain price feeds for internal and external use - Democratized arbitrage opportunities - Fee convergence to zero as demand subsides Security Features The protocol implements multiple layers of security measures to protect assets and maintain network stability: Conformation Counting To guard against double-spend attacks and chain reorganizations (https://docs.mayaprotocol.com/deep-dive/how-it-works/security) , the protocol employs dynamic confirmation requirements based on transaction value. This is particularly important for chains without instant finality. Solvency Verification The protocol includes an automatic solvency checker (https://docs.mayaprotocol.com/deep-dive/how-it-works/security) that operates in two modes: - Reactive: Continuously compares expected vault balances against actual chain wallet amounts - Proactive: Validates transaction solvency before signing to prevent potential insolvency Transaction Throttling To prevent rapid asset drainage (https://docs.mayaprotocol.com/deep-dive/how-it-works/security) , the protocol implements outbound transaction throttling with a maximum value limit per block (currently 1000 $CACAO worth). Large outbound transactions are automatically spread across multiple blocks, up to 720 blocks (approximately one hour), providing time for security measures to engage if necessary. Governance Mechanisms The protocol employs a minimalist governance approach (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) through the Mimir system, which allows for adjustments to network parameters without requiring direct node communication. This system manages: - Asset listing and delisting - Chain integration processes - Protocol upgrades - Economic parameters - Emergency response procedures The governance system is deliberately limited to prevent nodes from forming coalitions that could compromise network security, while still maintaining necessary protocol flexibility and upgrade capabilities. This technical infrastructure has enabled Maya Protocol to successfully integrate with multiple major blockchain networks, including its recent integration with the Radix network (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) , demonstrating the system's adaptability and robust cross-chain capabilities. Native Tokens Maya Protocol operates using a three-token system, each serving distinct purposes within the ecosystem. The protocol's token architecture is designed to align incentives between different stakeholders while maintaining economic stability. $CACAO $CACAO serves as the primary token of the Maya Protocol ecosystem (https://docs.mayaprotocol.com/introduction/readme/cacao) , with a total supply of 100 million tokens. The token's distribution was conducted through a liquidity auction that allocated 90% of the total supply, with the remaining 10% designated for the Impermanent Loss Protection treasury. Notably, the development team received no direct allocation of $CACAO tokens. $CACAO serves three essential roles in the protocol: - Liquidity Function: $CACAO acts as a settlement asset (https://docs.mayaprotocol.com/introduction/readme/cacao) in the protocol's liquidity pools, where it is paired equally (50:50) with external assets. This mechanism allows the protocol to maintain awareness of asset values it secures through arbitrage-driven price discovery. For every $1 million in multi-chain assets pooled, an equivalent amount of $CACAO is required in the pools. - Security Mechanism: The token provides sybil resistance (https://docs.mayaprotocol.com/introduction/readme/cacao) through a Proof of Bond system, where nodes must commit $CACAO as collateral. This bond serves both to identify nodes and to underwrite assets in the pools. If a node attempts to steal assets, their bond is deducted at 1.5 times the stolen amount to make the affected pools whole. - Economic Incentives: $CACAO facilitates the protocol's economic operations (https://docs.mayaprotocol.com/introduction/readme/cacao) through: - Transaction fee payment - Gas cost subsidization - Reward distribution to network participants $CACAO's value structure (https://docs.mayaprotocol.com/introduction/readme/cacao) includes both a deterministic component and a speculative element. The protocol's 1:1 pool ratio mechanism ensures that $CACAO's market capitalization maintains a minimum value equal to the non-$CACAO asset Total Value Locked (TVL) in the protocol. MAYA MAYA functions as a revenue-sharing token (https://docs.mayaprotocol.com/introduction/readme/cacao) with a fixed supply of 1 million tokens. Its primary purpose is to distribute protocol revenue to token holders while providing initial funding for protocol development. The MAYA token distribution follows this structure: - 15.6% allocated to founders (non-transferable) - 7% to RUNE token holders - 7% to early nodes - 7% to Tier 1 liquidity providers - 1% to Maya Mask NFT holders - 78% to the development fund MAYA token holders receive 10% of all protocol revenue (https://docs.mayaprotocol.com/introduction/readme/cacao) in the form of daily $CACAO distributions. This mechanism ensures that for every $9 earned by liquidity providers and nodes, MAYA holders, including the development team, earn $1, creating alignment between protocol development and long-term value creation. Unlike many protocol tokens, MAYA is not designed for active trading (https://docs.mayaprotocol.com/introduction/readme/cacao) and does not have native liquidity pools on the Maya Protocol. While external exchanges may choose to list the token, its primary function remains revenue distribution rather than trading. AZTEC AZTEC is a planned revenue-sharing token (https://docs.mayaprotocol.com/introduction/readme/cacao) designed for the forthcoming AZTECChain component of the protocol. Following a similar model to the MAYA token, AZTEC will capture 10% of all transaction fees generated on AZTECChain. The AZTEC token is scheduled for launch alongside AZTECChain, which will serve as a smart contract platform within the Maya Protocol ecosystem. AZTECChain will be built as a fork of the Cosmos Hub (https://docs.mayaprotocol.com/) , leveraging established infrastructure and the Cosmos smart contract development ecosystem. When operational, AZTECChain will enable advanced features such as: - Algorithmic stablecoins - Synthetic assets - CEX-style order book trading - Additional DeFi capabilities The protocol's documentation emphasizes that neither chain will artificially inflate yield to drive demand for their respective stablecoins or derivatives, maintaining a focus on sustainable economic design. Features and Services Cross-chain Swaps Maya Protocol's primary value proposition (https://docs.mayaprotocol.com/introduction/readme/roles/swapping) is enabling users to swap digital assets across different blockchain networks without traditional bridging or wrapping mechanisms. The protocol aims to provide superior user experience through open finance protocols and permissionless access to fast chains (like Dash), smart contract chains (such as Ethereum and Kujira), and censorship-resistant chains (like Bitcoin). A notable innovation in the protocol's swap mechanics (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) is the implementation of Streaming Swaps, which break large trades into multiple smaller components over time. This feature operates similarly to Time Weighted Average Price (TWAP) trades but with a 24-hour time limit, offering two key benefits: - The interval component allows arbitrageurs time to rebalance between sub-swaps - The quantity component reduces individual swap sizes to minimize price impact The protocol processes swaps (https://docs.mayaprotocol.com/introduction/readme/roles/swapping) through its Continuous Liquidity Pools, where each transaction involves: - Converting the input asset to $CACAO - Moving $CACAO between pools - Converting $CACAO to the desired output asset The entire process is handled atomically by the state machine, ensuring users never directly interact with $CACAO. Swap costs comprise two components (https://docs.mayaprotocol.com/introduction/readme/roles/swapping) : - A dynamic outbound fee based on network gas costs - Price slippage determined by trade size relative to pool depth Liquidity Provision Liquidity providers (LPs) can participate (https://docs.mayaprotocol.com/introduction/readme/roles/liquidity-providers) in the protocol by depositing assets into liquidity pools. The protocol supports both symmetrical (equal value of two assets) and asymmetrical (unequal values) deposits, though symmetrical additions are recommended for optimal performance. Maya Protocol implements an innovative Impermanent Loss Protection (ILP) mechanism (https://docs.mayaprotocol.com/deep-dive/how-it-works/impermanent-loss-protection-ilp) funded from the protocol reserve, which contains 10% of the total $CACAO supply. Key features include: - Protection begins 50 days after liquidity deposit - Coverage reaches 100% after 150 days if the asset outperforms $CACAO - Coverage reaches 100% after 450 days if $CACAO outperforms the asset - Protection is calculated at withdrawal time - Coverage accrues at 1% daily for outperforming assets and 0.25% daily for underperforming assets Liquidity providers earn returns through multiple streams (https://docs.mayaprotocol.com/introduction/readme/roles/liquidity-providers) : - Swap fees from trading activity - Block rewards from protocol emissions - Continuous income from the protocol's token reserve - Additional rewards based on the Incentive Pendulum mechanism Savings Program The protocol offers a savings feature (https://web.archive.org/web/20241106204039/https://docs.mayaprotocol.com/deep-dive/mayachain-finance/savings) that allows users to earn yield with single-sided asset exposure using synthetic assets. This program operates through a two-step process: - Users mint synthetic versions of their assets - These synthetic assets are locked in a savings vault, with users receiving Saver Units representing their ownership Savers receive 50% of the yield generated by the synthetic collateral (https://web.archive.org/web/20241106204039/https://docs.mayaprotocol.com/deep-dive/mayachain-finance/savings) , with the remaining 50% distributed to liquidity providers. This yield comes from: - Swap fees generated by the underlying liquidity - Protocol rewards - Additional protocol incentives Synthetic Assets Maya Protocol's synthetic asset model (https://docs.mayaprotocol.com/deep-dive/mayachain-finance/synthetic-asset-model) differs from traditional approaches by implementing a hybrid system that is both fully collateralized during existence and 1:1 pegged at redemption. This unique design provides capital efficiency while maintaining price stability. Synthetic assets are backed by constant-product liquidity, with: - 50% collateralization in the underlying asset - 50% collateralization in $CACAO - Pool rebalancing along a price curve to maintain stability - Price shifts subsidized by pool liquidity To manage high demand for synthetic assets (https://docs.mayaprotocol.com/deep-dive/mayachain-finance/synthetic-asset-model) , the protocol implements a Protocol-Owned Liquidity (POL) mechanism where the reserve can add $CACAO to pools when synthetic utilization approaches capacity limits. This helps maintain synthetic asset stability while protecting liquidity providers from excessive leverage exposure. The protocol continuously monitors synthetic asset utilization and automatically adjusts POL positions to maintain optimal market conditions and risk parameters. Governance Maya Protocol employs a minimalist governance approach designed to maintain network security while enabling necessary protocol adjustments. The system deliberately limits governance scope (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) to prevent nodes from communicating or learning each other's identities, which could compromise network security through potential collusion. Asset Management The protocol implements a permissionless asset listing system (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) where users signal demand for new assets by staking in new pools. When the network identifies a new asset, it creates a pool in bootstrap mode, during which swapping is disabled. The selection process occurs periodically, with the network evaluating all bootstrapping pools and listing the one with the highest value. Assets can be delisted through two primary mechanisms (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) : - Complete liquidity withdrawal by all providers - Pool depth falling below minimum requirements When a new bootstrap pool is enabled, its depth is compared to existing active pools. If the new pool has greater depth, it may replace the smallest active pool, which returns to bootstrap mode. Chain Integration The process for adding new blockchain support (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) follows a structured approach: - Community developers create a new Bifröst module - Proposal submission through a MAYAChain Improvement Proposal (MIP) - Review and validation by core developers - Integration into MAYANode software - Network upgrade through node rotation - Chain activation upon 67% node adoption Chain removal follows a similar threshold mechanism, where support is discontinued when 67% of nodes stop monitoring a chain, initiating an automated process to return assets to their owners. Protocol Upgrades The upgrade process (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) encompasses three main components: - Application logic (blockchain operation) - Schema (vault key-value storage) - Network software (TSS protocol management) Upgrades are implemented through an asynchronous process where nodes can update their software during regular network churn cycles. The network automatically activates new features when 67% of nodes adopt the latest version, ensuring smooth transitions without disrupting consensus. Mimir System The Mimir feature (https://docs.mayaprotocol.com/deep-dive/how-it-works/constants-and-mimir) provides flexible control over network parameters through two distinct mechanisms: Node Mimir - Requires two-thirds majority of active nodes for implementation - Only counts votes from currently active nodes - Used for routine parameter adjustments Admin Mimir - Temporary override capability for testing purposes - Cannot control funds or critical security parameters - Planned for eventual removal from the protocol Economic Parameters The protocol maintains several key economic constants (https://docs.mayaprotocol.com/deep-dive/how-it-works/constants-and-mimir) that can be adjusted through governance, including: - Emission curve for $CACAO distribution - Incentive curve for reward allocation - Maximum available pools - Minimum $CACAO pool depth - Pool cycle duration Emergency Procedures Emergency governance actions (https://docs.mayaprotocol.com/deep-dive/how-it-works/governance) are intentionally difficult to coordinate due to the protocol's emphasis on node anonymity. The primary emergency mechanism is Ragnarök, which triggers when node count falls below four, initiating an automated fund distribution process and system shutdown. The protocol includes multiple halt mechanisms (https://docs.mayaprotocol.com/deep-dive/how-it-works/security) for emergency situations: - Individual node pause capability (limited to 720 blocks, approximately one hour) - Cumulative halt extension through multiple node participation - Chain-specific trading halts - Automatic solvency-triggered safety measures These governance mechanisms have enabled Maya Protocol to successfully integrate with multiple blockchain networks while maintaining security and operational efficiency. The recent integration with the Radix network (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) demonstrates the effectiveness of this governance model in facilitating network expansion while preserving decentralized control. Ecosystem User Interfaces Maya Protocol operates as backend infrastructure, requiring user interfaces for interaction. The protocol supports multiple decentralized exchanges and wallet interfaces (https://docs.mayaprotocol.com/introduction/maya-ecosystem/user-interfaces-and-wallets) to provide users with various access points to its services. ThorWallet DEX serves as a primary interface (https://docs.mayaprotocol.com/introduction/maya-ecosystem/user-interfaces-and-wallets) offering both web and mobile access. Key features include: - Support for all Maya Protocol-compatible Layer 1 blockchains - Native $CACAO and MAYA token management - Cross-chain swap functionality - Liquidity position management - Integration with hardware wallets like Ledger - Comprehensive saver position management El Dorado provides a web-based interface (https://docs.mayaprotocol.com/introduction/maya-ecosystem/user-interfaces-and-wallets) with distinctive features: - Support for all Maya-supported Layer 1 blockchains - Unique Polkadot blockchain integration - Compatible with XDEFI and Keystore wallets - Full liquidity management capabilities $CACAOSwap offers specialized features (https://docs.mayaprotocol.com/introduction/maya-ecosystem/user-interfaces-and-wallets) including: - Integration with multiple wallet types including Keystore, MetaMask, XDEFI, Keplr, and Leap - Cross-chain swap functionality - Liquidity and saver position management - Support for all Maya-supported Layer 1 blockchains Infrastructure Tools MayaScan serves as the primary blockchain explorer (https://docs.mayaprotocol.com/blockchain-explorer/mayascan) for Maya Protocol, offering: - Comprehensive transaction tracking - Swap and liquidity monitoring - Network status oversight - Node performance tracking - Secure peer-to-peer messaging capability - Native token and NFT trading support through Ordinals technology and Memos The Maya Info Bot provides real-time network monitoring (https://docs.mayaprotocol.com/introduction/maya-ecosystem/tools) across multiple channels (Telegram, Discord, and X), tracking: - Large asset transfers - Significant swap transactions - Liquidity pool statistics - $CACAO price movements - Mimir parameter adjustments - Network alerts and updates Mayans.app combines social media elements with decentralized finance (https://docs.mayaprotocol.com/introduction/maya-ecosystem/tools) , offering: - Secure private messaging - MRC-20 token trading and staking - DeFi gaming integration - Market trend signals - Social network features for the Maya community Digital Assets Maya Masks represents the protocol's official NFT initiative (https://docs.mayaprotocol.com/deep-dive/maya-masks) , consisting of 1,689 Genesis Maya Masks. The collection features: - Two distinct categories: Golden Masks and regular Masks - Integration with Web3 avatars - Utility features including: - $CACAO staking rewards (planned for AZTECChain launch) - Community event access - $MAYA and $AZTEC token airdrops (4.5 tokens each per mask) - Enhanced benefits for Golden Mask holders The ecosystem supports multiple wallet solutions (https://docs.mayaprotocol.com/introduction/maya-ecosystem/user-interfaces-and-wallets) : XDEFI Wallet - Multi-ecosystem support for over 30 native blockchains - EVM and Cosmos chain compatibility - Hardware wallet integration with Ledger and Trezor - Native support for Bitcoin, Ethereum, Solana, and other major networks Hardware Wallet Support KeepKey integration (https://docs.mayaprotocol.com/introduction/maya-ecosystem/user-interfaces-and-wallets) provides: - Secure storage for $CACAO and $MAYA tokens - Native cross-chain swap capability in firmware - Support for Maya Layer 1 assets - Integration with multiple EVM and Cosmos chains Recent Developments The ecosystem continues to expand, with the recent integration of the Radix network (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) marking a significant milestone. This integration enables trustless cross-chain asset swaps between Radix and other supported networks, providing new opportunities for asset flow and ecosystem growth. The integration is particularly notable for enabling access to Maya Protocol's $63 billion TVL across supported chains for Radix users, while maintaining the protocol's commitment to security and decentralization. Technical Infrastructure Node Operation The Maya Protocol network is serviced by MAYANodes (https://docs.mayaprotocol.com/introduction/readme/roles/node-operators) , which are designed to operate in a decentralized and anonymous manner. The network initially targets 120 nodes, each comprising multiple independent servers that work cooperatively to facilitate cross-chain swapping capabilities. The node infrastructure employs several innovative features (https://docs.mayaprotocol.com/) to maintain decentralization and security: - Capped Proof of Bond validator selection to maintain a high Nakamoto Coefficient - Periodic Validator Churning every 5 days to prevent stagnation - Asynchronous Network Upgrades allowing gradual transition to new protocol versions - Chain-agnostic Bifrost Protocol for managing various blockchain connections Maya Protocol implements a unique security approach (https://docs.mayaprotocol.com/introduction/readme/roles/node-operators) for node operations. Unlike traditional staking systems, nodes must directly pay for their bond rather than accepting delegation. This requirement ensures that economic security assumptions remain valid, as a node operator who pays $1 million for their bond would only attempt theft if they could access more than $1 million in funds. While public delegation is not permitted, the protocol allows for private delegation (https://docs.mayaprotocol.com/introduction/readme/roles/node-operators) under specific conditions: - Limited to 6 bonders per node - Requires direct whitelisting by node operators - Assumes trust relationships between operators and bonders - Maintains identical network operation regardless of delegation status Liquidity Nodes Model The Liquidity Nodes model (https://docs.mayaprotocol.com/deep-dive/how-it-works/liquidity-nodes) represents a significant innovation in blockchain infrastructure, addressing common issues with traditional staking systems. Instead of requiring idle staked funds, nodes bond Liquidity Pairs, offering three key advantages: The model maintains slashing mechanisms (https://docs.mayaprotocol.com/deep-dive/how-it-works/liquidity-nodes) while requiring over 75% of capital to be bonded by nodes, with an ideal target of 87% to prevent Sybil attacks. Slashed funds are transferred to Protocol Owned Liquidity, with provisions for both manual and automatic forgiveness. The system distributes two types of rewards: - Node Exclusive Rewards (NER): Reserved for liquidity bonded to MAYANodes - Liquidity Pool Rewards (LR): Distributed to all liquidity providers based on their share The model achieves superior capital efficiency (https://docs.mayaprotocol.com/deep-dive/how-it-works/liquidity-nodes) through: - Simultaneous earning of node rewards and liquidity rewards - Reduced bonding risk through continued liquidity rewards during standby states - Creation of deeper liquidity pools while maintaining network security - Implementation of a self-reinforcing liquidity flywheel effect Economic Model The protocol implements a dynamic inflation mechanism (https://docs.mayaprotocol.com/deep-dive/how-it-works/dynamic-inflation) that can be enabled or disabled through node voting. This feature activates when $CACAO held outside liquidity pools exceeds 10% of the non-reserve supply. The inflation rate follows the formula: Rate of inflation = (1-y) * 40% + 1% where y represents the percentage of $CACAO in pools relative to total supply. The protocol's economic balance (https://docs.mayaprotocol.com/deep-dive/how-it-works/incentive-pendulum) is maintained through an Incentive Pendulum mechanism that adjusts rewards between nodes and liquidity providers based on network conditions: - Optimal State: Maintains roughly 85% bonded LP and 15% pooled LP - Unsafe State: Triggers when pooled capital exceeds 25% of bonded capital - Automatic adjustment of reward distribution to maintain economic security Network Security The protocol implements multiple security layers (https://docs.mayaprotocol.com/deep-dive/how-it-works/security) : Proactive Measures - Conformation counting for double-spend protection - Outbound transaction throttling - Automated solvency checking - Unauthorized transaction detection - Security event flagging Reactive Controls - Node operator triggered halts - Chain-specific trading suspensions - Emergency shutdown procedures - Automatic security alerting system These infrastructure components work together to enable Maya Protocol's cross-chain functionality while maintaining security and efficiency. The recent successful integration with the Radix network (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) demonstrates the robustness of this infrastructure in supporting network expansion while maintaining operational security. Future Development Roadmap Overview Maya Protocol's development roadmap for 2024 focuses on expanding chain integrations, improving user experience, and introducing new technical features. The protocol has already completed several major objectives (https://docs.mayaprotocol.com/introduction/roadmap-2024) , including: Completed Initiatives - Savers functionality, enabling users to earn fees without direct $CACAO exposure - Arbitrum integration, allowing Ethereum assets on the Arbitrum chain to participate in swaps and liquidity actions - Streaming Swaps implementation, which improves large trade execution by breaking them into smaller components - Radix network integration (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) , enabling trustless cross-chain asset swaps and creating new routes for TVL flow AZTECChain Development A significant component of Maya Protocol's future development (https://docs.mayaprotocol.com/) is AZTECChain, a smart contract platform being developed as a fork of the Cosmos Hub (Gaia). This initiative will enable: - Algorithmic stablecoin implementation - Derivatives such as Synths - CEX-style order book trading - Enhanced DeFi capabilities The protocol emphasizes a conservative approach to these features, noting that algorithmic stablecoins will be delayed upon launch to ensure proper economic design and testing through bounties. Additionally, neither chain will subsidize yield to artificially inflate demand for stablecoins or derivatives. Planned Integrations The protocol's roadmap (https://docs.mayaprotocol.com/introduction/roadmap-2024) includes several major blockchain integrations: THORChain DEX Aggregation - Enabling swaps between THORChain and MAYAChain assets - Creating broader liquidity networks across protocols Privacy-Focused Integration - Planned Zcash integration to support $ZEC deposits - Expansion into privacy-preserving transaction capabilities Additional Network Support - Cardano integration for $ADA token support - Memoless transaction capabilities to expand wallet and chain compatibility - Additional blockchain integrations to be announced Technical Enhancements The development team is working on several technical improvements to enhance the protocol's functionality: Memoless Transactions This feature (https://docs.mayaprotocol.com/introduction/roadmap-2024) will expand the protocol's compatibility by: - Enabling integration with chains that don't use memos - Broadening potential wallet integrations - Simplifying user experience across different blockchain ecosystems Infrastructure Scaling The protocol's architecture (https://docs.mayaprotocol.com/deep-dive/how-it-works/technology) allows for continuous improvement through: - Asynchronous network upgrades - Sharded Asgard vault scaling - Enhanced cross-chain communication protocols Economic Evolution The protocol's economic model (https://docs.mayaprotocol.com/deep-dive/how-it-works/dynamic-inflation) continues to evolve through: - Refinement of the dynamic inflation mechanism - Enhancement of the Incentive Pendulum system - Development of sustainable yield generation methods Integration Impact The recent Radix integration (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) demonstrates Maya Protocol's commitment to expanding cross-chain liquidity and accessibility. This integration has: - Enabled trustless cross-chain asset swaps with Radix - Created new routes for TVL flow across supported chains - Provided Radix ecosystem participants access to Maya Protocol's liquidity - Enhanced key network metrics including TVL, weekly transactions, and user acquisition The successful implementation of Streaming Swaps (https://www.radixdlt.com/blog/maya-protocol-integration-is-now-complete) during this period also showcases the protocol's ability to introduce complex features while maintaining security and efficiency. This feature has proven particularly valuable for large trades, as it: - Reduces slippage through trade size optimization - Improves price execution through temporal distribution - Allows arbitrageurs to maintain pool balance during execution These developments suggest a strong foundation for future growth and integration, with the protocol positioned to continue expanding its cross-chain capabilities while maintaining its commitment to security and decentralization. ## CrumbsNode URL: https://radix.wiki/ecosystem/crumbsnode Updated: 2026-08-16 Summary: CrumbsNode is the Radix validator node at the centre of the CrumbsUp ecosystem. CrumbsUp is a no-code platform on Radix for launching and running DAOs… CrumbsNode Type Radix validator node · part of the CrumbsUp ecosystem Status 🟢 Active – registered, accepting delegations Native token $CRUMB (governance token, 1 billion fixed supply) Validator address validator_rdx1sv…f2nju2zz (https://dashboard.radixdlt.com/network-staking/validator_rdx1svfvxj0glmg0ea2m0nqm47qlfypj2rcmp74t7p4wgjx2m0f2nju2zz) Total stake 74,487,256.22 XRD – rank 24 of 187 registered validators Unstaking 15,369,221.78 XRD in the pending-withdrawal vault, awaiting claim Validator fee 25% charged (the stored validator_fee_factor still reads 0 – see below) Uptime (30d) 100%, as measured on the Radix Dashboard at epoch 326958 (17 July 2026) Staker reward Monthly $CRUMB airdrop to CrumbsNode delegators Website crumbsup.io (https://crumbsup.io) · X (https://x.com/crumbs_up) On-ledger Read live from the Radix Gateway (/contents/tech/core-protocols/radix-gateway-api) at mainnet epoch 335,407 (16 August 2026, 07:09 UTC) CrumbsNode is the Radix validator node (https://dashboard.radixdlt.com/network-staking/validator_rdx1svfvxj0glmg0ea2m0nqm47qlfypj2rcmp74t7p4wgjx2m0f2nju2zz) at the centre of the CrumbsUp ecosystem. CrumbsUp is a no-code platform on Radix (/contents/tech/core-protocols/radix-engine) for launching and running DAOs (/ecosystem) – providing proposal and voting mechanisms that a DAO can operate with its own governance token, without requiring in-house smart-contract development. CrumbsNode is a Radix-native validator; it does not operate on other chains. The $CRUMB token $CRUMB is the governance token of the Crumbs ecosystem, issued on Radix with a fixed supply of 1 billion. Delegating XRD to CrumbsNode entitles stakers to a recurring monthly $CRUMB airdrop, which is how the project distributes governance rights and rewards ecosystem participation, in addition to ordinary XRD staking emissions net of the validator fee. Validator Read live from the Radix Gateway (/contents/tech/core-protocols/radix-gateway-api) at mainnet epoch 335,407 (16 August 2026, 07:09 UTC), CrumbsNode is registered and accepts delegated stake, with 74,487,256.22 XRD in its stake vault – rank 24 of the 187 registered validators. That is a fall from the ≈89.9 million XRD and rank 19 this page recorded at epoch 326958 on 17 July 2026, and it puts the node outside the top twenty for the first time in this page's history. The XRD has not moved to another validator. A further 15,369,221.78 XRD sits in the validator's pending_xrd_withdraw_vault – stake that has been withdrawn from the stake vault and is waiting on the network's unstaking delay before its holders can claim it with the claim NFTs (/contents/tech/core-concepts/liquid-stake-units) issued at unstake time. The two vaults together hold 89,856,478.01 XRD, within 0.1% of the figure this page previously carried, which is consistent with the drop being unstaking in flight rather than stake redelegated elsewhere. Claims are being drawn down against it: on 14 August 2026 at 19:29 UTC (https://dashboard.radixdlt.com/transaction/txid_rdx126htz82us2973kqdzzuymc3h27th6p77ztnyt8q32atv7njvumnsx90esn/summary) a single claim_xrd call took 304,991.96 XRD out of it. Its fee is 25%, which the ledger states in the change request rather than in the field named for it: the stored validator_fee_factor reads 0, while validator_fee_change_request carries new_fee_factor 0.25 with an epoch_effective of 310355, an epoch long past. The effective request is the fee charged; the substate field is stale. The same divergence holds across a large minority of the validator set (/contents/tech/core-concepts/validator-nodes) . (Stake and uptime make clear the node is actively operating, even as public-facing platform updates on crumbsup.io (https://crumbsup.io) have been quiet; the site itself is live, a single-page app describing CrumbsUp as “a Hub for DAOs in the Radix ecosystem”.) How to stake Open the Radix Wallet (https://wallet.radixdlt.com) , go to Stake, paste the CrumbsNode validator address (validator_rdx1sv…f2nju2zz), delegate XRD and confirm. Staked XRD earns standard network rewards (net of the 25% fee) plus eligibility for the monthly $CRUMB airdrop; unstaking follows the network's standard delay. Related - Cobra Stakes (/ecosystem/cobra-stakes) – Radix validator - Supreme Stake (/ecosystem/supreme-stake) – Radix validator - Radix Ecosystem directory (/ecosystem) ## Cobra stakes URL: https://radix.wiki/ecosystem/cobra-stakes Updated: 2026-08-16 Summary: Cobra Stakes is a validator node on the Radix network, providing Proof-of-Stake infrastructure that delegators use to help secure the network and earn… Cobra Stakes Type Radix validator node Status 🟢 Active – registered, accepting delegations Validator address validator_rdx1sw…32aavw9t (https://dashboard.radixdlt.com/network-staking/validator_rdx1swq3mn0u9qf68j6g3nugw3udakecggfgpu9e4yphe2rcqc32aavw9t) Total stake 92,918,353.30 XRD – rank 17 of 187 registered validators Validator fee 15% charged (the stored validator_fee_factor still reads 0.01 – see below) Uptime (30d) 100%, as measured on the Radix Dashboard at epoch 326958 (17 July 2026) Website cobrastakes.com (https://cobrastakes.com) – domain expired (16 August 2026) On-ledger Read live from the Radix Gateway (/contents/tech/core-protocols/radix-gateway-api) at mainnet epoch 335,407 (16 August 2026, 07:09 UTC) Cobra Stakes is a validator node (https://dashboard.radixdlt.com/network-staking/validator_rdx1swq3mn0u9qf68j6g3nugw3udakecggfgpu9e4yphe2rcqc32aavw9t) on the Radix (/contents/tech/core-protocols/radix-engine) network, providing Proof-of-Stake infrastructure that delegators use to help secure the network and earn staking (/contents/tech/core-concepts/staking) rewards. It is one of the network's larger validators and has no public-facing web presence: its branded domain, cobrastakes.com (https://cobrastakes.com) , has expired, while the node itself keeps proposing. Validator Read live from the Radix Gateway (/contents/tech/core-protocols/radix-gateway-api) at mainnet epoch 335,407 (16 August 2026, 07:09 UTC), Cobra Stakes is registered, accepts delegated stake, and holds 92,918,353.30 XRD – rank 17 of the 187 registered validators among 287 validator components on mainnet. Its stake has grown modestly since this page's previous reading of ≈92.4 million XRD at epoch 326958 on 17 July 2026. Its fee is 15%, and the ledger states that in two places rather than one. The validator's stored validator_fee_factor still reads 0.01, while its validator_fee_change_request carries new_fee_factor 0.15 with an epoch_effective of 289094 – an epoch long past. The request that has come into effect is the fee actually charged; the substate field is the stale one. The same divergence holds across a large minority of the validator set (/contents/tech/core-concepts/validator-nodes) , so a fee read from validator_fee_factor alone can be wrong by a wide margin. The website Cobra Stakes has no working site. Fetched with a browser user agent on 16 August 2026, both cobrastakes.com and www.cobrastakes.com return HTTP 200 with a 10,881-byte registrar page titled “Your domain is expired” – a step down from the “Coming soon” placeholder this page recorded in July. The validator's on-ledger info_url metadata still points at https://www.cobrastakes.com, so a wallet or explorer following that link lands on the expired-domain page. That is a presentation failure rather than an operational one, and the distinction matters: an expired domain says nothing about whether a node is proposing. Leaf Node (/ecosystem/leafnode) is the contrasting case, where the website going dark coincided with an on-ledger unregister. Here the ledger record is unbroken. How to stake To delegate to Cobra Stakes, open the Radix Wallet (https://wallet.radixdlt.com) , go to the Stake section, paste the validator address (validator_rdx1sw…32aavw9t), enter the amount of XRD to delegate and confirm the transaction. Staking rewards accrue automatically each epoch, net of the validator fee; unstaking is subject to the network's standard unstaking delay. Related - CrumbsNode (/ecosystem/crumbsnode) – Radix validator - Supreme Stake (/ecosystem/supreme-stake) – Radix validator - Validator nodes (/contents/tech/core-concepts/validator-nodes) – how the validator set works - Radix Ecosystem directory (/ecosystem) ## Flexathon URL: https://radix.wiki/contents/history/flexathon Updated: 2026-08-16 Summary: Flexathon [ /‘flɛksəθɔn/ ] was a solo hackathon run by Dan Hughes, founder of Radix, over his vacation in late 2020. Its stated mission, set out in hi… Flexathon Type Solo hackathon / proof-of-concept prototype Built by Dan Hughes, founder of Radix Dates 23 November – 11 December 2020 (stated deadline) Goal A working demonstration of cross-shard atomic composability under Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) Status Concluded. Prototype only — never released, and not a precursor to any shipped network. Public diary Google Doc (https://docs.google.com/document/d/1HkywxibycsVjq5e63_ZgyRycBRI3Myya3xLC56tVOP8/edit) — last entry Day 3 (25 Nov 2020) Code github.com/DanoshiFusermoto/hackation — named in the diary, returns 404 today Demo Radix Labs recording (https://www.youtube.com/watch?v=nXhABv1B9lk) , published 19 May 2021 Related Olympia (/contents/tech/releases/radix-mainnet-olympia) · Xi’an (/contents/tech/releases/radix-mainnet-xian) Category History (/contents/history) Flexathon [ /‘flɛksəθɔn/ ] was a solo hackathon run by Dan Hughes, founder of Radix, over his vacation in late 2020. Its stated mission, set out in his public diary (https://docs.google.com/document/d/1HkywxibycsVjq5e63_ZgyRycBRI3Myya3xLC56tVOP8/edit) , was to have “a working demonstration of some the fundamental technology innovations myself and the Radix team have been pioneering” by 11 December 2020 — specifically, atomicity and composability across shards under the Cerberus (/contents/tech/core-protocols/cerberus-consensus-protocol) consensus protocol. The result was demonstrated in a Radix Labs session, Radix Founder Demonstrates Cross Shard Atomic Composability (https://www.youtube.com/watch?v=nXhABv1B9lk) , published on 19 May 2021. The brief, and why it was set Hughes gave two reasons for spending vacation time on it. The first was simply that he missed doing hackathons. The second was adversarial: the Cerberus paper (/contents/tech/research/cerberus-whitepaper) — Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing, co-authored with Jelle Hellings, Joshua Primero and Mohammad Sadoghi and submitted to arXiv on 10 August 2020 (https://arxiv.org/abs/2008.04450) — had been public for three months, and in his words “some in the crypto community has been spreading doubt. So, enough of quietly working, time to flex some of our tech!” The scope was set deliberately narrow. The diary describes the build as “an independent implementation of Cerberus which is intended to showcase the possibilities of atomicity and composability in a sharded environment”, assembled from a mix of existing Radix core code, earlier Tempo and CAST work, components of Hughes’ own R&D framework, and new code written for the occasion. It also carried an unusually blunt disclaimer for a founder demo: the prototype “WILL be buggy, it WILL crash, it will NOT be commercial grade, unit tests will be minimal and some of the code patterns will be questionable”, and it would “not bear any resemblance to any of the networks planned for release on our roadmap, other than exhibiting the fundamentals of the Cerberus protocol”. What the public diary records The diary was published as a running log rather than a write-up — “a direct feed from me… full strength, non-filtered Dan incoming” — with each day given a topline, a “The Good” column and a “Challenges” column. Three days were recorded before it stopped: - Day 1 (23 Nov) — preparation. Collating the networking, database, event-handler and cryptographic primitives to build on top of. - Day 2 (24 Nov) — connectivity between nodes, simple atoms and particles, basic gossip; atoms could be sent around the network. - Day 3 (25 Nov) — atom pool voting implemented and tested at a network size of 32 nodes, with a start made on block generation and a proof-of-work implementation. Days 1 and 2 each closed with a short video posted to Hughes’ Twitter account, linked from the diary. The primary record and its gaps Almost everything publicly checkable about the Flexathon comes from two artefacts, and both are incomplete. The diary is the primary source, and it is 4,214 characters long and ends at Day 3 — three days into a nineteen-day run. Nothing in the public document covers the remaining sixteen days, the cross-shard atomicity milestone itself, or whether the 11 December deadline was met. Descriptions of the Flexathon that list “node connectivity, sending atoms, pool voting, early block production and proof-of-work” as its output are therefore describing the first three days, not the project. The diary names github.com/DanoshiFusermoto/hackation as the third of its four follow-along sources. That repository returns 404. Hughes’ GitHub account carries two public repositories today — Hyperscale (https://github.com/DanoshiFusermoto/Hyperscale) (created March 2025) and a fork of Apache Milagro — and neither is the Flexathon build. No public copy of the prototype’s source is known to survive. One archived capture of the repository page survives, and it is dated Day 1. The Internet Archive holds a single successful snapshot of github.com/DanoshiFusermoto/hackation, taken on 23 November 2020 at 21:45 UTC (https://web.archive.org/web/20201123214521/https://github.com/DanoshiFusermoto/hackation) — the evening of the diary's first day. It records a repository already at 49 commits on master, with one branch, no tags, no releases, no description and no topics; two watchers, no stars, no forks; a single top-level entry named core; and a latest commit message reading “Added empty atom to genesis block to solve NPE”. Its language breakdown is Java 100%, consistent with the diary's account of a build assembled from existing Radix core code rather than written from nothing, and a reminder that the Flexathon shares no lineage with the Rust hyperscale-rs (/contents/tech/research/hyperscale-rs) work that carries sharding today. The capture is the landing page, not the tree, so it does not recover a single line of the source. The archive's next visit, on 21 December 2022, records a redirect rather than a page — placing the repository's removal between those two dates. Barring a private copy, the prototype's code should be treated as lost. What does survive is the demonstration: a 46-minute Radix Labs recording (https://www.youtube.com/watch?v=nXhABv1B9lk) published on 19 May 2021, five months after the deadline the diary set. What it did and did not lead to The Flexathon achieved what it was built to achieve: a running, if fragile, demonstration that atomic composability across shards was implementable, at a moment when the claim rested on a whitepaper and an academic paper rather than on code. It is worth being precise about what followed, because the prototype is sometimes described as a foundation for the network that shipped. Olympia (/contents/tech/releases/radix-mainnet-olympia) , the first Radix public network, launched on 28 July 2021 running Radix Engine (/contents/tech/core-protocols/radix-engine) v1 and unsharded consensus with a single shard group. Alexandria (/contents/tech/releases/radix-developer-environment-alexandria) (15 December 2021) came after Olympia, not before it, and was a Scrypto developer environment rather than a mainnet. Babylon (/contents/tech/releases/radix-mainnet-babylon) (28 September 2023) also runs a single shard group. The cross-shard atomic composability the Flexathon demonstrated in December 2020 has, in other words, never run on a Radix production network. Multiple shard groups are scheduled for Xi’an (/contents/tech/releases/radix-mainnet-xian) , dated 2027, and the sharded execution work now proceeds in hyperscale-rs (/contents/tech/research/hyperscale-rs) rather than from any Flexathon code. Hughes’ own diary anticipated the distinction: the prototype was never meant to resemble the roadmap networks, only to prove the fundamentals were real. External links - Flexathon diary — Dan Hughes (Google Docs) (https://docs.google.com/document/d/1HkywxibycsVjq5e63_ZgyRycBRI3Myya3xLC56tVOP8/edit) - Radix Founder Demonstrates Cross Shard Atomic Composability — Radix Labs (YouTube, 19 May 2021) (https://www.youtube.com/watch?v=nXhABv1B9lk) - Cerberus: Minimalistic Multi-shard Byzantine-resilient Transaction Processing — arXiv (10 Aug 2020) (https://arxiv.org/abs/2008.04450) - DanoshiFusermoto — GitHub (Dan Hughes) (https://github.com/DanoshiFusermoto) ## DApp In a Day Workshop #5 - St Mary’s University URL: https://radix.wiki/contents/history/dapp-in-a-day-workshop-5 Updated: 2026-08-16 Summary: DApp In A Day #5 was the fifth in the DApp In A Day series of Scrypto developer workshops, sponsored by Shardspace, part of the broader Radix universi… DApp In a Day Workshop Event Type Scrypto / Web3 Developer Workshop (DApp In A Day #5) Status Completed Date & Time 26th February 2025, 10:00–17:00 Location SMU ESports Arena, Waldegrave Road, Twickenham, TW1 4SX ( Map (https://maps.app.goo.gl/sz3zYwxhUYH196Ly5) ) Sponsor & Mentor Shardspace (Mentor: Ascarbek) Category History (/contents/history) Related Links Event Video (https://youtu.be/tKd2PQOXvUI) · Telegram (https://t.me/RadixHackathon) · Radix on X (https://x.com/radixdlt/status/1883637405447799180) Related Topics DApp In A Day Workshops (/contents/history/dapp-in-a-day-workshop-1) · Brunel Hack 25 (/contents/history/brunel-hack-25) · History of Radix (/contents/history) DApp In A Day #5 was the fifth in the DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) series of Scrypto developer workshops, sponsored by Shardspace, part of the broader Radix (/contents/history) university-outreach programme. It was held at St Mary’s University’s ESports Arena on the 26th of February, 2025. ShardSpace (https://shardspace.app/) Event Sponsor - Shardspace https://youtu.be/tKd2PQOXvUI (https://youtu.be/tKd2PQOXvUI) Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: Wednesday, 26th February, 2025 TIME: 10:00 - 17:00 LOCATION: SMU ESports Arena, Waldegrave Road, Twickenham, TW1 4SX. MENTORS: Ascarbek (https://t.me/ascarbek) (Shardspace) REGISTRATION: Eventbrite (https://www.eventbrite.co.uk/e/dapp-in-a-day-web3-workshop-workshop-6-tickets-1249180254769) https://maps.app.goo.gl/sz3zYwxhUYH196Ly5 (https://maps.app.goo.gl/sz3zYwxhUYH196Ly5) St Mary’s University, which hosted the event, advertised it on Eventbrite as “DApp in a Day – Web3 Workshop – Workshop 6” (https://www.eventbrite.co.uk/e/dapp-in-a-day-web3-workshop-workshop-6-tickets-1249180254769) , counting its own workshops rather than the Radix series. This wiki records it as #5, the numbering used across the other DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) event records. Media https://x.com/radixdlt/status/1883637405447799180 (https://x.com/radixdlt/status/1883637405447799180) https://x.com/radixdlt/status/1894087468460409046 (https://x.com/radixdlt/status/1894087468460409046) “The Web3 workshop was incredible and huge thanks to the Radix Wiki team for making it such an inspiring event. Already looking forward to the next one!” (https://x.com/dinesh_adith/status/1895484194933125286) - Dinesh “A massive shoutout to Radix.Wiki and to St Mary’s University for hosting this event in their cutting-edge Esports Arena—a perfect example of how technology is rapidly evolving!” (https://x.com/Ashmy3101/status/1895483484749377945) - Ashmy https://x.com/RadixWiki/status/1884354464225566805 (https://x.com/RadixWiki/status/1884354464225566805) https://x.com/Adam_XRD/status/1894097346947936731 (https://x.com/Adam_XRD/status/1894097346947936731) https://x.com/Radix_ecosystem/status/1891837989321424911 (https://x.com/Radix_ecosystem/status/1891837989321424911) https://x.com/RadixWiki/status/1894710939326251093 (https://x.com/RadixWiki/status/1894710939326251093) https://x.com/radixdlt/status/1910616454829105605 (https://x.com/radixdlt/status/1910616454829105605) https://x.com/RadixWiki/status/1896607305384255898 (https://x.com/RadixWiki/status/1896607305384255898) Gallery Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a “Submission”). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## Mox Studio URL: https://radix.wiki/ecosystem/mox-studio Updated: 2026-08-15 Summary: Status note (August 2026): moxstudio.net is still being served, but its TLS certificate expired on 7 June 2026, so browsers refuse the connection and… Status note (August 2026): moxstudio.net is still being served, but its TLS certificate expired on 7 June 2026, so browsers refuse the connection and the site reads as offline — which is why the citations below stay pointed at the Internet Archive (https://web.archive.org/web/20260515140836/https://moxstudio.net/) . Both of the studio’s app-store listings have since been withdrawn, while the MOX token continues to trade on-ledger. Evidence in “Status (August 2026)” at the foot of this page. Mox Studio (https://web.archive.org/web/20260515140836/https://moxstudio.net/) is a gaming company specializing in Play-to-Earn (P2E) mobile and web-based games built on the Radix distributed ledger technology (DLT) platform. Founded in 2023, the company develops games that integrate cryptocurrency rewards through their native MOX token (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) , allowing players to earn digital assets while playing. Overview Mox Studio emerged from its founders' background in digital product management, marketing, and IT, with over 15 years of corporate experience (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) . Initially entering the blockchain industry in 2017, the team transitioned through various phases of crypto industry involvement before establishing Mox Studio. The company's primary focus is on creating engaging gaming experiences that showcase Radix DLT capabilities to a broader audience. Mox Studio's business model combines traditional gaming elements with blockchain technology, offering players the opportunity to earn cryptocurrency through gameplay. Their games are distributed globally through major platforms (https://web.archive.org/web/20260515140836/https://moxstudio.net/) including the App Store and Google Play Store, making blockchain gaming accessible to mainstream audiences. Both of those store listings have since been withdrawn — see “Status (August 2026)” below. The studio distinguishes itself through its integration with the Radix ecosystem (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) , featuring mascots and tokens from partner projects within their games. This approach not only enhances the gaming experience but also promotes wider adoption of the Radix platform. Their flagship game, Strangers (https://web.archive.org/web/20260515143515/https://moxstudio.net/games/strangers/) , exemplifies this integration, featuring both traditional gaming elements and blockchain-based rewards. Headquartered in Dalaman, Muğla (https://www.linkedin.com/company/moxstudio/) , Turkey, the company operates with a team of 2-10 employees, focusing on developing innovative gaming experiences that bridge the gap between traditional gaming and blockchain technology. Their mission emphasizes the creation of high-quality games that are both entertaining and financially rewarding for players. The studio's development approach prioritizes player engagement and technological innovation, demonstrated through their diverse portfolio of games including WOWO:Adventure, OciGravity, and Ociswap Hooks. Each game incorporates unique gameplay mechanics while maintaining the core principle of Play-to-Earn, allowing players to participate in the gaming economy through the MOX token system. History The development of Mox Studio evolved through several distinct phases, beginning well before its official establishment as a company. Early Blockchain Period (2017) The company's journey began in 2017 (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) when its founding team first entered the blockchain industry. This initial exploration was supported by over 15 years of prior experience in digital product management, marketing, and information technology sectors. During this period, the team focused on understanding blockchain technology and its potential applications in digital products. Expansion into Crypto Services (2018-2020) In 2018, the team began providing design consultancy services (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) to various business associates within the cryptocurrency industry. Their work during this period focused on helping projects elevate their brands and establish stronger market presence. By 2019, they had expanded their service offerings to include animation and motion design, building a comprehensive portfolio of crypto-related digital services. Gaming Integration (2021-2022) A significant pivot occurred in 2021 (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) when the team recognized the transformative potential of gaming within the crypto sector. This period marked a crucial transition as they began integrating their accumulated design expertise and development capabilities to create gaming experiences that could engage broader audiences. The focus shifted specifically toward developing games that could showcase blockchain technology's potential in interactive entertainment. Company Formation (2023) Mox Studio was officially established in 2023 (https://www.linkedin.com/company/moxstudio/) , marking the culmination of years of experience in blockchain, design, and gaming. The company was founded with a clear mission to develop Play-to-Earn (P2E) games that would integrate seamlessly with the Radix DLT ecosystem. This period saw the launch of their first major projects, including their flagship game Strangers. Recent Developments (2023-Present) Since its formal establishment, Mox Studio has continued to expand its game portfolio (https://web.archive.org/web/20250915132848/https://moxstudio.net/games/) and strengthen its position within the Radix ecosystem. Notable developments include: - The launch of multiple games including WOWO:Adventure, OciGravity, and Ociswap Hooks. - The introduction of the MOX token (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) as a central element of their gaming ecosystem. - Expansion into telegram-based gaming with titles like HUG Monsters and Radix Fusion (https://www.linkedin.com/company/moxstudio/) . - Development of partnerships within the Radix ecosystem to integrate various mascots and tokens into their games. The company maintains its headquarters in Dalaman, Muğla, Turkey, operating with a focused team of professionals dedicated to advancing their vision of blockchain-integrated gaming experiences. Their ongoing development efforts continue to push boundaries in combining traditional gaming elements with blockchain technology, setting new standards for Play-to-Earn gaming experiences. Games Portfolio Strangers Strangers (https://web.archive.org/web/20260515143515/https://moxstudio.net/games/strangers/) serves as Mox Studio's flagship game, offering a survival-based gaming experience where players find themselves stranded on an alien planet following a spacecraft malfunction. The game features: - Support for 13 languages including English, French, Chinese, Japanese, Korean, Russian, Polish, Spanish, Portuguese, German, Turkish, and Italian. - A roster of 44 unique characters with distinct abilities. - An arsenal of weapons allowing players to equip up to 6 simultaneously. - 177 different items for skill enhancement and gameplay customization. - Wave-based combat system with challenges lasting 20-90 seconds. - Four-tier upgrade system for character progression. - Integration with MOX token rewards system. WOWO: Adventure WOWO: Adventure (https://web.archive.org/web/20260122202551/https://moxstudio.net/games/wowo-adventure/) is a web-based pixel art platformer that follows the journey of WOWO, a character attempting to save their cursed village. The game represents a collaboration with the WOWO project, which aims to promote Radix as a mainstream blockchain platform. Players progress through levels while activating various skills, combining nostalgic gameplay elements with modern blockchain integration. OciGravity OciGravity (https://web.archive.org/web/20260308105049/https://moxstudio.net/games/ocigravity/) features Ocicat, the mascot of the Ociswap decentralized exchange (DEX) on Radix DLT. This pixel art platform game incorporates unique gravitational mechanics and puzzle elements. Players use one-button controls to navigate through levels while competing for positions on a global leaderboard. Ociswap Hooks Ociswap Hooks (https://web.archive.org/web/20260515142803/https://moxstudio.net/games/ociswap-hooks/) is a pixel art puzzle platformer featuring the Ocicat character. The game emphasizes hook-based navigation mechanics and includes competitive leaderboard features. It serves as another collaboration with the Ociswap DEX platform. Recent Additions Recent additions to the game portfolio include telegram-based games (https://www.linkedin.com/company/moxstudio/) such as: - HUG Monsters: A bouncing-style game incorporating $HUG and $MOX token rewards. - Radix Fusion: A puzzle game where players combine cryptocurrency tokens based on market capitalization. - Mings: A multiplayer game supporting up to 16 players simultaneously, inspired by Flappy Bird and Mario Kart. MOX Token The MOX token (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) serves as the primary cryptocurrency within Mox Studio's gaming ecosystem. Key features include: Token Utility - Used for in-game purchases. - Unlocking characters and special features. - Accessing game customization options. - Reward distribution for gameplay achievements. Token Distribution The total supply of MOX tokens is fixed at 100,000,000, allocated as follows: - 35% for Marketing, Team, and Development. - 20% for P2E Rewards. - 20% for Staking Rewards. - 15% for Presale and Liquidity. - 10% for Founders. Token Integration MOX tokens can be earned through gameplay (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) or purchased on supported cryptocurrency exchanges. The token system is designed to integrate with the Radix DLT platform, though some features await completion of Radix's deep linking development. Development Services Mox Studio offers game development services (https://web.archive.org/web/20260515143813/https://moxstudio.net/service/) structured around four key stages: - Conceptualization: Creating unique game concepts aligned with project vision. - Design: Developing detailed characters, environments, and game elements. - Development: Implementation using advanced technologies for mobile and web platforms. - Testing and Launch: Quality assurance and post-launch support. The company emphasizes customer-centric creativity and maintains a focus on fast, high-quality solutions while leveraging their expertise in both the gaming and crypto industries. Their development approach prioritizes end-to-end solutions and collaborative partnerships with clients. Technology Radix Integration Mox Studio's technology stack is built primarily around the Radix Distributed Ledger Technology (DLT) (https://web.archive.org/web/20260515140836/https://moxstudio.net/) platform. The integration of Radix DLT serves as the foundation for their Play-to-Earn (P2E) ecosystem, enabling cryptocurrency transactions and reward distributions within their games. This technological choice aligns with their mission to showcase Radix DLT capabilities to a broader gaming audience. Gaming Platforms The company develops games for multiple platforms, implementing a cross-platform strategy that includes: Mobile Development Mobile applications (https://web.archive.org/web/20260515140836/https://moxstudio.net/) are distributed through major platforms: - iOS applications through the Apple App Store. - Android applications through Google Play Store. Web-Based Gaming Web-based games (https://web.archive.org/web/20250915132848/https://moxstudio.net/games/) are developed to be accessible through standard web browsers, requiring no additional software installation. The studio utilizes modern web technologies to ensure consistent performance and accessibility across different devices and platforms. Telegram Integration Recent technological expansions include the development of telegram-based gaming platforms (https://www.linkedin.com/company/moxstudio/) , enabling multiplayer functionality and social integration. These implementations support features such as: - Simultaneous multiplayer gaming for up to 16 players. - Real-time leaderboard updates. - Integrated chat functionality. - Token reward distribution systems. P2E Implementation The Play-to-Earn mechanics (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) are implemented through a sophisticated system that integrates several technological components: Token Integration The MOX token system is integrated into the gaming platform through: - Smart contract implementation for token distribution. - Automated reward systems based on player achievements. - Integration with various cryptocurrency exchanges. - Staking mechanisms through platforms like DefiPlaza. Wallet Integration Games are designed to integrate seamlessly with the Radix wallet (https://www.linkedin.com/company/moxstudio/) , facilitating: - Direct token transfers. - In-game purchases. - Reward collection. - Asset management. Development Infrastructure The studio's development process (https://web.archive.org/web/20260515143813/https://moxstudio.net/service/) utilizes a comprehensive technological framework that includes: Game Development Tools - Advanced technologies for both mobile and web platform development. - Pixel art development tools for retro-style games. - Physics engines for games like OciGravity. - Multiplayer server infrastructure for social gaming experiences. Quality Assurance Systems The company employs rigorous testing protocols including: - Performance optimization tools. - Server load testing systems. - Cross-platform compatibility testing. - Network stability monitoring. Security Implementation Security measures are implemented across various aspects of the platform: - Blockchain transaction security. - User data protection. - Anti-cheat systems for competitive gaming. - Secure reward distribution mechanisms. Future Development The company continues to expand its technological capabilities (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) , with ongoing development in areas such as: - Deep linking integration with Radix. - Enhanced multiplayer functionality. - Improved cross-platform compatibility. - Advanced token utility implementations. The technology stack is continuously updated to maintain compatibility with the latest developments in both gaming and blockchain technologies, ensuring the platform remains current and competitive in the rapidly evolving blockchain gaming market. Business Model Play-to-Earn Framework Mox Studio's primary business model centers around the integration of Play-to-Earn (P2E) mechanics within their gaming ecosystem. The company has developed (https://web.archive.org/web/20260515140836/https://moxstudio.net/) a system where players can earn MOX tokens through gameplay achievements and activities. This approach creates a dual-value proposition where users both enjoy entertainment through gaming and potentially earn cryptocurrency rewards. The P2E framework is implemented through various mechanisms across their game portfolio. In their flagship game Strangers (https://web.archive.org/web/20260515143515/https://moxstudio.net/games/strangers/) , players can earn MOX tokens through regular gameplay, which can then be used to unlock additional characters, access special features, or customize their gaming experience. This creates a circular economy within the game ecosystem, encouraging sustained player engagement and investment in the platform. Revenue Streams The company generates revenue through multiple channels. Their games incorporate (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) various monetization strategies, including in-game purchases using MOX tokens. The token system serves as both a reward mechanism for players and a revenue generator for the company, with tokens being available for purchase on supported cryptocurrency exchanges. Additionally, Mox Studio offers comprehensive game development services (https://web.archive.org/web/20260515143813/https://moxstudio.net/service/) to clients, providing end-to-end solutions from conceptualization through launch and ongoing support. This service-based revenue stream complements their direct gaming revenue, creating a diversified business model that supports sustained growth and development. Distribution Strategy The company employs a multi-platform distribution strategy to maximize reach and accessibility. Their games are distributed globally (https://web.archive.org/web/20260515140836/https://moxstudio.net/) through major platforms including the Apple App Store and Google Play Store, ensuring broad market penetration across different geographical regions and user demographics. This wide distribution approach helps in building a diverse user base and creating multiple entry points for new players into their ecosystem. Recent expansions into telegram-based gaming (https://www.linkedin.com/company/moxstudio/) have further diversified their distribution channels, allowing them to tap into existing social media communities and create new engagement opportunities. Games like HUG Monsters and Radix Fusion demonstrate their ability to adapt their business model to different platforms while maintaining their core P2E mechanics. Ecosystem Integration A key aspect of Mox Studio's business model is their deep integration with the Radix DLT ecosystem. The company actively collaborates (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) with other projects within the Radix ecosystem, featuring their mascots and tokens within Mox Studio games. This strategy serves multiple purposes: it enhances the gaming experience, promotes wider adoption of the Radix platform, and creates mutual value through cross-project collaboration. Their partnership approach extends beyond simple integration, as demonstrated by games like OciGravity and Ociswap Hooks, which feature the mascot of the Ociswap decentralized exchange. These collaborations create a network effect within the Radix ecosystem, potentially driving user adoption across multiple platforms and services. Sustainability Model The company's approach to business sustainability is reflected in their token distribution model. The MOX token allocation (https://web.archive.org/web/20260122191001/https://moxstudio.net/token/) includes specific portions for marketing, team development, P2E rewards, and staking rewards, creating a balanced economic system that supports long-term growth. The allocation of 20% of tokens for P2E rewards and another 20% for staking rewards demonstrates a commitment to maintaining player engagement while ensuring economic sustainability. Market Position As a relatively new entrant in the blockchain gaming space, having launched in 2023 (https://www.linkedin.com/company/moxstudio/) , Mox Studio has positioned itself as a specialized developer focused on the Radix DLT ecosystem. Their business model reflects this specialization, with a clear focus on creating high-quality games that showcase the capabilities of blockchain technology while maintaining traditional gaming appeal. This positioning allows them to serve both conventional gamers and cryptocurrency enthusiasts, potentially expanding their market reach beyond traditional gaming audiences. Team Leadership and Development Mox Studio operates with a core team of professionals (https://web.archive.org/web/20260515140836/https://moxstudio.net/) specializing in various aspects of game development, design, and technical operations. The company maintains a relatively small but focused team structure, operating with 2-10 employees (https://www.linkedin.com/company/moxstudio/) as of 2024. Key Personnel The studio's development and operations are led by Baris Tasmaz (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) , who serves as the Game Designer & Developer. Tasmaz brings extensive experience in game development and design, playing a crucial role in shaping the studio's technical direction and creative vision. Ayse Tasmaz (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) holds the position of Designer & Product Manager, overseeing the studio's product development strategy and design implementations. Her role encompasses managing the overall product lifecycle and ensuring design cohesion across the studio's various projects. The technical testing and quality assurance department is headed by Eyup Akcelik (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) , who serves as the Senior Software Test Engineer. Akcelik's responsibilities include ensuring the reliability and performance of the studio's games across various platforms. Mehmet Topalak (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) functions as the App Support & Test Specialist, focusing on maintaining application quality and providing technical support for the studio's various gaming products. His role is crucial in ensuring smooth operation of the games and addressing technical issues that may arise. The web development aspects of the studio are handled by Gencay Kocak (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) , who serves as the Web Developer. Kocak's work is essential in maintaining and developing the studio's web-based gaming platforms and online presence. Corporate Structure The company operates from its headquarters in Dalaman, Muğla, Turkey (https://www.linkedin.com/company/moxstudio/) , maintaining a flexible work environment that accommodates both local and remote team members. This structure allows the studio to access talent globally while maintaining operational efficiency. Team Culture The team's approach is guided by several core principles (https://web.archive.org/web/20260122193908/https://moxstudio.net/about/) that shape their work culture. These include a commitment to integrity in all interactions, a passion for bringing original ideas to life, and a focus on excellence in game development and customer support. The team emphasizes innovation and community building, fostering an environment that encourages creative thinking and collaborative problem-solving. The studio's personnel structure reflects its evolution from its founding team's extensive experience in digital product management, marketing, and IT. This background has influenced the team's approach to combining traditional gaming elements with blockchain technology, creating a unique blend of technical expertise and creative game development capabilities. Status (August 2026) Re-read on 15 August 2026, Mox Studio is neither offline nor operating as the sections above describe. Three signals disagree with one another, and they are recorded separately here rather than averaged into a single verdict. The site is served, but browsers will not trust it moxstudio.net returns a complete WordPress homepage — title “Home - MOX STUDIO”, locale tr_TR — still describing the company as a “Radix DLT Focused Game Studio” and still listing Strangers, WOWO: Adventure, OciGravity and Ociswap Hooks. What fails is the certificate rather than the server: the site’s Sectigo domain-validated certificate for moxstudio.net expired at 23:59:59 UTC on 7 June 2026, so an ordinary browser refuses the connection and the domain presents as down. That is what the July 2026 reading recorded as “offline”, and it is why the archived copies remain the citable form of the site here. Both app-store listings have been withdrawn The homepage still links Strangers to Apple’s App Store and to Google Play. Both listings now return HTTP 404 — id6498866858 at Apple and com.moxstd.strangers at Google — so the claim above that the studio’s games are distributed through those platforms no longer holds. The 404s are genuine rather than an automated-request block: requests for the Radix Wallet listings, issued in the same session with the same user agent, returned 200 and 301. What remains playable are the itch.io (https://itch.io/embed-upload/10600161) builds the homepage frames directly, two of which responded; the third, embed-upload/10389859, returns 404. The token is fixed-supply and still trading MOX (resource_rdx1thmjcqjnlfm56v7k5g2szfrc44jn22x8tjh7xyczjpswmsnasjl5l9) was minted as 100,000,000 tokens on 1 July 2024. Its total supply now reads 84,000,000; the difference has been burned, which any holder is permitted to do, while minting is set to deny_all and that rule is itself immutable, so the supply cannot grow again. Unlike the studio’s distribution, the token is not dormant: swaps against XRD committed within the hour this reading was taken, through a native two-resource pool then holding roughly 11.66 million MOX against 538,700 XRD. The studio is therefore recorded as dormant — its published distribution has been removed and its domain is unattended enough for a certificate to lapse — while the token it issued continues to trade independently of it. ## Clarity Protocol URL: https://radix.wiki/ecosystem/clarity-protocol Updated: 2026-08-15 Summary: The Clarity Protocol is an open-source platform that enables decentralized autonomous organizations (DAOs) to manage on-chain governance. Clarity prov… The Clarity Protocol is an open-source platform that enables decentralized autonomous organizations (DAOs) to manage on-chain governance. Clarity provides a no-code interface for creating organizations, submitting proposals and recording votes on-chain. It launched on Cardano (https://www.clarity.community/) in 2022 and on Radix in October 2023; as of August 2026 its public product surface is Cardano-only and no Radix deployment is offered (see Status on Radix below). History In June 2022, Clarity launched on the Cardano testnet, allowing users to start experimenting with creating and managing DAOs. After extensive testing and refinement, Clarity launched on the Cardano mainnet in October 2022 and on Radix in October 2023 (https://x.com/clarity_dao/status/1716539995220025450) . Status on Radix Clarity the company is active. Its site claims "300+ teams", "$8M distributed via on-chain proposals" and "500+ proposals created" — but as of 15 August 2026 none of that surface mentions Radix. clarity.community (https://www.clarity.community/) is titled "Governance infrastructure for serious Cardano communities", and the features it advertises are Cardano-specific: DRep and SPO delegation-weighted snapshots, and CIP-1694 ratification thresholds. The application at clarity.vote (https://www.clarity.vote/) tells the same story at the routing layer. Its build manifest declares /cardano-governance, /cardano-dao-metrics and /cardano-treasury-withdrawals as named routes, alongside Cardano mainnet and testnet metadata API routes, and there is no Radix equivalent; requesting /radix returns the same 404 body as an invented control path, while /cardano-governance returns 200. The app root itself redirects to /cardano-governance/cast-votes. Radix was named on the product's own front page as recently as 6 August 2025, when the tagline read "Leverage no-code DAO tooling built for Cardano, Midnight, and Radix" ( archived copy (https://web.archive.org/web/20250806073717/https://www.clarity.vote/) ); the January 2024 snapshot (https://web.archive.org/web/20240111211223/https://www.clarity.vote/) read "built for Cardano and Radix". No archived copy of the app carries a Radix organization: of the 1,169 successfully archived URLs the Internet Archive holds for the domain, spanning September 2023 to July 2026, every organization route is /organizations/cardano/…. This page is recorded as Dormant on that basis — dormant on Radix rather than closed as a business. Key Concepts - Decentralized autonomous organizations (DAOs) - Groups that leverage blockchain technology to enable decentralized governance and decision-making. Clarity enables DAOs to manage on-chain governance. - Agora protocol - An audited library of open source Plutus scripts used to create and govern DAOs on Cardano. Clarity extends the functionality of Agora. - On-chain governance - Governance model where rules and decision-making are encoded on a blockchain. Clarity enables on-chain governance for DAOs. - Stakes - In Clarity, stakes are used to lock a DAO member's governance tokens to calculate voting power. - Proposals - On Clarity, DAO members can create proposals to hold votes on decisions. Proposals contain on-chain effects that execute if passed. - Voting - DAO members can vote on proposals using their stakes. Votes are recorded on-chain. Organizations vs Agoras Clarity distinguishes between Organizations and Agora DAOs. Organizations Organizations are groups that can leverage blockchain technology but rely on manual execution of governance decisions by trusted members. Pros of Organizations are that governance actions are free since they don't require on-chain transactions. They also allow for more control by restricting permissions. Cons are that they rely on trusted actors to manually enforce decisions. Agoras Agora DAOs are a subset of organizations on Clarity that rely on the Agora protocol for fully on-chain and automated governance. Agora DAOs use smart contracts to encode governance rules and autonomously execute decisions. Pros of Agora DAOs are trustless execution, transparency through on-chain record keeping, and permissionless participation based on token holdings. Cons are that governance actions require paying transaction fees. In Agora DAOs, any member can create proposals if they meet the minimum token threshold. Proposals contain on-chain effects that are executed if the proposal is approved through a vote. Votes on proposals are recorded on the blockchain. The Agora protocol supplies the on-chain governance infrastructure used by Agora DAOs on Clarity. Agora provides core components like governor contracts, stakes, and proposals. Clarity builds on top of Agora to make decentralized governance accessible for everyday users through its interface. Functionality Clarity offers various functionality to enable on-chain governance for DAOs without needing blockchain development skills: Creating and managing DAOs Clarity provides tools to create new decentralized autonomous organizations that leverage blockchain technology for governance and coordination. Participating in governance Clarity allows members of a DAO to take part in governance activities like submitting proposals, voting, staking tokens, and configuring parameters. Configuring governance parameters DAO admins can configure governance settings like token thresholds, timelocks, and voting cadences through Clarity's interface. Voting There are two main types of voting available in Clarity - polls and proposals. Polls are off-chain votes used to gauge sentiment from an organization's members. They do not execute any on-chain effects. Creating and voting in polls may be restricted to admin users depending on the organization's settings. Proposals involve on-chain voting that is recorded on the blockchain. Proposals are only available to Agora DAOs on Clarity. Any member who meets the minimum token threshold can create a proposal. Proposals contain smart contract effects that will automatically execute if the proposal is approved through the vote. Votes on proposals are submitted via transactions on the blockchain. There are key differences between the voting power used for polls versus proposals: - For polls, simply holding the governance token grants voting power based on the token balance. - For proposals, members must lock their governance tokens into stakes to gain voting power. The voting power is based on the amount of tokens locked in the stake. Proposals must go through defined stages including drafting, voting, execution, and completion based on the parameters in the DAO's governance contract. Proposal voting is permissionless for any member with enough stake. Bounties Bounties allow crowdsourcing submissions and conducting votes to synthesize collective intelligence. Team (https://clarity.community/team) - Logan Panchot: Handles community growth and fundraising. Graduated from Stanford University and has roles in business operations and community growth at Clarity. - Justin Schreiner: Leads frontend development. Has a background in Computer Science and is a Plutus Pioneer. - Matt Laux: Heads full-stack development. An engineering graduate from Texas A&M. - Ben Hart: Technical development leader with a decade of experience in the software industry. - Mark Florrison: Leads engineering operations. Founded MLabs, a Cardano and blockchain consulting company. - Chris Borders: Compliance lead and general counsel with over three decades of legal experience. - Tomasz Maciosowski, Nigel Farelly, Michał Adamczyk: Plutus Developers with a focus on Haskell and functional programming. Advisors - Mateen Motavaf: Former CEO of SundaeSwap, involved in strategic decision-making for Clarity. - Shannon Wu: Investor in the blockchain sector, advises Clarity on strategy and fundraising. - Paul Levine: Has 30 years of experience in the payments industry. - Izzat-Begum B. Rajan: Legal and tax expert with extensive experience in tax-efficient legal structuring. External Links - Clarity — official site (https://www.clarity.community/) - Clarity application (clarity.vote) (https://www.clarity.vote/) - "Clarity Protocol: Radix DLT Functionality" — Clarity on YouTube (https://www.youtube.com/watch?v=AaN50YIB8co) - @clarity_dao on X (https://x.com/clarity_dao) - Clarity Protocol on YouTube (https://www.youtube.com/@ClarityProtocol) See also - Caper (/ecosystem/caper) – on-chain DAO formation with treasury and exit rights ## IdeoMaker URL: https://radix.wiki/ecosystem/ideomaker Updated: 2026-08-14 Summary: IdeoMaker was a no-code decentralised application platform for business, announced in 2017 and built on Radix by a small team working from Rotterdam a… IdeoMaker was a no-code decentralised application platform for business, announced in 2017 and built on Radix (/contents/tech/releases/radix-mainnet-olympia) by a small team working from Rotterdam and Brașov. The platform never launched. Its website has not been republished since 6 August 2021, the Log In and Sign Up controls still read “Coming soon with Alpha”, and the Roadmap, Blog, Brandbook, Papers, Developers, Partners and Documentation entries in its own navigation all point at nothing. What is running is the team’s validator. Ideomaker Europe sits inside the Radix mainnet active set with 22.3 million XRD of delegated stake, and that operation – not the platform – is what the Active status on this page refers to. The sections below record the platform as its authors pitched it in 2021; Radix validator node and Status record what is on the ledger today. Proposed services (2021 pitch) The eight modules below are the platform as described on ideomaker.com, which has stood unchanged since August 2021. None of them was ever released; they are recorded here as the project’s stated design, not as available features. - Interactive Planning: Ideomaker offers an intuitive visual planning interface for users to visualize the production process, from ideation to execution. This interactive planning system helps users manage product development and distribution efficiently, with a clear overview of all stages of the process. - Global Reach: Ideomaker's geolocation features facilitate global collaboration. It uses smart matching algorithms to find potential partners based on diverse criteria such as pricing, delivery times, reputation, and quality. This ensures users can find the right support for development, distribution, or consultation, irrespective of location. - Open Ledger: Ideomaker utilizes a Decentralised Open Ledger, allowing for full transparency in product development. Users can monitor every aspect of their product's lifecycle, including manufacturing, transportation, and delivery. This ledger also helps to confirm the authenticity of products, and gives all stakeholders transparent access to a tamper-proof database. - IOT Connected: Ideomaker is designed to integrate and leverage Internet of Things (IoT) devices to enhance efficiency and reduce costs. This functionality prepares users for a future where automated tasks and services become the norm, and repetitive jobs are delegated to robots and other automated devices. - Team Projects: Ideomaker provides a global network of professionals that users can interact with to form their product development teams. The platform offers secure and reliable communication tools for effortless collaboration and synchronization of teamwork. - Automated Workflow: Ideomaker places a strong emphasis on automation. All its modules are designed to work together seamlessly, helping users improve manufacturing cycles, speed up delivery times, and reduce warehousing inefficiencies. - Marketplace & Tools: Ideomaker offers a modular framework of specialized tools. Users can choose from existing tools or create their own based on their unique needs. This framework is designed for intuitive use and seamless interaction. - In-App Store: Ideomaker features an in-app store for both end customers and businesses. Third-party developers can integrate their products and services into the store, which are then made interoperable across the whole platform without manual adjustments. Payment and economics (as pitched) The platform was to accept a native token alongside XRD (/contents/tech/core-concepts/staking) , the native token of the Radix network it was built on. Gradually, various cryptocurrencies will be accepted to provide users with as many opportunities for expansion and adoption as possible. In addition to digital payments, Ideomaker plans to spread the adoption of its services via Card and NFC payments and POS systems. Target audience (as pitched) The platform was aimed at a wide range of creators, including designers, developers, freelancers, artists, small to big brands, or hobbyists. It also serves suppliers, both local and international, from small to large companies. Team IdeoMaker is run by a small team of entrepreneurs with design and software development skills. The team operates from Rotterdam, Netherlands and Brasov, Romania, and they are open to expanding it with other skilled professionals from all over the world. The known members of the team are Vlad Butucariu, who is responsible for UI, UX, Dapp Design, and Rares Lupascu, who is involved in Software Development. Radix validator node IdeoMaker has run a validator node (/contents/tech/core-concepts/validator-nodes) since the Olympia (/contents/tech/releases/radix-mainnet-olympia) mainnet launch on 28 July 2021, and the node outlived the platform it was meant to fund. On mainnet today it is Ideomaker Europe, validator_rdx1svfawmdwc77092hzhd6rzlay0tg4g8dw2sd37mu7skaqjlsq624rfa, whose on-ledger info_url metadata is ideomaker.com. The address printed on the project’s own node page, rv1qg923hl7f725cs06eg5gmdcy4pfvpa8mfnjcw669traquj28c96z5w0rld0, is in the Olympia format and has addressed nothing since the Babylon (/contents/tech/releases/radix-mainnet-babylon) migration re-derived every address on the network. Read live from the Radix Gateway (https://mainnet.radixdlt.com/state/validators/list) at epoch 334878 on 14 August 2026, the validator is registered, accepts delegated stake, and holds 22,292,726.83 XRD – rank 47 of the 187 registered validators by stake, comfortably inside the top-100 active set. Of the 18,294,157.08 stake units (/contents/tech/core-concepts/liquid-stake-units) issued against that pool, 154,199.34 sit in the validator’s owner-locked vault, so roughly 99% of the stake belongs to delegators rather than the operator. Over the trailing month it made 66,548 proposals and missed 8; across Babylon’s history it has been in the active set for 301,926 epochs and missed 10,454 proposals out of 3,102,119 assigned. The node is not neglected. The fee is not the fee on the site The node page on ideomaker.com advertises a 2% fee and devotes a section to justifying it, and the validator’s stored validator_fee_factor agrees: 0.02. That is not what delegators are charged. The same validator carries a validator_fee_change_request to 0.1 with epoch_effective 312139, an epoch that began on 27 May 2026. Once a change’s epoch has passed the engine charges the request and leaves the stored field alone until the owner asks for the next change, so Ideomaker Europe has taken 10% of its delegators’ emissions – five times the published figure – since late May. Nothing here suggests concealment. A fee increase is a public transaction, it served the mandatory notice period of roughly 4,032 epochs before taking effect, and 10% is unremarkable among the network’s larger validators; what is stale is a marketing page nobody has touched in five years. The mechanism is described under Validator Nodes (/contents/tech/core-concepts/validator-nodes) , and 64 of the 187 registered validators are in the same state at this epoch. RadixStake (/ecosystem/radixstake) is the other case this wiki records in detail. Status The platform and the node have to be read separately, and the checks below were made on 14 August 2026. - The platform is finished. ideomaker.com (https://ideomaker.com) returns normally, but the Webflow build comment in its markup reads Last Published: Fri Aug 06 2021. It is a five-page brochure – home, project, team, node, contact – whose remaining navigation goes nowhere, and whose Log In and Sign Up buttons have said “Coming soon with Alpha” for five years. The homepage staking widget still reports Staked XRD 0 Mil / Stakers 0 against a real balance of 22.3 million. - The community channels are still open. The Telegram group (https://t.me/joinchat/G34OSRUy77qyOeejROKoRA) resolves with 109 members, and the Discord invite (https://discord.gg/uZxMPvde9r) still resolves to the ideomaker server. Neither is an announcement channel, so neither dates the wind-down. - The node is live. See above: registered, in the active set, 8 missed proposals in a month. - The promotional video is gone. This page previously carried a bare link to youtu.be/3Wd-mxpU60M as its only citation; YouTube’s oEmbed endpoint returns 404 for that ID, and the link has been removed. No wind-down was ever announced. What the record shows is a 2017 no-code platform that stopped being built somewhere in 2021, and a validator its team has kept in the active set ever since – which is the only reason an XRD holder is likely to encounter the name today. External Links - IdeoMaker – official website (https://ideomaker.com) - IdeoMaker – Radix validator node page (https://ideomaker.com/radixnode.html) - Ideomaker Europe on the Radix Dashboard (https://dashboard.radixdlt.com/network-staking/validator_rdx1svfawmdwc77092hzhd6rzlay0tg4g8dw2sd37mu7skaqjlsq624rfa) - IdeoMaker on Telegram (https://t.me/joinchat/G34OSRUy77qyOeejROKoRA) - IdeoMaker on Discord (https://discord.gg/uZxMPvde9r) - @ideomkr on X (Twitter) (https://twitter.com/ideomkr) – the account linked from the project website ## Hermes Protocol URL: https://radix.wiki/ecosystem/hermes-protocol Updated: 2026-08-13 Summary: Hermes Protocol is a Web3 notification and communications platform developed on the Radix network, designed to facilitate connections between business… Hermes Protocol is a Web3 notification and communications platform developed on the Radix network, designed to facilitate connections between businesses and Web3 users while preserving privacy and anonymity. https://youtu.be/QCXViOacn4I (https://youtu.be/QCXViOacn4I) Overview Hermes Protocol delivers real-time notifications for critical on-ledger events, including new Governance Polls, NFT sales, Validator changes, and more. The platform allows dApps to send newsletters without requiring users to disclose their email addresses, thus promoting privacy and anonymity in the Web3 space. Hermes Protocol is compatible with popular platforms like Discord, Telegram, and Twitter, aiming to optimize user experience for both end-users and business partners. History The idea for Hermes Protocol emerged during Terra's second hackathon, where co-founders Sérgio, Ana, and Duarte combined their Web3 knowledge to create a notification platform capable of sending on-chain notifications to Discord and Telegram users. Founders Sérgio Rebelo Sérgio has experience in online communities and software automation. His past positions include roles at Aptoide, Talkdesk, and AXA. He also co-founded a gaming events company in Portugal and worked with AXA in Belgium. https://youtu.be/OQoDNalYf8k (https://youtu.be/OQoDNalYf8k) Ana Ana is skilled in data analysis, fencing, and logical thinking. She holds a Master's degree in Management and has worked as a risk modeler at various European banks. Ana is proficient in several programming languages and is a front-end developer. Duarte Duarte is a full-stack developer with an interest in bots and automation. He met Sérgio in the "Among Us Portugal" online gaming community and contributed to the development of a community bot that streamlined gaming sessions. Stated Goals (2023 pitch) At the time of the Babylon (/contents/tech/releases/radix-mainnet-babylon) launch the team set out to reach 100,000 unique users within a year, partnering with wallet providers including Xidar (/ecosystem/xidar) , Z3us, Stream and the official Radix Wallet, and to convert that reach into 200 paying businesses. Neither figure was ever reported as met; see Status below. Competitive Positioning The project positioned itself against Push (formerly EPNS), Notifi, Dialect, Mailchimp and SendGrid, arguing that a model charging businesses rather than end users suited Web3 adoption better. Push and Notifi both remain in operation. Products and Grants The project website (https://hermesprotocol.io) , which is still online, presents three products rather than the single notification service described above: the notifications feed, peer-to-peer barter trades settled by a smart contract with fees shared between Hermes and the integrating dApp, and wallet-to-wallet messaging, an end-to-end encrypted cross-chain chat addressed by wallet address or domain name. It lists deployments on Terra, Terra Classic and Radix, names Ociswap (/ecosystem/ociswap) , XRD Domains (/ecosystem/xrd-domains) , XIDAR (/ecosystem/xidar) , RadixCharts (/ecosystem/radixcharts) and RadixScan (/ecosystem/radixscan) among its Radix partners, and credits the site itself to Momentum One. The same page lists the awards and grants the project won: an honourable mention at the Terra Spacecamp hackathon in 2021, an XDEFI grant and a Terra Emergency Builder Allocation in 2022, second place at the NEARCON hackathon in 2022, and a grant from the first cohort of the Radix Grant Program (/contents/history/radix-ecosystem-funding) in 2023. Status The Dormant status in the infobox rests on four checks made on 13 August 2026, each of which can be repeated in a few seconds: - The homepage’s own Enter App button points at app.hermesprotocol.io, and that hostname has no address record. A, AAAA and CNAME queries all return no data – the Cloudflare-hosted zone answers with its SOA and nothing else – while hermesprotocol.io and docs.hermesprotocol.io both resolve normally. The marketing site and the documentation are up; the application is not reachable. - The Telegram announcement channel (https://t.me/s/Hermes_Protocol) has published nothing since 27 June 2023. - The GitHub organisation (https://github.com/HermesProtocol-io) holds eight public repositories, and the most recent push to any of them is 23 February 2024, to the main hermes-protocol repository. - The website itself still returns normally and is unchanged, so no wind-down was ever announced. The team never said it had stopped. What the checks record is a project whose storefront stayed up while the application went off DNS, the announcement channel fell silent for three years and the code went untouched for two and a half. External Links - Hermes Protocol – Official Website (https://hermesprotocol.io) - Hermes Protocol – Documentation (https://docs.hermesprotocol.io) - HermesProtocol-io on GitHub (https://github.com/HermesProtocol-io) - Hermes Protocol – Telegram announcements (https://t.me/s/Hermes_Protocol) - Hermes Protocol on X (Twitter) (https://twitter.com/hermesprotocol) ## Quack Space URL: https://radix.wiki/ecosystem/quackspace Updated: 2026-08-13 Summary: Your Wallet is Your Voice: 5 Ways Quack.Space is Redefining Social Financial Identity Introduction: The End of the Silent Portfolio For too long, a st… Your Wallet is Your Voice: 5 Ways Quack.Space (https://quack.space) is Redefining Social Financial Identity Introduction: The End of the Silent Portfolio For too long, a structural divide has separated our digital discourse from our financial reality. We live in a fragmented ecosystem where social influence is built on one set of rails while capital is managed on another, creating a persistent disconnect between what we say and what we actually stake. This era of the "silent portfolio" is coming to an end. Quack.Space (https://quack.space) represents a profound fusion of the ATProtocol and RadixDLT, eroding the wall between liquidity and legacy social graphs. This integration formalizes a new paradigm: Social Financial Identity (SFI). In this framework, your social graph and reputation are no longer isolated metrics; they are provably linked to your on-chain assets and financial history. By making a user’s financial position an active, transparent component of their social presence, Quack.Space (https://quack.space) transforms the wallet from a passive vault into a resonant voice. 1. Your Influence is Now Provably Weighted The most significant shift in the Quack.Space (https://quack.space) ecosystem is the transition from "one user, one vote" to Token Weighted Views and Votes. Traditional social platforms are plagued by bot-driven sybil attacks and shallow engagement metrics that fail to distinguish between noise and conviction. Quack.Space (https://quack.space) corrects this by allowing engagement to be algorithmically amplified based on specific token holdings within a linked wallet. This introduces a sophisticated meritocracy where influence is backed by skin-in-the-game. When a verified holder engages with content, their signal is demonstrably louder. Crucially, this creates an intrinsic demand for project tokens; if you want your voice to carry weight in a specific community or governance debate, you must hold the underlying asset. It shifts the social dynamic from mere speculation to a verifiable, reputation-backed economy. "Establishes a verifiable, reputation-backed social economy where influence has tangible financial weight." 2. Sovereignty Without Compromise: The ATProto Bridge Digital identity has historically been a captive asset of the platform provider. Quack.Space (https://quack.space) dismantles this vendor lock-in through a sophisticated XRD Domain:Handle:DID mapping. This technical primitive uses the Radix ledger as the immutable "source of truth," providing cryptographic ownership of the social identity. By bridging to the Authenticated Transfer Protocol (ATProto), Quack.Space (https://quack.space) offers true portability. Users can migrate their followers, posts, and interaction data across any ATProto-compatible host without losing their history or their audience. This isn't just a convenience; it’s a strategic future-proofing of the social presence. In an era of de-platforming and shifting ecosystem allegiances, your social financial identity remains sovereign and portable. 3. The Feed as a Financial Filter Quack.Space (https://quack.space) moves social media from a stream of generic noise to a high-signal financial tool. Through the "Filter Feed by Token Holdings" feature, the user experience becomes dynamic. Instead of an algorithm guessing what you like, the feed can be set to prioritize content, polls, and discussions related to the specific assets in your wallet–such as QUACK∗∗or∗∗XRD. This financial curation is reinforced by the "Profile Top $Ticker" display and real-time in-post metrics. When a post mentions a specific ticker, it automatically embeds live pricing, 24-hour percentage changes, and the user's ownership status. This turns every post into a functional data point, ensuring that the context of the conversation is always grounded in the current reality of the market. 4. Coordinated Action via the "Flock Commander" To bridge the gap between social signaling and tangible utility, Quack.Space (https://quack.space) introduces the Flock Commander module. This system gamifies community coordination by organizing users into "Missions"–automated "Operations" that range from promoting high-value content to participating in Radix governance proposals. Execution is verified and tracked via linked Telegram bots, aggregating community impact into a metric known as "Flock Power." Participation is further incentivized through "Mission Reports" and "Merits"–reputation points that reward high-quality contribution. This creates a structured reputation economy where a user's status is derived from their history of successful operations and community support, rather than simple follower counts or vanity metrics. 5. Monetizing the Micro-Moment The monetization of social content is often opaque and delayed. Quack.Space (https://quack.space) streamlines this via the Tip Cart, Poll Tips, and the Reply Airdrop. These features allow for multi-asset token transfers directly within the social interface, rewarding creators for initiating high-value discussions or contributors for providing insightful replies. The platform measures this impact through two key metrics: • Post ‘Value’: Unlike a simple "like" count, this is a composite score based on tips received, engagement depth, and token-weighted views, adjusted by a time decay factor to ensure that current relevance is prioritized over legacy virality. • Handle Performance: A dynamic assessment of a user's overall contribution history and reputation score within the ecosystem. By turning engagement into tangible on-chain rewards, Quack.Space (https://quack.space) provides a transparent financial assessment of content, incentivizing a higher standard of participation. Conclusion: The Dawn of the Reputation Economy Quack.Space (https://quack.space) is more than a social network; it is the infrastructure for a reputation-backed social existence. This vision is supported by a growing suite of utilities, including the Radix Rolodex (/ecosystem/radix-rolodex) –a "reverse ads" platform utilizing a "deckbuilder" function to generate embeddable widgets (or "Rads") for any webpage–and the Doubt/it! poll system. The latter serves as a direct pipeline between social signaling and the gaming ecosystem at Doubtit.digital (https://doubtit.digital) , where yes/no polls feed directly into browser and board game content. We are moving away from the era of passive browsing and toward a world where your social presence is a provable extension of your financial convictions. As these lines continue to blur, the question for every participant in the Web3 space becomes: Are you ready for your social influence to be directly tied to your financial skin-in-the-game? ## RadUp URL: https://radix.wiki/ecosystem/radup Updated: 2026-08-13 Summary: RadUP was a validator node that was part of the Radix network. RadUp.io was a validator service committed to providing high performance validator node… Category Validator / Staking Network Radix (/contents/tech/releases/radix-mainnet-babylon) (mainnet) Type XRD staking validator node Status 🟢 Active (validator registered; website offline) Validator validator_rdx1s0d…ctuy2fx (https://dashboard.radixdlt.com/validator/validator_rdx1s0drhvkx30k62zu0usnzxzwuh0qcsqwlc2n2kfyexlyghqpctuy2fx) Stake 36,315,647.36 XRD (rank 36 of 188 registered, 6 Aug 2026) Fee 15% since epoch 312126 (was 1.95%) Uptime 99.99% (trailing month) Website radup.io (offline, HTTP 523) RadUP was a validator node that was part of the Radix network. RadUp.io (https://web.archive.org/web/20250401154431/https://www.radup.io/) was a validator service committed to providing high performance validator nodes for the Radix community. Status (August 2026): the validator is live, as the On-ledger status section records, while the project’s website (radup.io) is not: it returns an HTTP 523 (Cloudflare: origin unreachable) error. This page previously recorded the project as closed on the strength of that website alone. The historical sections below are Olympia-era, written from Wayback Machine captures (https://web.archive.org/web/20250401154431/https://www.radup.io/) : they quote a fee the node no longer charges, name the discontinued Radix desktop wallet, and describe a “no fee increases during the duration of Olympia (/contents/tech/releases/radix-mainnet-olympia) ” commitment for a phase that ended at the July-2023 Babylon (/contents/tech/releases/radix-mainnet-babylon) launch. Overview RadUp had been involved as a validator on the Radix network since its inception and had been chosen as a validator on both the Olympia betanet and Babylon betanet. RadUp.io offered a high-quality, low-cost, and reliable validator service. They aimed to serve the Radix network and community by running high-performing validator nodes. Mission The Mission of the RadUp validator was to ensure the integrity and reliability of transactions on the Radix network, helping to maintain the overall stability and trustworthiness of the network Fee Superseded: the node’s effective fee has been 15% since epoch 312126 (27 May 2026). The 1.95% below is the Olympia-era figure. RadUP charged a fixed fee of 1.95% (https://web.archive.org/web/20250114224306/https://www.radup.io/our-fee) for staking services, ensuring that stakers receive more than 98% of the total rewards associated with their stake. RadUp aimed to maintain a sustainable and fair fee structure. Features RadUp validator offered several features and benefits for stakers. Here are some of the key features: High Performance RadUp validator was designed to provide a high-performance node for staking XRD (Radix) tokens. They aimed to ensure efficient and reliable operation to maximize rewards for stakers. Fair Fee Structure RadUp charged a fixed fee of 1.95% for their staking services. This fee structure was intended to be fair and transparent, ensuring that stakers receive more than 98% of the total rewards associated with their stake. Sustainable Rewards RadUp made a promise of no fee increases during the duration of Olympia, which was the current phase in the Radix network development. This commitment ensured that stakers could earn predictable and consistent rewards without unexpected fee changes. Easy Staking Staking with RadUp was made easy and straightforward. Stakers only needed XRD tokens, the Radix desktop wallet, and the address of the RadUp validator node to start staking their tokens. Visibility and Transparency RadUp provided visibility into the validator nodes and their percentages of total stake. This transparency allowed stakers to make informed decisions about their stakes and choose the validator that aligns with their preferences and goals. Staking Process To stake (https://web.archive.org/web/20250401154431/https://www.radup.io/) with RadUP Validator, you can follow these general steps: Obtain Radix (XRD) tokens You need to acquire Radix (XRD) tokens to participate in the staking process. You can purchase these tokens from cryptocurrency exchanges that support Radix. Set up a Radix wallet Choose a Radix wallet that supports staking and is compatible with Radix tokens. The Radix desktop wallet is recommended for staking. Transfer XRD tokens to your wallet Once you have a Radix wallet, transfer the XRD tokens you acquired to your wallet address. Connect your wallet to Radix network Open your Radix desktop wallet and connect it to the Radix network. Follow the wallet's instructions to set up and connect. Delegate to the RadUP validator In your wallet settings, look for the staking or delegate section. Enter the validator address for RadUp.io. The address given by the archived site, rv1q2twz…250d832l, is an Olympia (/contents/tech/releases/radix-mainnet-olympia) -era address and does not resolve on Babylon (/contents/tech/releases/radix-mainnet-babylon) ; the current address is validator_rdx1s0drhvkx30k62zu0usnzxzwuh0qcsqwlc2n2kfyexlyghqpctuy2fx (https://dashboard.radixdlt.com/validator/validator_rdx1s0drhvkx30k62zu0usnzxzwuh0qcsqwlc2n2kfyexlyghqpctuy2fx) . Confirm and complete the delegation process following the wallet's instructions. Wait for confirmation It may take some time for the delegation to be confirmed on the network. Once confirmed, your tokens will be staked with the RadUP Validator. Service and Trust RadUp validator emphasized security and trust as essential pillars of their services. Here are some key points regarding their security measures and efforts to build trust. Validator Experience RadUp had been involved as a validator on the Radix network since its inception. They had been selected as a validator on both the Olympia betanet and Babylon betanet. Their active participation demonstrated their experience and technical expertise in running a validator node. Transparency RadUp provided visibility into their validator nodes and their percentages of total stake. This transparency allowed stakers to see the distribution of stake across validators and make informed decisions. Performance and Reliability RadUp focused on providing a high-performance validator node to serve the staking needs of the Radix community. Their aim was to ensure efficient and reliable operation to maximize rewards for stakers. Trustworthiness and Reputation RadUp was committed to being a trusted validator for stakers. They had established themselves as an active member of the Radix node running and wider community. These efforts collectively contributed to building a secure and trustworthy environment for stakers who chose RadUp validator. On-ledger status (August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) on 6 August 2026 at epoch 332670, the RadUp.io validator (https://dashboard.radixdlt.com/validator/validator_rdx1s0drhvkx30k62zu0usnzxzwuh0qcsqwlc2n2kfyexlyghqpctuy2fx) is registered, accepts delegated stake, holds 36,315,647.36 XRD — rank 36 of the 188 registered validators by stake — and recorded 99.99% uptime over the trailing month. Its on-ledger website field still reads https://www.radup.io. Stake units are resource_rdx1t47…xqv3mxu and unstake claims resource_rdx1nfp…l6tlhqy. The 1.95% fee described below is not what the node charges. Its stored fee factor is still 0.0195, but the validator carries a fee-change request to 15% that became effective at epoch 312126 — 27 May 2026 — so 15% is the fee actually applied to rewards. A delegator taking the archived fee page at face value would be wrong by a factor of nearly eight, which is the practical cost of reading a validator from its marketing site instead of from the ledger. ## Hack The System - London South Bank University URL: https://radix.wiki/contents/history/hack-the-system Updated: 2026-08-11 Summary: Hack the System is a community wealth building movement, which held its inaugural event on the 19-20 September, 2025, and aims to build Web3-powered m… Community Wealth Building Event Type Web3 Hackathon / Community Wealth Building Initiative Status Inaugural event held; ongoing movement for South London Key Dates Conceived 2022; Inaugural event 19–20 September 2025 Location Electric House, London South Bank University, 3 Wellesley Rd, Croydon CR0 2AG ( Map (https://maps.app.goo.gl/BjyVKG7FMNnEKFHz6) ) Key People & Entities David Randall (host); Crystalisr, Regens Unite, Blockchain Radicals, London South Bank University; Mentor: Avaunt (ShardSpace) Category History (/contents/history) Related Links RadixWiki on X (https://x.com/RadixWiki/status/1960002331761635825) · RegenCollective on X (https://x.com/RegenCollectiv3/status/1969022151358394485) Related Topics DApp In A Day Workshops (/contents/history/dapp-in-a-day-workshop-1) · Brunel Hack 25 (/contents/history/brunel-hack-25) · History of Radix (/contents/history) Hack the System is a community wealth building (https://en.wikipedia.org/wiki/Community_wealth_building) movement, which held its inaugural event on the 19-20 September, 2025, and aims to build Web3-powered marketplaces for South London. Details DATE: 19-20 September, 2025 TIMES: Friday: 17:00 - 20:00; Saturday: 9:00 - 16:00 LOCATION: Electric House, London South Bank University, 3 Wellesley Rd, Croydon CR0 2AG MENTORS: Avaunt (https://x.com/a_vaunt) (ShardSpace) REGISTRATION: Eventbrite (https://www.eventbrite.co.uk/e/hack-the-system-19-21-sep-tickets-1598556117379?aff=oddtdtcreator) https://maps.app.goo.gl/BjyVKG7FMNnEKFHz6 (https://maps.app.goo.gl/BjyVKG7FMNnEKFHz6) Media https://x.com/RadixWiki/status/1960002331761635825 (https://x.com/RadixWiki/status/1960002331761635825) https://x.com/RadixWiki/status/1967928507641557232 (https://x.com/RadixWiki/status/1967928507641557232) https://x.com/radixdlt/status/1968194817936200055 (https://x.com/radixdlt/status/1968194817936200055) https://x.com/RegenCollectiv3/status/1969022151358394485 (https://x.com/RegenCollectiv3/status/1969022151358394485) https://x.com/RadixWiki/status/1971591013572517946 (https://x.com/RadixWiki/status/1971591013572517946) https://x.com/crystalisr/status/1971818967896674722 (https://x.com/crystalisr/status/1971818967896674722) #hackthesystem #web3 #communitywealth #collaboration | Philip Porter (https://www.linkedin.com/posts/philip-porter-462b8929_hackthesystem-web3-communitywealth-activity-7367110832511455232-B-HA) #web3 #blockchain #communitywealth #innovation | Imogene Garthwaite (https://www.linkedin.com/posts/imogene-garthwaite-91293419a_web3-blockchain-communitywealth-ugcPost-7375480541313126400-5L4W) Last weekend, David Randall hosted Hack the System UK, bringing together leading voices to co-create the first blueprint for a South London community economy powered by tokenization, staking, and… | Michael Hernandez (https://www.linkedin.com/posts/michael-hernandez-363484223_last-weekend-david-randall-hosted-hack-the-activity-7377704353773666304-Tw8p) #communitywealthbuilding #radix #hackthesystem #hackthesystem | David Randall (https://www.linkedin.com/posts/davidchrandall_web3-blockchain-communitywealth-activity-7375659669714907136-1jvE/) What happens when a city decides that its cultural scene is worth saving? - Monocle | David Randall (https://www.linkedin.com/posts/davidchrandall_what-happens-when-a-city-decides-that-its-activity-7382369745125408768-wZ8B) Participants Gallery History HackTheSystem was conceived in 2022 by a coalition of organizations including Crystalisr (https://www.crystalisr.coop) , Regens Unite (https://www.regensunite.earth) , and Blockchain Radicals, alongside academic partners like London South Bank University (https://www.lsbu.ac.uk) . The initiative emerged from converging interests in regenerative economics, smart-city development, decentralized arts, and participatory democracy movements. Initially conceptualized as a single event, the first HackTheSystem gathering was postponed as organizers refined their approach and built stronger community relationships. After a three-year development period, HackTheSystem was relaunched in 2025 with a more focused methodology and clearer objectives. The initiative's evolution reflected growing interest in using blockchain and distributed ledger technologies, particularly the Radix ledger (/contents/tech/core-protocols/radix-engine) , to create community-owned cooperative structures modeled after established mutual organizations. Purpose & Vision To develop multiple Web3 platforms that connect local artists, creatives, and service providers with buyers in the South London Partnership area (1.2 million people), using blockchain technology to facilitate transactions and build community wealth. Through exhibitor showcases and self-organizing teams, create diverse local supply chains where Hipsters (cultural visionaries), Hackers (technical builders), and Hustlers (business developers) collaborate to build innovative solutions. Teams will form organically around exhibitor platforms - for example, an art sales platform might attract artists, promoters, developers, and art buyers who will work together to enhance the platform according to their collective requirements. Each team will compete to build the best community wealth building solution, with prizes awarded for the most innovative and viable platforms that keep wealth circulating within the South London community. Related Radix Events Hack the System sits within a wider wave of Radix (/contents/tech/core-protocols/radix-engine) -focused hackathons and workshops hosted at UK universities. The recurring DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) workshop series ran at St Mary's (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) , Roehampton (/contents/history/dapp-in-a-day-workshop-3-roehampton) , and Brunel (/contents/history/dapp-in-a-day-workshop-4) , alongside the standalone Brunel Hack 25 (/contents/history/brunel-hack-25) and the Radix Wiki Hackathon (/contents/history/radix-wiki-hackathon-1) . For the network these events build on, see the History of Radix (/contents/history) . Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a "Submission"). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. PHOTOGRAPHY AND VIDEO CONSENT By participating in this Workshop, Entrants acknowledge and consent to the Workshop Organizer and its authorized representatives taking photographs, videos, audio recordings, or other media ("Media") of Entrants during the Workshop. Entrants grant the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create derivative works from, and publicly display such Media for promotional, marketing, educational, documentation, or other business purposes in any medium now known or hereafter developed, including but not limited to websites, social media, publications, and presentations. ## DApp In a Day Workshop #1 - Westminster University URL: https://radix.wiki/contents/history/dapp-in-a-day-workshop-1 Updated: 2026-08-11 Summary: DApp In A Day #1 was the first event in the DApp In A Day series of Scrypto developer workshops. It was held at the University of Westminster in Londo… DApp In A Day #1 was the first event in the DApp In A Day series of Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developer workshops. It was held at the University of Westminster in London on the 28th of October, 2024, and set the format the later events reused: a single day, a university room, and a working dApp deployed by the end of it. A second workshop followed at St Mary’s University (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) two days later. Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: 28th October, 2024 TIME: 10:00 - 18:00 LOCATION: Room C103, 115 New Cavendish Street, London W1W 6UW. MENTORS: beemdvp (https://github.com/beemdvp) & @f_pieper (https://x.com/f_pieper) The DApp In A Day series DApp In A Day was a series of one-day, hands-on Scrypto (/contents/tech/core-protocols/scrypto-programming-language) workshops run at UK universities between October 2024 and November 2025, in which participants built and deployed a first dApp on Radix inside a single session. Each event was coordinated through the Radix Hackathon Telegram channel (https://t.me/RadixHackathon) , hosted by a university department or student society, and staffed by ecosystem developers acting as mentors. This page, the first event, serves as the index for the series. Event Date Host DApp In A Day #1 28 October 2024 University of Westminster, London DApp In A Day #2 (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) 30 October 2024 St Mary’s University, Twickenham DApp In A Day #3 (/contents/history/dapp-in-a-day-workshop-3-roehampton) 4 November 2024 University of Roehampton Brilliant On Chain / #4 (/contents/history/dapp-in-a-day-workshop-4) 4 December 2024 Brunel University, Blockchain Society DApp In A Day #5 (/contents/history/dapp-in-a-day-workshop-5) 26 February 2025 St Mary’s University, ESports Arena DApp In A Day #7 (/contents/history/dapp-in-a-day-workshop-7-roehampton) 3 November 2025 University of Roehampton Two universities hosted twice: St Mary’s took #2 (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) and #5 (/contents/history/dapp-in-a-day-workshop-5) , Roehampton #3 (/contents/history/dapp-in-a-day-workshop-3-roehampton) and #7 (/contents/history/dapp-in-a-day-workshop-7-roehampton) . Mentoring rotated with them: the three autumn-2024 events were run by beemdvp (https://github.com/beemdvp) and @f_pieper (https://x.com/f_pieper) , #4 by members of Brunel’s own Blockchain Society, and #5 by Shardspace (https://shardspace.app/) , which also sponsored it. Brunel later hosted the separate multi-day Brunel Hack 25 (/contents/history/brunel-hack-25) hackathon festival in July 2025. The numbering on this wiki follows the series’ own sequence and has no #6 entry. St Mary’s advertised the February 2025 event on Eventbrite as “Workshop 6” (https://www.eventbrite.co.uk/e/dapp-in-a-day-web3-workshop-workshop-6-tickets-1249180254769) , counting its own workshops rather than the series. For the wider context of Radix developer outreach, see History of Radix (/contents/history) and the other events collected under History / Events (/contents/history) . Media and gallery Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a “Submission”). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## MattiaNode URL: https://radix.wiki/ecosystem/mattianode Updated: 2026-08-10 Summary: MattiaNode is a validator on the Radix network created by Mattia , an active contributor to the Radix community. MattiaNode validator is a node used i… MattiaNode Type Radix validator node Status 🟢 Active – registered, accepting delegations Operator Mattia Validator address validator_rdx1s0qz…rzatmln (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0qzv2vmxydpnglk36mczrdwczpsskuzek2cs5nnld6j533rzatmln) Total stake 59,345,075.22 XRD (rank 33 of 187 registered) Validator fee 1.5% (no pending fee change) Uptime (30d) 99.997% – 4 proposals missed of 155,910 Location Italy – self-hosted (not on AWS / Azure / GCP) Hardware AMD Ryzen · 48 GB DDR4 · 1 TB NVMe · 1 Gbit/s fiber; UPS + 4G LTE failover On-ledger Read from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at mainnet epoch 333823, 10 August 2026 MattiaNode is a validator on the Radix network created by Mattia (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0qzv2vmxydpnglk36mczrdwczpsskuzek2cs5nnld6j533rzatmln) , an active contributor to the Radix community. Overview MattiaNode validator is a node used in the Radix network. It is a self-hosted and reliable validator node located in Italy. The MattiaNode validator is known for its decentralized setup, as it is not hosted on popular cloud providers like AWS or Azure. It runs on a beefy self-hosted server in Italy, equipped with an AMD Ryzen processor, 48GB of DDR4 RAM, 1TB of NVMe SSD storage, and a 1Gbit/s fiber connection. Choosing a validator node is crucial for staking $XRD on the Radix network. MattiaNode offers geographical decentralization and provider decentralization, making it an attractive option for individuals looking to stake their $XRD tokens. Mission The mission of MattiaNode validator is to contribute to the security, stability, and decentralization of the Radix network. As a self-hosted validator node, MattiaNode aims to provide a reliable and robust infrastructure for participating in the consensus protocol of the Radix network. By running their own validator node, the operator of MattiaNode actively contributes to securing the Radix network and ensuring the accuracy and integrity of transactions and data within the network. The node helps in validating transactions and reaching consensus on the state of the Radix ledger, making it an essential component of the network's overall functioning. In addition to its technical role, MattiaNode also plays a role in the Radix community. Mattia, the operator of the validator, has joined the RadixTalk forum as a moderator, actively engaging with the community and assisting in addressing queries related to the Radix network and its validator setup. Overall, the mission of MattiaNode validator encompasses supporting and furthering the goals of the Radix network, which include building a scalable, decentralized, and interoperable infrastructure for the next generation of decentralized applications. Benefits By joining the MattiaNode validator, participants can benefit from several advantages, including: Secure and Reliable Infrastructure As a validator node, MattiaNode provides robust and reliable infrastructure for participating in the consensus protocol of the Radix network. With its dedicated server and backup power supply, the validator node ensures uninterrupted and secure operation. Decentralization MattiaNode differentiates itself by not relying on popular cloud providers like AWS or Azure. This contributes to the decentralization of the network by diversifying the providers. Rewards Individuals can delegate their $XRD tokens to validators like MattiaNode and earn rewards for securing the network. By joining the validator, participants can earn rewards from their delegated stake. Participation in Network Governance Validators hold a stake in network governance by participating in the consensus protocol of the Radix network. As such, joining the MattiaNode validator enables individuals to contribute to the decision-making process of the network. Contribution to a Growing Ecosystem Joining the MattiaNode validator contributes to the growth of the Radix ecosystem by providing a more diversified and robust network. Participants in the validator node help increase the security and decentralization of the Radix network. Services Besides staking, MattiaNode provides additional network services to support the Radix ecosystem. These services include: Validator Infrastructure MattiaNode operates on a powerful self-hosted server located in Italy. The server is equipped with an AMD Ryzen processor, 48GB of DDR4 3600MHz RAM, 1TB of NVMe SSD storage (WD SN750), and a 1Gbit/s fiber connection. Additionally, the infrastructure is backed up with an uninterruptible power supply (UPS) and a 4G LTE redundant internet connection. Decentralized Network Operations MattiaNode prioritizes decentralization in its network operations. They do not rely on centralized cloud service providers like AWS, Azure, or Google Cloud, which helps avoid centralization and supports a more distributed network. Geographical Decentralization MattiaNode runs its node in Italy, contributing to the geographical decentralization of the Radix network. Green and Sustainable Energy MattiaNode's electricity supply is certified as 100% green and renewable. It is fed into the grid and produced by plants powered by renewable energy sources. Staking process The staking process for the MattiaNode validator is fairly straightforward. Here are the general steps: Create a Radix Wallet First, you'll need to create a Radix Wallet to store your $XRD tokens. You can create a wallet using the Radix Desktop Wallet or the Radix Web Wallet. Purchase $XRD Tokens Next, you'll need to purchase $XRD tokens from a cryptocurrency exchange that supports $XRD, such as KuCoin, Gate.io, or Bitget. You can then transfer these tokens to your Radix Wallet. Delegate $XRD Tokens Once your $XRD tokens are in your Radix Wallet, you can delegate them to the MattiaNode validator by using the Radix Wallet's delegation feature. You'll need to enter the validator's node address into the delegation form and set the amount of $XRD tokens you'd like to delegate. Earn Rewards The more $XRD tokens you delegate to the MattiaNode validator, the higher the potential rewards you can earn. Validator rewards are distributed based on the amount of tokens delegated, and the validator's performance and participation in the consensus protocol. Monitor Your Delegation It's important to monitor your delegation and the performance of the MattiaNode validator. You can check the status of your delegation and your rewards using the Radix Wallet's delegation dashboard. Validators may occasionally experience downtime or missed blocks, which could impact your rewards. Security and Trust Security and trust are essential considerations when choosing a validator like MattiaNode. Here are some key factors to understand about the security and trustworthiness of the MattiaNode validator: Reputation Building trust in the blockchain space often relies on a validator's reputation. Validators with a solid reputation are more likely to have a track record of reliability, honesty, and strong security practices. Assessing the reputation of MattiaNode can involve researching their history, community involvement, and any past contributions to the Radix ecosystem. Infrastructure and Reliability As a validator, MattiaNode is responsible for maintaining secure and reliable infrastructure to support the staking process. This includes maintaining secure server systems, implementing high availability measures, and ensuring robust network connectivity. Users should evaluate the technical capabilities and infrastructure of MattiaNode to ensure reliable staking operations. Security Measures Validators like MattiaNode should implement strict security measures to protect against potential attacks or breaches. These measures typically include secure server setups, encryption protocols, regular security audits, and best practices for handling user funds and data. Transparently communicating their security measures can enhance trust in the validator. Openness and Transparency Validators that prioritize openness and transparency can build trust with the community. This can include regularly sharing updates and reports on network participation, performance statistics, and any operational issues. Validators that actively engage with the community, provide clear communication channels, and respond promptly to inquiries contribute to trust and confidence. Community Feedback Evaluating community feedback and sentiment is another way to gauge trustworthiness. Engage with the Radix community, participate in forums, and research community sentiment and experiences with MattiaNode to get a sense of the validator's reputation and trust level. On-ledger record (August 2026) Read live from the Radix Gateway (https://docs.radixdlt.com/docs/network-gateway) at mainnet epoch 333823 (10 August 2026), the MattiaNode validator (https://dashboard.radixdlt.com/network-staking/validator_rdx1s0qzv2vmxydpnglk36mczrdwczpsskuzek2cs5nnld6j533rzatmln) is registered, accepts delegated stake, and holds 59,345,075.22 XRD — rank 33 of the 187 registered validators by stake. Its validator_fee_factor is 0.015 (1.5%) with no pending fee change request, so 1.5% is both the stored and the charged rate; see the wiki's validator nodes (/contents/tech/core-concepts/validator-nodes) page for why those two can differ elsewhere. Over the trailing 30 days — epochs 325183 to 333823, 8,639 epochs the node was active in — it made 155,906 proposals and missed 4, a 99.997% proposal rate. Across its whole history the node has made 5,207,576 proposals and missed 767. Stake units are resource_rdx1t5j…s7rj6f2w and unstake claims resource_rdx1n2y…a8a8372yw. The stake has grown since this page was last measured at epoch 326286 on 15 July 2026, when it stood at roughly 51.0 million XRD at rank #31 — more delegated stake (/contents/tech/core-concepts/staking) , a slightly lower rank, because other validators grew faster. ## RadixCharts URL: https://radix.wiki/ecosystem/radixcharts Updated: 2026-08-08 Summary: RadixCharts has closed. radixcharts.com now serves a single notice in place of the platform — "Service no longer available … We regret to inform you t… Status note (August 2026) RadixCharts has closed. radixcharts.com (https://radixcharts.com/) now serves a single notice in place of the platform — "Service no longer available … We regret to inform you that our data analytics service for RadixDLT is no longer available. Thank you for your support over the years" — with its only outbound link pointing at the Radix ecosystem directory (https://www.radixdlt.com/ecosystem-directory) . The documentation subdomain docs.radixcharts.com no longer resolves, which is why the feature descriptions below are cited to archived snapshots. The sections that follow are preserved as a record of what the platform did. RadixCharts (https://radixcharts.com/) is an analytics platform that provides real-time insights into the Radix ecosystem. Founded in 2022, it offers various statistics and data visualizations to help users understand the performance and growth of the Radix network. The platform showcases information about token prices, decentralized applications (dApps), transaction volume, staking statistics, and social media presence. https://youtu.be/hQNCyNCR0D8 (https://youtu.be/hQNCyNCR0D8) History The inspiration for RadixCharts came from the Radix community, which manually checked telegram group members to create rankings for NFT projects. Recognizing the need for automation and having a passion for data and statistics, the project was initiated in September 2022. Since its inception, RadixCharts' services have expanded considerably. Features - Total Value Locked (TVL): One of the primary metrics provided by RadixCharts is the Total Value Locked (https://web.archive.org/web/20250524190040/https://docs.radixcharts.com/data-analytics/total-value-locked) in the Radix network. TVL is a crucial indicator of the network's health and the trust users have in it. - $TOP Token: The $TOP token (https://web.archive.org/web/20251205022626/https://docs.radixcharts.com/token/usdtop) is utilized as an incentive for Radix influencers. It has a limited supply of 11,000 to maintain its exclusivity. - Validator Insights: RadixCharts offers detailed information on network validators. This feature is essential for those interested in staking their XRD. It provides intricate data on each validator's performance, uptime, and other critical statistics. Team RadixCharts was founded by Nelly Sayon. https://youtu.be/pAcoCAOUJLA?si=feaf3dlLcN9_zspw (https://youtu.be/pAcoCAOUJLA?si=feaf3dlLcN9_zspw) Achievements and Recognition - Scrypto Portfolio Challenge (September 2022): Nelly, the founder of RadixCharts, participated in the Scrypto Challenge, focusing on portfolio management and yield farming. After a few weeks of learning Scrypto, she submitted her project, "Juicy Yields," and received an honorable mention for her blueprint. - Dandelion Program Grant (January 2023): The Radix Ecosystem Metrics page (https://www.radixdlt.com/blog/runs-on-radix-q-a-radixcharts) on RadixCharts was developed as a result of a Dandelion Program grant. This initiative by RDX Works rewarded individuals with innovative marketing ideas. RadixCharts contributed by offering transparent, real-time visualizations of economic activities on the Radix platform, shedding light on the health and growth of the Radix ecosystem. - Developer Incentive (September 2023): Nelly, the founder, was awarded $1,500 of XRD as part of the Scrypto Developer Incentive program. The RDX Works team recognized her contributions to RadixCharts, which has become an integral tool for data retrieval and visualization. Partnerships - RadixScan: RadixCharts collaborates with RadixScan (https://www.radixdlt.com/blog/runs-on-radix-q-a-radixcharts) , a community explorer for the Radix network. RadixScan offers tools and extensive information on network activity, validators, tokens, and more. - Crew Labs: For their Validator Node (https://radixcharts.com/) , RadixCharts has partnered with Crew Labs. This collaboration involves a joint venture of innovators and entrepreneurs who are developing Web3 solutions. Closure and on-ledger status (August 2026) The website is closed; the validator is not. Read from the Radix Gateway on 8 August 2026 at epoch 333054, Radix Charts V2 (https://dashboard.radixdlt.com/network-staking/validator_rdx1svxx0jetjwnptndj60sm8h7ljs0v88fl6xhwcyp6ar397agwd0ezaz) is registered, accepts delegated stake, holds 27,229,258 XRD — rank 44 of the 188 registered validators — and charges a 2.5% validator fee. Uptime is 98.65% over the trailing month. The node's on-ledger description has not been updated to match the site. It still reads "By staking on our node you support the further development of RadixCharts" — a claim about a service that, by its own homepage, no longer exists. That text is metadata on the validator component and is what a wallet or explorer shows a delegator at the moment they choose where to stake. Delegated stake on Radix is never at risk from an operator going quiet: there is no slashing on the network (/contents/tech/core-concepts/staking) , and the stake units held by delegators can be unstaked and claimed independently of the operator. What continues is the fee — 2.5% of the emissions earned by 27.2M XRD, accruing to an operator whose stated purpose for collecting it has ended. ## Ploughshare URL: https://radix.wiki/ecosystem/ploughshare Updated: 2026-08-03 Summary: Ploughshare, previously known as CowDAO, is a project based on the SRWA protocol aimed at providing alternative finance solutions to farmers in New Ze… Ploughshare Type Real-world-asset (RWA) lending & borrowing for New Zealand farmers Formerly CowDAO Status 🟠 Dormant as a standalone Radix dApp – its dedicated site (ploughshare.srwa.io) is offline and ploughshare.nz (https://ploughshare.nz/) served a maintenance holding page when checked on 2026-08-03; the underlying tech is now delivered through SRWA (/ecosystem/srwa) Built on Radix + the SRWA (/ecosystem/srwa) (Smart Real-World Assets) protocol Token $MOO – fundraising, rewards & DAO governance (tokenomics never finalised) Sector AgTech / organic pasture-based agriculture finance, New Zealand Website srwa.io (https://www.srwa.io) Ploughshare, previously known as CowDAO, is a project based on the SRWA (/ecosystem/srwa) protocol aimed at providing alternative finance solutions to farmers in New Zealand amidst the decreasing bank support in the AgTech sector. Overview Ploughshare focuses on addressing the finance challenges faced by farmers in New Zealand due to banks' tightening terms and dwindling support in the AgTech space. By leveraging the Radix network, the SRWA protocol, and a network with proven real-world traction, Ploughshare positions itself as a viable alternative for farmers seeking financial support. Ploughshare demo (https://youtu.be/Q4i78_dr1ug) – srwa.io (https://www.srwa.io) , Nov 2023. Sustainability The project is deeply rooted in principles of sustainability and has plans to transition to a decentralized, DAO governance model. By partnering with subject matter experts, Ploughshare looks into the potential of acquiring orphan technologies and ensuring sustainability, focusing specifically on organic, non-GMO, pasture-based animal agriculture. Lending and Borrowing Initially, Ploughshare aims to introduce a straightforward DeFi style of lending and borrowing. However, it plans to diversify into traditional finance models over time. There is an ongoing exploration of a more extended term, mortgage-based loan offering with fixed interest rates and monthly installments, given its familiarity among most of Ploughshare's clientele. Ploughshare Token ($MOO) The Ploughshare token, represented as $MOO, plays a multifaceted role in the project: - Fundraising: During the token sale. - Reward System: For contributions to the project and for utilizing specific project features. - Governance: Serving as voting power within the DAO for project decision-making. Detailed information about the Ploughshare Tokenomics remains in the development phase. Regular updates can be found in the Tokenomics section. Early-stage Funding Ploughshare has already secured its early-stage funding, which is expected to catalyze its growth via investment rounds and the sale of Ploughshare tokens. Token Supply The tokenomics of Ploughshare remains a work in progress. Preliminary models suggest a fixed supply approach, but this may undergo changes leading up to the private sale investment round. Status Ploughshare's standalone Radix presence is dormant – its dedicated site, ploughshare.srwa.io, no longer resolves. However, the SRWA (/ecosystem/srwa) (Smart Real-World Assets) protocol that built it remains live (https://www.srwa.io) and still describes Ploughshare as a registered financial service provider in New Zealand for which SRWA supplies the tokenised lending-and-borrowing technology, spotlighting dairy-farming finance. ## P2P Fixed-Rate Lending (Stokenet) URL: https://radix.wiki/ecosystem/p2p-lending Updated: 2026-08-03 Summary: Editorial note: this entry documents a lending pattern demonstrated on Stokenet whose developers have not published a project name, team or website. I… Status Testnet (Stokenet) Type DeFi – Peer-to-Peer Lending Rate model Fixed interest rate (no variable rate risk) Liquidation None for fixed-rate positions Key technology Radix sub-intents (composable transactions) Language Scrypto Related Subintents & pre-authorizations (/contents/tech/core-concepts/subintents-and-pre-authorizations) , Cuttlefish (https://docs.radixdlt.com/docs/cuttlefish) , Scrypto (/developers/scrypto/01-fundamentals) Project name Not publicly disclosed – see note below Overview Editorial note: this entry documents a lending pattern demonstrated on Stokenet whose developers have not published a project name, team or website. It is retained as a description of the mechanism rather than as a directory entry for a named project, and will be renamed if the project identifies itself publicly. A peer-to-peer fixed-rate lending dApp in development on Stokenet (Radix's public testnet) demonstrates a trustless lend-and-borrow protocol where both parties agree to fixed interest rates before the loan is initiated. Unlike liquidity pool-based lending (Aave, Compound), where interest rates float with utilization, this protocol locks in rates at loan creation – eliminating variable rate risk for borrowers and lenders alike. The dApp is built using Radix sub-intents, the composable transaction feature introduced by the Cuttlefish protocol update (https://docs.radixdlt.com/docs/cuttlefish) , enacted on mainnet on 18 December 2024. Sub-intents allow each party in a multi-party transaction to sign their own portion independently, with a final assembler combining them into a single atomic transaction. This enables trustless loan initiation without a central escrow contract holding funds during the matching process. How It Works For lenders: A lender creates a loan offer specifying the asset, amount, interest rate, and duration. This offer is encoded as a sub-intent – a signed partial transaction that commits the lender's funds conditionally. The offer can be broadcast or matched off-chain without the funds leaving the lender's control until a borrower accepts. For borrowers: A borrower finds an acceptable offer, creates their own sub-intent (committing collateral), and an assembler combines both sub-intents into a complete atomic transaction. The loan is created, collateral locked, and principal transferred in a single Radix transaction. There is no window for front-running, rug pulls, or partial execution. Repayment: Fixed-rate positions have predetermined repayment schedules. Because the interest rate is fixed at loan creation, borrowers know their total repayment obligation from the start – no oracle risk, no utilization-rate spikes, no surprise rate increases. No Liquidation Risk Traditional DeFi lending (Aave, Compound, MakerDAO) uses over-collateralization with liquidation mechanisms: if collateral value falls below the liquidation threshold, bots sell the collateral at a discount to repay the loan. In volatile markets, borrowers can be liquidated even during temporary price dips – losing their collateral despite intending to repay. Fixed-rate P2P lending separates the interest rate from the collateral ratio. A borrower who commits collateral at loan creation and makes scheduled repayments cannot be liquidated due to price volatility – the terms are fixed. This is particularly valuable for longer-duration loans where variable rate and liquidation risk compound over time. The tradeoff is reduced capital efficiency compared to over-collateralized pool-based protocols. Lenders must wait for matched borrowers rather than earning yield from an always-available liquidity pool. Sub-Intent Technology The protocol's non-custodial matching mechanism is enabled by Radix's sub-intent (pre-authorization) system (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) , introduced in the Cuttlefish upgrade. Sub-intents allow a party to sign a partial transaction with specific preconditions and assurance properties, without broadcasting or finalizing it. Key properties used by this dApp: - Conditional execution: The lender's sub-intent only executes if the borrower's matching sub-intent is included in the final transaction - Assertions: The lender can assert minimum collateral ratios or specific asset types in the borrower's sub-intent - Atomic assembly: The final transaction either fully executes both sub-intents or fully reverts – no partial state - No custodian needed: Funds never leave participants' vaults until the matched transaction is finalized This is a direct application of Radix's subintent primitive (/contents/tech/core-concepts/subintents-and-pre-authorizations) to DeFi primitives that previously required trusted escrow contracts or custodial order books. Stokenet and Mainnet Path The dApp is currently on Stokenet (https://stokenet-dashboard.radixdlt.com/) , Radix's public testnet, where it can be tested with testnet XRD without real financial risk. The development team is building toward a mainnet launch. Stokenet now operates as community infrastructure following the Stokenet Goes Community handover (/contents/tech/releases/stokenet) , meaning external developers building on Stokenet are operating on independently maintained testnet infrastructure – closer to mainnet conditions than previous Foundation-operated testnet environments. External Links - Pre-Authorizations and Subintents – Radix Docs (https://docs.radixdlt.com/docs/pre-authorizations-and-subintents) - Stokenet Dashboard – Radix (https://stokenet-dashboard.radixdlt.com/) - Cuttlefish Protocol Update – Radix Docs (https://docs.radixdlt.com/docs/cuttlefish) - Subintents and Pre-Authorizations (/contents/tech/core-concepts/subintents-and-pre-authorizations) - Scrypto – Asset-Oriented Smart Contracts (/developers/scrypto/01-fundamentals) ## DApp In a Day Workshop #3 - Roehampton University URL: https://radix.wiki/contents/history/dapp-in-a-day-workshop-3-roehampton Updated: 2026-08-03 Summary: DApp In A Day #3 was the third event in the DApp In A Day series of Scrypto developer workshops. It was held at the University of Roehampton on the 4t… DApp In A Day #3 was the third event in the DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) series of Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developer workshops. It was held at the University of Roehampton on the 4th of November, 2024, closing the series’ opening run of three London workshops in eight days. Roehampton hosted the series again a year later for DApp In A Day #7 (/contents/history/dapp-in-a-day-workshop-7-roehampton) in November 2025. Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: 4th November, 2024 TIME: 10:00 - 17:00 LOCATION: DB117, Sir David Bell Building, Digby Stuart College, Roehampton Lane, London, SW15 5PU. MENTORS: beemdvp (https://github.com/beemdvp) & @f_pieper (https://x.com/f_pieper) In the series This workshop followed #1 at the University of Westminster (/contents/history/dapp-in-a-day-workshop-1) on 28 October and #2 at St Mary’s University (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) on 30 October, all three mentored by beemdvp (https://github.com/beemdvp) and @f_pieper (https://x.com/f_pieper) and coordinated through the Radix Hackathon Telegram channel (https://t.me/RadixHackathon) . The next event, Brilliant On Chain (/contents/history/dapp-in-a-day-workshop-4) , moved the format to a student society at Brunel University in December 2024. The full index of the series is kept on the #1 page (/contents/history/dapp-in-a-day-workshop-1) ; other Radix developer events are collected under History / Events (/contents/history) . Gallery Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a “Submission”). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## DApp In a Day Workshop #2 - St Mary’s University URL: https://radix.wiki/contents/history/dapp-in-a-day-workshop-2-st-marys-university Updated: 2026-08-03 Summary: DApp In A Day #2 was the second event in the DApp In A Day series of Scrypto developer workshops. It was held at St Mary’s University in Twickenham on… DApp In A Day #2 was the second event in the DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) series of Scrypto (/contents/tech/core-protocols/scrypto-programming-language) developer workshops. It was held at St Mary’s University in Twickenham on the 30th of October, 2024, two days after the opening workshop at the University of Westminster, and ran in the university’s ESports Arena. St Mary’s hosted the series a second time for #5 (/contents/history/dapp-in-a-day-workshop-5) in February 2025. Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: 30th October, 2024 TIME: 10:00 - 18:00 LOCATION: Room E13, SMU ESports Arena, Waldegrave Road, Twickenham, TW1 4SX. MENTORS: beemdvp (https://github.com/beemdvp) & @f_pieper (https://x.com/f_pieper) REGISTRATION: Eventbrite (https://www.eventbrite.co.uk/e/dapp-in-a-day-web3-workshop-tickets-1026774248417) In the series This was the middle event of the series’ opening run of three London workshops inside eight days: #1 at the University of Westminster (/contents/history/dapp-in-a-day-workshop-1) on 28 October, this one on 30 October, and #3 at the University of Roehampton (/contents/history/dapp-in-a-day-workshop-3-roehampton) on 4 November. All three were mentored by beemdvp (https://github.com/beemdvp) and @f_pieper (https://x.com/f_pieper) and coordinated through the Radix Hackathon Telegram channel (https://t.me/RadixHackathon) . Of the six recorded workshops, only St Mary’s and Roehampton hosted twice. The full index of the series is kept on the #1 page (/contents/history/dapp-in-a-day-workshop-1) ; other Radix developer events are collected under History / Events (/contents/history) . Media Gallery “Thank you so much, the workshops were great and I learned a lot!” - L.L “Thank you! It was a great experience, you have have a great team and all so helpful! Very rare to find!” - R.B “Had an amazing day at the workshop—great sessions and fantastic connections! Huge thanks to everyone involved for making it memorable.” - Caymann “I really enjoyed developing on Radix and is something I would wanna learn more about, in your future events I can also bring some of my class mates who would be interested in it.” - S.C Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a “Submission”). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## RADIX.wiki URL: https://radix.wiki/ecosystem/radix-wiki Updated: 2026-08-03 Summary: RADIX.wiki is a permissionless knowledge base and community hub for the Radix ecosystem. The organization runs events such as the Radix Wiki Hackathon… RADIX.wiki (https://radix.wiki) is a permissionless knowledge base and community hub for the Radix ecosystem. The organization runs events such as the Radix Wiki Hackathon (/contents/history/radix-wiki-hackathon-1) and the Dapp In A Day workshops (/contents/history/dapp-in-a-day-workshop-1) , while the site hosts 348 articles, ecosystem listings and community pages, all with a view to increasing the 'collision rate' between researchers, founders and contributors to Radix. Since 2022, the site has seen more than 10k visitors from over 100 countries. How to contribute There are several ways to contribute to the wiki: - Edit an article by clicking on the Edit button above. - Create a new page under the appropriate tag path (e.g., contents, ecosystem, community). - Ask questions or make suggestions in the comments section. - Enquire about sponsorships. Note: Contributing requires a Radix wallet with XRD. Creating pages requires 5,000–50,000 XRD depending on the section, editing requires 20,000 XRD, and commenting requires 10,000 XRD. Some sections (community, blog, RFPs) are author-only. Advantages - Utility: Knowledge and experience are wasted if they aren't shared, but a wiki can amplify and focus the collective wisdom, experience, and intelligence of the Radix community, benefitting the whole web3 movement. - Accessibility: Being spread across multiple locations makes information difficult and slow to find, but a comprehensive wiki can make it easier for community members to find the information they need, whether they are researching a topic or solving a problem. - Speed: Information on a wiki can be updated within minutes of a new development, giving an immediate benefit to the community. - Accuracy: Multiple users can contribute and edit content on a wiki, leading to a more comprehensive, balanced, accurate, and up-to-date resource that also reflects the diversity of its contributors. - Neutrality: Hype can be off-putting for newcomers, but a neutral voice helps people to view information about Radix objectively. - Simplicity: A rich block-based editor makes it easy for anyone to contribute, no matter how small the change. - Version control: Semantic versioning with block-level diffs tracks every change and makes it easy to review or roll back edits. - Collaboration: Bringing knowledge and creators together in one place increases the collision rate of the community, leading to more projects and shared endeavors that will compound for Radix over the coming weeks and months. Disadvantages - Quality control: Although XRD balance requirements help filter contributions, it can still be difficult to ensure that all information is accurate and reliable. - Vandalism: Balance gating and author-only restrictions mitigate this, but wiki content remains editable by qualifying users. - Ownership: Since the information is contributed by multiple users, there can be issues with ownership and authorship. Author-only sections (community pages, blog, RFPs) help address this for personal content. Roadmap Just as Wikipedia is the municipal center of the internet, our vision is to be the same for Web3, assuming that Radix will be its substrate. Having moved to a fully native web3 application, the wiki now combines the power of Radix with a block-based editing system. Upcoming milestones include: - Community governance and treasury management. - Contributor rewards. - Integrations with other Radix projects. - On-ledger storage. Technical Features Key technical features of the application include: - Decentralized authentication using ROLA (Radix Off-Ledger Authentication) with Ed25519 signature verification. - Block-based content system with sixteen block types, including rich text, columns, infoboxes, recent pages, page lists, asset price widgets, code tabs, stats, link grids and references. - Rich text editing via TipTap with tables, code blocks (syntax highlighted), YouTube/Twitter embeds, tab groups, and image uploads. - Semantic versioning with block-level change tracking (added, removed, modified, moved). - XRD balance-gated access control for creating, editing, and commenting. - Hierarchical tag-based content organization with per-path permissions. - Threaded comments. - Full revision history with structured diffs. Technical Description - Frontend: Next.js 15 (App Router) with React 19 for server-side rendering and client-side navigation. Tailwind CSS 4 with a custom dark-mode design system. - Database: PostgreSQL via Prisma ORM (hosted on Supabase). - Editor: TipTap 2.10 with custom block extensions. - State management: Zustand 5. - Image storage: Vercel Blob. - Authentication: Radix DApp Toolkit for wallet connection; ROLA challenge-response flow verified against the Radix Gateway API; JWT sessions stored in PostgreSQL. ## Ideosphere URL: https://radix.wiki/ecosystem/ideosphere Updated: 2026-08-03 Summary: Ideosphere was a decentralized science (DeSci) funding project co-founded by Rei Jarram and Mariana Oka. It launched in 2024 as a DeSci crowdfunding p… Ideosphere was a decentralized science (DeSci) funding project co-founded by Rei Jarram and Mariana Oka. It launched in 2024 as a DeSci (/contents/tech/core-concepts/decentralized-science-desci) crowdfunding platform on the Radix (/contents/tech/releases/radix-mainnet-babylon) network – a Patreon-style monthly-membership model for funding scientific research – but has since pivoted to a prediction-market funding model and is no longer built on Radix. Status As of 2026, Ideosphere is no longer part of the Radix ecosystem. The project pivoted away from its original Radix-based subscription model toward "prediction" and "discovery" markets, where traders speculate on research outcomes and the trading spread funds researchers. Per a November 2025 Cointelegraph report (https://cointelegraph.com/news/url-slug-ideosphere-prediction-markets-scientific-research) , the reworked project was still in early development (front-end mockups only) and had received a $10,000 grant from the Blockchain for Good Alliance. The original Radix crowdfunding platform is retained below as a historical record of the project's time in the Radix ecosystem. Mission Ideosphere's mission was twofold: to provide researchers with a consistent and accessible funding stream, and to create a global community where science enthusiasts can engage directly with cutting-edge research. Platform Ideosphere's platform was designed to cater to two primary user groups: researchers and supporters. The features and functionalities were tailored to meet the needs of each group, fostering a symbiotic relationship between those conducting scientific research and those passionate about supporting it. For Researchers Ideosphere offered several key benefits for researchers seeking funding and exposure for their work: - Global Science Outreach: Researchers could engage with a worldwide network to share their research, inspiring scientific curiosity and gaining support from an international community dedicated to STEM advancements. This global platform allowed for increased visibility and potential collaborations across borders. - Consistent Revenue Stream: Through the monthly membership model, researchers could secure a more stable and predictable source of funding. This consistent income could provide financial stability for ongoing research projects, allowing for better long-term planning and resource allocation. - Direct Funding Access: Ideosphere simplified the funding process by connecting researchers directly with supporters. This approach bypassed traditional grant processes, which can be time-consuming and highly competitive. Researchers could access funds from a dedicated community passionate about advancing STEM, potentially accelerating the pace of their work. For Supporters Ideosphere provided supporters with various ways to engage with and contribute to scientific research: - Exclusive Content: Supporters gained access to special content from the researchers they funded. This may include participation in Q&A sessions, early access to research findings, and the ability to collect badges showcasing their involvement. This exclusive access created a more personal connection between supporters and the research they were funding. - Likeminded Community: The platform fostered communities of people passionate about science and innovation. Supporters could join these groups to share ideas, discuss research, and connect with others who have similar interests in scientific advancement. - Monthly Memberships: Supporters could empower scientists through flexible, subscription-based memberships. These memberships could be adjusted or cancelled at any time, providing convenience and control over their level of support. - Proof of Donation NFTs: In a unique integration of blockchain technology, supporters received Non-Fungible Tokens (NFTs) as proof of their contributions. These NFTs featured custom art and designs related to the research projects they supported, serving as a digital record of their involvement in advancing scientific research. Website (30 July 2026): ideosphere.io has no DNS record at all. An unregistered domain can be bought by anyone – four defunct Radix projects' domains have already been re-registered as unrelated landing pages – so the link has been removed from this page's facts table. ## Z3US URL: https://radix.wiki/ecosystem/z3us Updated: 2026-08-03 Summary: Z3US is an open-source, community-centric web3 wallet designed for the Radix DLT (Distributed Ledger Technology) network 1 . The wallet is user experi… Z3US is an open-source, community-centric web3 wallet designed for the Radix DLT (Distributed Ledger Technology) network 1 (https://z3us.com/) . The wallet is user experience (UX) driven, focusing on providing a streamlined interface for users to interact with decentralized finance (DeFi) applications and NFTs (Non-Fungible Tokens). Functionality Z3US provides functionalities such as managing accounts, sending and receiving tokens, staking tokens to receive rewards, and connecting to DApps (Decentralized Applications) directly from the browser wallet 1 (https://z3us.com/) . It also prides itself on offering state-of-the-art security features, including support for hardware wallets like Ledger. History The project was founded in 2021 and launched its Beta version in June of the same year. By August 2021, Z3US had integrated with decentralized exchanges (DEX). Roadmap The roadmap (https://web.archive.org/web/20230225221454/https://z3us.com/roadmap) for Z3US includes plans for Wallet Babylon upgrades in Q1/Q2 2023, followed by the release of a Z3US iOS app in Q3/Q4 2023. Radix As for the Radix DLT network, it is a decentralized, secure, scalable, and fast platform where Z3US operates. ## EtherealDAO URL: https://radix.wiki/ecosystem/etherealdao Updated: 2026-08-03 Summary: EtherealDAO was a Decentralized Autonomous Organization (DAO) that was developing the EtherealUSD stablecoin protocol on Radix. The initiative was ins… EtherealDAO was a Decentralized Autonomous Organization (DAO) that was developing the EtherealUSD stablecoin protocol on Radix. The initiative was inspired by projects like MakerDAO and Liquity on the Ethereum network. By taking the lessons learned from these decentralized financial (DeFi) primitives, EtherealDAO sought to innovate in the smart contracts and decentralized stablecoin space. Overview EtherealDAO, governed by the $REAL governance token, aimed to establish a CDP-type stablecoin protocol that brought stability to the Radix network ecosystem. It featured unique mechanisms designed to maintain a tight peg to the U.S. dollar. The DAO used the PoS staking rewards incentive structure native to the network to drive development and maintain the ecosystem's health. EtherealUSD The design of EtherealUSD was unconfirmed but the Litepaper (https://ethereal.systems/EtherealUSD_Litepaper.pdf) proposed using a system called Ethereal Collateralized Debt Positions (ECDPs). ECDPs was a balance sheet of assets to liabilities, a user-owned position with market-making capabilities via a function called "Mandatory Pegging". This system focused on a single-collateral, single-liability system for V1, named EtherealUSD. The system derived a Collateral Ratio (CR) from ECDP, which was the value of assets over liabilities. If the CR went under the Minimum Collateralization Ratio (MCR), the ECDP was liquidated. The liquidation process involved a Dutch auction to sell assets of the ECDP, and any difference between sold and total assets went to the Treasury. "Mandatory Pegging" was a module that allowed anyone to either mint or burn the stablecoin directly against the system without creating an ECDP. This module ensured that the peg of the stablecoin was maintained in the market. The system operated in different "System Modes" depending on the Total Collateral Ratio (TCR), which was the total assets in all ECDPs over total liabilities. Various percentage values (RecoveryPoint, BackstopPoint, ConvexityPoint, and CriticalPoint) acted as triggers for the system to change its behavior. These system modes provided mechanisms to deal with different market conditions and potential attacks. Motivations for these design choices were to address issues seen in other DeFi protocols, such as inefficiencies in capital usage, maintaining a tight peg, and handling market volatility in a smoother manner. Initial Validator Offering (IVO) One of the innovative methods employed by EtherealDAO was an Initial Validator Offering (IVO). This approach enabled DAOs to crowdsource support for projects contributing to the network while advancing the ecosystem. It operated by the DAO registering a validator and calling upon community members to delegate their stake with them. The variable fee was adjusted to 100%, effectively redirecting all emission rewards to the DAO treasury for later use in incentivizing protocol participation and running operations. As a reward for their support, delegators received the project's tokens at a later date. To participate, users needed to delegate to the validator for a duration of six months. The validator operated at 100% fees during this time, with the airdrop amount dependent on the stake size. An hourly snapshot was taken to reserve tokens pro rata for everyone. Post-IVO, the validator operated at a 7% fee. The airdrop was split into two drops - one approximately two months into the IVO and the second after the IVO concluded. Tokenomics EtherealDAO operated with the $REAL Tokenomics system. Of the total token supply, 20% was allocated to the IVO airdrop and 80% was reserved for the DAO, under the control of the token voters. There was no predetermined allocation towards early contributors or the team. The DAO's initiators would request a 10% allocation vested over two years. All aspects of the EtherealDAO tokenomics would be decided through a DAO vote. Proceeds from the validator went directly to the DAO treasury, controlled by the tokens, less the transaction fees to deliver the airdrop. The EtherealDAO airdrop would be in the form of 20% $REAL tokens and 80% $unREAL tokens. $UnREAL tokens were a 1:1 $REAL claim that unlocked after staking liquidity in the protocol. After the Babylon hard fork, only smart wallets holding the Ethereal Validator LSU would qualify for the airdrop. Once the EtherealUSD protocol was live, participants would be able to engage in both the protocol and the IVO. EtherealDAO continued to welcome contributions and support from those interested in advancing the Radix ecosystem. Further Reading - Litepaper (https://ethereal.systems/EtherealUSD_Litepaper.pdf) ## Brilliant On Chain / DApp In A Day #4 - Brunel University URL: https://radix.wiki/contents/history/dapp-in-a-day-workshop-4 Updated: 2026-08-02 Summary: Brilliant On Chain was an event organized by Brunel University’s Blockchain Society. It was the fourth event in the DApp In A Day series of Scrypto wo… Brilliant On Chain was an event organized by Brunel University’s Blockchain Society. It was the fourth event in the DApp In A Day (/contents/history/dapp-in-a-day-workshop-1) series of Scrypto (/contents/tech/core-protocols/scrypto-programming-language) workshops and was held at Brunel University in Uxbridge on the 4th of December, 2024 — the first in the series run by a student society rather than by Radix mentors, and the first to place the workshop inside a wider programme of talks and a panel. Brunel hosted the ecosystem again in July 2025 for the multi-day Brunel Hack 25 (/contents/history/brunel-hack-25) . Details TELEGRAM: https://t.me/RadixHackathon (https://t.me/RadixHackathon) DATE: 4th December, 2024 TIME: 13:00 - 20:00 LOCATION: Michael Sterling Building, Brunel University, Uxbridge UB8 3PH MENTORS: Azizi A (https://www.linkedin.com/in/azizi-adeyemo/) , Abdur Razzak (https://www.linkedin.com/in/-abdur-razzak/) ORGANISER: Brunel University Blockchain Society AGENDA: 13:00 - 13:10 - Kick-off and Welcome. 13:15 - 17:00 - Workshop with Radix: Develop and Deploy Your First Web3 Solution. 17:30 - 18:00 - Opportunities Of Steller. 18:15 - 19:00 - Panel Discussion: Brilliant On Chain. 19:00 - 20:00 - Photo Session & Networking. In the series Brilliant On Chain followed the series’ opening run of three mentor-led London workshops — #1 at the University of Westminster (/contents/history/dapp-in-a-day-workshop-1) , #2 at St Mary’s University (/contents/history/dapp-in-a-day-workshop-2-st-marys-university) and #3 at the University of Roehampton (/contents/history/dapp-in-a-day-workshop-3-roehampton) , all inside eight days that October and November. It changed the format in two ways that later events kept: the host society ran the event and supplied the mentors, and the Radix workshop sat alongside other programming, here a second talk slot and a panel discussion. #5 (/contents/history/dapp-in-a-day-workshop-5) returned the series to St Mary’s in February 2025 and #7 (/contents/history/dapp-in-a-day-workshop-7-roehampton) closed it at Roehampton in November 2025. The full index is kept on the #1 page (/contents/history/dapp-in-a-day-workshop-1) ; other Radix developer events are collected under History / Events (/contents/history) . Media “A huge thank you to [RADIX.wiki] for running an exceptional Web3 development workshop. The hands-on experience and one-to-one guidance left a lasting impression on our participants.” - Jyotirmoy “What an amazing event! It was an honour to be part of such a knowledgeable and dedicated team. Thanks to everyone who contributed to making this a success. This is just the beginning of the Brunel Society of Blockchain!” - Aman Gallery Terms and Conditions The following terms apply to participation in this workshop ("Workshop"). Entrants may create original solutions, prototypes, datasets, scripts, or other content, materials, discoveries or inventions (a “Submission”). The Hackathon is organized by the Workshop Organizer. Entrants retain ownership of all intellectual and industrial property rights (including moral rights) in and to Submissions. As a condition of submission, Entrant grants the Workshop Organizer, its subsidiaries, agents and partner companies, a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to use, reproduce, adapt, modify, publish, distribute, publicly perform, create a derivative work from, and publicly display the Submission. Entrants provide Submissions on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## Backeum URL: https://radix.wiki/ecosystem/backeum Updated: 2026-08-01 Summary: Status note (July 2026): Backeum is defunct – the backeum.com website is offline and dead links have been unwrapped. The project's Scrypto blueprint r… Status note (July 2026): Backeum is defunct – the backeum.com website is offline and dead links have been unwrapped. The project's Scrypto blueprint remains public on GitHub (https://github.com/backeum/backeum-blueprint) as an archived reference. Backeum was an online platform designed to foster a culture of appreciation and backing within the Radix community. It served as a bridge between creators and their backers, allowing creators to fundraise, share exclusive content, and reward their supporters with unique NFTs, all while building a genuine community around their work. https://youtu.be/AB1LkI3SDSA?si=zDwHMVb33GkXVUe9 (https://youtu.be/AB1LkI3SDSA?si=zDwHMVb33GkXVUe9) Overview Backeum promoted a simple culture of appreciation and backing. By extending support to those pushing forward, the platform aimed to help the network grow. Users could discover someone they admire, tip them, and send a heartfelt 'good job' their way. In a blog post introducing Backeum, the team shared their inspiration drawn from the Radix community's radvocates who are passionate about decentralized finance. The platform was envisioned as a friendly neighborhood cafe, focusing on genuine interactions and appreciation. NFTs on Backeum were likened to "thank you" cards, given by creators to express gratitude to their supporters. These NFTs could be found in the Radix Wallet, ensuring they were easily accessible, secure, and truly owned by the user. Features: - Profile: Users could create a Backeum profile to share information about themselves and their work. This profile allowed them to post updates, receive tips and donations, and verify their identity with their XRD domain for added trust. - Community: The platform boasted a community filled with individuals who genuinely care and work hard. Users could engage with their backers, connect with others, and experience the value of mutual support. - NFT Collections: Backeum offered the unique feature of turning gratitude into NFTs. Creators could design NFT collections to reward their backers, giving them a special token of appreciation. - Competitions: Backeum hosted competitions centered around talent and community. These friendly contests allowed users to showcase their skills and let the community be both their cheerleader and jury. Frequently Asked Questions - What is Backeum? Backeum was a platform designed for creators and their backers. It enabled creators to fundraise, share exclusive content, and reward their supporters with unique NFTs, all while building a genuine community around their work. - When will the Backeum dApp launch? The dApp was nearing completion and would be launching soon. Updates regarding the exact launch date would be provided on official channels. - How do backers support creators on Backeum? Backers could support creators in various ways, such as through donations, purchasing or trading NFTs, participating in competitions, and accessing exclusive content. - How do I connect my Radix wallet to Backeum? Users could select the "Connect" button in the top right menu and follow the on-screen prompts. For setting up the wallet connection to the browser, users could visit Radix's official website (https://wallet.radixdlt.com/) . For more detailed information, you could visit the FAQ section on the website. Telegram Handle No Longer the Project's The Telegram handle @backeum_news, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . ## VikingLand URL: https://radix.wiki/ecosystem/vikingland Updated: 2026-08-01 Summary: VikingLand was an NFT marketplace that operated on the Radix platform. Its team later merged the marketplace with Radish Square to form RadLand . The… VikingLand was an NFT marketplace that operated on the Radix platform. Its team later merged the marketplace with Radish Square to form RadLand (/ecosystem/radland) . The platform was launched in February 2022. The organization had no direct influence on the price of the NFTs sold on the platform and charged a 5% royalty fee and a 2.5% marketplace fee. Collections VikingLand hosted a variety of collections, including "Undying Vikings", which was an official collection of VikingLand. There were several other official collections as well, such as "RaEggs", "RaDragons", and "Viking Warrior". Revenue Distribution 10% of VikingLand's revenue was distributed among holders of their official collections, which included "RaEggs", "RaDragons", and "Viking Warrior". Projects VikingLand was home to several NFT projects, some of which were among the first and had since sold out on the Radix DLT. Link-rot note (2026-07-30): VikingLand's successor domain radland.io has been re-registered and now redirects to an unrelated forex-affiliate page, so the website field has been cleared. See RadLand (/ecosystem/radland) for the archived snapshots. Telegram Handle No Longer the Project's The Telegram handle @RadLandNFT, cited for this project on this page until August 2026, no longer belongs to it. Read on 1 August 2026, it resolved to a channel created 29 June 2026 with one subscriber, no description, and a single post styled as a Collab.Land (https://collab.land) token gate – "Click below to verify your wallet and gain access" – whose button leads to @CollabLandlBot. That is not @collablandbot (https://t.me/collablandbot) , which Collab.Land's documentation names as its only legitimate Telegram bot (https://docs.collab.land/help-docs/FAQ/join-tg-group/) . The link has been removed from this page; eight other Radix project handles were found in the same state, and are listed at Recycled Telegram Handles (/contents/resources/recycled-telegram-handles) . ## UNISCI URL: https://radix.wiki/ecosystem/unisci Updated: 2026-08-01 Summary: Status (July 2026): the project appears dormant . Its website uniquescire.com no longer resolves (NXDOMAIN, verified 2026-07-08) and there has been no… [Notice: Written like an advertisement] Status (July 2026): the project appears dormant. Its website uniquescire.com no longer resolves (NXDOMAIN, verified 2026-07-08) and there has been no visible activity since 2023. Social channels listed on RadixList (https://www.radixlist.com/item/unisci) ( @uniscinft (https://twitter.com/uniscinft) , Discord, Telegram) remain listed but unverified. Unisci is an NFT project built on the Radix Distributed Ledger Technology (DLT). We specialize in creating handmade NFTs, with each NFT representing a unique theme that changes with the seasons. Our focus on combining craftsmanship with the power of Radix DLT allows us to offer collectors an exclusive and diverse collection of digital artworks. Features Our primary objectives include: - Building a strong and exclusive community. - Establishing a Vault that supports the growth and development of exciting new projects. The Project Get ready to join the Unisci revolution - where we combine the unique and the scientific for a project that's truly out of this world! The first part of our name 'unique' perfectly reflects our NFT drops, each one a stunning masterpiece unlike anything you've seen before. But that's just the beginning! The second part of our name 'scire' represents the additional value we bring to the table with our innovative project. So what are you waiting for? Come join us on this incredible journey! Unique Step into our world of handmade wonder with our collection of 500 unique NFTs, each one released piece by piece for your viewing pleasure! We've got a grand plan of 5 seasons, each packed with 100 incredible NFTs, all with their own unique themes that'll make your imagination soar. And the best part? Every single NFT is lovingly crafted by us, with no automatic trait generators in sight. It's like stepping into a whole new universe of digital art, and we can't wait for you to be a part of it! Scire Join the unstoppable Unisci community, where we're all about sharing information, knowledge, and ideas to our holders. Wondering how we make it happen? It's simple! We pour a good amount of the income from our mint into our vault, ensuring that we have the resources we need to keep building and innovating. The Unisci Vault A big amount of the total mint will be devoted to investing in cutting-edge Radix projects, including eye-catching NFTs, as well as developing our very own project. Get ready to join a community of like-minded individuals passionate about pushing the boundaries of what's possible! Team The Unisci team consists of a project manager named Cala and artist named Flok. Seasons Season 1: Radix Community The first theme of our collection is: Radix community! That means you can put together your own avatar, which we will draw for you! And it gets even better: our season 1 will be free to mint!!! 88 have successfully applied and received their nft. The remaining 12 spots will be assigned by us in the course of the project. Season 2: Arctic Prepare to embark on a thrilling adventure as we unveil our second season - a journey into the stunningly beautiful, yet dangerously unforgiving, Arctic wilderness! Our expedition team is braving the icy tundra, encountering all sorts of creatures along the way - from the adorable and cuddly to the fierce and ferocious. But be warned - danger lurks behind every snowbank, and even the most innocent-looking creature may not be what it seems! The misty veil of the Arctic hides many secrets, and only the bravest and most daring explorers will survive this epic journey. So grab your parka and join us on the trip of a lifetime! Season 3: Universe Our third season takes us on an interstellar journey into the vast and mysterious universe. Our spaceship, the Unistar, is home to a diverse crew of astronauts and adventurers. As we travel through the galaxies, we encounter strange and fascinating creatures, visit exotic planets, and discover ancient civilizations. But not all is as it seems in the infinite expanse of space. Hidden behind the glittering stars and colorful nebulas, there are dangerous forces at work. We must be vigilant and careful as we navigate the unknown depths of the universe. ## Xidar URL: https://radix.wiki/ecosystem/xidar Updated: 2026-07-30 Summary: XIDAR was a service and tool provider specializing in Web3 and DeFi (Decentralized Finance). It offered a range of user-friendly, robust solutions tha… XIDAR was a service and tool provider specializing in Web3 and DeFi (Decentralized Finance). It offered a range of user-friendly, robust solutions that aimed to streamline the Web3 and DeFi space, enabling users to easily navigate and explore the future digital landscape regardless of their technical knowledge. XIDAR believed that technical expertise and comprehension of Web3 and cryptocurrencies should not be a barrier for users to take advantage of the ongoing technological and financial paradigm shift. Platform XIDAR's platform was built on Radix, a decentralized ledger technology (DLT) network. Radix was chosen by XIDAR due to its unique, comprehensive, integrated bottom-up technological approach. XIDAR viewed Radix as the only platform that can fully support its vision of Web3 DeFi and offers the ability to fully leverage a decentralized network that enables fast and secure development without sacrificing scalability or composability. Products XIDAR Wallet The XIDAR Wallet was an industry-leading browser and soon-to-be mobile wallet for the Radix network. It allowed users to manage, send, receive, stake, and swap all tokens and NFTs (Non-Fungible Tokens) from the Radix DLT network. It also featured the ability to create or import multiple accounts and addresses, manage balances, search transaction history, stake XRD tokens, swap tokens in-app, add contacts, create native Radix tokens, recover wallet automatically, send tokens to multiple addresses in one transaction, and buy XRD directly with a credit card. $IDA Token The $IDA token was a utility token within the XIDAR ecosystem that lived on the Radix DLT network. It had a fixed supply of 240 million tokens. The $IDA tokens would represent a vital utility asset within the XIDAR ecosystem and would continue to play a pivotal role in all its products and services. In particular, $IDA tokens would empower users with decision-making capabilities in XIDAR's upcoming investment DAO (Decentralized Autonomous Organization) and provide access to premium features within the XIDAR wallet. XIDAR planned to announce further benefits related to its upcoming no-code dApp creator. Tokenomics The tokenomics for the $IDA token were as follows: - Ecosystem/Community Rewards: 96,000,000 $IDA (40%) - Liquidity & Exchanges: 16,800,000 $IDA (7%) - Private Sales: 15,600,000 $IDA (6.5%) - Tech & Dev: 36,000,000 $IDA (15%) - Team & Advisors: 32,400,000 $IDA (13.5%) - Marketing: 28,800,000 $IDA (12%) - Treasury: 14,400,000 $IDA (6%) The vesting period for founders was 12 months with no cliff. Website (30 July 2026): xidar.io has no DNS record at all. An unregistered domain can be bought by anyone – four defunct Radix projects' domains have already been re-registered as unrelated landing pages – so the link has been removed from this page's facts table. ## launchspace URL: https://radix.wiki/ecosystem/launchspace Updated: 2026-07-30 Summary: Launchspace was an accelerator for decentralized applications (dApps) built on the Radix platform. In addition, it served as a marketplace for Scrypto… Launchspace was an accelerator for decentralized applications (dApps) built on the Radix platform. In addition, it served as a marketplace for Scrypto blueprints and audits. This means that Launchspace provided support and resources to developers who are building dApps on the Radix platform. It also offered a platform for developers to share and sell their Scrypto blueprints and audits. Scrypto-based systems aim to enhance the security and accuracy of digital identities and transactions. Mission The mission of Launchspace was to drive the adoption and success of decentralized applications built on the Radix platform. They aimed to achieve this by providing an accelerator program that supported developers in building and launching their dApps efficiently. Launchspace also served as a marketplace for Scrypto blueprints and audits. This marketplace enabled developers to share and sell their Scrypto blueprints, which are the building blocks for secure and efficient digital identities and transactions. Additionally, developers could also offer their audit services to ensure the security and reliability of dApps built on Radix. In summary, Launchspace's mission was to foster innovation and growth in the Radix ecosystem by providing the necessary resources, support, and marketplace infrastructure for developers to create and commercialize their dApps while ensuring the highest level of security and trust. Features Some of the key features of Launchspace included: Accelerator for Radix dApps Launchspace provided support and resources to developers who are building decentralized applications (dApps) on the Radix platform. This included mentorship, technical assistance, and guidance to help accelerate the development process. Marketplace for Scrypto Blueprints Launchspace offered a marketplace where developers could share and sell their Scrypto blueprints. Scrypto is a technology that aims to enhance the security and accuracy of digital identities and transactions. Developers could showcase their blueprints and make them available for others to use as a starting point for their own dApp development. Marketplace for Audits Launchspace also served as a marketplace for audits. This means that developers could offer their services to conduct audits of dApps built on the Radix platform. Audits help ensure the security and reliability of dApps and provide trust to users and investors. These features worked together to support the development and growth of the Radix ecosystem, providing resources and opportunities for developers to create innovative and secure dApps. Blueprint A blueprint of Launchspace included the following elements: Accelerator Program Launchspace provided an accelerator program specifically designed to support developers building decentralized applications (dApps) on the Radix platform. This program offered mentorship, technical assistance, and guidance to help accelerate the development process of dApps. Scrypto Blueprint Marketplace Launchspace served as a marketplace where developers could share, showcase, and sell their Scrypto blueprints. These blueprints are the foundational elements for creating secure and efficient digital identities and transactions. Developers could offer their blueprints for others to use as a starting point for their own dApp development. Audit Marketplace Launchspace also operated a marketplace where developers could offer their audit services. Audits play a crucial role in ensuring the security and reliability of dApps, and Launchspace provided a platform for developers to showcase and offer their auditing expertise to others in the Radix ecosystem. Overall, Launchspace's blueprint consisted of an accelerator program to support dApp development on the Radix platform and marketplaces for Scrypto blueprints and audits. These initiatives aimed to drive innovation, adoption, and success in the Radix ecosystem. Benefits There were several benefits of joining Launchspace as a developer building decentralized applications (dApps) on the Radix platform. These benefits included: Access to an Accelerator Program Launchspace provided an accelerator program specifically designed to support developers building dApps on the Radix platform. This program offered mentorship, technical assistance, and guidance to help accelerate the development process of dApps. Networking Opportunities By joining Launchspace, developers could connect with other developers, entrepreneurs, industry experts, and investors in the Radix ecosystem. This offered networking opportunities that could lead to new partnerships, funding, and growth opportunities. Marketplace for Scrypto Blueprints and Audits Launchspace provided a marketplace for Scrypto blueprints and audits. Developers could showcase their blueprints and offer their audit services to others in the Radix ecosystem, creating new revenue streams and opportunities for growth. Exposure and Visibility Joining Launchspace could help raise the profile of a developer's dApp, providing exposure and visibility to potential users and investors. Technical Resources and Support Launchspace could provide technical resources and support to developers when building their dApps on the Radix platform. This could help reduce technical challenges and shorten development timeframes. Overall, joining Launchspace as a developer could provide numerous benefits, including access to an accelerator program, networking opportunities, marketplaces for Scrypto blueprints and audits, exposure and visibility, and technical resources and support. Security Launchspace placed a strong emphasis on security, particularly in relation to decentralized applications (dApps) built on the Radix platform. Here were some key aspects of security in Launchspace: Scrypto Blueprints Launchspace operated a marketplace for Scrypto blueprints, which are foundational elements for secure digital identities and transactions. By providing a platform for developers to share and sell these blueprints, Launchspace encouraged the use of secure design patterns and best practices in dApp development. Audits Launchspace also served as a marketplace for audits, ensuring that dApps built on the Radix platform undergo thorough security evaluations. These audits help identify and address potential vulnerabilities or weaknesses in dApps, providing a higher level of security for users and investors. Technical Support Launchspace offered technical support and guidance to developers building dApps on Radix. This support included assistance with security-related aspects such as secure coding practices, encryption, authentication, and secure storage of user data. Collaboration and Knowledge Sharing By being part of Launchspace, developers had the opportunity to collaborate and share knowledge with other developers in the Radix ecosystem. This promoted the adoption of security best practices and helped the community stay vigilant against emerging security threats. Continuous Improvement Launchspace was committed to continuously improving security within its ecosystem. This included staying up to date with the latest security practices, technologies, and industry standards to ensure a robust and secure environment for developers and users alike. Website (30 July 2026): beta.launchspace.app has no DNS record, and neither does launchspace.app itself. An unregistered domain can be bought by anyone – four defunct Radix projects' domains have already been re-registered as unrelated landing pages – so the link has been removed from this page's facts table. See also - Caper (/ecosystem/caper) – bonding-curve fundraising for DAO formation ## Arcane Labyrinth URL: https://radix.wiki/ecosystem/arcane-labyrinth Updated: 2026-07-30 Summary: Arcane Labyrinth was an adventure game that offered players the experience of navigating through a labyrinth consisting of 101 different floors. The g… Blockchain / Play-to-Earn Adventure Game Title Arcane Labyrinth Category Adventure Game (Ecosystem) Genre & Style Fantasy adventure with 2D pixel art graphics; designed for nostalgia and accessibility. Key Features 101-floor labyrinth, play-to-earn rewards, co-op multiplayer, monster battles, and treasure collection. Token $ARC – total supply of 100,000,000 tokens; used for governance and play-to-earn rewards (12% allocated to airdrops and liquidity providers). Main Character Jack, a seasoned adventurer who discovers a mysterious portal leading to a world of monsters and mazes. Official Reference arcanelabyrinth.io (offline) Arcane Labyrinth was an adventure game that offered players the experience of navigating through a labyrinth consisting of 101 different floors. The game was set in a fantasy world and featured an attractive pixel art style, designed to evoke a sense of nostalgia in players. Unique to Arcane Labyrinth was its play-to-earn system, which rewarded players with $ARC tokens upon successful completion of each floor of the maze. About Arcane Labyrinth: Uncovering the Mysteries of a Fantasy World was an adventure game that immersed players in a magical fantasy world filled with various obstacles and challenges. The game's graphics utilized a 2D pixel art style that combined fantasy and magical elements, providing players with an interesting and fun nostalgic experience. The game's difficulty was designed to be exciting yet fair, and not overly challenging to overcome. Plot The game's story revolved around a character named Jack, a seasoned adventurer from a remote village. Jack stumbled upon a mysterious portal in the middle of a forest, which transported him to a world filled with monsters and mazes. Gameplay The objective of the game was to complete each floor of the labyrinth by battling monsters and collecting treasures scattered throughout the maze. Players could discover new weapons and magic to assist them in combat and in solving more complex maze floors. The game also included a co-op multiplayer feature, allowing players to collaborate and assist each other in completing the floors of the maze. Tokenomics The game's economy was based on $ARC tokens, with a total supply of 100,000,000 tokens. These tokens were used for governance and play-to-earn rewards. The token distribution included 12% for airdrops and liquidity providers. Vision and Mission The creators of Arcane Labyrinth aimed to provide a fun and challenging gaming experience, with innovative features and unique level design that harkened back to classic gaming concepts. Their mission included creating an eye-catching and stunning game design, making gameplay challenging yet fair and fun, providing a co-op multiplayer feature, crafting an engaging and innovative story, and continuously developing and improving the game. ## Radix Namespace URL: https://radix.wiki/ecosystem/radix-namespace Updated: 2026-06-29 Summary: Radix Namespace is a permissionless, on-ledger domain name service built on the Radix network. Developed from the ground up by community member Wylie… Introduction Radix Namespace is a permissionless, on-ledger domain name service built on the Radix network. Developed from the ground up by community member Wylie and open sourced in February 2026 (https://t.me/RadixDevelopers) . It is implemented as an entiely new namespace (distinct from the now deprecated Radix Name Service) and is intended to be operated independently with optional compatibility paths for importing domains from other accepted domain-NFT resources. The system is currently deployed on Stokenet (Radix testnet). A key part of the design is that mainnet instantiation and stewardship must be taken on by another community member or ecosystem project (i.e., a separate operator becomes the instantiator and go-live steward). The "genesis" source code (https://github.com/radix-namespace) is fully open and organised as a GitHub organisation with core contracts and "turnkey" tooling, including a management client that guides deployment/configuration. Current Stokenet deployment: - Package: package_tdx_2_1pkq94qsyttgk89fe4suh3xsq24adfeypd9s6pd0zramlt8cew4ctty - Component: component_tdx_2_1cq3hzzgwypv3494aprg76c3pvxwpxmwalm7ld257pudj8urzc6l5ap - Genesis code org (to be forked): https://github.com/radix-namespace Features Radix Namespace provides a comprehensive naming system with the following capabilities: - Human-readable domains — register domains backed by bonds (stablecoins are the intended use case) - Subdomains — create, edit, and delete subdomains under any registered domain - Data records — store arbitrary records (wallet addresses, social links, metadata) against a domain - Reverse resolution — link an account address to a primary domain so others can discover a domain by address - Domain import compatibility — accepted domain NFT resources can prove ownership and receive the equivalent domain in this namespace - Third-party registrars — service providers can register as registrars, set a fee percentage, and earn fees on registrations they facilitate - Bond model (rebond/unbond) — bonds aren’t burned; owners can swap token backing (rebond) or return the domain to reclaim the bond (unbond) - Pre-allocation — admin can reserve domains for specific accounts before go-live; anyone can pay on behalf of an eligible claimant - On-ledger QR codes — each domain NFT includes a generated QR code stored entirely on-ledger as a lightweight SVG (no IPFS dependency) - Isolated subregistries — each domain gets its own subregistry component and a dApp definition account for wallet recognition Architecture The project is organised as a GitHub organisation (https://github.com/radix-namespace) containing several repositories, including: - Core Scrypto smart contracts — the namespace logic for registration, management, and resolution - TypeScript SDK — developer-friendly bindings for integrating the on-ledger components into apps and platforms - SDK documentation — reference docs for the SDK - Management client — a guided “wizard” style tool for instantiation, configuration (including reservations), inspection, and activation (burning admin badge to go live) Most repos include workflows intended to support facilitators/project leads, and the design allows the instantiator to define which external domain-NFT resources are “importable” for compatibility/migration purposes. Permissionless Design Once instantiated on mainnet, the admin badge is burned, permanently removing all admin access and making the system fully permissionless. No single entity can modify, censor, or control domain registrations after launch. Relationship to ILIS Radix Namespace is under community consideration to be integrated into the broader ILIS (I Like It Stable) (https://flux.ilikeitstable.com) ecosystem, built by octo.xrd (Radix Foundation member). Radix Namespace became a subject of ILIS orientated discussion in February 2026, with the fUSD stablecoin — a USD-pegged token created by borrowing against XRD collateral — being considered as a bond resource for domain registration. The bond model creates a natural synergy: domain registrations generate a use case for fUSD, while fUSD provides a decentralised stablecoin option for backing domain bonds without relying on centralised stablecoin issuers. External Links - GitHub Organisation — radix-namespace (https://github.com/radix-namespace) - ILIS (I Like It Stable) — fUSD Stablecoin (https://flux.ilikeitstable.com) - Telegram — Radix Developer Discussion (https://t.me/RadixDevelopers) Radix Namespace Type Name Service / Address Abstraction Original Developer Wylie Bond Model USD stablecoins (bonded, not burned) Stokenet Package package_tdx_2_1pkq94qs...cew4ctty Ecosystem Part of ILIS (https://flux.ilikeitstable.com) ## XRD Domains URL: https://radix.wiki/ecosystem/xrd-domains Updated: 2026-03-28 Summary: XRD Domains was a now-deprecated domain registration and management platform for .xrd names on the Radix network, and a major builder of tooling aroun… XRD Domains was a now-deprecated domain registration and management platform for .xrd names on the Radix network, and a major builder of tooling around the Radix Name Service (RNS). It previously served as the primary user-facing gateway for discovering, acquiring, and administering .xrd domains. In practice, XRD Domains acted as the "dashboard" experience for .xrd owners - abstracting the underlying on-ledger complexity and providing a more approachable interface for handling records / configuring how a domain resolved or behaved across Radix applications. As a result of the Radix Name Service (RNS) community vote, the project adopted a wind-down path for XRD Domains. The vote endorsed moving toward an immutable, fork based method of operation at community level, so a namespace could continue as a neutral, long-lived piece of infrastructure without depending on a single operating team or funding. In practice, that community-approved transition meant the centralized platform work that XRD Domains previously provided, was no longer the intended operating model and a clear cut path forward was necessary. With a new, alternative and open-sourced protocol designed to be durable and registrar-agnostic, XRD Domains was deprecated and subsequently closed as an active service.