rls

An Analysis of Compensating Transactions, Partial Settlement, and the Limits of Atomicity in Cross-Chain Payments
Many institutions and developers still treat a successful transaction receipt on the sender’s chain as proof that a payment is complete. In cross-chain systems, that is often not the case.
From reviewing technical documentation and observing basic behavior in controlled environments, one pattern consistently appears: the debit on the source chain can commit successfully, while the destination can still fail at a later step. When that happens, the funds do not automatically return. The system typically executes a **compensating transaction**.
Partial Atomicity
The official Rayls documentation (*Send Enygma Transactions* and *How Enygma Works*) describes the boundaries of atomicity clearly:
- The source call is atomic — the burn and the transfer request succeed or fail together.
- Each individual destination leg is atomic — the mint and any program steps on that leg succeed or fail together.
- All legs of a single payment are **not** atomic. Legs can settle independently.
The documentation states explicitly that “Failures are reversed, not rolled back.” The Hub transaction and the mint on the destination chain are separate transactions. If the mint or a program step fails on the destination, the relayer runs a compensating transaction to return the value to the sender. It is not one atomic transaction across chains.
Until the refund actually lands, the sender’s balance on the source chain remains reduced by the failed amount.
What Is a Compensating Transaction?
A compensating transaction is a **new and separate** transaction created to correct a failure. It is not a rollback of the original transaction.
According to the RaylsEnygmaHandler documentation, if any program step reverts, the entire leg (including the mint) fails. The relayer then returns the value to the sender on the source chain through a compensating mechanism. The refund appears under the **same reference ID** and is recorded as status `RECEIVED` on the source chain, rather than as a pure revert of the original debit.
A simple example consistent with the documented behavior:
- The source debits 10.
- One destination successfully receives 4.
- Another destination fails during execution.
- A separate compensating transaction returns 6 to the sender.
The final result is 4 delivered + 6 returned = 10. The original source transaction remains recorded as successful.
Diagrams
Basic flow:
Atomic vs Multi-Leg:
Partial Settlement Example:
Practical Risks Worth Noting
From the documentation and observations in controlled environments, several points are often overlooked:
1. Refunds are not instant
The Rayls documentation itself notes that until the refund lands, the sender’s balance remains reduced. Delays in the relayer or issues with proof generation can leave funds in a pending state longer than expected.
2. Reconciliation must be done per leg
A single source receipt is not enough. One must match what left the source, what arrived at each destination, what failed, and what was actually returned via the compensating transaction (typically under the same reference ID).
3. Dependence on off-chain components
Failure detection and refund initiation often rely on relayers. Even in local testing, warnings related to balance commitments or proof generation can appear. These risks are higher in production.
4. Controlled results ≠ production guarantees
Clean behavior in a lab with deliberately triggered failures does not automatically translate to production environments with concurrent load, network issues, or state inconsistencies.
Conclusion
A successful receipt on the source chain only proves that the debit committed. It does not prove that every destination received the funds, nor does it prove that any failed portion has been returned.
Successful source execution, destination settlement, and compensating refunds are related events, but they are **not the same event**. Understanding this distinction matters when designing or operating cross-chain settlement flows.
The official Rayls documentation already describes this compensating pattern openly. The important point is not to treat results from controlled environments as full proof of production reliability.
---
Disclaimer:
This article is an analysis based on publicly available Rayls documentation and technical observations in controlled environments. It is not a formal audit, investment advice, or a guarantee of any system’s behavior in production. Readers should verify details directly against the official documentation.
Sources
- Send Enygma Transactions: https://docs.rayls.com/docs/send-enygma-transactions
- How Enygma Works: https://docs.rayls.com/docs/how-enygma-works
- RaylsEnygmaHandler: https://docs.rayls.com/docs/raylsenygmahandler
#RLS $RLS

While exploring Rayls’ Sovereign Contracts repository, I reviewed the role-based permission settings for the Private Network Hub (PNH).
Rather than simply describing what each role does, I compared the implementation code, permission configuration scripts, and official documentation to see whether they aligned.
In an access control system, knowing only the role names isn’t enough. You also need to examine which permissions the code supports, what mappings the configuration scripts apply, and how the documentation describes them.

If a transfer fails on Rayls, will my tokens be returned?
What happens to tokens processed on the source chain if the destination transaction fails during a cross-chain transfer? $RLS
When moving tokens to another chain, assets may be locked or burned on the source chain. But if processing fails on the destination, a procedure is needed to restore the asset state.
Rayls' official documentation describes a recovery mechanism for this situation. However, examining the public code as well reveals additional points that need to be verified.

In my first two articles, I tested Rayls’ proof code on a cloud server, but the numbers came from just one type of machine, and the test code wasn’t available somewhere readers could easily reproduce the results. This time, I’ve made the test code public on GitHub and had GitHub’s own servers run it instead. I tested three types of CPUs, and anyone can click through to view the logs.
Here’s the short answer. Using the six-member anonymity set in Rayls Enygma’s private-transfer circuit as an example, generating a zero-knowledge proof for one transfer takes 1.55 to 1.95 seconds with a single vCPU, and 0.63 to 0.71 seconds with 4 vCPUs. Verifying the proof takes about 1 millisecond. The first time the service processes a transfer of a given size, it also takes an additional 1.9 to 2.9 seconds to load the proving key into memory. Assuming requests are processed serially, a 4-vCPU cloud server can generate 1.4 to 1.6 proofs per second.

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.