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.

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

Milestone 1 shipped node shuffling, and on 28 August 2026 a long exchange in the project's channel put the mechanism itself on the record. Getting into a shard is a lottery; getting out is first-in, first-out. "it's a lottery. once you're seated in a shard then it's a queue" – validators seated ahead of a new arrival are shuffled out ahead of it – and the two halves are deliberately different: "getting seated is random. getting shuffled out is fifo".

The exit used to be random too. It was changed to blunt randomness grinding by a large-stake adversary, which under a fully random scheme gets two bites at every draw: "if both seating and shuffling is random - the most successful grind will seat a malicious, and shuffle an honest". Making the exit predetermined removes the second. The seed has since moved as well – randomness was drawn from the beacon committee when that change was made, and is now supplied by the shards themselves, "which makes it orders of magnitude harder to grind" – but the FIFO exit is kept regardless, "because it's a good hardening anyway".

Why one shard is the whole network

Seating carries that much design weight because capturing a single shard is terminal rather than partial. No other shard can check its work: they do not hold its state, and "if they did - it would not be a sharded system". With a quorum inside one shard, "state is whatever you say it is", with lesser interference available on a gradient from f+1 upward. Because Radix is asset-oriented, XRD lives in every shard rather than in one contract, so the consequence is not confined to that shard's users: "you could mint a trillion XRD, stake it, and now you control the network".

The threshold is not monolithic security divided by shard count. On the developer's figure, taking two-thirds of a single shard on fair draws over a thousand-year horizon needs roughly 44% of all stake, against the 66% an unsharded proof-of-stake network requires – "which is still a very high bar", and materially more than the arithmetic a reader might expect. The caveat attached to it is economic rather than cryptographic: percentages resolve to money, and "the actual price of the asset has to do the heavy lifting at some point".

The liveness threshold, and the answer that is still unpublished

The 44% figure prices capture. Asked in the same exchange what it costs to attack liveness instead, the developer separated the two: “same same. you can impact liveness with 1/3”. The liveness threshold is the monolithic one, a third of a committee, and it is far below the share that capture needs; what differs is the consequence. Halting a committee is not a durable position, because the beacon takes the seats away: sustained liveness failure, in the developer’s words, is where “the beacon says fuck your committee - firing squad”. That is the channel’s statement of the mechanism the threat model documents in the f+1 to 2f band, where withholding halts a shard and the beacon undoes it with a full re-draw of every seat.

The question that prompted it asked specifically for the sharded liveness threshold, and for a time horizon at 20% Byzantine stake. Neither number was given. The sharded equivalent of the 44% capture figure, for liveness rather than safety, has not been published, and this page does not have one to record.

What shuffling costs, and what asset orientation saves

Sharding bounds the state any one node must hold, because a shard can always be split again – but the developer is explicit that this is a purchase rather than a saving: "it doesn't make it free - as you have more validators to pay". State growth is also not the same thing as usage. Balances are integers whose size does not change when they move, so a transfer costs no state at all, and an AMM holding two integers stays two integers under a million transactions; an account's state grows with the number of distinct assets it holds and shrinks when one hits zero, "as then we can forget the balance".

The asset-oriented model helps rather than hinders contention here, for the same reason. A balance lives in the holder's own account or in a component's vault instead of under one ERC-20-style ledger contract, so the balances are scattered across the state space and two accounts changing at once do not contend. The VM takes it further with locking semantics named delta, credit and reserve, so that commutative operations stay independent: "if 5 people all pay Bob at once - those also don't contend".

Three positions stated the same day

Stateless validation is rejected, not deferred. Asked directly whether Hyperscale would adopt it, the answer was no, and the objection is structural: "stateless validation means validators can't do their job unless someone else does theirs" – the failure point moves onto whoever supplies the state witnesses, which the developer places in the same category as ZK "verify, don't execute" designs moving it onto the proving clusters.

The megabyte-scale transaction bound is a choice. Sizing "gossip, serde, block space, data availability, etc to big ass edge-case transactions" is described as solving a non-issue at the cost of making the system objectively worse; transactions of about 1 MB remain available, and the ceiling is not treated as something to lift.

State bloat is expected to be the expensive act. Fee tables are unwritten, but the direction follows from shuffling: a security model that rotates validators between shards implies continuous state sync, so "bloating the size of state will probably comparatively be one of the most expensive things a person can do". That is the pricing counterpart to the fee design above, where every fee burns and none is paid to anyone.

The statements in this section are Telegram messages in the project's public channel, each attributed to the lead developer by the message's own embed markup.

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.

