hyperscale-rs

Introduction

hyperscale-rs is a community-built Rust implementation of the Hyperscale consensus protocol: software that splits a Radix network into shards which each order their own transactions, so that throughput grows as shards are added. It is the candidate codebase for Xi'an, the sharded consensus layer intended to make Radix linearly scalable. flightofthefox of Proven Network leads it, and opened it for public review in late 2025.

A request for comments (RFC) on delivering Xi'an went to the Radix governance forum on 20 April 2026 with an 18-month mainnet target, and the Radix Foundation agreed to fund Milestone 1, dynamic topology, which was complete on 7 August 2026. The RFC's terms stand: the lead developer is paid $50,000 in $XRD for each delivered milestone, signed off by the Radix Accountability Council. He withdrew from further grants on 3 September 2026 and reversed that on 4 October, saying he would not continue without pay (see Payment Restored).

The design departs from both the original Cerberus design and the Foundation's Hyperscale reference implementation. In the lead developer's words: "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."

Cerberus secures the current Babylon mainnet as a single, unsharded instance, and its sharded form was peer-reviewed in 2023. Xi'an does not implement it; its per-shard consensus and control plane are described under Architecture and Dynamic Topology and the Beacon Chain.

Background: Hyperscale & Xi'an

The Hyperscale Alpha consensus mechanism, formerly Cassandra, was Radix's approach to linear scaling, 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 (TPS), with peaks above 700,000, across more than 590 nodes.

Those tests used very small per-shard committees, on the lead developer's assessment. hyperscale-rs targets around 100 validators per shard, and at that size the older design's inter-shard messaging would saturate a single data centre's bandwidth at a fraction of that throughput.

The Xi'an production track carries the work towards a production network. 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: its core does no I/O, takes no locks and runs no async code, so the same code runs on real infrastructure or inside a deterministic simulator that injects faults and adversarial timing.

Three Layers

What is loosely called "the consensus" is three separate mechanisms. Shard consensus orders transactions, each shard running its own chain concurrently with the rest, which is where the linear scaling comes from. Execution consensus settles what those transactions did: after a block commits, its transactions execute and the shard's committee votes on the outcome. Beacon consensus decides which validators govern which shard and when, and never sees a transaction.

Shard Consensus

Each shard committee has n = 3f+1 seats, where f is the number of faulty seats it tolerates, and runs a two-chain commit derived from HotStuff-2. A proposer builds a block, and a quorum certificate (QC) forms when 2f+1 seats vote for it. A QC alone certifies only that the block is available; the block commits when a QC forms for its child at exactly the next round. Proposers build on a block as soon as its QC forms, and execution runs after the vote, so a transaction ordered at height N finalizes at N+1 or later.

One Clock

Every QC carries a weighted timestamp: the voters' clock readings, each clamped to no earlier than the parent's, averaged across the quorum. Byzantine voters cannot drag it backwards. Every committee lookup is the query schedule.at(weighted_timestamp), keyed on the parent block's timestamp, so every replica resolves a block's committee before the block exists. Schedules freeze one epoch ahead, so shard chains running at their own speeds and the slower beacon chain agree on who governs what without synchronised clocks.

Cross-Shard Commitment Without a Coordinator

A transaction that touches several shards commits on all of them or aborts on all of them. This is often called two-phase commit, in which a coordinator collects votes and announces the result; the project's atomic-commitment document rejects the comparison. There is no coordinator whose failure could block the rest, since every shard runs the same protocol. There are no votes on the outcome: it follows deterministically from committed chain content, and certificates attest a result every honest replica has already computed. A transaction goes through three steps:

1. Declare. The transaction lists up front the global objects it reads and writes, which fixes the participating shards and lets conflicts be found without executing anything.
2. Provision. Each source shard commits the transaction, and its proposer broadcasts provisions: the state values each destination shard needs, with a merkle multiproof against the source block's QC-attested state root, so the destination trusts the source quorum and never the proposer that sent it.
3. Execute and certify. Each participating shard executes the transaction once, in a batch called a tick, over its own state merged with the provisioned state. 2f+1 matching votes on the result form an execution certificate recording each transaction's outcome. A transaction succeeds only if every participating shard records success; one abort anywhere aborts it everywhere.

A deadline keeps this live: each batch carries a timeout on the weighted timestamp, and a batch not fully provisioned when it expires aborts on every participant, so a lost provision ends the transaction instead of stalling it. Shards never vote with each other; they execute and exchange proof of their execution. That drops the braiding of Cerberus, in which the shards a transaction touches join their consensus, and the lead developer's reason is “braiding is a terrible idea. makes shards co-dependent on each other for liveness”.

One State Tree

All state sits in one versioned binary Jellyfish Merkle Tree, a hash tree over a 256-bit keyspace whose root commits to every value in it, hashed with Blake3. A shard is a prefix subtree. Engine-internal objects such as vaults are keyed under their owning account's prefix, so an account's assets stay on one shard and resharding is a tree operation. Which shard holds a key follows from the beacon's record of splits. The lead developer calls "pre-sharded" state an incoherent idea; the open question, in his account, is knowing in advance which keys a transaction will touch.

Fault Model and Committees

The security analysis prices committees of 128 seats. Voting is one seat, one vote: stake decides who may hold a seat, never how much a vote weighs. The threat model states what sharding costs: a single chain is safe below a third of corrupt stake, whereas a sharded network's safety falls smoothly as corruption in the validator pool rises, because an adversary needs only the worst-drawn committee. The goal is security competitive with an unsharded chain, "not safer than one". At 128 seats the pool must stay under about 13% corrupt seats for the analysis to guarantee safety.

