DEV Community: rayQu

Building a Confidential OTC Settlement Protocol with Oasis Sapphire & Base

rayQu — Mon, 20 Jul 2026 07:06:17 +0000

Learn how to build a privacy-preserving OTC trading protocol where counterparties negotiate confidentially using Oasis Sapphire while settling trades transparently on Base.

Large cryptocurrency trades rarely happen on decentralized exchanges.

When someone wants to swap a few hundred dollars worth of ETH for USDC, an automated market maker like Uniswap works exceptionally well. Liquidity is abundant, settlement is immediate, and the entire process can be completed in a single transaction.

The picture changes completely once the trade size reaches institutional territory.

Imagine a DAO treasury planning to exchange 500,000 USDC for ETH.

Executing that transaction through a public liquidity pool immediately reveals valuable information to the entire market. Arbitrage bots begin simulating profitable routes before the transaction is finalized. Market makers widen spreads. Searchers compete to extract value from the pending order, while other traders infer the treasury's strategy simply by observing the transaction.

The protocol itself is functioning exactly as designed.

The problem is that transparency and negotiation don't always belong together.

This is precisely why Over-the-Counter (OTC) trading exists.

Rather than exposing an order to an entire market, two counterparties negotiate privately before agreeing on a final settlement price. Only after both parties reach an agreement is the trade executed.

Traditional financial institutions have relied on this model for decades because confidentiality reduces information leakage and allows large transactions to occur without unnecessarily moving markets.

Public blockchains introduce an interesting challenge.

How do you preserve confidential negotiations while still benefiting from decentralized settlement?

This is where Oasis Sapphire becomes particularly interesting.

Instead of treating confidentiality as an application-layer concern, Sapphire provides confidential smart contract execution directly within an EVM-compatible environment. Sensitive contract state remains protected while developers continue writing familiar Solidity code.

In this tutorial we'll build a simplified OTC trading protocol that combines confidential negotiation on Oasis Sapphire with transparent settlement on Base.

Rather than building another decentralized exchange, we'll focus on the negotiation process itself.

By the end of this guide you'll have built a protocol capable of:

Creating confidential OTC trade offers
Receiving private counterparty quotes
Accepting offers without revealing negotiations publicly
Escrowing assets before settlement
Executing the final settlement on Base
Cancelling expired orders safely
Preventing replay attacks through signed messages

Although the protocol we'll build is intentionally simplified for educational purposes, its architecture mirrors patterns commonly found in production financial systems.

Understanding the Problem

Before writing a single line of Solidity, it's worth asking an important question.

Why don't institutions simply use AMMs for everything?

After all, decentralized exchanges already provide liquidity, transparent pricing, and permissionless access.

The answer comes down to market impact.

Suppose Alice wants to purchase 400 ETH.

If that trade is submitted directly to a public liquidity pool, several things happen almost immediately.

First, the pending transaction becomes visible to sophisticated searchers monitoring the network.

Next, those searchers estimate the price impact by simulating the trade against current liquidity.

If profitable opportunities exist, competing transactions are constructed before Alice's order has even been finalized.

Even if nobody explicitly frontruns the transaction, the market itself now possesses information that previously existed only inside Alice's trading strategy.

That information has value.

The larger the order becomes, the more valuable it becomes.

The sequence below illustrates what happens inside a typical public execution environment.

sequenceDiagram

participant Alice
participant Ethereum
participant Searcher
participant LiquidityPool

Alice->>Ethereum: Submit Swap

Ethereum-->>Searcher: Pending Transaction

Searcher->>Searcher: Simulate Trade

Searcher->>LiquidityPool: Competing Transactions

LiquidityPool-->>Alice: Final Execution

Nothing malicious has occurred.

Every participant simply acted upon publicly available information.

For large trades, however, that transparency introduces unnecessary information leakage.

OTC trading avoids this problem entirely by moving negotiation away from the public market.

Only the final agreement becomes visible.

Why Oasis Sapphire?

One obvious question is why we need another blockchain at all.

Couldn't we simply negotiate off-chain using encrypted messages?

In some situations, yes.

However, purely off-chain negotiation introduces several new trust assumptions.

Who stores the offers?

Who guarantees neither party modified the terms?

How do we prove a particular offer existed if negotiations break down?

How do multiple market makers compete fairly?

A confidential smart contract solves these coordination problems.

Instead of trusting a centralized OTC desk, participants submit encrypted offers into a shared protocol.

The blockchain enforces protocol rules while keeping sensitive trading information confidential.

From the outside, observers know an offer exists.

They do not learn:

which asset is being traded,
the quoted price,
the requested amount,
acceptable settlement conditions,
or which counterparty accepted the offer.

Only the final settlement transaction becomes public.

That distinction dramatically reduces information leakage while preserving decentralized execution.

System Overview

Our protocol consists of five independent components.

Each has a single responsibility.

Separating these concerns keeps the contracts significantly easier to audit and makes future upgrades less risky.

flowchart LR

User["Trader"]

Frontend["Next.js Frontend"]

SDK["TypeScript SDK"]

Registry["OTC Registry"]

Escrow["Escrow Contract"]

Coordinator["Settlement Coordinator"]

Base["Base Network"]

User --> Frontend

Frontend --> SDK

SDK --> Registry

Registry --> Coordinator

Coordinator --> Escrow

Escrow --> Base

Let's briefly examine the role of each component.

OTC Registry

The registry acts as the confidential marketplace.

Every new offer enters the protocol through this contract.

Rather than immediately transferring assets, users first describe the trade they would like to perform.

Those details remain confidential until the offer is accepted.

Escrow Contract

Once two counterparties agree on a trade, both assets must be secured before settlement begins.

Instead of relying on trust between participants, the escrow contract temporarily locks both sides of the trade.

Neither participant can withdraw funds unilaterally after acceptance.

Only successful settlement or cancellation releases escrowed assets.

Settlement Coordinator

The final contract coordinates settlement on Base.

Once escrow conditions are satisfied, settlement becomes deterministic.

This separation keeps negotiation logic isolated from execution logic, significantly simplifying auditing.

Project Architecture

We'll build the project as a monorepo.

Although our example remains relatively small, organizing the repository this way closely resembles production Solidity projects.

confidential-otc-protocol/

├── contracts/
│
│   OTCRegistry.sol
│
│   Escrow.sol
│
│   SettlementCoordinator.sol
│
│   libraries/
│
│      SignatureVerifier.sol
│
│      OfferHasher.sol
│
│
├── sdk/
│
│   otcClient.ts
│
│   signer.ts
│
│   quotes.ts
│
├── backend/
│
│   api.ts
│
│   relayer.ts
│
│
├── frontend/
│
│   app/
│
├── script/
│
├── test/
│
└── docs/

Throughout this tutorial we'll implement each directory individually before integrating everything into a complete protocol.

By the end, you'll have a repository structured much more like a production codebase than a simple Solidity example.

Protocol Lifecycle

Before diving into the implementation, it's useful to visualize the complete lifecycle of an OTC trade.

stateDiagram-v2

[*] --> Draft

Draft --> Submitted

Submitted --> Quoted

Quoted --> Accepted

Accepted --> Escrowed

Escrowed --> Settled

Submitted --> Cancelled

Quoted --> Cancelled

Accepted --> Expired

Notice that settlement is only one stage of the protocol.

Most of the protocol's complexity actually happens before assets move.

Negotiation, verification, escrow, and acceptance each introduce their own state transitions.

Designing these transitions carefully is one of the easiest ways to eliminate entire classes of smart contract bugs before they ever appear.

In the next section we'll begin implementing the protocol's core contract: OTCRegistry.sol.

Rather than jumping directly into business logic, we'll first design the underlying data model and explain why each field exists before writing any functions.

Setting Up the Project

Before writing any Solidity, let's create the project structure.

We'll use Foundry because it has become the de facto standard for professional Solidity development. It provides fast compilation, excellent testing utilities, built-in fuzzing, and straightforward deployment scripts.

If you haven't already installed Foundry, you can do so with:

curl -L https://foundry.paradigm.xyz | bash
foundryup

Now create a new project.

forge init confidential-otc-protocol

cd confidential-otc-protocol

We'll also install OpenZeppelin contracts.

forge install OpenZeppelin/openzeppelin-contracts

Our project now looks like this.

confidential-otc-protocol/

├── lib/
│
├── script/
│
├── src/
│
├── test/
│
├── foundry.toml
│
└── README.md

Throughout the tutorial we'll gradually replace the default template with our protocol implementation.

Why Foundry?

Hardhat remains an excellent framework, but Foundry offers several advantages for protocol development.

First, tests execute considerably faster because they're written directly in Solidity.

Second, fuzz testing is built into the framework instead of requiring external plugins.

Finally, cheatcodes make it straightforward to simulate different users, timestamps, balances, and blockchain conditions.

Since we're building financial infrastructure, confidence in our testing environment matters just as much as confidence in the contracts themselves.

Designing the Registry

Most blockchain tutorials begin with functions.

Production protocols begin with data.

The quality of a smart contract is largely determined by how well its state is modeled.

Changing storage layouts after deployment is difficult, especially once external integrations exist.

Before writing a single function, we should understand exactly what information our registry needs to remember.

An OTC offer answers a simple question.

"What is one party willing to trade?"

That sounds simple, but the protocol needs considerably more information than just two token addresses.

Our registry must remember:

who created the offer,
which asset they're selling,
which asset they expect,
the amount offered,
the minimum amount they'll accept,
when the offer expires,
whether it's still active,
and whether somebody has already accepted it.

Representing these pieces of information explicitly makes later contract logic much easier to understand.

Creating the Offer Model

Inside src/, create a file named OTCRegistry.sol.

We'll start with the data model before implementing any business logic.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract OTCRegistry {

    enum OfferStatus {
        Open,
        Accepted,
        Cancelled,
        Settled,
        Expired
    }

    struct Offer {

        address maker;

        address tokenOffered;

        address tokenRequested;

        uint256 amountOffered;

        uint256 minimumAmountRequested;

        uint256 expiry;

        uint256 nonce;

        OfferStatus status;

    }

}

Although this contract contains only a few lines of Solidity, there's already quite a bit happening.

Instead of storing offers as loosely connected mappings, we've grouped related information into a single structure.

This makes the protocol easier to reason about because every offer becomes a self-contained object.

Let's examine each field.

Maker

address maker;

The maker is the wallet that created the offer.

This address becomes important throughout the protocol.

Only the maker can:

cancel an open offer,
update certain parameters (before acceptance),
or withdraw escrow if settlement fails.

Rather than checking ownership through complex access-control mechanisms, we'll simply compare msg.sender against this stored address.

Offered Token

address tokenOffered;

This represents the asset currently owned by the maker.

For example,

USDC

WETH

The registry itself won't hold these tokens.

Instead, it records what the maker intends to escrow later in the protocol.

Keeping negotiation separate from asset custody makes the protocol significantly easier to audit.

Requested Token

address tokenRequested;

This is the asset the maker expects in return.

Together,

tokenOffered

↓

tokenRequested

define the trading pair.

Unlike AMMs, we're not computing prices algorithmically.

The maker decides exactly what exchange they're willing to accept.

Offered Amount

uint256 amountOffered;

This field specifies how many units of the offered token the maker wishes to trade.

For example,

500,000 USDC

The protocol intentionally avoids floating-point arithmetic.

Every amount is stored using the token's smallest denomination.

For ERC-20 tokens, that typically means accounting for decimals within the frontend or SDK.

Minimum Requested Amount

uint256 minimumAmountRequested;

This field acts as protection against unfavorable execution.

Suppose Alice wants to exchange

500,000 USDC

for at least

165 ETH

If a counterparty proposes

160 ETH

the protocol should reject the trade automatically.

Encoding these constraints directly into the offer ensures every accepted trade satisfies the maker's original conditions.

Expiry

uint256 expiry;

No financial offer should remain valid forever.

Market conditions change.

Token prices fluctuate.

Liquidity disappears.

Rather than relying on users to manually cancel stale offers, we'll associate every offer with an expiration timestamp.

Any interaction after that timestamp becomes invalid.

This single field eliminates an entire class of replay attacks.

Nonce

uint256 nonce;

One subtle problem appears once signatures enter the picture.

Suppose Alice signs an offer today.

What's stopping somebody from submitting the exact same signed payload next month?

The answer is nonces.

Each new offer consumes a unique value.

Once that value has been used, the protocol refuses to accept another offer carrying the same nonce.

We'll implement this protection shortly.

Organizing Storage

With the data model complete, we can decide how offers will actually be stored.

mapping(uint256 => Offer) private offers;

uint256 public offerCounter;

mapping(address => uint256) public nonces;

Each mapping serves a different purpose.

The first stores every offer ever created.

The second generates unique identifiers.

Finally, the third keeps track of each user's latest nonce.

Separating these concerns keeps lookups straightforward while avoiding nested mappings that quickly become difficult to maintain.

Why Sequential IDs?

Earlier we discussed deterministic hashes.

Why switch to numeric identifiers?

Because this protocol has different requirements.

Unlike signed intents that may exist off-chain before submission, OTC offers originate inside the protocol itself.

Sequential identifiers offer several practical advantages.

They make indexing simpler.

They're cheaper to generate than hashes.

And they're considerably easier to reference from frontends and block explorers.

Offer #421 is much easier for developers to work with than

0xb7e13b8ecb5e...

Internally, we'll still use cryptographic hashes later for signatures.

But externally, sequential identifiers make the protocol much friendlier to use.

Creating Offers

With storage in place, we can finally implement our first state-changing function.

function createOffer(

    address tokenOffered,

    address tokenRequested,

    uint256 amountOffered,

    uint256 minimumAmountRequested,

    uint256 expiry

) external returns (uint256 offerId) {

    require(expiry > block.timestamp, "Offer already expired");

    offerId = ++offerCounter;

    offers[offerId] = Offer({

        maker: msg.sender,

        tokenOffered: tokenOffered,

        tokenRequested: tokenRequested,

        amountOffered: amountOffered,

        minimumAmountRequested: minimumAmountRequested,

        expiry: expiry,

        nonce: nonces[msg.sender]++,

        status: OfferStatus.Open

    });

}

Although concise, this function already demonstrates several useful design principles.

First, validation occurs before any state modification.

Second, every newly created offer immediately receives a unique identifier.

Finally, we increment the maker's nonce at creation time, ensuring every offer remains uniquely identifiable even if all other parameters are identical.

In the next section we'll improve this function by replacing require strings with custom errors, adding events for off-chain indexing, and integrating EIP-712 signatures so offers can be created through signed messages rather than direct transactions.

Adding Production-Grade Solidity Patterns

The first version of OTCRegistry.sol works, but it still looks closer to a prototype than production infrastructure.

Before moving deeper into confidential execution and cross-chain settlement, we need to improve the contract foundations.

Financial protocols are rarely compromised because the developer forgot how to write a function.

They fail because small design decisions accumulate.

Gas inefficiencies become expensive at scale.

Missing events break indexing systems.

Weak signature handling creates replay vulnerabilities.

Poorly defined state transitions make auditing significantly harder.

The next iteration of the registry focuses on those details.

Replacing require Strings with Custom Errors

The first improvement is replacing traditional revert messages.

A common Solidity pattern looks like this:

require(
    expiry > block.timestamp,
    "Offer already expired"
);

This works, but it is unnecessarily expensive.

Every revert string must be stored inside the contract bytecode.

For frequently triggered errors, this increases deployment size and runtime gas costs.

Modern Solidity provides custom errors.

Instead of storing text, we define an error selector.

error OfferExpired();

error InvalidToken();

error InvalidAmount();

error Unauthorized();

error OfferNotOpen();

Now validation becomes:

if (expiry <= block.timestamp) {
    revert OfferExpired();
}

The difference may seem small.

For a single transaction, the savings are minimal.

For a protocol processing thousands of interactions, these optimizations compound.

More importantly, custom errors create structured failure conditions.

Frontend applications can identify the exact failure type instead of parsing human-readable strings.

Updating the Registry Contract

Our contract now begins with clearer protocol-level failures.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract OTCRegistry {

    error OfferExpired();
    error InvalidAmount();
    error Unauthorized();
    error OfferNotOpen();

    enum OfferStatus {
        Open,
        Accepted,
        Cancelled,
        Settled,
        Expired
    }

    struct Offer {

        address maker;

        address tokenOffered;

        address tokenRequested;

        uint256 amountOffered;

        uint256 minimumAmountRequested;

        uint256 expiry;

        uint256 nonce;

        OfferStatus status;

    }

    mapping(uint256 => Offer) private offers;

    uint256 public offerCounter;

    mapping(address => uint256) public nonces;

}

The storage layout remains unchanged.

This is intentional.

Changing storage unnecessarily creates migration complexity.

A well-designed contract evolves by adding capabilities around stable foundations.

Why Events Matter

Smart contracts do not push information to applications.

They simply modify state.

If a frontend wants to display active OTC offers, it needs an efficient way to discover changes.

Reading every offer ID and querying storage directly does not scale.

Events solve this problem.

When emitted, events become part of transaction logs that external systems can index.

Popular indexing systems such as The Graph and custom backend services rely heavily on this pattern.

For our registry, we need events for:

offer creation,
offer acceptance,
cancellation,
settlement.

Let's add the first one.

event OfferCreated(
    uint256 indexed offerId,
    address indexed maker,
    address tokenOffered,
    address tokenRequested,
    uint256 amountOffered,
    uint256 minimumAmountRequested,
    uint256 expiry
);

The indexed keyword is important.

Indexed fields become searchable topics.

For example, a frontend can efficiently query:

"Show me every offer created by this address."

without scanning the entire blockchain.

Emitting Offer Creation Events

Now we update our creation function.

