Private Network design options

Rayls Private Networks have been designed to be flexible and configurable, according to the intended purpose of the Private Network and the needs of its users.

That flexibility carries responsibility with it, so the examples below show how the configuration of a Private Network can be tailored to meet the requirements of a specific commercial purpose.

Example 1: A CBDC network

Central bank digital currency (CBDC) networks are generally set up and governed by a country's central bank in order to mint CBDC tokens, which are the central bank's liability, and to transact them between domestic banks.

For this use case the central bank is the authority of the network, the sole issuer of its own currency, and sometimes also the regulator, although in other jurisdictions that responsibility is delegated to a separate financial regulator.

Here is how a Rayls Private Network would be tailored to fit that purpose:

1. The central bank installs the Private Network and assigns itself as the Private Network Operator, using its 'master' private key to deploy the governance smart contracts during installation.
2. The central bank also installs a Rayls Sovereign node to play the role of Mint and manage money supply. That node then requests to join the CBDC Private Network.
3. The Operator, which is the central bank, accepts the registration request and assigns that node the role of Issuer, since only Issuers can register tokens for teleporting across the Private Network between Rayls Sovereign nodes.
4. All other member nodes, meaning the country's wholesale banks, are assigned only the role of Participant, because the central bank alone should be able to mint CBDC tokens and that is the only token that will move around the Private Network.
5. Depending on the jurisdiction, the central bank may also be the regulator and take on the role of Auditor, allowing it to decrypt transactions between the transacting nodes, which in this example are the country's wholesale banks.
6. Alternatively, the central bank may delegate the role of Auditor to a different organisation, which in this example would be the country's financial regulator. Note that only the Auditor is able to view encrypted transactions between Rayls Sovereign nodes, so where the Auditor role is delegated, the Operator can still enforce governance but will have very limited visibility.
7. Where the Operator and Auditor sit in different organisations, smart contracts can be developed to automate the workflow across the Private Network Hub, so that flagged transactions trigger governance actions such as automatically freezing a fraudulent token.

This example shows how Rayls Private Networks can be configured for large financial market infrastructure providers and public sector organisations that require the highest levels of privacy and governance.

Example 2: A tokenised asset exchange platform

Consider next a financial asset tokenisation Private Network.

This network comprises many commercial banks, each issuing its own commercial bank bond tokens and transacting them with the others, together with a 'tokenisation platform registrar' that operates the Private Network and with whom all commercial bank bonds must be registered.

In this example the tokenisation platform registrar acts as the Private Network Operator, playing the roles of both Operator and Auditor at the same time.

Here is how that Private Network would be set up and operated:

1. The Operator installs the Private Network and assigns itself as the Network Operator, using its 'master' private key to deploy the governance smart contracts during installation.
2. The Operator also assigns itself as the Auditor, so that every time a new Rayls Sovereign node joins the Private Network it receives a Diffie-Hellman (DH) key exchange, allowing it to peek into encrypted transactions on the Private Network Hub.
3. Each commercial bank installs its own Rayls Sovereign node and requests to join the financial asset tokenisation Private Network as a member, communicating with the Operator, who then approves or rejects the request.
4. The Operator, in its Operator role, conducts due diligence and approves the requests, assigning each commercial bank the role of 'Issuer', so that each can register its commercial bank bonds for trading with other banks in the network.
5. The Operator in this example also wants to provide a stablecoin that the commercial banks can use to make payments and to purchase commercial bank bonds through a DvP transaction. A regulated third-party stablecoin provider installs a Rayls Sovereign node and is permitted to join the Private Network, where it mints and privately distributes the stablecoin to the other commercial banks.
6. Each commercial bank begins issuing (minting) its commercial bank bonds in its own Rayls Sovereign ledger. As it does so, it requests registration of the newly minted bond tokens with the Private Network Operator. The Operator checks the asset ID for uniqueness against its onchain and offchain systems and, once confirmed, approves the token registration to the Private Network so that it can be traded, updating the registries accordingly.
7. Once the commercial bank bond tokens are registered and the stablecoin is in circulation, the commercial banks can begin trading freely with one another, buying and selling their bonds in exchange for stablecoins with complete privacy and anonymity.
8. In its role as Auditor, the Operator can monitor the encrypted network activity by validating the proofs, meaning the Pedersen commitments, that each Rayls Sovereign node publishes regularly to the Private Network Hub, so as to ensure consistency, legitimacy and validity. Note that the Auditor does not have direct access to the encrypted transaction payload data. Any issues can be flagged, and some can be actioned automatically by the Operator role through smart contracts under defined conditions, such as freezing a member.

This example demonstrates a configuration that blends privacy and governance with restricted auditability, covering proofs only rather than the underlying data, unless fraud has been detected. The flexibility on show is what allows Rayls Private Networks to be optimised for precise privacy, governance and compliance requirements.

Example 3: An autonomous decentralised NFT marketplace

The final example is a very different setup.

Here an NFT marketplace is operated by a decentralised autonomous organisation (DAO), where governance rules are determined by votes cast by governance token holders, and the integrity of the Private Network is secured by validators within the Rayls Public Chain.

In this Private Network, Rayls Sovereign nodes represent NFT platform companies, each of which mints its own NFT collections on behalf of its customers and allows them to be transferred freely and internally between its customer accounts.

The steps involved are as follows:

1. When the NFT platforms request to join the NFT Marketplace Private Network as members, the DAO approves automatically so long as they meet the basic criteria, and automatically assigns them the role of 'Issuer' so that they can register their NFT tokens.
2. Note that the NFT provider must also agree to the terms and Governance Charter of the Private Network as voted for by the DAO's governance token holders, and is therefore bound by the outcomes of those terms in the event of malicious actors or of problems when transacting.
3. NFT platforms can then register their NFT tokens with the DAO Operator, which again approves automatically on the basis of pre-defined criteria and token uniqueness, meaning that the token has not already been registered.
4. As voted on by the DAO governance token holders, payment for NFT tokens can be made within the Private Network through a number of options, such as the Rayls token ($RLS), a third-party stablecoin that has been issued within the Private Network, or specified cryptocurrencies such as ETH.
5. NFT tokens are bought and sold privately across the NFT Marketplace Private Network between Rayls Sovereign nodes.
6. The Auditor role is managed by Rayls Public Chain proof verifiers, who have no access to encrypted transaction data unless their proof validations show that fraudulent activity has taken place, which then enables a transaction to be decrypted. For this example, assume that arrangement was defined in the Governance Charter and permitted by the DAO, which acts as the Private Network Operator.

This example demonstrates how Rayls Private Networks can be used to facilitate private and secure transactions within a highly decentralised network, without any single entity or individual holding control over what commercial activity is permitted or access to transaction data.