Auditing

In traditional finance, payment, clearing and settlement happen at different times and in different systems, and each institution keeps its own records. Supervisors audit after the fact, often on samples, and spend much of the effort reconciling records that don't agree.

A Rayls Private Network is multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub. Every transaction between institutions passes through the Hub and is recorded there once, so the network has a single record of its cross-chain activity. The Private Network operator can decrypt that record as it is written.

Who can audit

In the code, audit access belongs to the Private Network operator:

1. When the Hub is deployed, it registers the operator's audit identity: a participant entry named "Auditor", with the auditor role and the operator's own chain ID, 999, a constant in the contracts (OPERATOR_CHAIN_ID). The governance services must be configured with the same value. The entry holds the operator's view public key, an ML-KEM-768 key (Module-Lattice-Based Key-Encapsulation Mechanism, a post-quantum standard).
2. When an institution joins, its key service encrypts the institution's view private key to that key and stores the result on the Hub. Registration can't complete without this step.
3. The operator's governance listener holds the matching secret key. It decrypts each participant's view key, recovers the shared secret between every pair of participants, and decrypts the network's traffic.

There is one audit key per network, and it belongs to the operator. A regulator, or an internal audit team, gets access through the operator's governance services or Auditor Explorer, on terms the operator sets.

What the operator can read

The operator doesn't see activity inside a participant's Rayls Sovereign chain (Privacy Node in the code) that never crosses the Hub, such as payments between two clients of the same institution. That stays in the institution's own records.

The tools

The operator runs three governance services and a web interface:

• Listener. Reads each Hub block shortly after it is produced, decrypts what it can and stores the result.
• Flagger. Keeps a running balance for each chain and token. It flags a transfer that would take a chain's balance below zero, for tokens that Enygma's zero-knowledge proofs don't already cover, and a participant whose block headers stop arriving.
• API. Serves transactions (by message, batch, Enygma batch or DvP swap), participants, tokens, header proofs and flagged items, plus balances per chain and token.
• Auditor Explorer. A web interface over the API for searching and inspecting decrypted transactions.

See Monitoring cross-chain transactions and Flagging transactions.

What this gives an auditor

• One record. Cross-chain transactions are recorded once, on the Hub, so the operator's view doesn't depend on reconciling each institution's copy.
• Near real time. The listener decrypts transactions as they settle, so issues show up while they're happening rather than at the end of a reporting period.
• Automatic checks. The flagger raises balance and liveness anomalies without anyone looking for them.

Flags are records for a person to act on. They don't block or reverse anything on-chain. If the operator decides to act, it uses its governance powers, for example to freeze a participant or a token. See Governance.

Limits

• Network-wide only. There are no scoped view keys. You can't give an auditor a key limited to one participant, one account, one time window or one transaction.
• No separate auditor. The auditor role in the participant registry is the operator's own audit identity. The optional NETWORK_AUDITOR role in the Hub's access manager has no functions assigned. An auditor who isn't the operator works through the operator's tools.
• Read only. A view key can read but can't sign or spend. Spending needs each institution's spend key, which stays in its own key service.
• Hub traffic only. Activity inside each institution's chain is outside the operator's view.

📘

Capabilities developed for clients

Some audit capabilities, such as decryption levels that the operator configures for a separate auditor, or compliance flags that trigger action on-chain automatically, can be developed for a client's own deployment. This page describes what runs in production today: key agreement uses ML-KEM, and the audit key is the operator's.