Auditability without surveillance: why mathematical enforcement beats trusting the code

The discussion of blockchain privacy frequently collapses into a binary. Either you are on a public chain where everything is visible to everyone, or you are on a private chain where everything is hidden from anyone outside the network. Neither model works for regulated finance.

A bank does not need full transparency. Its trading positions, client relationships, and balance-sheet structure are commercially sensitive, and broadcasting them would create competitive harm before settlement is even complete. But it cannot operate in full opacity either. Regulators need to see what they are entitled to see. Counterparties need to see what is contractually necessary for them to see. Internal compliance functions need their own visibility. Tax authorities need theirs. None of those parties need, or should have, visibility into anything beyond their specific entitlement.

This is auditability. It is not the same as transparency, and it is not the same as opacity. It is a specific design problem with specific requirements: who can see what, under what conditions, with what proof of correctness, and with what assurance that the boundaries are enforced.

Three approaches have emerged in the market. They look superficially similar. They are not equivalent, and the differences matter enormously for institutions whose audit and disclosure obligations are non-negotiable.

Three models, three different sources of trust

The three approaches differ in where the trust ultimately rests.

Mathematical enforcement. Auditability is enforced by the cryptographic construction itself. The system supports keys that can be scoped to particular subsets of data, and the construction makes it cryptographically infeasible to access anything outside the scope of the key. The boundary is not a configuration that can be overridden by an administrator or a platform operator. It is a mathematical constraint. This is the Enygma model.

Hardware-rooted trust. Auditability is enforced by the integrity of a trusted execution environment. Auditable code runs inside a secure enclave on a hardware chip, and the audit interface is provided by that code. The boundary holds if the hardware seal is intact and if the code inside the enclave faithfully enforces the rules it claims to enforce. This is the TEE-based model.

Policy-based access control. Auditability is provided by access control rules enforced by the network operator. The network is opaque to outsiders, and the operator decides who gets to see what, typically through administrative configuration. This is the traditional permissioned private chain model.

For a regulated institution, these three models have radically different implications. The differences are not academic. They surface at the moment that matters most: when the auditor needs the data, when the regulator asks the question, when the dispute reaches the court.

How mathematical enforcement works

In the Enygma model, the cryptographic construction separates two different powers that other systems fuse into one.

The spending key authorises operations: moving funds, executing transactions, transferring assets. The viewing key grants visibility: the ability to decrypt and inspect specific transactions.

The two keys are bound mathematically but operate independently. The viewing key is constructed in such a way that it provides access to the data but contains no information that would allow it to be used to authorise operations. The spending key is constructed in such a way that it controls authority but does not, on its own, provide any general decryption capability beyond what is required for the user's own state.

This separation has practical consequences that are easier to feel through examples than to argue through abstractions.

A regulator can be given a viewing key scoped to a specific bank's transactions over a specific time window. The regulator can inspect those transactions in full detail. The regulator cannot move any funds, alter any records, or perform any operation that affects the state of the system. If the regulator's environment is compromised, the attacker gains visibility into the audited window. They do not gain spending authority over any account.

A counterparty bank can be given a viewing key scoped to a specific bilateral relationship. The counterparty can verify the transactions between the two institutions. It cannot see transactions with any other party.

An internal compliance function can be given a viewing key scoped to anti-money-laundering analysis, with visibility into the patterns required for AML screening but not into the full commercial detail of underlying trades.

A tax authority can be given a viewing key scoped to settlement events with tax implications.

In each case, the entity granted access can see exactly what they are entitled to see and nothing else. The boundary is not enforced by a policy that an administrator can override. It is enforced because the cryptographic construction of the viewing key does not include the ability to access anything outside its scope.

The institution holding the spending key retains data sovereignty. Visibility can be granted without granting authority, granted to multiple parties with different scopes, and revoked without affecting historical auditability.

Why hardware-rooted trust falls short

The auditability model in a TEE-based system rests on two trust assumptions that are not present in mathematical enforcement.

