Cryptographic foundations of Enygma

Rayls Enygma lets payments between the Rayls Sovereign chains of a Rayls Private Network settle on the Private Network Hub without revealing amounts, balances or which participant received value (see Who sees what). It does this by combining zero-knowledge proofs, commitments and post-quantum key agreement.

This page lists each primitive, what Enygma uses it for and how it is implemented, and ends with what is and isn't protected against a future quantum computer. The table below summarises them.

At a glance

Zero-knowledge proofs

A zero-knowledge proof shows that a statement is true without revealing why. Enygma uses Groth16, which produces small proofs that are cheap to verify on-chain, over the BN254 curve, built with the gnark library.

The circuits are:

• Payments: transfer, deposit into DvP and withdraw from DvP, each in versions for an anonymity set of k = 2, 3, 4, 5 and 6 participants;
• DvP: a JoinSplit circuit for Enygma coins and for ERC-1155 coins, and an ownership circuit for ERC-721 coins.

The proofs API (rayls-sovereign-gnark-api) generates proofs server-side for the relayers. A verifier contract for each circuit, and each k, checks them on the Private Network Hub, the Hyperledger Besu chain at the centre of the Rayls Private Network.

A transfer proof shows that:

• the sender is in the anonymity set and knows the secret key behind its public key;
• the sender knows the opening of its previous balance commitment, and the amount it sends is between zero and that balance;
• the new commitments are well formed and add up to zero;
• the random factors, the nullifier and the message tags are correctly derived from the sender's shared secrets and the block number.

Trusted setup

Each Groth16 circuit needs proving and verifying keys made in a one-off trusted setup. Whoever knows the setup's secret randomness could forge proofs. The keys in the open-source repository come from a single-party setup and are for development and testing only. A production network should use keys from a multi-party ceremony, where the setup is safe as long as one participant destroyed their share.

Pedersen commitments

A Pedersen commitment to a value v is C = v·G + r·H, where G and H are points on an elliptic curve and r is a random factor. It hides v, and the committer can't later change it. Enygma uses the Baby Jubjub curve, which works efficiently inside BN254 circuits. H is derived by hashing to the curve ("nothing up my sleeve"), so no one knows a relationship between G and H that would let them open a commitment to a different value.

Commitments can be added: C(v₁, r₁) + C(v₂, r₂) = C(v₁ + v₂, r₁ + r₂). Enygma uses this in two ways:

• Running balances. Each participant's balance on the Hub is the sum of every commitment it has received, so the Hub updates balances without seeing them.
• Zero-sum transfers. In a transfer, the values and the random factors of all the commitments each sum to zero, so the commitments add up to the identity point. The proof checks this, which shows that no value was created.

The random factors aren't arbitrary. Each one is a Poseidon hash of a shared secret between the sender and a receiver and the block number, so only the parties to that secret can work them out.

Pedersen commitments are used for payment balances only. DvP coins use Poseidon commitments (see below).

Poseidon

Poseidon is a hash function designed to be cheap inside zero-knowledge circuits. Enygma uses it for public keys, nullifiers, message tags, random factors and DvP coins. Different uses are kept apart by domain-separation constants.

Keys

Each participant has two kinds of key, generated by its key service:

• Spend key. A secret key sk, with public key pk = Poseidon(sk, sk). It proves ownership when spending. It stays in the participant's key service, encrypted with a key management service.
• View key. An ML-KEM-768 key pair. Other participants use the public key to agree secrets with it, and the private key reads the participant's messages. The view key can't spend. At registration, the view private key is encrypted to the Private Network operator. See Who sees what.

Key agreement with ML-KEM

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key-agreement standard that NIST published in 2024 as FIPS 203. Enygma uses ML-KEM-768 to:

• agree a shared secret between every pair of participants when a participant joins the network;
• give each participant its view key;
• protect the terms of DvP swaps for the counterparty.

ML-KEM replaced CSIDH (Commutative Supersingular Isogeny Diffie–Hellman), which the Rayls research papers use (ePrint 2025/1639, ePrint 2025/1638), for every view key and every shared secret, in February 2026.

Encryption

Transaction messages and DvP terms are encrypted with AES-256-GCM. The keys are derived from shared secrets with HKDF over SHA3-256.

Nullifiers

A nullifier is a one-time value that marks something as spent without revealing what was spent:

• Payments: Poseidon(sender's hashed secret, block number), so each participant can send one Enygma transaction per block. The Hub rejects a nullifier it has already seen.
• DvP coins: Poseidon(sk, leaf index), unique to each coin.

Message tags

Each transaction carries a tag for every participant: Poseidon(Poseidon(12), shared secret, block number). A receiver recomputes the tags for its own shared secrets to find the messages meant for it, without trying to decrypt every message on the Hub. The circuit checks that the tags are correctly formed.

DvP coins

A DvP coin is a Poseidon commitment to its owner's spend public key, a random salt, the amount or token ID, and the asset. It is stored as a leaf in a Merkle tree in the asset's vault. Spending coins needs a proof of membership in the tree and the coins' nullifiers. See Private DvP with Enygma.

Quantum computers

Enygma's design, as set out in the Rayls research papers, aims at quantum privacy: an attacker with a quantum computer who records Hub data today still can't recover the amounts, or who received them. The random factors that hide amounts come from ML-KEM shared secrets, which a quantum computer isn't known to break.

Enygma's proofs are not quantum-secure: a large quantum computer could forge them.