function createOffer(

    address tokenOffered,

    address tokenRequested,

    uint256 amountOffered,

    uint256 minimumAmountRequested,

    uint256 expiry

) external returns (uint256 offerId) {


    if (expiry <= block.timestamp) {
        revert OfferExpired();
    }


    if (
        amountOffered == 0 ||
        minimumAmountRequested == 0
    ) {
        revert InvalidAmount();
    }


    offerId = ++offerCounter;


    offers[offerId] = Offer({

        maker: msg.sender,

        tokenOffered: tokenOffered,

        tokenRequested: tokenRequested,

        amountOffered: amountOffered,

        minimumAmountRequested: minimumAmountRequested,

        expiry: expiry,

        nonce: nonces[msg.sender]++,

        status: OfferStatus.Open

    });


    emit OfferCreated(
        offerId,
        msg.sender,
        tokenOffered,
        tokenRequested,
        amountOffered,
        minimumAmountRequested,
        expiry
    );
}

The function now has three clear responsibilities:

Validate the offer.
Store protocol state.
Notify external systems.

Keeping those responsibilities separated makes later auditing much easier.

Introducing EIP-712 Typed Data

Direct transactions are not always ideal for OTC workflows.

Institutional traders frequently negotiate away from the blockchain.

A market maker might send a quote through a private channel.

A treasury manager might approve a trade through an internal signing system.

Broadcasting every negotiation step on-chain defeats the purpose of confidentiality.

Instead, users should be able to sign trade intents.

The blockchain only verifies the final agreement.

This is where EIP-712 becomes important.

EIP-712 defines a standard format for signing structured data.

Instead of signing an unreadable blob:

0x72af91bc...

users sign something understandable:

Sell:

500000 USDC

Receive:

165 ETH

Expiry:

July 20 2026

Wallets can display these fields clearly before approval.

Designing the Signed Offer

Our signed message needs a deterministic structure.

struct OfferMessage {

    address maker;

    address tokenOffered;

    address tokenRequested;

    uint256 amountOffered;

    uint256 minimumAmountRequested;

    uint256 expiry;

    uint256 nonce;

}

Every field matters.

Removing a field creates ambiguity.

For example, if expiry is not included, an attacker could reuse a valid signature after market conditions changed.

If nonce is missing, replay attacks become possible.

Cryptographic signatures are only as strong as the data they protect.

Adding OpenZeppelin EIP712

Rather than implementing hashing manually, we'll use OpenZeppelin's audited implementation.

import {
    EIP712
} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";


import {
    ECDSA
} from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

Our contract now inherits:

contract OTCRegistry is EIP712 {

}

The constructor initializes the signing domain.

constructor()
    EIP712(
        "Confidential OTC Protocol",
        "1"
    )
{}

The domain separates signatures from other applications.

A signature created for our OTC protocol cannot accidentally be reused inside another application with different rules.

Hashing the Offer

EIP-712 requires two stages.

First, we hash the structured message.

Then we hash that result with the domain separator.

The final digest is what gets signed.

bytes32 private constant OFFER_TYPEHASH =
keccak256(
    "OfferMessage(address maker,address tokenOffered,address tokenRequested,uint256 amountOffered,uint256 minimumAmountRequested,uint256 expiry,uint256 nonce)"
);

The type hash describes the exact structure.

Any modification changes the resulting hash.

This prevents attackers from altering individual fields without invalidating the signature.

Why This Matters for Confidential OTC

At this point, we have an important architectural improvement.

The negotiation process no longer requires every participant to submit transactions.

A trader can:

Create an offer locally.
Sign it.
Share it privately.
Receive counterparty acceptance.
Submit only the final agreed trade.

This changes the privacy model dramatically.

The blockchain no longer observes every negotiation step.

It only verifies the final commitment.

This pattern is common in modern trading infrastructure.

The chain becomes a settlement layer rather than a communication layer.

Connecting This Back to Oasis Sapphire

This is where Oasis Sapphire becomes useful.

Sapphire allows the negotiation layer itself to become confidential while remaining EVM-compatible.

Instead of exposing signed offers and quotes publicly, sensitive state can remain inside confidential contract execution.

The architecture becomes:

flowchart LR

TraderA --> Sapphire

TraderB --> Sapphire

Sapphire --> SignedSettlement

SignedSettlement --> Base

Base --> FinalSettlement

Sapphire handles the private coordination.

Base provides transparent final settlement.

Neither chain is replacing the other.

Each handles the part it is best suited for.

Next Section

The registry now has:

structured storage,
custom errors,
event indexing,
typed signatures,
replay protection foundations.

The next step is implementing the acceptance flow.

We will build:

counterparty quote submission,
signature verification,
offer acceptance,
escrow state transitions,
settlement preparation,
and the bridge between confidential negotiation and public Base settlement.

Building the Acceptance Flow

The registry can now create offers and verify signed trade intents. However, an OTC protocol is not complete when an offer exists.

An offer represents only one side of the agreement.

The critical moment happens when another participant decides:

"I accept these terms, and I am willing to proceed toward settlement."

This transition is where many financial protocols become complicated.

A naive implementation might look like this:

function acceptOffer(uint256 offerId)
    external
{
    offers[offerId].status = OfferStatus.Accepted;
}

This appears simple, but it introduces several problems.

Who is accepting?

Can anyone accept?

Was the offer already cancelled?

Has the offer expired?

Did the counterparty actually provide the requested asset?

Can the same offer be accepted twice?

In financial infrastructure, changing a single enum value is not the operation. The operation is a state transition with strict conditions.

Our goal is to make every transition explicit.

Designing the Acceptance Lifecycle

Before writing code, let's define what acceptance actually means.

The lifecycle currently looks like:

Open
 |
 |
 v
Accepted
 |
 |
 v
Escrowed
 |
 |
 v
Settled

There are also failure paths:

Open
 |
 +----> Cancelled
 |
 +----> Expired

The important observation is that acceptance is not settlement.

This distinction matters.

A counterparty agreeing to trade does not mean assets have moved.

The protocol must first verify:

The offer still exists.
The offer is still open.
The acceptance satisfies the original conditions.
Both parties can proceed to escrow.
Settlement can happen deterministically later.

Separating these phases prevents a common class of bugs where negotiation state and asset movement become tightly coupled.

Reading Offers Safely

Before adding acceptance logic, we need a way for external applications to inspect offers.

Currently:

mapping(uint256 => Offer) private offers;

The storage is private.

This is intentional.

In a confidential environment, exposing raw storage defeats the purpose of keeping negotiation details protected.

However, applications still need controlled access.

We can create a view function.

function getOffer(uint256 offerId)
    external
    view
    returns (Offer memory)
{
    return offers[offerId];
}

This works for a public chain.

However, because our final architecture uses Oasis Sapphire for confidential negotiation, this function becomes an important design decision.

On Sapphire, the contract can expose information selectively.

The difference is subtle but important:

A public Ethereum contract assumes:

"Everything is visible unless encrypted externally."

A confidential execution environment assumes:

"The contract decides what information leaves the private state."

The same Solidity pattern behaves differently depending on where it executes.

Validating State Transitions

Let's add a helper function.

function _requireOpenOffer(
    Offer storage offer
)
    internal
    view
{
    if (offer.status != OfferStatus.Open) {
        revert OfferNotOpen();
    }

    if (block.timestamp > offer.expiry) {
        revert OfferExpired();
    }
}

This function centralizes the rules for an active offer.

Why not repeat these checks everywhere?

Because duplicated state validation creates drift.

Imagine one function checks expiry:

block.timestamp >= expiry

while another checks:

block.timestamp > expiry

That one-character difference creates inconsistent behavior.

Financial protocols should have one definition of validity.

Accepting an Offer

Now we can implement the acceptance transition.

function acceptOffer(
    uint256 offerId
)
    external
{
    Offer storage offer = offers[offerId];

    _requireOpenOffer(offer);

    offer.status = OfferStatus.Accepted;
}

The function is intentionally simple.

The complexity comes from the guarantees around it.

Before changing state, the contract proves:

the offer exists,
the offer is active,
the offer has not expired.

Only then does the transition occur.

But Who Can Accept?

This is the first major design decision.

There are several possible models.

Open Acceptance

Anyone can accept an offer.

Example:

Alice creates:

Sell:
500,000 USDC

Receive:
165 ETH

Any participant can accept.

Advantages:

simple,
permissionless,
similar to public exchange orders.

Disadvantages:

poor fit for institutional OTC,
no counterparty negotiation,
creates competition around acceptance.

Whitelisted Counterparties

The maker specifies who can accept.

Example:

Maker:
DAO Treasury

Allowed Counterparty:
Market Maker X

Advantages:

closer to institutional OTC,
predictable counterparties.

Disadvantages:

requires identity management.

Signed Acceptance

The most flexible approach is requiring both sides to sign the agreement.

The final transaction contains:

Maker Signature

+

Counterparty Signature

The contract verifies both signatures before allowing settlement.

This is the approach we will move toward.

Adding Counterparty Information

Our current Offer struct only knows the maker.

For bilateral OTC trading, we need another participant.

Update the structure:

struct Offer {

    address maker;

    address taker;

    address tokenOffered;

    address tokenRequested;

    uint256 amountOffered;

    uint256 minimumAmountRequested;

    uint256 expiry;

    uint256 nonce;

    OfferStatus status;

}

The new field:

address taker;

represents the counterparty who accepted the trade.

Before acceptance:

maker = Alice

taker = address(0)

After acceptance:

maker = Alice

taker = Bob

This gives the protocol an explicit record of both parties.

Updating Acceptance

Now acceptance records the counterparty.

function acceptOffer(
    uint256 offerId
)
    external
{
    Offer storage offer = offers[offerId];

    _requireOpenOffer(offer);

    offer.taker = msg.sender;

    offer.status = OfferStatus.Accepted;

    emit OfferAccepted(
        offerId,
        msg.sender
    );
}

The state transition is now clearer.

Before:

Open

maker:
Alice

taker:
none

After:

Accepted

maker:
Alice

taker:
Bob

The contract now knows exactly who negotiated the trade.

Adding Acceptance Events

Just like offer creation, acceptance needs an event.

event OfferAccepted(
    uint256 indexed offerId,
    address indexed taker
);

This allows external systems to react.

For example:

A backend service can listen for:

OfferAccepted

and automatically begin escrow preparation.

A frontend can update:

Status:
Accepted
Waiting for escrow

Events become the communication layer between blockchain state and applications.

Preventing Double Acceptance

Consider this sequence:

Transaction 1:
Bob accepts offer #10

Transaction 2:
Charlie accepts offer #10

Only one should succeed.

Our _requireOpenOffer check already prevents this.

After Bob's transaction:

offer.status = OfferStatus.Accepted;

The second transaction sees:

OfferStatus.Accepted

and reverts.

This is why explicit state machines are powerful.

The contract does not need complicated logic.

The state itself prevents invalid actions.

Why This Matters for Confidential OTC

At first glance, acceptance looks like a simple update.

It is not.

Acceptance is the point where private negotiation becomes a binding agreement.

In traditional OTC markets, this moment happens after:

price discovery,
counterparty verification,
risk checks,
legal confirmation.

On-chain, the smart contract replaces much of that coordination.

The contract becomes the neutral agreement layer.

With Sapphire, this process can remain confidential:

Trader A
   |
   |
Private Offer
   |
   v

Oasis Sapphire

   |
   |
Accepted Agreement
   |
   v

Base Settlement

The public chain does not need to observe every negotiation step.

It only needs proof that settlement conditions were satisfied.

Preparing for Escrow

Acceptance alone is still not enough.

A malicious counterparty could accept an offer and then disappear.

Example:

Alice:

Locks:
500,000 USDC

Bob:

Accepts trade

Then Bob never provides ETH.

The protocol must solve this problem.

The next stage introduces escrow.

We will build:

ERC-20 token transfers,
secure custody,
allowance handling,
escrow state tracking,
settlement authorization,
withdrawal rules,
failure recovery.

This is where the protocol starts becoming an actual OTC settlement system rather than a negotiation registry.

Building the Escrow Layer

The acceptance flow gives us something important.

We now have agreement.

But agreement is not settlement.

This distinction is fundamental in financial protocols.

A traditional OTC desk does not send millions of dollars simply because two traders verbally agree on a price. There is usually a custody layer, a clearing process, or a settlement mechanism that guarantees both parties perform.

Smart contracts need the same separation.

The registry answers:

"Who agreed to trade?"

The escrow contract answers:

"Are the assets actually secured?"

Only after both questions have a valid answer should settlement begin.

Why Escrow Exists

Consider a simple failure scenario.

Alice creates an offer:

Sell:
500,000 USDC

Receive:
165 ETH

Bob accepts.

The registry now contains:

status = Accepted;

But nothing forces Bob to provide ETH.

The protocol has created an agreement without enforcement.

This is the difference between:

Negotiation Layer

and:

Settlement Layer

The escrow contract connects them.

Separating Escrow From the Registry

A common beginner design is putting everything into one contract.

Something like:

contract OTCProtocol {

    createOffer()

    acceptOffer()

    deposit()

    settle()

    cancel()

}

This looks convenient.

However, it creates several problems.

The contract now handles:

offer management,
token custody,
settlement,
permissions,
refunds.

Every additional responsibility increases audit complexity.

Instead, we separate concerns.

Our architecture becomes:

                 OTCRegistry

              "What was agreed?"
                    |
                    |
                    v

                  Escrow

              "Are assets locked?"
                    |
                    |
                    v

        SettlementCoordinator

              "Execute final trade"

Each contract has one job.

Creating Escrow.sol

Inside:

src/Escrow.sol

we create our custody contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {
    IERC20
} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";


contract Escrow {

}

The first dependency is ERC-20 support.

The escrow contract does not care whether the token is USDC, WETH, or another asset.

It only needs the standard interface.

Modeling Escrow Positions

An escrow position represents one side of a trade.

We need to store:

who deposited,
which token,
how much,
which offer it belongs to,
current state.

Let's define it.

contract Escrow {

    enum EscrowStatus {
        Pending,
        Deposited,
        Released,
        Refunded
    }


    struct Deposit {

        address depositor;

        address token;

        uint256 amount;

        uint256 offerId;

        EscrowStatus status;

    }

}

The structure is intentionally small.

Escrow contracts should avoid unnecessary state.

Every stored variable creates another invariant that must remain correct forever.

Tracking Deposits

Now we need storage.

mapping(uint256 => Deposit) public deposits;

uint256 public depositCounter;

Each deposit receives an identifier.

Example:

Deposit #42

Offer:
#100

Depositor:
Alice

Token:
USDC

Amount:
500000

This identifier becomes useful during settlement.

Depositing Assets

Now we can implement the first important function.

function deposit(
    uint256 offerId,
    address token,
    uint256 amount
)
    external
    returns (uint256 depositId)
{

    require(
        amount > 0,
        "Invalid amount"
    );


    IERC20(token).transferFrom(
        msg.sender,
        address(this),
        amount
    );


    depositId = ++depositCounter;


    deposits[depositId] = Deposit({

        depositor: msg.sender,

        token: token,

        amount: amount,

        offerId: offerId,

        status: EscrowStatus.Deposited

    });

}

The flow is:

User approves the escrow contract.
Escrow pulls tokens using transferFrom.
A deposit record is created.
The protocol now knows assets are secured.

Why Approval Comes First

ERC-20 tokens do not allow arbitrary contracts to move funds.

The user must first approve spending.

The sequence is:

User Wallet

approve()

      |

      v

Escrow Contract

transferFrom()

      |

      v

Escrow Balance

This is standard ERC-20 behavior.

For production systems, frontends usually combine these steps into a single user experience.

The user sees:

"Deposit 500,000 USDC"

rather than manually performing approval and transfer operations.

Safe Transfer Handling

The previous example uses:

IERC20(token).transferFrom()

However, production contracts should handle tokens that do not properly return boolean values.

OpenZeppelin provides:

SafeERC20

Let's update the contract.

import {
    SafeERC20
} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";


contract Escrow {

    using SafeERC20 for IERC20;

}

Now deposits become:

IERC20(token).safeTransferFrom(
    msg.sender,
    address(this),
    amount
);

This protects against non-standard ERC-20 implementations.

Adding Events

Like the registry, escrow needs events.

event Deposited(
    uint256 indexed depositId,
    uint256 indexed offerId,
    address indexed depositor,
    address token,
    uint256 amount
);

Then after creating the deposit:

emit Deposited(
    depositId,
    offerId,
    msg.sender,
    token,
    amount
);

External systems can now monitor escrow activity.

For example:

Offer Accepted

        |

        v

Waiting for Deposits

        |

        v

Both Sides Funded

        |

        v

Settlement Ready

The Escrow Invariant

The most important property of this contract is:

Escrowed funds
=
Funds controlled by protocol rules

Users should never be able to bypass the settlement process.

After depositing:

Alice
 |
 | 500,000 USDC
 v

Escrow Contract

Alice cannot simply withdraw.

Bob cannot withdraw.

The only valid paths are:

Successful Settlement

or

Authorized Refund

This is the core security property.

Connecting Escrow to Acceptance

Right now the escrow contract does not know whether an offer was actually accepted.

That is intentional.

Remember our separation of responsibilities.

The registry knows:

Offer #100

Maker:
Alice

Taker:
Bob

Status:
Accepted

The escrow knows:

Deposit #55

Offer:
#100

Amount:
500,000 USDC

Status:
Deposited

The settlement coordinator will connect these pieces.

Introducing the Settlement Coordinator

The final architecture becomes:

                 Sapphire

              OTCRegistry

        Negotiation + Agreement


                    |

                    v


                  Escrow

          Asset Security Layer


                    |

                    v


        SettlementCoordinator

             Cross-chain Execution


                    |

                    v


                  Base

          Public Settlement

The coordinator becomes the bridge between confidential negotiation and public execution.

Why This Architecture Fits Sapphire + Base

This separation lets each network do what it does best.

Sapphire handles:

private offers,
confidential quotes,
negotiation state.

Escrow handles:

asset custody,
enforcement.

Base handles:

transparent settlement,
final ownership changes.

The protocol does not attempt to make one chain solve every problem.

Instead, it assigns responsibilities.

Next Section

The escrow layer now provides:

ERC-20 custody,
deposit tracking,
safe token transfers,
event indexing,
clear ownership boundaries.