Within a committee, agreement is unconditional below f+1 corrupt seats; from f+1 to 2f a fork becomes possible, but only through double-signatures that prove themselves; at 2f+1 the committee has unilateral control, and the documentation states there is no recovery.

Design Documentation

In early July 2026 the project published a design-documentation set of nine documents, mirrored on hyperscale.rs, from consensus layers to resource economics and determinism. It ends with an invariant register of 75 safety and liveness properties, which the models in the specs/ tree check (see Formal Verification).

Dynamic Topology and the Beacon Chain

The topology layer is Milestone 1 of the Xi'an RFC: the validator lifecycle and the shards' changing shape, which earlier reference implementations left untested.

The Beacon Chain

The beacon chain is a slow control-plane chain, run by all validators, that records which shards exist, which committee runs each and which part of the state space each owns, so any node can check that a cross-shard message carries a valid quorum. It carries no user transactions. Each epoch a VRF sortition (a verifiable random draw) samples a small committee, which runs Strong Prefix Consensus, a leaderless BFT protocol (Prefix Consensus for Censorship-Resistant BFT): each member proposes its view of the shard headers and a few voting rounds settle on the proposals' common prefix, so one honest member keeps the chain fair. The committee only proposes; the whole validator pool commits each block in a two-phase vote, pool ratification, so an entirely Byzantine committee cannot commit one.

Beacon state is never stored on-chain: every replica derives it by folding the committed blocks, as can a light client. Shards and the beacon talk through lifting and lowering: staking, registration, jailing and missed proposals are committed into a shard's block headers and lifted into the next beacon block, which applies any topology change and lowers the new committee assignments back.

Stake Pool and Market-Driven Parameters

Under the stake pool model an operator runs at most one active validator per unit of the minimum stake, a seat price the protocol sets, not governance, every epoch inside the beacon fold. A pool with stake S offers one seat at S, two at S/2 and so on, and the price is the offer that supplies exactly the validators the next epoch's committees need. It never rises past the tightest pool's per-validator budget, so repricing alone cannot deactivate a sitting validator, and never falls below a sybil floor, so corrupting a third of a committee always costs real stake.

Shuffling

Each shuffle interval, every shard draws one random replacement from the pool and rotates out its longest-tenured member, seated make before break: the outgoing member keeps its seat and vote until the entrant has synced. The safety analysis credits this trickle with keeping at most one syncing seat per committee and with turning slow, cheap corruption into fast, expensive corruption; it does not stop an adversary who can compromise a seated validator within hours.

Accountability Without Slashing

The protocol has no slashing. Missed proposals and beacon absence jail the seat until a cooldown passes. A double-sign, which no correct node can produce, convicts the operator's whole stake pool: every validator it runs is revoked for good, the pool can never register again, and its withdrawals are impounded for a governed span, then released whole. Pools may hold delegators' stake, which slashing would burn while barely touching an operator running mostly delegated stake.

Dynamic Sharding and Live Resharding

When a shard's committed state passes the split threshold in bytes, its proposer asserts a split in the block, and every replica checks the claim before voting. Merges use a much lower threshold, so shards do not oscillate, and governance sets both. State is a prefix subtree of one global merkle trie, so a split hands each child one of the parent root's two children and a merge joins them under one hash; nothing is re-keyed.

A split runs without halting. The beacon assigns observers to each child, which snap-sync their subtree and follow the parent's writes while it keeps producing blocks. Once both children can seat 2f+1 ready members, the beacon schedules the cut. The parent's terminal block carries the two child roots and fixes which cross-shard work it settled; in-flight work is not handed on, and a surviving shard accepts work naming the parent only if it is in that settled set.

Virtual Nodes

An operator can run several validators as virtual nodes (vnodes) in one process, and those shuffled into the same shard share execution, storage and networking. The lead developer runs eight on one 16-core machine.

Batch Sequencing on Contended State

State locks would throttle a hot spot such as a popular DEX pool to under one transaction per second. Fine-grained per-substate locking reads a manifest and the blueprint metadata of the components it calls to find the substates it touches, so transactions on different parts of one component run concurrently. For indivisible state such as a pool's price, hot-state flagging lets one shard sequence whole batches under a single lock once the beacon agrees the flag, at the cost of more load on that shard, a window for maximal extractable value within each batch, and a wait for the next epoch of about five minutes. Both were designed for a mempool that settled conflicts before execution, a premise removed in August 2026 (see Contention: locking leaves the mempool below).

Seating, Shuffling and the Single-Shard Threshold (August 2026)

On 28 August 2026 the lead developer explained in the project channel why a seat is a random draw but the exit is first-in, first-out. The exit was once random too. He changed it because an adversary with large stake, grinding a fully random scheme, could seat a malicious validator and shuffle out an honest one with the same draw. The randomness has since moved from the beacon committee to the shards themselves, which he says makes it far harder to grind, and the fixed exit stays as extra hardening.

Why one shard is the whole network

Capturing one shard compromises the whole network. No other shard holds its state, so none can check its work, and a quorum inside it decides what its state is. Because Radix is asset-oriented, $XRD lives in every shard, so a captured shard could mint $XRD, stake it and control the network. On the developer's figure, taking two-thirds of one shard on fair draws over a thousand years needs about 44% of all stake, against 66% on an unsharded proof-of-stake network, and he notes that a share of stake is only as costly as the asset's price makes it.

Halting a committee is cheaper: a third of its seats, the same threshold as an unsharded chain. The halt does not last, because the beacon re-draws a stalled committee (see the fault model under Architecture). The sharded liveness equivalent of the 44% figure has not been published.

Three positions stated the same day

Stateless validation is rejected. "stateless validation means validators can't do their job unless someone else does theirs": it moves the failure point onto whoever supplies the state witnesses.

