Can a Bank Access DeFi Without Exposing Its Entire Financial System?

DeFi has opened a completely different way of interacting with financial services.

People can exchange tokens, provide liquidity, access lending protocols and interact with smart contracts without depending on traditional banking infrastructure.

But when we talk about financial institutions, things become more complicated.

A bank cannot simply move its entire financial system onto a public blockchain.

It manages customer accounts, financial records, internal transactions and regulated assets. Some information must remain within its own environment, and access to its systems must be controlled.

At the same time, keeping everything inside a private network creates another challenge.

How can a bank access external blockchain applications, liquidity and other financial institutions if its infrastructure remains completely isolated?

This creates a difficult balance between two requirements:

  • Maintaining control over institutional operations.

  • Accessing the wider blockchain ecosystem.

Rayls is designed around connecting these different environments.

Rather than forcing institutions to choose between private infrastructure and public blockchain access, its architecture combines Rayls Sovereign, Rayls Private Networks and the Rayls Public Chain.

Let's understand how this works and why it matters for institutional finance.

Why Is Connecting Private Finance to DeFi Difficult?

Before looking at Rayls, let's understand the actual problem.

Imagine a bank operating its own private blockchain.

The bank can issue tokenised assets, manage customer balances and execute internal transactions within its own environment.

Everything is controlled by the institution.

Now imagine the bank wants to interact with an external DeFi application, such as a liquidity pool or a tokenised asset protocol.

There are several challenges.

1. Different blockchain environments

The bank's private network and the public DeFi application may operate on separate chains. They need a reliable way to communicate and coordinate transactions.

2. Asset compatibility

A public application cannot automatically use every asset that exists on a private institutional ledger. The asset needs a supported representation and a valid mechanism for interacting across networks.

3. Data confidentiality

The bank may need to interact with an external application without exposing all its internal account information, transaction history or customer data.

4. Settlement coordination

When two parties exchange financial assets, both sides need a reliable settlement process. One party should not complete its side while the other side fails to deliver.

5. Governance and access

Financial institutions need to know which participants and assets are authorised to interact with their networks.

This is why simply connecting two blockchains is not enough.

The infrastructure must consider messaging, asset movement, privacy, permissions and settlement.

This is the problem that institutional blockchain interoperability is trying to solve.

How Does Rayls Separate Institutional and Public Activity?

Rayls uses three interconnected environments, each designed for a different purpose.

1. Rayls Sovereign

Rayls Sovereign is the institution's own private blockchain environment.

Each institution operates its own ledger, where it can manage tokens, customer balances, smart contracts and internal financial activity.

The institution does not need to expose every internal transaction to other network participants.

2. Rayls Private Network

A Rayls Private Network connects multiple Sovereign ledgers through a shared Private Network Hub.

Participating institutions can communicate and transact through this permissioned environment.

The Hub provides shared network infrastructure, including participant and token registries, messaging contracts and settlement-related contracts.

3. Rayls Public Chain

The Rayls Public Chain is an EVM-compatible, permissionless Layer 1 blockchain.

It provides access to public smart contracts, applications and the wider blockchain ecosystem.

The interesting part is how these environments connect.

A Rayls Sovereign ledger can participate in one or more Private Networks and can also reach the Public Chain.

This means an institution can maintain its private financial operations while accessing supported cross-network functionality.

It is not about making every transaction public.

It is about choosing the appropriate environment for each activity

Can a Private Network Interact With Public DeFi Protocols?

This is one of the most interesting parts of the Rayls architecture.

According to the Rayls High-Level Architecture documentation, a protocol deployed on the Public Chain can be consumed from inside a Rayls Private Network.

The documentation specifically mentions examples such as:

  • Vaults

  • Swap pools

  • Delivery-versus-Payment (DvP) contracts

Let's understand this with a simple example.

Imagine a financial institution operating on a Rayls Private Network.

It wants to interact with a protocol deployed on the Public Chain.

Instead of treating its entire internal financial system as public, the institution can use the supported connection between its Sovereign environment and the Public Chain.

The public protocol provides the onchain functionality, while the institution continues to operate its own private infrastructure.

This creates an opportunity to connect institutional financial activity with public blockchain applications.

However, there is an important distinction.

Accessing a public protocol does not automatically mean every private asset can interact with every DeFi application. The asset, contracts and cross-chain flow must be supported by the implementation.