The next part will implement the final settlement path.

We will cover:

SettlementCoordinator.sol
cross-chain settlement design
proving escrow conditions
releasing funds safely
Base integration patterns
replay protection across chains
handling failures and cancellations

This is where the complete OTC protocol architecture comes together.

Building the Settlement Coordinator

At this point, the protocol has three important capabilities.

The registry can create and accept agreements.
The escrow contract can lock assets.

What remains is the most important operation:

Moving from a private agreement into final settlement.

This is where the architecture becomes interesting.

The protocol intentionally separates:

Private negotiation

        |

        v

Verified agreement

        |

        v

Public settlement

The negotiation does not happen on Base.

The final ownership transfer does.

Why Settlement Should Be Separate

A common mistake is allowing the escrow contract to directly perform settlement.

Something like:

function settle()
external
{
    transferTokens();
}

This couples custody and execution.

The escrow contract now needs to understand:

who receives funds,
which chain settlement happens on,
whether signatures are valid,
whether external messages are trusted.

That creates unnecessary complexity.

Instead, escrow only answers:

"Are the required assets secured?"

The settlement coordinator answers:

"Should the trade execute?"

Creating SettlementCoordinator.sol

Inside:

src/SettlementCoordinator.sol

we create:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;


contract SettlementCoordinator {

}

The coordinator will eventually communicate with:

OTCRegistry

        |

        |

Escrow

        |

        |

Base Settlement Layer

Defining Settlement State

A settlement has its own lifecycle.

It is different from an offer lifecycle.

The offer lifecycle:

Open

 |

 v

Accepted

 |

 v

Escrowed

 |

 v

Settled

The settlement lifecycle:

Created

 |

 v

Verified

 |

 v

Executed

 |

 v

Completed

Let's model this.

enum SettlementStatus {

    Pending,

    Ready,

    Executed,

    Failed

}

This prevents ambiguous states.

Settlement Records

The coordinator needs to know:

which offer is being settled,
which escrow positions are involved,
who receives what,
whether execution happened.

Create the structure:

struct Settlement {

    uint256 offerId;

    uint256 makerDeposit;

    uint256 takerDeposit;

    address maker;

    address taker;

    SettlementStatus status;

}

A settlement is not an offer.

An offer describes intention.

A settlement describes execution.

Keeping those separate avoids mixing negotiation state with financial state.

Storing Settlements

mapping(uint256 => Settlement)
public settlements;


uint256 public settlementCounter;

Example:

Settlement #7

Offer:
#421


Maker:
Alice


Taker:
Bob


Maker Deposit:
USDC


Taker Deposit:
ETH


Status:
Ready

Creating a Settlement

Once both sides have escrowed funds, we create a settlement.

function createSettlement(
    uint256 offerId,
    uint256 makerDeposit,
    uint256 takerDeposit,
    address maker,
    address taker
)
external
returns(uint256 settlementId)
{

    settlementId = ++settlementCounter;


    settlements[settlementId] =
        Settlement({

            offerId: offerId,

            makerDeposit: makerDeposit,

            takerDeposit: takerDeposit,

            maker: maker,

            taker: taker,

            status: SettlementStatus.Pending

        });

}

This function does not move funds.

That is intentional.

Settlement creation is a coordination step.

Verifying Escrow Conditions

Before execution, we need proof that both sides funded the trade.

The coordinator should never trust user input.

A malicious user could attempt:

makerDeposit = fakeDepositId

The coordinator must verify directly with escrow.

The pattern becomes:

Escrow

"Is deposit X valid?"

        |

        v

SettlementCoordinator

"Proceed or reject"

Escrow Interface

Instead of importing the entire escrow contract, define a small interface.

interface IEscrow {

    function getDeposit(
        uint256 depositId
    )
    external
    view
    returns(
        address depositor,
        address token,
        uint256 amount,
        uint256 offerId,
        uint8 status
    );

}

The coordinator only knows what it needs.

This reduces coupling.

Making Settlement Ready

Now we can verify both deposits.

function markReady(
    uint256 settlementId
)
external
{

    Settlement storage settlement =
        settlements[settlementId];


    require(
        settlement.status ==
        SettlementStatus.Pending,
        "Invalid state"
    );


    settlement.status =
        SettlementStatus.Ready;

}

In production, this function would perform full escrow validation.

The simplified version demonstrates the state machine.

Executing Settlement

Execution is where assets finally move.

The coordinator instructs escrow:

Release maker asset

        +

Release taker asset

The important rule:

Both sides execute atomically.

Either:

Alice receives ETH

Bob receives USDC

or:

Nothing happens

Partial settlement is dangerous.

Atomic Settlement Pattern

A bad implementation:

releaseAliceFunds();

releaseBobFunds();

If the second operation fails:

Alice receives funds

Bob receives nothing

A production system requires transactional atomicity.

The better pattern:

function settle(
    uint256 settlementId
)
external
{

    Settlement storage settlement =
        settlements[settlementId];


    require(
        settlement.status ==
        SettlementStatus.Ready,
        "Not ready"
    );


    // execute both transfers


    settlement.status =
        SettlementStatus.Executed;

}

Because Solidity transactions revert entirely on failure, the operation is atomic.

Cross-Chain Settlement Design

Now we reach the interesting architectural question.

How does Sapphire communicate with Base?

The answer is not:

"Move the whole application to Base."

The answer is:

Create a settlement message.

The flow becomes:

Sapphire

Private Trade Agreement

        |

        v

Settlement Message

        |

        v

Base

Public Execution

The settlement message contains only what is necessary.

For example:

struct SettlementMessage {

    bytes32 tradeId;

    address receiver;

    address token;

    uint256 amount;

    uint256 nonce;

}

Notice what is missing.

No negotiation history.

No quotes.

No private strategy.

Only the information required for final execution.

Why This Matters

The privacy boundary becomes very clear.

Before settlement:

Confidential

After settlement:

Public

This mirrors traditional finance.

A hedge fund may privately negotiate a block trade.

But once settlement occurs, ownership changes become visible.

The blockchain is not replacing OTC markets.

It is improving the settlement layer.

Adding Replay Protection

Cross-chain systems introduce another risk.

A valid settlement message could potentially be submitted twice.

Example:

Message:

Pay Alice 500 ETH

Executed once.

Then replayed.

Executed again.

This is why every settlement message needs uniqueness.

The simplest mechanism:

mapping(bytes32 => bool)
processedMessages;

Before execution:

require(
    !processedMessages[id],
    "Already executed"
);

After:

processedMessages[id] = true;

One small mapping prevents catastrophic duplication.

Current Architecture

We now have:

                 Oasis Sapphire


          Confidential Negotiation


                    |

                    v


              Settlement Message


                    |

                    v


                   Base


          Transparent Final Settlement

Each layer has a clear responsibility.

Integrating Oasis Sapphire Confidential Execution

The settlement architecture is now complete.

However, we have not yet fully answered the original question:

How do we actually make OTC negotiation confidential?

So far, we have built a conventional Solidity protocol:

offers,
signatures,
escrow,
settlement coordination.

Those components work on any EVM-compatible chain.

The reason Oasis Sapphire is interesting is that it changes the privacy model of the application.

Instead of asking:

"How do we encrypt everything before putting it on-chain?"

we can ask:

"Which parts of the application should execute privately?"

That distinction is extremely important.

Public Blockchains and Information Leakage

On a traditional EVM chain, contract state is transparent.

If a contract stores:

struct Offer {

    address maker;

    address tokenOffered;

    uint256 amount;

    uint256 price;

}

then anyone can eventually inspect:

who created the offer,
what asset they want,
how much they are trading,
the conditions.

Even if the frontend hides this information, the blockchain does not.

For OTC trading, that is a problem.

The negotiation itself is valuable information.

What Sapphire Changes

Oasis Sapphire provides confidential EVM execution.

The developer experience remains familiar:

pragma solidity ^0.8.24;

contract OTCRegistry {

}

but execution happens inside a confidential environment.

Sensitive state can remain protected while the contract continues using Solidity patterns.

The important architectural shift is:

Before Sapphire:

User

 |
 |
Encrypted Data

 |
 |
Public Smart Contract

 |
 |
Everyone Observes State

After Sapphire:

User

 |
 |
Confidential Contract Execution

 |
 |
Protected State

 |
 |
Only Authorized Outputs Revealed

Moving the Registry to Sapphire

The OTC Registry is the natural candidate for Sapphire.

Why?

Because the registry contains negotiation information.

The escrow and final settlement layer do not need the same privacy guarantees.

A better architecture becomes:

                 Oasis Sapphire


          OTCRegistry

     Private Offers + Quotes


                 |

                 |

          Settlement Proof


                 |

                 |

                  Base


          Final Asset Settlement

The registry becomes the private negotiation engine.

Confidential Offer Storage

Previously we stored:

mapping(uint256 => Offer)
private offers;

On a public chain, private storage is only private by convention.

On Sapphire, confidential state is enforced by the execution environment.

This means the contract can safely maintain information such as:

struct PrivateOffer {

    address maker;

    address requestedCounterparty;

    uint256 amount;

    uint256 price;

    bytes encryptedTerms;

}

without exposing every field publicly.

Private Quotes

Institutional OTC trading rarely happens with a single offer.

Usually the process looks like:

Trader:

"I want to sell 10 million USDC."

Market makers:

"Here are three quotes."

Trader:

"I accept quote #2."

A public blockchain would reveal every quote.

That creates unnecessary information leakage.

Sapphire allows this flow:

Trader

 |
 |
Private Request

 |
 |
Sapphire Contract

 |
 |
Market Makers Submit Quotes

 |
 |
Trader Accepts Best Quote

Only the final agreement needs to leave the confidential environment.

What Sapphire Does Not Hide

It is important not to overstate confidentiality.

Sapphire does not magically make everything invisible.

The final settlement on Base is public.

Observers can see:

settlement transactions,
transferred assets,
destination addresses,
execution timing.

The privacy boundary is:

Negotiation

Private


Settlement

Public

This is exactly the same separation used in traditional OTC markets.

Confidential Signatures

Our earlier EIP-712 flow becomes even more useful here.

Instead of broadcasting every signed message:

Offer Created

Quote Received

Counter Offer

Revised Quote

the application can keep those interactions confidential.

Only the final signed commitment becomes relevant.

The protocol effectively changes from:

Every negotiation step is public

to:

Only the final agreement is verifiable

Sapphire Design Principles

When building confidential contracts, the same engineering principles still apply.

Privacy does not replace good architecture.

We still need:

explicit state machines,
replay protection,
authorization checks,
safe token handling,
deterministic settlement.

Confidential execution protects information.

It does not protect incorrect logic.

Building the SDK and Production Workflow

The smart contracts are complete.

Now we need users to interact with them.

A professional protocol rarely exposes raw contract calls directly.

Instead, applications use an SDK layer.

Our repository already contains:

sdk/

    otcClient.ts

    signer.ts

    quotes.ts

This layer handles:

wallet connections,
typed messages,
signatures,
contract calls,
settlement tracking.

Creating the SDK Client

Example:

class OTCClient {

    constructor(
        private registryContract,
        private signer
    ) {}


    async createOffer(params) {

        return this.registryContract
            .createOffer(
                params.tokenOffered,
                params.tokenRequested,
                params.amount,
                params.minimum,
                params.expiry
            );

    }

}

The frontend should not know Solidity details.

It should think in business operations:

createOffer()

acceptOffer()

deposit()

settle()

Signing Offers

The SDK also handles EIP-712.

Example:

const signature =
await signer.signTypedData(
    domain,
    types,
    offer
);

The user sees:

Sell:

500,000 USDC

Receive:

165 ETH

Expires:

Tomorrow

not:

0x83ab29ff....

Readable signatures reduce user mistakes.

Frontend Flow

A complete user journey looks like:

Trader Opens App

        |

Creates OTC Request

        |

Signs Private Intent

        |

Market Makers Submit Quotes

        |

Trader Accepts Quote

        |

Assets Escrowed

        |

Settlement Message Created

        |

Base Transaction Executed

        |

Trade Complete

Testing the Protocol

Financial protocols require more than happy-path testing.

We should test:

invalid signatures,
expired offers,
double acceptance,
failed deposits,
replayed settlement messages,
unauthorized withdrawals.

Example Foundry Test

function testCannotAcceptExpiredOffer()
    public
{

    vm.warp(block.timestamp + 2 days);


    vm.expectRevert(
        OfferExpired.selector
    );


    registry.acceptOffer(
        offerId
    );

}

The goal is not simply proving success.

The goal is proving invalid behavior is impossible.

Fuzz Testing

OTC protocols have many numeric inputs:

amounts,
timestamps,
nonces,
token quantities.

Fuzz testing helps discover unexpected edge cases.

Example:

function testAmounts(
    uint256 amount
)
public
{

    vm.assume(amount > 0);


    createOffer(amount);

}

The framework automatically explores many values.

Security Checklist

Before deploying a protocol handling valuable assets:

Access Control

Verify:

only makers cancel offers,
only accepted counterparties settle,
only authorized coordinators release escrow.

Replay Protection

Verify:

signatures cannot be reused,
settlement messages cannot execute twice,
nonces increment correctly.

State Transitions

Verify:

Invalid:

Open → Settled

Valid:

Open
 |
Accepted
 |
Escrowed
 |
Settled

Token Safety

Use:

SafeERC20,
allowance checks,
zero address validation.

Failure Recovery

Every financial protocol needs failure paths.

Examples:

expired offers,
abandoned settlements,
cancelled negotiations.

A protocol is not defined only by successful trades.

It is defined by how safely it handles failure.

Final Architecture

The completed system looks like this:

                    Trader A


                       |

                       |

              Oasis Sapphire


        Confidential OTC Registry

        - Private Offers

        - Private Quotes

        - Signed Agreements


                       |

                       |

              Settlement Message


                       |

                       |

                    Base


        Public Settlement Layer

        - Asset Transfer

        - Final Ownership


                       |

                       |

                    Trader B

Conclusion

Large trades require different infrastructure from ordinary swaps.

Automated market makers are excellent for transparent liquidity.

They are not designed for confidential institutional negotiation.

An OTC protocol needs a different approach.

The architecture we built separates the problem into three layers:

Confidential Negotiation

Handled by Oasis Sapphire.

This protects sensitive trading information while preserving smart contract coordination.

Asset Security

Handled through escrow.

This ensures both parties commit funds before execution.

Public Settlement

Handled by Base.

This provides transparent final ownership transfer.

The result is not a replacement for decentralized exchanges.

It is a complementary system designed for a different class of trading.

Large financial transactions require both privacy and trust minimization.

Confidential execution provides the privacy.

Smart contracts provide the enforcement.

Public settlement provides the transparency.

Together, they create a practical foundation for the next generation of decentralized OTC trading systems.

Building a Confidential Cross-Chain Identity Protocol with Oasis Sapphire, ENS & Base

rayQu — Thu, 16 Jul 2026 07:15:44 +0000

The biggest paradox in Web3 identity is that while we demand privacy in the real world, our on-chain infrastructure defaults to absolute transparency. If you attach a KYC credential, credit score, or real name to your ENS domain, it is immediately indexable by anyone.

But what if you could store your sensitive Personally Identifiable Information (PII) inside a secure enclave, and only expose cryptographic proofs of that data to smart contracts on other chains?

In this advanced tutorial, we are building a Confidential Cross-Chain Identity Layer. We will use Oasis Sapphire (the first confidential EVM) as our secure vault, Base (Ethereum L2) as our execution environment, and the Oasis Privacy Layer (OPL) via Celer IM to bridge the two.

The Real-World Use Case: Compliant DeFi on Base

Imagine a DeFi lending protocol on Base that requires users to be non-US citizens and over 18 to access leverage.

The Problem: Storing "Country" and "Date of Birth" directly on Base violates privacy and data protection laws (like GDPR).
The Solution: The user mints an ENS name (alice.base.eth) on Base. They store their private KYC data in a smart contract on Oasis Sapphire. When the Base DeFi protocol queries the ENS resolver, the resolver triggers a cross-chain message via OPL to Sapphire. Sapphire computes the logic inside a Trusted Execution Environment (TEE), checking if age > 18 && country != US, and returns a simple true or false back to Base.

No PII is ever leaked, the public RPCs see nothing but ciphertext, and the DeFi protocol remains fully compliant.

Architecture & Interaction Flow

We will utilize EIP-3668 (CCIP-Read) for off-chain data resolution and Celer Inter-Chain Messaging (IM) for state synchronization between Base and Sapphire.

sequenceDiagram
    participant User
    participant DeFi as Base DeFi Protocol
    participant Resolver as Base ENS Resolver
    participant Relayer as Celer IM / OPL
    participant Sapphire as Oasis Sapphire (TEE)

    User->>Sapphire: 1. Encrypt & Store KYC (Age, Country)
    Note over Sapphire: State is encrypted end-to-end
    User->>DeFi: 2. Request Undercollateralized Loan
    DeFi->>Resolver: 3. Verify compliance for `alice.base.eth`
    Resolver->>Relayer: 4. Dispatch Cross-Chain Request
    Relayer->>Sapphire: 5. Execute query inside TEE
    Sapphire-->>Sapphire: 6. Decrypt -> Check logic -> Re-encrypt
    Sapphire->>Relayer: 7. Emit boolean compliance proof
    Relayer->>Resolver: 8. CCIP-Read Callback with Proof
    Resolver-->>DeFi: 9. Returns `true` (Compliant)
    DeFi-->>User: 10. Loan Approved

Repository Structure

For this advanced stack, we will use a monorepo built with Hardhat/Foundry to manage multi-chain deployments.

cross-chain-identity/
├── contracts/
│   ├── base/
│   │   ├── ENSIdentityResolver.sol     # Custom ENS Resolver on Base
│   │   └── IDeFiProtocol.sol           # Mock DeFi contract
│   ├── sapphire/
│   │   ├── ConfidentialVault.sol       # TEE-encrypted storage contract
│   │   └── VerificationEngine.sol      # Logic computation 
│   └── interfaces/
│       ├── ICelerMessageBus.sol        # Celer IM interface
│       └── IOasisPrivacyLayer.sol
├── scripts/
│   ├── deploy-base.js
│   ├── deploy-sapphire.js
│   └── bridge-setup.js
├── hardhat.config.js                   # Configured for Base & Sapphire networks
└── package.json

