A warm introduction to running a Private Network

Some institutions want to run a network in which other institutions exchange tokenised value privately, under rules the network sets. They include financial market infrastructure (FMI) providers such as central banks, clearing houses, payment processors and stock exchanges. A banking group may also want one, to keep its legal entities, business lines or branches separate while still settling between them.

A Rayls Private Network is built for these cases. This page explains what one is, what the operator and the participants can each do, and what isn't part of the production release.

What a Rayls Private Network is

A Rayls Private Network is multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub.

Rayls Sovereign chains. Each participating institution runs its own EVM (Ethereum Virtual Machine) chain, a Rayls Sovereign chain (Privacy Node in the code). Its clients, balances and contracts live there. See Rayls Sovereign.
The Private Network Hub. The Private Network Hub is a Hyperledger Besu chain at the centre of every Rayls Private Network, run by the Private Network operator. Every message between Rayls Sovereign chains passes through it. It holds the network's registries for participants, tokens and approved contract templates, the cross-chain messaging contracts, and the Enygma and DvP (delivery-versus-payment) contracts.
Private relayers and key services. Each participant also runs a private relayer, which carries messages between its chain and the Hub, and a key service (CTS), which holds its keys encrypted with a key management service.

The network is permissioned: only participants the operator has registered and activated can send or receive cross-chain messages. For the components in detail, see Private Network architecture.

How cross-chain traffic stays private

Messages are encrypted for the receiving participant. When a participant registers, its key service agrees a shared secret with every other participant using ML-KEM, a post-quantum key exchange. Token transfers and arbitrary messages between two chains are encrypted with keys derived from that secret. The Hub stores and relays them without reading them, and the other participants can't read them either. See Privacy in a Private Network.
Enygma hides amounts and receivers. Rayls Enygma adds zero-knowledge proofs and commitments, so private payments settle on the Hub without revealing amounts, balances or which participant received value. The sender is still visible on the Hub.
The operator can read everything. Each participant's view private key is encrypted to the operator when it registers. With it, the operator's governance services decrypt every cross-chain message and every Enygma transfer. Choose your operator with that in mind. See Who sees what and Auditing.

What the operator can do

The operator runs the Hub and the governance services, and holds the Hub's administrator role. With the code as it is today, the operator can:

Register participants and set each one's role: an issuer can register tokens on the Hub, a participant can only receive and send tokens that issuers have registered.
Change a participant's status. Only active participants can send or receive cross-chain messages, so setting a participant to frozen or inactive cuts it off. See Freezing participants.
Approve tokens that issuers submit, so they can move between chains. See Approving new tokens.
Freeze a token for chosen participants. See Freezing tokens.
Approve the contracts that Enygma transfers may call on arrival, through the Hub's template registry.
Delegate these powers to separate accounts with on-chain roles, and require waiting periods before some of them take effect. See Private Network roles.
Inspect all cross-chain activity in the Auditor Explorer. The flagger marks token transfers that would take a chain's balance of a token below zero, and participants whose chains stop reporting block headers to the Hub. Enygma and DvP transfers are exempt from the balance check, because their zero-knowledge proofs already prevent overspending. See Flagging transactions.
Pause and upgrade the Hub contracts, as the Hub administrator.

What participants can do

Each participant runs its own Rayls Sovereign chain and, with it, can:

run its own applications and clients, with payments between its own clients staying on its chain;
issue tokens, if it is an issuer, and submit them to the Hub for approval;
send private payments to other participants with Enygma, and exchange assets for Enygma tokens with private DvP;
send arbitrary messages to contracts on other participants' chains.

Not in the production release

These aren't part of the production release today. Some can be developed for a client's own deployment.

No separate auditor. There is no auditor with its own keys, and no scoped or configurable decryption: whoever holds the operator's view secret key can read every cross-chain message. To give a regulator visibility, give it access to the operator's Auditor Explorer, which shows the whole network.
No automatic enforcement. The flagger only flags. Freezing a participant or a token is always a separate transaction by an authorised account.
No application workflow. Institutions don't apply to join on-chain. The operator registers each participant after agreeing terms with it off-chain.

Where to go next

Running a Private Network: the steps to set one up.
Network design options: the choices you make, with example designs.
Installing a Private Network: run one locally with the Rayls CLI.
Why a Rayls Private Network?, and, for central bank digital currency (CBDC) networks, CBDCs on Rayls Private Networks.

Research

The Private Network shape, with each bank running its own private ledger connected to a shared chain through a relayer, comes from Rayls: A Novel Design for CBDCs (ePrint 2025/1639), refined in Rayls II: Fast, Private, and Compliant CBDCs (ePrint 2025/1638). See also Published academic material.

The implementation differs from the papers in places. The papers connect the banks' ledgers to a decentralised programmable blockchain; in the code, the Hub is a permissioned Hyperledger Besu chain run by the operator. The papers aim to hide the payer of each transaction; on the Hub, the sending participant is visible. Key agreement uses ML-KEM rather than CSIDH. Where they differ, these pages describe the implementation.