rayls

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.
#Rayls #Blockchain #Web3 #Consens #Finality

$RLS
While reviewing the Rayls Relayer code again, I noticed something odd.
If the Relayer is the one delivering messages, shouldn’t it also have RELAYER permission for "executeMessage()"?
But when I traced the actual code, that wasn’t the case.
Instead, Rayls separates the authority to deliver messages from the authority to actually execute them.
On the Public Chain, the first place the Relayer enters is "PublicRNEndpoint.receivePayload()".
Rather than executing the message directly here,

Blockchain gives financial institutions something they badly need: verifiable settlement without relying entirely on a closed database.
But there is an obvious problem.
Banks cannot simply put every transaction detail on a public blockchain.
Balances, counterparties, transaction amounts and other sensitive information may need to remain private - while regulators, counterparties and the network still need enough evidence to verify that something actually happened.
So how can you get privacy + verifiability at the same time?
This is where the architecture behind Rayls becomes interesting.
Start with a private transaction
Imagine a financial institution needs to transfer a tokenised asset internally.
The transaction needs to execute in a controlled environment where sensitive financial information isn't exposed publicly.
This is where the idea of a private execution environment becomes important.
Instead of starting with a public blockchain and trying to hide information afterwards, the transaction can begin inside an environment designed for privacy.
The transaction is executed privately
In the Rayls architecture, private institutional activity can happen within the Sovereign environment.
The transaction logic and relevant state can remain within that private environment while authorised participants interact with it.
The important part is that privacy is part of the execution model itself.
This creates the first separation:
Private execution does not automatically mean isolated from everything else.
The interesting question is what happens when that transaction needs to interact with a wider settlement environment.
You don't need to reveal everything to prove something
This is where zero-knowledge technology becomes interesting.
Instead of publishing all the underlying transaction information, a system can produce cryptographic evidence that a particular statement is valid.
In simple terms:
You can prove that something is correct without revealing everything that made it correct.
For institutional infrastructure, this distinction is important.
The verifier doesn't necessarily need to see the complete private transaction. It may only need enough cryptographic evidence to verify the required condition.
Where do Pedersen commitments fit?
A commitment can be thought of as a cryptographic way of locking information into a verifiable representation without immediately revealing the underlying value.
Pedersen commitments are one of the cryptographic building blocks that can be used in privacy-preserving systems.
They allow a value to be committed while maintaining mathematical properties that can later support verification and proofs.
The commitment itself isn't the complete privacy system.
It's one component that can help build a system where information can remain hidden while certain properties about that information can still be proven.
Generating the zero-knowledge proof
Once the relevant private information and conditions are established, a zero-knowledge proof can be generated.
The proof provides evidence that the required computation or condition was satisfied.
The verifier can then verify the proof without necessarily receiving the original private data.
That's the important distinction:
The data can remain private while the validity of a computation becomes verifiable.
This is one of the reasons zero-knowledge systems are interesting for financial infrastructure.
Proof and encryption are not the same thing
This distinction is easy to miss.
Encryption protects information by making the underlying data unreadable without the appropriate key.
A zero-knowledge proof provides evidence that a statement is true without requiring the verifier to see the underlying secret information.
A commitment allows information to be cryptographically bound without immediately revealing the information itself.
They solve different problems.
And in a privacy-preserving financial system, these different cryptographic mechanisms can work together
So how does the transaction move outside the Sovereign?
A private transaction eventually may need to interact with other parts of the network.
This is where the architecture becomes interesting.
The goal isn't to expose the complete private transaction.
Instead, the relevant information needed for interoperability or settlement can move through the appropriate infrastructure.
In the Rayls architecture, this can involve the private environment interacting through Relayers toward the relevant settlement layer.
The important idea is:
The transaction can interact with a broader network without making all of its private data public.
Where does the transaction actually settle?
This depends on what the transaction needs to accomplish.
Private institutional activity can remain within private environments, while interactions that require broader network settlement can connect toward the Rayls Public Chain.
That separation is useful because not every piece of institutional activity needs to exist publicly.
A private transaction doesn't become public simply because it eventually needs to interact with a broader settlement layer.
What does the settlement layer actually know?
This is one of the most interesting parts.
A settlement layer can verify the information it needs without necessarily receiving every detail of the original private transaction.
That creates an important distinction:
“I can verify that this happened correctly.”
is not the same as:
“I can see every detail of what happened.”
For institutional blockchain infrastructure, that difference matters.
The objective isn't necessarily maximum visibility.
It's appropriate visibility.
What happens to the private information?
The sensitive transaction information can remain within the private environment instead of becoming ordinary public blockchain data.
This allows institutions to maintain stronger control over confidential information while still participating in a broader settlement architecture.
The idea isn't simply to hide everything.
It's about deciding:
What needs to remain private?What needs to be proven?Who needs to see what?
That distinction becomes especially important in regulated financial markets.
But what about regulators?
This is where privacy shouldn't be confused with zero visibility.
Financial institutions still need compliance, auditing and controlled access.
A privacy-preserving architecture can therefore support selective disclosure.
Instead of making everything public to everyone, authorised parties can receive the information they are entitled to access.
This creates a more realistic model for regulated financial infrastructure:
Private by default.
Verifiable when required.
Accessible to authorised parties.
The exact permissions and disclosure mechanisms depend on the implementation and regulatory requirements, but the architectural principle is important.
Why not just use a normal private blockchain?
A conventional private blockchain can keep transactions away from public networks.
But that creates another problem:
How does private institutional activity connect to broader liquidity, assets and settlement?
A completely isolated network can solve privacy while creating fragmentation.
The more interesting challenge is connecting private institutional environments with a wider settlement layer without giving up the privacy requirements of participants.
That's a very different problem from simply building another private chain.
The interesting part isn't just privacy
For me, this is the bigger takeaway.
The architecture separates several things that are often treated as one:
Execution
Where the transaction actually happens.
Privacy
Who can see the underlying information.
Verification
What can be cryptographically proven.
Settlement
Where the relevant state ultimately needs to be recognised.
Once these responsibilities are separated, the architecture becomes much more flexible.
And this is where Rayls becomes interesting to study.
The complete transaction flow
At a high level, the process can be understood like this:
Private transaction
↓
Sovereign / private execution
↓
Cryptographic commitments + zero-knowledge proof
↓
Relayer / interoperability layer
↓
Settlement / verification
↓
Broader network state
The important part is that the transaction doesn't need to become completely public just because it needs to interact with a broader blockchain environment.
Publicly verifiable does not mean publicly readable
This is probably the simplest way to understand the entire concept.
A blockchain can provide evidence that something is valid without exposing every piece of the underlying information.
For financial institutions, that distinction could be extremely important.
Because the real challenge isn't simply:
“How do we put banks on a blockchain?”
It's:
“How do we give financial institutions the benefits of blockchain while respecting their privacy, compliance and operational requirements?”That's the problem this architecture is interesting to examine for.
Final thoughts
The more I look at institutional blockchain infrastructure, the more I think privacy vs transparency is the wrong framing.
The better question is:
What should be private, what should be verifiable, and who should be allowed to see what?
That's where architectures like Rayls become worth examining.
Not simply because they use blockchain, but because they explore how private execution, cryptographic verification and broader settlement can work together.
For institutional adoption, that separation could matter just as much as the blockchain itself.
Sources / further reading
Rayls Official DocumentationRayls High-Level Architecture Documentation
#Rayls #Blockchain #Privacy $RLS