Step-by-Step Implementation

Step 1: The Confidential Vault on Oasis Sapphire
Oasis Sapphire is EVM-compatible but runs inside secure enclaves. State variables are encrypted by default. We will write ConfidentialVault.sol to store user data securely.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@oasisprotocol/sapphire-contracts/contracts/Sapphire.sol";

contract ConfidentialVault {
    // This state is encrypted inside the Sapphire TEE
    struct IdentityRecord {
        uint256 dateOfBirth;
        string countryCode;
        bool isVerified;
    }

    mapping(address => IdentityRecord) private privateIdentities;

    // Address of the Celer Message Bus on Sapphire
    address public messageBus;

    constructor(address _messageBus) {
        messageBus = _messageBus;
    }

    /**
     * @dev User updates their private data. Transactions are end-to-end encrypted.
     */
    function updateIdentity(uint256 _dob, string calldata _countryCode) external {
        privateIdentities[msg.sender] = IdentityRecord({
            dateOfBirth: _dob,
            countryCode: _countryCode,
            isVerified: true
        });
    }

    /**
     * @dev Executed via cross-chain message from Base.
     * Computes compliance without revealing raw data.
     */
    function verifyComplianceCrossChain(address _user, address _baseCallbackContract) external {
        require(msg.sender == messageBus, "Only Relayer");

        IdentityRecord memory record = privateIdentities[_user];

        // Confidential computation: Is over 18 and not US?
        bool isCompliant = false;
        if (record.isVerified) {
            uint256 age = (block.timestamp - record.dateOfBirth) / 31556926; // Approx years
            if (age >= 18 && keccak256(bytes(record.countryCode)) != keccak256(bytes("US"))) {
                isCompliant = true;
            }
        }

        // Construct payload to send back to Base
        bytes memory message = abi.encode(_user, isCompliant);

        // Send via Celer IM (Oasis Privacy Layer) back to Base
        // (Pseudocode for Celer IM integration)
        ICelerMessageBus(messageBus).sendMessage(
            _baseCallbackContract,
            8453, // Base Mainnet Chain ID
            message
        );
    }
}

Note: Because Sapphire encrypts calldata, an observer on block explorers will only see gibberish bytes, completely protecting the user's DoB and Country.

Step 2: The Cross-Chain ENS Resolver on Base
On Base, our custom ENS Resolver implements executeWithCCIPRead to pause execution, request data from Sapphire, and resume via a callback once Celer IM delivers the result.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@ensdomains/ens-contracts/contracts/resolvers/PublicResolver.sol";

contract ENSIdentityResolver {
    address public messageBus;
    address public sapphireVaultAddress;

    mapping(address => bool) public complianceCache;

    error OffchainLookup(address sender, string[] urls, bytes callData, bytes4 callbackFunction, bytes extraData);

    constructor(address _messageBus, address _sapphireVaultAddress) {
        messageBus = _messageBus;
        sapphireVaultAddress = _sapphireVaultAddress;
    }

    /**
     * @dev Standard check called by DeFi protocols on Base.
     */
    function isUserCompliant(address _user) external view returns (bool) {
        // If not in cache, trigger CCIP-Read / Cross-chain flow
        if (!complianceCache[_user]) {
            string[] memory urls = new string[](1);
            urls[0] = "[https://our-relayer-gateway.io/verify/](https://our-relayer-gateway.io/verify/){sender}/{data}";

            revert OffchainLookup(
                address(this),
                urls,
                abi.encodePacked(_user),
                this.celfCallback.selector,
                abi.encode(_user)
            );
        }
        return complianceCache[_user];
    }

    /**
     * @dev Callback executed by Celer Executor once Sapphire computes the result.
     */
    function executeMessage(
        address _srcContract,
        uint64 _srcChainId,
        bytes calldata _message,
        address _executor
    ) external payable returns (uint256) {
        require(msg.sender == messageBus, "Only Celer Message Bus");
        require(_srcChainId == 23294, "Only Sapphire Mainnet"); // Sapphire Chain ID
        require(_srcContract == sapphireVaultAddress, "Invalid source contract");

        (address user, bool isCompliant) = abi.decode(_message, (address, bool));

        // Cache the confidential state on Base
        complianceCache[user] = isCompliant;

        return 1;
    }
}

Step 3: Hardhat Deployment & Orchestration
To deploy this, your hardhat.config.js needs RPC endpoints for both networks. Oasis Sapphire provides standard Web3 RPC endpoints, making the developer experience seamless.

module.exports = {
  solidity: "0.8.19",
  networks: {
    base: {
      url: "[https://mainnet.base.org](https://mainnet.base.org)",
      accounts: [process.env.PRIVATE_KEY]
    },
    sapphire: {
      url: "[https://sapphire.oasis.io](https://sapphire.oasis.io)",
      chainId: 23294,
      accounts: [process.env.PRIVATE_KEY]
    }
  }
};

When integrating the frontend, use the @oasisprotocol/sapphire-paratime wrapper for Ethers.js. This automatically encrypts your transactions on the client side before sending them to the Sapphire network.

import { ethers } from "ethers";
import * as sapphire from "@oasisprotocol/sapphire-paratime";

// Wrap your standard signer to enable end-to-end encryption
const provider = new ethers.providers.Web3Provider(window.ethereum);
const signer = sapphire.wrap(provider.getSigner());

// Now call the vault; the calldata will be automatically encrypted!
const vaultContract = new ethers.Contract(VAULT_ADDR, VAULT_ABI, signer);
await vaultContract.updateIdentity(946684800, "UK");

Step 4: Building the CCIP-Read Off-Chain Gateway (Node.js)
When the Base contract reverts with OffchainLookup, the user's wallet (or the dApp frontend) will automatically send an HTTP GET request to the URL specified in the revert. We need an Express server to catch this, trigger the Celer IM message to Sapphire, and manage the asynchronous state.

// server.js (Gateway)
const express = require('express');
const { ethers } = require('ethers');

const app = express();
app.use(express.json());

app.get('/verify/:sender/:data', async (req, res) => {
    const { sender, data } = req.params;

    try {
        // Decode the user address from the original call data
        const decodedUser = ethers.utils.defaultAbiCoder.decode(['address'], data)[0];

        // 1. Trigger the cross-chain message on the Relayer/Sapphire side
        // In a production environment, this triggers a relayer bot to pay gas on Sapphire
        await dispatchToSapphire(decodedUser);

        // 2. We return a pending state or an acknowledgment 
        // Note: Because Celer IM is asynchronous, the Base contract will receive 
        // the actual boolean value from the Celer Executor in a subsequent block.
        res.status(200).json({
            status: "pending_cross_chain_execution",
            message: "Celer IM dispatched to Oasis Sapphire. Await callback on Base."
        });

    } catch (error) {
        res.status(500).json({ error: error.message });
    }
});

app.listen(3000, () => console.log('CCIP-Read Gateway running on port 3000'));

Step 5: Gas Abstraction (Zero-Gas UX on Sapphire)
A major UX hurdle in cross-chain architectures is forcing the user to hold the native gas token (ROSE) on Oasis Sapphire just to update their identity.

To solve this, we can implement the Oasis Gas Station Network (GSN) or a custom Paymaster. Because Sapphire supports EIP-4337 (Account Abstraction) and standard meta-transactions, you can set up a Gas Relayer. The user signs an EIP-712 message containing their encrypted KYC data, and your backend submits it to Sapphire, paying the ROSE gas fee on their behalf. The user only ever needs ETH on Base.

Step 6: Security & Threat Model
When dealing with cross-chain PII, the threat model extends beyond standard smart contract bugs:

State Desyncs: If a user updates their age on Sapphire but the Base cache isn't refreshed, the Base DeFi protocol might operate on stale data. Always implement a Time-to-Live (TTL) or an expiration timestamp on the complianceCache mapping on Base.
Replay Attacks: Ensure the Celer IM callback (executeMessage) strictly verifies _srcChainId and _srcContract. If an attacker can spoof the message origin, they can arbitrarily set their complianceCache to true on Base.
TEE Side-Channels: While Sapphire's Secure Enclaves (Intel SGX) protect data in use, developers must ensure they do not leak data via access patterns. Avoid writing logic that significantly changes gas consumption based on the value of a private variable.

Conclusion

By combining ENS on Base with the Oasis Privacy Layer, we've built a robust architecture that solves Web3's biggest compliance hurdle. Smart contracts on L2s can now leverage confidential logic, request attestations, and maintain composability without doxxing their users.

The future of Web3 identity isn't fully transparent, nor is it siloed in isolated private chains. The future is modular, cross-chain, and selectively private.

If you found this advanced tutorial helpful, leave a comment below or check out the Oasis Privacy Layer Documentation to dive deeper into confidential smart contracts!

Building a Confidential Data Clean Room on Oasis Sapphire: Privacy-Preserving Analytics Across Organizations

rayQu — Sat, 13 Jun 2026 17:27:40 +0000

One of the biggest unsolved problems in data engineering is collaboration between organizations that do not trust each other enough to share raw data.

Consider the following scenarios:

Two crypto exchanges want to identify overlapping fraudulent wallets.
Multiple banks want to detect coordinated money laundering activity.
Healthcare providers want to compare patient cohorts for research.
Marketing companies want to measure customer overlap.
Cybersecurity firms want to identify shared threat actors.

In all of these cases, the organizations would benefit from collaboration.

The problem is that they cannot expose their underlying datasets.

Traditional solutions usually involve:

Trusted third parties
Secure legal agreements
Data escrow providers
Multi-party computation frameworks
Internal clean room infrastructure

These solutions are expensive, operationally complex, and often difficult to audit.

This is where Oasis Sapphire, once again (:p), becomes interesting.

Instead of sharing raw data, organizations can:

Encrypt datasets locally
Submit encrypted data to Sapphire
Execute confidential computations
Receive aggregated results
Never expose the underlying records

In this tutorial we will build a complete confidential data clean room that allows multiple organizations to compare datasets without revealing them. I will also answer any comments/dms I'm going to get as soon as possible!

We will cover:

Architecture design
Confidential smart contracts
Dataset encryption
Secure submissions
Set intersection algorithms
Similarity metrics
Differential privacy
Attestation concepts
Production deployment considerations

By the end, you will have a system capable of performing privacy-preserving analytics across organizations.

The Problem

Suppose Exchange A maintains a list of suspicious wallets:

0x111...
0x222...
0x333...
0x444...

Exchange B maintains its own list:

0x333...
0x444...
0x555...
0x666...

Both exchanges want to know:

How many suspicious wallets do we have in common?

A traditional approach would require both exchanges to reveal their full datasets.

This creates multiple risks:

Customer privacy violations
Regulatory concerns
Competitive intelligence leakage
Data retention obligations

The clean room model allows the question to be answered without exposing the datasets themselves.

The final output becomes:

{
  "overlap": 2
}

Nothing else is revealed.

High-Level Architecture
                Exchange A
                     |
                     |
            Encrypt Dataset
                     |
                     v

          +------------------+
          | Oasis Sapphire   |
          | Confidential     |
          | Data Clean Room  |
          +------------------+

                     ^
                     |
            Encrypt Dataset
                     |
                     |

                Exchange B

                     |
                     v

              Aggregated Result

               overlap = 2

The critical observation is that raw data never leaves the confidential execution boundary in plaintext.

Project Structure
sapphire-clean-room/

├── contracts/
│   ├── CleanRoom.sol
│   ├── SimilarityEngine.sol
│
├── scripts/
│   ├── deploy.ts
│
├── worker/
│   ├── encryptDataset.ts
│   ├── submitDataset.ts
│
├── api/
│   ├── server.ts
│
├── datasets/
│   ├── exchangeA.csv
│   ├── exchangeB.csv
│
├── test/
│   ├── cleanRoom.test.ts
│
└── hardhat.config.ts

Understanding Data Clean Rooms

A data clean room is a controlled environment where:

Data providers submit information
Computations occur
Raw data remains hidden
Only approved outputs leave the environment

Traditionally, cloud providers offer clean room services.

The challenge is trust.

Organizations must trust:

Infrastructure operators
Database administrators
Cloud providers

Sapphire introduces a different trust model.

The computation occurs inside confidential execution environments backed by Trusted Execution Environments (TEEs).

This means computation is isolated from the host system itself.

Step 1: Dataset Registration Contract

We begin by allowing organizations to register encrypted datasets.

pragma solidity ^0.8.20;

contract CleanRoom {

    struct Dataset {
        bytes encryptedData;
        address owner;
        uint256 submittedAt;
        bool active;
    }

    uint256 public datasetCount;

    mapping(uint256 => Dataset) public datasets;

    event DatasetSubmitted(
        uint256 indexed datasetId,
        address indexed owner
    );

    function submitDataset(
        bytes calldata encryptedData
    ) external {

        datasetCount++;

        datasets[datasetCount] = Dataset({
            encryptedData: encryptedData,
            owner: msg.sender,
            submittedAt: block.timestamp,
            active: true
        });

        emit DatasetSubmitted(
            datasetCount,
            msg.sender
        );
    }
}

This contract stores encrypted payloads only.
The blockchain never sees plaintext records.

Why Encryption Alone Is Not Enough

A common misconception is:

"Just encrypt the data and store it on-chain."

Encryption protects storage.

It does not solve computation.

Eventually somebody must decrypt and process the data.

The real challenge is:

How do we compute on sensitive information without exposing it?

That is where Sapphire enters the picture.

Step 2: Confidential Set Intersection

The most common clean room operation is set intersection.

We want:

A ∩ B without revealing A or B.

Inside Sapphire we can safely decrypt datasets and perform the operation.

pragma solidity ^0.8.20;

contract SimilarityEngine {

    function computeIntersection(
        address[] memory a,
        address[] memory b
    )
        public
        pure
        returns (uint256)
    {
        uint256 overlap;

        for (uint256 i = 0; i < a.length; i++) {

            for (uint256 j = 0; j < b.length; j++) {

                if (a[i] == b[j]) {
                    overlap++;
                }
            }
        }

        return overlap;
    }
}

This implementation is intentionally simple. We will optimize it later.

Why This Naive Approach Does Not Scale

Suppose:

Dataset A = 100,000 entries
Dataset B = 100,000 entries

Complexity becomes:

100,000 × 100,000 = 10 billion comparisons

This is not practical. We need better data structures.

Step 3: Hash-Based Intersection

Instead of nested loops we build lookup tables.

function computeIntersectionFast(
    bytes32[] memory a,
    bytes32[] memory b
)
    public
    pure
    returns (uint256)
{
    uint256 overlap;

    for (uint256 i = 0; i < a.length; i++) {

        for (uint256 j = 0; j < b.length; j++) {

            if (a[i] == b[j]) {
                overlap++;
            }
        }
    }

    return overlap;
}

In production, off-chain preprocessing should convert datasets into hashed representations.

Benefits include:

Smaller payloads
Better privacy
Faster matching
Similarity Metrics

Sometimes overlap counts are insufficient.

Organizations may want similarity scores.

A common metric is Jaccard Similarity.

The formula is:

Jaccard Similarity = Number of Shared Records / Total Unique Records

Interpretation:

0.0 = completely different
1.0 = identical datasets

Implementing Jaccard Similarity
function computeJaccard(
    uint256 intersection,
    uint256 unionSize
)
    public
    pure
    returns (uint256)
{
    return (intersection * 1e18) / unionSize;
}

Returning scaled values avoids floating-point arithmetic.

Step 4: Local Dataset Encryption

Before submission, organizations encrypt locally.

Example Node.js utility:

import crypto from "crypto";

const algorithm = "aes-256-gcm";

export function encryptDataset(
  plaintext: string,
  key: Buffer
) {

  const iv = crypto.randomBytes(16);

  const cipher =
    crypto.createCipheriv(
      algorithm,
      key,
      iv
    );

  let encrypted =
    cipher.update(
      plaintext,
      "utf8",
      "hex"
    );

  encrypted += cipher.final("hex");

  const tag =
    cipher.getAuthTag();

  return {
    iv: iv.toString("hex"),
    encrypted,
    tag: tag.toString("hex")
  };
}

Encryption occurs before data leaves the organization.

Step 5: Submission Worker

import { ethers } from "ethers";

async function submitDataset() {

  const contract =
    new ethers.Contract(
      CONTRACT_ADDRESS,
      ABI,
      signer
    );

  const encrypted =
    await encryptDataset(
      dataset,
      key
    );

  const tx =
    await contract.submitDataset(
      ethers.toUtf8Bytes(
        JSON.stringify(encrypted)
      )
    );

  await tx.wait();
}

This worker becomes the ingestion pipeline.

Differential Privacy Layer

Even aggregate results can leak information.

Example:

Dataset overlap: 1245

Repeated queries could allow reconstruction attacks.

To mitigate this, we can introduce controlled noise.

function addNoise(
    uint256 value,
    uint256 noise
)
    internal
    pure
    returns (uint256)
{
    return value + noise;
}

Result:

Actual overlap: 1245
Reported overlap: 1242

Privacy improves while preserving utility.

Multi-Party Data Clean Rooms

The real power appears when more than two organizations participate.

Exchange A
Exchange B
Exchange C
Exchange D

        |
        v

   Sapphire Clean Room

        |
        v

  Aggregated Analysis

Examples:

Shared fraud detection
Shared sanctions monitoring
Shared AML screening
Shared cybersecurity intelligence
Production Security Considerations
Dataset Poisoning

An attacker may submit fabricated data.

Mitigations:

Staking requirements
Dataset signatures
Reputation systems
Replay Attacks

An attacker may repeatedly submit old datasets.

Mitigations:

mapping(bytes32 => bool)
public processedHashes;

Reject duplicates.

Query Abuse

Attackers may repeatedly request computations.

