The week in brief
- You can now open a sharded Radix network in a browser tab, running the real node software, and watch a transaction go through it.
- Hyperscale will not reuse the Radix Engine. A purpose-built virtual machine is being written instead, decided at the design stage rather than after launch.
- Existing applications will need at least a recompile, and at worst a tool that rewrites their source; there is no date for either.
- Braided cross-shard voting, the mechanism the original Cerberus paper is known for, has been dropped in favour of shards exchanging proofs.
- A community ambassador prepared submissions to register Radix in the cross-chain naming registry and in x402, the standard for machine-to-machine payments.
- The community's own voting application settled its first two binding votes.
The most useful thing anyone shipped this week is a link. On 27 July flightofthefox compiled the hyperscale-rs node to WebAssembly and put a four-validator sharded network in a browser tab: open the demo, submit a transaction, and follow it across shards. It runs the actual node software, with only two substitutions: it keeps its data in memory rather than on disk, and it routes messages directly at a fixed 150 millisecond delay instead of over a real network. It is deterministic, so the same starting seed replays the same run exactly. Sharded consensus is usually a paper. This is a page you can pause.
Underneath it, the project's thirteenth week on its first milestone produced 125 commits and the keystone of adaptive sharding: the precise moment a shard splits or merges is now decided by one tested and formally modelled path rather than several.
A new virtual machine, decided early
The Radix Engine runs every smart contract on Radix today. It will not run the sharded network. Asked on 1 August whether the engine was built for sharding, flightofthefox said it was not in the ballpark, and not in the same postcode as the ballpark; asked whether a new virtual machine made more sense than adapting the old one, he said it was already underway.
The sharding adjustments are so many that it would require touching everything. At some point it becomes easier to start with intention than to retrofit.
The reason is state contention. Consensus and the Radix Engine each work well on their own; run together, they stall on transactions queuing for the same state locks, and sharding cannot make that queue shorter.
Back in April the migration had three possible shapes, and two of them would have spared existing applications: leave deployed code untouched, or run the old environment alongside the new one. Both have now gone. What remains is a new execution layer plus a migration for everything already on mainnet. Asked what that costs a developer, the answer was a recompile at best and, at worst, an automatic tool that rewrites their source code. Asked twice whether Scrypto survives, the channel pointed back at that same answer. Neither carries a date.
This changes what a vote is about. The Xi'an proposal asks the DAO to fund Hyperscale delivery, and the money now buys an execution layer written from scratch plus the migration of every application on mainnet, which is a different proposition from maintaining what Babylon shipped. The status card on this wiki was rewritten during the week to say so.
Two design answers
The beacon chain is the part that appoints every committee of validators. It never sees a transaction, so it does not cap throughput, and its resistance to censorship comes from its shape: unseating it means taking down more than a third of its committee, where designs with a single leader, such as MultiversX's metachain or NEAR's, present one machine to attack. The real ceiling sits elsewhere, in the gossip of block headers that authenticates the state every cross-shard execution depends on, and eventually in the speed of light.
The second answer is a removal. Braided cross-shard voting, the mechanism the Cerberus paper is best known for, is out, on the grounds that it makes shards depend on each other to stay alive. Shards now execute independently and exchange proof that they did; when every shard involved holds every proof, the transaction commits. No votes cross between them.
This wiki spent the week catching up. The hyperscale-rs article was reconciled against all nine design documents and went from version 4.10.1 to 5.0.1 across eighteen corrections, including a description of the transaction flow that still said two-phase commit and a claim of one-round finality that the project's own invariants contradict. It also now records finding G-1, a safety gap the project adjudicated against itself in its own specification: above the fault threshold, a retained committee with a corrupt majority can stretch the re-bind window and admit an orphaned commit past a halted tip. A project that writes its own open weakness into the register is telling you something useful about the register.
Getting Radix named in other people's standards
On 30 July the community ambassador avaunt proposed registering Radix in the Chain Agnostic namespaces registry and adding it as a supported network in x402, the open standard for machine-to-machine payments over HTTP. The first gives every cross-chain tool a canonical way to name Radix chains, accounts and assets; the second puts Radix in the path of agent payments while that path is still being laid.
The submissions went public on 1 August and can be reviewed now: naming profiles for chains, accounts and assets, and an exact-payment scheme forked from xStelea's original and realigned with upstream. Three pull requests are planned, for the specification, a reference implementation and a kit for developers.
The machinery carrying that vote is itself new. The consultation application runs on mainnet, and it has now moved real decisions: two temperature checks, on continuing to operate Stokenet and on moving the website off Webflow, both passed and were lifted on 28 July into binding votes weighted by XRD, closing on 4 August. Its rough edges are being reported and fixed in the open, including a vote button that overflowed the page on Android and stopped people voting at all. An unpaid ambassador drafting standards documents, and a bug report about a button: that is what the handover looks like from the outside.
Two operators published bad news
The RadixPlanet validator had promised to cut its fee from 40% to 35% once the XRD price recovered. The price pulled back, the margin went with it, and the operator held the fee where it was and said so, rather than letting the promise lapse quietly. Muan Protocol paused its mainnet front end outright, citing almost no users, while it rebuilds around non-custodial snapshot voting, and is refunding anyone who paid fees on a first-version voting NFT.
Nothing this week came from the Radix Foundation, whose blog has published nothing since 28 April. The record now lives in a Telegram channel, a git repository, a voting application on the ledger and a handful of ambassador forks.
The week on the ledger
Read from the Radix Gateway as the ledger stood at midday on 2 August 2026, epoch 331,433, against the same reading a week earlier.
| Metric | This reading | On the week |
|---|---|---|
| XRD staked | 4.94 billion | up 37 million, or 0.8% |
| Validators in the active set, of those registered to be | 100 of 179 | unchanged |
| Validators holding a third of the stake between them | 8 | unchanged |
| Share of stake held by the largest 10 | 39.81% | down 0.02 points |
| Validators charging a fee that differs from the one they publish | 77 | unchanged |
Stake up 37 million XRD on the week, with everything else steady.
This week on the wiki
The hyperscale-rs article is the one to read, having been rewritten against the design documents this week; and the Xi'an page for what the funding proposal now covers.
Everything else this week.
Hyperscale
Standards
Governance and operators
Next: the first binding votes settle, and the new virtual machine still has no date.
Sources
- ↑ hyperscale-rs, the sharded network demo ↗
- ↑ hyperscale.rs, the project site ↗
- ↑ The Chain Agnostic namespaces registry ↗
- ↑ x402, the machine-to-machine payment standard ↗
- ↑ The Cerberus whitepaper ↗
- ↑ Radix Gateway, ledger state read at epoch 331,433 on 2 August 2026 ↗
- ↑ hyperscale-rs on this wiki ↗
- ↑ The Radix Engine on this wiki ↗
- ↑ Xi'an on this wiki ↗
- ↑ RadixTalk, the governance category ↗
- ↑ Radix developer documentation ↗
- ↑ Radix Knowledge Base ↗
- ↑ radixdlt on GitHub ↗
- ↑ The Radix Dashboard ↗
- ↑ The Radix Foundation blog ↗
- ↑ hyperscale-rs on GitHub ↗
- ↑ The Radix Engine Toolkit on GitHub ↗
Radix Week in Review series, Issue #6: ← Previous: Issue #5, Jul 20–26, 2026 · Next: Issue #7, Aug 3–9, 2026 → · All recaps · Subscribe
Previously: Hyperscale's design was set against the standard list of sharding problems and answered point by point, and the Foundation put the DAO about a month out.
