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