Last time I took the publicly released proof code by Rayls and ran it through, measuring that each write in the anonymity set of 6 takes 1.96 seconds per person. But in that paper, there are three sentences that are inferences rather than measurements—I’m aware of that myself. This week I swapped the machine to a 2-core setup and added a few more data points, so that I can go back and fill in those three statements with measured numbers.
First, let’s clarify the relationship between this piece and the previous one, so readers don’t think it’s a reprint of the same paper. The previous article measured the proof time in a single-core environment for the 2-person and 6-person settings; these two numbers were retested this time and are almost unchanged. The entirely new content of this piece is the three things from the previous one that couldn’t be measured and could only be inferred.

In the Rayls official website supplier comparison table, there are nine rows, and I chose the one labeled “Privacy.” The reason is simple: privacy is important, and Besu is open source—its documentation and code are both available for me to look up.
In the comparison table, Rayls checks both rows—“Isolated Privacy” and “Cryptographic Privacy”—while Besu only checks the first row. I planned to verify using the other party’s own documentation, so I looked up Besu’s documentation, then pulled down its code and counted it line by line.
The conclusion isn’t “Besu doesn’t work.” The real difference is this: these two companies place privacy at different layers, and Besu moved it away earlier than many people think.

On September 19, Rayls published a post (“Privacy has a price”). The title said “honest math,” but the entire piece only provided a single range of numbers: a proof takes anywhere from a few hundred milliseconds to a few seconds. For weeks I kept writing about Rayls’ privacy architecture; this time I’m sharing the new stuff with everyone. I pulled down the publicly released proof code, ran it dozens of times in practice, and I’m sharing this interesting conclusion!
Let’s first talk about what the blog covers. Its core argument can be summarized in two sentences. The first sentence is where the cost comes from: confidential transactions are more expensive than transparent ones—mainly because generating zero-knowledge proofs is costly, while verification is relatively cheap. Even a basic confidential transfer proof takes several hundred milliseconds to a few seconds on ordinary commercial hardware. The second sentence is what you should ask: institutions shouldn’t only ask about TPS; they should ask what the throughput is under the level of privacy and auditability they actually need when facing real business workloads. The blog argues that the volume in interbank settlement isn’t large, and it falls well within what confidential settlement systems can handle.