The 1 MB transaction bound is a choice. Sizing gossip, block space and data availability for much larger edge-case transactions would, he says, solve a non-issue and make the system worse.

Bloating state should be expensive. Shuffling validators between shards means continuous state sync, so growing state would probably be one of the most expensive things a person can do.

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. On 8 August 2026 PR #142, "Schedule execution as a chain of ticks, bounded by work", moved sequencing out of the mempool and into execution.

Now admission does not arbitrate conflicts. A proposer selects from the pool in hash order up to the block budget, so two transactions touching one cell, a single piece of state, can both be selected. Execution then runs the block's work as one batch, partitioned into conflict groups against a single overlay, and each batch's output is the next one's baseline. Contenders see each other's writes instead of waiting, and a hot cell no longer costs a commit cycle per transaction. A work budget on the block header, MAX_DRAIN_WORK, bounds how much committed but unsettled work a shard may owe.

The repository records the change as a retired invariant. INV-EXEC-3, that no two transactions in flight share a declared key, could never have held: a transaction took its claim when its block committed, while proposers select over blocks that have not, so two conflicting transactions could both run against a baseline that excluded the other. INV-EXEC-4, a cross-shard conflict detector, went too; a cross-shard cycle is now broken by the payer's deadline abort, which settles neither side, where the old hash-order tiebreak settled one. Local transactions cannot deadlock, because nothing holds them apart.

Asked on 9 August 2026 whether a popular token launch or NFT mint would queue at the mempool, the lead developer said the premise no longer applied, and pointed to the interactive demo: its eight accounts collide often, and repeated submissions that used to commit one after another now commit together. That is a demo, not a benchmark.

Redundant execution across shards

On 30 August 2026 he stated a cost the documentation does not: because every shard owning declared state runs the transaction, cross-shard atomic commitment replicates the same execution more times than a monolithic system would. His answer was to split transactions into stages around an atomic core, mainly so that the core touches one shard, for "the classic pattern of many users from many shards just hitting a single swap pool".

Leg local execution (4 September 2026)

On 4 September he named the design leg local execution. Its case: twelve users on twelve shards swap against one XYZ/USDC pool. Under plain atomic commitment each taker's shard and the pool's shard exchange state and both run the whole transaction, which blocks the next, so the last taker might wait over a minute, and in practice, he wrote, a Hyperscale network would be unfit for DeFi. Leg local execution splits a transaction into three stages:

• Inbound legs: pure reservations of value, held as escrow.
• Atomic core: the part that has to succeed or fail together.
• Outbound legs: total and infallible, applied if the core succeeds.

The split works, he wrote, because manifests are now directed acyclic graphs, and hyperscale-vm's manifest document already calls their independent parts legs. In the twelve-taker case the core is the pool alone, so its shard processes every swap in one tick; certificates still flow to the other eleven shards, off the critical path, and only the core's shard runs the swap logic. A core spanning shards, such as a trade across two pools on different shards, still runs full atomic commitment and slows the traffic around it. His remedy is to price fees as multiples of the shards the core touches, which the VM's manifest can express because it fixes the payer and max_fee in the envelope.

Leg local execution merges (9 September 2026)

PR #156, "Initial leg local execution impl.", merged on 9 September 2026, opened and merged by its author that day with no review recorded, and #157, a refactor, followed that evening. He had held the branch back until it was robust, as safety-critical code and "an almost complete rewrite of how execution works".

The invariant register now holds nine leg-local invariants, INV-LL-1 to INV-LL-9: a transaction has exactly one core, committing as a single atomic unit (INV-LL-2); the only writes committed before the core's verdict are inbound escrow movements, kernel cells keyed by the transaction, and the payer's fee burn (INV-LL-3); and an outbound delivery never gates a verdict or holds a reservation (INV-LL-7). 04-atomic-commitment.md has not yet been rewritten around the stages.

Execution Layer: from the Radix Engine to a Purpose-Built VM

hyperscale-rs is a consensus layer, and for most of its first year it ran the real Radix Engine, the software that executes transactions on Radix mainnet, through an engine crate, once per transaction over merged local and provisioned state. The Foundation's reference implementation simulated execution instead. In August 2026 the project replaced the Radix Engine with a purpose-built virtual machine, hyperscale-vm, whose design has its own page. Radix mainnet is unaffected: it still runs the Radix Engine under Cerberus-derived Babylon consensus, and no migration has been scheduled.

Why the Radix Engine was replaced

On 11 April 2026 the lead developer called the choice a decision rather than a technical limit, with three options: (a) a low-friction change under which existing dApps keep working; (b) a higher-friction change that may need dApps to adapt but produces a better system; or (c) both, at the most complexity for builders and maintainers.

The argument turns on data dependencies. Cross-shard commitment needs every transaction to declare up front which objects it reads and writes, and the ideal VM resolves that declaration deterministically from the transaction manifest and the metadata of the blueprints it calls. He judged the Radix Engine's state access "too loose" for that. Previewing a transaction would then need either an ingress node holding state from every shard, which stops scaling past a point, or nodes pulling state on demand and discovering dependencies part-way through execution, which is slow and, because preview happens before submission, has no clean way to pay the nodes doing it. Knowing in advance which substate keys a contract in a Turing-complete language will touch is part of the motivation for a new VM, which makes the footprint a property of the language rather than an estimate recovered by analysis.

He confirmed the direction on 1 August 2026: the Radix Engine is nowhere near built for sharding, a new VM is underway, and the sharding changes would touch everything, so starting fresh is easier than retrofitting. Mapped to April's options: "yeah option B. options A and C have dissolved". Keeping the Radix Engine, he argued, would leave two good components forming a mediocre system, particularly for DeFi, because of waiting on state locks.

What carries over for Scrypto developers

