hyperscale-vm

Introduction

hyperscale-vm is the execution engine being written for hyperscale-rs, the community-built sharded consensus layer that is the leading candidate to deliver Xi’an. An execution engine is the part of a node that runs smart contracts and works out how each transaction changes the ledger; on today's Babylon mainnet that part is the Radix Engine. The repository was created on 30 July 2026 by flightofthefox, the lead developer of hyperscale-rs, two days before he confirmed in the project channel that a new VM was "underway" in place of a sharding retrofit of the Radix Engine.

Its design rests on one idea, which its overview calls determinism-by-declaration: every node can work out which shards a transaction involves, which state it will read or write, whether it conflicts with other transactions and whether its fee is covered, all before running it. A sharded network needs that information up front to decide which shards must take part in a transaction and what to lock. Most smart-contract engines only discover it by executing the contract. hyperscale-rs consumes the engine as its vm/ git submodule, through 13 path crates.

Declaring access before execution

Every method a contract exposes carries an effect signature: a function from the method's arguments to the set of state entries (substates) it will touch and how it will touch each one. Signatures are written in a restricted language with no loops, no recursion, no arithmetic and no reads of state, so evaluating one costs time proportional to the size of the transaction and needs no engine, according to the design documents.

One function, route(), folds those signatures over a transaction manifest and returns the shards taking part, the entries each shard must handle and the call graph. Mempools schedule transactions on its output, proposers budget blocks on it, and wallets can show a user what a transaction will touch without simulating it. Nodes recompute the result themselves rather than trusting a copy carried in the transaction.

The kernel enforces the declaration by construction. It hands a contract a handle only for each entry the signature declared; an access to anything else has no handle to call and traps the same way on every node. The documents put the division of labour this way: "the compiler owes tightness, the gate owes soundness". A single publish gate, run both by local builds and by the network's admission check, refuses a package whose declarations do not match its code, so a package that builds locally has passed the same check the chain runs.

Access modes and parallel execution

Where most engines lock a whole object exclusively, hyperscale-vm declares each access in one of five modes, and two transactions touching the same entry can run side by side when their modes are compatible:

Mode	Meaning	Runs alongside
read	Read of current committed state	Other reads
locked	Read of state that can never change, such as package code or a resource's fixed configuration	Everything
delta	Increase or decrease a balance by an amount decided at run time	Other deltas and reserves
reserve(n)	Decrease that succeeds only if the committed balance, less earlier reservations, covers n	Deltas and other reserves
write	Exclusive read-modify-write	Nothing but locked

Because deposits are commutative deltas, the README's example is that a thousand deposits into one vault form a single parallel group rather than a queue. Deltas apply in an order fixed by transaction hash, and the design requires receipts to be byte-identical whether a batch runs serially, in parallel or in a deliberately shuffled order. The modes also cut cross-shard traffic: a shard only has to be sent what another shard must read, so a cross-shard leg made of deltas needs nothing sent in advance and can start immediately. Ranges of keys, such as the entries of an order book, can be declared with a cap on how many entries are read, which lets scans and order-book fills be declared and priced before they run.

Two engines, one profile

Contracts are core WebAssembly modules restricted to a deterministic subset: no floating point and no threads. Each module is metered by a pass that makes it count its own fuel, including the cost of copying data across the boundary with the host. The subset is executed by two independent engines: a version-pinned build of wasmtime, which nodes run, and a reference interpreter written separately as an executable specification. The two are tested against each other, and the README treats any divergence as a release blocker "whichever side is wrong".

Supporting several production engines is a stated non-goal: each protocol version names one engine version, and upgrades.md describes how moving that pin, the profile or the admitted contract toolchains is audited as a protocol event. The encoding used on the wire and in state is HBOR, a canonical, merkleized format defined in the same repository. The protocol's own packages, the account and the stake pool, ship as committed WebAssembly blobs in the stdlib crate.

Relationship to the Radix Engine and Scrypto

hyperscale-rs ran the real Radix Engine until August 2026 and moved onto hyperscale-vm after Milestone 1 closed. The lead developer's reason was that a sharded network has to know in advance which state a transaction will touch, and doing that for a general-purpose contract language is, in his words, "part of the motivation for a new VM". Babylon mainnet is unaffected and continues to run the Radix Engine.

The overview lists Scrypto and EVM compatibility among its non-goals, stating that its effect-typed interface cannot be expressed under either and that there will be no shim layer. Contracts are written against the repository's own sdk crate, which provides a #[blueprint] macro, and tested with a testing crate that runs a package against the real kernel under cargo test. In August the lead developer described moving an existing contract as "just a recompile" at best and an automatic transpiler at worst, and said the aim is to keep ideas such as manifests, resources, subintents and badges while replacing the layers beneath them.

Asked in the channel on 24 September how Babylon would move onto the new engine, the lead developer answered that all ledger data, accounts and assets included, would be transformed at genesis, and that developers might need to rebuild their contracts, which he expected to need some social coordination but not to be difficult. He said there is no point sizing the migration until the engine is closer to stable, and that building on Babylon in the meantime still makes sense, since most of a dApp's code is not contract code.

Status

The repository is marked "Work in progress. Do not use." All 1,218 commits on main to 24 September 2026 are by flightofthefox, and the last push was on 19 September. The invariant register (INV-VM-*) is written as the starting point for formal verification, and the overview names four properties to prove first: execution cannot leave its declared access set, value is conserved, no shard works for a fee payer who cannot pay, and receipts do not depend on execution timing. Progress is reported in the project's Telegram channel and its weekly digests.

External Links

• GitHub: hyperscalers/hyperscale-vm
• Architecture documentation
• GitHub: hyperscalers/hyperscale-rs
• hyperscale-rs on Telegram