Mitigations:

Rate limiting
Access control
Usage quotas
Membership Inference Attacks

An attacker may attempt to infer whether a specific record exists.

Mitigations:

Differential privacy
Minimum cohort sizes
Query restrictions
Future Extensions

This architecture can evolve into:

Confidential AML Network
Banks privately compare suspicious entities.
Cross-Exchange Fraud Detection
Exchanges identify shared attackers.
Healthcare Research Network
Hospitals compare patient cohorts without sharing records.
Privacy-Preserving Advertising Analytics
Companies measure audience overlap.
Confidential Supply Chain Intelligence
Manufacturers compare supplier data without exposing relationships.

Conclusion

Most blockchain applications focus on moving value.

Far fewer explore moving information safely.

Confidential data clean rooms represent a massive opportunity because they solve a real-world problem that organizations face every day:

How can we collaborate on data without exposing the data itself?

Oasis Sapphire provides a powerful foundation for this model by combining smart contracts with confidential execution.

Instead of choosing between privacy and computation, we can finally have both.

The result is a new class of applications where organizations can learn from each other without surrendering control of their most valuable asset: their data.

Building a Confidential Event-Driven Indexer on Oasis Sapphire (Beyond The Graph Pattern)

rayQu — Thu, 11 Jun 2026 07:18:56 +0000

Most blockchain indexing systems today assume a very simple model:

all blockchain data is public, and indexing is just a deterministic transformation of public events.

This assumption works well for analytics platforms like dashboards, DEX trackers, or portfolio tools.

However, it breaks down in real-world scenarios where:

event data is sensitive (wallet behavior, internal flows, private classifications)
indexing logic itself is proprietary (risk models, scoring systems, compliance logic)
or you need selective disclosure (some users can see more data than others)

In traditional architectures, you are forced to choose between:

transparency (but no privacy)
privacy (but no verifiability)

Oasis Sapphire introduces a third option:

execute indexing logic inside a confidential runtime (TEE-backed), while still using standard EVM interfaces.

This tutorial builds a confidential event-driven indexer, where:

raw blockchain events remain public
classification logic is hidden
only sanitized outputs are exposed externally

Think of it as:

“The Graph, but the mapping function is private and policy-controlled.”

Why This Is Architecturally Different

To understand why this matters, let's compare the standard indexing pipeline:

Traditional Indexing (The Graph-style)

Smart Contract -> Events -> Indexer -> Public Database -> API

Everything is:

deterministic
reproducible
fully observable

This is great for trustlessness, but it creates problems:

any adversary can reconstruct your analytics logic
wallet behavior is fully exposed
proprietary scoring models cannot exist

Confidential Indexing (Oasis Sapphire model)

Smart Contract -> Events
                     ↓
        Sapphire Confidential Runtime
                     ↓
          Private State Transformation
                     ↓
         Offchain Worker + Storage
                     ↓
            Sanitized Public API

Key difference:

The transformation function (indexing logic) is no longer public.

Real-World Use Case

We will build a confidential DeFi activity indexer that:

tracks swaps on a DEX
computes internal risk scores
classifies activity (low / medium / high risk)
hides wallet-level behavior
exposes only aggregated metrics

This is useful for:

institutional compliance dashboards
private DeFi analytics platforms
MEV-aware monitoring systems
regulated crypto infrastructure

Why Not Just Use Existing Indexers?

Existing solutions like The Graph or custom ETL pipelines have a fundamental limitation:

they cannot hide the transformation logic itself.

Even if you obfuscate the backend:

input events are public
transformations are reproducible
reverse-engineering is trivial

With Sapphire:

logic executes in a TEE (Trusted Execution Environment)
computation is not externally observable
only final outputs are revealed

Project Structure (Production-Grade)

confidential-indexer/
│
├── contracts/
│   ├── Dex.sol
│   ├── ConfidentialIndexer.sol
│   ├── interfaces/
│
├── worker/
│   ├── indexer.ts
│   ├── eventDecoder.ts
│   ├── riskEngine.ts
│   ├── db.ts
│
├── api/
│   ├── server.ts
│   ├── routes/
│
├── scripts/
│   ├── deploy.ts
│
├── test/
│   ├── indexer.test.ts
│
└── hardhat.config.ts

Step 1: Event Source Contract (DEX Simulation)

We start with a simple decentralized exchange emitting swap events.

This is intentionally minimal, the complexity happens in the indexing layer.

// contracts/Dex.sol
pragma solidity ^0.8.20;

contract Dex {

    event Swap(
        address indexed user,
        address indexed tokenIn,
        address indexed tokenOut,
        uint256 amount,
        uint256 timestamp
    );

    function swap(
        address tokenIn,
        address tokenOut,
        uint256 amount
    ) external {
        emit Swap(
            msg.sender,
            tokenIn,
            tokenOut,
            amount,
            block.timestamp
        );
    }
}

Key idea:

We deliberately include structured data so the indexer can apply richer classification logic.

Step 2: Confidential Indexer Contract (Sapphire Core Logic)

This is the core of the system.

Key properties:

runs inside Sapphire confidential runtime
decrypts event payloads
applies private scoring rules
stores encrypted internal state

// contracts/ConfidentialIndexer.sol
pragma solidity ^0.8.20;

import "@oasisprotocol/sapphire-contracts/contracts/Sapphire.sol";

contract ConfidentialIndexer {

    struct SwapData {
        address user;
        address tokenIn;
        address tokenOut;
        uint256 amount;
        uint256 timestamp;
    }

    struct PoolState {
        uint256 riskScore;
        uint256 volume;
    }

    mapping(bytes32 => PoolState) private pools;

    event Indexed(bytes32 indexed poolId, uint256 riskScore, uint256 volume);

    function processSwap(bytes calldata encryptedSwap) external {

        // Step 1: decrypt inside TEE
        bytes memory decrypted = Sapphire.decrypt(encryptedSwap);

        SwapData memory data = abi.decode(decrypted, (SwapData));

        // Step 2: derive pool identifier
        bytes32 poolId = keccak256(
            abi.encodePacked(data.tokenIn, data.tokenOut)
        );

        // Step 3: update private state
        PoolState storage state = pools[poolId];

        state.volume += data.amount;

        uint256 risk = computeRisk(data, state);

        state.riskScore = risk;

        // Step 4: emit only sanitized output
        emit Indexed(poolId, state.riskScore, state.volume);
    }

    function computeRisk(
        SwapData memory data,
        PoolState memory state
    )
        internal
        pure
        returns (uint256)
    {
        uint256 score = 0;

        // Large trade heuristic
        if (data.amount > 1_000_000 ether) {
            score += 5;
        }

        // Volume spike heuristic
        if (state.volume > 10_000_000 ether) {
            score += 3;
        }

        return score;
    }
}

Why this is important:

The key innovation is:

the risk model is never observable externally

That means:

adversaries cannot game your scoring system
analytics logic is not reproducible
you can build proprietary indexers

Step 3: Event Worker (Offchain Index Aggregator)

This component listens to Sapphire outputs and stores them.

Unlike traditional indexers, it does NOT compute logic, only stores results.

// worker/indexer.ts
import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);

const contract = new ethers.Contract(
  process.env.CONTRACT_ADDRESS,
  ABI,
  provider
);

contract.on("Indexed", async (poolId, riskScore, volume) => {

  console.log("Indexed update received");

  await db.upsert({
    poolId: poolId.toString(),
    riskScore: riskScore.toString(),
    volume: volume.toString(),
    updatedAt: Date.now()
  });
});

Step 4: Public API Layer (Sanitized Exposure)

This layer ensures no raw or sensitive data leaks.

// api/server.ts
import express from "express";
const app = express();

app.get("/pool/:id", async (req, res) => {

  const pool = await db.get(req.params.id);

  res.json({
    pool: req.params.id,
    riskScore: pool.riskScore,
    volume: pool.volume,

    // intentionally no user-level data exposed
    granularity: "aggregated"
  });
});

app.listen(3000);

Key Design Insight: Privacy Boundary Model

This architecture introduces a strict separation:

Layer	Visibility
Smart contract events	Public
Sapphire execution logic	Confidential
Risk model / heuristics	Hidden
Aggregated outputs	Public (sanitized)

Hard Engineering Problems (Important Section)

1. Determinism vs Confidential Execution

TEE environments must remain deterministic:

same input -> same output
but without revealing internal computation steps

2. Trust in Index Correctness

Because computation is hidden:

you rely on enclave guarantees
or multi-worker validation systems

3. Composability Limitations

Unlike The Graph:

results are not universally reproducible
external contracts cannot verify raw computation

4. State Replay Problem

Encrypted state introduces challenges:

historical recomputation is non-trivial
debugging requires replay tooling inside TEE

Why This Matters

This pattern enables a new category of systems:

private blockchain analytics
institutional DeFi infrastructure
MEV-resistant monitoring tools
compliance-aware data pipelines

It shifts the paradigm from:

“everything is transparent and verifiable”

to:

“computation is verifiable, but not necessarily observable”

Final Thoughts

Most blockchain infrastructure assumes transparency is always beneficial.

But in real systems, especially financial and institutional contexts:

privacy is required
analytics are proprietary
and data exposure is a liability

Oasis Sapphire enables a third design space:

verifiable execution with confidential logic

This indexer pattern is just one example of what becomes possible when indexing itself becomes programmable and private.

Building a Verifiable Multi-Chain AI Execution Layer with Oasis ROFL + Sapphire + TDX

rayQu — Thu, 21 May 2026 07:02:11 +0000

Most AI on blockchain applications today still rely heavily on trust.

The AI inference happens on centralized servers.
The wallet keys live in backend infrastructure.
Smart contracts trust APIs blindly.
And users have no way to verify what actually happened off-chain.

In this tutorial, we’ll build something far more advanced:

A verifiable confidential AI execution layer using:

Oasis Sapphire
ROFL (Runtime Offchain Logic)
Intel TDX Trusted Execution Environments
Remote Attestation
Enclave-managed wallet signing
Cross-chain transaction execution

This architecture enables:

Private AI inference
Verifiable off-chain execution
Secure enclave wallet management
Cross-chain automation
Trust-minimized AI agents

Without needing zkML or expensive zkVM proving systems.

What We’re Building

+---------------------------------------------------+
|                 User / dApp                       |
+--------------------+------------------------------+
                     |
                     v
+---------------------------------------------------+
|          Sapphire Smart Contract                  |
|---------------------------------------------------|
| - Stores trusted ROFL identities                  |
| - Verifies enclave signatures                     |
| - Accepts/verifies AI execution results           |
+--------------------+------------------------------+
                     ^
                     |
             Signed attested result
                     |
+---------------------------------------------------+
|          ROFL App Inside Intel TDX                |
|---------------------------------------------------|
| - Runs AI inference                               |
| - Calls APIs                                      |
| - Generates wallet keys internally                |
| - Signs responses                                 |
| - Performs remote attestation                     |
+--------------------+------------------------------+
                     |
                     v
         External APIs / Other Chains / LLMs

Why This Matters

Most AI agents today suffer from major trust issues.

| Problem                       | Why It Matters                    |
| ------------------------------------------------------------------|                                                              
| Centralized inference         | Outputs can be manipulated        |
| Backend wallet custody        | Keys can be stolen                |
| Hidden execution logic        | Impossible to audit               |
| Fake oracle data              | Contracts trust unverifiable APIs |
| Cross-chain trust assumptions | Bridges increase attack surface   |

ROFL changes this entirely.

Instead of trusting a backend server:

computation runs inside a Trusted Execution Environment
outputs are cryptographically signed
enclave identities are attested
smart contracts verify execution authenticity

This creates trustless off-chain compute.

Core Technologies

Sapphire

Sapphire is Oasis Network’s confidential EVM runtime.

Features:

encrypted calldata
encrypted state
confidential smart contract execution
Solidity/EVM compatibility

Unlike traditional EVM chains, node operators cannot inspect execution data.

ROFL (Runtime Offchain Logic)

ROFL allows developers to run arbitrary off-chain logic inside TEEs.

This means your application can:

call APIs
run AI models
sign transactions
manage secrets
execute autonomous workflows

while remaining cryptographically verifiable.

Intel TDX

Intel TDX provides confidential virtual machines with:

encrypted memory
hardware isolation
attestation support
strong execution guarantees

ROFL supports TDX-backed confidential compute environments.

Architecture Deep Dive

        User Prompt
              |
              v
+-----------------------------------+
|      Sapphire Smart Contract      |
+-----------------------------------+
              |
              v
+-----------------------------------+
|       ROFL TDX Enclave            |
|-----------------------------------|
| 1. Receives encrypted request     |
| 2. Runs AI inference              |
| 3. Generates signed result        |
| 4. Signs with enclave wallet      |
+-----------------------------------+
              |
              v
      Cross-chain execution
              |
              v
     Ethereum / Base / Arbitrum

Step 1: Install Oasis CLI

curl -sSL https://get.oasis.io | bash

Verify installation:

oasis --version

Step 2: Create a ROFL Application

mkdir ai-executor
cd ai-executor

oasis rofl init

This generates:

rofl.yaml

The manifest defines:

enclave configuration
TEE type
networking
policies
deployment settings

Step 3: Configure ROFL Manifest

Example advanced configuration:

name: ai-executor
version: 0.1.0

tee: tdx
kind: containers

resources:
  memory: 8192
  cpus: 4

network:
  paratime: sapphire

policy:
  quotes:
    pcs:
      tdx: {}

container:
  runtime: docker

Important Manifest Settings

| Field       |    Purpose                     |
| ------------|--------------------------------|                                
| tee         | TEE backend (SGX/TDX)          |
| kind        | Raw or containerized workloads |
| resources   | Enclave memory + CPU           |
| network     | Connected ParaTime             |
| policy      | Attestation requirements       |

Step 4: Build the Enclave

oasis rofl build

This generates an ORC bundle:

my-app.orc

The bundle includes:

enclave measurements
metadata
binaries
identity hashes

Step 5: Generate Wallet Keys Inside the Enclave

This is one of the most powerful features.

Traditional AI agents store keys:

in .env files
in cloud KMS systems
in backend infrastructure

Instead:

Wallet Key Generated INSIDE TEE
        ↓
Key Never Leaves Enclave
        ↓
Transactions Signed Securely

No backend custody required.

Example Rust Wallet Generation

use k256::ecdsa::SigningKey;
use rand_core::OsRng;

fn generate_wallet() -> SigningKey {
    SigningKey::random(&mut OsRng)
}

The private key only exists inside enclave memory.

Step 6: Run AI Inference Securely

Example inference service:

from transformers import pipeline

classifier = pipeline(
    "text-classification",
    model="distilbert-base-uncased"
)

result = classifier("Execute strategy?")
print(result)

Inside ROFL:

prompts remain confidential
inference is hidden from operators
outputs are signed by the enclave

Secure AI Execution Flow

User Prompt
    ↓
ROFL Enclave
    ↓
Private AI Inference
    ↓
Signed Output
    ↓
Sapphire Verification

Step 7: Remote Attestation

Attestation proves:

“This exact code executed inside genuine TDX hardware.”

Without attestation:

TEEs are just claims

With attestation:

contracts can verify enclave authenticity

Attestation Flow

ROFL App Starts
      ↓
TEE Generates Measurement
      ↓
Attestation Quote Produced
      ↓
Quote Registered On-Chain
      ↓
Sapphire Verifies Identity

Step 8: Register the ROFL App

Create the application:

oasis rofl create \
  --network testnet \
  --paratime sapphire

Deploy updates:

oasis rofl update

This stores:

enclave identities
measurements
execution policy
attestation configuration

on-chain.

Step 9: Smart Contract Verification

Now we create a Sapphire contract that verifies:

enclave identity
signatures
trusted execution

Solidity Verification Contract

pragma solidity ^0.8.20;

contract VerifiedAIExecutor {

    mapping(bytes32 => bool) public trustedEnclaves;

    function registerEnclave(bytes32 enclaveId) external {
        trustedEnclaves[enclaveId] = true;
    }

    function verifyExecution(
        bytes32 enclaveId,
        bytes calldata signature,
        bytes calldata result
    ) external view returns (bool) {

        require(trustedEnclaves[enclaveId], "Untrusted enclave");

        // Signature verification logic
        return true;
    }
}

Step 10: Cross-Chain Transaction Execution

This is where things become extremely powerful.

The enclave can:

manage Ethereum wallets
sign Base transactions
execute Arbitrum transactions
interact with multiple chains

without bridges.

Cross-Chain Execution Flow

AI Strategy Generated
        ↓
TEE Decides Action
        ↓
TEE Signs Transaction
        ↓
Broadcast To Ethereum RPC
        ↓
Result Returned To Sapphire

This enables:

autonomous trading systems
AI treasury management
confidential DAO executors
secure cross-chain agents

Step 11: Deterministic Execution Logging

AI outputs are often nondeterministic.

To improve auditability:

hash prompts
hash outputs
hash model versions

Example:

let hash = sha256(prompt + model_version + output);

Then store:

output hash
enclave ID
timestamp

on-chain.

Security Considerations

TEEs are powerful but not perfect.

Potential risks:

side-channel attacks
hardware trust assumptions
speculative execution vulnerabilities

Still, TEEs provide dramatically stronger guarantees than centralized servers.

Why This Architecture Is Important

Traditional AI systems rely on:

trusted cloud providers
centralized APIs
backend custody

ROFL + Sapphire introduces:

Traditional Backend	ROFL + Sapphire
Centralized inference	TEE-attested inference
Backend wallet storage	Enclave-managed keys
Hidden execution	Verifiable execution
API trust assumptions	Hardware-backed trust
Centralized orchestration	Permissionless infrastructure

Real-World Use Cases

Verifiable AI Trading Agents

The enclave:

runs private strategies
signs trades
proves execution authenticity

Confidential Healthcare AI

patient data remains private
inference occurs inside TEEs
outputs become auditable

Autonomous DAO Executors

AI agents:

propose governance actions
execute treasury operations
prove execution legitimacy

Multi-Chain AI Wallet Infrastructure

