Overview

Rayls Sovereign is a small set of components that an institution installs inside its own perimeter, organised into a ledger layer and an infrastructure layer, together with a shared component that the institution connects to but does not own.

Rayls uses a hub-and-spoke topology. Each institution operates a spoke, consisting of its own Rayls Sovereign ledger and the services that run alongside it, and every spoke connects to a single shared Private Network Hub that routes encrypted messages between institutions. No spoke communicates with another spoke directly, and the Hub never sees the contents of the messages it carries.

This page sets out what each component does, which components are required, and how they communicate. For the deployment topologies and resource envelopes those components need, see Deployment options and system requirements.

---

The two layers of a Rayls Sovereign deployment

The ledger layer is the Rayls Sovereign ledger itself, which is the institution's own EVM-compatible blockchain. It executes local transactions, holds the institution's token contracts and business logic, and exposes a standard Ethereum JSON-RPC interface.

The infrastructure layer is the set of services that connect that ledger to everything outside it. The Relayer carries cross-chain messages, the Cryptographic Trust Suite handles all key material and all encryption, and a PostgreSQL store holds Relayer state so that the Relayer can resume cleanly after a restart.

Applications and users interact with the infrastructure layer rather than reaching into the trust-sensitive paths directly. All cryptographic signing is delegated to the Cryptographic Trust Suite, and all cross-chain transport is delegated to the Relayer.

---

Component inventory

Required to run Rayls Sovereign

Required to use Enygma

Shared, not owned by the institution

Optional

---

The Rayls Sovereign ledger

The v3.0 ledger is Axyl, a Rust implementation that separates ordering from execution. The consensus layer implements Narwhal and Bullshark, a directed-acyclic-graph design in which workers build and validate transaction batches and primaries certify batch headers into the graph, with Bullshark defining how that graph is ordered into a linear chain of commits. The execution layer is built on Reth and produces standard Ethereum EVM blocks, serving the ordinary eth_* JSON-RPC surface.

The practical consequence for a developer is that nothing about Axyl requires bespoke tooling. Hardhat, Foundry, Remix, ethers.js, web3.js, viem and MetaMask all work unchanged, because the interface they talk to is the standard Ethereum one.

Because the EVM hardforks run through Prague from genesis, EIP-1559 fee-market behaviour and EIP-7702 smart-account patterns are available from the start, and the secp256r1 precompile is present, which is what supports passkey-based authentication.

Gasless operation

Axyl supports a fully gasless network mode, configured at genesis and immutable thereafter. Because the EIP-1559 base-fee delta is proportional to the parent base fee, a genesis base fee of zero combined with a zero minimum-base-fee floor holds the base fee at zero indefinitely, so transactions in the Rayls Sovereign ledger cost nothing beyond the value transferred. Both the genesis base fee and the minimum-base-fee floor have to be zero for the property to hold.

Contract size

The Rayls Sovereign ledger client raises the EIP-170 contract size limit well above the 24 KB Ethereum default, which allows complex multi-step financial logic and zero-knowledge verification bytecode to sit in single contracts rather than being split purely for size. Contracts intended to deploy on the Private Network Hub or on a public chain remain engineered to 24 KB through a modular design, because the raised limit is a property of the Rayls Sovereign ledger client and not of the contracts themselves.

---

How the components communicate

The Relayer itself runs a set of cooperating internal services rather than a single loop. A listener watches the Rayls Sovereign ledger for MessageDispatched events, a second listener watches the Private Network Hub for DataStored and status events, a Merkle service builds inclusion proofs, executors build and submit transactions to each side, and dedicated services handle Enygma batching, DvP coordination and atomic transaction lifecycle management.

---

What stays inside the institution

Every component listed as required runs inside the institution's own environment, on its own hardware or in its own cloud tenancy, behind its own controls. The Rayls Sovereign ledger holds plaintext balances, counterparties and contract state, and none of that leaves the institution. What leaves is an encrypted payload accompanied by a Merkle proof, and the Private Network Hub can verify the proof without being able to read the payload.

The Cryptographic Trust Suite is the boundary for key material. It runs as its own process, private keys never leave it, and it encrypts key material at rest through envelope encryption against a cloud key management service or an on-premise hardware security module. See Key management and cryptography in Rayls Sovereign.

---

Version consistency

The components have to be at the same release version, or the system will not operate correctly. The six service and contract repositories that make up the v3.0.0 release are versioned together, while the Axyl ledger versions on its own cadence and is at v1.2.0 for that release. The "v3.0" label describes the product stack rather than a single uniform version string across every artefact.

For any deployment, confirm the ledger version and the service version against the release notes before installing, and upgrade the components together rather than individually.