I started staking RLS back in the pre-commitment phase—it was just something I got into by reading the official materials. After the name “Sovereign” was introduced, most of the discussion ended up lingering on “is it just a name change?” I think that question is backwards. The name doesn’t matter; what matters is what was changed underneath, and how much a firm can get that it can independently verify during due diligence. For every number in this piece, I’ve provided the exact source; you can reproduce it by following along.
First, let me clarify something. Because last week I wrote an article about auditability, some readers may have seen it.
Most of the content here is new. It comes from Axyl’s code repositories, the audit directories within those repos, and Axyl’s performance benchmarks documentation page. I hadn’t touched any of those before. Only the small section about key custody continues the conclusion from the previous article—I’ll mark it there. I separate what’s new from what’s old because what I “looked up this week” versus what I “looked up before” should be something readers can distinguish for themselves.

I started staking RLS from the pre-commitment phase; reading the official blog is just a habit. In the article published on September 12 about auditability, the second half lists six standards, saying that everything is fully satisfied “by construction” under mathematical compulsion. I agree with that, but “satisfied by construction” is a claim you can verify, not something you must simply believe. So I spent a week digging up the corresponding evidence for each of the six items from the publicly available source code, technical documentation, and on-chain interfaces—and now I’m sharing it with everyone.
Let’s start with its categorization. I think it’s more useful than most discussions of “privacy vs. transparency.” There are three ways to achieve auditability: mathematical enforcement—embedding it into cryptographic constructions; hardware trust—relying on the integrity of trusted execution environments; and policy-based access control—who can see what is determined by configuration set by the network operator.

When I look at lockup announcements, they usually only care about one thing: whether this commitment can be verified. Most projects’ “team lockup” ultimately comes down to a single sentence—you either choose to believe it or you don’t. This time is a bit different, so I checked on-chain.
First, let’s state the facts clearly. Parfin is the core technology provider behind Rayls. It is responsible for developing privacy nodes, the private network, the Enygma privacy framework, and the Rayls mainnet. As compensation for its work prior to the TGE, it received 1,070,493,535 RLS tokens—about 11% of the initial total supply of 10 billion.
This batch of tokens was previously held by an institutional custodian on Ethereum. The reason is straightforward: at the time of the TGE, the Rayls chain hadn’t gone live yet, so the tokens could only be held in custody. Now that the mainnet is available, this batch has been migrated to the Rayls chain and locked in a smart contract that can be publicly verified. At the same time, the unlock date has been pushed back from December 2026 to December 2027.

Brothers, I’ve been lurking in the Rayls community for a long time. I know everyone is very dissatisfied with the team—so am I. But the team is really doing work and has been putting in effort. It’s just that the Rayls team is taking a compliance-first route. Brothers, don’t give up—leave it to time. I believe the Rayls team will ultimately deliver the exam papers that satisfy us. Let me share some good news with you brothers—it's about the recent Rayls team integrating with an RPC. This is a very important thing!!
A quick overview at a glance
What is RPC
You can think of RPC as a dedicated hotline between an application and the blockchain.

