Radix Week in Review: Milestone 1 Done, and the New Engine Goes Public

The week in brief

• hyperscale-rs finished its first milestone, covering validator lifecycle, consensus, and shards that split and merge while the network keeps running.
• The execution engine that will sit on top of it went public eight days after its first commit: 259 files of Rust, and a README that opens by telling you not to use it yet.
• Scrypto survives the change of engine; what changes is underneath it.
• A Hyperscale validator should run on a Raspberry Pi, and there is no slashing in the design: cheating impounds your stake for 90 days rather than burning it.
• Someone published 38 reference guides for AI coding agents, and a community member used them to put an escrow contract on mainnet in an afternoon.
• The DAO's governance contract is live on mainnet with real addresses, and all three of its counters read zero.

The milestone, and what it covered

Milestone 1 covers the validator lifecycle, the consensus engine, and dynamic sharding, which lets shards split and merge as load changes without the network stopping. The last piece to land was committee rotation: when a shard's set of validators changes, seats are replaced one at a time rather than all at once, so the new one is in place before the old one goes. Two items were deferred, chiefly the ability to split a shard because of fee pressure rather than because it has accumulated bytes, and both wait on the fee system, which in turn waits on the layer above.

The new engine, in public

That layer arrived on Friday evening as a link: 259 files of Rust across twelve crates, 133 commits, dual-licensed Apache-2.0 and MIT, eight days from first commit to a public repository with a working reference interpreter in it.

Its design idea is that a transaction should declare what it touches instead of being run to find out. On Radix today the only reliable way to learn what a transaction affects is to execute it and watch, which is fine on a single shard and fatal across many, because the network has to know which shards are involved before it can schedule anything. The new engine moves that answer to the front: one function reads a transaction's instructions and returns the shards involved, the state each will touch, and how it will be touched, with no execution and no reading of state. A queue of pending transactions can be scheduled from that; a proposer can budget from it; the preview a Radix wallet shows before you sign comes from the same read. If a contract then reaches for something it never declared, there is no handle for it to call and it fails on the spot.

The payoff is in the locking. Instead of locking a whole object, the engine has five kinds of access and a table of which ones can safely run together: reads share with reads, and increments and reservations commute, so a thousand deposits into one vault stop forming a queue and become a single parallel group. Nothing is executed speculatively and nothing is rolled back, because the conflicts fall out of the declarations.

Every transaction profile is then executed twice, by a pinned version of the standard runtime and by a reference interpreter written independently from the specification, and the two are compared. A disagreement blocks the release whichever side turns out to be wrong. That is a check the engine cannot outrun, wired in by the people building it.

Scrypto survives, which was the biggest open question for builders since the Radix Engine was ruled out for sharding the week before. The answer on Monday was that Scrypto is a couple of Rust macros, that reaching parity is not hard, and that the parts developers actually handle, such as manifests, resources, subintents and badges, are considered good and stay. What changes is beneath them: state, locking and parallelism. Existing contracts face a recompile at best and an automated conversion tool at worst.

What a validator seat will cost

Asked whether a Hyperscale node could run on a Raspberry Pi 5 with a fast disk, the answer was almost certainly, and possibly several on the same board: under a tenth of one processor core, around 200 MB of memory, and storage bounded by how often shards split. A Babylon node today wants a server. That single fact does more to decide who is allowed to run this network than any policy document.

The penalties match. There is no slashing anywhere in the design. Go offline or fall behind and your seat is jailed until you bring it back. Do something provably dishonest, such as voting two ways or issuing two proposals for the same round, both of which require deliberately modifying the software, and your stake is impounded for 90 days: locked, not burned, with the period set by governance. That distinction matters most to people who never touch a machine, because someone who staked with the wrong operator loses access for a season and keeps their money. Delegation shifts too, from backing one validator towards backing a pool that may run several, and if more machines turn up than the network needs, the price of a seat rises until the surplus leaves.

An afternoon to mainnet

On Thursday a former lead of Radix's application engineering team published what he knew in a form an AI coding agent can read: 38 reference guides covering transaction manifests, Scrypto, the Gateway, ROLA, subintents, pools, royalties, fees and data encoding, bundled so the agent clones the real Radix sources and works against them rather than inventing an interface that never existed. It is the cheapest available fix for the hardest problem a small ecosystem has, which is that these models have read every line of Solidity ever written and almost no Scrypto.

The demonstration came the same day. A community member pointed an agent at it and about three hours later had Trade Vault, a person-to-person escrow, with contracts deployed to mainnet and a wallet flow attached. It carries a use-at-your-own-risk warning and it duplicates something another project already does, which is beside the point: the limit on how much gets built on Radix has always been how many people know how to build it, and that limit moved.

Three counters, all zero

On 7 August the DAO's on-chain identifier policy replaced its placeholders with real mainnet addresses, and because addresses can be checked, this wiki checked them. The governance component is live and running the code the policy names. Its three counters, for temperature checks, proposals and council elections, all read zero. Every governance path in the framework routes through a contract that is deployed, correct, and has processed nothing.

The rest of the week rhymed with that. Asked whether he was in touch with the Accountability Council about signing off Milestone 2, the hyperscale-rs developer said there is no Council to be in touch with. A transitional council does exist and has not been idle: it retained lawyers, drafted the DAO's operating agreement and charter, and put two proposals to a vote on 28 July. Its job is to form the company and take the handover, not to approve engine milestones. The permanent elected body that would do that does not exist, and until a voting application capable of running an election appeared on 4 August there was no way to elect it.

The wallet and the Gateway are in maintenance mode until the community picks a direction and votes it through, and the route to picking one runs from draft discussion to temperature check to proposal, with nothing currently in flight. The Radix Foundation blog has published nothing since 28 April.

Into that gap, on Saturday, a team published a governance design of its own, with a hash-pinned tally document and an independent verifier. It drew real technical questions and one objection of principle: that the useful half could have arrived as a change to the voting application the DAO already runs, without standing up a second system underneath the vote. Both sides argued from an operating agreement that is still a draft.

The most telling conversation happened on Sunday and had no announcement attached. Someone asked what is actually left in the treasury the DAO is about to inherit, and nobody could say. So the channel costed out survival instead: how many validators does the network strictly need to keep producing blocks, which they put at four, and who would run them for nothing. The Gateway is paid for to the end of 2026. One member pointed out that he already runs five validators, two of them taken on when DeXter and HUG collapsed. An hour of arithmetic produced a workable answer.

The week on the ledger

Read from the Radix Gateway as the ledger stood at midday on 9 August 2026, epoch 333,449, against the same reading a week earlier.

Stake up 20 million XRD, and three more validators charging a fee that differs from the one they publish.

Concentration watch

Eight validators held a third of all staked XRD, unchanged, and 15 held half.

This week on the wiki

hyperscale-rs for what Milestone 1 covers, and Radix governance for why a deployed contract with three zero counters is the state of play rather than a glitch.

What to watch

• Whether any of the three counters moves off zero, which is the only evidence the governance machinery works.
• An answer on what the treasury holds, before the vote that hands it over.
• A second contributor on the new engine, which currently has one.

Corrections

Nothing this week.

Next: the activation vote, with the two numbers that decide it, what the treasury holds and what a year of running a DAO costs, both still unwritten.

Radix Week in Review series, Issue #7: ← Previous: Issue #6, Jul 27 – Aug 2, 2026 · Next: Issue #8, Aug 10–16, 2026 → · All recaps · Subscribe

Previously: A sharded Radix network now runs in a browser tab, and Hyperscale will get a purpose-built virtual machine rather than reusing the Radix Engine.