One enclave can securely control:

Ethereum
Base
Arbitrum
future ecosystems

without custodial bridges.

The Bigger Picture

ROFL introduces something Web3 desperately needs:

Trustless Off-Chain Compute

Not:

“another oracle”
“another AI chain”

But:

verifiable computation
confidential execution
autonomous infrastructure

This creates a new primitive between:

smart contracts
AI infrastructure
confidential computing
cross-chain orchestration

Final Thoughts

Most AI + blockchain systems today still require enormous trust assumptions.

With:

Sapphire
ROFL
TDX
attestation
enclave-managed wallets

developers can finally build systems where:

computation is private
outputs are verifiable
execution is cryptographically authenticated

This unlocks:

autonomous AI agents
confidential DeFi automation
verifiable off-chain compute
secure cross-chain execution
trusted AI infrastructure

And this is likely only the beginning of what confidential compute on Oasis can enable.

Resources

Building a Confidential AI RAG Agent on Oasis Sapphire + ROFL

rayQu — Tue, 12 May 2026 08:42:31 +0000

An advanced Oasis Network tutorial for developers who want to combine AI, confidential smart contracts, encrypted vector storage, and verifiable off-chain execution.

Introduction

Most AI applications today leak sensitive data somewhere in the pipeline.

Even if the frontend is secure, prompts, embeddings, retrieval context, API calls, or inference metadata are usually visible to:

Cloud providers
Backend operators
Database administrators
Analytics tools
Infrastructure vendors

This becomes a serious issue for:

Financial AI assistants
Healthcare copilots
Private enterprise knowledge bases
Identity systems
Reputation engines
On-chain AI agents

In this tutorial, we will build a Confidential Retrieval-Augmented Generation (RAG) Agent using:

Oasis Sapphire
ROFL (Runtime Off-chain Logic)
Encrypted storage
Smart contracts
Off-chain AI inference
Verifiable confidential execution

Instead of storing prompts or embeddings publicly, we will:

Encrypt user knowledge before storage
Perform confidential retrieval
Execute AI inference off-chain through ROFL
Return only approved outputs on-chain
Keep sensitive data hidden from everyone except the user

What We Are Building

We are building a confidential AI assistant where:

Users upload private documents
Documents are encrypted before storage
Embeddings are generated off-chain
Retrieval happens confidentially
AI inference runs through ROFL
Smart contracts manage permissions and integrity

The architecture combines:

Confidential EVM execution
Off-chain compute
AI pipelines
Privacy-preserving storage
Ethereum compatibility

Final Architecture

flowchart TD
    A[User Uploads Document] --> B[Frontend Encrypts Data]
    B --> C[IPFS / Arweave Storage]
    B --> D[Oasis Sapphire Contract]

    D --> E[ROFL Worker]
    E --> F[Embedding Model]
    F --> G[Encrypted Vector Store]

    H[User Query] --> I[Confidential Retrieval]
    I --> G

    G --> J[Relevant Context]
    J --> K[LLM Inference]
    K --> L[Signed Response]
    L --> D

    D --> M[Verified Output Returned]

Why Sapphire Matters

Traditional EVM chains expose:

Contract state
Function arguments
Internal logic
Metadata
User activity

Sapphire changes this model by introducing confidential smart contracts.

This allows developers to:

Encrypt application state
Generate secrets securely
Store confidential metadata
Protect AI prompts
Hide retrieval logic
Secure wallet-based identity systems

Unlike “privacy through frontend encryption,” Sapphire provides confidentiality at the runtime layer.

Why ROFL Matters

Large AI models cannot realistically run fully on-chain.

Inference requires:

GPUs
External APIs
Heavy compute
Vector databases
Long-running processes

ROFL enables:

Off-chain execution
Trusted compute
Verifiable outputs
Secure communication with Sapphire

Think of ROFL as a confidential execution bridge between:

Smart contracts
AI systems
External infrastructure

Tech Stack

Layer	Technology
Smart Contracts	Solidity + Sapphire
Off-chain Compute	ROFL
Storage	IPFS / Arweave
AI Embeddings	Sentence Transformers
Vector Search	ChromaDB / Qdrant
Frontend	Next.js
Wallet	RainbowKit + Wagmi
Encryption	AES-GCM
AI Inference	OpenAI / Local LLM

Step 1: Setting Up Sapphire

Create a new project:

mkdir confidential-rag-agent
cd confidential-rag-agent
npm init -y

Install dependencies:

npm install hardhat ethers dotenv

Initialize Hardhat:

npx hardhat

Add Sapphire configuration:

require('@oasisprotocol/sapphire-hardhat');

module.exports = {
  solidity: '0.8.20',
  networks: {
    sapphire: {
      url: 'https://testnet.sapphire.oasis.io',
      chainId: 23295,
      accounts: [process.env.PRIVATE_KEY]
    }
  }
}

Step 2: Creating the Confidential Contract

Our contract will:

Store encrypted metadata
Register AI responses
Verify ROFL signatures
Manage access permissions

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ConfidentialRAG {

    struct Document {
        string cid;
        bytes encryptedKey;
        address owner;
    }

    mapping(uint256 => Document) public documents;

    uint256 public docCounter;

    event DocumentStored(uint256 indexed id, address owner);

    function storeDocument(
        string memory cid,
        bytes memory encryptedKey
    ) external {

        documents[docCounter] = Document({
            cid: cid,
            encryptedKey: encryptedKey,
            owner: msg.sender
        });

        emit DocumentStored(docCounter, msg.sender);

        docCounter++;
    }
}

Step 3: Encrypting User Data

Never upload raw user data directly.

Instead:

Generate a local encryption key
Encrypt the document client-side
Upload encrypted data to IPFS
Store only references on Sapphire

Architecture:

sequenceDiagram
    participant U as User
    participant F as Frontend
    participant I as IPFS
    participant S as Sapphire

    U->>F: Upload document
    F->>F: Generate AES key
    F->>F: Encrypt document
    F->>I: Upload encrypted file
    I-->>F: CID
    F->>S: Store CID + encrypted key

Example encryption:

const encrypted = await encryptFile(file, secretKey)

Step 4: Generating Embeddings Through ROFL

We now process the encrypted content off-chain.

ROFL workers can:

Fetch encrypted files
Decrypt securely
Generate embeddings
Store vectors
Return signed proofs

ROFL Flow:

flowchart LR
    A[Sapphire Event] --> B[ROFL Worker]
    B --> C[Decrypt File]
    C --> D[Generate Embeddings]
    D --> E[Vector Database]
    E --> F[Signed Result]
    F --> G[Sapphire Contract]

Example Python embedding pipeline:

from sentence_transformers import SentenceTransformer

model = SentenceTransformer('all-MiniLM-L6-v2')

embedding = model.encode(document_text)

Step 5: Confidential Retrieval

When a user asks a question:

Query embedding is generated
Similar vectors are retrieved
Relevant context is assembled
Context stays encrypted/private
LLM receives only authorized information

This prevents:

Prompt leakage
Public retrieval inspection
Competitor scraping
Metadata deanonymization

Step 6: AI Inference Layer

The inference engine can use:

OpenAI APIs
Local Llama models
Mistral
DeepSeek
Confidential GPU infrastructure

Prompt assembly example:

prompt = f"""
Context:
{retrieved_context}

Question:
{user_question}
"""

Step 7: Returning Verifiable Results

ROFL signs outputs before returning them.

The contract verifies:

Authorized worker
Valid signature
Fresh timestamp
Integrity proof

This creates a verifiable AI pipeline.

Security Design

Our architecture protects against:

Threat	Mitigation
Public prompt leakage	Sapphire confidentiality
Storage snooping	Client-side encryption
Vector DB exposure	Encrypted embeddings
Fake AI outputs	ROFL signatures
Metadata correlation	Confidential execution
Frontend compromise	Wallet authorization

Is this Architecture good?

Most Web3 AI projects today are not truly private.

They usually:

Store prompts publicly
Leak retrieval context
Expose embeddings
Depend entirely on centralized APIs

Oasis enables something different:

Confidential AI infrastructure.

That is a much bigger opportunity than simple “AI on blockchain” narratives. So yes, this is huge.

Improvements (!)

You can extend this architecture with:

Multi-Agent Systems

Use multiple ROFL workers for:

Retrieval
Ranking
Moderation
Inference
Verification

zkML Integration

Combine:

ROFL confidentiality
ZK proofs
Verifiable inference

Token-Gated Knowledge Access

Require NFT or token ownership before retrieval.

Cross-Chain Identity

Use confidential reputation scores across:

Ethereum
Base
Arbitrum
Solana

Potential Real-World Use Cases

Industry	Use Case
Healthcare	Private medical copilots
Finance	Confidential portfolio AI
Gaming	Hidden strategy agents
Enterprise	Secure internal knowledge AI
DAOs	Private governance research
Identity	Confidential trust scoring

Performance Considerations

AI systems are expensive.

Optimize:

Embedding caching
Batched retrieval
Async inference
Vector compression
Partial encryption
Event indexing

Avoid pushing unnecessary data on-chain.

The blockchain should coordinate trust, not store entire AI workloads.

Common Mistakes Developers Make

Storing Raw AI Data On-Chain

Never store:

Prompts
Embeddings
Conversations
User documents

Directly on public chains.

Treating Frontend Encryption as Enough

Frontend-only privacy still exposes backend operators.

Ignoring Metadata Privacy

Even transaction patterns can reveal sensitive information.

Production Architecture

flowchart TB
    subgraph User Layer
        A[Wallet User]
        B[Next.js Frontend]
    end

    subgraph Confidential Layer
        C[Sapphire Smart Contract]
        D[ROFL Workers]
    end

    subgraph AI Layer
        E[Embedding Models]
        F[LLM Inference]
        G[Vector Database]
    end

    subgraph Storage Layer
        H[IPFS]
        I[Arweave]
    end

    A --> B
    B --> C
    B --> H
    C --> D
    D --> E
    D --> F
    D --> G
    H --> D
    I --> D

Closingg Thoughts

The next generation of AI applications will not be won by the teams with the biggest models.

They will be won by the teams that solve:

Privacy
Data ownership
Confidential computation
Verifiable inference
User-controlled AI

Oasis Sapphire and ROFL provide a powerful foundation for building that future.

Instead of thinking about blockchain as "where data lives". think about it as a trust coordination layer for confidential AI systems.

That shift changes everything.

Useful Resources

Oasis Network

Ethereum / Smart Contract Development

Decentralized Storage

AI / Vector Databases

Frontend / Wallet Integration

Security / Cryptography

Building a Transparent Crypto Donation Ledger with Oasis Network (Beginner Tutorial)

rayQu — Mon, 20 Apr 2026 07:52:23 +0000

Crypto donations are great for transparency… until your donors open a block explorer and see a wall of hashes.

In this tutorial, we’ll build a simple, verifiable donation ledger using Oasis Network, a blockchain that lets you combine privacy + transparency using confidential smart contracts.

What we’re building

A minimal system where:

Donations are recorded on-chain
Expenses are recorded and linked to donations
Anyone can see totals and categories (public)
Sensitive details stay private but provable

Why Oasis?

With Oasis Sapphire (its confidential EVM):

You write Solidity like Ethereum
But contract state can be encrypted
You can expose only what matters (e.g. totals)

Docs: https://docs.oasis.io
Sapphire: https://oasis.net/sapphire

Step 1: Setup your environment

You can use Hardhat like a normal EVM chain:

mkdir oasis-ledger && cd oasis-ledger
npm init -y
npm install --save-dev hardhat
npx hardhat

Add Oasis Sapphire testnet config:

module.exports = {
  networks: {
    sapphire: {
      url: "https://testnet.sapphire.oasis.io",
      accounts: [PRIVATE_KEY]
    }
  },
  solidity: "0.8.20"
};

Step 2: Write the smart contract

Create DonationLedger.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract DonationLedger {

    struct Donation {
        address donor;
        uint amount;
    }

    struct Expense {
        uint amount;
        string category;
    }

    Donation[] public donations;
    Expense[] public expenses;

    uint public totalDonations;
    uint public totalSpent;

    function donate() external payable {
        donations.push(Donation(msg.sender, msg.value));
        totalDonations += msg.value;
    }

    function addExpense(uint _amount, string memory _category) external {
        expenses.push(Expense(_amount, _category));
        totalSpent += _amount;
    }

    function getBalance() public view returns (uint) {
        return totalDonations - totalSpent;
    }
}

This is intentionally simple:

Fully transparent totals
Expand later with private metadata (Oasis advantage)

Step 3: Deploy to Oasis Sapphire

Create a deploy script:

async function main() {
  const Ledger = await ethers.getContractFactory("DonationLedger");
  const ledger = await Ledger.deploy();

  await ledger.waitForDeployment();

  console.log("Deployed to:", await ledger.getAddress());
}

main();

Run:

npx hardhat run scripts/deploy.js --network sapphire

Step 4: Interact with the contract

Example (Hardhat console):

npx hardhat console --network sapphire

const ledger = await ethers.getContractAt("DonationLedger", "DEPLOYED_ADDRESS");

// donate
await ledger.donate({ value: ethers.parseEther("0.1") });

// add expense
await ledger.addExpense(ethers.parseEther("0.05"), "food");

// check totals
await ledger.totalDonations();
await ledger.totalSpent();

Step 5: Build a simple frontend (optional)

Even a basic UI can transform usability:

Show:
- Total donations
- Total spent
- Remaining balance
Add buttons:
- “Donate”
- “Add Expense” (admin)

You can use:

Next.js
ethers.js
wagmi

Step 6: Where Oasis shines (upgrade idea)

Right now everything is public.

With Oasis, you can:

Store private expense metadata (e.g. invoice hashes)
Keep donor notes confidential
Reveal only:
- totals
- categories
- proofs

This is done using confidential state inside Sapphire contracts.

Final result

Instead of showing donors this:

“Here’s our wallet, go check Etherscan”

You show them:

€100k raised
€40k spent on food
€20k spent on shelter

And every number is still verifiable on-chain

Takeaway

Using Oasis, you can build:

Transparent donation systems
Clean public dashboards
Private but provable accounting

All without leaving the EVM ecosystem.

Resources

Privacy-Preserving Federated Learning on Oasis Network (Sapphire ParaTime)

rayQu — Thu, 16 Apr 2026 09:21:10 +0000

Overview

In this tutorial, we’ll build an advanced machine learning system on the Oasis Network using confidential smart contracts (Sapphire ParaTime).

Instead of common examples (NFT auctions, oracles, etc.), we’ll implement:

Confidential Federated Learning with On-Chain Aggregation

The key points on why this tutorial is really on point

Data never leaves clients in plaintext
Model updates are encrypted
Aggregation happens inside TEEs
Fully privacy-preserving collaborative AI

🧠 Architecture

Clients (Hospitals / Devices)
|
| Encrypted Gradients
v
+-----------------------------+
| Oasis Sapphire ParaTime     |
|                             |
| - Decrypt gradients (TEE)   |
| - Aggregate updates         |
| - Update global model       |
+-----------------------------+
|
v
Clients download updated model

Tech Stack

Oasis Sapphire (Confidential EVM)
Solidity
Python (PyTorch)
Web3.py / ethers.js

Step 1: Smart Contract (Confidential Aggregator)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ConfidentialFederatedLearning {

    struct Update {
        bytes encryptedGradient;
    }

    mapping(address => Update) public updates;
    address[] public participants;

    bytes public globalModel;

    function submitUpdate(bytes calldata encryptedGradient) external {
        if (updates[msg.sender].encryptedGradient.length == 0) {
            participants.push(msg.sender);
        }

        updates[msg.sender] = Update(encryptedGradient);
    }

    function aggregate() external {
        bytes[] memory gradients = new bytes[](participants.length);

        for (uint i = 0; i < participants.length; i++) {
            gradients[i] = updates[participants[i]].encryptedGradient;
        }

        // Executed confidentially in Oasis Sapphire
        globalModel = confidentialAggregate(gradients);

        delete participants;
    }

    function confidentialAggregate(bytes[] memory gradients)
        internal
        returns (bytes memory)
    {
        // Placeholder logic (runs inside TEE)
        return abi.encodePacked("aggregated_model");
    }

    function getModel() external view returns (bytes memory) {
        return globalModel;
    }
}

Step 2: Local Training (PyTorch)

import torch
import torch.nn as nn
import torch.optim as optim

class SimpleModel(nn.Module):
    def __init__(self):
        super().__init__()
        self.fc = nn.Linear(10, 1)

    def forward(self, x):
        return self.fc(x)

def train_local(data, labels):
    model = SimpleModel()
    optimizer = optim.SGD(model.parameters(), lr=0.01)
    loss_fn = nn.MSELoss()

    for _ in range(5):
        optimizer.zero_grad()
        output = model(data)
        loss = loss_fn(output, labels)
        loss.backward()
        optimizer.step()

    return model.state_dict()

Step 3: Serialize + Encrypt Updates

import json
import base64

def serialize_weights(weights):
    return base64.b64encode(json.dumps({
        k: v.tolist() for k, v in weights.items()
    }).encode())

Step 4: Send Updates to Oasis

from web3 import Web3

w3 = Web3(Web3.HTTPProvider("https://testnet.sapphire.oasis.dev"))

contract_address = "YOUR_CONTRACT_ADDRESS"
abi = [...]  # compiled ABI

contract = w3.eth.contract(address=contract_address, abi=abi)

def send_update(encrypted_gradient, private_key):
    account = w3.eth.account.from_key(private_key)

    tx = contract.functions.submitUpdate(
        encrypted_gradient
    ).build_transaction({
        'from': account.address,
        'nonce': w3.eth.get_transaction_count(account.address),
        'gas': 2000000
    })

    signed = account.sign_transaction(tx)
    tx_hash = w3.eth.send_raw_transaction(signed.rawTransaction)

    return tx_hash

Step 5: Trigger Aggregation

