RADIX WikiRADIX Wiki

In 1846 Parliament settled an argument about track. Isambard Kingdom Brunel had laid the Great Western on a seven-foot gauge because seven feet rode steadier and carried more; nearly everyone else had laid four foot eight and a half. The Regulating the Gauge of Railways Act chose the narrower one, and the Great Western then spent forty-six years pulling up its own railway and relaying it, finishing in May 1892. Brunel's engineering was the better engineering, and the wrong width.

Radix made a decision of that class this week, and made it at the surveying stage rather than after four decades of traffic. The Radix Engine runs every smart contract on the network today. It will not run the sharded network that hyperscale-rs is building. A purpose-built virtual machine is underway instead, and the two migration paths that would have carried existing dApps across unchanged have gone. You can widen a road. You cannot widen it into a railway.

The Gauge Question

On 1 August, in the project's Telegram channel, hyperscale-rs lead developer flightofthefox was asked whether the Radix Engine was built for sharding. "It's not in the ballpark. It's not in the same zip code as the ballpark." Asked directly whether a new VM made more sense than modifying the existing one, the answer was "yeah, it's underway". The reasoning followed a few minutes later: "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."

Back in April the migration had three shapes. Two of them spared the ecosystem: leave existing blueprints untouched, or run a dual modality with a legacy environment alongside the new one. Both are gone. "yeah option B. options A and C have dissolved." Option B is the one that ends with a new execution layer and a migration for everything already deployed.

What that costs the ecosystem is the open question, and it stayed open all week. Asked whether Scrypto goes too, the channel got no answer. Asked this morning whether existing apps face minor edits or rewrites from scratch, the channel got no answer to that either. Both questions are now the most consequential unresolved facts in the Radix stack, and neither has a date on it.

The governance consequence is immediate. The Xi'an RFC asks the DAO to fund Hyperscale delivery, and the wiki's status card for that decision was rewritten this week to say what the money now buys: an execution layer built from scratch, plus the migration of every dApp on mainnet. That is a different proposition from maintaining the engine Babylon shipped with, and the people voting on it deserve to price it correctly.

A Network in a Browser Tab

The same fortnight produced the most legible artifact the project has made. On 27 July flightofthefox compiled the node to WebAssembly and put a multi-shard network in a browser tab. Open hyperscale.rs/demo and four validators come up across a shard trie, chains marked by weighted time and attestation, and you can submit a transaction and follow it through. It runs the actual node software: the only substitutions are in-memory storage instead of RocksDB, and a simulated network layer routing messages directly at 150 ms latency. It is deterministic, so the same seed replays the same run byte for byte. Sharded consensus is normally something you read a paper about. Here it is a page you can pause.

Underneath it, the week's digest reported the keystone of adaptive sharding landing: the exact moment a shard splits or merges is now derived through a single tested and formally modeled path. Milestone 1, week 13, 125 commits.

Two design answers came out of the channel alongside it. The beacon chain, which appoints every committee, never sees a transaction and therefore does not cap throughput: "transactions don't need to touch it", and some canonical agreement on what shards exist was always required, whatever the Cerberus paper called it. Its censorship resistance is structural rather than incidental. Where MultiversX's metachain and NEAR's design are leadered, and so present one machine to attack, unseating the hyperscale-rs beacon means taking down f+1 of its committee. The real ceiling sits elsewhere: block header gossip, which authenticates the state roots every cross-shard execution depends on, and eventually the speed of light.

The other answer is a deletion. Braided cross-shard voting, the mechanism the Cerberus paper is known for, is out. "Braiding is a terrible idea. Makes shards co-dependent on each other for liveness." Shards now execute independently and exchange proof of execution; when every involved shard holds every proof, the transaction commits. No votes cross between them.

The wiki spent the week catching up to all of it. The hyperscale-rs article was reconciled against all nine design documents and went from version 4.10.1 to 5.0.1 across eighteen exact-match corrections, including a stale two-phase-commit description of the transaction flow and a claim of one-round finality that the invariants contradict. It also now records finding G-1, an open safety gap the project adjudicated against itself in its own specification: in the recovery band above f, a retained committee's corrupt majority can drag the certified re-bind window and admit an orphan commit past a halted tip. Publishing the weakness in the register is the strongest signal in the repository.

The Register of Names

A railway that reaches the border still needs the other country to know what to call it. That is the work the community started this week. On 30 July the Radix ambassador avaunt posted a temperature check proposing that Radix be registered in the Chain Agnostic namespaces registry and added 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 as they standardize.

The submission material went public on 1 August and is reviewable now: the CAIP-2, CAIP-10 and CAIP-19 profiles for Radix, and an x402 exact-payment scheme forked from xStelea's original and realigned with upstream. Three pull requests are planned: the specification, a reference implementation, and an SDK. The vote is open at Temperature Check 6.

The machinery carrying that vote is itself new. The consultation dApp is running on mainnet, and it has now moved real decisions: Temperature Checks 4 and 5, on continuing Stokenet operations and on moving the website off Webflow, both passed and were lifted on 28 July into binding XRD-weighted Proposals 1 and 2, which close on 4 August. Its rough edges are being reported and patched in the open, including a vote button that overflowed the page on Android and kept people from voting at all. This is what the transition to community governance looks like in practice: an unpaid ambassador drafting standards documents, and a bug report about a button.

Housekeeping

Two operators published honest bad news this week, which is worth more than a good announcement. The RadixPlanet validator had promised to cut its fee from 40% to 35% after XRD recovered in late July; 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 in silence. Muan Protocol paused its mainnet frontend outright, citing almost no users, while it rebuilds around non-custodial snapshot voting, and is reimbursing anyone who paid fees on a version-one vote NFT.

None of this week's news came from the Radix Foundation. Its blog has published nothing since 28 April, when it announced its move to maintenance mode. The record now lives in a Telegram channel, a git repository, an on-chain consultation dApp and a handful of ambassador forks. That is what the handover to the community actually looks like from the outside: the sources change before the substance does.

Two dates carry into next week. Proposals 1 and 2 close on 4 August, the first binding XRD-weighted votes the new dApp has ever settled. And somewhere in the answer to a question asked twice in a Telegram channel and not yet answered sits the cost of the new gauge: what happens to Scrypto, and what every dApp already on mainnet has to do to reach the other side.