Forem: rayQu

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.

Confidential Smart Contracts with Oasis Sapphire

rayQu — Mon, 16 Feb 2026 08:01:37 +0000

Many Web3 apps still face the same structural problem. Public blockchains are transparent by default, which is great for verification but terrible for anything that requires secrecy, protected data, or private logic. Auctions leak bids, games leak strategy, AI agents leak prompts, and business workflows leak sensitive inputs.

Oasis Network addresses this by adding a confidential execution layer to the familiar EVM model.

What Oasis does differently

Oasis separates consensus from execution and allows specialized runtimes called ParaTimes. One of these runtimes, Sapphire, is a confidential EVM designed for privacy preserving smart contracts.

Developers still write Solidity. They still use Hardhat **or **Foundry. Deployment feels like any other EVM chain.

The key difference is that contract state, calldata, and execution are encrypted and processed inside trusted execution environments. Validators cannot read plaintext inputs or storage.

This turns privacy from an application level workaround into a native runtime feature.

Why this matters in practice

Confidential execution unlocks use cases that are fragile or impossible on fully public chains:

Sealed bid auctions where bids stay hidden until reveal
Onchain games with hidden state
Private DAO voting with verifiable results
AI agents whose strategies and prompts must remain secret
Enterprise workflows that need verifiable execution without exposing documents

Instead of trying to hide data offchain and only posting final results, the sensitive logic itself can run onchain while remaining confidential.

Dev experience

One of the strongest points is that Sapphire does not require learning a new programming language or cryptographic framework.

A normal Solidity contract like a counter or registry becomes confidential automatically when deployed to Sapphire. Private variables are not just compiler hints. Storage and transaction inputs are encrypted at runtime.

A typical workflow looks like:

Configure Sapphire RPC in MetaMask
Fund wallet via the testnet faucet
Create a standard Hardhat project
Install the Sapphire helper plugin
Deploy Solidity contracts normally

From there, transaction calldata is encrypted locally and only decrypted inside the runtime.

Positioning in the ecosystem

Oasis works well as a confidential coprocessor rather than a replacement chain.

Public settlement, liquidity, and composability can remain on Ethereum or L2s. Sensitive computation, private registries, hidden metadata, or sealed commitments can run on Sapphire. Results can then be bridged or proven back to public chains.

This hybrid model lets builders keep transparency where they want it and add privacy where they need it.

Current direction

The Oasis ecosystem is increasingly focused on privacy for AI, data marketplaces, and confidential DeFi. Sapphire is already live and usable today, which makes it one of the few production confidential EVM environments rather than a research concept.

For developers who already know Solidity, the barrier to testing confidential smart contracts is extremely low.

Curious to hear from builders here. have you actually ran into situations where onchain transparency broke your design? And what would you build first if private execution was available by default?

Attestation Is Not Enough: Why TEEs Need On-Chain Trust

rayQu — Sun, 18 Jan 2026 12:07:45 +0000

Trusted Execution Environments (TEEs) are getting a lot of hype in Web3, and for good reason. They enable confidential smart contracts, private off-chain agents, and a new class of trust-minimized applications. But as Oasis Network’s recent blog explains, remote attestation alone doesn’t give you real trust.

What Remote Attestation Actually Proves

Remote attestation gives you a signed quote from hardware that:

A specific binary ran
On specific hardware
At a specific point in time

Sounds solid … until you realize it only proves a snapshot. It doesn’t tell you anything about:

Whether the quote is fresh
Whether the enclave used the latest state
Who is actually running it
Whether the code you audited is the exact code that was deployed

And that’s why raw attestations on their own become verification theater, offloading complex crypto-hardware responsibilities onto users who aren’t security researchers.

The Critical Gaps

Even a "valid" attestation doesn’t automatically guarantee:

Freshness & Liveness - A stale but valid attestation can be reused
State Continuity & Anti-Rollback - Old state can be replayed
Operator Accountability - Attestations don’t tell you who controls the enclave
TCB Governance - Hardware vendors define threat models; users might demand stricter policies
Code Provenance - You still need reproducible builds and verifiable binaries

Simply put: attestation ≠ trust if you leave these holes unaddressed.

Turning TEEs into Trust Systems

So how do you fix this?

Instead of expecting every user to parse raw hardware quotes, Oasis proposes treating consensus as the verifier. A fault-tolerant network of stake-bearing validators:

Collects attestations + verification evidence
Verifies TCB, freshness, policies, upgrade history
Agrees on validity via BFT consensus
Publishes a simple on-chain verification state

Now users don’t need to parse multi-kilobyte attestation blobs or know Intel/AMD internals, they simply verify a consensus signed proof.