Multi-stage routes, and the redundancy the design still carries (August 2026)

The rework above attacks contention inside a shard. On 30 August 2026, in a channel argument about whether Hyperscale's lighter nodes amount to an energy story, the lead developer stated the cost that sits on the other axis, and it is a concession the project's own documentation does not make: "cross-shard atomic commitment via only partial execution sharding means you're actually replicating the same execution more times than you would in a monolithic system".

That follows from the pipeline described under Architecture. Because every shard owning declared state runs the transaction, a transaction spanning several shards is executed once per shard, where a single-ledger chain executes it once. Sharding buys parallelism between transactions and pays for it in duplicated work within one, and the bill grows with how many shards a transaction reaches.

The same message describes the mitigation, in the first person and as work in progress: "i'm working through breaking transactions into multi-stage routes with a pattern of escrow->atomic core->total settlement stages". The stated motive is not the duplicated compute. It is contention: "not particularly for the purpose only reducing redundant compute... but mostly because if the common pattern is that the atomic core can touch only one shard - that's much better for contended throughput", and the case he names for it is the obvious one, "the classic pattern of many users from many shards just hitting a single swap pool". The shape of the answer is to shrink the atomically committed part of a cross-shard transaction down to a single shard and push the rest into stages either side of it, so that the swap pool's shard is the only one that has to agree with anybody.

It is a design in conversation, not a specification. As of 31 August 2026 neither repository carries it. The ten architecture documents in hyperscale-rs/docs describe cross-shard commitment only as the single provision, execute, certify pipeline, and contain no occurrence of "escrow" or of a multi-stage route; the sole "escrow" anywhere in hyperscale-vm/docs is an unrelated reference to call and escrow boundary values in the canonical ABI. This page records the design at the weight it currently has, which is a statement by the person writing the code.

“Leg local execution”: the route acquires a name (4 September 2026)

Five days later the sketch above was named and specified, still in the channel and still ahead of either repository. At 12:44 UTC on 4 September 2026, with mainnet in its ninetieth hour of halt, the lead developer described what he is “for lack of a better name… calling ‘leg local execution’”, and placed it at “where the rubber meets the road in terms of getting the state contention payoffs of a redesigned VM”. The message is authorship-verified through its public embed.

The failure mode, stated concretely. Twelve users on twelve different shards want to swap against one XYZ/USDC pool. Under the naive atomic commitment described under Architecture above, the taker’s shard and the pool’s shard trade state and both run the whole transaction, which blocks the next one and so on down the queue, so “the taker who was unluckiest in the ordering might be waiting over a minute for his swap”. His conclusion about that outcome is the sharpest statement of the stakes the project has published: in practice “any hyperscale network would end up being dogshit for defi”.

Three stages. A transaction is decomposed into inbound legs, which “must be pure reservations of value and treated as escrow” to the stage below; an atomic core, “the part of the transaction that truly needs to either succeed or fail together”; and outbound legs, which “must be total and infallible, and can just be treated as an ‘if core succeeds, then these things will happen’”. The enabling condition is named, and unlike the staging itself it is checkable in writing: the decomposition is possible “now manifests are DAGs”.

What it buys. In the twelve-taker case the atomic core is single-sharded — just the swap venue — so that shard “can rip through all the transactions in one execution tick” without blocking coordination with the other eleven. The certificate exchange with those shards still happens; it stops being on the critical path. The second gain is compute, and it answers the concession recorded immediately above: under naive atomic commitment all twelve shards execute the AMM swap logic for their own transaction, whereas here “compute is only replicated across the atomic core shards (which probably in the vast majority will just be 1 shard)”.

What it costs, and how that cost is met. A transaction whose atomic core genuinely spans shards — one touching two pools in different shards — still runs on atomic commitment and is “relatively slower and also slow everyone else doing the more typical fan-in”. The mitigation he names is pricing rather than mechanism: “not really any way to solve that except to price fees for transactions as multiples of however many shards the atomic core touches”, which “also makes sense given the compute is replicated”. That is a fee schedule the successor engine is positioned to express and the current one is not — the VM’s manifest format puts the payer and max_fee in the envelope and carries “no fee instruction of any kind”, so what a transaction costs is settled against its declared shape rather than by whatever a component chooses to lock mid-execution.

