Previously: flightofthefox had just rebuilt the network layer around iroh and given staking pools self-founding and handover paths.
A quiet, focused week: all sixteen changes landed in the new VM, the engine built from scratch that lets smart contracts run across shards. flightofthefox spent the week tightening how the engine reads shared state and how fees are burned, while the chat was dominated by the fallout of a big exchange hack.
+1.9k −384
-84% vs last wk
lines changed
Commits / day
peak 7/day · 3/7 days active
Momentum
Lines changed / week
last 8 weeks
What flightofthefox built
Keeping shared state honest
Most of the week went into rules for how a contract reads state handed over from another shard: every read must come from the exact piece that was served, never from somewhere stale. This is what makes identical execution — and thus atomic cross-shard payments — possible.
→ see “The Generals” on hyperscale.rsFees are burned, provably
The engine now tracks the fee burn alongside every state change, so destroyed fees are accounted for as rigorously as balances themselves. It matters because money vanishing without a record is exactly what an auditable network can't afford.
→ see “The Journey” on hyperscale.rsRandom draws respect the clock
New rules pin committee draws to randomness seeds from strictly earlier epochs, and fix the clock per transaction rather than per block. That keeps validator assignments unpredictable and fair — nobody can peek at seeds before choosing how to act.
→ see “The Lottery” on hyperscale.rsThe bottom line
Standout change
The new VM now enforces that contracts can only ever read the exact cross-shard state that was proven and served to them.
What's next
Likely next: more VM hardening around served-state reads and fee accounting, plus the hinted optimized networking design.
Heard in the chat
The mood: The chat was dominated by the Binance hack and whether Radix validators should block the stolen wallets; flightofthefox also held a lively Friday office-hours call.
“censorship resistance isn’t something you can just assume, it has to be worked on”
— flightofthefox, in the community Telegram
flightofthefox explained
Validators are sovereign
He explained there's no coordinated vote needed to block certain transactions — validators can individually decide what blocks to vote on, and he reminded them they are sovereign.
Governance baked into protocol
He said Hyperscale has its own governance and voting built into the protocol, because any DAO-style voting not aligned 1:1 with actual consensus powers is toothless.
Post-quantum is mandatory
Asked whether Hyperscale will be quantum-resistant, he answered that it's not worth releasing anything non-quantum.
Friday office hours
He set up a drop-in TGIF voice call open to anyone wanting to chat about Hyperscale, Radix, crypto, software or life in general.
This week's concept
The Generals— The two generals put down their messengersThe bulk of the work hardens the engine's reads of provisioned state, which is the bedrock of executing cross-shard transactions byte-identically on every shard.
hyperscale.rs/generals Jargon, decoded
Fee burn — Transaction fees that are permanently destroyed rather than paid to anyone.
Kernel — The VM's trusted core that contracts must go through to read or write any state.
Provisioned state — A piece of shard state shipped to another shard under a proof, so it can be verified rather than trusted.
Where the work landed
rules for reading served, proven state
fee burn carried with state changes
vm/docs
documenting the new VM rules
Reference — concept map, roadmap & links▾
The full picture
The ClockConsensus-attested time across independent shards.
The CensusThe leaderless beacon of validators, stake and shards.
The OverlapWhy two conflicting blocks can never both commit.
The GeneralsAll-or-nothing cross-shard commits, computed not voted.
The ArchiveEvery published byte is preserved or provably expired.
The LibraryAll state in one merkle tree; a shard is a subtree.
The WillHow in-flight transactions settle when a shard dies.
The LotteryRandom, ever-moving committees; proven cheats are jailed.
The TriageUnder overload, urgent traffic never waits for bulk.
The GovernorValidator entry is re-priced every epoch, like a market.
The Crash LabThe simulator that replays any failure byte-for-byte.
The ProofProving safety with maths, not just tests.
The AsterisksEvery design's trade-offs — including Hyperscale's own.
The four parts
✓ done
Adaptive Sharding
Shards that split and merge on their own · Aug 2026
100%
The new VM
A new engine built from scratch so smart contracts run across shards
–
Indexing & APIs
So wallets and apps can read a sharded network
–
Validator tooling & testnet
Running a node, and a public test network
–
Foundations & reliability
Networking, storage, crypto and testing that every part stands on
Bars show this week's share of lines changed. Shared groundwork counts as Foundations & reliability. Since day one: 5,733 commits — one developer, fully in public.
Links
Questions? flightofthefox is always happy to discuss in the community Telegram.
Written by AI from public commits, the community chat and hyperscale.rs — may contain mistakes. · generated 2026-11-09