Rayls Privacy Node
Rayls Privacy Node
A Rayls Privacy Node 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, a Privacy Node 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 Privacy Node. It is installed within the institution's own environment, behind its own firewalls, and operated under its own controls.
What a Privacy Node does on its own
Inside a single institution, a Privacy Node 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 node.
Because a Privacy Node is EVM-compatible, existing Solidity contracts, audited patterns and developer tooling carry over. Teams do not need to learn a bespoke stack.
What a Privacy Node does in concert with others
A Privacy Node becomes more interesting when it connects to other Privacy Nodes, either through a Rayls Private Network (permissioned, governed by participating institutions) or through the Rayls Public Chain (permissionless, EVM-compatible Layer 1).
When connected, a Privacy Node can:
- Transact privately and anonymously with other Privacy Nodes, including payment requests, atomic settlement, and atomic delivery-versus-payment (DvP).
- Reach the broader on-chain ecosystem through the Public Chain: dApps, public liquidity pools, and any KYC-cleared participant.
- Allow selective audit through Enygma's view-key mechanism. Auditors hold view-only keys that decrypt specific authorised transactions. Spending authority and viewing authority are cryptographically separated, not 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 on the Privacy Node. The settlement state lives in smart contracts on whichever chain carries the transaction. Outsiders see that a transaction occurred and that it was valid; they do not see what it contained.
Anatomy of a Privacy Node
A Privacy Node is not a single binary. It is a small set of components that together provide an institution with everything required to run privately and to transact privately with others.
Components are organised by what an institution is trying to do.
Required to run a Privacy Node
| Component | Role |
|---|---|
| EVM node | The execution layer. Geth today, replaced by Reth in the Axyl release. Currently uses MongoDB, deprecated in Axyl. |
| Relayer | Handles communication between the Privacy Node and the Rayls Public Chain. Currently uses MongoDB, replaced by Postgres by April. |
| KMM (Key Management Module) | Manages the keys used by the Relayer to sign transactions. Currently uses MongoDB, replaced by Postgres by April. KMM will be replaced by the Cryptography Trust Suite (CTS), which decouples key custody from the Relayer so the Relayer never directly handles or stores keys. |
| NATS JetStream | Messaging backbone required by the Relayer and the Governance API. |
Optional, for single-institution use
| Component | Role |
|---|---|
| Rayls Backend | APIs for governing tokens and the users that transact between the Privacy Node and the Rayls Public Chain. |
| Blockscout | Block explorer recommended for integration with the Privacy Node. |
Required to use Enygma (any cross-institution flow)
| Component | Role |
|---|---|
| Gnark API | Generates the zero-knowledge proofs that Enygma transactions depend on. Required whenever Enygma is in use, whether the transaction settles on a Private Network or on the Public Chain. |
Optional, for participation in a Private Network
| Component | Role |
|---|---|
| Governance API | APIs for monitoring transactions, tokens and participants at the Private Network level. Uses PostgreSQL. |
| Auditor Explorer | Visual interface for transactions executed at the Private Network level. |
Migrating to Axyl
Rayls is in the middle of a planned migration to Axyl, the consensus mechanism designed for institutional throughput (~10,000 TPS, sub-second finality). Axyl is already live on the Rayls Public Chain. The migrations are scheduled by June. The migration is being phased so that institutions running today keep running through the change.
What changes:
- EVM node. Geth becomes Reth.
- High availability. Today's Privacy Node runs as a single Geth node. The Axyl release introduces a consensus mechanism that runs across at least four nodes, eliminating single-node availability risk.
- Key management. KMM becomes the Cryptography Trust Suite (CTS), a decoupled key-custody component. The Relayer no longer handles or stores keys directly.
- Databases. MongoDB is replaced by Postgres for the Relayer and the KMM by April, and is deprecated for the EVM node in the Axyl release.
- Performance and footprint. Several supporting changes (Postgres in place of MongoDB, the Gnark API for Enygma proof generation, broader infrastructure work) are part of an active resource optimisation effort. The Axyl release is meaningfully lighter to run than the current stack.
Operating environment and resources
A Privacy Node 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.
Resource specifications for the current and Axyl releases are published on the [deployment requirements] page. Numbers below are placeholders pending update.
Deployment tiers under review:
- Lightweight tier: pending
- Enterprise tier: pending
Performance characteristics:
- Sub-second transaction finality.
- Roughly 10,000 transactions per second on Privacy Nodes in the Axyl release.
- 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 a Privacy Node
To run a Privacy Node, please contact the Rayls team (Contact us) and we will help you with the setup. A self-service CLI will be available in June.
Updated 18 days ago