What I found when looking into Rayls’ consensus, settlement architecture, and transaction receipts.
I started with a simple question:
If a blockchain promises sub-second finality, does that mean the entire transaction is completed in less than a second?
At first, the answer might seem obvious. A transaction gets confirmed, the network reaches consensus, and the operation is finished.
But financial infrastructure is more complicated than that.
A transaction can be committed on one ledger while a larger operation still depends on another ledger, a relayer, proof verification, or execution on the destination side.
While researching Rayls, I found that understanding its finality claims requires looking beyond the headline speed numbers.
The key is knowing which Rayls environment handles the transaction, what event counts as final, and whether the claim covers the entire workflow or only one stage.
1. Finality and transaction completion are not the same thing
Think about a transfer between two financial institutions.
The sending institution records the instruction. The transaction is processed. The receiving institution may then need to validate and complete its side of the operation.
Calling the process “instant” can hide the fact that multiple steps are involved.
Blockchain systems have a similar distinction.
- Consensus finality: The network has agreed on a transaction’s position in its committed history.
- Execution: The transaction successfully applies its changes to the blockchain’s state.
- End-to-end completion: The intended operation has finished across all the systems involved.
These are related, but they are not interchangeable.
A transaction may be final on its source ledger without the entire cross-network workflow being complete.
That does not make the finality claim meaningless. It means we need to understand exactly what the claim measures.
2. Rayls has different transaction paths
Rayls is not simply one blockchain with one settlement mechanism. Its architecture includes multiple environments designed for different requirements.
Rayls Sovereign provides private ledgers for individual institutions.
Rayls Private Network connects Sovereign ledgers through a shared Private Network Hub.
Rayls Public Chain provides a public EVM-compatible environment.
According to Rayls’ "official architecture documentation" (https://docs.rayls.com/docs/rayls-high-level-architecture), the source of truth depends on the transaction path.
Transaction path - Source of truth
Within one Sovereign ledger - The institution’s ledger
Between Sovereign ledgers inside a Private Network - The Private Network Hub
Between Sovereign ledgers through the Public Chain - The Public Chain
This is an important distinction.
A transaction processed entirely within one institution’s ledger is not the same as a transaction that moves between institutions. A transaction involving the Public Chain follows another settlement path.
So instead of asking only, “How fast is Rayls?”, a more useful question is:
Which environment is settling this transaction, and what exactly has become final?
3. How does Axyl support finality?
Rayls uses Axyl as the consensus mechanism for its Public Chain. Its documentation also says Axyl was adopted by Rayls Sovereign in July 2026, replacing Clique proof of authority.
However, the Private Network Hub still uses Hyperledger Besu proof of authority for now.
That means Axyl should not be described as the consensus mechanism for every Rayls environment.
Its design is worth understanding because it separates several responsibilities.
Narwhal: Making data available
Axyl uses Narwhal to organise transaction batches into a directed acyclic graph, or DAG.
Rather than treating transaction data as something that must always be produced sequentially by one participant, this design supports parallel data dissemination.
The goal is to make the relevant transaction data available to the validators.
Bullshark: Agreeing on order
Making data available is not enough. The network also needs to agree on the order in which transactions are committed.
Bullshark processes the DAG and establishes a consistent ordering under the protocol’s consensus rules.
The design uses Byzantine fault-tolerant consensus assumptions to help honest validators agree on a consistent history, even if some participants behave incorrectly or become unavailable within the protocol’s fault limits.
Reth: Executing transactions
Once the transaction order has been established, Reth handles EVM execution.
This is where another important distinction appears.
A transaction can be submitted to a network but still fail to execute successfully. Consensus and execution serve different purposes: one establishes the agreed order, while the other applies valid transactions to the EVM state.
That difference becomes particularly relevant when developers check transaction receipts.
Sources: "Rayls Axyl overview" (https://docs.rayls.com/docs/meet-axyl-the-consensus-behind-rayls) and "Axyl technical documentation" (https://docs.rayls.com/docs/about-the-axyl-consensus-algorithm).
4. The detail that caught my attention: transactions without receipts
While reading the Axyl documentation, I found a developer-facing caveat that deserves attention.
The documentation explains that invalid transactions can be skipped without producing a receipt.
Examples include transactions with a bad signature, insufficient balance, a mismatched nonce, or a duplicate transaction.
It also notes that the Public Chain does not expose a public mempool.
Why does this matter?
Developers often expect a submitted transaction to remain pending until it is confirmed or reverted. But if an invalid transaction is skipped without a receipt, an application cannot safely assume that the transaction is simply waiting to be included.
For a wallet or payment application, this creates an important user-experience challenge.
What should the interface display if the user submitted a transaction but no receipt appears?
Should it keep showing “pending”? Should it retry? How can it avoid confusing an unsuccessful submission with a transaction that has already completed?
The documentation recommends tracking submissions, retaining transaction hashes, polling for receipts, and treating the absence of a receipt after a reasonable timeout as a possible dropped transaction.
This is a useful lesson:
Finality is a consensus property, but handling transaction status is also an application-design responsibility.
A fast consensus mechanism does not remove the need for robust error handling.
5. What happens when a transaction moves between institutions?
Rayls’ Private Network Hub adds another layer to the discussion.
According to the "official Hub documentation" (https://docs.rayls.com/docs/private-network-hub), the Hub helps coordinate transactions between Sovereign ledgers and validates cryptographic proofs associated with those transactions.
The documentation describes two relevant mechanisms:
- Time-based state commits, which publish block-header information from a Sovereign ledger to the Hub periodically.
- Transaction proofs, which are submitted by the participating Sovereign ledgers and checked against the relevant state information.
The Hub also supports batching, allowing thousands of transactions to be grouped into one Hub transaction.
Rayls states that a Private Network can support 15,000+ transactions per second with sub-second finality, depending on configuration and transaction type.
That qualification matters.
A throughput figure does not automatically tell us how quickly every individual payment completes. Nor does the finality of a transaction committed to one environment prove that every subsequent step across another environment has already finished.
For a serious evaluation, I would separate three measurements:
1. Consensus latency: How long does it take to commit a transaction?
2. Execution latency: How long does it take to apply the transaction successfully?
3. End-to-end latency: How long does the complete operation take across the systems involved?
These measurements answer different questions.
6. Does sub-second finality prove every transaction finishes in under a second?
Not by itself.
Rayls’ official documentation describes Axyl as providing deterministic sub-second finality and documents performance claims of 15,000+ transactions per second.
Those claims are useful starting points. But understanding the design and independently verifying production performance are two different tasks.
For this article, I reviewed the published Rayls architecture, consensus, and Private Network Hub documentation. I did not run a production benchmark or independently verify the throughput figures.
A reproducible benchmark would need to specify the environment, transaction types, workload, test duration, and the exact point at which latency is measured.
I would also want to know:
- Is the measurement from submission to consensus commit, or from submission to successful execution?
- Does it measure a local transaction or a cross-ledger operation?
- Is the result a best-case figure, an average, or a tail-latency measurement?
- What happens when validators become unavailable or transactions are invalid?
- For cross-network workflows, does the measurement stop at source finality or wait for destination-side completion?
Without those details, a headline number cannot answer every operational question.
This does not mean Rayls’ claims are false. It means we should avoid interpreting a specific finality guarantee as a universal promise about every transaction path.
7. What should developers check before relying on a finality claim?
If I were evaluating blockchain infrastructure for financial applications, I would start with five questions.
1. Which environment is authoritative?
Identify whether the operation settles on Sovereign, the Private Network Hub, or the Public Chain.
2. What does “final” mean in this context?
Does the application need a committed transaction, successful execution, or completion across multiple systems?
3. What happens when no receipt arrives?
Understand how invalid, skipped, or dropped transactions are handled before designing the interface.
4. How does the application handle uncertainty?
Track transaction hashes, use sensible timeouts, and avoid blindly retrying operations that may already have succeeded.
5. Can the performance claim be independently reproduced?
Look for a defined environment, workload, measurement method, and latency statistics.
These are not questions unique to Rayls. They are useful when evaluating any blockchain that promises fast settlement.
Final thoughts
I started this research expecting to find a straightforward answer about transaction speed.
Instead, the more useful finding was that finality depends on the transaction path and the environment where settlement occurs.
Rayls documents Axyl for the Public Chain and Sovereign, while the Private Network Hub currently uses Besu proof of authority. The Hub has its own validation and batching model, and the Axyl documentation highlights a practical issue around invalid transactions that do not produce receipts.
The important distinction is between a transaction becoming final on a particular ledger and the entire intended operation completing across all the systems involved.
For financial infrastructure, speed matters. But speed alone does not define settlement quality.
The questions I would keep asking are simple:
Where did the transaction settle? What exactly became final? And what evidence confirms that the intended operation completed?
Those questions tell us much more than a speed number on its own.
Official sources
- "Rayls High-Level Architecture" (https://docs.rayls.com/docs/rayls-high-level-architecture)
- "Meet Axyl: The Consensus Behind Rayls" (https://docs.rayls.com/docs/meet-axyl-the-consensus-behind-rayls)
- "Axyl Technical Specifications" (https://docs.rayls.com/docs/about-the-axyl-consensus-algorithm)
- "Rayls Private Network Hub" ( https://docs.rayls.com/docs/private-network-hub )
- "A Warm Introduction to Rayls Sovereign" (https://docs.rayls.com/docs/a-warm-introduction-rayls-sovereign)
- "A Warm Introduction to the Rayls Public Chain" (https://docs.rayls.com/docs/a-warm-intro-do-rayls-public-chain)
Research note: This article analyses Rayls’ published technical documentation. It is not an independent production benchmark.