NurseeGabriel

Most Blockchain projects simply say Quote "we have processed millions of transactions"
That's right .. that's a key achievement but the question is HOW DO USERS KNOW whether those claims are true ? That is the problem!.
The question demands for an answer and the answer is the solution .This is where RAYLS comes in.
Now ..let's break it down
RAYLS through its innovative approach brought in Transparency model and proof of usage framework.But first, let's understand the concept of proof of usage brought by Rayls.
Proof of Usage by Rayls is an approach through which it displays objective data of ecosystem activities.. "Objective" means that they are measurable. It can also be defined as transparency mechanism that captures transaction fee data generated within Rayls Privacy Nodes and Private Networks, then posts verifiable cryptographic proofs to the Rayls Public Chain.
The actual place where Rayls publishes these objective ecosystem metrics such as transaction volumes, network usage statistics, fees generated, and token burn information is THE TRANSPARENCY PORTAL .
The aim is to make network activity observable rather than relying solely on claims without proof.
Rayls does not say .. we have the numbers or we have processed numerous of transactions..and add Trust us ..
No
They actually have a portal where u can see and verify facts and figures.You may be wondering why transparency portal is needed at this stage ...
Here is the fact.
For so long .. Blockchain has a problem which includes where projects claims that they have millions of users, massive adoption, high transaction volumes but if u check closely You will find out that most numbers attached to the claims are inflated, statistics can't be verified.
This shouldn't work this way ..
Proof matters and that's why Rayls transparency portal is the ultimate solution to this problem. The problem are inability of the users to evaluate and verify ecosystem growth, institutions can't get adoption, token holders or users can't even understand the framework and Users may entirely depend on Feeds.
The portal created by Rayls allows users, validators and beyond to understand the framework, network or ecosystem activity, Revenue generation and Ecosystem usage And Fact remains that with this approach
There is connection between Usage, Revenue and tokenomics.
Here is Rayls data so far ..this will help you to understand what proof of usage by Rayls looks like and how Transparency portal presents them to you.
→ $1M+ cumulative revenue generated from Private Chains
→ 4 active Privacy Nodes operated by financial institutions. These nodes are ✅ Nuclea: is a Brazilian financial market infrastructure and clearing house.✅Nimofast: they deal on cross boarder payments and remittance.✅caixa: this is one of the largest Brazils state-owned banks.✅Xp: the Leading Brazilian investment and brokerage firm
→ 38M+ $RLS already burned(actual figure is at 48,247,458.88 $RLS )
Every fee generated by Private Chains contributes back to the network:
→ 50% is used to buy back and permanently burn $RLS
→ 50% supports long-term ecosystem growth
And 10% of the foundations monthly token unlocks
In further breakdown, private chain fees passed back to Rayls foundation amounts a total of $72,000 which is an advantage up to 20% increase. Private Chain allows financial institutions securely transact on-premise using Rayls high-performant blockchain technology, which can further utilise private Rayls Enygma transactions. Fee data from these networks is captured and proven on the Public Chain via Proof of Usage.
To verify figures ...use this on etherscan 👇
0x8C377e6d86285B195CA55d165305156024B246c2
https://transparency.rayls.com/
Public Chain: this is the public, permissionless layer of the Rayls ecosystem which has been live since 30 April 2026 . it is where activity is settled and value is locked.
Public Chain TVL: as currently is at $298,192
Total Public Chain transaction volume: $6,828,318 which is better growth reading +274.2%
Total transaction amounts to 193,529 total
Average Transaction Cost is at $0.00264
Total validators is 7 while total wallets is 1,599
In $RLS : Staked $RLS (% of True Circulating supply which is 1,661,185,076.92 $RLS ) is 5.9%
Circulating supply: 2,035,085,873.79 $RLS
True Circulating supply: 1,661,185,076.92 $RLS
Fully Diluted Valuation (FDV): $20,880,572
Number of Holders is at 51,394
Total (same as Max) Supply is at 9,951,752,541.12 $RLS
Total $RLS Staked is 97,302,346.42 $RLS
Official Smart Contracts are as follows
Ethereum:Mainnet: 0xB5F7b021a78f470d31D762C1DDA05ea549904fbd
BNB Chain:BSC: 0x17ea10b6ae4fde59fdbf471bd28ab9710f508816
Rayls: Rayls Chain: 0x07e17E17e17E17e17e17e17E17E17E17E17e17EA
However let's take a look into one project that has claimed tens of millions of users over the years
Pi Network , many users have questioned the gap between this claimed number of users and observable on chain activity. This has raised concerns about transparency around ecosystem growth and metrics. There is no dedicated public transparency dashboard that connects usage, revenue generation, tokenomics and network activity in one place. Another project such as BlockDag has also this particular area of concern because users raised criticism too regarding verifiability of its fundraising and ecosystem claims. Users have raised questions regarding the verifiability of the ecosystem and adoption metrics."
The same way some Defi projects on Ethereum network as of 2025 claimed strong growth and TVL figures but users found out that Some TVL calculations have been criticized for relying on methodologies that can result in double counting or make independent verification difficult.
Furthermore,
Let's say for an instance
If Users can utilise private networks, public chain services and applications built on Rayls .That's practical usage.This brings it down to the ecosystem generating transaction fees and these fees contribute to token Burns according to tokenomics And Then validators gets reward
This becomes a sequence, measurable which makes everything becomes interconnected
Let's take a clear example.Imagine two Restaurants (Resta X and Resta Y)
Resta X claims they have mass number of customers and they are selling off big quantity of food which means they are successful .. without any tangible customer numbers, Revenue figures and number of sales . While Resta Y claims the same thing with an accurate figures and numbers which indicates daily customers , number of customers, monthly revenues and growth statistics..
Which one of them seems to be more trustworthy.
Resta Y right, that's because they provided figures, numbers which aligns with the daily customers and monthly revenue.
One thing interesting pertaining to Blockchain Transparency is that it does not stop at transaction visibility. Economy transparency is also required at the institutional adoption.knowing that a network processing transaction is useful however comprehending whether that activity brings it to sustainable ecosystem growth may even be significant and essential. Proof of usage brings closer measurable adoption. It shifts away the discussion from speculation.. rather than asking whether a project will succeed one day, builders can begin asking whether people are using it today.
Transparency becomes meaningful when people can observe how a network is being used.
@Rayls