Dropping (a) and (c) removes both paths that would have left today's blueprints running unchanged. On 2 August the lead developer put the friction at a recompile at best and an automatic source transpiler at worst. On 3 August he said that Scrypto amounts to a couple of Rust macros and parity is not hard to reach, and that the surface a Scrypto developer writes against, the transaction manifest, the resource model, subintents and badges, should stay, while state, locking and parallelism change underneath.

The VM repository's architecture overview is stricter. It lists Scrypto and EVM compatibility among its non-goals, because its effect-typed ABI, the binary interface through which a contract declares its effects, cannot be expressed under either, and it rules out a shim layer. The VM ships its own blueprint macros and its own resource, badge and principal types, so the concepts are meant to carry over and the compiled blueprints are not.

The switch lands (August 2026)

hyperscalers/hyperscale-vm was created as a public Rust repository on 30 July 2026. Between 4 and 9 August the two-engine arrangement was removed rather than deprecated: commit 523c7dbf retired the two-engine material from the system docs on 5 August, and PR #141, "Initial VM switch spike", merged on 7 August, the day the VM was wired in as a git submodule with its own documentation, so the two projects version independently. The project's Weekly #13, published on 10 August, reported the codebase running on one engine with no external Radix dependencies, and the workspace Cargo.toml bears it out: the VM's crates resolve into the vm/ submodule, and no Radix crate appears.

The blessed engine and its upgrade discipline

The VM computes routing, locking, provisioning, conflict verdicts and fee assurance before execution, from committed content, identically on every replica. One pure function, route(), reads a transaction's manifest and returns its shards and key sets without executing anything or reading state, which is the property the April discussion found missing from the Radix Engine. Two engines check each other. wasmtime is, as the lead developer put it in the project channel on 12 August 2026, the only one that runs the network; a slow reference interpreter, written independently of it, exists to confirm the expected outputs for given inputs. Under upgrades.md any divergence between them blocks a release whichever side is wrong. In hyperscale-rs the reference interpreter is the wasm32 build behind the in-browser simulation, by decision rather than as a fallback.

Both repositories pin wasmtime exactly, at =47.0.3, and treat an upgrade as a protocol event: a version bump or a backend change is consensus-visible, ships through the epoch-gated governance channel and activates at an epoch boundary, never mid-epoch. hyperscale-vm's Cargo.toml said the pin would move to wasmtime 48, the long-term-support release expected on 20 August 2026; under wasmtime's release process a long-term-support release is supported for 24 months, against two months for the rest.

What a Migration Would Involve (1 September 2026)

On 1 September 2026, with Radix mainnet a day into a halt, the lead developer set out in the channel what moving Radix to Xi'an would involve.

An upgrade is a new genesis

Xi'an is a different protocol from Babylon, so the only upgrade path is to end the old chain and import its state into a fresh genesis: dump the state at a set epoch, transform it and load it, as Olympia moved to Babylon in the 2023 migration. Addresses would change again, because sharding needs a new addressing scheme.

Contracts are harder, and the difficulty is authority rather than compilation: someone has to recompile each one, and someone has to decide what checks the new artefact passes, so that no owner slips a back door into a previously safe swap contract. He left the answer with the operators: “it is ultimately the validators who will decide what code to run and thus what (if any) irregular state transitions happen during the migration process”.

The shim, and what will not survive it

Against the VM repository's no-shim non-goal, he called both authoring layers Rust SDKs with vaults, resources and proofs whose differences would probably take minutes to adapt, and hoped to shim things so that old contracts just work, with a test in the coming weeks. The channel is the later source, and it states a hope.

Two capabilities go regardless, for reasons he calls irreducible under sharding: locking fees from a component during execution, and branching cross-component calls on mutable state. A call graph that branches on state read mid-execution cannot be routed to its shards in advance, and a fee locked by a component the transaction did not name comes from an account the manifest never declared. The transaction that emptied Radix's bridged assets the day before used the first, locking its fee from inside the published blueprint against a third party's $XRD vault.

The lead developer’s position

Asked whether Hyperscale would still integrate with Radix, he offered to help migrate state and the wallet if Radix still exists and the DAO wants it. He would not launch an L1 in 2026, and would finish the tech as an open-source project any network can use; on an upgrade against a reset he would vote in the DAO like everyone else. Asked whether the Xi'an milestone payments should stay at $50,000 in $XRD or move to fiat, he said grants were the furthest thing from his mind, a position he reversed on 4 October (see Payment Restored).

Halting a Sharded Network (September 2026)

After the August 2026 halt of Radix mainnet, Aditya Ingle asked in the project channel on 1 September 2026 whether halting Hyperscale would be “almost infeasible”, given per-shard committees and constant shuffling. The lead developer answered that a shard can halt but others keep running, apart from cross-shard transactions that need its state, and that the beacon chain replaces the whole committee of a shard stalled for hours rather than minutes, since a shard should recover from a brief partition by itself.

For an engine defect draining every shard at once, he proposed “a on-chain governed toggle which if voted to flip - then txn processing stops”, built on the existing on-chain governance, and noted that two days earlier he would have rejected the idea. projectShift asked that such a vote be decentralised and give delegators and node runners fairer shares of power. No toggle is implemented. Babylon stopped when enough node runners each shut down their own machine to take staked power below what consensus needs, which is why restarting it requires each of them to decide again; the successor design is now discussed with a governed stop as a built-in feature.

Fees, Emission and the Work Budget

A sharded network has to decide who is paid when several shards do the work of one transaction. docs/06-resource-economics.md answers it in sections added in August 2026 on where fees burn and bounding the drain.

Fees burn where they are signed

