Xi’an [ /ʃi’æn/ ] will be the next major release of the Radix network. Xi’an will allow an unlimited number of shard groups, enabling Radix’s sharded state model to be fully utilized.
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 (public work at hyperscale.rs), whose RFC for delivering Xi’an was submitted to the Radix governance forum on 20 April 2026 with an 18-month mainnet target.
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 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.