Blockchain Adoption by banks and other financial institutions picks another restructuring
Here is why
The challenges of Blockchain adoption today by Banks and other regulated financial institutions Is PRIVACY.
While Blockchain maintains it's conventional style of transparency and immutability ...the said banks and other financial institutions face challenges on protection of customers information, data and compliance with regulations. Privacy Is not about hiding everything but is all about Showing only what needs to be shown to only those who need to see it.
The financial institutions need to fix the privacy exposure so that they can protect the sensitive data, information of the customers and other vital confidential business data.
So with these challenges
It will be discouraging for the financial institutions to adopt Blockchain right
Yeah!
This is why RAYLS invented Enygma to fix the loophole
For instance:
Imagine sending money through a transparent envelope. Everyone can see how much money is inside and who is receiving it. Enygma fixes that transparent envelope with an encrypted box or wallet. Only authorized people can open it and access it.
But here is the main slack,👇
Privacy can't just be addressed while transparency, auditability and efficiency that helps regulate financial institutions are left behind,
Do you know why?
It is because auditability helps regulators to adequately perform oversight. And control transparency is needed also ..they are all part of the process.
This gives us second reason why RAYLS choose Enygma because what Enygma does is to provide private, auditable, programmable and compliant transactions
Enygma fixes this problem by combining 3 different technological solutions and these technologies work on different aspects
Enygma selectively placed each on where they will serve better
These technologies includes
Zero-Knowledge Proofs (ZK), Fully Homomorphic Encryption (FHE), and Trusted Execution Environments (TEEs)
This serves better and they are not competitors
ZK proves correctness without revealing secrets.(This also allows one party to prove that a statement is correct 💯 without exposing the details or data behind the statement) Imagine entering a VIP event , instead of showing your passport, ID card that reveals your details and private information ..you just have to present a cryptographic proof like a ticket which indicates that U are an authorised member. They will allow u in .. nothing else is exposed.
So with ZK
Transactions can be verified as valid without revealing confidential transaction details.
FHE performs computations without exposing data. With this ..you don't need to prove validity by revealing vital confidential information.(The analysis will carry on while the data is encrypted..only the authorized recipient decrypts the data)
TEEs protect sensitive execution environments while maintaining high performance.(They rely on hardware security unlike ZK )
But here is the main Reason why ZK is heightened at the transaction layer
.. Transparency and auditability needs to work together and With ZK it happens because
Transaction validity can be proven without exposing confidential financial information.
Participants know the transaction is legitimate without seeing every underlying detail.
So
This supports both privacy and auditability.
Enygma is the best key player because it allows financial institutions to use blockchain technology without facing the challenges anymore.
Now Adoption is growing and Rayls is behind the growth
@Rayls