No shard is paid. A fee is a claim against the payer named in the signed envelope, on that payer's shard, and nowhere else. The signed fee ceiling is a block-validity condition: a block is invalid if it commits a transaction whose payer cannot cover its ceiling, counting every ceiling the block and its uncommitted ancestors already engage. The reservation moves nothing and resolves once at finalization, inside the settling receipt, burning the attested cost on success or a class floor on abort. No shard's revenue then depends on another shard's honesty, though a counterpart shard does real work for a fee it never receives.

The emission divides by measurement

The fixed per-epoch emission pays for that work. Each shard's blocks carry two running totals every verifier recomputes, attested work and stored bytes, and the epoch fold divides the issuance into a participation floor per ready validator plus each shard's share of the epoch's work and storage. The floor exists because weighting on work alone would pay an idle shard nothing and leave a new shard unfundable.

The work budget

Fees do not bound what a shard commits to doing. It commits work when it proposes and discharges it at settlement several blocks later; the work in between is the drain, bounded by the MAX_DRAIN_WORK figure the contention rewrite put on the block header. A transaction's work is derived at admission, never taken from the wire: a fixed admit-and-track charge, its declared footprint, and its signed execution ceiling. The fixed charge prices zero-gas envelopes, which still cost a receipt and mempool tracking, and declared gas has its own ceiling, so one envelope cannot reserve a shard's whole allowance.

The header carries the running total, so a validator checks it without reading history. A block that adds transactions to an over-budget drain is invalid, while a block with none stays valid, so the blocks carrying releasing certificates are never refused. The budget replaced a per-block transaction count that priced a publish and a transfer alike. The economic invariants are INV-ECON-1 to INV-ECON-6.

Retiring State: the Substate Sweep (August–September 2026)

The substate sweep deletes kernel state that is owed only for a bounded time, such as a subintent nullifier, the replay protection for a subintent, once no chain can still need it. The automated digest called it the network's first real garbage collection; asked what that meant, the lead developer said it reclaims storage, not memory, which Rust needs no collector for.

Why a sweep is a consensus operation

Under docs/03-state-and-sync.md, nothing retires a committed cell on a schedule, so without a sweep, time-bounded state is permanent. Removing a cell moves the state root, so every validator must reproduce each removal exactly. Three rules follow:

• The cell carries its own expiry in its value and its key, so no side index is needed.
• The block states a frontier, not a list. Sweepable cells sort by expiry bucket, so a block removes the cells between its parent's frontier and its own, capped per block, with a cursor marking where it stopped.
• Advancing is mandatory. A removal earns no fee and costs block space, so honest proposers would converge on omitting it; a block that could sweep and did not is refused.

The properties are INV-SWEEP-1 to INV-SWEEP-9 in docs/08-invariants.md: a block's removals depend only on its frontier pair and committed state; a sweep removes no cell an admissible transaction could still read; sweep work per block is bounded, so a backlog drains across blocks; and the cursor never moves back across a reshape.

The work landed on 31 August and 1 September 2026 and closed with a Quint model, specs/substate_sweep.qnt (Model K), checked with the twins described under Formal Verification. The same week, intents gained a signed header naming their network, and a transaction's validity window narrowed to the intersection of every intent it binds, closing cross-network replay. Integrating the sweep into shard execution comes next.

Crate Structure

The Cargo workspace sits beside the crates of the execution engine, hyperscale-vm, in the vm/ submodule. Every subsystem with an I/O or timing dependency is a trait with a production and a simulation backend: networking (network-iroh / network-memory; iroh replaced libp2p as the only production transport on 28 October 2026), storage (storage-rocksdb / storage-memory), task dispatch (dispatch-pooled / dispatch-sync) and signing (crypto-bls / crypto-mock).

The consensus-critical crates are shard (per-shard consensus), beacon (the control plane), execution (execution certificates), provisions, remote-headers (header sync for verifying remote shards), jmt (the state tree), effects-bridge (the binding to the VM) and engine (the batch executor over the VM kernel). Tooling makes up the rest: simulation and simulator host the deterministic harness; scenarios holds tests that run on both the simulator and a real multi-process cluster, so a scenario that passes on one and fails on the other is a real defect; and demo is the WebAssembly build behind the in-browser network demo.

Performance

Consensus simulation

A 300-node run on the deterministic simulation harness, reported on 13 April 2026, completed 23,950 of 30,000 submitted transactions within a 30-second window, at an average 798 TPS and a peak of 1,147, with median latency of 6.4 seconds, 7.8 seconds at p99, and no lock contention.

The per-shard target is roughly 1,000 TPS at 5-second finality. The lead developer calls this a deliberate trade: rather than chase sub-second finality, which atomic commit bounds, the project targets hardware a home user on consumer fibre can run, for what he estimates at a few dollars a month. 10,000 TPS per shard is configurable but would need machines beyond that profile.

Execution against the Radix Engine

On 19 August 2026 the lead developer published the first execution benchmark for the purpose-built VM that replaces the Radix Engine, in hyperscalers/vm-comparison. It times plain token transfers on one core, from received transaction to committed store, with both engines pinned by git revision, signing done outside the timed loop as a wallet would, and a distinct sender per transfer. On an Apple M-series machine, 1,000 transfers, best of three rounds:

Hyperscale is slower at validate, where it pays for admission and shard routing that Babylon has no counterpart for. The Radix Engine figure agrees with the engine's own --bench transfer benchmark. The harness lists architectural differences that cut both ways: the Radix Engine's account is native Rust and touches no wasm, while hyperscale calls its account component through wasmtime twice per transfer; a Babylon transaction must lock_fee, while the hyperscale VM has no fee concept. A Scrypto-blueprint transfer, which would compare the two wasm engines directly, has not been built.

