hyperscale-rs

Introduction

hyperscale-rs is a community-built Rust implementation of the Hyperscale consensus protocol for the Radix DLT ecosystem, and the leading candidate to deliver Xi'an – the sharded consensus layer intended to make Radix linearly scalable. It is led by flightofthefox of proven.network and was opened for public review in late 2025.

A formal RFC for delivering Xi'an 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, 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 remains the consensus securing the current Babylon mainnet as a single, unsharded instance, and its sharded form was 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 (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 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 carries this into a production network candidate. After the interim Hyperscale phase closed in February 2026, hyperscale-rs emerged as the leading community-led candidate.

Architecture

hyperscale-rs is a pure consensus layer, 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. 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 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, 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” – drew the lead developer's agreement and his reason: “braiding is a terrible idea. makes shards co-dependent on each other for liveness”. 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” – 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 over a 256-bit keyspace, hashed with Blake3, in which a shard simply is a prefix subtree. Engine-internal objects such as 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, 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 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 is candid about what 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 – nine numbered documents, mirrored as named essays on hyperscale.rs, running from a system overview through the consensus layers, dynamic sharding, state and sync, atomic commitment, Byzantine safety, resource economics and determinism. It closes with an invariant register 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 carries nine models written in Quint 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 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) 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 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 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 metadata of the 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 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.

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", 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. 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 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.

Asked the hotspot question on 9 August 2026 – whether a popular token launch or NFT 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.

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 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", 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 plus the metadata of any blueprints it references. The Radix Engine, on the developer's assessment, is "too loose" 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". Asked whether a new VM made more sense than modifying it, the reply was "yeah, it's underway", 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". That is option (b), and he confirmed the mapping in as many words: "yeah option B. options A and C have dissolved". 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”.

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". 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". 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", and then doubting 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", 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".

That draws the line the earlier messages had left implicit. The surface a Scrypto developer writes against – the transaction manifest, the resource model, subintents and 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 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 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 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 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 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 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 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" — 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-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", merged on 7 August; commit 523c7dbf, "Retire the two-engine material from the system docs", had landed two days earlier. The project's own Weekly #13, 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 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 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 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 under Cerberus-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 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 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 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 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 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 — 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.

Fees, Emission and the Work Budget

Milestone 2's first week also put the economic layer on the record. 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" and "Bound adding to the drain rather than the drain itself" — 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 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, with the fee-reservation properties held in the VM repository's own INV-VM-* register.

Crate Structure

The project is a Cargo workspace of 33 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") and carried into attestation by PR #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 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 that replaced the Radix Engine in the stack. That evening the lead developer published one, in a repository built for the purpose: hyperscalers/vm-comparison, "throughput comparison between HS-VM and RE", created at 17:34 UTC with a single commit, "Initial bench.", 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 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.

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": 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" – 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". 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", 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". 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", 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".

Xi'an RFC and Funding (April–May 2026)

On 20 April 2026, flightofthefox posted an RFC for delivering Xi'an for Radix 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, 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; 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; 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'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."

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 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 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.

The project lead, flightofthefox, answered the timing question directly on 14 August. A red-team initiative is "a very good idea", 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 is the more useful target today.

That places security review after the purpose-built VM 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 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."

ML-DSA-65 is the middle parameter set of the lattice signature standard NIST published as FIPS 204 in August 2024. In 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)	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: existing holders would upgrade when they chose to, through 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, 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" — 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. 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" — 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 at 03:00, and a virtual/native ML-DSA-65 account scenario 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 — 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”. 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”, 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”. 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”.

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”, 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. 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 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".

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, the answer arrived five minutes later as a commit rather than a reply: "Add license." to hyperscale-vm at 21:17:15 UTC and the same commit 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".

The terms are broader than the RFC specified. Each repository carries both LICENSE-APACHE and LICENSE-MIT, copyright "The Hyperscale Contributors", and declares license = "MIT OR Apache-2.0" in its workspace 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) – 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 and the rendered explainer site at 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", 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 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 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
• GitHub Repository – hyperscalers/hyperscale-vm (the purpose-built execution layer)
• Hyperscale Project Overview – official documentation site
• In-Browser Network Demo (WebAssembly)
• Design Documentation – /docs (overview + invariant register)
• Formal Models – /specs (Quint + Apalache)
• RFC: Xi'an – Delivering Hyperscale for Radix (radixtalk)
• Telegram Community – hyperscale-rs for Radix
• Prefix Consensus for Censorship-Resistant BFT (paper)
• Radix Labs Roadmap – To Hyperscale and Beyond
• Hyperscale Update – 500k+ Public Test Done
• Wiki: Radix Mainnet (Xi'an)
• Wiki: Hyperscale 500K TPS Public Test
• Wiki: Radix Accountability Council