Previously: flightofthefox had wired the fee and resource-pricing system end-to-end and unified the intent model, pushing deeper into Milestone 2's VM work.
Week 8 of Milestone 2 brought a deep, focused rebuild of how cross-shard transactions are tracked and resolved inside the VM. flightofthefox reworked the entire 'crossing' system — the machinery that lets a transaction spanning multiple shards record, answer, and clean up its commitments — while also tightening fee holds and pruning dead execution paths. In Telegram, a rich conversation about migration and compatibility showed the community engaging seriously with what Hyperscale would mean for existing Radix apps.
+3.1k −3.4k
-76% vs last wk
lines changed
Commits / day
peak 10/day · 7/7 days active
Momentum
Lines changed / week
last 8 weeks
What flightofthefox built
Cross-shard crossings rebuilt
Most of the week redesigned 'crossings' — how the VM tracks cross-shard transactions end to end. Crossings are now named once with all keys derived from that name, answers carry two verdicts, and blocks carry crossing records directly.
→ see “The Generals” on hyperscale.rsFee holds and vault deposits
Fee reservations are now treated as committed holds inside the kernel, and vault deposits moved from scattered jobs into a single kernel path — making resource handling cleaner and more predictable.
→ see “The Journey” on hyperscale.rsDead execution paths pruned
Several outdated job types and a crossing tombstone mechanism were removed entirely, replaced by simpler flag-based logic — less code to maintain, fewer edge cases to break.
→ see “The System” on hyperscale.rsThe bottom line
Standout change
The crossing system — how cross-shard transactions are named, tracked, answered, and cleaned up — was comprehensively rebuilt.
What's next
Likely next: continuing to refine the crossing system and tackling the local execution path flightofthefox flagged as a major challenge.
Heard in the chat
The mood: A lively week: a developer named Seböööl dove into the codebase and sparked a detailed exchange about migration, contract compatibility, and whether Babylon and Hyperscale can coexist.
“leg local execution is my vietnam”
— flightofthefox, in the community Telegram
flightofthefox explained
Migration path to Hyperscale
The rough plan is dump, transform, genesis — contracts rebuilt before launch if devs are active, stragglers upgraded later through beacon-chain voting with blueprints sitting disabled until then.
Component interaction design
Calls between components should work if the target is in immutable config or passed as an argument, but he wants to explore extending the manifest DAG at the call site rather than replicating Radix Engine's method dispatch.
Contract upgrades without proxies
He plans a native blueprint upgrade system so developers don't have to build proxy patterns, with upgrades coordinated through beacon-chain witnesses to apply consistently at the same epoch.
Why no public backlog
The foundation is still in flux, so maintaining a formal spec would slow things down — there is an order of operations, and it's too early to size the migration.
This week's concept
The Generals— The two generals put down their messengersThe dominant work this week was rebuilding how cross-shard transactions are tracked and resolved — the core of atomic cross-shard commitment.
hyperscale.rs/generals Jargon, decoded
Crossing — The VM's name for a cross-shard transaction's tracked lifecycle as state moves between shards.
Fee hold — The portion of a transaction's fee reserved upfront before it runs, so it cannot overspend.
Tombstone — A marker showing a cross-shard record has been retired and is safe to clean up later.
Where the work landed
crossing answers and state effects reworked
vault deposits, fee holds, crossing jobs
APIs updated for new crossing and fee model
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 road to mainnet
✓ M1
Adaptive Sharding
~4 mo
Now: Milestone 2 · Radix Engine — Week 8 · since August 2026. Since day one: 4,959 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-09-28