Split the work, not the world.
Every blockchain that shards for scale gives something up — atomic transactions, composability, or finality. Hyperscale is built on the position that none of those trade-offs are necessary. Add shards, get proportional throughput, and keep the semantics of a single chain.
Why sharding usually breaks things
A single chain has a hard ceiling: every validator re-executes every transaction, so adding validators adds security, never throughput. Sharding fixes that by splitting state and validators into parallel groups — but then a transaction touching two shards needs both to agree, and the known answers all compromise:
Shards mail each other
Cross-shard actions become multi-step sagas with user-visible half-done states. Your swap left one shard before it arrived at the other.
Execute now, apologize later
Run it and reconcile afterwards. Finality becomes "probably final," and contracts must survive being un-run.
Composability fenced off
Contracts only interact within their own shard. The ecosystem fragments into islands that need bridges.
Hyperscale's answer: a transaction declares the state it touches, every shard that owns any of it participates, and the transaction commits atomically on all of them or none — synchronous, composable, final.
How that's possible — and how the shard map itself grows and shrinks with demand — is the rest of the story.Three engines, one clock
Hyperscale runs three different consensus mechanisms, each shaped for its job, instead of forcing one protocol to do everything:
Shard chains order
Each shard is its own BFT chain (a HotStuff-2 derivative: rotating proposers, two-round commits, provably fork-free). Shards run concurrently and never wait on each other — this is where linear scaling comes from.
Execution certifies
Ordering a transaction and agreeing on its result are different problems. After a block commits, validators execute it and certify the outcomes with a second, lighter quorum. Splitting these apart is what lets a shard commit to running a cross-shard transaction before it can know the result.
The beacon coordinates
One deliberately slow chain — a block per epoch — tracks validators, stake, and the shard map. It never sees a transaction. Its one product: a schedule mapping any moment in time to the committee governing each shard.
The clock that glues it together is made of votes. Every quorum certificate carries the average of its voters' clock readings, clamped so it can never run backwards — a timestamp no minority of liars can meaningfully move, agreed as part of consensus itself.
Any artifact, from any shard, at any time, resolves to exactly one governing committee by looking up its attested timestamp in the schedule — computed one epoch ahead, so every honest node gets the identical answer. Dozens of unsynchronized chains, one unambiguous notion of "who's in charge right now."Cross-shard commits nobody votes on
Here's the trick at the heart of the system. A transaction touching shards 01 and 10 goes through three stages — provision, execute, certify — and at no point does anyone decide the outcome. Everyone computes it.
Provision. Each shard sends the others the state values the transaction needs — not as a message to be trusted, but as a merkle proof against its own committed, quorum-signed blocks. A provision is a verifiable fact about a chain, not a claim by a node.
Execute. Once a shard holds proven state from every counterparty, all participants have byte-identical inputs. Execution is deterministic, so they all compute the same receipts — independently, with no further communication.
Certify. Each shard's validators sign a certificate over the outcome. The transaction finalizes only when certificates from every participating shard, all agreeing on the same result hash, are assembled. Divergent certificates simply can never assemble into a valid commit — atomicity is enforced by the shape of the artifact, not by a coordinator. (The journey follows one payment through all four stages.)
If you're thinking "two-phase commit" — it isn't. There's no coordinator to crash, no votes that could go either way, and no blocking: outcomes are pure functions of what the chains committed, deadlines are attested on-chain time, and a stuck transaction aborts identically everywhere.
Deadlocks between transactions can't form either — the mempool never lets two in-flight transactions share any declared piece of state, and genuine cross-shard conflicts resolve by a deterministic tiebreak every shard computes the same way.A shard map that breathes
All state lives in one giant binary merkle tree, and a shard is simply a subtree — everything under one prefix. Objects owned by an account are keyed under that account's prefix, so ownership never straddles a boundary. That single design choice makes resharding almost embarrassingly clean:
The lifecycle is fully automatic. A shard whose state crosses a size threshold asserts a split in its own blocks — a claim every validator checks against their own copy before voting, so it can't be faked. The beacon then drafts fresh validators from the standby pool, they sync their half of the data while the old shard keeps running (make-before-break), and only when both child committees provably have a supermajority ready does the flip execute. Each child's genesis block is derived purely from the parent's final block — every node computes it independently and it must hash to exactly what the beacon recorded, or the flip refuses to happen. Merging is the same movie in reverse.
The hardest part: transactions caught in the boundary. What happens to a cross-shard transaction whose counterparty shard stops existing mid-flight?
The dying shard's final block fixes, forever, exactly which transactions it settled — and that "settled set" is attested into the beacon. Survivors enforce a fence: a caught transaction finalizes if and only if the departed shard settled it; everything else aborts, identically, everywhere. Verdicts come from frozen chain history — never from whether some message happened to arrive in time.A moving target for attackers
Sharding's classic weakness: corrupting one committee is much cheaper than corrupting the whole network. Hyperscale's defense is to make every committee a randomly drawn, constantly moving target:
Seeded assignment
Committees are sampled from on-chain randomness re-mixed every epoch. Nobody — including the adversary — knows placements far in advance.
Continuous shuffle
Membership rotates as a steady trickle, one seat at a time, so committees stay live while an adversary's slow corruption of any one shard keeps being dispersed.
Proven expulsion
Double-signing is self-proving evidence: permanent jail. Chronic offline behavior is witnessed on-chain — via proofs a block proposer cannot censor or forge — and jailed on threshold.
Between shards, no node is ever trusted — only quorums and proofs. A shard believes another shard's headers because they carry supermajority signatures under the right committee; it believes state because of merkle proofs into those headers; it believes results because of execution certificates. Every check resolves its committee through the attested clock, so there is never ambiguity about whose signatures count.
A thermostat for validator supply
An elastic shard map means elastic demand for validators — every split needs a fresh committee, every merge releases one. So the cost of activating a validator isn't fixed: the protocol prices it, every epoch, like a market.
Each epoch the beacon computes how many validators the topology needs — every committee, plus a standby buffer for shuffles, jailings, and the next split — and sets the activation stake at the marginal price where supply meets that target. Two guardrails: the price never rises past the point that would push out a sitting validator (repricing alone can never eject anyone), and it never falls below a hard floor, so buying influence always costs real stake.
The other half is vnodes: one machine can run many validator identities, sharing storage, execution, and networking — two seats on the same shard share one copy of the data and one execution of each transaction, and messages between co-hosted identities skip the network entirely. The marginal cost of a seat becomes its stake, not another server. That's deliberate: stake is the security parameter; hardware shouldn't be the bottleneck on an elastic validator supply.
Deterministic to the core
Everything above depends on different machines computing identical answers — and on rare, gnarly events (a shard splitting under load, a partition healing mid-transaction) being testable. So the entire protocol is written as pure state machines: no clocks, no threads, no network calls inside the logic. Time is an input. Randomness is an input. Every transition is a function.
The payoff is enormous: entire multi-shard networks — beacon, splits, merges, partitions, message loss, all of it — replay byte-for-byte from a random seed. A failure found once is reproducible forever with one command. The scariest code paths in any sharded system, the ones that fire once a month in production, are the most heavily exercised code in this repository. And the same determinism that makes tests reproducible is what makes replicas agree — it's one property doing both jobs.