Why This Matters??

This architecture transforms TEEs from:

🔹 isolated hardware boxes

into

🔹 integrated, verifiable components

within a larger trust system

full thread can be read through Oasis official blog, here!

Oasis in 2025: A Shift Toward Verifiable Off-Chain Compute

rayQu — Tue, 13 Jan 2026 10:36:30 +0000

2025 didn’t bring a single “killer app” moment for crypto, but it did bring something more important: infrastructure getting real.

One of the most underappreciated shifts this year was how Oasis positioned itself as a practical bridge between on-chain systems and real-world compute.

This post is a short recap of why Oasis mattered in 2025, especially for devs building beyond toy smart contracts.

The Problem We Finally Stopped Ignoring

Smart contracts are:

Transparent
Deterministic
Verifiable

But also:

Slow
Expensive
Terrible at handling private data or complex logic

Most serious protocols already rely on off-chain systems (AWS, GCP, custom infra), but those systems are:

Opaque
Centralized
Impossible to verify on-chain

2025 was the year projects stopped pretending this tradeoff didn’t exist.

Oasis’ Core Bet: Trusted Execution Environments (TEEs)

Oasis doubled down on TEE-based compute, enabling:

Off-chain execution
With hardware-level confidentiality
And cryptographic attestations
Verifiable by on-chain logic

This isn’t theoretical privacy, it’s auditable execution.

You don’t “trust the operator”.
You verify what code ran, where it ran, and what it produced.

ROFL: A Decentralized TEE Cloud (Not Just a Whitepaper)

ROFL (Runtime Off-chain Logic Framework) became one of the most important and misunderstood pieces of Oasis' stack.

What it actually enables:

Deterministic off-chain execution
Across a decentralized set of TEE nodes
With outputs posted on-chain
And reproducible verification guarantees

In practice, this means you can:

Run risk engines
Pricing models
ML inference
Fraud detection
Private analytics

…without exposing data or logic, and without blindly trusting AWS.

Why Real Projects Started Paying Attention

The big signal in 2025 wasn’t marketing, it was adoption by protocols with real risk.

Using Oasis + ROFL allowed teams to:

Keep existing infra
Add verifiability instead of rewriting everything
Gradually decentralize trust, not functionality

This hybrid model (centralized performance + decentralized verification) is likely how most production crypto systems will evolve.

What This Means for Devs

If you’re building in 2026+, Oasis makes sense when you need:

Private state
Complex logic
Off-chain performance
On-chain trust guarantees

You don’t replace your backend. You prove it.

That’s the mental shift Oasis helped normalize in 2025.

Oasis didn’t try to “replace Ethereum”.
It didn’t chase memes.
It didn’t promise magic scalability.

Instead, it focused on something harder:
Making off-chain compute verifiable.

And that’s exactly the kind of boring, foundational work that ends up shaping the next wave of adoption.

Oasis for Developers: an underrated EVM for privacy-first dApps

rayQu — Sun, 11 Jan 2026 10:21:51 +0000

If you’re building in Web3 and everything starts to feel like:

MEV everywhere
Front-running by default
Sensitive logic exposed in calldata

…it might be time to look at Oasis Sapphire.

https://www.youtube.com/watch?v=LDLz06X_KNY

What Oasis actually is

Oasis is a Layer 1 with a modular architecture
Sapphire is an EVM-compatible ParaTime (smart contract runtime)
You deploy Solidity contracts almost exactly like Ethereum

What makes it different

Confidential EVM execution
Contract state, inputs, and internal logic can be encrypted
Data is only visible inside the secure runtime (TEE-backed)

This isn’t “privacy by obfuscation”. It’s enforced at execution level.

Why this matters for devs

Protect MEV strategies (arbs, liquidations, auctions)
Build sealed-bid auctions without commit–reveal hacks
Hide sensitive parameters (fees, thresholds, allowlists)
Reduce attack surface from calldata-based exploits

Dev experience

Solidity + standard tooling (Foundry, Hardhat)
Minimal changes to existing contracts
No custom rollup infra, no sequencers to manage
Deploy like an app, not like an infrastructure company

When Oasis makes sense

DeFi protocols with strategy logic
Account abstraction / paymaster logic
Games with hidden state
Governance or voting systems
Any app where “everything public” is a liability

Trade-offs (being honest)

Smaller ecosystem than Ethereum L2s
You need to design with confidentiality in mind
Not every app needs privacy, obviously.. but when you do, it’s hard to fake

If Ethereum L2s optimize for throughput, Oasis optimizes for who gets to see what. And that’s a powerful primitive most stacks still don’t have.