Testing Rayls Sovereign's Zero Base Fee Claim Against EIP-1559
Brief answer
I wanted to know whether Rayls Sovereign’s documented gasless configuration keeps the base fee at zero indefinitely. Under the standard EIP-1559 calculation and parameters tested here, an above-target parent block makes the child base fee 1 wei, and subsequent empty blocks do not restore zero. A zero-priced transaction then fails the base-fee requirement. I have not established that production Sovereign uses that calculation and parameter set.
Axyl's execution code adds an important detail. The production fee-resolution path calls "compute_next_base_fee" when EIP-1559 is active. That function calls "calc_next_block_base_fee" and clamps the result to a configurable minimum using ".max(self.min_base_fee)". The chain-spec wrapper defaults this floor to "MIN_RAYLS_PROTOCOL_BASE_FEE", although its builder allows a different value.
The Sovereign documentation says gasless mode uses a zero floor, but I have not yet traced that setting to the production configuration or verified the underlying calculation function's implementation in this code path. A reader-run measurement of the public chain still points away from the bare per-block rule: its fee stayed at exactly 48 gwei across 300 near-empty blocks. My own tests cover the specification and the Alloy library's published vectors, not a running Axyl chain.
What I was trying to find out
Many institutions want a ledger where moving a token costs nothing. Free transactions remove the need to fund every employee wallet with a fee asset. They also remove the usual defense against spam, which is price. A gasless chain therefore has to explain how it stays gasless and how it stays usable.
Rayls Sovereign, the institution-run ledger, offers a gasless mode. The architecture page (modified 22 October 2026) says the mode is set at genesis and cannot change afterwards. It gives its reason in one sentence: because the EIP-1559 base-fee change is proportional to the parent base fee, a zero genesis fee and a zero floor "holds the base fee at zero indefinitely."
That is a mathematical claim, so I tried to check the mathematics.
The sentence rests on the word proportional. I went to the specification to see whether proportional is the whole rule.
The Axyl code shows why the configured floor matters. In "compute_next_base_fee", the current fee is taken from the parent header, falling back to "self.min_base_fee" if the parent has no base fee. When EIP-1559 is active, the code calls "calc_next_block_base_fee" and then applies ".max(self.min_base_fee)". Consequently, a zero minimum does not, by itself, prevent the calculation from returning 1 wei. Whether it does so depends on the underlying calculation and its parameters. The documentation's zero-floor explanation therefore needs to be assessed against both the calculation function and the actual gasless configuration.
Where the trail got complicated
Three Rayls statements about base fees need to be reconciled with the implementation. The Axyl Technical Specs (25 August 2026) say base fees are recalculated per block under the EIP-1559 rule, with its parameters recalibrated each epoch. The Axyl repository overview ("doc/index.md") says base fees remain constant within an epoch and are adjusted at epoch boundaries. The Why Rayls? page (24 August 2026) says fees are pegged to USDC.
The code adds a fourth piece of evidence: when EIP-1559 is active, "resolve_base_fee" calls "RaylsChainSpec::compute_next_base_fee", which calculates a next-block fee and applies a configurable minimum floor. This confirms that a per-block calculation path exists, but does not by itself establish whether epoch logic, a configured floor, or another setting determines the fee on a particular network. The gasless Sovereign configuration must be traced separately.
Per-block and epoch-constant updating require reconciliation if they describe the same mode and version. A USDC-denominated pricing objective could coexist with either. The inspected wrapper alone does not establish how these policies interact in gasless Sovereign.
What the specification says
EIP-1559 computes the next base fee from the parent block. The gas target is the block gas limit divided by an elasticity multiplier of 2. If the parent used exactly the target, the fee holds. If it used less, the fee falls by the parent fee times the shortfall, divided by the target and by 8. If it used more, the fee rises by the same expression, with a floor: the increase is at least 1 wei. The decrease has no such floor. A transaction is valid only if its max fee per gas is at least the block's base fee.
So proportional describes the decrease. The increase carries a one wei minimum that does not depend on the parent fee, and a zero parent fee is exactly the case where that minimum applies.
What I tested
I transcribed the update rule from the specification text into a short script and ran it from a zero base fee with an illustrative 100 million gas limit. Blocks at or below the target of 50 million keep the fee at 0. A block using the full 100 million moves it to 1 wei. After that, 1,000 empty blocks leave it at 1 wei, because the decrease on a 1 wei fee rounds down to nothing. A zero-priced transaction satisfies the base-fee pricing condition at base fee 0 and fails it at 1 wei. This comparison does not test its other validity requirements. From 1 wei, about 85 consecutive full blocks lift the cost of a 21,000-gas transfer past one gwei in total.
I then checked the script against code. The Axyl README says the execution layer is built on reth and alloy. In alloy-eips 2.5.0 (docs.rs, published 23 September 2026, linked under Sources at its pinned version), calc_next_block_base_fee adds the increase at lines 123 to 131 with a comment reading "Ensure a minimum increase of 1." The library's own test, calculate_base_fee_success at lines 207 to 237, includes a base fee of 0 with gas used above target producing 1, then 1 producing 2 and 2 producing 3. All ten vectors of that test are in the table below and in the script, which asserts each one and passes.
alloy-eips 2.5.0, src/eip1559/helpers.rs, test calculate_base_fee_success (elasticity 2, denominator 8)
# parent base fee gas used gas limit target next base fee branch
0 1,000,000,000 10,000,000 10,000,000 5,000,000 1,125,000,000 increase
1 1,000,000,000 10,000,000 12,000,000 6,000,000 1,083,333,333 increase
2 1,000,000,000 10,000,000 14,000,000 7,000,000 1,053,571,428 increase
3 1,072,671,875 9,000,000 10,000,000 5,000,000 1,179,939,062 increase
4 1,059,263,476 10,001,000 14,000,000 7,000,000 1,116,028,649 increase
5 1,049,238,967 0 2,000,000 1,000,000 918,084,097 decrease
6 1,049,238,967 10,000,000 18,000,000 9,000,000 1,063,811,730 increase
7 0 10,000,000 18,000,000 9,000,000 1 increase
8 1 10,000,000 18,000,000 9,000,000 2 increase
9 2 10,000,000 18,000,000 9,000,000 3 increase
One changelog entry touches this function. The alloy release notes list "fix(eip1559): prevent divide-by-zero in next base fee calculation" (pull request 3951) under v2.0.5, released 18 May 2026. The v2.5.0 notes, dated 23 September 2026, list no base-fee change, and the 2.5.0 source includes the fix. The pull request describes it as a defensive guard. In the source it is two early returns that hand back the parent base fee unchanged when the elasticity multiplier or the change denominator is zero, or when the gas limit is below the elasticity so the target rounds to zero, plus three regression tests at lines 367 to 387. It leaves the increase and decrease branches alone, so the one wei floor stands.
None of the ten vectors reaches the guard, because they use elasticity 2, denominator 8 and gas limits of at least 2,000,000, and the same test module repeats the 0, 1 and 2 inputs under four other parameter sets, each giving 1, 2 and 3. My script has no zero-parameter case and would raise a division error if the target were zero, where the library returns the parent fee.
Three limits apply to these results. First, I inspected Axyl's production fee-resolution path and chain-spec wrapper, but I have not verified the complete implementation of "calc_next_block_base_fee" or traced the gasless configuration to the code that constructs the production chain specification. Second, my simulation's 100 million gas limit is illustrative: I could not establish the Sovereign block gas limit or confirm its configured EIP-1559 parameters. Third, I have not run the calculation against a live Axyl node or verified the behavior of a running gasless Sovereign ledger
What the public chain adds
A reader ran a read-only script of mine against the Rayls public chain RPC (chain ID 72957, client version 1.4.1) it was a single run on 24th October 2026 at 2:10 am UTC. The public chain is not a gasless Sovereign ledger, so the result bears on Axyl's fee logic and says nothing directly about the gasless mode.
Across 300 blocks the base fee stayed at exactly 48 gwei, including across the boundary between epochs 176 and 177. The busiest block used 113,967 gas against a limit of 500,000,000, so every block sat far below the 250,000,000 target if the elasticity multiplier is 2. For an empty-block approximation starting at 48 gwei, using elasticity 2 and denominator 8, the standard rule falls below 1 gwei after 29 updates and eventually settles at 7 wei. This approximation is not a replay of the reader’s actual gas-use sequence. If the supplied consecutive-block records are accurate, they are inconsistent with the standard per-block update under elasticity 2 and denominator 8.
Several mechanisms could produce a constant fee, including epoch-based updating, a configured minimum or another custom policy. A library guard is relevant only if Axyl invokes that helper with triggering parameters; I established neither. These possibilities are not exhaustive. Epoch constancy alone would preserve zero within an epoch, not establish persistence across the boundary. The observed sequence therefore does not identify the Public Chain’s mechanism or determine Sovereign’s gasless behaviour.
The gas limit I could find
The one gas limit the Sovereign docs state belongs to a transaction.The execution code also shows that the next block's gas limit is taken from the canonical parent header, while the base fee is resolved separately through "gas::resolve_base_fee". This means the block's gas limit and the fee calculation are distinct inputs to block construction.
The Backend's fixed transaction gas limit of 5,000,000 must not be treated as the block gas limit or used to infer the EIP-1559 gas target.The Integrating Rayls Sovereign page (modified 6 October 2026) says the optional Backend builds every transaction with a fixed gas limit of 5,000,000 and takes the gas price from the chain's RPC. Neither that page nor the architecture page gives the block gas limit or the elasticity multiplier.
The Backend detail still matters. A Backend transaction asks the chain for its gas price, so it follows the fee wherever the fee goes. Two standard validity rules then apply. These are my reading of the usual rules, and no Rayls page states them. First, the transaction's max fee per gas must be at least the block's base fee, so a zero-priced transaction fails outright once the base fee is 1 wei, whatever the sender's balance.
Second, the sender's balance must cover the upfront cost, which is the gas limit times the max fee per gas plus any value transferred. For the Backend's 5,000,000 gas limit at 1 wei, that is at least 5,000,000 wei before any value, which a zero-balance account cannot meet even with a correctly priced transaction. Besu documents disabling a transaction-pool balance check in free-gas configuration. That admission setting does not itself establish that execution permits an otherwise unaffordable positive-fee transaction. I did not establish whether Axyl modifies either layer.
How Besu solves the same problem
Besu's free gas guide (retrieved 25 October 2026) treats gasless as a configuration. For a network on London or later, it says the operator must also enable zeroBaseFee on every node, set the minimum gas price to zero, and turn off the transaction pool balance check so zero-balance senders pass. It gives the reason: London introduced a non-zero base fee, which normally means transactions need gas.
The difference.
Besu turns the base fee off with an explicit switch and lists the other settings that must agree. The Rayls page relies on arithmetic and a floor parameter.
Why it matters.
Both configurations and formulas can be tested. Besu names an explicit free-gas switch; the reviewed Rayls explanation does not identify the additional behaviour needed to preserve zero under above-target load.
The trade off:
Besu needs every node configured identically, and it's guide warns that a node with a higher minimum gas price silently drops zero-price transactions.
Rayls documents gasless mode as fixed at genesis. Whether its implementation preserves zero under load and across epoch boundaries remains unverified.
What changes in practice.
A Besu operator audits a short checklist. A Rayls operator should inspect the applicable fee code and test a recorded gasless configuration under above-target load and across an epoch boundary before promising permanent gaslessness
Takeaway
The inspected wrapper applies a minimum to the calculated fee; setting that minimum to zero does not suppress a positive result. Standard EIP-1559 produces such a result after an above-target parent block. Rayls’ zero-forever explanation therefore requires an additional implementation or configuration justification. Whether production Sovereign provides it remains unverified. Completing the check requires a pinned source revision, the applicable helper and configuration, and tests under above-target load and across an epoch boundary.
@Rayls

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.
@Rayls

