Forem: rayQu

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.

Oasis & TEE Vulnerabilities and Why Oasis Survived the Storm

rayQu — Sun, 21 Dec 2025 17:19:22 +0000

Trusted Execution Environments (TEEs) like Intel SGX and AMD SEV‑SNP recently hit the news with two nasty physical attacks: Battering RAM & Wiretap. These attacks target memory encryption and can expose attestation keys.

But here’s the kicker: Oasis wasn’t affected. Let’s break it down:

What went down with TEEs

The attacks:

Extract keys directly from memory using physical access.
Break the confidentiality guarantees of SGX v2 / SEV‑SNP.
Affected projects had to patch immediately.

examples: Phala, Secret Network, Crust, IntegriTEE.

Why Oasis stayed safe

Oasis isn’t just “TEE inside blockchain”. it’s layered security:

Runs critical components (key manager, Sapphire/Cipher runtimes) on older SGX v1, not affected by these attacks.
Core system doesn’t rely on enclave secrecy for correctness or funds safety.
Even if a TEE key were compromised, ephemeral keys & rotation reduce risk drastically.

Defense‑in‑Depth

Oasis uses multiple layers to protect users:

On‑chain governance & staked validators
Ephemeral key rotation & policy blacklists
Enclave isolation for sensitive components

Even if a hardware TEE is compromised, consensus, funds, and historical messages stay safe.

Dev Takeaways

TEEs are powerful but not infallible.
Layered security > single-point trust.
Design protocols assuming hardware can fail.

Oasis shows a blueprint for confidential computing done right in Web3.

Verifiable Compute for Onchain Prop Trading: Carrot Meets Oasis ROFL

rayQu — Sun, 21 Dec 2025 17:01:24 +0000

As decentralized finance continues to mature, one of the persistent challenges has been reducing reliance on centralized or opaque computation, particularly in performance-sensitive applications like proprietary trading. The Oasis Protocol ecosystem has published a detailed update on how Carrotfunding.io plans to tackle this by integrating ROFL (Runtime Offchain Logic Framework) to bring cryptographically verifiable compute into its trading stack.

Trusted Compute in DeFi

Prop trading, where skilled traders deploy capital under performance constraints, has traditionally relied on centralized engines for order execution, risk evaluation, and performance assessment. Even when using decentralized vaults and execution rails, a core piece of this puzzle often remains a black-box server environment (for example, AWS) that users must implicitly trust.

This trust assumption limits the ability to provide fully transparent and provable financial services. In a space where trustlessness and verifiability are fundamental value propositions, bridging this gap is crucial.

Carrot’s Approach with Verifiable Compute

Carrotfunding is introducing a verification layer using ROFL. This framework leverages trusted execution environments to independently verify compute results generated by the existing trading infrastructure. In practical terms, this means:

A ROFL instance runs in parallel with the AWS-based engine.
Every compute operation, whether order placement logic, trader evaluation metrics, or payout calculations, is independently verified by ROFL.
Cryptographic proofs of these compute results are made available onchain.
This approach preserves performance and compatibility with existing systems while adding an orthogonal layer of verified trust.

Benefits for Traders and Capital Providers

Traders benefit from verifiable evaluation logic. Instead of taking the platform’s word on performance metrics or evaluation criteria, they can independently confirm that the rules were applied fairly and consistently.
Investors and capital allocators gain confidence that the pool’s rules for risk, capital deployment, and reward distribution are enforced without manipulation or manual interference.
This model strengthens the credibility of onchain prop trading and opens the door for similar applications across DeFi where proving computational integrity is essential.

The Road Ahead

Currently, ROFL runs alongside existing compute infrastructure. Over time, Carrot aims to migrate toward a fully ROFL-centric compute model. This reflects a broader trend in Web3: combining the efficiency of offchain computation with the trust guarantees of onchain verification.

For developers and teams exploring verifiable compute patterns in financial, AI, or agentic applications, this integration between Carrot and Oasis ROFL provides a practical reference model. Full thread on oasis' blog, here!

Oasis launches a strategic investment arm and backs SemiLiquid to build confidential RWA credit infrastructure

rayQu — Tue, 16 Dec 2025 07:49:07 +0000

Oasis Protocol recently announced the launch of a strategic investment arm, marking a shift from pure ecosystem grants to longer-term capital deployment and hands-on technical collaboration.