The README's four-core figure of up to 102,000 transfers a second is what perfect scaling would give, not a prediction: the parallel executor spawns a thread per conflict group, shared-memory effects are unpriced, and one contended AMM cell serialises completely. Babylon's figure stays flat by design. Its committer executes one transaction at a time because a manifest's references grant visibility rather than declare an access set, so before execution there is no conflict set for a scheduler to group on.

Why more throughput means more shards

Asked on 20 August 2026 whether the VM should use a hardware-shaped register instruction set as Solana does, the lead developer replied that per-shard throughput "will pretty much always be bandwidth" bound, and that adding shards beats marginal compute gains "which might have to come at the cost of expressiveness". At 39 µs a transfer, execution sits far inside the 1,000 TPS per-shard target, so the benchmark is a margin rather than a goal, and throughput grows with shard count.

Transaction Flow

A transaction passes through three phases. Before consensus, a user signs it and submits it through an RPC gateway; the node works out which components, resources, packages and accounts it touches and places it in the mempool of each shard involved, gossiping cross-shard transactions to all of them over iroh, which opens direct QUIC connections between validators and falls back to a relay where a direct path fails.

In consensus, each round's proposer, chosen deterministically, builds a block from its mempool, and the committee votes until the block commits under the two-chain rule described under Architecture.

In execution, each shard runs its committed transactions and settles cross-shard ones by the declare, provision, execute and certify steps described there. A transaction is final when the execution certificates of every participating shard record success for it.

Running a Node

The lead developer expects a node serving Radix-level load to use under 10% of one CPU core and about 200 MB of RAM, so a Raspberry Pi 5 with an NVMe SSD could run one, possibly several, with storage bounded by shard splits. He gave the figures on 4 August 2026 for the current consensus-layer code, without saying at what load a Pi would stop coping, and expects them to change with the new VM.

Downtime and misbehaviour

A home validator needs no second node as a backup; failover at the network layer is enough for an operator who wants one, and a node that drops is jailed and unjails itself when its connection returns. Only provable Byzantine faults, such as double voting or sending different proposals for one round, are punished, and by impounding rather than slashing: the operator's stake locks for 90 days by default, a span governance can change, so a node runner cannot repeat an attack quickly and delegators lose nothing permanently. Being offline or slow is never impounded.

Delegation and sybil resistance

$XRD holders would delegate much as under Babylon, but to a stake pool that may run several nodes rather than to one validator. Cheap hardware does not open a sybil attack, because every node still needs stake, and a surplus of nodes keeps pushing the seat price up until skimping on hardware makes no sense for stake of that size. Phones are ruled out on operational grounds: mobile operating systems sleep apps aggressively.

What capacity costs

More throughput is priced in validators rather than hardware: another shard needs another 128 nodes online, partly amortized by vnodes, plus a free pool to draw shuffle replacements from. The protocol encodes both. A split is gated on the free pool being deep enough to staff it, and the epoch fold prices activation against committees times committee size, plus a standing reserve. A channel member's figure of 12,800 nodes for 100 shards is an extrapolation, not a project figure.

A demand spike is met by topology: shards split to free execution capacity while enough free nodes exist, and how well that absorbs a spike depends on how fast a shard splits, a latency the project has not published. A GUI validator client is still to be built, with the aim that complete amateurs can run a node. The developer puts a home node's power draw below a rounding error on an electric bill and calls Babylon, whose validators mostly sign empty blocks, "crazy inefficient", but declined to quantify any of it before testnets, since the software is pre-alpha. None of these figures is a measurement.

Disk Use and History (October 2026)

On 9 October 2026 the lead developer published ballpark disk-use figures for a validator at production settings. A node keeps its shard's current state and about three hours of history, and prunes the rest, which is safe because shard blocks are checkpointed into the beacon chain.

A busy shard would hold steady at 60–100 GB. State grows with accounts until a shard splits; storage bonding, a charge for ongoing use of state, is still to be built. The beacon chain keeps everything, at 15–130 MB a day, the one unbounded item. Validators need only current state, so full history would sit with gateway operators in archive nodes he expects 2–3 entities to run, a design not yet started. All of this is design, not shipped behaviour.

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

On 20 April 2026 the lead developer, flightofthefox, posted an RFC for delivering Xi'an for Radix to the Radix governance forum. The request for comments names hyperscale-rs as the production candidate for the Xi'an mainnet release, pays for it in six delivery milestones, and commits to relicensing the code under Apache 2.0 on acceptance; the licence added on 7 August 2026 went further (see Licensing under Development & Community).

Milestones

• M1 – validator lifecycle and consensus engine: dynamic topology, node shuffling, validators joining and leaving, the staking model. Reported complete on 7 August 2026, except splitting shards on fees as well as storage size, which waits on the fee system and so on the VM.
• M2 – breaking API changes that align the engine with the Gateway, the API layer apps read the ledger through, for sharded operation
• M3 – a Gateway rewrite for sharded data
• M4 – an alpha cross-platform desktop validator for home validators on consumer hardware
• M5 – post-quantum cryptography
• M6 – mainnet launch and the support window

Solo-Developer Risk

The proposal acknowledges that the project is a solo effort, and offers three answers to the risk of depending on one person: a larger proposal employing a second developer, key-man insurance bought by the DAO, or accepting the risk because payment is per milestone.

Milestone 1 Funding

In May 2026 Milestone 1 funding went through Consultation V2, the community's voting process: a temperature check passed within two days and became a binding proposal needing a quorum of about 940m $XRD. The holdings of the Radix Foundation and RDXH sit in custodial vaults that cannot vote, so quorum depended on community turnout. The Foundation said it would pay Milestone 1 directly if consensus was clear, rather than wait at least two months for the community DAO, MIDAO, to be constituted. Work began in mid-May. Until April the project had run on donations through FoxFund, which the lead developer then asked supporters to redirect into voting for the RFC.