A private EVM is an Ethereum-compatible chain that is not the public Ethereum network: same bytecode, same Solidity contracts, same developer tooling, but run by an institution or a small group of them with the public excluded from reading it by default. Banks want this specifically so they can reuse a decade of audited smart-contract patterns and ordinary developer hiring without broadcasting every trade to competitors. That part is simple.
What sent me looking is a specific fact: the software Rayls' own Private Network Hub runs on, Hyperledger Besu, already ships a built-in way to do exactly this. Rayls builds something else instead. I wanted to know why.
Besu already has a privacy feature
Besu calls it private transactions, and the mechanism is specific. A sender's node passes the transaction to a paired Tessera node which encrypts it and distributes it point-to-point to the Tessera nodes of everyone else in the deal. Only a privacy marker transaction, a hash pointing at that off-chain exchange goes onto the actual cha$in. Besu's own documentation describes the result as two parallel systems: "the private transaction distributed to involved participants, and the privacy marker transaction (PMT) included on the public blockchain."
This is privacy by segregation: the content simply never reaches anyone outside the deal. It is the same category Rayls' own marketing materials, in earlier reporting on this platform, use to describe competing products.
Here is where it gets specific and dated.
The feature is being retired
Besu's own current documentation states it in nearly identical language across five separate pages: "Tessera-based privacy is deprecated in Besu version 24.12.0 and later." A standing warning, not a roadmap note repeated on the privacy overview, the private-transactions page, the processing page, the privacy-groups page, and the plugin page.
That deprecation traces to a specific, named announcement. The Besu Maintainers published it on 24 September 2024, titled "Sunsetting Tessera and Simplifying Besu," and gave a direct reason: Tessera is "not performant enough for their intended use cases." The same post pointed to the replacement path, app-layer privacy solutions built outside Besu's base client, as robust and performant enough that Besu no longer needed to maintain its own version.
Besu's own release notes record the feature's actual removal in version 25.6.0, released 4 June 2025, under the changelog line "Remove Tessera Privacy feature." Checked against independent release trackers, that is roughly eight months from announcement to removal, and almost exactly eight years and eight months after Quorum, Tessera's conceptual ancestor, first shipped. Current Besu releases have removed Tessera-based privacy entirely, past the point of mere discouragement.
There is a second older constraint worth knowing, because it bears directly on Rayls' own history. Besu's documentation has long warned against running private transactions in production on a consensus mechanism where forks occur, naming proof-of-work and Clique specifically, and labeled the combination an early-access feature as far back as Besu v1.4. Rayls' own Sovereign ledger ran on exactly that consensus, Clique, before its migration to Axyl in 2026. Had Rayls wanted Besu's native privacy on its old stack, Besu's own documentation would have told it not to run that combination in production.
Even setting the deprecation and the Clique warning aside, the architecture itself does not fit a growing institutional network well. Besu's privacy groups are fixed at creation. Its documentation is blunt about it: "Once created, you cannot change the members of a privacy group." Adding one commercial bank to an existing group means forming an entirely new group, and migrating whatever state the old one held.
Why banks wanted this category of product at all
The need predates Rayls by nearly a decade. J.P. Morgan unveiled Quorum in October 2016, a modified Go Ethereum client built to sit between fully private and fully public for derivatives and payments, according to Fortune's contemporary reporting. The design swapped private data for cryptographic hashes on a shared chain with one JPMorgan engineer describing the result at the time as "a clear separation between private and public." That is the same two-word problem a private EVM has always existed to solve: shared infrastructure, excluded public.
ConsenSys acquired Quorum from J.P. Morgan in August 2020, folding its development into what became ConsenSys Quorum, offered through two clients: GoQuorum and, increasingly, Besu itself. Tessera-based privacy is the direct descendant of that original 2016 design, the industry's first widely adopted answer to how a bank gets privacy on an EVM chain.
What Rayls built instead
Rayls' Enygma framework does not move private data off-chain at all. It keeps the data on the Hub, encrypted and wrapped in zero-knowledge proofs, verifiable by anyone who can read the chain without being readable by them. A Private Network Operator recovers institutions' view keys, encrypted to it during registration, and can read every transfer; participants hold separate spend keys that can authorise value movement but were never built to decrypt anyone else's. Adding a new institution means registering a new view key, not rebuilding a group.
I checked Rayls' own Hub, key-management, and Enygma documentation, specifically the pages describing the Besu-based Private Network Hub, for any mention of Tessera, privacy groups, or a privacy marker transaction, the vocabulary of the software that Hub actually runs. None of the pages reviewed use any of those terms. That absence sits across documentation that would be a natural place to mention it if Rayls were layering its privacy on top of Besu's native feature rather than replacing it, suggestive of building something separate, though an absence like this stops short of conclusive proof.
Rayls' public hackathon-starter repository also loaded directly, giving one more place to check. It documents the separate Reth-based Privacy Node layer rather than the Besu-based Hub, so it neither confirms nor rules out Tessera use at the Hub specifically. It's evidence about a different part of the stack.
There is also a measured cost to the feature Rayls appears to have skipped. An independent academic test of a live Besu-and-Tessera deployment, published on arXiv in 2025, recorded private contract deployment latency averaging above 5 seconds, with individual private function calls ranging from roughly 1 to over 6 seconds, attributed specifically to the encryption, off-chain payload distribution, and consensus coordination Tessera adds on top of ordinary Besu processing. That's measured, independent evidence that segregation-based privacy carries its own overhead, separate from and in addition to whatever overhead a cryptographic approach adds.
The question, and what the evidence actually supports
If Besu already has a built-in way to make transactions private, why would anyone running on Besu need a second, separate privacy layer?
Three separate facts, taken together, point the same direction. Besu's own maintainers announced the feature's retirement in September 2024 and finished removing it by June 2025, citing performance in their own words. Besu's own documentation discouraged the one consensus mechanism, Clique, that Rayls' own ledger ran on for most of its history. And the feature's static, re-creatable-only privacy groups were a structural mismatch for a network that Rayls' own documentation describes being built up one newly admitted institution at a time. Each of those three is a specific, dated mismatch between what Besu's native tool offered and what Rayls' own documented growth pattern needs.
Why this distinction matters in practice
An institution evaluating "do we need Rayls, or can we just run Besu with Tessera" is really asking two different questions that happen to share a vendor, and the second one has an answer with an expiration date on it. Besu's segregation model trusted node operators to keep data off the public record entirely and asked nothing more exotic of a developer than ordinary Ethereum tooling, exactly what Quorum promised banks in 2016, but that specific implementation no longer ships in a current Besu release.
Rayls' cryptographic model trusts math rather than operator discipline, lets a network grow by registering individual keys instead of rebuilding fixed groups, and runs on software whose maintainers completed the removal traced above eight months after announcing it.
This is a specific, dated answer to a specific question. Besu's own documentation is what actually explains why a chain running Besu would need something Besu does not fully offer anymore.
@Rayls