The first is trust in the hardware. The security guarantee of a TEE rests on the integrity of the chip manufacturer's root of trust. If that is compromised, by a hardware flaw, a supply chain attack, or a vulnerability in the attestation mechanism, the audit interface cannot be relied upon. This is not a theoretical concern. Intel SGX has had documented vulnerabilities that broke the isolation guarantees under certain conditions. ARM TrustZone has had its own incidents. Hardware roots of trust are sound in expectation, but their failure modes do exist, and when they fail, the failure is invisible to everyone except the attacker.

The second is trust in the code. A TEE attests that a specific piece of code is running inside the enclave. It does not attest that the code does what it claims to do. The attestation mechanism produces a hash that confirms the code is the same code that was reviewed. The correctness of the code itself depends on the developer's claims, on any code review that has been performed, and on the absence of bugs. For institutions operating under regulatory obligations that require demonstrable controls, this creates a problematic dependency. The audit assurance flows from the chip manufacturer and the code reviewer, not from a property of the system that the regulator can verify independently.

The contrast is sharp. In a mathematically enforced model, the regulator does not need to trust the chip manufacturer, the code reviewer, the system operator, or the institution. The cryptographic construction provides the boundary. In a TEE-based model, the regulator trusts the hardware vendor and the code that has been reviewed.

For regulated institutions whose compliance posture must withstand adversarial scrutiny, the difference between "the mathematics requires this to hold" and "the hardware vendor's seal says this is holding" is material. Both might be true in practice. Only one is provable from first principles.

Why opaque private chains fall short

Private blockchain networks, operated by consortium members with access restricted to permissioned participants, have been promoted for institutional use cases for years. The intuition is straightforward: keep the network closed, and the data stays private.

The problem is that "private" in this sense means "the network operator controls who sees what." That model has three significant limitations for regulated finance.

The access boundary is administrative, not cryptographic. The network operator can grant access. Anyone with sufficient operational privilege can see everything. This is the opposite of what regulated institutions need: a model where the institution itself retains sovereignty and decides what is disclosed and to whom, not a model where a network operator does it on their behalf.

Audit access is not selectively scoped. When a regulator needs visibility into a specific account or time window, the audit interface typically provides access to broader data than the regulator strictly needs. There is no cryptographic mechanism to enforce a tight boundary between what the regulator can see and what they cannot. The boundary, when it exists at all, is enforced by trust in the operator's access control implementation.

Private chains are typically disconnected from the public ecosystem. Tokenised assets on a closed network cannot easily move to a public chain where global liquidity and counterparties already exist. The privacy comes at the cost of access to the infrastructure that increasingly defines the value of being on-chain in the first place.

The older generation of permissioned blockchain projects (Hyperledger consortia, R3 Corda networks, early CBDC pilots on closed infrastructure) demonstrated the problem in practice. The privacy was real, but it was the wrong kind of privacy. It was the privacy of a walled garden, not the privacy of a sovereign institution operating in a shared global market with mathematically enforced disclosure controls.

What institutional auditability actually requires

For a regulated institution evaluating an audit model, six properties matter. They are not negotiable for serious compliance use cases.

Selective disclosure: the ability to grant visibility to specific data, not all data. Auditors should see what they are entitled to see and nothing more.

Scoped access: the ability to bound that visibility by account, time, asset class, counterparty, or other dimensions relevant to the audit purpose.

Separation of visibility from authority: the auditor can see, but cannot act. The visibility credential does not carry operational power.

Verifiability of correctness: the auditor can confirm that the data they see is genuine and complete, not selectively curated by the institution. Mathematical proofs of correctness are stronger than operational assurances.

Revocability: visibility can be withdrawn, and the withdrawal is enforced cryptographically rather than relying on the cooperation of the party whose access is being revoked.

Durability: the audit trail remains accessible and verifiable years after the events it records, surviving key rotation, software upgrades, and operational change.

A system that meets all six is institutionally auditable. A system that meets only some of them requires the institution to compensate for the gaps through additional operational controls, which is a real cost and a real residual risk.

The three models map differently against these six properties.

