CBDCs on Rayls Private Networks

A central bank digital currency (CBDC) is money issued by a central bank in digital form, as a direct liability of the central bank. A wholesale CBDC is held and exchanged by banks and other financial institutions, rather than by the public.

This page explains how a wholesale CBDC maps onto a Rayls Private Network, how that design comes from the Rayls research papers, and where the implementation differs from them.

The research behind the design

Rayls has published two papers on CBDC design:

Rayls: A Novel Design for CBDCs (ePrint 2025/1639), also presented as a poster at the IEEE Symposium on Security and Privacy (S&P) 2024;
Rayls II: Fast, Private, and Compliant CBDCs (ePrint 2025/1638).

In both, each commercial bank runs its own private ledger, and the ledgers connect through relayers to a shared chain. The papers call these the privacy ledgers and the commit chain. Banks enforce compliance locally on their own ledgers, and Enygma settles payments between banks with commitments and zero-knowledge proofs, batching many client payments into each interbank transaction. See Published academic material.

That is the shape of a Rayls Private Network: multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub.

In the papers	In a Rayls Private Network
Privacy ledger, one per bank	Rayls Sovereign chain (Privacy Node in the code), one per participant
Commit chain	Private Network Hub, a Hyperledger Besu chain
Relayer	Private relayer, one per chain
Enygma	Rayls Enygma: an Enygma token on each chain, and the Enygma contracts on the Hub

A wholesale CBDC network

Role	Who	Runs
Private Network operator	The central bank	The Private Network Hub, the governance services and the Auditor Explorer
Issuer	The central bank	Its own Rayls Sovereign chain, registered with the issuer role, where it deploys and mints the CBDC
Participants	Commercial banks	Each its own Rayls Sovereign chain, private relayer and key service

The CBDC is an Enygma token: an ERC-20 token on each bank's chain, with each bank's balance held on the Hub as a commitment that hides the amount.

The CBDC lifecycle

Issue. The central bank deploys the Enygma token on its own chain through the contract factory, registers it, and submits it to the Hub, where it approves the token as operator. It then mints on its own chain. The minted amount is public on the Hub, and only the issuing chain's relayer can change the token's supply there. See Running Rayls Enygma.
Distribute. The central bank sends the CBDC to commercial banks with Enygma transfers. The other banks can't see the amounts, or which bank received value. The receiving bank's relayer mints the tokens on its chain.
Pay between banks. Banks pay each other with Enygma transfers. One Hub transaction can carry many payments from the same bank. See How Enygma works.
Use inside a bank. On a bank's own chain, the CBDC is an ordinary ERC-20 balance. Transfers between accounts at the same bank stay on that chain and never reach the Hub.
Redeem. A bank sends the CBDC back to the central bank, which burns it on its own chain. The burn is public on the Hub.

Building on the CBDC

Each bank can run its own contracts on its own chain, for example to issue a tokenised deposit or another client-facing token backed by the CBDC it holds.

An Enygma transfer can also carry program steps: calls to contracts on the receiving chain that run when the transfer arrives, in the same transaction as the credit. They can only call contract code and functions that the operator has approved in the network's template registry. See Programmable transfers and Send Enygma transactions.

What the central bank controls and sees

As operator and issuer, the central bank can:

admit banks to the network, set their roles and freeze them;
freeze the CBDC for chosen banks, so they can't send or receive it across chains, or use it in delivery versus payment (DvP);
mint and burn on its own chain;
read every interbank transfer, decrypted, through its governance services and Auditor Explorer.

It doesn't see transfers between accounts at the same commercial bank, which stay on that bank's chain.

The other banks can see which banks took part in each Enygma transaction and which bank sent it, but not the amounts, or which of the other banks received value. See Who sees what.

Where the implementation differs from the papers

Topic	Papers and research code	Implementation
Key agreement	CSIDH (Commutative Supersingular Isogeny Diffie–Hellman)	ML-KEM-768 (Module-Lattice-Based Key-Encapsulation Mechanism, a post-quantum standard) for every view key and shared secret, since February 2026
Auditor	The Enygma research repository describes the auditor as optional, seeing only what participants share with it	Every participant's view key is encrypted to the Private Network operator when it joins, so the operator can read all cross-chain traffic. There are no scoped auditor keys.
Who paid whom	Hidden	Receivers are hidden among up to six participants. The sender is visible, because each bank's relayer submits its own transactions to the Hub.
Commit chain	The research code assumes a Byzantine-fault-tolerant consensus	The code doesn't fix the Hub's consensus. It is a decision for each deployment.
Performance	The papers report the authors' benchmarks	These docs don't quote performance figures. They depend on the deployment.

Not in the production release

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

Visibility rules set by role, such as an auditor whose access the central bank limits to some activity. Access is network-wide and belongs to the operator.
Role-based visibility enforced at the consensus layer. Privacy comes from encryption and Enygma's proofs, not from the Hub's consensus.
Retail CBDC payments. The Enygma research repository includes a retail payments design based on unspent transaction outputs (UTXOs), but it isn't part of the Private Network code.