Layer 1 blockchain
Radix ticker XRD
Summary
Radix mainnet runs a HotStuff-derived BFT consensus with a delegated proof-of-stake validator set. At the start of each epoch (about five minutes) the top 100 registered validators by delegated XRD stake form the active set; votes count by stake and a quorum needs more than two-thirds of it. The docs describe deterministic finality with no probabilistic forks. Cerberus, the sharded consensus design published in 2020, is not active on mainnet: the network still runs as one shard, and Radix's 2024 roadmap says the team put the Radix Engine and Scrypto first. On 31 August 2026 validators took enough stake offline to stop commits after an engine exploit. The Eagle Ray update, set in the node software to enact unconditionally at epoch 339,898, restarted the ledger: the Gateway records that epoch's first transactions on 11 September 2026, and it was still advancing on 29 September. 14192021222324
Design
- System
- Layer 1 blockchainThe Radix Public Network is an independent layer 1 with its own delegated proof-of-stake validator set; it does not settle to another chain. It went live as Olympia in July 2021 and was rebuilt by the Babylon upgrade in September 2023. Its ledger is kept as a numbered stream of committed transactions grouped into epochs: consensus proposes vertices, but their boundaries disappear once committed. Commits stopped from 31 August 2026 after an engine exploit and resumed on 11 September 2026 with the Eagle Ray protocol update.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- Each consensus round has one leader from the active set. The node software rotates leaders in proportion to stake, so validators with more stake propose more often. The leader's round-change transaction records missed proposals, and at the epoch change a validator's share of new XRD emissions is scaled by its reliability; with mainnet's current setting, missing even one of its proposals in an epoch forfeits that epoch's emissions. Anyone can register a validator by paying a creation fee in XRD, but only the top 100 by stake take part in an epoch.
- Fork choice
- No open weight-based chain selection. A vertex commits only with a quorum certificate signed by validators holding more than two-thirds of active stake, and committed transactions are final. If more than one-third of stake stops voting, commits halt until enough returns; validators used this on 31 August 2026 to stop the ledger on purpose.
Qualifications
- Settlement family · Partial. Recorded as other. Radix's own terms: the Radix Public Network settles on its own node software (a Java service wrapping a Rust core that embeds the Radix Engine), with HotStuff BFT consensus, an asset-oriented Radix Engine where tokens are native resources held in vaults, Scrypto blueprints compiled to WebAssembly, and human-readable transaction manifests. Nothing settles to another chain.
- Finality · Partial. Recorded as other. Radix's own terms: HotStuff BFT with a decentralized validator set gives deterministic finality; commits are final and there are no probabilistic forks. A commit needs validators holding more than two-thirds of active stake. No slashing backs it today: missed proposals only forfeit emissions, and the validator docs say locked owner stake may be at risk of slashing in future.
- Block metrics · Partial. The ledger has no block numbers for integrators: every committed transaction gets a state version, an auto-incrementing number with no gaps, and transactions are grouped into epochs of about five minutes. Consensus vertices exist, but their boundaries disappear once committed, so the docs tell integrators to use the state version where they would expect a block height.
- Sharding · Not applicable. Mainnet is not sharded. Cerberus, the sharded design, and the Hyperscale research network are not live on mainnet; sharded operation is planned for the Xi'an release. Hyperscale test results describe that research network only.
- Tps · Contested. The published throughput figures come from the Hyperscale research network and from plans; no measured mainnet rate with a published method was found. They are kept in the classified claims list and are not comparable with observed mainnet load.
- Slashing · Not applicable. No slashing is active. With mainnet's current reliability setting, a validator that misses any of its proposals in an epoch receives no emissions for that epoch, and stakers wait about one week to unstake. The validator docs describe owner stake locked with a four-week withdrawal delay as a signal of commitment that may be at risk of slashing in future.
- Upgrade process · Partial. Named protocol updates normally enact at an epoch boundary once validators holding a set share of stake (75% for Anemone, Bottlenose and Cuttlefish) have signalled readiness for a set number of epochs. The September 2026 Eagle Ray update was instead coded to enact unconditionally at epoch 339,898, with user transactions barred for the epoch before, so node operators adopted it by upgrading.
- Operational dependence · Contested. Consensus runs on independent validators, but the default Gateway, wallet connection relays, node releases and docs were Foundation services. The Foundation entered maintenance mode in May 2026, pre-funded a standalone team of its former DevOps staff to run the Gateway and relays through December 2026, and hands decisions to an elected Radix Accountability Council and a planned DAO. Whether this is decentralized is contested and not scored here.
Tradeoffs
- Emphasizes
- Security and Scalability
- Gives up
- Open, unbounded participation in consensus, and on today's mainnet, horizontal scale. Only the top 100 validators by stake take part in each epoch, and mainnet runs as one shard until the planned Xi'an release, which has no confirmed schedule. Protocol updates have shipped as node software from Foundation-funded developers, and the September 2026 recovery update was fixed to enact at a set epoch without a stake-weighted readiness vote.Scalability is the stated goal of the Cerberus design and the Hyperscale research network, not a property of current mainnet. Security here means BFT safety with deterministic finality, which held during the August 2026 incident. The exploit itself was an engine authorization defect introduced in 2023 and missed by a 2024 audit, so asset safety depended on engine correctness. No slashing is active today.
- Full node at home
- Demanding 567The node guide suggests 8 CPUs, 16 GB of RAM, 500 GB of SSD storage to start and at least 100 Mbps of bandwidth, on Ubuntu 22.04 with a Java 17 runtime; builds are listed for Linux, macOS and Windows. Every node keeps the complete ledger state, and anyone can run one without stake. Joining consensus needs enough delegated stake to rank in the top 100 validators. The Radix Wallet reads through a Gateway by default; the Gateway is a separate indexer set up alongside a node, so running one adds to these requirements.
- Throughput claims
- Lab benchmark: 500,000 tx/s 2526Controlled benchmark; not observed network behavior.Public Hyperscale test on 31 January 2026 (sustained rate as reported by the interim Hyperscale lead).128 shards; 384 bootstrap and 40 validator nodes on AWS m6i.xlarge instances (4 cores, 16 GB RAM) plus community-run nodes; 6 load-generation nodes with 48 cores and 192 GB RAM each.Measured on Hyperscale, a separate research network, not on Radix mainnet, which still runs one shard on its existing node software. The Foundation called it a public, non-validated performance test; no third party certified the figure, and the setup, code and logs were still to be published when the phase closed in February 2026. The load was swap transactions generated by the test's own load nodes; the two posts report peaks differently (above 700,000 and above 800,000 per second). Any mainnet use depends on the planned Xi'an release, whose delivery is now a community matter with no confirmed schedule.
- Theoretical peak 172324Theoretical peak; not comparable across chains or with observed load.Unbounded ('unlimited', 'infinitely scalable') throughput claimed for the planned Xi'an release through sharded Cerberus; no figure given.Xi'an is a plan. The November 2024 roadmap targeted an alpha in early 2027 and launch in the second half of 2027; the Foundation ended its own Hyperscale work in February 2026, so that timeline no longer has a funded owner. The claim describes a design property (linear scaling by adding shards), not a measured or configured rate.
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Built into the protocolLimited scope | Limited to exchanges on Radix itself. A transaction intent can be signed by up to 16 signers, its manifest runs every step as one atomic unit and can assert what each account receives, and a failed transaction rolls back every change except fees, so two parties can co-sign one transaction that moves both assets in full or not at all. This is the ordinary signed transaction, separate from the subintents assessed under signed offers. No hash-time-locked or other trust-minimised cross-chain swap was found in the reviewed docs. 21112 |
| Authenticated data publication | Unknown | No data-publication feature was found in the reviewed docs. The ledger keeps Merkle trees over state and over transaction payloads and receipts, which are building blocks, but no documented flow lets a publisher commit to data that others retrieve and check against the commitment. 1 |
| Light clients | Built into the protocolLimited scope | Protocol, limited: consensus signs proofs of the committed ledger, and the docs say a chain of epoch proofs from the genesis epoch proof can verify the current validator set and current ledger proofs, while Merkle trees over state, transaction payloads and receipts can verify state and transaction outcomes. The limit: no packaged light client was found, the reviewed docs point users to full nodes, the Core API or the Gateway, and a verifier must start from the genesis epoch proof and fetch proofs from a node. 16 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer on Radix was found in the reviewed sources. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Spend conditions come from the engine's badge and access-rule system: accounts, resources and Scrypto components (blueprints compiled to WebAssembly and run by the Radix Engine) assign roles whose rules can require signatures, badges or combinations of them. Accounts can also be placed under the built-in access controller, which holds the account's owner badge behind primary, recovery and confirmation roles. 891015 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Built into the protocolLimited scope | Part (b) through the built-in access controller: an account's owner badge can be held under primary, recovery and confirmation roles, and a recovery started by the recovery role can be confirmed by anyone after a timed-recovery delay the owner sets in advance, replacing the lost factors. Part (a) is limited to the built-in account locker, where an application can take back resources it stored for a user who has not yet claimed them. An ordinary completed transfer cannot be reclaimed or cancelled. 81516 |
| Rollups | Unknown | No rollup or validium settling to Radix was found in the reviewed sources; scaling work targets sharding the base layer. |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Built into the protocolFull scope | Subintents (called pre-authorizations in the wallet), part of the transaction format since the Cuttlefish update in December 2024: a maker signs a subintent that withdraws what they give, yields it to a parent and asserts what they must get back; whoever holds it can wrap it in a transaction (unless the maker limits which parent may use it), and both legs commit in that one transaction or not at all while the maker's assets stay in their account. Matching happens off the network; a subintent carries an expiry window. Atomix, a third-party mainnet app, uses them for direct offers. 3131431 |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | ThinOciswap, DefiPlaza, CaviarNine | DeFiLlama lists several exchanges on Radix, including Ociswap's Basic and Precision pools and CaviarNine's pool products, which it lists on Radix only, and DefiPlaza, which it lists on Radix and Ethereum; Ociswap and DefiPlaza served their own apps at review. The Foundation's incident report says liquidity pools were among the vaults drained on 31 August 2026. Operators, audits and current liquidity depth were not reviewed. 2737 |
| Issuer-native stablecoins | None found | Neither Circle's USDC contract list nor Tether's supported-protocol list includes Radix. Dollar tokens on Radix were bridged representations minted through Hyperlane routes, which were shut down during the August 2026 incident. 27303536 |
| Algorithmic stablecoins | Unknown | No algorithmic dollar stablecoin with material use was verified. DeFiLlama lists Flux, a borrowing protocol that lends against staked XRD with user-set interest rates, and the STAB Protocol, whose stable asset has a variable target set by an interest-rate mechanism; both are collateral-backed designs and were not reviewed. 37 |
| Bridges | UnknownHyperlane warp routes (third party; shut down 31 Aug 2026), Astrolescent (bridge front end), Maya Protocol (third party; XRD not listed at review) | Hyperlane warp routes went live on Radix in September 2025 for USDC, USDT, wBTC and ETH to and from Ethereum, Arbitrum, Base and BNB Smart Chain, and after Instabridge shut down they became the route for eXRD, XRD's Ethereum form. On 31 August 2026 Hyperlane took its Radix validators offline and the Foundation paused routes; reopening was not verified. DeFiLlama also lists Maya Protocol, a separate cross-chain swap network, on Radix, but Maya's node API did not list XRD on 29 September 2026. With no route verified open at review, whether any bridge works today is not known. Risk: Users trust Hyperlane's validator and relayer set and route owners, not Radix consensus; Maya Protocol swaps rely on the vaults its own network manages. The 2026 exploit drained bridged assets from vaults on Radix and moved them out through the Hyperlane routes, and the bridge could only help contain it by shutting down. A wrapped asset is only as sound as the bridge that minted it. 272829303738 |
| Block explorers | Established in the ecosystemRadix Dashboard (now served as RadixScan), RadXplorer | Radix's docs list dashboard.radixdlt.com as the mainnet explorer and staking dashboard; at review that address redirected to RadixScan's dashboard, and the Foundation says the Dashboard now runs on community or free-to-host alternatives. RadXplorer, a separate site, describes itself as a Radix explorer; only its page metadata was read. Neither operator was verified. Explorer data is provider-indexed. 18283940 |
| Hardware wallets | ThinLedger (through the Radix Wallet) | See custody rows: a Ledger device signs through the Radix Wallet and the Radix Connector extension using the Radix Babylon device app, while Ledger's own currency list has no Radix entry; Trezor says it does not support Radix. 323334 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Through an intermediaryRadix Wallet with the Radix Connector browser extension, signing with the Radix Babylon device appSame as native: Unknown | Can: Install the Radix Babylon (XRD) app on a Nano S, S Plus or X from Ledger Live's app catalogue, per Radix's guide Can: Create a hardware-protected account in the Radix Wallet and approve every transaction on the device Can: Verify an account address on the device screen Cannot: Find Radix or XRD in Ledger's published Ledger Wallet currency list (@ledgerhq/cryptoassets 13.56.0) Cannot: Use the account without the Radix Wallet and the Radix Connector extension on a linked computerRadix's guide says Nano S support may end in future updates and that the flow will change when multi-factor account control reaches the Radix Wallet. Ledger's coin page address for Radix redirected to its general supported-assets list at review. 3233 |
| Trezor | None foundSame as native: No | Cannot: Manage Radix in Trezor Suite; Trezor's page says it does not currently support RadixTrezor's page asks users who used Radix with Trezor before to contact support; no third-party signing path is named. 34 |
Public data
iKnow Blockchain has no public-data lookups for Radix yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Reviewed Sep 29, 2026 Next review due Oct 9, 2026, 12:00 UTC.
Publication date · newest first
-
Foundation report: engine flaw exploited on 31 August 2026 and ledger halted by validators
The Radix Foundation's incident report says an attacker used a Radix Engine flaw, introduced in a June 2023 code tidy-up and missed by a 2024 audit, to withdraw Hyperlane-bridged ETH, WBTC, USDT, USDC, BNB and SOL from vaults it did not own, including liquidity pools, and moved them off Radix. Hyperlane removed Radix from its validator and relayer operations and was asked to shut the remaining routes, and within about three hours of the first report validators took enough stake offline to stop all commits. The fix was reviewed by audit firms, and the report, version 1.4, described restoration as in progress.
- Implementation:engine fix written and independently reviewed
- Release:incident report published (version 1.4)
- Activation:commits halted from 31 August 2026; they resumed on 11 September 2026 with the Eagle Ray update
Sources: Radix Foundation (Radix Blog) — Public Incident Report: Vault-Authorisation Vulnerability and Loss of Network Liveness (external site) · Radix DLT (babylon-node repository, GitHub) — mainnet_protocol_config.rs at v1.4.0.0 (external site) · Radix Foundation Gateway — Radix mainnet Gateway transaction stream from epoch 339,898 (read 2026-09-29) (external site)
-
Eagle Ray protocol update (node v1.4.0.0) released with the engine fix
Radix's node repository published Eagle Ray v1.4.0.0 on 10 September 2026, two days after a release candidate. The mainnet protocol configuration in that release enacts Eagle Ray unconditionally at the start of epoch 339,898, with user transactions barred during epoch 339,897, so it does not wait for the stake-weighted readiness signal used for earlier updates. The node release notes contain only licence text; the matching engine release, Scrypto v1.4.0 (7 September 2026), moves the engine to a new system version that checks whether a caller may invoke the object it names.
- Implementation:engine change in Scrypto v1.4.0; shipped in babylon-node v1.4.0.0
- Release:released 10 September 2026 (release candidate 8 September)
- Activation:enacted at epoch 339,898; the Gateway records that epoch's first transactions at 11:39 UTC on 11 September 2026
Sources: Radix DLT (babylon-node repository, GitHub) — Eagle Ray v1.4.0.0 (external site) · Radix DLT (babylon-node repository, GitHub) — mainnet_protocol_config.rs at v1.4.0.0 (external site) · Radix DLT (radixdlt-scrypto repository, GitHub) — Scrypto v1.4.0 (Eagle Ray) (external site) · Radix DLT (radixdlt-scrypto repository, GitHub) — system_callback.rs at v1.4.0 (caller access check enabled from system version 5) (external site) · Radix Foundation Gateway — Radix mainnet Gateway transaction stream from epoch 339,898 (read 2026-09-29) (external site)
-
Radix Foundation moved to maintenance mode and pre-funded core services through 2026
The Foundation said that from May 2026 it would reduce to essentials: minimal new development, critical-only social updates and minimal support. The Gateway, Signalling Server and Radix Connect Relay moved to a standalone operation run by its former DevOps team, pre-funded through December 2026. The Dashboard, docs and developer console moved to community or free hosting, the eXRD route runs over Hyperlane, and the remaining treasury is to pass to a community entity once one exists.
- Proposal:set out in the January 2026 strategy
- Implementation:services transferred or moved to community hosting as described
- Release:announced 28 April 2026
- Activation:maintenance mode from May 2026
Sources: Radix Blog — Foundation Update: Moving to Maintenance Mode (external site) · Radix Blog — 2026 Strategy: The Next Chapter of Radix (external site) · Radix Blog — The Foundation Operational Stack: Mapping the 2026 Transition (external site)
-
Foundation closed its interim Hyperscale research phase after a public test
The interim Hyperscale lead reported that a public test on 31 January 2026 sustained the throughput target set for it, using swap transactions across 128 shards with cross-shard atomic transactions, on commodity cloud machines plus community nodes; a private test showed per-shard throughput holding when the shard count doubled. The closing post hands the work to the community and says the Foundation intends to open-source the remaining code and publish the test setup and network configuration, with no date because parties outside the Foundation must agree. Hyperscale is a research network, not Radix mainnet.
- Implementation:research network tested; not integrated into mainnet software
- Release:no release; open-sourcing of remaining code pending
- Activation:not activated on mainnet
Sources: Radix Blog — Interim Hyperscale: Closing the Chapter (external site) · Radix Blog — Hyperscale Update: 500k+ Public Test Done (external site) · RadixTalk (community-run) — [RFC] Xi'an: Delivering Hyperscale for Radix (external site)
-
Token holders elected a five-member Radix Accountability Council
A consultation weighted by XRD, run from 30 January to 6 February 2026, chose a five-member council from 22 nominees to guide the move from the Foundation to a community structure; about 1.34 billion XRD from 1,151 accounts took part. The council's remit is to set up its operating framework, coordinate transition tasks and act as the interface between the community and the Foundation. A separate consultation, published on 13 February, approved tapering the Foundation's validator subsidy to zero by June 2026.
- Proposal:consultation opened 30 January 2026
- Implementation:council elected
- Release:results published 7 February 2026
- Activation:council setting up the DAO entity, per the Foundation's April 2026 update
Sources: Radix Blog — Consultation Results: Radix Accountability Council (external site) · Radix Blog — Consultation Results: The Future of the Validator Subsidy (external site) · Radix Blog — Foundation Update: Moving to Maintenance Mode (external site)
Topics your AI can explain
Your AI can explain these topics for Radix through the connection, with sources.
Known gaps
What this profile's review did not establish:
- No measured mainnet throughput or finality time with a published method was found; the only figures come from the Hyperscale research network and from plans.
- The current number of registered validators and the stake held by the largest validators were not read, so stake concentration is not recorded.
- No Radix Foundation announcement of the restart was found. The date comes from the node configuration (epoch 339,898) and the Gateway's record of that epoch's first transactions (11:39 UTC on 11 September 2026). The Foundation's incident report, version 1.4 of 17 September 2026, still says restoration is in progress and that nothing has committed since liveness was lost.
- Radix's protocol update pages still list Dugong as in development and do not mention Eagle Ray. The engine code for Eagle Ray (Scrypto v1.4.0) was read only for its single system-version change, which adds a check on whether a caller may invoke the object it names; no Foundation write-up of the update was found.
- Whether the Hyperlane routes reopened after 31 August 2026, and how drained pools and bridged balances were handled, was not verified.
- The Radix Wallet's multi-factor account flow was in Stokenet testing in the reviewed posts; its mainnet release was not verified, though the access controller it uses is live.
- A Radix DAO formation vote was shown as open on Radix sites at review; its terms and outcome were not read.
- The operators of RadixScan and RadXplorer, and who runs the Gateway after the Foundation's funding ends in December 2026, were not verified.
- Two public API providers listed in Radix's docs (Grove's Core API endpoint and RadixAPI) did not resolve on 29 September 2026; the provider list may be stale.
- Whether the remaining Hyperscale code, configuration and logs were published, and whether the April 2026 community proposal to build Xi'an was accepted, was not verified.
- Exchange liquidity, operators and audits of the DEXs, and any algorithmic stablecoin beyond DeFiLlama's listing, were not reviewed.
- No cross-chain atomic swap, packaged light client or data-publication feature was found; absence was not exhaustively verified.
- Whether Ledger Wallet shows XRD balances directly was not tested; Ledger's currency list has no Radix entry.
Sources
Oldest dated source check: Source checked Sep 29, 2026 Next check due Oct 29, 2026.
- Consensus, Ledger Forks, Blocks, and Trust chains (external site)
- Transactions for Integrators (external site)
- Cuttlefish (protocol update page) (external site)
- Consensus Manager (external site)
- Validator (external site)
- Node overview (external site)
- Running a Node (external site)
- State Model - Introduction (external site)
- Authorization (external site)
- Scrypto (external site)
- Transactions & Manifests (external site)
- Transaction Limits (external site)
- Subintents (external site)
- Pre-authorizations & Subintents (external site)
- Access Controller (external site)
- Account Locker (external site)
- Introduction to Radix at Babylon (external site)
- Environments (external site)
- mainnet_protocol_config.rs at v1.4.0.0 (Eagle Ray enactment epoch and transaction moratorium) (external site)
- WeightedRotatingLeaders.java at v1.4.0.0 (stake-weighted leader rotation) (external site)
- ValidationState.java at v1.4.0.0 (stake-weighted quorum threshold) (external site)
- Radix mainnet Gateway transaction stream from epoch 339,898 (read 2026-09-29) (external site)
- Cerberus: A Parallelized BFT Consensus Protocol for Radix (v1.01, March 2020) (external site)
- Radix Labs Roadmap - To Hyperscale and Beyond (external site)
- Hyperscale Update: 500k+ Public Test Done (external site)
- Interim Hyperscale: Closing the Chapter (external site)
- Public Incident Report: Vault-Authorisation Vulnerability and Loss of Network Liveness (external site)
- Foundation Update: Moving to Maintenance Mode (external site)
- 2026 Strategy: The Next Chapter of Radix (external site)
- Hyperlane is Live! (external site)
- Radix Subintents in Action: Peer-to-Peer Trading with Atomix (external site)
- Using Ledger Nano S, S Plus or X with the Radix Wallet (external site)
- @ledgerhq/cryptoassets 13.56.0 currency list (external site)
- Radix wallet (support status) (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
- DeFiLlama protocols API (Radix entries: Ociswap, DefiPlaza, CaviarNine, Flux, STAB Protocol, Maya Protocol and others) (external site)
- Maya Protocol node API: inbound addresses (chains listed on 2026-09-29) (external site)
- RadixScan Dashboard: Explorer, staking and more for Radix (external site)
- RadXplorer - Radix Explorer (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding