Forem: rayQu

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.

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!