Mathematical enforcement, by construction, delivers all six. The cryptographic separation of viewing keys and spending keys provides scoped, revocable, verifiable selective disclosure without conferring authority. The durability question is one of key management, which is addressable.

TEE-based models can deliver selective disclosure and scoped access, but the assurance flows from hardware and code rather than from mathematics. Revocability and verifiability of correctness are operationally complex and depend on the attestation mechanism being intact.

Policy-based private chains deliver selective disclosure in principle, but the scope is rarely cryptographic, the separation of visibility from authority is rarely enforced, and the verifiability of correctness depends on trust in the operator.

How this lands in real regulatory scenarios

The differences become concrete in specific institutional workflows.

A bank participating in a CBDC pilot needs to give the central bank auditor access to its transactions on the network. With mathematical enforcement, the bank generates a viewing key scoped to the central bank's regulatory entitlement and shares it. The central bank can inspect every transaction within scope. It cannot move funds. The bank retains operational control. This is the model used in the Drex pilot in Brazil and is the architectural pattern that Project Agorá and similar BIS-led multi-currency efforts are converging on.

A multinational bank operating across DORA-regulated jurisdictions needs to demonstrate cryptographic risk management as part of its operational resilience reporting. With mathematical enforcement, the cryptographic controls themselves are the demonstration. The institution can point to specific, verifiable properties of its cryptographic infrastructure rather than to operational policies and access logs.

A tokenised fund issuing shares across multiple jurisdictions needs to give different regulators different views of the same asset. With mathematical enforcement, each regulator receives a viewing key scoped to their jurisdictional entitlement. The fund operator retains spending authority. The investors see only what they are entitled to see, which may be different again from what either regulator sees.

A counterparty in a delivery-versus-payment settlement needs to verify that the other side of the trade has happened correctly. With mathematical enforcement, the verification is provided by a proof, not by access to the full transaction history of the other institution. The counterparty learns what it needs to learn and nothing more.

In each of these cases, the institutional requirement is the same: visibility for those entitled to it, opacity for everyone else, and a boundary enforced by something stronger than the operator's promise to enforce it.

The Rayls position

Rayls approaches the auditability problem at the architectural level, not as a single feature. The ecosystem operates on three distinct layers of privacy, each playing a different role in the institutional architecture.

The public chain. The Rayls public chain is completely transparent. This is the layer where shared liquidity sits, where global counterparties connect, and where settlement events are recorded in a form that anyone with access can verify. Transparency is the right property at this layer, not a problem to be designed around.

The Privacy Node. Each institution operates its own Privacy Node, holding its own keys, its own data, and its own state. Sovereignty over institutional data sits inside the node. The connection between the Privacy Node and the public chain is governed and compliance-controlled: the institution itself decides what remains private within the node and what is bridged to the public chain. Data sovereignty is enforced at the architectural boundary rather than negotiated through an operator or imposed by the network.

The Enygma framework. Enygma is the cryptographic protocol that adds verifiability and auditability to every transaction that flows through it. It is the layer that delivers mathematically enforced selective disclosure: the spending-key and viewing-key separation, scoped audit interfaces, and the cryptographic constructions that allow regulators to verify what they are entitled to verify without compromising the rest of the data. Enygma is deployable on Rayls and on other EVM-compatible chains, which means the audit and verifiability properties travel with the protocol rather than being tied to any single network.

The three layers compose into an architecture where transparency, sovereignty, and auditability are different properties supplied by different parts of the stack, and where the institution holds the controls that determine how each property applies to a given flow. The model is described in detail in the academic specifications of Rayls I and Rayls II on the IACR cryptology archive, which provide the cryptographic definitions and security proofs that institutional buyers can validate independently.

The architectural choice is not stylistic. Regulated institutions cannot outsource their assurance model to a chip manufacturer's attestation, and they cannot outsource it to a network operator's access control. The cryptographic proof has to stand on its own, because in the situations where the audit model matters most, the operational and hardware-based fallbacks become the weakest point in the assurance chain.

‍