That is why the underlying interoperability architecture matters.

The objective is to make public blockchain functionality accessible without removing the institution's private operating environment

What Is Delivery-versus-Payment, and Why Does It Matter?

Let's look at a real financial use case.

Imagine Alice wants to purchase a tokenised bond from Bob.

Alice has the payment asset, while Bob owns the bond token.

Both parties need assurance that the exchange will happen correctly.

Alice does not want to send the payment without receiving the bond.

Bob does not want to transfer the bond without receiving the payment.

This is where Delivery-versus-Payment (DvP) comes in.

DvP is a settlement mechanism where the delivery of an asset and the corresponding payment are linked.

Rayls implements DvP functionality for its Private Networks through Enygma DvP.

According to its documentation, the flow works broadly like this:

Step 1 — Agree on the trade

Alice and Bob agree on the trade terms outside the settlement process, including a shared swap ID.

Step 2 — Deposit the assets

Alice deposits her Enygma payment tokens into the DvP process.

Bob deposits the bond represented by a supported ERC-721 or fungible ERC-1155 token.

Step 3 — Hold the assets

The assets are held in vaults on the Private Network Hub while the settlement is being coordinated.

Step 4 — Execute the swap

The DvP mechanism uses cryptographic commitments and proofs to spend the deposited assets and create new coins for their intended owners.

Step 5 — Complete the settlement

Both sides of the exchange are handled in one Hub transaction.

This is important because the payment and asset delivery are connected instead of being treated as two unrelated transfers.

One technical detail worth knowing: the documented production functionality supports Enygma tokens against ERC-721 and fungible ERC-1155 assets across two chains. It does not mean every possible token-for-token or currency-for-currency swap is already supported.

This is a practical example of how institutional blockchain infrastructure can support more coordinated financial settlement.

What Happens Behind the Scenes?

Connecting separate blockchain environments requires several components to work together.

Rayls uses a combination of smart contracts, relayers and cryptographic infrastructure.

Let's look at the main components.

1. Endpoint contracts

These contracts provide the messaging interface used by participating chains.

They help initiate and receive cross-chain messages.

2. Private Relayer

Each institution runs its own private relayer.

It listens to the institution's Sovereign chain, handles messages travelling between that chain and the Hub, and executes incoming messages.

3. Private Network Hub

The Hub acts as the shared intermediary between participating Sovereign chains.

It maintains network registries and handles cross-chain messaging infrastructure.

4. Cryptography Trust Suite (CTS)

CTS supports key management and signing operations for the relayer.

It helps protect the cryptographic keys used by the institution.

5. Public Relayer

Rayls also has a separate public relayer that handles communication with the Public Chain.

The Rayls relayer repository describes three Go binaries:

  • relayer — private relayer.

  • pubrelayer — public relayer.

  • cts — Cryptography Trust Suite.

An important part of this design is message encryption.

The relayer documentation explains that cross-chain payloads remain end-to-end encrypted while travelling through the Hub.

The Hub routes messages without being able to read their encrypted contents.

This is how Rayls separates message routing from access to the underlying message data.

What Could This Mean for Institutional DeFi?

Traditional finance and DeFi have developed with different priorities.

Public blockchain applications focus on open participation, programmability and access to onchain markets.

Financial institutions need controlled participation, confidentiality, governance and reliable settlement.

Connecting these environments is not simply about transferring tokens from one chain to another.

It requires infrastructure that can coordinate:

  • Private institutional ledgers.

  • Permissioned communication between financial institutions.

  • Cross-chain asset movement.

  • Encrypted messaging.

  • Smart contract execution.

  • Coordinated financial settlement.

  • Access to public blockchain applications.

Rayls approaches this through its connected Sovereign, Private Network and Public Chain environments.

Its DvP implementation also demonstrates how cross-chain financial settlement can be handled within a permissioned institutional network.

Of course, this does not mean every DeFi protocol is automatically available to every bank, or that every asset can move freely between these environments.

The supported contracts, assets, governance rules and implementation all matter.

But the broader idea is interesting.

Financial institutions may not need to abandon their private infrastructure to explore public blockchain applications.

Instead, they need a way to connect both environments while respecting the requirements of institutional finance.

That is the direction worth watching as traditional finance and DeFi move closer together.