Overview

A cross-chain transaction in Rayls travels from one institution's Rayls Sovereign ledger, through the Private Network Hub, and into another institution's Rayls Sovereign ledger. It passes through ten distinct stages on the way, and understanding those stages explains both the timing an application should expect and the privacy properties an institution is relying on.

This page describes the standard teleport, which is the path a straightforward token transfer takes. The atomic, Enygma and DvP flows add phases on top of the same path rather than replacing it, and the differences are set out at the end.

---

The ten stages

On the sending side

1. The transaction is submitted. A user or an application submits a transaction to the Rayls Sovereign ledger, either directly over JSON-RPC or through the optional Backend, calling the teleport function on the relevant token handler.

2. The ledger executes locally and burns. The token handler burns the tokens from the sender's balance in the Rayls Sovereign ledger, the endpoint contract prepares the cross-chain message, and a MessageDispatched event is emitted. Burning on the source is what guarantees that an asset never exists on two chains at the same time, since the corresponding mint happens only on the destination.

3. The Relayer detects the event. The Relayer's listener polls the Rayls Sovereign ledger for new blocks, detects the MessageDispatched event, and adds the message to its processing queue.

4. A Merkle proof is built. The Relayer's Merkle service collects recent messages, builds a Merkle tree, and generates an inclusion proof for this specific message. The proof is what allows the Private Network Hub to verify that the message is legitimate without having to trust the Relayer that submitted it.

5. The payload is encrypted. The Relayer asks the Cryptographic Trust Suite to encrypt the payload for the destination institution. Encryption happens before anything leaves the institution, which is what allows the Hub to route a message it cannot read.

6. A zero-knowledge proof is generated, where the flow requires one. For Enygma and DvP transactions the Relayer requests a proof from the Gnark API. A standard teleport does not need one and skips this stage.

At the Private Network Hub

7. The encrypted batch is submitted. The Relayer calls the Teleport contract on the Private Network Hub. The contract validates the Merkle proof, stores the encrypted blob, and emits a DataStored event carrying the destination chain identifier.

On the receiving side

8. The destination Relayer picks the message up. The receiving institution's Relayer polls the Private Network Hub, detects the DataStored event, checks whether the destination chain identifier is its own, and queues the message if it is.

9. The payload is decrypted. The receiving Relayer asks its own Cryptographic Trust Suite to decrypt the payload, which only the intended recipient institution is able to do.

10. The message executes in the destination ledger. The Relayer calls the endpoint contract in the destination Rayls Sovereign ledger, the endpoint checks that the message has not already been executed, and the token handler mints the tokens to the recipient.

---

Timing

Applications should be designed around the end-to-end envelope rather than around any individual stage, since the dominant contributors are the Hub block time and the polling intervals at each end.

---

What the Private Network Hub can and cannot see

The Hub is shared infrastructure, and the design assumption is that it should be unable to violate privacy even though every institution connects to it.

What the Hub holds: the encrypted message blob, the Merkle proof it needs in order to verify that the message is legitimate, the source and destination chain identifiers, a public participant registry, a public token registry, and, for Enygma, balance commitments rather than balances.

What the Hub cannot read: transfer amounts, recipient addresses, the details of the transaction, and the internal identity of the sender.

Messages are grouped by type into separate Merkle trees, identified as tree 0 for ERC-721, tree 1 for ERC-20, tree 2 for ERC-1155 and tree 3 for Enygma.

Selective disclosure to a designated Private Network Auditor is a separate mechanism and is not a property of the Hub. Where a Rayls Private Network has an Auditor role assigned, that role holds view-only access covering the participant registry, the token registry, the balances each participant submits as a proof, and a decrypted record of Private Network Hub transactions. Spending authority and viewing authority are separated cryptographically rather than by policy, so an auditor can read without being able to transact.

---

The encryption in one paragraph

Every cross-chain message is encrypted end to end. The scheme establishes a post-quantum shared secret between the sending and receiving institutions using ML-KEM key encapsulation, derives a symmetric key from that secret using HKDF-SHA3, and encrypts the payload with AES-256-GCM. To avoid carrying the full key-encapsulation ciphertext on every message, the encapsulation is performed once per participant pair at setup and the resulting ciphertext is stored on the Private Network Hub, so that each subsequent message carries only a small tag. Only the intended recipient institution can decrypt, and the Hub stores and forwards ciphertext alone.

---

What happens when a stage fails

Sending side

At the Private Network Hub

Receiving side

For atomic transactions there are two separate timeouts operating at different layers, and they should not be conflated. The Teleport contract on the Private Network Hub enforces a hard on-chain lock time of 240 seconds. Separately, the Relayer runs its own off-chain expiration-revert timer, which is a required configuration value in the deployment rather than a value the protocol fixes.

For the revert behaviour as a token owner experiences it, see Sending Teleports.

---

How the other flows differ