To be honest, the first time I saw these three abbreviations put together, I thought they were three different answers to the same question: faster, safer—pick one and you’re done. Later I realized that ranking them side by side is like asking, “Which is best—a hammer, a screwdriver, or a wrench?” The answer depends on whether you have a nail, a screw, or a bolt.
The issues they each solve are actually three problems that have been conflated.
The first problem is: I want to prove that something is true, but the data needed for the proof is sensitive, and I don't want to show it to you. A bank wants to tell regulators that a transaction is legal, authorization is correct, and there are no duplicates—yet it doesn't want to put the amounts and the payer/payee details on the ledgers. This kind of proof that is true but doesn't reveal the underlying data is ZK’s home turf. Its charm lies in guaranteeing the conclusion comes from mathematics, not from “I promise you, I won’t let you see.” Regulators or auditors who receive the verification key can check the result, but they can’t touch the underlying data. The cost is also real: it’s good at proving properties of data, but not good at letting multiple parties compute together when no one has complete data, and it’s far more compute-intensive than plaintext.

In the crypto circle, you can see “some traditional finance giant is moving into blockchain” every week. I mostly swipe past headlines like this, because in most cases they end up in an innovation lab, issue a press release, and then there’s no follow-up. There’s a very simple way to judge whether something is true: for an ordinary customer, in their own app, can they directly click in and use it?
XP Inc. This time it met the standard.
First, get a clear picture of the company, because its scale determines how much weight this carries. XP is a Brazil-based investment platform listed on Nasdaq, ticker symbol XP. I checked its investor relations page for Q1 2026 data: customer assets are on the order of R$152.9 billion reais—more precisely, R$1.529 trillion; there are more than 18,000 financial advisors; and over the past twelve months, total revenue is R$19.8 billion reais, with pre-tax profit of R$5.8 billion reais.

I started staking from the batch of pre-commitments in June, so I’ve gone through this whole process already. This time it’s open to everyone. A lot of people around me have been asking how to operate it and what to watch out for, so I’m just going to lay everything out clearly in one go.
First, let’s talk about the change itself.
Rayls uses delegated proof-of-stake: validators run nodes, produce blocks, and help secure the public chain. Regular holders don’t need to run nodes themselves—they can delegate their RLS to a validator and share part of the staking rewards.
This mechanism went live in June, but at the time it was only available to wallets that participated in the pre-commitment plan and the liquidity seed activities. Those participants locked their tokens before the mainnet launch, and the official team offered a three-month 55% boosted annualized return. They even sent 1 USDr to each qualifying wallet so they wouldn’t even have to worry about having gas.

I started staking RLS back in the pre-commitment phase, and when I read the official blog, it was usually to see whether my position would be affected. This August 30 article about quantum stuff was different: the whole piece was teaching institutions how to do procurement, with little direct relevance to someone like me, a retail investor. But I still read it to the end, because it opened with a pretty strict rule, and that rule eventually brought me back to the article itself.
The rule is like this: if a claim says something is "quantum-safe" but doesn’t clearly state which standardized algorithm it uses and at what parameter level, then it isn’t a claim at all, just a label.

In my previous article about XP, I kept wondering about one thing: once an institutional stablecoin like USDXP is issued, how exactly does it participate in real cross-border settlement? This piece is my attempt to fill in that gap, and it also helped me finally understand a term for the first time: “stablecoin sandwich.”
First, let’s explain this term. It’s actually very visual. A single cross-border payment: the two ends are your local currency, with a layer of public stablecoin in the middle. The payer converts their local currency into a USD stablecoin; the stablecoin completes the cross-border settlement on-chain; then the payee converts it back into their own local currency. Doesn’t it look like two slices of bread with that middle layer in between? That’s the phrase the industry started using to describe stablecoin-based cross-border settlement.

In the previous post, I talked about the staking being opened up itself. But in the backend, the most frequently asked question from many brothers was actually the same sentence: exactly how do you do it? So this time, I went through the whole process again from start to finish, and wrote down every step and every spot that’s easy to get stuck. Just follow it.
Here’s the link to the previous post: 质押开放给所有人了,但有几件事最好先知道
First, let’s make it clear who this article is for. If you’ve never come across Rayls at all— and even aren’t very familiar with terms like wallets or bridging— then this is written for you. For every piece of technical terminology, I’ll briefly explain it along the way.

