Scalability

A Rayls Private Network is multiple Rayls Sovereign chains connected together via a central Hyperledger Besu chain, the Private Network Hub. Its capacity comes from that split: most activity stays on the institutions' own chains, and only what crosses between them reaches the Hub, in batches.

Each institution has its own chain

Each participant runs its own Rayls Sovereign chain (Privacy Node in the code). Client accounts, internal payments and the institution's own contracts run there, on capacity that the institution sizes and pays for. None of that work touches the Hub or the other participants' chains.

If one chain isn't enough, an institution can run more than one. Each chain joins the network as a separate participant, with its own relayer and key service.

The Hub carries only cross-chain traffic, in batches

Batching happens at three levels:

Level	What is batched	Default limit in the code
Application	A contract can send many messages in one transaction with the endpoint's batch functions (`sendBatch`, `sendBatchToResourceId`).	Fewer than 500 messages per call. The limit is set when the chain's contracts are deployed.
Relayer	Every second, the relayer collects pending outgoing messages and submits one Hub transaction per destination chain.	Up to 100 messages per round
Enygma	The relayer combines pending Enygma transfer requests for a token into one batch, with one zero-knowledge proof, so one Hub transaction can carry many client payments.	Up to 1,000 requests per batch

So if Bank A's clients make 100 payments to clients of Bank B within the same second, the Hub records one transaction from Bank A for Bank B, not 100.

Joining is a single connection

A new participant connects to the Hub only, not to each of the other participants. Its relayer reads from and writes to the Hub, and the network needs one connection per participant rather than one per pair.

Each pair of participants still agrees its own shared secret, through ciphertexts posted on the Hub, so a network with n participants holds about n²/2 key agreements. These are made once, when a participant joins.

Limits to plan for

The Hub is shared. All cross-chain traffic in the network goes through one chain, so its capacity bounds the network's cross-chain throughput. The code leaves the Hub's consensus, nodes and block settings to each deployment.
One Enygma transaction per sender per block. Each participant's Enygma transactions for a block go into one batch, because the nullifier that prevents double spending is tied to the sender and the block. See How Enygma works.
Enygma proofs take time. Each Enygma batch needs a zero-knowledge proof from the proofs API before it reaches the Hub.
Settlement is asynchronous. A message is delivered after the destination relayer picks it up from the Hub and executes it on the destination chain.

📘
Performance figures
These docs don't quote throughput or latency figures for Private Networks. They depend on the hardware, the Hub's configuration, the number of participants and the mix of traffic. Ask Rayls for benchmarks that match your deployment.