Who sees what: privacy and oversight

Enygma hides amounts, and who receives each payment, from the other members of a Private Network. It doesn't hide who sends, and it is not private from everyone. The Private Network operator can read every transfer, and some actions, such as minting, are public on the Private Network Hub, the Hyperledger Besu chain at the centre of the Rayls Private Network. This page sets out what each party can see and do.

What each party can see

Party	Can see	Can't see
Anyone who can read the Hub, including Hub validators and every member of the network	Which participants (up to six) were in each Enygma transaction, and which of them submitted it (the sender); the commitments, nullifiers and encrypted messages; the token and the time; the amount and the participant of every mint and burn	Transfer amounts, balances, and which of the other participants received value
A participant in a transaction	Everything above, plus its own decrypted message: what it received, or that it received nothing	The other participants' messages and balances
The receiving institution	The transfer it received, as it mints the tokens on its own chain	Other transfers it wasn't part of
The operator of a Rayls Sovereign chain (usually the institution itself)	All client balances and payments on its own chain, which are ordinary ERC-20 records there	Other institutions' chains
The Private Network operator	Every Enygma transfer in the network, decrypted: sender, receiver and amount. See The operator's view.	Spend keys. It can read transfers but can't sign them.

The anonymity set and small networks

Each Enygma transaction names k participants, where k is the number of participants in the network, capped at six. Participants who aren't part of the payment receive a commitment to zero.

The anonymity set hides the receivers. It doesn't hide the sender: each transaction is submitted to the Hub from the sending participant's own account. The Rayls research papers (ePrint 2025/1639, ePrint 2025/1638) describe a design that also hides the payer. The current implementation doesn't. How much it hides about the receivers depends on the size of the network:

Participants in the network	What the anonymity set hides
2	Nothing between the two: the only possible receiver is the other participant. Amounts stay hidden.
3	Limited. A participant that is in a transaction and receives nothing knows that the sender paid the third participant.
4 to 6	Every participant is in every transaction. Anyone else learns only that the sender may have paid one or more of the others.
More than 6	Each transaction includes six participants. Observers learn only that the sender may have paid one or more of the other five.

Zero-value validation transactions, which the relayer sends to finalise each transfer, mean that a transaction doesn't always carry value. That weakens what an observer can infer from any single transaction.

The operator's view

When an institution registers in the network (see Adding new participants), its key service encrypts the institution's view private key to the Private Network operator, as part of the registration. Registration can't complete without this step. With those keys, the operator's governance services decrypt every Enygma transaction on the Hub (and every other message that crosses it: see Auditing), and the Private Network Auditor Explorer shows each transfer's addresses, chains and amounts.

In practice:

Audit access is network-wide. The operator, or whoever it gives access to its tools, such as a regulator, sees every transfer in the network.
There are no scoped view keys. You can't give an auditor a key limited to one account, one time window or one transaction.
A view key can't move funds. Spending needs the institution's separate spend key, which stays in its own key service. With view keys only, the operator can read but not spend.

Who can change what

Action	Who	Where	Notes
Freeze a token for a participant	The Private Network operator, or a compliance officer it appoints	Hub token registry	A frozen participant can't send the token through Enygma or use it in DvP. See Freezing tokens.
Mint and burn supply	The token's issuer	Issuer's chain, then Hub	The amount and the participant are public on the Hub.
Burn a holder's balance on a chain	Owner of the token contract on that chain	That Rayls Sovereign chain	`burn(from, value)` doesn't need the holder's approval.
Approve a token for the network	Private Network operator	Hub	See Approving new tokens.
Approve contracts for program steps	Anyone can propose one; the Private Network operator approves or revokes it	Hub template registry	Standard Rayls templates are pre-approved. Only approved contract code and functions can run on arrival.
Spend a participant's balance	Only that participant, with its spend key	Through its own relayer	Neither the operator nor the issuer can spend it.

Designing for these properties

If participants must not learn each other's activity, plan for at least four participants in the network.
Assume the network can see when each participant sends, and how often, but not to whom or how much.
Treat the Private Network operator as able to see all Enygma activity, and choose the operator accordingly. See Private Network roles. In a central bank digital currency (CBDC) network, for example, that is usually the central bank.
Payments between clients of the same institution never reach the Hub. They are as private as that institution's own chain.