def trigger_aggregation(private_key):
    account = w3.eth.account.from_key(private_key)

    tx = contract.functions.aggregate().build_transaction({
        'from': account.address,
        'nonce': w3.eth.get_transaction_count(account.address),
        'gas': 3000000
    })

    signed = account.sign_transaction(tx)
    tx_hash = w3.eth.send_raw_transaction(signed.rawTransaction)

    return tx_hash

Step 6: Fetch Global Model

Once the Oasis network has aggregated all encrypted updates inside the confidential execution environment, clients can retrieve the updated global model.

This step completes the federated learning cycle.

def get_global_model():
    model_bytes = contract.functions.getModel().call()
    return model_bytes

At this stage, the returned model_bytes represent the latest version of the collaboratively trained model.

In a real production system, this data would typically be:

A serialized PyTorch/TensorFlow model
Or compressed weight tensors
Or even encrypted checkpoints for secure distribution

The key idea is that the model itself becomes a shared decentralized artifact, continuously evolving without exposing any participant’s raw data.

Real Use Case #1: Healthcare AI Across Hospitals

One of the most impactful applications of this architecture is in healthcare machine learning.

Problem

Hospitals often cannot share patient data due to strict regulations such as:

GDPR (Europe)
HIPAA (United States)

This creates a major bottleneck:

Each hospital has only a partial view of reality.

As a result:

Disease prediction models are weaker
Rare conditions are underrepresented
AI generalization suffers significantly

Solution Using Oasis Confidential ML

With Oasis Sapphire, each hospital:

Trains a local model on private patient data
Extracts gradients or weight updates
Encrypts them automatically via confidential execution
Sends updates to the shared aggregation contract

The Oasis network then:

Aggregates updates inside a Trusted Execution Environment (TEE)
Prevents any party from seeing individual contributions
Produces a globally improved model

Why This Works So Well

Instead of centralizing sensitive data, we are centralizing intelligence, not information.

This shift has massive implications:

Patient data never leaves hospitals
Research collaboration becomes frictionless
Models benefit from global diversity of data
Compliance is preserved by design, not enforcement

In practice, this enables systems like:

Early disease detection models trained across continents
Rare condition classifiers with global coverage
Personalized treatment recommendation systems

Real Use Case #2: Cross-Bank Fraud Detection Network

Another powerful application is in financial systems.

Problem

Banks face a paradox:

Fraud detection improves with shared data
But banks cannot share customer transaction data

This leads to:

Fragmented fraud intelligence
Delayed detection of new fraud patterns
High false-negative rates

Solution: Confidential Federated Fraud Learning

Using this architecture:

Each bank:

Trains a fraud detection model locally
Learns patterns specific to its users
Computes gradient updates privately
Submits encrypted updates to Oasis

Oasis:

Aggregates all updates confidentially
Produces a global fraud detection model
Sends improved model back to all participants

Why This Is Powerful

The system effectively creates a collective fraud intelligence network without violating privacy.

This leads to:

Faster detection of new fraud patterns
Cross-bank intelligence without data exposure
Stronger anomaly detection models
Reduced financial losses across the ecosystem

Full Training Loop Visualization

Let’s now put everything together into a full lifecycle loop:

ROUND t (Federated Learning Cycle)

Client A (Hospital / Bank / Device)
    └── Train local model
    └── Compute gradients
    └── Encrypt updates
    └── Submit to Oasis

Client B
    └── Train
    └── Encrypt
    └── Submit

Client C
    └── Train
    └── Encrypt
    └── Submit

                ↓

     🔐 Oasis Sapphire TEE Layer
     ┌──────────────────────────────┐
     │ 1. Decrypt securely          │
     │ 2. Aggregate updates         │
     │ 3. Apply weighting (optional)│
     │ 4. Update global model       │
     └──────────────────────────────┘

                ↓

📦 Global Model Updated On-Chain

                ↓

Clients Pull Latest Model → Next Training Round

Advanced Enhancements (Production-Level Thinking)

At this stage, the system is already functional, but real-world deployments require additional sophistication.

1. Differential Privacy Layer

To further strengthen privacy guarantees, we can inject controlled noise into model updates before submission.

This ensures that even in edge cases, individual contributions cannot be reverse-engineered.

def add_noise(weights, epsilon=0.1):
    noisy_weights = {}

    for k in weights:
        noise = torch.randn_like(weights[k]) * epsilon
        noisy_weights[k] = weights[k] + noise

    return noisy_weights

This technique is widely used in privacy-preserving ML systems and complements Oasis’s confidential execution layer.

2. Weighted Aggregation Strategy

Not all participants contribute equally.

For example:

A hospital with 1M patients should have more influence than one with 1K
A bank with higher transaction volume should contribute more signal

So instead of simple averaging, we apply weighted aggregation.

This can be implemented inside the confidential contract layer to ensure fairness while preserving privacy.

3. Incentive Mechanism for Participants

A real decentralized ML system must also include economic incentives.

You can design:

Token rewards per valid update
Slashing for malicious or low-quality gradients
Reputation scoring for long-term contributors

This transforms the system into a self-sustaining AI network economy.

4. Hybrid ZK + Confidential ML Systems

An even more advanced extension is combining:

Zero-Knowledge Proofs (ZKPs)
Oasis confidential compute

This allows participants to prove properties like:

'My model was trained correctly'
'My data distribution satisfies constraints'
'No poisoning attacks were introduced'

without revealing any underlying data.

So Why Does This Architecture Matter

What we built here is not just a federated learning system.

It represents a shift in how machine learning systems are designed:

From centralized data collection → to decentralized intelligence collaboration

Oasis enables something very rare in blockchain systems:

Computation on private data
Without exposing the data itself
While still preserving verifiability

This unlocks entirely new categories of AI systems:

Privacy-first foundation models
Cross-organization collaborative AI
Decentralized intelligence networks

Where You Can Take This Next

If you want to push this further (and it gets very interesting), you can extend this system into:

Confidential LLM fine-tuning networks
Multi-agent decentralized reinforcement learning
Privacy-preserving recommendation systems
Genomics ML across research institutions
Token-incentivized AI training marketplaces

Closing Thought

The combination of federated learning + confidential execution fundamentally changes what is possible in machine learning systems.

Instead of asking:

"Where do we store the data?"

We now ask:

"How do we learn from data without ever seeing it?"

And that is exactly the space where Oasis Network becomes powerful.

Building a Confidential Sealed-Bid NFT Auction on Oasis Sapphire

rayQu — Fri, 20 Mar 2026 10:36:48 +0000

Ever wanted to run a blockchain auction without revealing bids until the end?

In this tutorial, we’ll build a sealed-bid NFT auction on Oasis Sapphire, where bids are fully encrypted, events are private, and the winner is publicly verifiable, perfect for NFT drops, private DeFi auctions, or confidential governance.

We’ll cover:

Why Sapphire for privacy-first auctions
Smart contract design for sealed-bid auctions
Off-chain bid commitment and encryption
Encrypted events on Sapphire
React + ethers.js frontend integration
Testing, deployment, and advanced tips

By the end, you’ll have a production-ready privacy-preserving auction.

Part 1: Why Privacy Matters on Blockchain Auctions

Traditional Ethereum-style auctions expose bids as soon as they hit the blockchain. This causes issues like:

Front-running attacks: Bots see your bid and immediately outbid you
Loss of privacy: High-value bids are visible to competitors
Manipulation risk: Public bids allow strategic manipulation

Oasis Sapphire solves this by offering:

Confidential calldata: Input values are encrypted
Encrypted events: Logs can be private but verifiable
EVM compatibility: Solidity contracts work with minimal changes

So the result: You can build auctions where nobody knows your bid until reveal, yet the outcome is fully trustless.

┌─────────────┐        submitBid(commitment)       ┌───────────────┐
│   Bidder A  │ ────────────────────────────────>  │  SealedAuction│
└─────────────┘                                    │ (encrypted)   │
┌─────────────┐        submitBid(commitment)       │               │
│   Bidder B  │ ────────────────────────────────>  │               │
└─────────────┘                                    └─────┬─────────┘
                                                      │
                                                      ▼
                                        ┌───────────────────────┐
                                        │ Reveal Phase          │
                                        │ - submit value+salt   │
                                        │ - verify commitment   │
                                        │ - determine winner    │
                                        └─────────┬─────────────┘
                                                  │
                                                  ▼
                                       ┌─────────────────────────┐
                                       │ Winner + Final Price    │
                                       │ (publicly verifiable)   │
                                       └─────────────────────────┘

Part 2: Project Setup

Create Hardhat Project

mkdir sapphire-nft-auction
cd sapphire-nft-auction
npm init -y
npm install --save-dev hardhat @nomiclabs/hardhat-ethers ethereum-waffle chai
npm install @oasisprotocol/sapphire-paratime

Configure Hardhat for Sapphire Testnet

require("@nomiclabs/hardhat-ethers");
require("@oasisprotocol/sapphire-paratime");

module.exports = {
  solidity: "0.8.20",
  networks: {
    sapphire_testnet: {
      url: "https://testnet.sapphire.oasis.io",
      chainId: 23295,
      accounts: [process.env.PRIVATE_KEY], // your testnet wallet
    },
  },
};

Make sure you fund your testnet wallet with some ROSE test tokens (Testnet Faucet)

Part 3: Smart Contract Architecture

We’ll implement a sealed-bid auction:

submitBid: Accepts encrypted bid commitments
reveal: Checks commitments, reveals bids, determines winner
events: Logs encrypted bid submissions

Create contracts/SealedAuction.sol:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract SealedAuction {
    struct Bid {
        bytes32 commitment;
        bool revealed;
    }

    address public owner;
    address public winner;
    uint256 public finalPrice;

    mapping(address => Bid) public bids;

    uint256 public biddingEnd;
    uint256 public revealEnd;

    event BidEncrypted(address indexed bidder, bytes32 encrypted);
    event Revealed(address indexed bidder, uint256 value);

    constructor(uint256 _biddingTime, uint256 _revealTime) {
        owner = msg.sender;
        biddingEnd = block.timestamp + _biddingTime;
        revealEnd  = biddingEnd + _revealTime;
    }

    function submitBid(bytes32 commitment) external {
        require(block.timestamp < biddingEnd, "Bidding closed");
        bids[msg.sender] = Bid({commitment: commitment, revealed: false});
        emit BidEncrypted(msg.sender, commitment);
    }

    function reveal(uint256 value, bytes32 salt) external {
        require(block.timestamp >= biddingEnd, "Reveal not started");
        require(block.timestamp < revealEnd, "Reveal ended");

        Bid storage b = bids[msg.sender];
        require(b.commitment == keccak256(abi.encodePacked(value, salt)), "Bad reveal");
        require(!b.revealed, "Already revealed");

        b.revealed = true;
        emit Revealed(msg.sender, value);

        if (value > finalPrice) {
            finalPrice = value;
            winner = msg.sender;
        }
    }
}

Key points to keep in mind:

Only the hash of the bid is stored on-chain, not the bid itself.
Bids remain private until reveal().
Events can optionally be encrypted for extra confidentiality.

Part 4: Off-Chain Bid Commitment

Before submitting a bid, you generate a commitment hash off-chain:

import { ethers } from "ethers";

function createCommitment(bidValue) {
  const salt = ethers.utils.hexlify(ethers.utils.randomBytes(32));
  const commitment = ethers.utils.keccak256(
    ethers.utils.defaultAbiCoder.encode(["uint256","bytes32"], [bidValue, salt])
  );
  return { commitment, salt };
}

// Example
const bid = createCommitment(500);
console.log("Commitment:", bid.commitment, "Salt:", bid.salt);

Salt prevents brute-force attacks on commitments
The commitment hash is sent on-chain using submitBid()

Bidder Client
+-----------------+
| bidValue + salt |
+--------+--------+
         |
         | keccak256 -> commitment
         v
+-----------------+     encrypted calldata    +------------------------+
| submitBid()     | ------------------------> | SealedAuction Contract |
| (commitment)    |                           | stores only commitment |
+-----------------+                           |                        |
                                              +-----------+------------+
                                                          |
                                               encrypted event emitted
                                                          |
                                                          v
                                               Off-chain listener/frontend
                                               (decrypts if authorized)

Part 5: Submitting & Revealing Bids

await auctionContract.submitBid(commitment);

// Wait until bidding period ends
await auctionContract.reveal(bidValue, salt);

On Sapphire, you can use encrypted calldata so even miners/validators don’t see the bid during submission.

Part 6: Adding NFT Rewards

Let’s take it a step further: the winner receives an NFT. Add this to your contract:

interface IERC721 {
    function safeMint(address to) external;
}

IERC721 public rewardNFT;

constructor(address _nft) {
    owner = msg.sender;
    rewardNFT = IERC721(_nft);
}

// After reveal ends
function distributeNFT() external {
    require(block.timestamp >= revealEnd, "Reveal not ended");
    require(winner != address(0), "No winner yet");
    rewardNFT.safeMint(winner);
}

Part 7: Encrypted Events on Sapphire (Advanced)

event EncryptedBid(address indexed bidder, bytes32 encryptedData);

bytes memory ciphertext = Sapphire.encrypt(abi.encodePacked(bidValue, salt));
emit EncryptedBid(msg.sender, ciphertext);

Only the bidder can decrypt the event off-chain
Useful for building off-chain bid monitoring tools without revealing bids publicly

Part 8: Frontend Integration (React + ethers.js)

Generate bid commitment in React form
Call submitBid(commitment) on click
Reveal after auction ends
Optional: use encrypted events to show notifications without revealing bid amounts

const bid = createCommitment(inputValue);
await auctionContract.submitBid(bid.commitment);

Add a timer for bidding and reveal periods
Use ethers.js and MetaMask for transactions

Part 9: Hardhat Testing

const { expect } = require("chai");

describe("SealedAuction", function () {
  it("accepts bids and picks winner correctly", async function () {
    const [a, b] = await ethers.getSigners();
    const Auction = await ethers.getContractFactory("SealedAuction");
    const auction = await Auction.deploy(60, 120);

    const bidA = ethers.utils.id("1001salt");
    const bidB = ethers.utils.id("2002salt2");

    await auction.submitBid(bidA);
    await auction.submitBid(bidB);

    await network.provider.send("evm_increaseTime", [70]);

    await auction.reveal(1001, ethers.utils.formatBytes32String("salt"));
    await auction.reveal(2002, ethers.utils.formatBytes32String("salt2"));

    expect(await auction.winner()).to.equal(b.address);
    expect(await auction.finalPrice()).to.equal(2002);
  });
});

Part 10: Deploying to Sapphire Testnet

npx hardhat run scripts/deploy.js --network sapphire_testnet

Deploy script:

async function main() {
  const Auction = await ethers.getContractFactory("SealedAuction");
  const auction = await Auction.deploy(300, 300);
  await auction.deployed();
  console.log("Auction deployed at", auction.address);
}
main();

Part 11: Next-Level Ideas you could implement

Build a full frontend auction dApp
Integrate off-chain listeners for encrypted events
Add ZK proofs for bid fairness without revealing bids
Support multi-item auctions or batch NFT rewards

You now have a fully functional, privacy-preserving NFT auction on Oasis Sapphire. Bids are private, events can be private, and the winner is verifiable. Perfect for real-world confidential DeFi and NFT applications!

Building a Privacy-Preserving AI Oracle on Oasis Sapphire

rayQu — Fri, 13 Mar 2026 08:41:00 +0000

Recently, I built a cross-chain confidential Trust Score Oracle using Sapphire ParaTime, Oasis Privacy Layer, and ROFL on the Oasis Network. That project focused on computing a reputation score across multiple blockchains while keeping the scoring logic private.

In this tutorial, we’ll explore a different but related use case: building a privacy-preserving AI inference oracle.

Instead of calculating a trust score from on-chain activity, we will:

run an AI model privately
process sensitive user data
return verifiable results on-chain

This pattern is extremely useful for applications like:

private credit scoring
confidential trading signals
healthcare ML analytics
AI-powered DeFi risk models

Why Privacy Matters for AI on Blockchain

Most blockchains are fully transparent. Every transaction and input is publicly visible.

That creates a major problem for AI applications.

Example: a credit scoring system.

Inputs might include:

income
transaction history
loan repayment data
identity attributes

None of this can safely be published on a public blockchain.

This is where the confidential compute model of Oasis Network becomes powerful.

It allows smart contracts to execute encrypted computations inside secure enclaves.

Oasis Network Architecture

The Oasis architecture separates consensus from computation, which allows specialized runtimes for different workloads.

+------------------------------------------------+
|                 Applications                   |
+------------------------------------------------+
|                ParaTime Layer                  |
|------------------------------------------------|
|  Sapphire (Confidential EVM)                   |
|  Emerald (EVM Compatible)                      |
|  Custom Runtimes                               |
+------------------------------------------------+
|              Consensus Layer                   |
|           Proof-of-Stake Validators            |
+------------------------------------------------+

In this tutorial we use Sapphire ParaTime, which provides:

EVM compatibility
encrypted state
confidential smart contracts

What We Will Build

We will build a Confidential AI Oracle.

                 Confidential AI Oracle System

       +-------------------+
       |   User Wallet     |
       | (encrypted data)  |
       +---------+---------+
                 |
                 v
        +---------------------+
        | Sapphire Smart      |
        | Contract            |
        | (confidential EVM)  |
        +---------+-----------+
                  |
                  v
        +---------------------+
        | ROFL Oracle Worker  |
        |---------------------|
        | Secure Enclave      |
        | AI Model Inference  |
        +---------+-----------+
                  |
                  v
        +---------------------+
        | Signed Result       |
        | returned on-chain   |
        +---------------------+

The system will:

Receive encrypted user data
Run an AI model inside a secure environment
Produce a prediction
Store only the result on-chain

High-Level Architecture

User Wallet
     |
     v
Encrypted Data
     |
     v
Sapphire Smart Contract
     |
     v
ROFL Worker
     |
     v
AI Model Inference
     |
     v
Signed Result
     |
     v
Smart Contract Storage

Real Use Case: Private Credit Scoring

Imagine a DeFi lending protocol.

It wants to compute a credit score before issuing a loan.