I set out to find one single fact: who can add a new bank to a Rayls Private Network. The first pass at an answer turned out to be right but incomplete and the missing piece was sitting on a page search engines don't index.
Rayls' general Sovereign overview, updated 17 September 2026, describes a Rayls Private Network as "permissioned, governed by participating institutions." Plural. Rayls' dedicated roles page by contrast, is unambiguous about who actually runs one: "The Operator is the authority of the Private Network. They install the Private Network and they alone hold the power to enforce governance."
Both pages are current. Neither links to or qualifies the other. Everything in this paragraph is Rayls describing its own system in prose which is a real source but still a claim made by the vendor about itself, not yet checked against anything that runs independently of that prose.
What the documentation says the Operator holds
The roles page states that authority in a dedicated warning callout, not buried in regular prose: only the Operator's own private key can execute updates to the Private Network Operator smart contract. One key, one party, flagged for emphasis.
Rayls' setup guide for adding a new participant names that key directly. The environment variable is PRIVATE_KEY_SYSTEM, described as the private key used for the Hub's contract deployment, "known to the Private Network Operator." The same guide's prerequisites require the governance contracts to already be deployed, by whoever held that key first before anyone else can be added. The roles page lists five governance methods that key unlocks: approving or rejecting member registration, approving or rejecting token registration, assigning member roles, freezing members, and querying the proof system that keeps the ledger consistent. None of the five is described anywhere in that documentation as requiring a vote among existing members. That is an absence I can confirm in the documentation I read; it is not, on its own, proof that no such mechanism could exist undocumented
What is independently checkable beyond the documentation
Prose can be rewritten without warning. Code, once deployed, is harder to quietly change, so it is worth asking whether any of this is verifiable at that level rather than taking Rayls' own description on trust.
One avenue is public. Rayls maintains an open-source repository, rayls-sovereign-contracts, which its own GitHub listing describes as covering "Privacy Nodes, a Private Network Hub, and privacy-preserving cross-chain messaging via Enygma," written in Solidity under the Apache 2.0 license with four listed contributors. Its existence is itself a fact worth having: the Hub's governance logic is implemented as smart contracts rather than as an internal backend policy a vendor could alter unilaterally and silently, which is a meaningfully different trust model from "the company says so." Confirming that in code, rather than in prose, means pulling the actual contract source and checking for an explicit Operator-only modifier the way the roles page describes it. That check is not completed here.
The repository is public, so it remains open for anyone who wants to run it directly, and nothing above should be read as a claim about what the code says, only about what the documentation says.
Testing it against Rayls' own worked example
Rayls publishes its own worked examples on a page marked noindex in its own metadata, meaning it will not surface in a search engine even though it is live, current documentation.
The first worked example is exactly the case worth testing: a central bank setting up a national CBDC network. Step one, in Rayls' own words, has the bank "assigns itself as the Private Network Operator, using its 'master' private key to deploy the governance smart contracts." Step three has that same bank approving its own minting node as Issuer. Step four assigns every commercial bank the lesser role of Participant, because the page states, only the central bank should be able to mint the currency in the first place. A second worked example, a tokenised bond exchange run by a platform registrar, follows an identical shape: the registrar installs the network, assigns itself Operator with its own master key, then approves each commercial bank afterward, one at a time.
Run the plural description through either case and it fails the same way both times. A central bank does not co-deploy its governance contract with the commercial banks it has not admitted yet, and a platform registrar does not ask the first bank's permission before approving the second.
Where the plural description does hold
Rayls' own examples do not stop at two, and the third is the one that complicates a clean verdict.
The same design-options page describes a third configuration: an NFT marketplace Private Network run by a decentralised autonomous organisation, where membership and token-registration decisions follow rules that governance token holders vote on, rather than a named institution's own discretion and where Rayls' own text states the design works without any single entity or individual holding control over what activity is permitted.
The mechanism documented in the first two examples stays intact here, as far as the documentation describes it. The Operator smart contract, the single deployment key, the member and token registries: nothing on the design-options page suggests those stop existing in the DAO case. Only one thing changes: who or what occupies the Operator position. That part is my own architectural reading, not a sentence Rayls' page states outright. The design-options page describes the outcome, a DAO voting on governance rules with no single entity in control, without spelling out the exact technical mechanism that seats a DAO in the Operator role. Given that the roles page describes no second pathway to Operator authority besides holding that one key, the most consistent reading is that a voting or multisig contract address sits where a central bank's own address sits in the first two examples.
Rayls' documentation does not say that in those words; it is the inference that fits the pieces that are documented. If that reading holds, the plural phrasing stops being loose marketing and becomes a reasonably fair description of that specific deployment, even though it isn't the shape either of Rayls' institutional examples takes.
That matters for how broadly the correction should be read. It would overstate the case to say Rayls' documentation never describes collective control; the DAO example shows it does, explicitly and by name. It would equally overstate the case to treat that example as representative of what Rayls builds for banks and central banks, which is the audience the brief's own worked example and this piece, set out to test.
Where this pattern shows up elsewhere
The same split between framing and mechanism shows up at other permissioned-ledger vendors, not just Rayls.
R3's Corda documentation uses an almost identical title for the default case: the Network Operator, who "onboards participants of a business network," per R3's own glossary. Corda's architecture docs name the mechanism under that title directly: "you need a certificate from the network operator to join." A certificate issued by one party, in Corda's standard deployment, not a vote recorded among existing ones.
Hyperledger Besu, the software Rayls recommends for running the Hub itself documents an identical default-to-exception structure inside one project. Its concepts pages describe permissioning as requiring a distributed network of trust among participants. Its how-to documentation is flatter: "only admin accounts can add or remove nodes from the permission list," and those admin addresses are set once, as a deployment parameter written into the network's genesis file, by whoever deploys the permissioning contract first. All three platforms default to one key in their standard documented deployment. Rayls' own third example is the clearest evidence here that a more distributed arrangement is possible by design elsewhere, built deliberately, when someone puts a voting mechanism into the Operator role instead of a single institution.
So which description is true
Both, pointed at different things.
The plural phrasing is accurate as a description of who a Rayls Private Network is for: institutions transacting with each other as opposed to a retail-facing public chain. By Rayls' own third worked example, it can also be an accurate description of a specific deployment, one where a DAO's vote, not a bank's treasury, sits behind the Operator's single key, on the architectural reading set out above.
In the two configurations Rayls documents as its primary institutional use cases, the central bank CBDC network and the tokenised asset exchange, that same phrasing describes the network's category rather than its control structure. Rayls' own wording for who holds control there is direct: the Operator holds that power alone. That sentence and the setup guide's environment variable live on two different pages, and connecting them, the authority named on one page and the specific key named on the other, is a reasonable reading rather than a quote Rayls has written as a single continuous claim. Nothing in either page or in the worked examples, suggests a different key or a second authority.
The practical test for an institution evaluating this, or any permissioned platform making a similar claim, is to skip the category language and find the worked example. Ask who is named in step one, whether every participant that follows is reacting to a decision that party already made by itself and, where the vendor publishes its source code, whether anyone has actually read the contract rather than the page describing it.
@Rayls