The first investment from this new arm is SemiLiquid, a project building custody-native credit infrastructure for tokenized real-world assets.

From a developer and infrastructure perspective, this is an interesting signal about where Oasis is positioning itself.

What SemiLiquid is building

SemiLiquid focuses on enabling credit against tokenized assets without requiring those assets to leave institutional custody.

In practice, this means
• Assets remain with a qualified custodian
• Credit eligibility and collateral constraints are verified on-chain
• Sensitive financial data is never publicly exposed

This addresses a major blocker for institutional DeFi adoption: privacy and compliance around balance sheets, collateral composition, and counterparty exposure.

Why Oasis is involved

SemiLiquid is built on Oasis’s confidential compute stack, including Sapphire and Oasis’s runtime confidentiality guarantees.

The key technical components include
• Confidential smart contracts executed in trusted execution environments
• On-chain verification with private state
• Liquefaction primitives that allow off-chain or private data to influence on-chain logic without disclosure

For developers, this shows a concrete production use case where confidential EVM execution is not just a theoretical privacy feature, but a requirement for regulated financial workflows.

Pilot results and real usage

According to Oasis, SemiLiquid has already completed pilot workflows with institutional partners such as Franklin Templeton and Zodia Custody.

These pilots included
• Collateral locking
• Credit issuance
• Automated repayment logic
• Privacy-preserving verification

All executed on Oasis infrastructure.

This is notable because many RWA projects stall at the proof-of-concept stage, while this one appears to be testing full lifecycle flows.

Why this matters for builders

If you are building in DeFi, RWAs, or compliance-aware systems, this announcement highlights a few trends
• Confidential execution is becoming infrastructure, not a niche feature
• Institutions require verifiable logic without public state exposure
• Blockchain investment arms are starting to fund infrastructure layers, not just applications

Oasis moving from grants to strategic investments suggests a focus on fewer but more deeply integrated projects that push the limits of what on-chain systems can safely handle.

Full thread can be found in this link!

ERC 8004 and Trustless AI Agents

rayQu — Fri, 28 Nov 2025 08:56:02 +0000

What ERC 8004 Tries To Solve

AI agents need a way to identify themselves, prove what they did, and accumulate reputational history across different environments.
Today this is fragmented. Each API or platform uses its own identity model, its own reputation rules, and its own trust signals.
ERC 8004 proposes a shared framework so that autonomous agents can reliably interact across chains and systems.

Identity Registry

The standard introduces a common identity layer where each agent is represented as a token.
The token points to a JSON document called an agent card.
The card contains information such as capabilities, metadata, links to external profiles, and service endpoints.
This allows clients and other agents to discover what an agent can do without depending on centralized API registries.

Validation Registry

Agents produce outputs that sometimes must be verified.
ERC 8004 defines a mechanism for validators to respond to requests, return results, and attach supporting information such as proof files or reexecution traces.
This is important for tasks where correctness matters, including code generation, data transformation, or fact-based responses.

Reputation Registry

Trust grows when feedback is consistent across platforms.
The reputation layer lets users or clients leave structured feedback that agents can carry with them.
Feedback can include scores, tags, and optional file references.
The goal is to create a portable reputation footprint instead of siloed rating systems.

Trustless Agents

When identity, validation, and reputation are standardized, an agent can operate without relying on a single platform.
The agent becomes portable.
The client does not need to trust the hosting company but only the chain-level registries.
This creates a foundation for agent markets, agent-to-agent commerce, and autonomous services.

Why This Matters

Developers gain an open and verifiable way to expose AI services.
Users get transparent trust signals.
Platforms can interoperate instead of locking agents inside proprietary ecosystems.
This moves AI services toward the same open model that helped the web grow.

Real Use Cases

Running autonomous assistants that perform API calls with verifiable logs
Building agent marketplaces where discovery and scoring work across vendors
Creating validator networks for correctness checking
Composing multiple agents into pipelines without hidden trust assumptions

How To Start

Build an agent card describing capabilities and metadata
Register it through an identity registry implementation
Use the validation and reputation registries to attach proof and feedback data
Publish your agent so other clients or agents can discover and interact with it

ERC 8004 is still young but it has practical design goals.
It aims for interoperability, transparency, and portable trust.
As the agent ecosystem grows, shared standards like this will become essential infrastructure. Full article can be accessed through this link.