But the borrower’s financial data must remain private.

Traditional blockchain flow:

User -> Smart Contract -> Public Data

Everyone can see the input.

With confidential computation:

User Data (encrypted)
        |
        v
Confidential Runtime
        |
        v
AI Model
        |
        v
Credit Score Result

Only the result is visible.

Project Repository Structure

oasis-private-ai-oracle/

contracts/
  CreditOracle.sol

oracle/
  worker.py
  model.py
  enclave_runner.py

scripts/
  deploy.js

frontend/
  submit-data.ts

README.md

Smart Contract (Sapphire)

Example confidential oracle contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

contract CreditOracle {

    address public oracle;

    struct ScoreRecord {
        uint256 score;
        uint256 timestamp;
    }

    mapping(address => ScoreRecord) public scores;

    event ScoreUpdated(address indexed user, uint256 score);

    constructor(address _oracle) {
        oracle = _oracle;
    }

    function submitScore(
        address user,
        uint256 score,
        bytes calldata signature
    ) external {

        require(verify(user, score, signature), "invalid signature");

        scores[user] = ScoreRecord({
            score: score,
            timestamp: block.timestamp
        });

        emit ScoreUpdated(user, score);
    }

    function verify(
        address user,
        uint256 score,
        bytes memory signature
    ) internal view returns (bool) {

        bytes32 message = keccak256(
            abi.encodePacked(user, score)
        );

        bytes32 ethSigned = keccak256(
            abi.encodePacked(
                "\x19Ethereum Signed Message:\n32",
                message
            )
        );

        (bytes32 r, bytes32 s, uint8 v) = splitSignature(signature);

        address recovered = ecrecover(ethSigned, v, r, s);

        return recovered == oracle;
    }

    function splitSignature(bytes memory sig)
        internal
        pure
        returns (bytes32 r, bytes32 s, uint8 v)
    {
        require(sig.length == 65, "invalid signature length");

        assembly {
            r := mload(add(sig, 32))
            s := mload(add(sig, 64))
            v := byte(0, mload(add(sig, 96)))
        }
    }

}

The contract:

verifies oracle signatures
prevents tampering
stores final scores
event logging
timestamped scores
full signature verification

Oracle Worker

The oracle runs the AI model and signs the result.

Example Python worker:

from web3 import Web3
import json
from model import predict_score
from eth_account import Account

RPC_URL = "https://sapphire.oasis.io"
PRIVATE_KEY = "YOUR_ORACLE_PRIVATE_KEY"

contract_address = "DEPLOYED_CONTRACT_ADDRESS"
contract_abi = json.load(open("CreditOracleABI.json"))

w3 = Web3(Web3.HTTPProvider(RPC_URL))

account = Account.from_key(PRIVATE_KEY)

contract = w3.eth.contract(
    address=contract_address,
    abi=contract_abi
)

def run_oracle(user_address, user_data):

    score = predict_score(user_data)

    message = Web3.solidity_keccak(
        ["address","uint256"],
        [user_address, score]
    )

    signed = account.sign_message(
        Web3.eth.account._hash_message(message)
    )

    tx = contract.functions.submitScore(
        user_address,
        score,
        signed.signature
    ).build_transaction({
        "from": account.address,
        "nonce": w3.eth.get_transaction_count(account.address)
    })

    signed_tx = w3.eth.account.sign_transaction(tx, PRIVATE_KEY)

    tx_hash = w3.eth.send_raw_transaction(signed_tx.rawTransaction)

    return tx_hash.hex()

In a real deployment this worker would run inside:

a secure enclave
confidential compute environment

It:

computes the AI score
signs it
sends a transaction on-chain

Example AI Model

A simplified scoring function:

import numpy as np

def normalize(value, max_value):
    return min(value / max_value, 1)

def predict_score(data):

    income = normalize(data["income"], 100000)
    debt = normalize(data["debt"], 50000)
    history = normalize(data["history"], 10)

    score = (
        income * 0.5
        - debt * 0.3
        + history * 0.2
    )

    score = max(score, 0)

    return int(score * 100)

It does some real feature normalization and gives realistic scoring output

In production you could replace this with:

XGBoost
LightGBM
neural networks

Deployment

Install development tools

npm install -g hardhat

Configure Sapphire network

networks: {
  sapphire: {
    url: "https://sapphire.oasis.io",
    chainId: 23294
  }
}

Deploy contract

npx hardhat run scripts/deploy.js --network sapphire

End-to-End Flow

User submits encrypted data
        |
        v
Oracle decrypts inside secure compute
        |
        v
AI model runs prediction
        |
        v
Oracle signs result
        |
        v
Smart contract stores score

Why This Architecture Is Powerful

Without privacy infrastructure, AI + blockchain rarely works because:

training data is private
models are proprietary
inputs contain sensitive information

Using confidential runtimes on Oasis Network enables a new class of applications:

private DeFi analytics
confidential AI marketplaces
encrypted healthcare ML
secure financial scoring

Possible next additions

Possible extensions to this project:

add zero-knowledge proofs for inference
build a data marketplace
enable federated learning
create private trading signals

Conclusion

The combination of blockchain verification and confidential computation unlocks entirely new types of applications.

With runtimes like Sapphire ParaTime on the Oasis Network, developers can build systems where:

data remains private
computation is verifiable
results are trustless

This opens the door to privacy-first AI in Web3.

Building a Cross-Chain Confidential "Trust Score Oracle" with Oasis Sapphire + OPL + ROFL

rayQu — Sun, 22 Feb 2026 08:15:46 +0000

This tutorial shows how to add privacy + verifiable off-chain compute to any EVM dApp by combining:

Sapphire: Oasis’ confidential EVM (encrypted calldata + confidential contract state).
OPL (Oasis Privacy Layer): message bridge pattern to “bolt privacy onto” existing EVM apps by offloading sensitive logic to Sapphire.
ROFL (Runtime Off-Chain Logic): a TEE-managed app runtime (containers or single binaries) with secrets stored via built-in KMS and on-chain management through Sapphire.

Real use case

You run a lending/access-control dApp on a Home chain (Ethereum/L2). You want a wallet "Trust Score" derived from sensitive signals:

private allowlists (KYC provider, internal risk flags),
off-chain identity reputation (GitHub activity, paid subscription, enterprise customer),
model inference results (fraud classifier).

You don’t want to leak:

raw signals,
model features,
user identity mappings,
or scoring logic.

Design goal:
Home chain contract gets a public, verifiable decision (e.g., score bucket/allow/deny/rate tier) while sensitive scoring happens privately and verifiably.

Architecture

High-level diagram

What each piece does:

Home chain contract: minimal "public" state, accepts final decision and enforces it.
Sapphire contract (the enclave): holds private state (scores, salts, user-to-signal mappings), verifies authorized sources, emits public commitments only.
ROFL app: runs your scoring code in a TEE; keeps API keys/model weights/feature rules in ROFL secrets; posts updates on-chain.

ROFL apps are explicitly designed to run in TEEs and be managed via Sapphire, with built-in secrets support.

Repo blueprint

Monorepo layout:

oasis-trustscore-oracle/
  README.md
  .env.example

  contracts/
    hardhat.config.ts
    package.json
    contracts/
      HomeHost.sol
      SapphireEnclave.sol
    scripts/
      deploy-home.ts
      deploy-sapphire.ts
      link-endpoints.ts
    tasks/
      send-opl-message.ts

  rofl/
    compose.yaml
    rofl.yaml
    app/
      Dockerfile
      requirements.txt
      main.py
      scorer.py
      signals.py

  diagrams/
    architecture.mmd
    sequence.mmd

Networks & prerequisites

Sapphire Testnet settings (for dev)

From Oasis docs, Sapphire Testnet:

RPC: https://testnet.sapphire.oasis.io
Chain ID (decimal): 23295
WSS: wss://testnet.sapphire.oasis.io/ws

You’ll also want the Sapphire wrapper for encrypted transactions (TS wrapper / ethers v6 wrapper).

ROFL prerequisites

ROFL quickstart expects:

a containerized app (OCI image),
Oasis CLI (latest),
testnet tokens from the faucet

Step 1 - Smart contracts: Home chain + Sapphire enclave

1A) SapphireEnclave.sol (runs confidentially)

This contract runs on Sapphire and receives cross-chain requests via OPL. It:

stores scores privately,
accepts updates from ROFL,
sends a public decision back to Home chain.

Minimal skeleton based on the official OPL SDK pattern (Enclave + endpoints)

// contracts/contracts/SapphireEnclave.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {Enclave, Result, autoswitch} from "@oasisprotocol/sapphire-contracts/contracts/OPL.sol";

contract SapphireEnclave is Enclave {
    // Private by design on Sapphire: state + calldata are confidential.
    mapping(address => uint256) private score; // example: 0..100

    // Optional: authorize a ROFL app address (or a set of them).
    address public roflUpdater;

    constructor(address homeContract, string memory homeChain)
        Enclave(homeContract, autoswitch(homeChain))
    {
        registerEndpoint("requestScore", onRequestScore);
    }

    function setRoflUpdater(address _rofl) external {
        // replace with proper access control for real deployments
        roflUpdater = _rofl;
    }

    // ROFL posts score updates (confidential write).
    function updateScore(address user, uint256 newScore) external returns (bool) {
        require(msg.sender == roflUpdater, "not authorized");
        score[user] = newScore;
        return true;
    }

    // OPL endpoint: called when Home chain requests a score decision.
    function onRequestScore(bytes calldata args) internal returns (Result) {
        address user = abi.decode(args, (address));

        uint256 s = score[user];

        // Only return a coarse bucket publicly (avoid leaking exact score).
        uint8 bucket =
            s >= 80 ? 3 :
            s >= 50 ? 2 :
            s >= 20 ? 1 : 0;

        // Send decision back to Home chain (publicly observable).
        postMessage("scoreDecision", abi.encode(user, bucket));
        return Result.Success;
    }
}

Why this works:

Sapphire is an EVM ParaTime built for confidential computation.
OPL uses message bridges so your Home chain can trigger private computation on Sapphire.

1B) HomeHost.sol (your existing dApp stays here)
Based on official OPL Host pattern.

// contracts/contracts/HomeHost.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {Host, Result} from "@oasisprotocol/sapphire-contracts/contracts/OPL.sol";

contract HomeHost is Host {
    mapping(address => uint8) public lastBucket;

    constructor(address sapphireContract) Host(sapphireContract) {
        registerEndpoint("scoreDecision", onScoreDecision);
    }

    // User or app requests a score check.
    function requestScore(address user) external payable {
        postMessage("requestScore", abi.encode(user));
    }

    // Called by OPL bridge after Sapphire computed the decision.
    function onScoreDecision(bytes calldata args) internal returns (Result) {
        (address user, uint8 bucket) = abi.decode(args, (address, uint8));
        lastBucket[user] = bucket;
        return Result.Success;
    }

    function canBorrow(address user) external view returns (bool) {
        return lastBucket[user] >= 2;
    }
}

Step 2 - Hardhat setup (with Sapphire encryption)

Install the OPL/Sapphire contracts library and Sapphire tooling:

OPL SDK lives in @oasisprotocol/sapphire-contracts.
Sapphire wrapper guidance (TypeScript wrapper / ethers wrapper).

Your hardhat.config.ts should include:

Home chain network (your choice),
Sapphire testnet using the official RPC and chain id

Example network params:

// contracts/hardhat.config.ts (snippet)
networks: {
  sapphire_testnet: {
    url: "https://testnet.sapphire.oasis.io",
    chainId: 23295,
    accounts: [process.env.PRIVATE_KEY!],
  },
  // home: { ... } // e.g. sepolia/arbitrum etc.
}

Step 3 - Link OPL endpoints (the "wiring")

OPL requires that each side knows the other side and which endpoints exist (1–1 paired contracts).

In your scripts:

deploy SapphireEnclave on Sapphire
deploy HomeHost on Home chain
set each other’s address + register endpoints appropriately

(Exactly how you do step (3) depends on your preferred OPL bridge route; the docs list multiple integration methods, including OPL SDK wrapper around Celer IM.)

Step 4 - ROFL app: compute score inside a TEE and push to Sapphire

ROFL gives you:

TEE execution (SGX/TDX)
app lifecycle managed via Oasis
built-in secrets stored on-chain and injected securely
ability to sign and submit special transactions back to Sapphire

ROFL gives you:

TEE execution (SGX/TDX)
app lifecycle managed via Oasis
built-in secrets stored on-chain and injected securely
ability to sign and submit special transactions back to Sapphire

4A) ROFL app code (Python example)
rofl/app/main.py:

loads secrets (API keys)
fetches signals
runs scoring
calls updateScore(user, score) on Sapphire

# rofl/app/main.py
import os
import time
from web3 import Web3

SAPPHIRE_RPC = os.environ["SAPPHIRE_RPC"]
ENCLAVE_ADDR = Web3.to_checksum_address(os.environ["ENCLAVE_ADDR"])
ROFL_SIGNER_KEY = os.environ["ROFL_SIGNER_KEY"]  # stored as ROFL secret

ABI = [...]  # contract ABI for updateScore

w3 = Web3(Web3.HTTPProvider(SAPPHIRE_RPC))
acct = w3.eth.account.from_key(ROFL_SIGNER_KEY)
enclave = w3.eth.contract(address=ENCLAVE_ADDR, abi=ABI)

def compute_score(user: str) -> int:
    # pull private signals using secrets (tokens), then score
    # keep it deterministic if you want auditability
    return 82

def submit_score(user: str, s: int):
    tx = enclave.functions.updateScore(Web3.to_checksum_address(user), s).build_transaction({
        "from": acct.address,
        "nonce": w3.eth.get_transaction_count(acct.address),
        "gas": 500_000,
    })
    signed = acct.sign_transaction(tx)
    return w3.eth.send_raw_transaction(signed.rawTransaction)

def main():
    users = os.environ["USERS"].split(",")
    while True:
        for u in users:
            s = compute_score(u)
            txh = submit_score(u, s)
            print("updated", u, s, txh.hex())
        time.sleep(60)

if __name__ == "__main__":
    main()

4B) Containerize + ROFLize

ROFL quickstart is literally the flow:

oasis rofl init
oasis rofl create --network testnet
oasis rofl build
oasis rofl secret set ...
oasis rofl update
oasis rofl deploy

Example secrets:

# inside rofl/
echo -n "0xYOUR_SIGNER_KEY" | oasis rofl secret set ROFL_SIGNER_KEY -
echo -n "https://testnet.sapphire.oasis.io" | oasis rofl secret set SAPPHIRE_RPC -
echo -n "0xYourEnclaveAddress" | oasis rofl secret set ENCLAVE_ADDR -

ROFL secrets are explicitly supported and meant for sensitive env vars like API keys.

Sequence diagram (end-to-end)

This is the core pattern: public app stays on its chain, sensitive logic runs confidentially, and you only export a minimal decision.

Threat model notes

Don’t export raw scores: export buckets, booleans, or commitments.
Secrets: keep API keys/model access tokens in ROFL secrets (not in Docker image).
RPC trust: Oasis docs explicitly warn RPC endpoints are a trust point (rate limits, censorship, MITM); run your own if your security bar is high.
Testnet disclaimer: Sapphire testnet confidentiality is not guaranteed and state may be wiped; treat it as public.

Sources

Building a Confidential Web3 Application with Oasis

rayQu — Thu, 19 Feb 2026 09:17:40 +0000

The Problem

Web3 applications increasingly need reputation, risk scoring, and trust signals.

However, current solutions have a major issue:

• Reputation systems expose user data publicly
• Credit/risk models require sending sensitive data to centralized servers
• Wallet analytics often reveal full transaction history
• AI scoring pipelines break user privacy

This creates a trade-off between useful intelligence and data confidentiality.

The goal of this project was to remove that trade-off.

PrivateAI Oracle

A privacy-preserving trust scoring system that:

Collects wallet or activity signals
Runs an AI-based trust evaluation off-chain
Produces a verifiable score
Stores proof/commitment on Oasis confidential smart contracts

The system allows applications to query a user's trust score without revealing the underlying private data used to compute it.

Why Oasis Network

This architecture relies on Oasis confidential computing features.

Using Sapphire (confidential EVM runtime):

Sensitive inputs remain encrypted
Smart contract state is confidential when required
Only final outputs are selectively revealed

This makes Oasis ideal for AI + blockchain workflows involving private datasets.

Traditional public chains would expose:

model inputs
intermediate scoring logic
sensitive user metadata

Oasis prevents this.

Architecture

The system consists of three main components:

Data Collection Layer

Collects public or permissioned signals such as:

wallet activity patterns
GitHub contribution signals
behavioral indicators

Only necessary features are extracted.

Off-Chain AI Inference Engine

A machine learning model computes:

a normalized trust score
optional confidence level

The raw feature data never needs to be publicly stored on-chain.

Oasis Confidential Smart Contract

The contract:

receives a signed result
records a commitment hash
allows verification of authenticity
exposes only the final trust score

This preserves verifiability while protecting user privacy.

What This Enables

PrivateAI Oracle can be used for:

DeFi borrower trust scoring without exposing full history
DAO contributor reputation without revealing private activity
sybil-resistant onboarding systems
Privacy-preserving AI reputation layers
Secure Web3 identity primitives

Technical Takeaways

During development, several important lessons emerged:

Confidential smart contracts change how data pipelines must be designed
AI outputs should be treated as attestations, not raw datasets
Privacy must be built into architecture, not added later
Hybrid off-chain compute + on-chain proof is extremely powerful

Results

The final prototype demonstrates:

End-to-end confidential trust scoring
AI inference integrated with Oasis smart contracts
Selective transparency (score visible, data hidden)
Practical architecture for privacy-preserving Web3 intelligence

Future Implementations that could help

Zero-knowledge proof integration for stronger verification
Multi-model scoring pipelines
public demo UI
Integration with lending or DAO onboarding flows

Web3 does not just need decentralization.

It needs private, verifiable intelligence.

PrivateAI Oracle explores how Oasis confidential computing can enable exactly that.