Inside the engine of scalable privacy

In our first post, we explored why privacy is a foundational requirement for blockchain adoption. From identity protection to confidential transactions and regulatory auditability, we introduced the concept of programmable transparency, our smart glass, giving users the power to control what they share, with whom, and when, all while remaining verifiable onchain.

In the second post, we introduced  Rayls Enygma, our privacy-preserving layer designed for both enterprise-grade and DeFi-ready applications. Built for EVM compatibility and shaped through real-world collaborations like JP Morgan’s EPIC and Brazil’s Project Drex, Enygma combines advanced cryptographic technologies including homomorphic encryption and zero-knowledge proofs, into a seamless, developer-friendly solution.

Now, it’s time to take a look under the hood.

This post is for anyone who wants to understand how Enygma works, not just what it promises. Whether you’re a compliance officer at a financial institution or a developer building DeFi protocols, you’ll see how our architecture enables:

• Auditor visibility without compromising confidentiality
• Scalable private transactions without bottlenecks
• Fine-grained access control using programmable key pairs
• Encrypted communication and message tagging across subnets

We’ll walk through the core phases that power Rayls Enygma and show you how we’ve made privacy a first-class citizen in the Rayls Subnet ecosystem.

‍

The three phases of private interaction

At the heart of Rayls Enygma lie three main phases: Register, Transact, and Audit. These steps govern how data flows securely and privately between two or more participants. For this article, we’ll focus on Enygma’s application layer. If you’re curious about the Rayls privacy node architecture or Rayls' private Network infrastructure, you’ll find detailed documentation  here.

‍

Phase 1: Register – Setting the privacy foundation

To interact with Enygma, a user must generate two cryptographic key pairs:

1. Spending Key Pair – used to authorise and sign transactions
2. Viewing Key Pair – used to decrypt the details of transactions intended for that user

Once these key pairs are created, a post-quantum cryptographic mechanism generates shared secrets between the user and every other participant in the network. These shared secrets enable:

• Encrypted transactions

• Private message tagging

• Selective audit access

This foundational step ensures that only the intended recipient can decrypt transaction details, while allowing authorised auditors to access data if the corresponding view key is shared with them.

‍

Phase 2: Transact – Private, scalable, and programmable

Let’s walk through how a typical private transaction works.

A participant on the network begins by issuing a private token, which triggers the deployment of a smart contract that tracks every transaction involving this token. To preserve confidentiality:

• Token balances are stored as Pedersen commitments
• ZK (Zero-Knowledge) proofs are used to validate each transaction without revealing sensitive data
• Anonymity sets help further obscure sender/receiver identity and transaction flow

Before processing a transaction, the system verifies:

• The sender’s balance (without revealing it)
• That no double spending has occurred
• That the transaction logic meets all conditions for execution

If all conditions are met, the transaction is processed, and the recipient can retrieve the ZK proof, decrypt the information, and update their own balance accordingly.

Enygma also supports programmability with atomicity. This means that transactions can include custom actions — and if any part of the process fails, the entire operation is rolled back automatically to maintain system integrity.

‍

Confidential settlement with DvP

Rayls Enygma also supports confidential Delivery vs Payment (DvP) transactions, a key requirement for use cases such as NFT trading, asset swaps, and interbank settlements.

Here’s how it works:

• Both participants deposit their assets into a DvP smart contract, where each deposit is represented as a UTXO (Unspent Transaction Output)
• Each participant sends a private agreement message to confirm the settlement
• The contract waits for both parties to confirm within a pre-defined time window – customizable per each settlement.
• Optional programmable conditions, such as checking an oracle or verifying asset valuation, can be added before the final exchange takes place

This mechanism ensures both parties agree to the same terms before the swap is executed and that it remains private throughout.

‍

Phase 3: Audit – Transparent oversight by design

Enygma’s approach to auditability is grounded in selective transparency.

In the Rayls ecosystem, we’ve created a dedicated auditor role. Auditors receive view-only keys, which allow them to decrypt and inspect specific transactions for which they’ve been granted access. However:

• Auditors cannot authorise or sign transactions
• Spending rights remain solely with the asset owner

This separation of roles ensures compliance and oversight, without exposing private data unnecessarily, a critical capability for institutions operating under regulatory frameworks.

‍

Bringing Privacy from Theory to Production

With Rayls Enygma, we’ve moved beyond theory to deliver a production-ready privacy solution — one that’s not just cryptographically sound, but operationally practical. Whether you're enabling confidential CBDC transfers, powering private DeFi swaps, or building compliant tokenisation platforms, Enygma offers a privacy layer that is modular, auditable, and designed for scale.

This is privacy you can build with.

‍

In my next post, we’ll explore the future of Enygma and what’s coming next for developers, institutions, and DeFi ecosystems.

If you missed the first two articles, you can catch up here: Rethinking Privacy for Blockchain Adoption and What is Rayls Enygma.

For more information on Enygma please refer to Rayls Docs and our published academic material.

‍

The future of privacy isn’t a black box — it’s programmable, provable, and permissioned by design.

‍