In my last few posts, I’ve been measuring how long Rayls proofs take to compute. But for banks, there’s a more fundamental question: when has money truly arrived—and can no longer be taken back? This week, I changed direction and had GitHub’s servers monitor both Ethereum and the Rayls public chain for two hours, to see how they answer that question for themselves.
Here’s the short answer first. When banks say a payment has "arrived," they mean two things: it’s legally irrevocable, and it can’t be rolled back technically. On the technical side, Ethereum nodes mark a block as "finalized" 12.6 to 19.2 minutes after the latest block, with a median of 16 minutes. The Rayls public chain, by contrast, marks each block as finalized the moment it is produced, with a new block appearing roughly every 1.35 seconds. This kind of "deterministic finality" comes at a cost: if consensus can’t progress, the chain stops instead of forking. The Rayls public chain has stopped at least twice since launch—once for 11.72 hours and once for 9.15 hours. After both outages, it resumed directly from the block where it had stopped.
Two kinds of “finality”; banks need both
Principle 8 of the Principles for Financial Market Infrastructures (PFMI), published in 2012 by the Bank for International Settlements’ Committee on Payments and Market Infrastructures and the International Organization of Securities Commissions, says that financial market infrastructures should provide “clear and certain final settlement,” at least by the end of the value date and, where necessary, intraday or in real time. One key consideration is that the system rules must clearly define the point at which settlement becomes final. Article 5 of the EU’s 1998 Settlement Finality Directive takes the same approach: from the point defined by the system rules, neither participants nor third parties can revoke transfer orders.
This is legal finality, determined by rules and law. Technical finality asks a different question: can the block containing this transaction still be replaced?
Public blockchains fall into two categories here. Bitcoin has probabilistic finality: the more blocks added on top of a block, the less likely it is to be replaced, but that likelihood never reaches zero. That’s why exchanges say to “wait for a certain number of confirmations.” Chains with deterministic finality use Byzantine fault-tolerant consensus: once enough validators have signed a block, it will not change. Ethereum today falls between these two models: the latest block may still be replaced; it is considered finalized only after validators have voted on a checkpoint.
These two kinds of finality need to be considered together because banks’ rules need a point in time they can specify. Deterministic finality provides that point: once the block is produced, it is final. Probabilistic finality only offers a process in which risk keeps decreasing.
How to reproduce the test
The test code is in the finality folder of the public hansonhan0520-lang/enygma-bench repository. It runs through GitHub Actions, and the results are automatically saved to the repository. This is my first hands-on test of finality; my earlier articles measured zero-knowledge proof computing power, so they do not overlap with this one.
The sampling script monitored both chains at the same time, for one hour per run, across two runs: once every 0.25 seconds for the Rayls public chain and once every second for Ethereum. Each time, a single batch request retrieved the “latest,” “safe,” and “finalized” blocks, ensuring all three readings were from the same moment. I recorded the block hash the first time each height appeared, then queried them all again at the end and once more a few hours later to see whether any blocks had been replaced.
The two sampling runs were Actions runs 40642493952 and 40649630038, from 06:12 to 08:22 UTC on October 28, 2026. Ethereum was queried through a PublicNode public node, and Rayls through its official public node, mainnet-rpc.rayls.com.
Ethereum: the node itself says to wait about 16 minutes
Over two hours, Ethereum produced 599 blocks, averaging about 12 seconds per block, with three missed slots. The node’s “finalized” block consistently lagged 62 to 95 blocks behind the latest block, equivalent to 12.6 to 19.2 minutes; the median was 16 minutes in both hours. The “safe” block lagged by 30 to 63 blocks.
This is consistent with what ethereum.org says: an Ethereum block is finalized after about 15 minutes, because validators need to vote across two epochs.
All 605 Ethereum blocks from those two hours were rechecked afterward, and not one had been replaced. But that does not show that Ethereum never reorgs. Replacing a head block is rare to begin with, and a two-hour sample is too small to reveal how often it happens. The real difference between Ethereum and Rayls is what the nodes themselves are willing to commit to.
Rayls: a block is final as soon as it appears
On Rayls, over two hours, there were 27,788 queries, and every time the “finalized” block was the same as the latest block. The “safe” block matched, too. Blocks were produced every 1.35 seconds on average, with 5,325 heights observed. All were rechecked 0.3 to 1.4 hours after sampling ended, and not one hash had changed.
This result comes from the node’s design, not from chance. The Rayls public chain’s consensus client is called Axyl, and its code is public on GitHub. The public node reported version 1.4.1 (6909618), which matches the mainnet-v1.4.1 tag in the public repository. In this version’s execution flow, whenever the consensus layer submits a batch of results, the node first sets the executed block as the latest block, then calls finalize_block on the very next line, pointing both “finalized” and “safe” to that block. In other words, the node doesn’t wait to “see what happens after a few more blocks”; consensus commitment is finality.
There’s also a figure from an observer’s perspective: a Rayls block appears on the public node about 2 seconds after the timestamp embedded in the block. Ethereum is also around 2 seconds. Block timestamps are only precise to the second, so this figure is useful only as a rough indication.
The trade-off: stop rather than fork
The other side of deterministic finality is that the chain can only stop when consensus cannot make progress. Axyl’s own documentation puts it plainly: block ordering and finality require the currently active validators to be working properly. Without them, nothing gets committed.
I used binary search to find the longest gaps between blocks on-chain and found two outages. The first lasted 11.72 hours, from 21:59:32 on May 5, 2026, to 09:42:29 on May 6 (UTC). The second lasted 9.15 hours, from 01:05:33 to 10:14:47 on June 21. For both outages, the first block produced afterward had a parent hash that exactly matched the last block before the outage, indicating that the chain resumed from where it left off, with no fork and no replaced blocks.
There is an incident report for the second outage in the Axyl repository. During the transition into epoch 52, a batch of delayed transactions was built into the latest block but carried an older round number. The proposer interpreted this as a serious execution backlog and kept throttling, until all seven validators had stopped; restarting them did not help. The fix was commit 3a71a1a. The first outage is not documented in the public repository’s incident folder.
These are the longest gaps I found in each of the two date ranges. I did not scan the entire chain block by block, so I cannot rule out shorter pauses.
Block intervals changed twice
Looking back across the entire chain’s block-production history revealed another finding not mentioned in public materials. I sampled 61 evenly spaced segments from the genesis block to the present and calculated the average block interval for each. From the April 30 launch until around September 9, the interval was stable at 1.29 to 1.32 seconds, except for the two segments containing outages. From September 11 to October 5, it shortened to 0.69 to 0.70 seconds. After October 7, it returned to 1.33 to 1.38 seconds.
This explains an older figure. On September 12, I read an average block time of 568 milliseconds from a block explorer; that was during the faster period. Quoting that number today would be out of date.
I could not determine what caused the changes. The three public mainnet versions were released on July 27, August 25, and October 2, with no new version around the first change. There was a version released on October 2 a few days before the second change, but proximity in time does not mean it was the cause. The block-production parameters in the code are configured by the operator. The defaults are a maximum of 10 seconds and a minimum of 5 seconds between proposals; actual mainnet blocks are produced much faster than this default.
Also, Rayls’s claim of “sub-second finality” appears on the information page for its Sovereign institutional ledger. Sovereign and the public chain both use Axyl consensus, but they are deployed differently. I measured the public chain, so this figure neither confirms nor disproves the claim about Sovereign.
What this means for banks
This section is inference, not measurement.
First, deterministic finality lets the “point of finality” in the rules map directly to a block. The PFMI requires system rules to define when settlement becomes final. A block on the Rayls public chain is inherently such a point, while Ethereum takes about another fifteen minutes.
Second, banks need to ask more about availability. The UK’s CHAPS settlement hours are 06:00 to 18:00 on each business day. An outage lasting 9 to 12 hours could take up most of a settlement day. An outage does not undo transactions that have already settled, but no new settlements can be made. So when evaluating networks like this, in addition to finality, banks should ask about the frequency and duration of outages and the recovery process. These are operational resilience concerns for regulators.
Third, technical finality is not the same as legal finality. The fact that a block cannot be replaced is a technical one; when a transaction becomes legally irrevocable still depends on the system rules and the laws of the relevant jurisdiction.
What remains unresolved
I measured the Rayls public chain, not the Sovereign ledger and private-network hub used by banks in production. Near the end of the second sampling run, the official Rayls public node started returning “too many requests” (HTTP 429), indicating that it has rate limits; the Rayls readings for that run had already been saved, and the summary was recalculated from the raw data. According to Rayls materials, the hub still runs on a Besu proof-of-authority network, and the documentation also says that cross-institutional Enygma transactions take tens of seconds to reach finality. Neither of these was measured in this test. The observations came from just one public node and one GitHub runner. Seeing no Ethereum reorgs over two hours does not mean its reorg rate is negligible. I looked for the longest outage in each of two date ranges.
My take
On Ethereum, it takes about fifteen minutes before you can say a transaction has “arrived”; on the Rayls public chain, it counts as arrived as soon as the block is produced—and that’s what the node code says, too. But deterministic finality comes with a different kind of risk: stopping. The Rayls public chain has stopped at least twice in six months, each time for more than nine hours.
The test is simple to reproduce: anyone can run the finality and finality-halt workflows in the enygma-bench repository and check whether Rayls’s “finalized” block always matches the latest block, and whether any new long gaps have appeared on-chain. If Rayls publishes finality-time and availability data for Sovereign and the hub, the same method can be used to compare them.
References:
CPMI-IOSCO (Principles for Financial Market Infrastructures), Principle 8, April 16, 2012: https://www.bis.org/committees/cpmi/pfmi/overview
European Union (Settlement Finality Directive) 98/26/EC, May 19, 1998: https://legislation.gov.uk/eudr/1998/26/data.html
ethereum.org, Single slot finality (page updated July 23, 2026): https://ethereum.org/roadmap/single-slot-finality/
Axyl consensus client source code, tag mainnet-v1.4.1 (October 2, 2026); incident report doc/incidents/2026-06-21-mainnet-halt.md: https://github.com/raylsnetwork/axyl
Sampling code and all logs for this article, Actions runs 40642493952 and 40649630038, follow-up checks, and outage investigation (October 28, 2026): https://github.com/hansonhan0520-lang/enygma-bench