Funding Withdrawn (3 September 2026)

On 3 September 2026, three days into the network halt, the lead developer wrote in the project channel that he had “decided not to pursue any proposal, grants or ongoing engagements with radix as a network, dao, or otherwise”. He said the project would continue at an unchanged pace, and gave the relationship rather than the amount as the reason: he wanted nothing to do with people who thought a small grant had bought him.

The RFC topic was neither closed nor archived, so the proposal stands on the forum unaltered. Its funding and governance terms lapsed until 4 October: the five unpaid milestones, the Council sign-off, the arbitrator and the no-exit-fee stop. The licence is irrevocable, and the code and roadmap are unchanged.

What the Withdrawal Covers

Questioned later that morning by a channel admin who called the position ambiguous, he narrowed it to future grants, not the work: he does not wish to pursue additional grants from Radix, would keep working unpaid, and would rather take compensation off the table than argue over it. The Foundation payment, he said, bound neither side to continue, and its only deliverable was open-sourcing the work to date, which the 7 August licence discharged.

He would not name Radix as the destination. He called Hyperscale an open source project whose adoption in any format is all he cares about, and refused to launch a chain and token of his own. That afternoon he committed to the work more broadly than the RFC does: he would work through the VM, the gateway, the desktop validator, every other milestone, and further ideas such as privacy.

What Becomes of Radix (11 September 2026)

On 11 September, the day mainnet committed its first round in ten days, a member asked what happens to holders and their tokens. He answered that he wants to build good primitives, whoever uses them, and on the holders' fate: “i don't know mate. it is not really something that i have any control over”.

An Upgrade Path for Radix (12 September 2026)

Hours later a holder asked whether Radix could add Hyperscale through a network upgrade or whether it is a standalone network. He answered: “of course, not any more than any other network, but yes. 100% there is an upgrade path, and i would sherpa that path”.

Further Payments Declined (12 September 2026)

On 3 September he had said a Milestone 1 payment from RDX Works was about a week away, and withdrew ahead of it. On 12 September he was asked in the channel why the Radix Foundation had paid him and whether he had returned the payment. He replied that the Foundation paid for services rendered, and that he returned no payment but chose not to receive any further; no payment record has been published. That evening a validator operator, Validador GENKIPOOL, argued that the proposal had promised Xi’an itself, and the lead developer answered that he would keep working on Hyperscale and do his best to help Radix adopt it as a Xi’an upgrade.

He gave a second reason for refusing grants: if Xi'an then did nothing for holders, people would ask who profited, and an answer naming him would bring anger. He doubted that Radix reaches one transaction per second, which makes it the network furthest from needing Hyperscale. He gave no dates: the milestones keep their order, though the VM work is much larger than the RFC assumed; he expects feature-complete faster than people think possible, but would not say when he would recommend that any network adopt it, because recent hacks reinforce the need to be bullet-proof.

Payment Restored (4 October 2026)

On 4 October 2026 a member asked whether he could still be paid if he completed the milestones and integrated Hyperscale with Radix. He answered that if Radix wants to give a grant because it helps achieve its goals, “this is a good alignment of incentives”, and that Radix is the only network he knows of that means to upstream the technology. In the same exchange he withdrew all offers of unpaid help, said he would not continue without money, and asked to be paid for the Radix integration, which he called “a modest technical problem which is easily handled”.

The RFC's terms are the standing deal: $50,000 in $XRD per milestone at the 30-day TWAP, sign-off by the Radix Accountability Council, and arbitration for disputes. Milestone 2 is the next payment, and it falls to the DAO treasury, which the Radix Foundation is handing over.

Formal Verification (July–August 2026)

Deterministic simulation testing cannot speak for paths it never walked, so since 3 July 2026 the project has also kept machine-checked models of its protocols. The repository's specs/ directory holds ten models written in Quint, a specification language in the TLA+ family, and checked with Apalache, a symbolic model checker that searches every behaviour the rules permit up to a fixed number of steps. Each model checks properties named in the invariant register.

All ten pass, per specs/README.md, read 24 August 2026:

A statistical companion, SEC-1, uses concentration bounds and Markov analysis to price the premise every model assumes: that fewer than one third of any committee is Byzantine.

What the models have found

Modelling the beacon against Prefix Consensus for Censorship Resistant BFT (Xiang, Tonkikh and Spiegelman, February 2026), the algorithm it implements, showed the implementation resolving a value's parent differently from the paper in one corner case. The deterministic simulator replayed the model's counterexample as a failing test, and the fix landed with a permanent regression scenario.

Model G's finding G-1, in which a committee past the one-third bound skews the weighted timestamp until a replica admits an orphan commit past a halted shard's tip, led to a beacon-mandated freeze, now modelled and implemented, that revokes a halted committee's cross-shard authority at detection. The project records the band between f+1 and 2f corrupt members as "a bounded-exposure regime, not a clean recovery".

Limits

The project states them in the explainer hyperscale.rs/proof, posted to the project channel on 24 August 2026. The register is a to-do list worked through in the open, not a completed proof. A model is not the code, so every counterexample is replayed against the consensus core, which is written as pure transition functions. Checking covers small committees and short horizons, ten steps by default; specs/README.md says bounded checking is not proof and names inductive invariants as the next step. None of this is an external review.

Security Review and Audit (August 2026)

hyperscale-rs has not been audited, and no audit has been commissioned or funded. On 13 August 2026 a community post in the project channel cited the Bitcoin Red Team's use of frontier language models to scan open-source code and asked how and when the DAO should help; a reply hoped the project could afford an audit before the Xi'an mainnet release.

