Xi’an (also written Xian, said /ʃi’æn/) is the planned next major release of the Radix network, the layer-1 ledger that today runs the Babylon release. Xi’an would spread the ledger across an unlimited number of shard groups rather than one, which is what makes Radix’s sharded state model usable in production and what its claims of linear scalability and unlimited atomic composability rest on.
Development toward it runs in hyperscale-rs, a Rust consensus project named as the production candidate in an RFC put to the Radix governance forum on 20 April 2026. Xi’an has no current release date; the two schedules published for it, and what overtook each, are in Release Timeline below.
Release Timeline
Two dated plans have been published for Xi’an. Neither is current.
Radix Labs roadmap, 30 November 2024
The last schedule to come from Radix itself was published on 30 November 2024 as Radix Labs Roadmap - To Hyperscale and Beyond, which spells the release Xian throughout:
| Radix Labs roadmap, November 2024 | |
| Production planning of Xian | Q4 2025 |
| Implementation of Xian in Rust | 2026 |
| Alpha Xian | early 2027 |
| Beta Xian | mid 2027 |
| Launch | H2 2027 |
Three tracks were to run in parallel to reach those dates: the Cassandra research network, a sharding upgrade to the Radix Engine due to finish implementation in Q3 2025 and pass a soft audit in Q4 2025, and Xi’an itself. Xi’an was to run on the sharded Radix Engine that second track produced. It will not: the production candidate is building a purpose-built virtual machine instead, a decision confirmed on 1 August 2026 and set out under Execution Layer below. Radix has published no revised dates since.
The Xi’an RFC, 20 April 2026
The second plan came from outside Radix. The developer of hyperscale-rs, posting as flightofthefox, proposed delivering Xi’an across six milestones – the validator lifecycle, engine and gateway alignment, a gateway rewrite, a desktop validator application, post-quantum cryptography, and mainnet launch – for 300,000 USD-equivalent paid in XRD, with a 50m $XRD bonus on the sixth. The timeline was 18 months to mainnet-ready delivery plus a 12-month support window, best case a testnet in Q4 2026 and mainnet in Q1 2027.
Only the first milestone was funded. It passed the community consultation process in May 2026 and the Radix Foundation paid it directly rather than wait for the DAO to be constituted; the remaining five depended on a DAO treasury that had not come online. At 00:28 UTC on 3 September 2026, three days into the network halt, the developer wrote in the project channel that he had decided not to pursue any proposal, grants or ongoing engagements with Radix. The funding terms lapsed with that: the five unpaid milestones, the Radix Accountability Council sign-off on each of them, and the arbitration clause. The work did not – he said he anticipated no change in the velocity of delivering the tech – and on 12 September he reported Milestone 1 delivered in full and said he was not requesting its 50,000 USD payment.
What is scheduled now
Nothing is. On 12 September 2026 the developer declined to give dates, saying the milestones keep their order but that the virtual-machine work is larger than the RFC assumed and that migration preparation will likely grow with it; he would not estimate how long after feature-complete he would recommend any network adopt the result. Radix is not a settled destination for the code either. Both hyperscale repositories carry a dual MIT and Apache-2.0 licence, which lets Radix adopt them, and the developer said on 12 September that an upgrade path exists and that he would guide it – while placing Radix among the candidate networks rather than ahead of them. The hyperscale-rs article records that exchange in full.
State Model
The Radix 'universe' exists on a fixed space of 2^256 data shards, served by a distributed network of validators called Shard Groups. Shard coverage for Xi’an will be allocated according to processing power, storage and bandwidth. A fixed ledger space allows wallet addresses to be deterministically mapped to a shard and, hence, for the global state of the network to be a derived sum of shard states. With so many shards, the likelihood of two substates being mapped to the same hash (a hash collision) at 1m transactions per second (tps), has been estimated as one every 3.67^63 years. The Radix protocol assumes that 256 bits are enough to avoid "almost all" collisions in shard addresses. In the rare event of a collision, the corresponding transaction would fail and the user would simply retry, automatically resulting in different shard addresses.
An early proto-implementation of Xi’an was explored in the 2021 Cassandra research project. Active development toward Xi’an is now carried out in the hyperscale-rs project, whose public work is at hyperscale.rs.
Radix’s founder, Dan Hughes, has said that the first release of Xi’an might begin with 8-16 shard groups, which will be increased as the network throughput grows.
Consensus
Cerberus is the original sharded-consensus design for Xi’an, intended to let an effectively unlimited number of shards operate independently without losing atomic composability; its sharded form was peer-reviewed. The current Xi’an production candidate, hyperscale-rs, does not implement Cerberus as-is – its per-shard consensus is a HotStuff-2–derived two-chain commit coordinated by a leaderless beacon chain – so community members have argued that Radix’s scalability should no longer be framed around Cerberus.
Execution Layer
Xi’an was long assumed to run the Radix Engine, and the production candidate integrates the real engine today. That is changing. On 1 August 2026 the lead developer confirmed that a purpose-built virtual machine is underway, now developed as hyperscale-vm, rather than a sharding retrofit of the Radix Engine, which he assessed as "not in the ballpark" for sharded operation, adding 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."
The technical driver is that cross-shard commitment requires each transaction to declare in advance which state it touches. The hard part, in his words, 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".
Of three options framed in April 2026 – dApps unchanged, dApps adapted, or both environments supported – he confirmed on 1 August that the second is the path and the other two "have dissolved". Existing dApps will therefore need migrating, though the expected cost is modest: "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". What this means for Scrypto as a named language has not been stated. None of this affects Babylon mainnet, which continues to run the Radix Engine.
Validator Nodes in Xi’an
It remains unclear if every Xi’an wallet will be given the software to run a validator node. The consensus algorithm's operation is also uncertain when most nodes are powered down. Power drain and feasibility of running mobile validators are additional concerns.
Topology and Validator Sets
The production candidate's published design fixes several parameters that earlier community discussion left open. 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, and 128 seats at the operating point its security analysis prices. Voting is one seat, one vote: stake is an admission gate deciding who may hold a seat, never a weight on the vote itself, and a stake pool may hold at most one active validator per unit of the current minimum stake.
Shard splits are not driven by transaction demand. A shard proposes its own split when its committed substate byte total crosses a governed threshold, asserted in the block manifest and validated by every replica against its own accounting; merges work identically against a much lower threshold, the gap between them preventing oscillation. Splitting happens live, without halting the shard, and moves subtree roots rather than re-keying state.
Earlier community discussion described validator sets varying between 100 and 3,000 members with splits triggered once TPS demand saturated a set. That model predates the current candidate and is superseded by the design above.
External Links
- Radix Labs Roadmap - To Hyperscale and Beyond – the November 2024 plan, and the last dated schedule Radix published
- RFC: Xi’an, Delivering Hyperscale for Radix – the April 2026 milestone proposal on the governance forum
- hyperscale.rs – public work on the production candidate