Rayls Sovereign

Rayls Sovereign is the piece of Rayls that an institution actually installs and runs. Think of it as a tokenised core banking system: a ledger, a database and the business logic to run them, all sitting inside the institution's own perimeter.

More precisely, Rayls Sovereign is a sovereign EVM-compatible chain operated by a single institution. It executes the institution's internal activity, holds its tokenised balances, runs its smart contracts, and produces the cryptographic material (proofs, commitments, encrypted payloads) that allows it to transact privately with peer institutions across Rayls Private Networks and the Rayls Public Chain.

No external party has access to a Rayls Sovereign ledger. It is installed within the institution's own environment, behind its own firewalls, and operated under its own controls.

What Rayls Sovereign does on its own

Inside a single institution, Rayls Sovereign is enough on its own to:

Issue fungible and non-fungible tokens in the standard ERC-20, ERC-721 and ERC-1155 formats, privately.
Operate accounts and balances for clients, business lines or trading desks, with internal transfers and cash management between them.
Run smart contracts that automate internal workflows or enforce governance rules such as freezing, seizing or locking tokens.
Integrate with existing systems through APIs: core banking platforms, ERP systems, price feeds, identity and KYC stores.
View an internal explorer of all transactions touching the ledger.

Because Rayls Sovereign is EVM-compatible, existing Solidity contracts, audited patterns and developer tooling carry over. Teams do not need to learn a bespoke stack.

What Rayls Sovereign does in concert with others

Rayls Sovereign becomes more interesting when it connects to the ledgers of other institutions, either through a Rayls Private Network (permissioned, governed by participating institutions) or through the Rayls Public Chain (permissionless, EVM-compatible Layer 1).

When connected, an institution running Rayls Sovereign can:

Transact privately and anonymously with other institutions, including payment requests, atomic settlement, and atomic delivery-versus-payment (DvP).
Reach the broader onchain ecosystem through the Public Chain, including dApps and public liquidity pools.
Allow selective audit through Auditor View. A designated Private Network Auditor, usually a financial regulator, holds decryption keys that give it a view of Private Network Hub data without any ability to move value, so spending authority and viewing authority are cryptographically separated rather than enforced by policy.

Privacy across these flows is delivered by the Enygma Framework. The cryptography (zero-knowledge proof generation, Pedersen commitments, encryption, key handling) runs inside the institution's own environment, in two services that sit alongside the ledger. The Gnark API generates the zero-knowledge proofs, and the Cryptographic Trust Suite holds the key material and performs the encryption, decryption and signing. The settlement state lives in smart contracts on whichever chain carries the transaction, which for a Rayls Private Network means the Private Network Hub. Outsiders see that a transaction occurred and that it was valid; they do not see what it contained.

Anatomy of Rayls Sovereign

Rayls Sovereign is a small set of components that together give an institution everything it needs to run privately and to transact privately with others.

Four of them are always present: the EVM node that executes the institution's transactions, the Relayer that carries messages to and from the Private Network Hub and the Rayls Public Chain, the Cryptographic Trust Suite that holds key material and performs encryption, decryption and signing, and NATS JetStream, the messaging backbone that the Relayer and the Governance API depend on.

The rest depend on what the institution is doing. The Gnark API is added where Enygma is in use. The Governance API and the Auditor Explorer are added for participation in a Rayls Private Network. The Rayls Backend and a Blockscout explorer are optional in any deployment.

Every component, what it does, where it runs and whether it is required, is set out in full in Rayls Sovereign architecture and components.

Migrating to Axyl

Rayls Sovereign moved to Axyl in July 2026. Axyl is the consensus algorithm designed for institutional throughput (15,000+ TPS, sub-second finality), a DAG-based Byzantine fault tolerant design derived from Narwhal and Bullshark and running on Reth. It launched on the Rayls Public Chain mainnet on 30 April 2026 and was adopted on Rayls Sovereign after that. The move was phased, so institutions running through the change kept running.

What changed:

EVM node. Geth gave way to Reth, and Clique proof of authority gave way to Axyl.

High availability. The earlier Rayls Sovereign ledger ran as a single Geth node with one validator. Axyl runs Byzantine fault tolerant consensus across a committee, so single-node availability risk no longer applies.

Key management. The Key Management Module became the Cryptographic Trust Suite, a decoupled key-custody component. The Relayer no longer handles or stores keys directly.

Databases. The Relayer moved from MongoDB to PostgreSQL. The ledger holds its consensus and execution state in the node's own embedded store rather than in an external database. MongoDB remains only where an institution deploys the optional Rayls Backend, which uses it for wallet and custody records.

Performance and footprint. Several supporting changes (PostgreSQL in place of MongoDB, the Gnark API for Enygma proof generation, broader infrastructure work) came out of an active resource optimisation effort, and the Axyl release is meaningfully lighter to run than the stack it replaced.

The Private Network Hub is a separate matter. It continues to run Besu with proof of authority consensus and is unaffected by the Axyl rollout.

Operating environment and resources

Rayls Sovereign is intended to run inside the institution's own infrastructure, on commodity hardware, and to scale by adding capacity to its supporting components rather than to the EVM node itself.

Two deployment tiers are published.

Lightweight tier, for development and testing: 2 vCPU, 4 GB RAM, 100 GB SSD, Docker 20.10 or later, and Kubernetes 1.20 or later where Kubernetes is used.

Enterprise tier, for production: 4 or more vCPU, 16 GB RAM, 500 GB high-performance SSD, Docker 24.0 or later, and Kubernetes 1.25 or later where Kubernetes is used.

These figures cover the ledger itself. The Relayer, the Cryptographic Trust Suite, and any optional components, including the Gnark API where Enygma is in use, are sized on top of them.

Performance characteristics:

Sub-second transaction finality.
15,000+ transactions per second in the Rayls Sovereign ledger under Axyl.
Designed for the operational requirements institutions already meet on existing infrastructure: high availability, disaster recovery, monitoring, and integration with the institution's existing identity and credential systems.

How to run Rayls Sovereign

To run Rayls Sovereign, contact the Rayls team (Contact us) and Rayls will help with the setup. Teams that would rather install and operate the stack themselves can use the Rayls Sovereign CLI (rayls-sovereign-cli), which is publicly available on GitHub.