Why Rayls

The problem Rayls is built to solve

Roughly $100 trillion of regulated capital sits with banks and financial institutions. Almost none of it moves on-chain.

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 on-chain economy. CBDCs and tokenisation networks address narrow problems but are not a general-purpose infrastructure. Existing privacy approaches on public chains are partial: 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 on-chain markets that need them, and on-chain 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 is moving onto Axyl, a consensus mechanism designed for institutional throughput (10k TPS). Axyl delivers hard, deterministic finality in under a second, with no risk of chain reorganisations. Axyl is the consensus mechanism in production on the Public Chain today, and is being rolled out across Privacy Nodes (replacing Geth) and Private Networks (as an alternative to Besu). Privacy Nodes target around 10,000 transactions per second with sub-second finality, sized for institutional settlement volume rather than retail consumer throughput.

Cheap and predictable. Privacy Nodes and Private Networks are gasless. Institutions running their own Privacy Node, 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 on-chain activity in stable units, regardless of token-price volatility. This is the property most public chains do not currently offer, and the one that 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 Privacy Nodes, 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 (block explorers, indexers, 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 .

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: zero-knowledge proofs, homomorphic encryption, Pedersen commitments, 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). Take a look to this section for more information on Enygma .

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: Privacy Nodes, 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: Privacy Nodes are private to the institution that runs them, 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. 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.