I set out to find one single fact: who can add a new bank to a Rayls Private Network. The first pass at an answer turned out to be right but incomplete and the missing piece was sitting on a page search engines don't index.
Rayls' general Sovereign overview, updated 17 September 2026, describes a Rayls Private Network as "permissioned, governed by participating institutions." Plural. Rayls' dedicated roles page by contrast, is unambiguous about who actually runs one: "The Operator is the authority of the Private Network. They install the Private Network and they alone hold the power to enforce governance."
Both pages are current. Neither links to or qualifies the other. Everything in this paragraph is Rayls describing its own system in prose which is a real source but still a claim made by the vendor about itself, not yet checked against anything that runs independently of that prose.
What the documentation says the Operator holds
The roles page states that authority in a dedicated warning callout, not buried in regular prose: only the Operator's own private key can execute updates to the Private Network Operator smart contract. One key, one party, flagged for emphasis.
Rayls' setup guide for adding a new participant names that key directly. The environment variable is PRIVATE_KEY_SYSTEM, described as the private key used for the Hub's contract deployment, "known to the Private Network Operator." The same guide's prerequisites require the governance contracts to already be deployed, by whoever held that key first before anyone else can be added. The roles page lists five governance methods that key unlocks: approving or rejecting member registration, approving or rejecting token registration, assigning member roles, freezing members, and querying the proof system that keeps the ledger consistent. None of the five is described anywhere in that documentation as requiring a vote among existing members. That is an absence I can confirm in the documentation I read; it is not, on its own, proof that no such mechanism could exist undocumented
What is independently checkable beyond the documentation
Prose can be rewritten without warning. Code, once deployed, is harder to quietly change, so it is worth asking whether any of this is verifiable at that level rather than taking Rayls' own description on trust.
One avenue is public. Rayls maintains an open-source repository, rayls-sovereign-contracts, which its own GitHub listing describes as covering "Privacy Nodes, a Private Network Hub, and privacy-preserving cross-chain messaging via Enygma," written in Solidity under the Apache 2.0 license with four listed contributors. Its existence is itself a fact worth having: the Hub's governance logic is implemented as smart contracts rather than as an internal backend policy a vendor could alter unilaterally and silently, which is a meaningfully different trust model from "the company says so." Confirming that in code, rather than in prose, means pulling the actual contract source and checking for an explicit Operator-only modifier the way the roles page describes it. That check is not completed here.
The repository is public, so it remains open for anyone who wants to run it directly, and nothing above should be read as a claim about what the code says, only about what the documentation says.
Testing it against Rayls' own worked example
Rayls publishes its own worked examples on a page marked noindex in its own metadata, meaning it will not surface in a search engine even though it is live, current documentation.
The first worked example is exactly the case worth testing: a central bank setting up a national CBDC network. Step one, in Rayls' own words, has the bank "assigns itself as the Private Network Operator, using its 'master' private key to deploy the governance smart contracts." Step three has that same bank approving its own minting node as Issuer. Step four assigns every commercial bank the lesser role of Participant, because the page states, only the central bank should be able to mint the currency in the first place. A second worked example, a tokenised bond exchange run by a platform registrar, follows an identical shape: the registrar installs the network, assigns itself Operator with its own master key, then approves each commercial bank afterward, one at a time.
Run the plural description through either case and it fails the same way both times. A central bank does not co-deploy its governance contract with the commercial banks it has not admitted yet, and a platform registrar does not ask the first bank's permission before approving the second.
Where the plural description does hold
Rayls' own examples do not stop at two, and the third is the one that complicates a clean verdict.
The same design-options page describes a third configuration: an NFT marketplace Private Network run by a decentralised autonomous organisation, where membership and token-registration decisions follow rules that governance token holders vote on, rather than a named institution's own discretion and where Rayls' own text states the design works without any single entity or individual holding control over what activity is permitted.
The mechanism documented in the first two examples stays intact here, as far as the documentation describes it. The Operator smart contract, the single deployment key, the member and token registries: nothing on the design-options page suggests those stop existing in the DAO case. Only one thing changes: who or what occupies the Operator position. That part is my own architectural reading, not a sentence Rayls' page states outright. The design-options page describes the outcome, a DAO voting on governance rules with no single entity in control, without spelling out the exact technical mechanism that seats a DAO in the Operator role. Given that the roles page describes no second pathway to Operator authority besides holding that one key, the most consistent reading is that a voting or multisig contract address sits where a central bank's own address sits in the first two examples.
Rayls' documentation does not say that in those words; it is the inference that fits the pieces that are documented. If that reading holds, the plural phrasing stops being loose marketing and becomes a reasonably fair description of that specific deployment, even though it isn't the shape either of Rayls' institutional examples takes.
That matters for how broadly the correction should be read. It would overstate the case to say Rayls' documentation never describes collective control; the DAO example shows it does, explicitly and by name. It would equally overstate the case to treat that example as representative of what Rayls builds for banks and central banks, which is the audience the brief's own worked example and this piece, set out to test.
Where this pattern shows up elsewhere
The same split between framing and mechanism shows up at other permissioned-ledger vendors, not just Rayls.
R3's Corda documentation uses an almost identical title for the default case: the Network Operator, who "onboards participants of a business network," per R3's own glossary. Corda's architecture docs name the mechanism under that title directly: "you need a certificate from the network operator to join." A certificate issued by one party, in Corda's standard deployment, not a vote recorded among existing ones.
Hyperledger Besu, the software Rayls recommends for running the Hub itself documents an identical default-to-exception structure inside one project. Its concepts pages describe permissioning as requiring a distributed network of trust among participants. Its how-to documentation is flatter: "only admin accounts can add or remove nodes from the permission list," and those admin addresses are set once, as a deployment parameter written into the network's genesis file, by whoever deploys the permissioning contract first. All three platforms default to one key in their standard documented deployment. Rayls' own third example is the clearest evidence here that a more distributed arrangement is possible by design elsewhere, built deliberately, when someone puts a voting mechanism into the Operator role instead of a single institution.
So which description is true
Both, pointed at different things.
The plural phrasing is accurate as a description of who a Rayls Private Network is for: institutions transacting with each other as opposed to a retail-facing public chain. By Rayls' own third worked example, it can also be an accurate description of a specific deployment, one where a DAO's vote, not a bank's treasury, sits behind the Operator's single key, on the architectural reading set out above.
In the two configurations Rayls documents as its primary institutional use cases, the central bank CBDC network and the tokenised asset exchange, that same phrasing describes the network's category rather than its control structure. Rayls' own wording for who holds control there is direct: the Operator holds that power alone. That sentence and the setup guide's environment variable live on two different pages, and connecting them, the authority named on one page and the specific key named on the other, is a reasonable reading rather than a quote Rayls has written as a single continuous claim. Nothing in either page or in the worked examples, suggests a different key or a second authority.
The practical test for an institution evaluating this, or any permissioned platform making a similar claim, is to skip the category language and find the worked example. Ask who is named in step one, whether every participant that follows is reacting to a decision that party already made by itself and, where the vendor publishes its source code, whether anyone has actually read the contract rather than the page describing it.