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. Unlike the shardspace itself, which is fixed at 2^256 shards, shard groups are dynamic and can adjust their shard coverage according to demand.
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 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. 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 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, though not as an implementation of the design above. Hyperscale, the open-source Rust client proposed for Radix as Xi'an, keeps the problem and replaces most of the answers: its lead developer describes it as throwing out almost all of the designs from both Cerberus and the Foundation's original Hyperscale. It has also shipped one of the mechanisms this page leaves to research. In July 2026 it added shard halt recovery: the network detects a halted shard, seats a fresh committee and restores the shard without losing or duplicating cross-shard transactions in flight. The recovery path is one of the models the project checks formally with Apalache. The next section sets out how Xi'an's committees differ from the groups described above.
Hyperscale is an open project rather than a Radix deliverable. Its author says an upgrade path to Radix exists and that he would guide the network along it, "not any more than any other network"; no migration has been scheduled.
Shard Groups in the Xi'an Candidate
The description above reflects the original Radix design. The Xi'an production candidate 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 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.
What Sharding Costs: the Latency Budget
Everything above is about how shards are served. The other half – what a transaction pays for the arrangement – had no place on this page, and it is the half a reader comparing Radix to a single-set chain needs. The figures below come from the Xi'an candidate's lead developer, flightofthefox, answering questions in the project's own Telegram group on 19 and 20 September 2026; they describe the candidate as designed, not a network in production, and nothing here has been measured against a running shard.
The round trips
Finality is counted in block inclusions rather than in seconds, because the second count depends on whatever block time the validator set running it settles on. The single-shard minimum is four inclusions: two blocks to include the transaction, then execution, then two more to include the result. Crossing shards adds three further costs on top of that floor:
- Provisioning and certifying. Both are steps of execution in the cross-shard case, and each carries its own round trips.
- The gas-paying shard goes first, for two more blocks, before any other shard may select the transaction. The reason is anti-griefing rather than accounting: a shard that is not the payer’s cannot know the fee is actually reserved unless the payer’s shard says so, and without that step the network could be filled with transactions whose payers are invalid.
- Cross-shard locks, where the transaction touches state another shard is holding – though leg-local execution removes this cost as long as the atomic core of the transaction is single-shard.
The trade this makes
The cost is deliberate and it is the price of the property atomic composability across shards demands. Asked directly what sharding gives up, the answer was finality: It’s always going to be quicker to execute transactions in blocks, rather than go through the whole async execution rigamarole which is required to support cross-shard. If you don’t actually have enough usage to need more than one shard – it would be a strict downgrade
(19 September 2026). That is a conditional, and the condition is demand: below one shard’s worth of usage the architecture is a net loss by its own designer’s account.
The positioning that follows from it was stated as plainly: the candidate targets only extremely high throughput use cases. if i were a random dApp builder, i would probably build on Solana
(20 September 2026), and the bet is on the market rather than on the benchmark – the market for transactions that can tolerate a few extra seconds is larger than the market for transactions which are so sensitive to latency as to require sub-second finality
, with the benefit of shards staying non-obvious until low-latency chains start running out of blockspace regularly. Set against the throughput figures the project publishes, this is the side of the ledger those figures do not show.