Governance
Regulated institutions work within clear rules about who may take part in a market, what may be traded, and who answers for those rules. A tokenised network needs the same: a known authority that sets the rules, a record of them that everyone can check, and enforcement that doesn't depend on each member's goodwill.
A Rayls Private Network is multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub. Governance follows that split:
- the Private Network operator governs the network through the Hub;
- each institution governs its own Rayls Sovereign chain (Privacy Node in the code).
The Private Network operator
The operator is the institution that sets up the Hub and deploys its contracts. It is usually a financial market infrastructure (FMI) provider, such as a central bank, a clearing house or an exchange, or the parent of a banking group that runs a network for its subsidiaries.
The account that deploys the Hub holds the administrator role in the Hub's access manager, and so controls every restricted function on the Hub. The operator can then hand individual powers to other accounts (see Delegating the operator's powers).
What the operator decides
| Decision | How | Effect |
|---|---|---|
| Who joins | Add participants to the participant registry, each with a chain ID, a name and a role | Only registered participants can send or receive cross-chain traffic. See Adding new participants. |
| What each participant may do | Set its role: participant, issuer or auditor | Only an active issuer can register tokens for the network. |
| Whether a participant can transact | Set its status: new, active, inactive or frozen | Only active participants can send or receive. See Freezing participants. |
| Which relayers may write to the Hub | Grant the RELAYER role to each participant's relayer accounts | Without it, a participant's relayer can't submit anything to the Hub. |
| Which tokens can move between chains | Approve a token that an issuer has submitted | Approval activates the token on the issuer's chain, and only then can it be used across chains. See Approving new tokens. |
| Freezing a token | Freeze or unfreeze a token for a list of participants | Those participants can't send or receive the token across chains, or use it in Enygma delivery versus payment (DvP). See Freezing tokens. |
| Which contracts transfers may call | Approve or revoke contract templates. Anyone can propose one. | Enygma program steps can only call approved contract code and functions. |
| Who may broadcast | Allow or forbid a participant to send a message to all participants at once | Controls network-wide broadcasts. |
| What can be swapped in DvP | Register asset groups and the pairs of groups that may settle against each other | Sets which assets Enygma DvP accepts. |
Every change is a transaction on the Hub, so it is recorded there, and participants can read the current registries at any time.
Where the rules are enforced
The Hub copies its registries to every Rayls Sovereign chain: the participant list, the per-participant token freezes and the approved templates. The rules are then checked at these points:
- On the sending chain, before a message leaves. The chain's endpoint checks that both the sending and the receiving chain are active participants, and that the token involved isn't frozen for either of them. If a check fails, the transaction reverts on the sending chain.
- On the sending chain, for Enygma. The chain's Enygma contracts make the same participant and freeze checks for the sender and for every destination.
- On the Hub, for Enygma and DvP. The Hub's contracts verify each zero-knowledge proof. For Enygma, that proof shows the sender can afford the transfer and that no value is created. The Hub also rejects a nullifier it has already seen, which prevents double spending. Only the issuing chain's relayer can change an Enygma token's supply.
- On the receiving chain, for program steps. The programmability executor only runs calls that match an approved template.
The Hub can't inspect ordinary cross-chain messages, because they are encrypted, so their rules are checked on the sending chain.
After the fact: flags
The operator's governance services also watch the network as it runs. The flagger keeps a running balance for each chain and token, from the decrypted transfers and the mints and burns that issuers report. 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;
- a participant whose block headers stop arriving at the Hub.
Flags are records for the operator to investigate in the Auditor Explorer or through the API. They don't block anything on-chain. The operator decides what to do, for example freeze the participant. See Flagging transactions.
Delegating the operator's powers
The Hub's access manager is role-based. It supports:
- roles that can call specific functions on specific contracts;
- admin roles, which grant and revoke other roles, and guardian roles, which can cancel scheduled operations;
- delays: a delay before a new role grant takes effect, and an execution delay that makes a role holder schedule a call and wait before it runs;
- pausing all restricted functions of one contract.
The contracts repository includes an optional set of business roles that an operator can activate: a Private Network operator role (participants, token approvals and templates), a compliance officer role (freezing and unfreezing tokens), a token manager role and a network auditor role. The token manager and network auditor roles don't have any functions assigned, so they are labels only.
Each institution governs its own chain
Each Rayls Sovereign chain has its own access manager, administered by the institution that runs it. The institution decides who can deploy contracts, mint its tokens and administer its chain. The operator has no administrative power inside a participant's chain: it acts on the network through the Hub and the registry copies the Hub sends to each chain.
Why a Hub
Because every participant connects only to the Hub, a network of n participants needs n connections rather than one per pair. A new participant connects to the Hub, and the Hub's registries tell every chain about it.
The Hub also gives the network one place where its rules are recorded and changed, by one accountable operator, while each institution keeps control of its own chain.
Custom rulesThe production release has no governance rules engine or library of ready-made rules: network rules are the registries, roles and checks on this page. Further rules can be written as smart contracts, by you or by Rayls as part of a client's own deployment.
Updated about 15 hours ago