Still in conversation, but half of it is now written down. Read on 4 September 2026, none of the ten architecture documents in hyperscale-rs/docs contains “leg local”, “inbound leg”, “outbound leg” or “escrow”; cross-shard commitment is still documented only as the single provision, execute, certify pipeline. The premise it rests on has moved the other way. hyperscale-vm’s manifest document is titled “Manifests and intents: the typed dataflow DAG” and states the property the staging needs: “Sequencing is dataflow-only. Execution order is the DAG’s topological order; independent legs are visibly independent. Acyclicity is subsumed by the format: a manifest is acyclic or it does not parse.” The word this design turns on is already the repository’s word for the independent parts of a transaction; what is not yet written anywhere is the machinery that executes them in three stages.

Leg local execution merges (9 September 2026)

The machinery arrived five days after it was named, in one merge rather than day by day. Pull request #156, “Initial leg local execution impl.”, opened from the branch new-local-leg at 03:37 UTC on 9 September 2026 and merged into main at 15:15 UTC the same day by its author, carries 300 commits across 313 files, +42,964 and −14,112 lines, with no review and no comment recorded on it. A second pull request, #157, “LLE streamline + refactor.”, merged at 19:03 UTC the same evening: 17 commits over 45 files, +2,514 and −3,698.

The lead developer had explained the delay in the channel while the branch was open, twice. At 23:26 UTC on 7 September he wrote that “kitwatcher only tracks main branch. work is happening on a feature branch for leg local execution. it’s on github but won’t be merged until i think it’s robust, safety critical”, and at 16:37 UTC on 8 September that leg local execution “is an almost complete rewrite of how execution works” and that he is “not merging them before they’re done in order to appease any silly conception anyone might have around a kitwatcher score”. Kitwatcher is a community tracker that scores Radix repositories on commits to the default branch, so a branch held back reads there as an idle project. Both messages are authorship-verified through their public embeds.

