Overview

All key material in a Rayls Sovereign deployment is handled by one component, the Cryptographic Trust Suite, which runs as its own process inside the institution's perimeter. Private keys do not leave it. The Relayer never holds a key; it asks the Cryptographic Trust Suite to encrypt, decrypt or sign on its behalf, over a local interface, and receives the result.

That separation is the reason an institution can hold its own keys while still running the rest of the stack conventionally. Compromise of the Relayer does not yield key material, because the Relayer never has any.

---

The keys an institution holds

Three key types are in use, each with a distinct purpose, and they are deliberately not interchangeable.

The separation between sign keys and view keys is the mechanism behind selective disclosure. A party that holds a view key can read a transaction and cannot spend, because spending requires a sign key it does not have. That separation is cryptographic rather than a matter of policy or access configuration, which is what allows an institution to grant a regulator visibility without granting it authority.

---

Where keys are stored

Key storage is pluggable, so that an institution can use whatever it already uses.

Keys are protected at rest through envelope encryption against the chosen key management service, so the material persisted by the Cryptographic Trust Suite is ciphertext rather than key material. Decryption happens through the key management service at the point of use.

Because every encryption and decryption operation goes through the institution's own key management service, the audit trail those services produce covers Rayls key operations in the same way it covers everything else the institution runs. For a compliance function, that means no new audit surface has to be built.

An institution can supply its own keys at install and at rotation, and the keys the platform uses for its own internal services are held separately from the institution's keys.

---

How messages are protected

Every cross-chain message is encrypted end to end before it leaves the institution.

The scheme establishes a post-quantum shared secret between the sending and the receiving institution using ML-KEM key encapsulation, derives a symmetric key from that secret using HKDF-SHA3, and encrypts the payload with AES-256-GCM. Only the intended recipient institution can decrypt, and the Private Network Hub stores and forwards ciphertext without being able to read it.

Carrying a full key-encapsulation ciphertext on every message would be expensive, so the encapsulation is performed once per participant pair at setup and the resulting ciphertext is stored on the Private Network Hub, after which each message carries only a small tag. The saving in per-message overhead is substantial and the security property is unchanged, since the shared secret is still established by post-quantum key encapsulation between exactly two institutions.

The primitive set in use is ML-KEM for key encapsulation, AES-256-GCM for symmetric encryption, HKDF-SHA3 for key derivation, and Poseidon for the zero-knowledge-friendly hashing that the proof system depends on.

---

Auditor access, and its limits

Where a Rayls Private Network has appointed an Auditor, that role can decrypt Private Network Hub data. The mechanism keeps the auditor's reach bounded and makes the boundary structural rather than procedural.

Each institution's Relayer encrypts its own view key against the operator's public key and stores the result on the Private Network Hub as part of its participant record, alongside a message authentication code. The auditing service recovers those keys at startup, verifies the authentication code, and derives the pairwise shared secrets it needs in order to read.

What this gives an auditor is the ability to read. It does not give the ability to sign, to transfer, or to act on an institution's behalf, because the key material involved is view key material and nothing else. The same design also means that an institution can see, on the Private Network Hub, exactly which participant records exist and therefore what has been made readable.

---

Signing keys and rotation

Transaction signing keys support rotation. More than one key can be available per chain, rotation happens on a usage basis, nonce tracking per key prevents conflicts, and keys that have already signed pending transactions remain valid until those transactions settle.

Key generation is on demand, meaning a key pair is created the first time it is needed rather than provisioned in bulk in advance.

---

What this means for a security review

• Key material never leaves the Cryptographic Trust Suite, and the Relayer, which is the component with the most external exposure, never holds a key.
• Key custody rests with the institution's existing key management service or hardware security module, so the existing key governance framework applies without modification.
• The audit trail for key operations is the institution's own key management service audit log.
• Viewing authority and spending authority are separated by cryptography rather than by configuration, so a misconfiguration cannot turn read access into write access.
• The message encryption path uses post-quantum key encapsulation, so traffic captured today is not readable by a future quantum adversary that has not also obtained the institution's keys.