Within a Rayls Private Subnet, there are several different user roles that exist. Let's take a look:

Subnet Participants are transacting institutions that connect their Privacy Ledger to a Subnet to exchange tokens of value with other institutions.

The Governor is the authority of the Private Subnet. They install the Subnet and only they have the power to enforce governance within the permissioned network.

The Auditor is the regulator of the Private Subnet. They have read-only access to the Subnet, are responsible for validating state and transaction proofs, and may have the power to decrypt transaction data from the Commit Chain.

As Subnet Participants have been covered in detail on the Privacy Ledgers page, let's dive deeper on the Governor and Auditor roles.

Private Subnet Governor

A Private Subnet's Governor is empowered to enforce governance rules and make changes to how the Private Subnet operates.

🚧

Note that only the Governor's private key is able to execute updates to the Subnet Governor smart contract.

Below is a summary of the governance features available to Governors in Rayls.

Governance methods

• Approve / reject member registration - add / delete members from member registry
• Approve / reject token registration - add / delete tokens from token registry
• Assign and update Private Subnet member roles (Issuer, Participant and Auditor are default options)
• Freeze / unfreeze member - prevents / enables a Privacy Ledger from sending / receiving messages or tokens across the Subnet
• Query state validation ‘Flagger’ to identify cryptographic proof anomalies between expected state and reported state of Privacy Ledger balances (used to ensure Subnet consistency and security)

Rayls Governor tools

Included within the Rayls Governor installation package are the following tools:

1. Rayls Governor API - enforce governance rules directly into the Governor smart contracts
2. Rayls Custody - update Governance contracts via the Rayls Custody API
3. Governance engine - inter-connected governance smart contracts, with Governor-only authentication
4. Rayls Auditor Application - on our roadmap, coming soon!

---

Private Subnet Auditor

A Private Subnet's Auditor is empowered to continuously cryptographically validate the Subnet's state and transactions. They may also be able (in accordance with the Private Subnet Governance Charter) to peek into the private transactions between Privacy Ledgers, stored on the Commit Chain.

Subnet Auditors are able to "peek" into encrypted transactions as they performed a Diffie-Hellman (DH) key exchange with each Privacy Ledger when they joined the Private Subnet. These DH keys are what enables them to decrypt transactions stored on the Commit Chain, enabling them to regulate the network. These DH keys are stored within Rayls Custody (or another preferred key custody solution).

To keep things simple, think of the Auditor role as having limited read-only access to the cross-Subnet transactions that pass through the Commit Chain (not inside the Privacy Ledgers). If they identify non-compliant transactions, then they may (if allowed / required by the Governance Charter of the Private Subnet) inform the Governor, who can then take action (e.g. freeze a member).

This interplay between an Auditor that monitors and flags (read-only) and a Governor who can enforce rules and changes to the system (write-only) enables a powerful separation of responsibilities. Alternatively, the approach also enables a Private Subnet Operator to play both of these roles at the same time. This is a design choice for the Operator to make when setting up their Private Subnet.

ℹ️

Currently the Governor and Auditor roles managed from the same infrastructure, but we are currently working to technically segregate these roles such that they can be managed by different entities.

Auditor methods

• Query the list and statuses of members registered with the Private Subnet (Member Registry)
• Query the list and statuses of tokens registered with the Private Subnet (Token Registry)
• Query token balances held by each Privacy Ledger (individually and aggregated)
• Validate state commits to proactively prevent double spend
• Decrypt and query cross-Subnet transactions and transaction statuses between Privacy Ledgers within the transaction (block) explorer