The short answer
I wanted to know what a bank gets when a chain advertises "deterministic sub-second finality," and which clock that second runs on. For Rayls' Axyl consensus, my reading gives a split answer. The design is a Byzantine fault tolerant protocol that can deliver deterministic finality: once the consensus layer commits a transaction, honest nodes agree on its place, as long as fewer than a third of the committee's voting power is faulty. I could not find a published definition of the moment a client may treat a transaction as final. I also could not read the benchmark figures behind "sub-second," because they sit in images.
The property is documented as design, and the speed is documented as a claim. Neither is verified by my own measurement.
Why settlement cares about finality
A settlement is a promise that a payment cannot be taken back. Both sides need a named moment after which they release goods, cash or the next leg of a trade. On a chain, the question is what stands behind that moment.
Ethereum's answer is explicit in the
ethereum.org
Gasper page (last updated 3 April 2026). A block is justified once two thirds of staked ether vote for it, and finalized once another justified block sits on top. Only epoch-boundary checkpoints qualify. After that, reversal requires an attacker to destroy at least a third of all staked ether. The
ethereum.org
block proposal page gives 12-second slots and 32-slot epochs (6.4 minutes), so two successive epochs come to 12.8 minutes. That figure is my arithmetic and the exact wait for a given transaction depends on where it lands in an epoch.
Finality here is a named state with a price tag. A bank can write it into a policy.
Rayls makes a different offer. Per the Rayls architecture page, its public chain has run on Axyl since mainnet launch on 30 April 2026, and a press release of 19 March 2026 had already promised instant finality on the Axyl testnet. That sounds better than 12.8 minutes. The useful question is what each number measures.
Dated versions of one claim
A GlobeNewswire release from Rayls dated 19 March 2026, which I read on FinTech Futures, says the team launched an updated public testnet powered by Axyl, with "sub-second block times, instant finality, 15k+ TPS" among its features.
A May 2026 mainnet launch release also carries a finality claim. I could only see an excerpt of it in a search result, because the page hosting it did not render, so this note does not rely on it.
The Rayls docs repeat the headline on several pages. Introducing the Rayls Public Chain (modified 25 August 2026) promises deterministic sub-second finality for "instant, irreversible settlement." Why Rayls? (24 August 2026) says Axyl delivers hard finality in under a second "with no risk of chain reorganisations." The architecture page (6 October 2026) dates Axyl on mainnet to 30 April 2026 and repeats 15,000+ TPS. None of them names the event the clock starts or stops on.
The Axyl pages give no latency figure, and the benchmark page (25 August 2026) records prototype consensus-layer results, as images, with four nodes, 512-byte transactions, 500 KB batches and a 50 ms batch delay.
Two first-party sources disagree on the headline number. The March release says 15k+ TPS, and the Axyl repository README, which I opened on 19 October 2026, says the protocol targets 10,000+ TPS. The same README reports a Halborn audit of the consensus protocol, with three assessments between February and March 2026 and remediation reviews in April and May.
I keep returning to that list. Block time is a duration, TPS is a rate and finality is a guarantee, yet the release sets them side by side as if they were one kind of number. Instant from what event? The release leaves that open, and the docs describe the machinery well enough to ask the question precisely.
What the docs say happens to a transaction
As Documented. The Axyl Technical Specs say transactions are not executed until the consensus layer has committed them. The October consensus page gives the commit rule: a leader commits once the next round's certificates carrying at least f+1 voting power reference it, and its history is then flattened into one deterministic order. Each batch in the committed sub-DAG becomes one EVM block, executed strictly one after another. A transaction found invalid at execution is skipped with no receipt and no fee, and there is no public mempool.
Verified by reading the code (nothing was run). In
bullshark.rs
on main, commit_leader sums the voting power of the next-round certificates whose headers reference the leader, and commits once that sum reaches the committee's validity threshold. The larger quorum is used elsewhere, for batch acknowledgements, header parents and certificates. The file elects one leader per even round and has no fallback-leader logic, which fits a partially synchronous reading of Bullshark, though I did not compare it with the paper line by line. One mismatch: the docs say the leader is checked two rounds back, while the code checks the round just before the certificate being inserted. I read it once, and the Rayls team(
@x10xalex
) should confirm which is current.
Finality in Axyl is therefore a consensus event, and the receipt is a later execution event. A transaction can be committed and then skipped, leaving nothing to look up. The docs tell dApps to keep their own transaction hashes and, after a timeout of "a few epochs," treat a missing receipt as a drop. The same page defines an epoch as 24 hours and lists a status endpoint as roadmap.
The Axyl repository's overview document (doc/index.md) adds two checkable details. The rayls_latestHeader endpoint returns the consensus chain tip, and each EVM block header carries the digest of the consensus header that produced it, with the epoch and round packed into the nonce field. A client can therefore tie an execution block to a committed round. Whether the standard finalized tag is wired to that commit is not stated in the files I read. The overview also keeps two committee records apart: the on-chain ConsensusRegistry contract, and the signed EpochRecord with its EpochCertificate, served by rayls_epochRecord, which syncing nodes verify.
The same overview contradicts the docs site on one point. The repository says base fees are constant within an epoch. The Technical Specs page says they move per block under the EIP-1559 rule, with only the rule's parameters recalibrated each epoch. Why Rayls? adds a third phrasing, base fees pegged to USDC. Reading baseFeePerGas across consecutive blocks settles it.
My analysis. Success may be final within a second while failure reaches certainty on a scale of days. A settlement system needs a clock for both outcomes.
The second condition is the committee, and here the docs disagree with each other. The Axyl page (6 October 2026) says each 24-hour epoch uses a fixed committee, every validator has voting power 1, and the Rayls Foundation operates the set at launch. Why Rayls Built an L1 (25 August 2026) calls the validators trusted financial institutions and says Axyl works "in a permissionless setting," while the architecture page says any institution can choose to run public-chain validators. I take the newest and most specific page, the Axyl one, as today's picture and the others as intent or roadmap. None of the pages gives a committee size or a slashing penalty like Gasper's one-third burn. So the promise of no chain reorganisations means no reorganisation unless validators holding a third of the voting power fail or collude, and on the Axyl page's account one operator runs them. The first half is documented. The second half is my reading.
Finality also varies by layer, and the same headline appears on three different stacks. The Rayls Sovereign page (17 September 2026) says Sovereign ledgers moved to Axyl in July 2026, replacing Clique proof of authority and a single Geth validator, while the Private Network Hub continues to run Besu with proof of authority. The Hub page (6 October 2026) is looser. It says the Hub can be any EVM platform, with Besu recommended, and it claims 15,000+ TPS with sub-second finality for a Private Network "depending on configuration and transaction types," reached by batching thousands of transactions into one Hub transaction. No Rayls page names the Besu mode.
Besu's own documentation (updated 13 October 2026) says QBFT and IBFT 2.0 have immediate finality and that Besu no longer supports Clique, so the mode decides whether Hub finality is immediate at all. The Hub page also says Sovereign ledgers publish their block headers to the Hub every few seconds, and transaction proofs are checked against those commits. A cross-ledger payment is therefore validated on a cadence of seconds, while inclusion on the Hub can be faster. I could not determine the end-to-end latency.
Reading the numbers
The benchmark setup matches the baseline in the Narwhal and Tusk paper (EuroSys 2022, arXiv 2105.11827 v4): four validators, 500 KB batches, 512-byte transactions. That match is my observation. The paper measured latency from client submission to commit by the leader, on a WAN across five AWS regions, and reports Narwhal-HotStuff above 130,000 tx/s at under two seconds. The Bullshark paper (arXiv 2201.05677 v3, September 2022) reports 125,000 tx/s at two seconds with 50 parties.
Independently verified (my arithmetic, standard-library Python; the script sits under Run it yourself). The batch parameters cap one worker near 19,500 tx/s, so 15,000 TPS of 512-byte payload, about 7.7 MB/s, fits at the consensus layer. The documented quorum, floor(2N/3)+1, keeps two quorums overlapping in at least f+1 nodes for every total voting power N from 4 to 300 (every validator has power 1 at launch, so N is the validator count), and it equals 2f+1 only when N = 3f+1. At N = 8, for example, the quorum is 6 while 2f+1 is 5. The documented validity threshold equals f+1 for every N in that range.
Execution is a separate measurement. The Narwhal authors wrote that high throughput helps only if an execution engine can match it, and deferred building one to future work. Axyl runs one batch per EVM block, sequentially. At 21,000 gas per simple transfer, 15,000 TPS means 315 million gas per second, and one full batch is 20.5 million gas. The pages I read state no block gas limit, so consensus-layer TPS and end-to-end TPS remain two figures.
A four-node lab committee and a 50-party WAN deployment cannot share a latency scale, so the paper figures give no check on Axyl's claim.
How Ethereum and the DAG papers differ
The difference. Ethereum finalizes checkpoints over two epochs and backs the result with a stake that can be destroyed. The DAG protocols behind Axyl commit leaders within rounds and rest safety on the faulty share of the committee staying under a third.
Rayls' own finality claim about Ethereum does not hold up as written. Why Rayls Built an L1 marks Ethereum L1 as lacking deterministic finality, while the Gasper page describes finalized checkpoints that cannot be reverted without destroying a third of the stake. Both pages are first-party, and they agree only if the table means sub-second and unconditional, which the page's own prose about sub-second deterministic finality suggests. On that reading Axyl's guarantee is conditional too, on fewer than a third of the voting power being faulty.
Why it matters. "Final" is backed by different things. On Ethereum it is an economic cost, and on Axyl at launch it is the integrity of one operator's validators.
The trade-off. Axyl's design buys speed and gives up, for now, the decentralization and slashing economics that make Ethereum's slower finality expensive to attack.
What changes in practice. An Ethereum integrator waits for the finalized state. An Axyl integrator first has to learn which signal marks commit, then track its own submissions, since failures leave no receipt.
Takeaway
Deterministic finality is a promise in two parts: a rule that fixes the order, and a reason to believe nobody can break the rule. Axyl documents the rule in detail. Commit needs f+1 support, and execution follows commit. The reason to believe rests today on one operator's committee, and the sub-second figure rests on benchmark images and a release that lists finality beside block time and TPS. A settlement team should ask three questions before relying on it: which signal marks commit, what happens to a transaction that is skipped, and who controls two thirds of the voting power.