Releasing RBFT

When we designed Rayls, we knew one thing from day one: institutions need choice.

Rayls was built to connect private institutional workflows to public liquidity through a unified EVM stack across Privacy Nodes, Private Networks, and the Public Chain. That architecture needs deterministic finality, high throughput, and strong operational reliability. To deliver that, we decided to invest in a new L1, but existing EVM consensus algorithms could not deliver all the necessary requirements, so we decided to create our own consensus algorithm.

In fact, we decided to go for the dual strategy and create two new EVM consensus algorithms in-house. Both using Reth (the Rust Ethereum client) as the execution base for maximum performance.

This article introduces the first one of the new consensus created by Rayls called RBFT (Rayls Byzantine Fault Tolerant) protocol that we are opening to the community, and tells the story of how we built it in parallel with the second consensus algorithm called Axyl. Then dives into how we decided which to launch Rayls with, en route to our broader multi-consensus roadmap.

RBFT Technical Brief

RBFT is a Byzantine fault tolerant consensus client based on QBFT principles and implemented over a Reth execution layer.

For each block height, the protocol selects a proposer that suggests the next block, and the validator set coordinates around that proposal through successive voting phases.

In normal operation, validators first validate the proposed block and then exchange votes to confirm agreement on the same block content. Once quorum is reached, the block is finalised and the network advances to the next height. This gives deterministic finality, which is a core requirement for Rayls use cases where settlement certainty matters.

When a proposer is slow or unavailable, RBFT moves to a new round with a different proposer rather than stalling the chain. This round-change behaviour preserves liveness under adverse conditions while still enforcing quorum-based safety.

In practice, RBFT gives Rayls a production-grade consensus path that balances fast finalisation, resilience, and operational control.

Why Rayls Built Two Consensus Clients

From the beginning, our vision was not a single-consensus network. We wanted Rayls users to eventually be able to choose the consensus mechanism that best fits their requirements.

For example, some of our institutional clients are already working with Hyperledger Besu which implemented QBFT and as such already have a validator strategy and requirements. In those cases it would be beneficial for clients to migrate to Rayls using RBFT, for minimal disruption and replanning required.

With that in mind, we adopted Reth as the execution foundation for our blockchain, giving us a high-performance, modular, EVM-native base for building multiple consensus paths.

We started by assigning two separate teams to create solutions that could compete for Rayls usage, which turned out as:

RBFT
A QBFT-style Byzantine fault tolerant consensus written from scratch, with deterministic round-based finalization and Reth as its execution layer.

Axyl
A client derived from the Telcoin Network codebase, enhanced with major performance work, combining a Narwhal/Bullshark-style consensus layer with a Reth-compatible EVM execution pipeline.

Both were built to meet the same Rayls requirements: deterministic finality, fast and low-latency block production, and institutional-grade resilience.

Selecting the Initial Client

Before building true interchangeability, we had to select one consensus baseline for launch. Consensus sits at a core system boundary, so making it genuinely swappable requires additional compatibility layers, broader testing, and safe migration controls that were not yet in place.

So we opted to harden one path end to end first and later assess a move toward multi-consensus support.

After both implementations reached stability, we benchmarked them to make a launch decision based on production behaviour. We focused on the metrics that matter most for public L1 operations: throughput, latency, and stability under load.

Both clients performed well and proved operationally viable, but in our current benchmark profile, Axyl showed more maturity, performing better under stress and allowing a higher number of transactions per second, so we selected it as the initial consensus for launch of the Rayls L1 public chain.

What Comes Next

Rayls is an open-source company, and today, we are open-sourcing RBFT because transparency and composability are essential for institutional blockchain infrastructure. Open source creates a stronger base for independent review, community contribution, and clearer technical evaluation by institutions building on Rayls.

At the same time, our execution plan remains set. We will continue scaling Axyl as the initial core consensus path, while keeping open the possibility of a move toward multi-consensus support, so RBFT can be integrated into Rayls, where users see it as the better fit.

We are excited to share RBFT with the community and build that future in the open.

For anyone wanting to explore the code and contribute, start here: https://github.com/raylsnetwork/rbft

‍