--- title: "Radix Week in Review: Show Your Work" path: "/blog/week-in-review-2026-07-26" version: "1.0.0" author: "Hydrate" createdAt: "2026-07-26T11:07:57.370Z" updatedAt: "2026-07-26T11:07:57.370Z" --- # Radix Week in Review: Show Your Work | Week of | July 20–26, 2026 | | Top story | Hyperscale's design set against Vitalik Buterin's 2017 Sharding FAQ and answered question by question | | Protocol & Dev | hyperscale-rs slashing and Cerberus-lineage debates run in the open; the lead developer drafts a testing writeup for r/rust | | Ecosystem | Radix Seal ships: ROLA document signing, encryption, and private chat | | Community & Governance | The Foundation says the DAO is roughly a month out; the community debates its structure in public | | Sources | Telegram (RadixDevelopers, hyperscale-rs, radix_dlt), X, hyperscale.rs, the genkipool console, radix.wiki | Crypto runs on claims. A whitepaper asserts that it scales; a launch deck asserts that it decentralizes; the reader is asked to take the assertion on trust and check nothing. What made this week on Radix worth reading is that it did the rarer thing. It showed the working. On the protocol side, the answers to a decade-old set of hard questions were written out in public, question by question, where anyone can grade them. On the governance side, a community argued the structure of its coming DAO in the open, in the group chat, before any vote. Two different exams, both marked where the whole class can see. ## Answering a Ten-Year-Old Exam In December 2017 Vitalik Buterin published a [Sharding FAQ](https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html), the canonical catalogue of everything that makes sharding a blockchain hard: cross-shard atomicity, data availability, validator assignment, the single-shard takeover attack. Almost ten years on, most of it is still the exam every sharded design has to sit. This week the lead developer of [hyperscale-rs](/contents/tech/research/hyperscale-rs) (known in the channels as flightofthefox) worked through that FAQ point by point against Hyperscale's architecture and posted the comparison for discussion. It travelled: a community member reposted it to X under the title [Sharding: Questions Then. Answers Now.](https://x.com/Gbyte691/status/2080289880228188256), and it became the most-amplified Radix post of the week. The design's answer to the central question is the one Radix has carried since Cerberus. Where conventional sharding forces a choice between shards mailing each other asynchronous messages, executing optimistically and rolling back, or fencing composability off into walled gardens, Hyperscale keeps atomic composability across shards: a transaction [declares the state it touches](https://hyperscale.rs), every shard that owns any of that state takes part, and the transaction commits on all of them or on none. The claim is old. What was new this week was setting it beside the specific questions a skeptic would ask and answering them in order. The channel did not treat any of it as settled. A long thread asked the uncomfortable question directly: was Dan Hughes's original consensus work abandoned, and is any of it left? The answer that formed was that Hyperscale is an evolution of Cerberus's principles adapted to the current implementation and to the goals of the Xi'an release, not a lift of the old Cerberus and Cassandra code. The original [Cerberus paper](https://assets.website-files.com/6053f7fca5bf627283b582c2/608811e3f5d21f235392fee1_Cerberus-Whitepaper-v1.01.pdf), the argument ran, begins from a static validator set and never engages the dynamic-membership problems that a live sharded network actually faces. A parallel thread argued slashing: whether provable byzantine actions such as double-voting should cost a validator its stake, and whether the honest form of that is impounding bonded stake for a fixed period, slashing the time value of the capital rather than the capital itself, with the impounding duration left as a governance knob. None of these are shipped decisions. They are the design being reasoned through where the reasoning can be checked. The developer also began drafting a writeup of Hyperscale's testing and verification setup for the Rust community, aimed at the r/rust and This Week in Rust audiences: the sans-io architecture that keeps protocol logic free of network plumbing, the deterministic simulator that replays a whole network from a seed, and the Quint models that let the consensus rules be machine-checked. The point of taking it there is the same as the point of the FAQ comparison. It puts the working in front of readers who did not come to be convinced. ## Doing the Governance Arithmetic in Public Last week the story was that the protocol's walls were nearly finished while the polity meant to govern it had not yet formed. This week the polity got a rough date. In discussion on the developer channel the Foundation stated that the DAO is expected to launch in around a month, followed by the establishment and KYC of the permanent [Accountability Council](/community/radix-accountability-council). A near-term timeline changes the register of every governance conversation from someday to soon. It also sharpened the interim's awkwardness into something concrete. The Foundation, now in maintenance mode with no marketing resource, spent part of the week working out who should run its social channels during the handover. The proposal was a narrow, vetted contract for a trusted returning contractor to publish community-submitted posts under Foundation guidelines, precisely because those accounts are Foundation property ultimately bound for the DAO and cannot be handed to an unvetted third party in the weeks before the transfer. It is a small question that exposes the shape of the larger one: an organization designed to dissolve still has to hold the keys until the body that replaces it exists. And the community argued the shape of that body in the open. A widely-shared sketch laid out a four-part model for the transition: a decentralized treasury that releases funds against milestone votes rather than in a lump; sub-DAOs that divide labour into specialised units so holders vote on leadership and budgets instead of micromanaging every line, which is the usual cure for voter apathy; legal wrappers along the lines of an unincorporated association so the DAO can sign real-world contracts such as exchange listings; and progressive decentralization across three phases, ending with the Foundation dissolving entirely. Running under it was a smaller, more immediate funding question: the volunteer who hosts Stokenet, Radix's public test network, cannot keep doing it unpaid forever, and put the matter of compensation and continuation up for a community vote. The [governance framework](/contents/tech/core-concepts/radix-governance) that will decide these is itself still in review. The difference this week is that the arithmetic was done where everyone could follow it. ## A Wallet That Signs More Than Transactions The week's clearest piece of shipped ecosystem work extended the wallet past payments. Radix Seal, released inside the community-built [genkipool console](https://radix-community.genkipool.com/seal), uses ROLA (Radix Off-Ledger Authentication, the scheme that lets a Radix wallet prove who holds it without a password) to do three things entirely in the browser: sign documents, encrypt files end to end, and hold a private peer-to-peer chat. Encryption keys are derived from a wallet signature, no server ever holds the content or the keys, and a signature can optionally be anchored as a soulbound NFT for an immutable audit trail. It is a concrete answer to a question ROLA has always implied but rarely demonstrated at this reach: what a wallet is good for once it is treated as an identity rather than a spending device. ## What's Taking Shape Next week tells whether the estimates hold: whether the DAO's month-out figure survives contact with the legal review still in front of it, and whether the sharding answers written down this week land any differently in front of the Rust audience they are about to meet. The reasoning is on the table either way. The rest is who reads it. ## Sources - [Vitalik Buterin – Sharding FAQ (2017)](https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html) - [hyperscale.rs – Hyperscale documentation](https://hyperscale.rs) - [Sharding: Questions Then. Answers Now. (X)](https://x.com/Gbyte691/status/2080289880228188256) - [Cerberus Whitepaper v1.01](https://assets.website-files.com/6053f7fca5bf627283b582c2/608811e3f5d21f235392fee1_Cerberus-Whitepaper-v1.01.pdf) - [Radix Seal – genkipool community console](https://radix-community.genkipool.com/seal) - [radix.wiki – hyperscale-rs](/contents/tech/research/hyperscale-rs) - [radix.wiki – Radix Governance](/contents/tech/core-concepts/radix-governance) - [radix.wiki – Radix Accountability Council](/community/radix-accountability-council)