The design is now written down, where this section recorded on 4 September that it was not. hyperscale-rs/docs/08-invariants.md carries a section headed “Leg-local execution” holding nine invariants, INV-LL-1 to INV-LL-9, that state the terms the three-stage division holds to: a transaction has exactly one core and it commits as a single atomic unit across its core set (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 and never holds a reservation (INV-LL-7). Each names the file and function that enforces it. The pipeline document the section points at, 04-atomic-commitment.md, still describes cross-shard commitment as provision, execute, certify, and has not been rewritten around the stages.

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.

What a Migration Would Involve (1 September 2026)

On 1 September 2026, with Radix mainnet twenty-two hours into a halt and the channel arguing over whether the network should be upgraded or restarted as something else, the lead developer answered the migration question in more detail than at any point before. The account below is his, message by message, and each is authorship-verified through the Telegram embed.

An upgrade is a new genesis

Asked what “new” would even mean, he set out that a Xi'an upgrade is not an in-place upgrade of the running chain: “it's a completely different protocol to Babylon so the only way to upgrade is to terminate the old chain and import to a fresh genesis”. Mechanically that means dumping “the state at a predetermined epoch, transform it and load it in at the xi'an genesis—same process that Olympia -> Babylon was” — the 2023 migration that already put every Radix holder through one address change. This one would do it again: “more address changes… because a new addressing scheme was required for sharding”. The sharded design fixes the address format, so the change is a consequence of the topology rather than a choice.

Contracts are the harder half, and the difficulty he names is not compilation but authority. “Contracts are much more of a PITA… because someone has to recompile and then you have to think about what are the checks and balances on the new artifact.” The open question he poses is who is allowed to publish the recompiled blueprint: whether “the blueprint owner [should] be able to unilaterally update their WASM… or does it also need some kind of consensus from validators who've checked against known source to make sure they haven't, for example, put a back door into their [previously safe] swap contracts which allow them to drain”. A migration that requires every package to be rebuilt is also a migration in which every package could be rebuilt into something else, and nothing in a state dump distinguishes the two. Who decides, in the end, he places 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

On the developer surface he was more optimistic than the repository has been in writing. The two authoring layers are “both just rust sdks, with vaults, resources, proofs, etc.”, and differences that cannot be absorbed “are probably the sorts of things that only require a few minutes to adapt”. Earlier in the afternoon he had gone further: “almost every single design decision had to get revisited in hs-vm… hoping that it will be possible to shim things such that old contracts just work… the blueprint macros are pretty similar-ish. Hopefully be in a good spot to test that in the coming weeks.” That is worth setting against the VM repository's own architecture overview, which lists among its explicit non-goals “Scrypto or EVM compatibility — the effect-typed ABI is not expressible under either; no shim layer”. The written document and the channel now say different things about whether a shim exists; the channel is the later of the two, and it is a hope with a test date rather than a commitment.

Two capabilities he names as going regardless, and the reasons are structural: locking fees from a component during execution, and branching cross-component calls on mutable state — “there's generally irreducible reasons for each of those related to sharding”. Both are consequences of the declared-footprint rule described above: 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 is a payment from an account the manifest never declared. The first of those has a very recent illustration. The transaction that emptied Radix's bridged assets the previous afternoon carried no LOCK_FEE instruction at all; its fee was locked from inside the published blueprint, against a third party's XRD vault. The capability the attacker used to pay for the attack is one the successor engine does not offer — not as a response to the incident, but because a sharded router cannot price a call it cannot see coming.

On the other side of the ledger he listed additions rather than removals: “a more well-rounded cryptography stdlib including ZK verification”, and interest in “borrowing the ZK tunnels concept from SUI”. Neither has appeared in the repository yet.

Where the developer places himself

The same afternoon fixed the project's relationship to Radix more explicitly than the code alone had. Asked whether Hyperscale would still be integrated with Radix, the answer began “Integrate with what? Hyperscale doesn't use any Radix components anymore… as Radix Engine turned out to be way too far from what was required” — the channel's confirmation of what the August dependency cut-over had already made true in the manifest — and ended with an offer that is conditional in its first clause: “if Radix still exists, and the DAO wants help migrating all the state, balances, etc. and integrating/updating the wallet and such. Yeah, I'm sure I would still help out with that.”

He declined the leadership the channel kept offering him. On the suggestion of launching a new chain: “I don't think I'm mad enough to launch an L1 in 2026. Just going to finish the tech as the open source project that it is. And then probably collapse because I've been running on fumes for months. Any network can use Hyperscale, or not use it.” On being asked to decide between an upgrade and a reset: “I will vote in the DAO like everyone else. People should not particularly listen to my opinions on things outside my narrow expertise.” And asked at 18:32 whether he would still want the Xi'an milestone payments denominated at $50,000 in XRD or would rather be paid in fiat now, he answered only “Grants are the furthest thing from my mind presently” — leaving the denomination of the programme's funding open on the day the token it is denominated in could not be transferred.

Halting a Sharded Network (September 2026)

The August 2026 halt of Radix mainnet put a question to this design that had not been asked of it before: whether a network of independently seated shard committees, with membership constantly shuffling, could be stopped at all. It was raised in the project channel on 1 September 2026 by Aditya Ingle, who asked whether a halt in hyperscale would be “almost infeasible” given per-shard committees and constant shuffling. The exchange that followed is the first design change the incident has produced in the successor network, and each message below is authorship-verified through the Telegram embed.

A shard can halt, and the beacon chain treats it as a fault

The lead developer's answer was that halting is possible but not global: “you can halt of course but one shard halting doesn't impact others so the liveness impact is localised”, with the caveat that cross-shard transactions needing state in that shard are affected. A stalled shard is not left stalled: prolonged outages are noted by the beacon chain, which rotates the whole committee to restore liveness. He put a figure on “prolonged” at hours rather than minutes, because a shard is expected to recover on its own from a temporary network partition, and a full committee rotation resyncs an entire validator set at once instead of dripping one shuffled member in at a time. The mechanism that makes a stuck shard self-healing is, on this reading, also the mechanism that makes a deliberate network-wide stop hard to reach.

An on-chain governed toggle, proposed two days after being called absurd

Pressed on the case that actually arose, an engine-level defect draining funds in every shard at once, he proposed the fix himself: “there's probably a more elegant way to go about it than yanking the power cords out of the wall… maybe like having a on-chain governed toggle which if voted to flip - then txn processing stops”, adding that it “would be simple enough to implement given the on-chain governance machinery is there already”. He then marked the reversal himself: “two days ago i would have said ‘why the hell would anyone want that?!’”. projectShift answered that “it's now obvious that a well implemented decentralized network with a serious bug can become impossible to halt”, asked for governance options that are themselves decentralised in who opts in and out, and asked that the asymmetry between delegators and node runners be reduced so both sides have a fair chance of equal power over such a decision.

Nothing here is implemented. It is a channel exchange, not an RFC, and the crate tree carries no such toggle at the time of writing. What it records is the direction of travel: Babylon was halted by enough of its node runners each independently stopping their own machine to take staked power below the threshold consensus needs, which is why restarting it requires each of them to decide again, and the successor design is now being discussed with a governed stop as a first-class feature rather than an emergency improvised out of the operators' own hands.

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.

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

Milestone 2's fifth week produced the change the project's own weekly digest led with, and a correction to how the digest described it. On 7 September 2026 the automated digest bot posted Week #17 (31 August – 6 September, 19 commits) to the project channel under the line that "the substate sweep gives the network its first real garbage collection". Asked a few hours later in the same channel whether that meant null state or memory, the lead developer answered plainly: "Cleaning up storage, not memory. IE reclaiming space from guards which don't need to exist once validity windows for the artifacts expire anyway, like subintent nullifiers. No memory GC needed with Rust." The distinction matters for anyone reading the phrase against a runtime they know: nothing here pauses, traces or collects at run time.

Why a sweep is a consensus operation

The design was written down as it landed. docs/03-state-and-sync.md gained a section titled "Retiring state" whose premise is that a committed cell "can be written and overwritten; nothing retires one on a schedule", while some kernel state is owed only for a bounded time — a subintent nullifier "stops being replay protection once no chain can still be deciding a spend of the subintent" — and without a sweep that state is permanent. What follows from that is the part that makes it hard: removing a cell moves the state root, so the removal is not housekeeping a node may do in its own time. It is a consensus operation every validator has to reproduce exactly.

Three consequences are stated in the document. The cell answers for its own life: a sweepable cell carries its expiry in its value and keys by it, so no side index and no transaction body is needed to decide whether it is still owed — which matters because the key prefix is the only thing guaranteed to survive a shard reshape, and a rule keyed off anything else "would not survive a split". The block states a frontier, not a list: sweepable cells sort by an expiry bucket leading the key's local half, so a chain's sweep is a cursor over that order and a block's removals are exactly the cells between its parent's frontier and its own, with the interval capped and the cursor recording where a capped sweep stopped. Advancing is obliged: a removal earns no fee and costs a proposer block space, so "a rule permitting omission is one honest proposers converge on omitting" — a block that could sweep and did not is refused.

The invariant register

A single 30-line commit registered the properties in docs/08-invariants.md as INV-SWEEP-1 through INV-SWEEP-9, alongside the existing consensus, state and economic families. The load-bearing ones are the determinism claim (INV-SWEEP-1, a block's removals are a function of its frontier pair and committed state, so "nothing about which node proposed the block, or how a node came by its state, enters into it"), the safety claim (INV-SWEEP-3, a sweep removes no cell any admissible transaction could still read), the liveness pair (INV-SWEEP-4, sweep work per block is bounded and a partial sweep says where it stopped, so a backlog drains across blocks; INV-SWEEP-6, mandatory advance), and the two that keep the cursor monotone across a reshape (INV-SWEEP-7, nothing is born below the cursor; INV-SWEEP-8, an inherited frontier never rises). What stops a sweep retiring something still in use is not a clock-skew bound but co-location: the chain holding the cell is the chain that would read it.

Eleven commits, and a model of what breaks it

The work is legible commit by commit in the repository across 31 August and 1 September 2026: an expiry given to a nullifier "in its value and in its key", the key led by the bucket its expiry falls in, a shard's sweepable cells indexed by expiry bucket, a bound on how many one block may create, expired cells retired at a frontier the header states (694 additions across twelve crates, the largest of the set), a from-scratch commit made to state what it removes, and a test watching a real nullifier leave state once nothing can reach it. On 1 September the set closed the way this project closes design work: a 560-line Quint model, specs/substate_sweep.qnt, registered as Model K — one module for a chain's frontier walk and one for what a successor's cursor starts at, with everything else (consensus, execution, the index that finds the candidates) left as an oracle, and with the "twins" that deliberately break the invariants written beside the model, the same technique described under Formal Verification below.

The second item in the same digest is smaller and unrelated to the sweep: intents now carry a signed header naming the network they are for, so an intent naming a network its envelope does not is refused, and a transaction's validity window narrows to the intersection of every intent it binds. Both close cross-network replay. The digest names integrating the sweep into shard execution as the next step.

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:

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:

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.

Why the answer to more throughput is more shards (August 2026)

The 20.3× figure invites the obvious follow-up: how much further can the VM itself be pushed? On 20 August 2026 a channel member put that question to an AI coding assistant against the repository and posted the exchange — does hyperscale use a register-style instruction set mapped onto the hardware, as Solana does with SBF, rather than stack-shaped bytecode? The lead developer's reply treated micro-optimisation as the wrong axis altogether: “there's no real need to throw the kitchen sink at micro compute optimizations. the bottleneck for per-shard throughput will pretty much always be bandwidth as hs-vm will be plenty fast (competitive with SOTA). and it's better to just add additional shards, rather than try to squeek out further marginal bumps which might have to come at the cost of expressiveness”.

Three commitments are packed into that. Per-shard throughput is expected to be bandwidth-bound rather than CPU-bound, which is consistent with the shape of the benchmark above — 39 µs of execution per transfer is nowhere near the constraint at a per-shard target of roughly 1,000 TPS. Scaling is therefore horizontal by design: more shards, not a faster instruction set, which is the same conclusion the consensus section reaches from the other direction. And expressiveness is treated as a budget that micro-optimisation spends — the narrower and more hardware-shaped an instruction set becomes, the less the language above it can express, and the project is unwilling to trade in that direction for marginal gains it does not need.

The practical reading for this page is that the execution figures above are a margin, not a target. The VM's job is to stay comfortably inside the per-shard budget set by the home-validator hardware profile, and the throughput story is told by shard count.

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

What another shard costs, and what a demand spike does (August 2026)

The figures above price one node. On 30 August 2026 a channel member argued that Hyperscale's node requirements were a genuine differentiator against other networks, "a big issue on most nets, Radix included". The lead developer declined the energy framing, and in declining it gave the first public arithmetic for what capacity costs in validators rather than in hardware: to get more throughput "you have to have another 128 nodes online (granted there is some variable amortization via vnodes)... plus you need a free pool online to draw shuffle replacements from". Both halves are protocol rather than rhetoric. A split is gated on the free validator pool being deep enough to staff it, and the epoch fold prices activation against committees times committee size, plus a standing reserve. What is new is the framing: an increment of throughput has a validator price, and the standing reserve is part of it. The 100-shard version of the same arithmetic, 12,800 small validator nodes against Solana's roughly 1,000 large ones, is the channel member's extrapolation and not a project figure.

Later that day another member put four questions to the developer, and the four answers are the most compact statement of the operating story so far. Throughput and latency under realistic DeFi load "depends on the hardware and network links of the validators". Running a node is "not very" painful, with a qualification that dates the client work: a GUI validator client is "still pending building", and the goal is "for complete amateurs to be able to run". A demand spike is answered by topology rather than by headroom, "shards split into more shards (as long as there are enough free nodes to support a split) freeing up more execution capacity", which is the same free-pool dependency arriving from the user's side. The fourth question, on whether the architecture forces redundancy that eats the theoretical gains, was returned as a question, and the answer to it is the multi-stage routing work recorded under Contention above. One follow-up sharpened the third: how well splitting absorbs a spike depends mechanically on how fast a shard splits, which is a latency the project has not published.

On power specifically the developer put a home node below noticeability, "doing Radix-level TPS... won't even add enough to your computers power draw to appear as a rounding error on your electric bill", and in the same exchange gave an unflattering reading of what today's mainnet actually costs to run: "everyone is just basically signing empty blocks at the moment. Babylon should only really need a small fraction of a single core... it's crazy inefficient". He then declined to quantify any of it, which is the caveat the rest of this section should be read under: "people can provide their own experience with energy use during testnets. it's not worth spending any time thinking about before then. particularly as the software is pre-alpha and still changing every day". Nothing here is a measurement.

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.

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

Funding Withdrawn (3 September 2026)

That arrangement ended in one sentence. At 00:28 UTC 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”. Asked at once whether the project would continue, he said it would: “yes, hyperscale will continue. and radix is free to adopt the protocol as they wish. it is an open project.” On delivery he was explicit: “i don’t anticipate any change in the velocity of delivering the tech… the tech will be delivered because i think it is good.” The reason he gave was the relationship rather than the amount: “i just don’t want anything to do with people who think some minuscule grant has purchased me for particular project.” Each message is confirmed as his at its own public embed.

The withdrawal was stated in the channel only. Re-read on 3 September 2026, the RFC topic holds fifteen replies whose last is dated 4 May 2026, and is neither closed nor archived, so the proposal stands on the forum unaltered. For this article the consequence is confined to the funding and governance terms: the five unpaid milestones, the Accountability Council sign-off on each of them, the named arbitrator and the funder’s no-exit-fee stop at any boundary all lapse with the proposal, while the licence granted in August 2026 is irrevocable and the code, the roadmap and the single-author concentration described throughout this article are unchanged. Whether the DAO can still adopt the result is a question about adoption rather than about funding, and the only answer on the record is that Radix is free to do so.

What the Withdrawal Covers (3 September 2026)

Between 09:18 and 11:00 UTC the same morning, pressed in the project channel over what the withdrawal meant, the lead developer answered the questions the first four messages had left open. The exchange was adversarial — his counterpart for most of it was a channel admin arguing that the position was ambiguous and that “if you build scaling for Radix it’s underpaid” — and the answers are correspondingly blunt. Each is confirmed as his at its own public embed.

The scope is future grants, not the work. Asked directly whether he no longer wished to receive funding beyond what had already been paid out, he answered: “How much more clear can I be? I do not wish to pursue additional grants from Radix” — and separated that from any principle, “not particularly because I think that steering organisations of decentralized networks should not support open source devs working on their technical foundations. Merely because irrational counterparties like yourself make the whole experience miserable.” He had put the same point more plainly an hour earlier: “The idea I would stop working on it if not paid is laughable to me… I just don’t want to deal with the bullshit associated with taking any grants because people run roughshod over any parameters specified anyway.” Where the withdrawal message of 00:28 UTC gave the relationship as the reason, this states the mechanism: the grant is what gives the dispute a surface, so removing the grant removes the dispute — “if the root of our disagreements is compensation, I’d rather just take the matter off the table.”

What the Foundation payment bought was narrower than the RFC schedule. Rejecting the reading that a grant had made him Radix’s technical lead, he described the terms of what was actually paid: “I have always been 100% clear there was never any obligations of either side to continue… the foundation payment was very clear that the only deliverable was open-sourcing work completed to date.” That is a materially smaller commitment than the six-milestone table above implies, and it is discharged: the dual MIT/Apache-2.0 licence committed to both repositories on 7 August 2026 is the deliverable, and it is irrevocable. On that account nothing is owed in either direction, which is consistent with a withdrawal announced without notice or settlement.

No payment record has been published. The only figure on the record entered the conversation from the questioner, who asked whether he no longer wished to receive funding “past the $50k or whatever it was already paid out”; the developer’s reply took the number up sarcastically rather than confirming it — “that $50k which became $25k will fund hyperscale for the rest of time and it will require no sacrifices on my part.” Neither the Foundation nor the developer has published an amount or a payment date, so the wiki records the exchange rather than a figure. The halving it describes is what the RFC’s own mechanism does: payment is denominated in USD but settled in XRD at a 30-day TWAP, so a payment fixed in dollars and taken in a falling token is worth what the token is worth when it is sold, and the price has since fallen further still.

Radix is not stated to be the destination. The sharpest disagreement was over whether hyperscale-rs is being built for Radix. He declined the framing twice — “you just choose to completely ignore the clear parameters I’ve always had (that Hyperscale is an open source project)” — and put the goal in terms that name no chain: “the only thing I particularly care about is the tech being adopted… in any format that takes”, and “I would much rather just work on the tech and give it away to anyone and everyone.” Asked why not simply launch a chain of his own with a token, he refused that too: “talk about monetization of the tech is actually a thing that undermines my motivation.” For Xi'an the consequence is precise and worth stating plainly: the licence lets Radix adopt this code, and the author says he would welcome anyone adopting it, but as of 3 September 2026 there is no commitment from him that Radix is where it lands. He closed the exchange on the only thing he did commit to — “I’m just going to wake up again tomorrow and keep working on the tech anyway.”

The withdrawal has a price, and it was about a week from being paid. Through the afternoon of 3 September the same developer put a figure on what the decision costs him, without naming an amount: “If I was trying to hyper-optimize for some financial gain I would wait a week for RDX to pay out M1… I’m not though, I just want to work on the tech and try to keep my sanity and dignity.” That dates a pending Milestone 1 payment from RDX Works to roughly 10 September 2026 and places the withdrawal ahead of it rather than after it — the first statement from either side that the milestone schedule was still live and paying when it was abandoned. No payment record has been published, and the sum is not stated; the figures circulating in the channel come from questioners rather than from either party and are not recorded here.

The same message is also the fullest commitment yet made to the work itself, and it is broader than the RFC: “And work on it i will. Through all the stages of VM, and gateway, and desktop validator, and everything else in the milestones. And even all the additional ideas I’ve thought of along the way like privacy solutions.” Read alongside the refusal earlier the same morning to say that Radix is where the code lands, the position is now specific on both halves: the six-milestone programme survives the withdrawal, the funding does not, and the destination is still unstated. On the tokens already earmarked for it he was explicit that they should go elsewhere — “The game theoretic optimal play of the DAO is to reallocate those earmarked tokens toward getting users or something” — and on his own position, “The only person who really needs to worry about funding is me…. and I’m not worried.”

Formal Verification (July–August 2026)

Deterministic simulation testing, described above, runs the system thousands of times against hostile schedules and replays any failure forever. It cannot say what happens on the paths it never walked. Since 3 July 2026 the project has run a second programme beside it: machine-checked models of the protocols themselves. The repository's specs/ directory holds ten protocol models written in Quint, a specification language in the TLA+ family, and checked with Apalache, a symbolic model checker, through quint verify. The first commit added a model of the weighted-time clock; the directory has taken 63 commits since, the most recent on 24 August 2026.

The properties are not invented model by model. They come from the project's invariant register, which gives every safety and liveness claim a stable identifier: 75 of them across eight families (INV-SEC, INV-SHARD, INV-BEACON, INV-EXEC, INV-RESHAPE, INV-DET, INV-STATE, INV-ECON), with the execution layer's own properties kept in the VM's separate register. A model cites the IDs it checks rather than restating them, which makes the register a verification worklist rather than documentation.

The ten models

Scope and status as recorded in specs/README.md, read 24 August 2026. Apalache is exhaustive within an explicit depth bound, so a status of "verified" means the property held over every behaviour the rules permit inside that bound.

The models compose by abstraction rather than by size: each takes an earlier model's verified properties as axioms, so B resolves committees through A's clock, C treats a shard chain as the commit oracle B justifies, and D adds shard termination on top of C. No model contains the whole system, which is the point. A statistical companion, SEC-1, prices the premise every model assumes (fewer than one third of any committee Byzantine) with concentration bounds and Markov analysis instead of a reachability check.

The discipline

Four rules in specs/README.md do most of the work, and each answers a way this kind of programme usually goes wrong. Properties come from the register, so a model cannot quietly check something easier than what the system claims. Transitions come from the code, not the docs: every modelled rule names its implementing crate, file and function in a comment, on the grounds that a model transcribed from prose verifies the documentation rather than the system. Every model ships a broken twin, an instance whose rules violate the property's precondition so that quint verify must produce the counterexample, because "a checker that has never produced a counterexample against the model proves nothing about the model". And a finding is not closed until it is traced through the implementation and resolved as a code change, a documentation change, or a stated non-issue.

Checking runs in three tiers: quint typecheck, then quint run for fast random search, then quint verify, which hands the model to Apalache for an exhaustive search to a bounded depth (ten steps by default). Counterexamples are written out as ITF JSON traces, the format a future bridge could replay directly against the Rust state machines.

What the models have found

Two results are on the record. Modelling the beacon's agreement layer against Prefix Consensus for Censorship Resistant BFT (Xiang, Tonkikh and Spiegelman, February 2026), the algorithm it implements, surfaced a real divergence: in one corner case the implementation resolved a value's parent differently from the paper, legal-looking and wrong under exactly the right absence of data. The model produced the recipe, the deterministic simulator replayed it as a failing test, and the fix landed with a permanent regression scenario pinning it; the deviation now survives only as model E's parent_of broken twin, which forks two replicas on one committed value with no Byzantine action at all.

The second is less comfortable and is published as such. Model G takes as its premise that the Byzantine assumption has already failed, and its Finding G-1 is an Apalache counterexample rather than a pass: because a retained committee beyond the one-third bound can drag the quorum's weighted timestamp arbitrarily, a folded replica can admit an orphan commit past a halted shard's tip. The mitigation modelled and implemented alongside it is a beacon-mandated freeze that revokes a halted committee's cross-shard authority network-wide at detection, and the honest conclusion recorded with it is that the band between f+1 and 2f corrupt members is "a bounded-exposure regime, not a clean recovery".

What is and is not claimed

The project states the limits itself, in the register and in the public explainer hyperscale.rs/proof, posted to the project channel on 24 August 2026. First-pass models of the critical core exist and are being checked; the register is a to-do list worked through in the open, not a completed proof. A model is not the code, and keeping the two in agreement is a separate obligation, made tractable because the consensus core is already written as pure transition functions and kept honest by replaying every counterexample against the implementation. And model checking is exhaustive only inside its bounds: small committees, short horizons, on the bet that protocol bugs have small witnesses. specs/README.md says it plainly, that bounded checking is not proof, with inductive invariants named as the upgrade path once a model stabilises.

None of this is an external review. No audit has been commissioned, and the project's own position on when one should happen is recorded in the section below.

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:

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