I’ve been going through the Rayls docs, and one thing I initially found confusing was the difference between a Privacy Node, Private Network, and Public Chain.
After looking at how they connect, it became much easier to understand.
They each have a different role.
1. Privacy Node: the institution’s own blockchain
A Rayls Privacy Node is an EVM-compatible chain operated by a single institution.
What happens inside the institution stays inside its own environment.
It can issue tokens, manage balances, run smart contracts and handle its internal activity there.
One detail I found important: a Privacy Node is not a validator.
The docs describe it more like the institution’s own onchain environment, where its data, keys and workflows are controlled by the institution itself.
That makes sense for banks because they need control over sensitive financial information.
2. Private Network: where institutions interact
The next part is the Rayls Private Network.
This is a permissioned blockchain network where multiple institutions can connect through their Privacy Nodes.
So instead of every institution keeping its own isolated blockchain, they can interact with other approved participants while keeping transactions private.
Rayls uses a Private Network Hub to coordinate these interactions.
This is where Enygma becomes interesting.
Enygma is Rayls’ privacy protocol for confidential transactions. The docs show how it can be used for private token transfers and Delivery-versus-Payment, where two assets can be exchanged while keeping sensitive transaction information protected.
There is also an auditor role, so privacy doesn't simply mean that nobody can ever inspect anything.
That balance between confidentiality and authorised visibility is one of the things I found interesting while going through the docs.
3. Public Chain: the open side
Then there is the Rayls Public Chain.
This is an EVM-compatible Layer 1 designed to connect the institutional side with the open blockchain ecosystem.
This is where public applications, assets and DeFi can operate.
The current docs also mention over 10,000 TPS and sub-second deterministic finality through Rayls' Axyl consensus.
So the Public Chain isn't simply another place to store assets.
It is the open side of the architecture.
The simple way I understand it now
Think about an institution issuing a tokenised asset.
Privacy Node
The institution creates and manages the asset in its own environment.
↓
Private Network
The institution can interact with other approved institutions privately.
↓
Public Chain
The asset can reach the open blockchain ecosystem and public liquidity when appropriate.
Of course, the actual flow depends on the use case. The important part is that Rayls doesn't force every activity into the same environment.
Each environment has a specific job.
And this is where Rayls Enygma fits
This was probably the most interesting part for me.
Blockchain usually gives you transparency by default, but financial institutions often need the opposite for sensitive transactions.
Enygma is designed to provide confidential transactions while keeping them verifiable and auditable.
For example, Rayls documents describe confidential transfers where the sender, recipient and amount can be hidden from public view, while authorised auditors can still access the necessary information.
It also supports private DvP flows for tokenised assets.
So the goal isn't simply:
"make everything private."
It is more about giving different participants different levels of visibility depending on what they are authorised to see.
What I took away from exploring Rayls
Before going through the docs, I mostly thought of Rayls as another blockchain project focused on institutions.
After looking at the architecture, I see the idea differently.
The Privacy Node gives an institution its own controlled onchain environment.
The Private Network lets approved institutions interact.
The Public Chain connects that institutional infrastructure to the open blockchain world.
And Enygma provides the privacy layer for sensitive activity.
That separation is probably the part of Rayls I found most interesting.
Instead of asking institutions to choose between private infrastructure and public blockchain access, Rayls is building a way for the two sides to work together.
That was the part that clicked for me after actually going through the docs.
@Rayls #Rayls

To be honest, when it comes to partnership news, I usually just glance at it and swipe past. Nine out of ten are only re-hanging logos with each other. But I stopped and read this one through because it touches the most boring—and also the most expensive—part of cross-border payments.
Cross-border remittances are slow, and many people think it’s because the “network is slow.” The real reason is much more boring: it isn’t that the money is “sent” over; it’s been “sitting there” already. When a bank wants to pay to a particular country, it usually has to open an account with a local bank in advance and pre-deposit a large amount of money there—a piece of jargon called a nostro account. Every payment corridor around the world has to keep a slice of funds, like depositing a stack of cash at each friend’s house in case you pass by one day and need it. The money stays idle on the books, and exchange-rate fluctuations are borne by the account balance itself. After a cross-border payment runs its course, it often takes several days.

Rayls is a project I’ve followed for a long time. Recently, it launched a community project called The Rail, and the gameplay is somewhat different from the usual "points-grinding activities." It doesn’t reward spamming; it recognizes people who consistently put in real effort. In short, let me explain how it works! Family, if you also think it’s great, come join and fill out the form to get on board.
https://tally.so/r/dWgdrA
1. What is The Rail
The Rail is Rayls’s community ambassador program. Its purpose is to recognize meaningful contributions and turn them into identity, permissions, and rewards. The official positioning is: "a community built on real contributions, not a points-grinding game," described as "a small family room where everyone genuinely cares about one another." The operating logic is: you contribute → earn points → level up your role → get recognized.