Why Rayls?

The problem Rayls is built to solve

Roughly $100 trillion of regulated capital sits with banks and financial institutions, and almost none of it moves onchain.

The reasons are not mysterious. Public blockchains are transparent by default, and a bank cannot put client balances, counterparty positions, or settlement flows onto a public ledger without breaching the privacy obligations it is regulated to uphold. Private blockchains solve that, but only by isolating themselves from public liquidity and the wider onchain economy. CBDCs and tokenisation networks address narrow problems and are not general-purpose infrastructure. Existing privacy approaches on public chains are partial, in that most leak metadata, fail under audit requirements, or scale poorly.

The result is a stand-off. The world's deepest pools of liquidity sit in systems that cannot interoperate with the onchain markets that need them, and onchain markets cannot grow into institutional scale without those pools.

Rayls is built to break the stand-off.

What Rayls is, in this context

Rayls is a general-purpose, EVM-compatible blockchain infrastructure that gives institutions everything a private chain offers (privacy, sovereignty, governance, performance) and everything a public chain offers (open liquidity, programmability, interoperability) in a single coordinated system.

What makes Rayls different

A chain built for institutional scale

Performance, cost predictability, and operational robustness are the second reason institutions choose Rayls, independently of the privacy story. Many institutions already operate on EVM-compatible public chains and are looking for a chain that handles institutional volume, settles with deterministic finality, charges predictable fees, and meets the operational requirements of regulated infrastructure. Rayls is built for those requirements.

Fast. Rayls runs on Axyl, a consensus mechanism designed for institutional throughput at 15,000+ TPS. Axyl delivers hard, deterministic finality in under a second, with no risk of chain reorganisations. It has been in production on the Public Chain since mainnet launch on 30 April 2026, and it was adopted on Rayls Sovereign in July 2026, superseding Clique proof of authority. Rayls Sovereign ledgers target 15,000+ transactions per second with sub-second finality, sized for institutional settlement volume rather than retail consumer throughput.

Cheap and predictable. Rayls Sovereign and Rayls Private Networks are gasless. Institutions running their own Rayls Sovereign ledger, or transacting inside a Private Network they participate in, do not pay gas on those transactions. On the Public Chain, base fees are pegged to USDC and collected by a system contract that converts them into RLS each epoch. The practical effect is that institutions can budget onchain activity in stable units, regardless of token-price volatility. This is the property most public chains do not currently offer, and it is what makes treasury operations on Rayls behave more like familiar institutional infrastructure than like a typical public chain.

Robust. Axyl is structured in three layers (consensus, middleware, execution) with strict sequential execution at the block level and epoch-based committee rotation for decentralisation. Validators are decoupled from Rayls Sovereign, so institutions choose independently how much of the consensus surface they want to operate. Standard Ethereum RPC interfaces are exposed in full, so existing tooling and infrastructure such as block explorers, indexers and monitoring work without modification. The full architecture, including the DAG-based consensus, the epoch model, and the EVM fork configuration, is documented on the Axyl Consensus Algorithm page.

Privacy that institutions can actually deploy

Privacy on Rayls is not pseudonymity, ring signatures, or selective hiding. It is verifiable privacy, delivered by the Enygma Framework through zero-knowledge proofs, homomorphic Pedersen commitments and post-quantum key encapsulation, all working together to give institutions four properties at once.

The cryptographic foundations are published in peer-reviewable form on the IACR ePrint archive (Rayls I and Rayls II). There is more detail in the Enygma section.

A coordinated public and private system, not a bridge between two

Many institutional blockchain stories involve bridging a private chain to a public chain after the fact. Rayls is designed as a single system from the start, so Rayls Sovereign, Rayls Private Networks and the Public Chain are interoperable by construction, share an EVM execution model, and use the same privacy framework. An asset issued privately can move to public distribution without leaving the system, and a public protocol can be consumed from inside a Private Network without a wrapper.

Permission models that match institutional reality

Most institutional networks force a single permission model on every participant. Rayls separates the layers, so a Rayls Sovereign ledger is private to the institution that runs it, Private Networks are permissioned and governed by the institutions that form them (which is what makes them suitable for modelling jurisdictions and regulatory frameworks), and the Public Chain is permissionless. An institution is not forced to choose one mode for all activities.

Standard EVM, not a bespoke stack

Every Rayls environment is EVM-compatible, which means existing developer tooling, audited contract patterns, the ERC-20, ERC-721 and ERC-1155 standards, and the broader Ethereum ecosystem of libraries and security practices all carry over. Teams do not need to learn a proprietary stack to build on Rayls, and existing Solidity codebases can be ported with minimal change.

Who Rayls is for

Rayls is suited to:

• Banks and other regulated financial institutions building tokenised products, settlement infrastructure or cross-border payment rails, and needing privacy that survives audit.
• Central banks and market infrastructure operators designing CBDCs or wholesale settlement networks where institutional and public layers need to coexist.
• Institutions already operating on EVM-compatible public chains and looking for stronger performance, deterministic finality, predictable fees, and operational robustness suited to regulated infrastructure, without giving up EVM compatibility.
• Developers and protocol teams building DeFi or tokenisation applications that want to be reachable from institutional liquidity without compromising on EVM tooling.