Operating a Rayls Private Network

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

The guides in this section are for the Private Network operator: the organisation that runs the Hub and decides who joins the network and which tokens can move across it. In a central bank digital currency (CBDC) network, that is usually the central bank.

What the operator runs

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 delivery-versus-payment (DvP) contracts.

Around the Hub, the operator runs:

Each participating institution runs its own Rayls Sovereign chain (Privacy Node in the code), a private relayer and a key service (CTS). See Private Network roles and Private Network Technical Architecture.

How the operator acts on the network

The operator's control starts with one account: the holder of the ADMIN role in the Hub's access manager (RaylsAccessManagerV1). By default this is the account that deployed the Hub contracts. In the reference scripts its private key is the PRIVATE_KEY_SYSTEM variable.

The Hub's governance functions are restricted, and any restricted function that isn't mapped to another role can only be called by ADMIN. After deployment, adding participants, changing their status, approving tokens and freezing tokens are all in that group.

The operator can hand some of these powers to other accounts by activating the Hub's optional business roles: PRIVATE_NETWORK_OPERATOR can add participants in bulk, change their status and role, and approve tokens; COMPLIANCE_OFFICER can freeze and unfreeze tokens. See Private Network roles.

There is no operator web interface or API for these actions. The governance API and the Auditor Explorer only read. To change anything, the operator calls the Hub contracts directly: with the Hardhat tasks in rayls-sovereign-contracts, or with any Ethereum tool that can sign a transaction. The Hardhat tasks read these environment variables:

What the operator can see

The operator's governance services hold the operator's view secret key (PNH_RAYLS_VIEW_SECRET_KEY), an ML-KEM-768 key. ML-KEM is a post-quantum key exchange. When an institution joins, its key service encrypts the institution's own view private key to the operator. With those keys, the listener decrypts all cross-chain traffic on the Hub:

• Enygma transfers: sender, receiver and amount;
• DvP swap terms;
• the payloads of arbitrary messages between chains.

What stays inside one Rayls Sovereign chain never reaches the Hub, and the operator can't see it. The operator can read, but it can't spend: spending needs each institution's spend key, which stays in that institution's key service. See Who sees what.

📘

The auditor is the operator

When the Hub is deployed, the operator registers itself as a participant with the Auditor role, under chain ID 999 (OPERATOR_CHAIN_ID in the contracts), and with the operator's view public key. Every institution encrypts its view key to that public key. There is no separate auditor key and no scoped access: anyone the operator lets use the governance API or the Auditor Explorer sees all decrypted cross-chain traffic. The Hub's optional NETWORK_AUDITOR role has no functions assigned.

Operator tasks

To set up a network first, see Running a Private Network and Installing a Private Network.

Trying it locally

The Rayls CLI starts a complete Private Network on one machine with ./rayls init --full. That stack includes the governance services and the Auditor Explorer:

The local Hub is a single Besu node with a zero gas price: a development set-up, not a production design.

Where the design comes from

The shape of a Private Network, institutions' private ledgers connected through a shared chain, comes from Rayls: A Novel Design for CBDCs (ePrint 2025/1639) and Rayls II: Fast, Private, and Compliant CBDCs (ePrint 2025/1638). The implementation differs in two ways that matter to an operator. The papers connect the ledgers to a decentralised blockchain; in the implementation, the Hub is a Besu chain run by the operator. And the papers have each bank enforce regulatory rules on its own ledger; the implementation adds network-wide controls on the Hub, run by the operator: participant and token approval, freezes, and decryption of cross-chain traffic. See also Published academic material.