Introduction
hyperscale-rs is a community-built Rust implementation of the Hyperscale consensus protocol for the Radix DLT ecosystem. The project's stated goal is to produce a viable Xi'an candidate — the next-generation sharded consensus layer that will enable Radix to become what its community describes as "the world's first linearly scalable Layer 1 network."
Led by flightofthefox of proven.network, the project was publicly announced with the opening of its source code and an invitation for community review and contribution. It is community-funded through a Radix donation address and represents an independent effort to improve upon the official reference implementation of Hyperscale.
Background: Hyperscale & Xi'an
Radix's long-term roadmap centres on achieving linear scalability — the ability to increase throughput proportionally by adding more shards to the network. The Hyperscale Alpha consensus mechanism (formerly known as Cassandra) represents Radix's approach to this problem, combining principles from Nakamoto consensus and classical Byzantine Fault Tolerant (BFT) protocols.
In public testing, the Hyperscale protocol sustained over 500,000 transactions per second with peaks exceeding 700,000 TPS across more than 590 participating nodes. Private testing demonstrated linear scaling at roughly 250,000 TPS on 64 shards and maintained the same per-shard throughput at 500,000 TPS on 128 shards.
The Xi'an production track will implement this hybrid consensus mechanism into a production network candidate, with an Alpha release targeted for early 2027. A significant portion of the Xi'an work involves reimplementing the stack entirely in Rust, moving away from Java and the hybrid nature of the current Babylon network.
Architecture
hyperscale-rs is architected as a pure consensus layer — deliberately containing no I/O, no locks, and no async code. This design decision enables deterministic simulation testing as a core design principle, allowing the entire consensus logic to be tested without non-determinism from network or disk operations.
Consensus Mechanism
The protocol uses a faster two-chain commit derived from HotStuff-2. The lead developer evaluated HotStuff-1 during the BFT module implementation but concluded that the theoretical latency improvement was not worth the added complexity — describing HotStuff-2 as being in the "Goldilocks zone."
Key consensus features include:
- Optimistic pipelining — proposers can submit new blocks immediately after quorum certificate (QC) formation, without waiting for the previous block to be fully committed
- One-round finality — BFT provides finality with no possibility of reorganisation after QC
- Cross-shard livelock prevention — enhanced mechanisms for detecting and resolving deadlocks across shards
- Two-phase commit for cross-shard atomicity, where a coordinator sends prepare messages, shards lock resources, then commit or abort
Fault Model
The system uses n = 3f+1 validators per shard, tolerating up to f Byzantine nodes, with a quorum requirement of 2f+1 votes for QC formation.
Radix Engine Integration
Unlike the reference implementation, hyperscale-rs integrates with the real Radix Engine for smart contract execution, providing actual transaction processing rather than simulated execution.
Crate Structure
The project is organised as a modular system of 15+ Rust crates, each handling a specific responsibility:
Core
- hyperscale-types — fundamental data structures: cryptographic hashes, blocks, votes, quorum certificates
- hyperscale-core — trait-based architecture foundation and state machines
- hyperscale-bft — Byzantine fault-tolerant consensus mechanics: block proposal, voting, view changes
Execution
- hyperscale-execution — transaction processing with two-phase commit coordination
- hyperscale-mempool — transaction pool administration and shard-specific queuing
- hyperscale-livelock — cross-shard deadlock detection and resolution
Infrastructure
- hyperscale-node — integrates all subsystems into a complete node
- hyperscale-production — networking via libp2p and persistence via RocksDB
Testing & Tooling
- hyperscale-simulator — deterministic simulation testing framework with configurable network conditions
- hyperscale-spammer — load generation utility for performance evaluation and benchmarking
Transaction Flow
The transaction lifecycle follows a 14-step pipeline from user submission to finality, spanning three phases:
Pre-Consensus (Steps 1–6)
A user signs a transaction externally, which is submitted via an RPC gateway. The node receives the raw bytes, converts them to internal events, and performs cross-shard analysis to determine which NodeIDs (components, resources, packages, accounts) are touched. Transactions enter shard-specific mempools; cross-shard transactions are propagated to all involved shards via libp2p Gossipsub.
BFT Consensus (Steps 7–11)
Proposer selection occurs deterministically per round (e.g., round-robin by validator identity). The proposer builds a block from mempool transactions. Validators authenticate the block and broadcast votes. A quorum certificate is formed when 2f+1 votes are collected — notably, the QC is not sent as a separate message but is formed by the next proposer from collected votes. The block is committed once the commit rule is satisfied.
Execution & Finality (Steps 12–14)
Committed transactions are executed per shard using the Radix Engine. Cross-shard coordination uses a two-phase commit protocol where the coordinator sends prepare messages, shards lock resources without visible state changes, then commit or abort with state applied in an agreed order. BFT provides one-round finality with no possibility of reorganisation.
Improvements Over Reference Implementation
According to the project's pinned announcement, hyperscale-rs aims to improve upon the official Hyperscale reference implementation in several areas:
- Better architected — modular crate structure replacing monolithic code
- Better documented — improved code documentation and community-contributed learning materials
- Better tested — deterministic simulation testing as a core design principle
- More modular and maintainable — ongoing refactoring work to break down what was described as "kitchen drawer" crates into more focused, understandable modules
- More closely aligned with production values — designed with real-world deployment in mind
- More observable — enhanced monitoring and debugging capabilities
- Significant upgrades to the consensus process — including the HotStuff-2 based approach
- Safety violation fixes — addresses serious safety violations identified in the reference implementation
- Real Radix Engine — uses the actual Radix Engine for smart contract execution rather than an alternative execution environment
The lead developer notes that the implementation may currently be slower in practice due to the overhead of fixing safety bugs and using the more resource-intensive real Radix Engine, but states that an apples-to-apples comparison would show faster performance.
Development & Community
hyperscale-rs is developed openly with an active Telegram community of 316 members. The project's development is tracked through automated GitHub commit notifications in the channel via a Kit-Watcher bot.
Key Contributors
- flightofthefox (proven.network) — lead developer and channel admin
- wizzl0r — channel owner, involved in PR reviews and testing infrastructure
- Radical — code reviewer, working through the codebase and contributing documentation on transaction flow
Current Development Focus
As of February 2026, active work includes refactoring runner crates to be more modular and accessible to newcomers. The project has identified a need for contributors with experience in Terraform, Infrastructure-as-Code (IaC), and cloud infrastructure to help with end-to-end testing.
Funding
The project is community-funded through a Radix donation address, with community members contributing voluntarily to support ongoing development.
Connect your wallet to join the discussion.