The lead developer welcomed a red-team effort on 14 August but not yet: execution and VM code is still in progress, so scanning it now "will just generate a lot of noise over incomplete code, or areas i already know need attention". He put the moment at the first release candidate or testnet, and pointed anyone wanting to start sooner at the currently deployed network. It is a stated position, not a published policy.

Post-Quantum Signatures (August 2026)

The Xi'an RFC schedules post-quantum cryptography for Milestone 5, but the first post-quantum scheme landed on 16 August 2026, when the execution layer registered ML-DSA-65 in its signature scheme registry. ML-DSA-65 is a parameter set of FIPS 204, NIST's lattice signature standard of August 2024. In crates/types/src/scheme.rs it takes scheme id 3, after Ed25519 (1) and secp256k1 (2). The registry records sizes and verification cost, in Ed25519 verifications:

The registry does not say which schemes a network accepts, a protocol-version question, and leaves verification to an embedder through the SchemeVerifier trait. The same day the consensus repository added transaction signing and verification under ML-DSA-65, with scenarios for securifying an account onto it and for virtual and native ML-DSA-65 accounts.

Asked whether this meant an Olympia-style migration, the lead developer said it adds a third signing scheme to Babylon's two. Holders would move by choice through account securification, which rewrites an account's authorisation rules without changing its address.

He called post-quantum work "a cross cutting concern, it'll just be done as appropriate", outside the milestones, with transaction signing the easy part. Post-quantum consensus signing, which involves zero-knowledge constructions and WOTS+ and XMSS, has not been attempted, and no network has been versioned to accept scheme 3.

Light Clients and State Proofs (August 2026)

Reading the ledger today means trusting a node or a Gateway API. On 20 August 2026 a developer asked in the project channel whether a web application could verify state and finality itself as a light client, checking compact proofs locally in WebAssembly. The lead developer answered that he intends to build light-client infrastructure and that its building blocks exist, because cross-shard execution is already a light-client flow: one shard group accepts a claim about another's state on evidence rather than trust.

The open problem is who serves the proofs. Validators would need a fee to serve them on demand, the active validator set should be validating and executing instead, and light clients consume proofs rather than serve them. A few archive nodes serving proofs, much like a Gateway, would still be "a step up from needing to trust a gateway completely", since the answer can be checked. Proofs would not replace a Gateway: they are much larger than the data they attest and show only that a given value sits at a given substate key, where a Gateway aggregates state to answer complex queries.

Development & Community

hyperscale-rs is developed in the open. Its Telegram channel grew from 319 members at the February 2026 unveiling to 451 by June, carries automatic GitHub commit notifications, and is where the lead developer answers the design questions several sections of this page cite.

Licensing

Both repositories were public but unlicensed from their creation, so under default copyright the code could be read but not used, modified or redistributed. On 7 August 2026, minutes after a question in the channel, the lead developer committed "Add license." to hyperscale-vm and the same commit to hyperscale-rs. Each now carries LICENSE-APACHE and LICENSE-MIT, and its Cargo.toml declares license = "MIT OR Apache-2.0", the Rust convention that lets a user take either. Anyone may now fork or maintain the code, which answers the RFC's key-man risk by licence rather than by contract.

Contributors

• flightofthefox (Proven Network) – lead developer, about 2,500 commits, sole driver of the architecture
• kaldeberger – secondary contributor, about 70 commits
• shambupujar, dazligth, cyril88888, pprogrammingg – community contributors
• wizzl0r – channel owner, pull-request reviews and testing infrastructure
• Radical – code reviewer, author of the community transaction-flow documentation

Milestone 1 Timeline

• March–May 2026 – consensus core hardened; on 13 April the lead developer called its foundations solid.
• May–June 2026 – beacon chain, stake pools, snap-sync joining, trickle shuffling, and first cuts of live shard splitting and merging.
• 2 July 2026 – design documentation and the explainer site hyperscale.rs published.
• Mid-July 2026 – consensus "pretty much finished"; outside developers invited onto the execution layer, gateway and desktop validator.
• 13–26 July 2026 – shard halt recovery, the resharding cut-over, and fork fencing, which permanently revokes a proven double-signer's key.
• 27 July 2026 – a live demo runs the node's simulator, compiled to WebAssembly, as a multi-shard network in a browser tab.

Roadmap and Public Testing

Rather than the Foundation's one-off set-piece tests, the project intends long-lived public testnets that nodes register into and out of at will, which the beacon chain makes possible. Importing Babylon state would re-index it from an Aptos-style Jellyfish Merkle Tree into a pure binary one suited to multiproofs, with a new hashing algorithm.

On 8 November 2026 the lead developer said the milestone view of the project is out of date, and that three streams of work are running, none of them public yet: a formal specification of the whole system, verified in Lean 4, a language for machine-checked proofs; a redesign of consensus that replaces the separate shard consensus (HotStuff-2) and beacon consensus (prefix consensus) with one model, prefix consensus running on top of a DAG (directed acyclic graph); and the first version of the desktop validator client, in preparation for the first testnets.

Where can I read the Hyperscale Weekly digest?

Hyperscale Weekly, a week-by-week digest of hyperscale-rs development, is published at telegram-mcp-phi.vercel.app. hyperscaleDigestBot announces each issue in the project's Telegram channel. An issue covers one Monday-to-Sunday week: commits and lines changed, headline changes linked to the hyperscale.rs explainer for the part of the design they touch, and smaller items. Issues come in nine languages and as a PDF.

Week #1 covers 11 to 17 May 2026, and a prologue, Week #0, covers the 1,350 or so commits made from 7 December 2025 to 10 May 2026. The newest issue is Week #26, for 2 to 8 November, which leads on the new VM letting a contract read only the cross-shard state that was proven and served to it.

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)
• Hyperscale Weekly – the weekly development digest
• 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