Privacy in a Private Network
A Rayls Private Network is multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub. Privacy works differently in each part: inside an institution's own chain, on the Hub, and for the Private Network operator. This page explains each in turn.
Inside an institution's chain
Each institution runs its own Rayls Sovereign chain (Privacy Node in the code), an EVM (Ethereum Virtual Machine) chain on infrastructure it chooses. Its clients' accounts, balances and internal payments are ordinary EVM records there, and they never reach the Hub. Only the institution, and whoever it gives access to its chain, can see them.
That includes Enygma tokens: a payment between two clients of the same institution is an ordinary ERC-20 transfer on that institution's chain.
Between chains: encrypted messages
When a contract on one chain sends a message to another chain, the sending chain's private relayer encrypts it before it reaches the Hub:
- every pair of participants shares a secret, agreed with ML-KEM-768 (Module-Lattice-Based Key-Encapsulation Mechanism, a post-quantum standard) when they join the network;
- the relayer encrypts each batch of messages for its destination chain with AES-256-GCM (the Advanced Encryption Standard with 256-bit keys, in Galois/Counter Mode), using a key derived from that shared secret;
- it attaches a message tag derived from the same secret, so the destination recognises the batch as its own without trying to decrypt every batch on the Hub.
Other members of the network, and anyone else who can read the Hub, see an encrypted batch and a tag that means nothing to them.
Between chains: Enygma
Enygma adds more. It hides transfer amounts and balances behind commitments, and it hides the receiver among up to six participants. The Hub checks each transfer with a zero-knowledge proof, without seeing the amount. The sender is not hidden, and mints and burns are public on the Hub. See Rayls Enygma and Who sees what.
What the Hub shows
Anyone who can read the Hub, including the other participants and whoever runs the Hub's nodes, can see:
| Visible on the Hub | Why |
|---|---|
| Which participant submitted each batch or Enygma transaction, and when | Each relayer submits its Hub transactions from its own authorised account. |
| The size of each encrypted batch | The ciphertext is stored on the Hub. |
| The participant list, roles and statuses | They're in the participant registry. |
| Registered tokens: name, symbol, issuer and status, and which participants a token is frozen for | They're in the token registry. |
| The amounts of mints and burns that issuers report | Issuers report changes in supply in clear, for Enygma tokens and other registered tokens alike. |
| The block headers of every Rayls Sovereign chain | Each relayer posts its chain's headers. Headers contain no transactions, but they show block times and how much gas each block used. |
| Which participants took part in each Enygma transaction, and the delivery-versus-payment (DvP) swap events | See Who sees what. |
The Hub doesn't show the content of messages, who receives them or, for Enygma, the amounts.
What the Private Network operator sees
When a participant joins, its key service encrypts the participant's view private key to the Private Network operator, and registration can't complete without it. From those keys, the operator's governance services recover every shared secret in the network. They decrypt:
- every message between chains: sender, receiver, chains, token, amount and payload;
- every Enygma transfer: sender, receiver and amount;
- the terms of every DvP swap.
The operator doesn't see activity inside a participant's chain that never crosses the Hub. A view key can only read: it can't sign or spend. See Auditing.
Who sees what
| Party | Sees | Doesn't see |
|---|---|---|
| An institution | Everything on its own chain; messages and Enygma transfers it sends or receives | Other institutions' chains and messages |
| Other participants, and anyone else with access to the Hub | What the Hub shows (table above) | Message contents, receivers, Enygma amounts |
| Private Network operator | All of the above, plus every cross-chain message, Enygma transfer and DvP term, decrypted | Activity inside each chain that doesn't cross the Hub |
Quantum computers
The shared secrets come from ML-KEM-768, a post-quantum standard published by the US National Institute of Standards and Technology (NIST), and the messages use AES-256. Enygma's zero-knowledge proofs and commitments use elliptic curves, which a large quantum computer could break. See Cryptographic foundations of Enygma.
Designing for these properties
- Treat the Private Network operator as able to read all cross-chain activity, and choose the operator accordingly.
- Assume the other members can see when you send and how often, but not what or to whom.
- Keep payments between your own clients on your own chain.
- If Enygma's anonymity set matters to you, plan for at least four participants. See The anonymity set and small networks.
Updated 2 days ago