I started staking RLS from the pre-commitment phase; reading the official blog is just a habit. In the article published on September 12 about auditability, the second half lists six standards, saying that everything is fully satisfied “by construction” under mathematical compulsion. I agree with that, but “satisfied by construction” is a claim you can verify, not something you must simply believe. So I spent a week digging up the corresponding evidence for each of the six items from the publicly available source code, technical documentation, and on-chain interfaces—and now I’m sharing it with everyone.
Let’s start with its categorization. I think it’s more useful than most discussions of “privacy vs. transparency.” There are three ways to achieve auditability: mathematical enforcement—embedding it into cryptographic constructions; hardware trust—relying on the integrity of trusted execution environments; and policy-based access control—who can see what is determined by configuration set by the network operator.
It proposes six institution-level auditability standards and then says mathematics enforces that the construction satisfies all six.
To avoid talking too vaguely, here’s a fixed scenario: a bank participates in a CBDC pilot, and the central bank auditor needs to inspect the bank’s transactions on the network. Brazil’s Drex is exactly this scenario, and Rayls is piloting inside it. There’s only one question: why should what the auditor sees be trustworthy.
The first and second items: selective disclosure and scoped limitation.
The destination of these two items is the same thing: the observation key.
Rayls’s GitHub is public. In the relayer repository’s cryptography directory, there’s an mlkem.go file. It contains GenerateSalt, which uses the recipient’s ML-KEM-768 observation public key encapsulation to share a shared secret; RecoverSalt uses the local ML-KEM-768 observation private key to decapsulate; it calls Go’s standard library functions NewEncapsulationKey768 and NewDecapsulationKey768. The variable names are literally “view public key” and “view secret key.”
So the cryptographic basis for the observation key is ML-KEM-768, and this is documented.
Let me add one more point about its significance. In Rayls’s August 30 article about quantum readiness, they specifically emphasized: if a “quantum-safe” claim doesn’t include parameters at the level of specifics, then it’s not an assertion but merely a label; and the examples they gave are exactly not the same—ML-KEM-512 and ML-KEM-1024 are different. In that article, when describing its own upgrade, they only wrote “replaced with ML-KEM.” In the code, it says 768. This isn’t a flaw: 768 is the NIST officially specified parameter set, and it’s also the industry-recommended default for enterprise deployments. It’s just a fact that previously required reading the code to know, but can now be cited directly.
Since the tiers are determined, the cost of switching tiers can be calculated. FIPS 203 fixes the sizes: the encapsulation public key of 768 is 1184 bytes, the ciphertext is 1088 bytes, and both 1024 are 1568 bytes.
The key is frequency, and the key management documentation also states this: encapsulation is done once for each pair of participants during network build; the ciphertext is stored on the private-network hub; afterward each message carries only a small tag. So it doesn’t grow with transaction volume. In a network with 30 institutions there are 435 pairs, and the difference between two tiers is about 215 KB; even with 60 institutions and 1770 pairs, the difference is still under 1 MB—and it’s one-time only.
The amount is so small it’s meaningless—which is exactly the conclusion: if a deployment needs a higher tier, the resistance won’t come from bandwidth or storage; it’s just a change of code. In general quantum-post migration discussions, parameter choices are often performance trade-offs, and at this layer they’re not.
This scope is limited to this item; the technical documentation adds the other half: observation capability can be constrained by time window and by account.
Third item: separation of visibility and permissions.
The technical documentation’s wording is harder than the blog’s: spending keys and observation keys are mathematically independent, and you cannot derive one from the other. In the security review summary, the sentence is even more direct: observation permissions and spending permissions are separated by cryptography rather than configuration, so a single configuration mistake cannot turn read permission into write permission.
The key management documentation also corrected one assumption I’d made. All key materials on the institution side are handled uniformly by a component called Cryptographic Trust Suite, running within the institution’s own boundary. The Relayer never holds any keys; it only acts on behalf for encryption and decryption. An auditor’s read permissions come from this: each institution encrypts its own observation key with the operator’s public key, stores it along with an authentication code in the private-network hub as part of the participant record; the audit service retrieves it at startup.
There’s a side-product document that points it out itself: institutions can see on the hub which participant records exist, meaning they know what of their things are set to be readable. The act of granting visibility is itself visible.
By the way, this page’s three categories of key tables also confirm what I saw in the code: ECDSA on secp256k1 for signing keys, ML-KEM for observation keys, and Baby JubJub on BN254 for spend/payment keys. The documentation and the source code match exactly.
Fourth item: verifiable correctness.
This blog post relies on zero-knowledge proofs. Rayls has a dedicated gnark-api service to generate and verify Groth16 proofs.
The Enygma transaction document provides several specific parameters that are usually not referenced. The anonymous set size is 2 or 6—meaning each transfer will be packaged together with one other transfer or five transfers, so observers can’t tell who initiated the transfer. A single crossTransfer can target up to 5 target chains and carry up to 5 callable actions. The atomicity of a batch is guaranteed by the Enygma contract on the private-network hub: it first verifies the proofs for the entire batch, and only then mints for any destination.
There’s also an operational cost. The document is very direct: batching, proof generation, and hub verification add up to dozens of seconds, so you should plan accordingly—not like the sub-second finality of intra-institution transactions. Verifiability isn’t free; its price is those dozens of seconds.
But there is one place where the wording is worth calling out separately, because it involves four pieces of material.
The technical documentation’s phrasing about Pedersen is firmer than the blog: it says the Pedersen commitment “hides a value, and at the same time binds the committer to that value so it cannot be changed later,” treating binding as a property in the statement. The quantum article from August labels this as requiring no handling, meaning it is already quantum-resistant. In the code enygma_math.go, it shows using two independent generators on the BabyJubJub curve to compute v·G plus r·H—this is the standard and correct Pedersen construction. In Rayls’s two academic papers (IACR IDs 2025/1639 and 2025/1638), the term describing the entire design is “quantum-private,” with the explanation that a quantum adversary cannot infer the payer, payee, and amount of a transaction. This is a claim purely about confidentiality.
My reading is that among the four materials, only the paper’s wording is precise. BabyJubJub is built on the BN254 scalar field, so the hiding property holds for quantum adversaries—this is exactly the portion the paper claims. Binding depends on discrete logarithms—this is the portion the paper does not claim.
For an institution that needs to prove its compliance posture can withstand adversarial review, “a quantum adversary can’t see my balance” and “a quantum adversary can’t forge a fake balance” are two different things—and yet in the documentation and the blog they are written as if they’re one and the same. The paper does not commit this merge.
Fifth item: revocability.
I looked into this for a long time. Rayls’s documentation has a page in a document called “Private Network Design Options” that contains the answer. But it’s not the same thing as what the blog says, and I think it’s even more interesting.
An auditor is a role designated by the operator; alongside it are the participant and the issuer. The key is that the auditor’s visibility isn’t a simple on/off switch—it’s determined by the tier level. This document uses three examples to illustrate the tiers.
In the Central Bank Digital Currency (CBDC) network tier, auditors can decrypt transactions between nodes. In the tokenized-asset trading platform tier, auditors monitor by verifying the Pedersen commitments each node publishes to the hub; the documentation explicitly states that auditors do not have direct access to the encrypted transaction payload data—they only look at proofs, not the content. The DAO-operated NFT marketplace tier is the most extreme: the audit role is performed by an on-chain proof verifier, with default zero access rights. Decryption of that transaction is enabled only when proof verification indicates fraud.
The three tiers are laid out together; the line in the auditor-browser section—“the decryption level can be configured at build time”—is where it lands.
Back to that blog post: it says visibility can be revoked and that revocation is enforced by cryptography. The documentation gives a different design: visibility is set by tier at build time, not revoked after the fact. Both can restrict auditors—one is a pre-constraint, one is post-hoc withdrawal.
Governance layer indeed has a revocation mechanism: roles can be updated; member status can be active, frozen, or disabled; freezing is executed by the operator via the ParticipantStorage governance contract. But I could not find an implementation description for retracting the visibility an auditor already has. There is one detail that makes this issue very concrete: the documentation says auditors receive a Diffie-Hellman key exchange each time a new node joins, and access capability is delivered in the form of key material. I’m still investigating whether removing a role can block future grants and, additionally, whether it can make the already-delivered key material invalid.
Sixth item: persistence.
This item is the opposite of the fifth one: the blog downplays itself.
It says persistence belongs to key management and is solvable, which reads like a blank space. But the key management documentation turns that “can be solved” into a concrete design. Key storage is plug-and-play with what the institution already has: AWS KMS, Google Cloud KMS, Azure Key Vault, and local HSM; only the development environment uses local files. Static envelope encryption is used; what gets persisted is ciphertext, not key material.
The most critical is this sentence. Because every encryption/decryption goes through each institution’s own key management service, the audit trail those services already generate—covering Rayls’s key operations—is the same as covering other things that an institution runs on its own. The compliance conclusion provided to the compliance department in the documentation is: no new audit surface needs to be built for this. This is exactly what persistence wants: audit trails live in the institution’s own system, not in some vendor’s proprietary logs.
Rotation is also described very precisely: each chain can have multiple signing keys; rotate them according to usage. Each key has its own tracked nonce. A key that has already signed a pending transaction remains valid until those transactions are settled. This solves exactly the gap that most often goes wrong during rotation.
However, there is one boundary: the section describing rotation is about signing keys; I didn’t see observation-key rotation in these pages. Persistence is exactly what’s at stake here—whether, years later, the audit trail can still be read—and that depends more on the observation-key side.
The tool the auditor actually uses.
The earlier parts are about cryptography, but what the auditor truly uses when seated is a tool. The documentation states that the private-network auditor’s browser is accessible only to auditors; the operator and other participants cannot access it. It provides a decrypted view of cross-chain transactions.
Scope is limited: it only covers cross-chain transactions recorded to the private-network hub; transactions occurring inside an institution’s own Sovereign ledger are not accessible to auditors. Therefore, the auditor’s visibility is between institutions, not within an institution.
So is there an instance that can be fully verified?
Yes, and only one, because the architecture itself determines that most things can’t be seen.
The official documentation explains the reason: Enygma transactions originate from each institution’s own Sovereign ledger; each institution deploys a browser to monitor its own ledger; the cross-chain part is placed on the private-network hub and viewed by the auditor’s browser. By design, institution activities are not on the public chain, so Enygma transactions are not found on the public-chain browser. This is not a missing piece—it is a necessary consequence of the three-layer architecture.
But that Parfin lock-up contract is on the public chain, and it’s exactly a complete sample of “mathematical enforcement.”
The one starting with address 0x1463889D is the contract name RlsTokenLock; the source code is verified and it is not a proxy contract. That means it’s one of the few objects where you can both read the code and check the current state. I matched both sides.
The constructor declares totalAmount as 1,070,493,535 RLS. The RLS the contract currently actually holds is 1,070,493,535. Not a single wei off—fully funded.
The unlock schedule is even more worth mentioning. The constructor contains 48 timestamps, and I decoded them all: the first tier is December 1, 2027; afterward, each tier is on the 1st day of every month; the last tier is November 1, 2031. The span is about 3.92 years, and each tier is about 22.3 million RLS. Earlier public materials emphasized being locked until December 2027—that is correct for the first tier. The full picture given by the constructor is that after the first tier, there are nearly four more years of monthly releases.
The contract’s own comments state the design intent very plainly: it is not upgradeable; the deployment terms are forever terms; without pre-expiration unlocking, no key can be moved up a tier before the expiration date. I matched these two items against the code one by one. The timetable is written into the constructor without any setter, and the contract is indeed not a proxy.
That’s what “mathematical enforcement” looks like in an instance I can fully validate: the claim matches the code, and the code is more specific than the claim. In the six standards, the things I could only find traces of in the source code and documentation are visible all the way through here.
Two other places with external references.
When the blog talks about TEE, it says Intel SGX had recorded vulnerabilities that broke isolation guarantees. That part is correct, but it plays down its own point. The isolation-type issues include Foreshadow, Plundervolt, EPIC Leak, and SmashEx, with IDs CVE-2018-3615, CVE-2019-11157, CVE-2022-21233, CVE-2021-0186, and CVE-2021-33767. The truly most damaging one is the 2020 SGAxe: it used CVE-2020-0549 to extract the authentication keys themselves from Intel’s certified enclaves in production, and then could issue arbitrary statements that Intel’s own attestation service would judge as legitimate.
The blog’s argument is that the TEE guarantee is provided by proofs issued by hardware, while SGAxe breaks precisely the part that issues those proofs. The most severe failure wasn’t that data was stolen; it was that the guarantee itself was forged. To put it fairly, all of this has been fixed today through microcode updates and TCB recovery. Today’s SGX is not the SGX of 2018. The accurate statement is that the hardware trust root has a rolling vulnerability surface.
Another place says BIS’s Project Agora is converging to the same architecture. I reviewed BIS’s prototype report from May 27; topologically it does look similar, with a two-layer structure, a shared ledger, and independent ledgers per jurisdiction. But Agora’s boundary is defined by jurisdiction; the report doesn’t explain how access control inside the jurisdiction ledgers is implemented. So whether the convergence extends into the trust model layer can’t be seen from existing public materials.
Which parts are confirmed, and which parts are my inferences.
Confirmed: ML-KEM-768 is used for observation keys, see relayer/cryptography/mlkem.go; Pedersen for BabyJubJub generator construction, see enygma_math.go; auditor private keys are encrypted and delivered via the relayer, see governance service/cryptography/service.go; spending keys and observation keys are mathematically independent; the observation scope can be constrained by time and account; the auditor browser only covers cross-chain transactions and the decryption level can be configured at build time—each is shown in the official technical documentation. Cryptographic Trust Suite centrally holds the keys and the Relayer never holds keys; key storage is plug-and-play with KMS or HSM; static envelope encryption is used; audit logs from the institution’s own key-management service are the audit trail of key operations; signing keys are rotated based on usage and keys used to sign pending transactions remain valid until those transactions settle; encapsulation is completed once per participant during network build; anonymous set size is 2 or 6; a single crossTransfer targets up to 5 destination chains; finality is on the order of dozens of seconds; freezing participants is executed by the operator via the ParticipantStorage governance contract—again all in official technical documentation. The validation status of RlsTokenLock, non-proxy attribute, the 48-tier timetable, and declared amount versus actual balance are all read via the public browser interface on September 12, 2026. SGX vulnerability IDs come from the CVE records and the SGAxe paper. Agorá’s structure and data come from BIS publicly available materials.
My inference: among the four pieces of material, only the paper’s wording about Pedersen is precise. The description “enforced by mathematics” is about execution rather than distribution. SGAxe supports the blog’s argument better than isolation-type vulnerabilities. None of these are written in those three materials.
Unverified: the mechanism to reclaim after the fact in the fifth item. I checked five documents: key management, the auditor’s browser, Enygma cryptography foundations, participant freezing, private network design options, and the private network hub. In addition, I checked two code repositories—relayer and governance service. I found a three-tier configuration of visibility, the granting mechanism, and the participant freezing and disabling, but I did not find any implementation of reclaiming already-granted visibility and enforcing it via cryptography. I also couldn’t verify long-term rotation for observation keys; the section describing rotation in the documents is about signing keys.
Finally, something unrelated to the technology.
In the same week as the article was published, the official announcement extended 55% of the staking tiers to September 15th, and said that during the adjustment of the staking mechanism, early supporters would continue to receive that portion of the returns. Future updates about staking and broader token economics, including burning, would be announced separately.
I have been staking since the pre-commitment phase and fully participated for three months. The original tier was scheduled to end on September 9th. In those days, I saw on the interface that the quota was fully used and I couldn’t add more, and for a moment I thought it was a frontend issue. Now it looks like the mechanism is being adjusted.
This is my personal view, not a factual statement: during the window for mechanism changes, instead of cutting things off directly, they chose to extend the period and also clearly wrote out the dates. I think that’s a sincere approach. The most likely thing during a mechanism adjustment period is ambiguous wording; providing a specific date means the deadline will either be honored or explained again.
This is just a specific incident and does not constitute a judgment about any long-term arrangement. I do not predict returns, nor do I suggest that anyone make a decision based on this.
Reference sources: Rayls official blog “Auditability without surveillance: why mathematical enforcement beats trusting the code,” September 12, 2026; Rayls official technical documentation—two pages on Enygma cryptography foundations and the private-network auditor’s browser; GitHub organization raylsnetwork repositories rayls-sovereign-relayer and rayls-sovereign-pnh-governance; Rayls public chain browser explorer.rayls.com addresses and smart-contracts interface (data retrieval time: September 12, 2026); NIST FIPS 203; CVE records 2018-3615, 2019-11157, 2020-0549, 2021-0186, 2021-33767, 2022-21233 and the SGAxe paper; BIS Project Agorá prototype report othp110; IACR cryptographic e-archive 2025/1638 and 2025/1639; Rayls official X account announcement on September 12, 2026.
