DEV Community: DC

Blockchain Interoperability, Decoded. And What Lies Ahead.

DC — Thu, 23 Jul 2026 10:23:00 +0000

Demystifying the intricacy of blockchain technology has been going on for decades now, and you would think we have come far enough to simplify the basic mechanics. Mostly true, but when a fundamental question like connectivity comes up, we are still trying to hone a universal hack for interoperability.

The Problem Of Chains In Silo

The blockchain space is teeming with networks, and most of them are built to be self-sufficient, deterministic, and siloed. This isolation in the distributed ledger technology is a deliberate design to insulate the networks from total damage should one of them break down.

This system assures safety, but comes with the inherent flaw of fragmentation, which hugely limits the scope of the technology. If Ethereum does not know what is going on over at Solana, it not only creates a bottleneck in data movement but also leaves liquidity stuck. The value of any asset will depreciate if it can only move inside the home chain. You need to be able to transfer your tokens across networks. Hence, we need protocol interoperability.

Moving away from monolithic to modular blockchain architecture was one of the first steps. The advent of layer-2 networks, optimistic rollups, and sidechains could only address scalability but they hardly solved the data and value transfer proposition.

The cost of communication to enable this was one of the biggest pain points of the last decade - transactional overheads in the form of gas fees piling up, sometimes making fund transfers too expensive to be viable. Many of us have experienced this firsthand.

Building Bridges For Seamless Connection

Over the years, we have seen breakthroughs in the interoperability situation- from cross-chain bridge iterations to, most recently, chain abstraction. Bridging your assets can either take the lock and mint route or the more fine-tuned atomic swap method.

Lock and mint process, or its variation of burn and mint process, works like this. Assets are locked (or burned) on the source chain, and identical value assets are created or minted on the destination chain.

In the atomic swap process, trustless cross-chain bridges, governed by smart contracts, are used.

Bridging, whether you go with a human-dependent model (multisig) or a trust-logic model (on-chain light client), has its own set of challenges. These bridges simply need to be:

trustless (existence of any external federated group of administrators could mean lost decentralization and exposure to hacking risks)
extensible (adaptability of one protocol to another network’s domain)
generalizable (capability to access and process all cross-domain datasets)

The bottom line is there is always a trade-off.

Bridges that are safe to use extract the cost of security as gas fees, and those that are cheap have high vulnerabilities leading to potential loss of your funds.

As our DeFi footprint increases, hackers exploiting bridges have been a regular risk, with several hundred million user funds falling prey (The Fragility Report, The Mass Extinction Event).

The time has come to talk about privacy now, and we will take a look at Oasis Privacy Layer (OPL) and runtime off-chain logic (ROFL).

Privacy As A Solution

The gap left by the Bridging Trilemma - safe or cheap, rarely both - is where Oasis comes into the discussion.

As a layer-1, PoS protocol with confidential computing and verifiable privacy as foundational premises, Oasis designed OPL, powered by the network's confidential EVM runtime, Sapphire, as an on-chain, plug-and-play interoperability tool.

OPL is curated to ease developer activity, enabling cross-chain communication without migration. It bridges confidentiality to dApps living entirely on other chains through message-passing bridges. The dApp's main logic stays exactly where it is, gas token and all. Only the privacy-sensitive parts of execution get routed to Sapphire.

What you get as a user out of this arrangement is confidential cross-chain transactions. No background tech distracting your experience, nor your financial privacy being accessible publicly in the name of full transparency.

Compared to Polkadot's parachains or Cosmos's IBC at the network level, or even bridge protocols such as LayerZero and Axelar, this has a distinct point of difference. While the others solve the interoperability challenge with composability and stop at data (and value) movement, Oasis asks and answers the next logical question: whether this data should be visible once it does, and adds a privacy-preserving layer as a solution.

The Off-chain Alternative

After multisig, light client, and OPL, we now have a new approach- the Trustless AWS model. It involves secure and verifiable computation while moving the heavy lifting of verification off-chain. Oasis ROFL framework is a step in this direction.

ROFL retains the black-box or secure enclave approach of OPL, using Trusted Execution Environments (TEEs) like Intel SGX or TDX. The architecture and the workflow promise optimal performance for running tamper-proof code and private, secure data processing.

Moreover, Oasis can provide Privacy-as-a-Service to other chains by aligning ROFL with OPL. This means we can enjoy confidential bridging that combines multisig-grade trust with light-client-grade security, especially with cost efficiency that zero-knowledge proofs (ZKPs) lack. As cross-chain architectures, both ZKPs and even optimistic verification models also come up short in terms of built-in privacy capabilities.

However, what sets ROFL apart from everything else that came before is that it opens a door that bridges were never designed for: confidential, cross-chain intents. This is the basis for private swaps. Here, you can specify the condition that must be met before a swap executes. With enclave-held keys and the swap order sitting in the enclave memory until the moment of execution, it is structurally resistant to manipulation or front-running of the transaction.

The Road Ahead

The thread of our discussion inevitably leads to a conundrum. As interoperability options evolve, bridges can be faster, cheaper, safer, on-chain or off-chain, and still have a ceiling to what they can achieve. A single wallet achieved through chain abstraction might be the way to go.

Consider this: a ROFL enclave holding a private key for any chain. It would mean signing a single transaction on Oasis while the matching action executes on Bitcoin or Ethereum or Solana or any protocol of your choice, without ever touching any of those networks directly. Here, you get smooth UI and UX, and the complexity is not your concern.

Does this mean we have solved interoperability? No. But we have redefined the problem we started with. Moving data and assets across chains is doable and done. Now, we examine the mechanics of moving trust itself, verifiably and cheaply, without giving up confidentiality. That's where I think the road goes next.

Sources:

Verifiable DeFi Is Catching On. Case Studies: Robin Markets, Tradable.

DC — Tue, 21 Jul 2026 09:54:51 +0000

Confidential decentralized finance (DeFi) has always been one of the best use cases for Oasis's privacy stack. The industry's first and only production-ready confidential EVM, Sapphire, was, however, only half the solution for trustless applications to ensure user data is sovereign and secured by default.

On-chain runtime can only take you so far, especially when processing huge datasets or sensitive information is concerned. Oasis has crossed that hurdle now with runtime off-chain logic ROFL in production. This framework runs off-chain compute inside a Trusted Execution Environment (TEE) before handing over the result to Sapphire for on-chain storage and finalization.

As Sapphire and ROFL enable verifiable privacy at scale, thereby counteracting the trust bottleneck, several projects have aligned themselves with Oasis to integrate this privacy layer for their products. Here, I will outline two examples that offer a glimpse into the future where confidential DeFi unfolds as verifiable private DeFi of tomorrow, uplifting user experience.

Robin Markets & verifiable yield with trustless oracle

Prediction markets are an interesting spin-off of the DeFi space, and Polymarket is undeniably one of the biggest players. Here, users can bet on real-world scenarios and outcomes, from elections to sports to just anything that involves Yes/No decisions. They can buy YES or NO tokens that are essentially tokenised positions in the market. The potentially lucrative returns attract not only crypto-native but also mainstream users, and at any given time, hundreds of millions in positions are open.

Funds locked with idle positions

The prediction market sounds fun and simple to engage with but has an inherent problem. When a user buys those YES or NO tokens, the time taken to resolve the position may range from a few hours to a few days to a few months. And until resolution, the funds are locked in the position, sitting idle, and with zero benefit to the asset owner.

Robin Markets proposes to solve this inefficient situation.

Users can trade and stake the YES or NO tokens, and earn passive income. It works like this.

Robin Markets pairs the YES and NO tokens
Then finds a YES staker and a NO staker on the same market
Next pulls the underlying USDC collateral from Polymarket
Finally routes it into viable DeFi yield strategies

With this scenario, both the YES and NO stakers stay in the market with their open positions untouched, while the collateral helps earn them APY.

Yield distribution mechanism

Users earning from idle positions is good news, but the yield distribution scenario is challenging. At the resolution point, one position wins, and the other loses. But the yield accumulated during the lifecycle of the positions is not equivalent for the opposing parties, representing variable risks.

It is improbable that the YES and NO stakers split the risk and the position 50:50, so the yield payout also cannot be an even distribution. Splitting the yield at the final resolved price is also inaccurate, as it will nullify the changing positions during the lifecycle of the staking period.

Time-weighted average, or TWAP, is used to solve this dilemma. This mechanism tracks the average price of both the YES and NO positions during the lifecycle of the staking period before calculating yield distribution. Robin Markets has a trustless oracle server to access the price history from Polymarket. It then uses TWAP to process the yield calculation, and signs the results on-chain. Any update on the yield in the staking vault only applies when a valid signature is verified from the oracle.

Oasis role

The trustless oracle runs on ROFL, executing the whole process of price fetching, TWAP computation, and result sign-off inside a secure enclave. No part of the process is visible, accessible, or modifiable by Robin Markets or any third parties. Also, since on-chain verification of signature must accompany any update, it ensures the oracle data remains in sync with the current chain state.

The verifiable-by-design computation and tamper-proof oracle reports ensure there are no trust gaps in the mechanism, letting users avail a first for yield on locked prediction-market positions.

Tradable & verifiable market intelligence

DeFi is the go-to web3 use case for many, but the market reality of retail traders versus institutions and professional traders shows a huge and unfair gap. While institutions benefit from reading and interpreting on-chain flows, liquidity conditions, and real-time market sentiments, professional traders have access to high-grade tools, automations, and data analysis and insights.

The Tradable platform and its SenseAI tool help plug this imbalance. With automated trading enabled and a personalised AI portfolio assistant to help, users other than traditional heavy hitters can also make the most of the market opportunities.

As an autonomous agent, SenseAI reads the market 24x7, bringing institutional feeds and insights to retail. It involves simultaneous access to three layers.

Macro structures like dominance trends and ETF flows
Network health like wallet data and capital inflows/ outflows
Market sentiment like fear/ greed cycles, narrative buildup, and trajectory

With institutional-grade intelligence on their fingertips, average users can use the opportunity to translate market trends and signals into potentially high-return crypto portfolios.

The mechanics of SenseAI

SenseAI, as a market intelligence tool, differs from most similar solutions that produce information overload by dumping too much raw data, with users unable to decide how to interpret the signals or what to do next. Instead, it runs a process that combines reasoned output from strategy, research, and analysis.

As a result, SenseAI is involved in context building to decide what matters and when, data access and processing, and using all this to analyse signals and infer the best foot forward. Two key components of the process are divergence and confluence.

Divergence is where the tool can flag the fragility of a network even when the price pumps and no apparent weakness is visible or predicted by price action. Confluence is where the tool can read signal over narrative so that liquidity and on-chain activity expansion is validated as real strength rather than mere hype.

Every insight is encrypted, verified and paid on-chain, yet the whole process feels like a normal web request.

Oasis role

Market analysis, especially using autonomous agents, needs integrity, and that trust must be earned. The mechanism should be tamper-proof, and there should also be no bias for or against any crypto assets. Running inside ROFL, SenseAI ensures confidential compute on the Tradable virtual chain on Aurora. With remote attestation securing the tool's mechanism, it is safe from any manipulation by the operator, and the user prompts also stay confidential.

Like any other AI tool, memory is the eternal pain point. As user interactions grow, memory also grows, branches, and needs constant access for context. The storage problem is solved by putting the entire memory, comprising messages and context, in an encrypted file on Autonomys Auto Drive. So, the confidential on-chain smart contract gatekeeps and proves any conversation that happens; Auto Drive stores the conversation content, and only the user, holding the keys, can access and read it.

Currently, SenseAI is in testnet mode, where usage by the community provides the information layer for the tool. After mainnet rollout on Aurora and enabling of live token payments, it will be integrated into the Tradable platform as the verifiable market intelligence for individual traders.

Final words

Robin Markets and Tradable's SenseAI showcase how next-gen confidential DeFi evolves alongside AI agents. Integrating Oasis's tech stack like ROFL underlines the value of off-chain compute and verifiable privacy.

What is your take on these projects? Let's hit the comments section.
Also, explore Oasis's in-house private DeFi solution, Privana, or how the protocol can help build and deploy verifiable agents.

ROFLize an App: Bonus Guide to Features & Troubleshooting (Part 1)

DC — Fri, 17 Jul 2026 08:11:12 +0000

Earlier, I described the entire workflow of how to ROFLize an app, from setting up prerequisites to testing it. In a 2-part addendum, I will take you through the various features of ROFL that enhance the apps using it, and also how to troubleshoot issues. The first part covers the first three features.

ROFL Marketplace

While outlining the deployment process of the workflow, I first mentioned the ROFL marketplace. So, what is it? The ROFL marketplace is an on-chain protocol designed for app developers and ROFL node providers.

As the diagram shows, the ROFL marketplace has three entities.

App developers: They build an app, register it on-chain, and rent a machine from the ROFL provider to deploy their apps.
ROFL providers: They are the on-chain entity that bills and assigns machines to the developers, with a hosting plan called the offer.
ROFL nodes: These are servers running on the Oasis node that instantiate machines for hosting an app.

If you are an app developer, refer to the 2-part workflow series, and the deployment process in Part 2 will be relevant for you. Or, if you approach this as an ROFL provider, start by learning about the ROFL node and setting it up to execute runtime off-chain logic inside a TEE.

Secrets

Sometimes we encounter situations where containers need to access data, but exposing it would be disastrous. API keys for accessing certain services fall into this category, and blockchain transparency cannot prevent them from becoming public. Containers running in ROFL can safely pass this type of data using the secrets feature.

Secrets are arbitrary key-value pairs powered by end-to-end encryption, which can only be decrypted inside an app with the right attestation. You can manage this feature using the Oasis CLI, for example:

echo -n "my very secret value" | oasis rofl secret set mysecret -

For a detailed understanding of secret management commands, including importing from .env files, removing secrets, and other advanced features, check out the CLI documentation.

In the above example, the mysecret we created is only encrypted and updated in the local app manifest file, and not yet reflected in the full app version. This enables you to configure multiple secrets without constantly updating the on-chain app configuration. Once you have created all the secrets you need, you can update them all at once with the usual command.

oasis rofl update

Note: The local app manifest doesn't need to be private while storing the secrets. The secret values inside the manifest are end-to-end encrypted. In effect, they are completely inaccessible, even to the administrator who set them up. The reason why only the app can decrypt the secret is that every time a new secret is created, it is encrypted with a corresponding new ephemeral key. As soon as encryption is done, the ephemeral key is discarded and irretrievable.

Now, the secrets pass inside the ROFL containers in two ways.

Environment Variables

Each secret is automatically exposed in the Compose environment and can be trivially used in the Compose file. When this happens, the secret name convention changes, using capitalization and underscores. For example, the earlier known mysecret will now become MYSECRET. However, if you use any space in the name, e.g., my secret, it will become MY_SECRET.

services:
  test:
    image: docker.io/library/alpine:3.21.2@sha256:f3240395711384fc3c07daa46cbc8d73aa5ba25ad1deb97424992760f8cb2b94
    command: echo "Hello $MYSECRET!"
    environment:
      - MYSECRET=${MYSECRET}

Container Secrets

Each secret is also defined and can be passed as a container secret as per Docker documentation. You will also need to define this as an external secret since it is created by the app during boot.

services:
  test:
    image: docker.io/library/alpine:3.21.2@sha256:f3240395711384fc3c07daa46cbc8d73aa5ba25ad1deb97424992760f8cb2b94
    command: echo "Hello $(cat /run/secrets/mysecret)!"
    secrets:
      - mysecret

secrets:
  mysecret:
    external: true

Persistent Storage

Sapphire's confidential EVM runtime enables ROFL developers to use smart contracts for secure and consistent storage. But this is not workable for apps with intensive read/write functions. That's why ROFL has built-in support for local persistent storage. This feature comes with these characteristics:

Local per-machine storage, not synchronized across other ROFL replicas
Fully encrypted on the host machine
Preserved during ROFL upgrades and node restarts

One of the key benefits of this feature is its utility for caching. Whenever the compose.yaml file defines Docker images, persistent storage becomes the default storage destination. They are fetched only the first time an app is deployed, and afterwards, a cached version is used.

Another aspect of the feature is that all non-external container volumes will automatically reside in persistent storage. Let me illustrate this with an example. Here, I have defined a new volume, as referenced in Docker documentation. I have named it my-volume and made .ollama in the home folder persistent. As a result, every time a machine hosting the app restarts, I will not need to download ollama models.

compose.yaml

services:
  ollama:
    image: "docker.io/ollama/ollama"
    ports:
      - "11434:11434"
    volumes:
      - my-volume:/root/.ollama
    entrypoint: ["/usr/bin/bash", "-c", "/bin/ollama serve & sleep 5; ollama pull deepseek-r1:1.5b; wait"]

volumes:
  my-volume:

In the concluding part of this addendum guide, I will discuss the remaining features and troubleshooting process.

For technical specs, APIs, architecture, and integration guides, the Oasis documentation is your starting point.
For direct support on specific issues, the Oasis engineering team is available in the dev-central channel on the official Discord.

ROFLize an App? Part 2: Create, Build, Deploy, Test

DC — Wed, 15 Jul 2026 07:48:55 +0000

Continuing with the 2-part series that is designed to guide developers as they attempt to ROFLize an app, we have so far covered the workflow, the prerequisites needed to proceed, how to containerize the app, and initialize.
In this concluding part of the series, I will show you how to create, build, deploy, and test the app.

Create

The first step for building an app is to create on-chain and assign a unique identifier or app ID. This ID is for use by on-chain smart contracts and has two functions:

helps interact with the right app
gives the app access to a decentralized key management system

To create an app, you will need enough funds. Currently, the threshold for creating a ROFL app is 100 tokens.
If you are doing this on mainnet, you will need to procure 100 ROSE from a centralized exchange.
For this tutorial, we are assuming a testnet setup, so you can get your 100 TEST free from the official faucet.
It is also advisable that you create or import a secp256k1-bip44 account to use with the Ethereum-compatible tooling like Hardhat.

The next step is to select the network - mainnet or testnet, and also the initial administrator account of the app, say myaccount. The CLI will automatically update the manifest file with the assigned app identifier.

oasis rofl create --network testnet --account myaccount

Once done, the CLI will also output the new identifier. For example:

Created ROFL application: rofl1qqn9xndja7e2pnxhttktmecvwzz0yqwxsquqyxdf

This makes the app deployer account the default initial admin for any update to the app's configuration. You can always change the admin address at any point.
Note: The CLI implements a simple governance mechanism. Here, the app's admin is a single account, and even a smart contract can be the admin. It is also possible to implement advanced agent governance mechanisms like using multi-sigs or DAOs with veto powers to control the upgrade process.

Now, a final note about the App ID. It is derived using one of the two schemes:

Creator address + creator account nonce: This is the default. It helps run tests, e.g. in sapphire-localnet, where you want a deterministic app ID.
Creator address + block round number + index of the rofl.Create transaction in the block: This is when you want a non-deterministic approach. It is the preferred mode in production environments. It deters potential attackers from determining the app ID in advance, even if they knew the creator address.

To select which app ID derivation scheme you want, you can simply pass the --scheme parameter.

Build

This operation brings together compose.yaml, specific operating system components, and the hash of a trusted block on the Sapphire chain. As a result, you can safely execute the app inside a TEE.

Whenever any part of the app changes, this step is necessary before deploying. The build process takes the compose file together with other ROFL artifacts and deterministically generates a bundle that you can deploy later.
Another function of the build process is to compute the enclave identity of the bundle. This is needed during remote attestation to authenticate the app instances before they can be allowed to access the key management system and other features.

oasis rofl build

Running this step generates a ROFL bundle to be used later for deployment.

ROFL app built and bundle written to 'myapp.default.orc'.

Update On-chain App Config

Any changes to the app's policy defined in the manifest also require updating the on-chain app config, so that the changes can take effect.
The designated admin account can issue an update transaction by running the CLI.

oasis rofl update

Alternatively, you can automate the build and verify steps using the build-deploy-rofl-action GitHub Action. More on this later.

Deploy

This is one of the most detailed sections of the workflow.

A ROFL app can be deployed to Sapphire or Cipher paratimes where the ROFL module has been installed. For our purposes, we will proceed with Sapphire, as it implements all ROFL functionalities.

You can deploy your app in several ways to a ROFL node, defined as a light Oasis Node with support for TEE and configured Sapphire runtime. I will discuss in detail on using the ROFL marketplace and GitHub Actions options.

Alternatively, you can copy over the ROFL bundle to your ROFL node manually and configure it. As the ROFL node is a separate and elaborate topic, not in the scope of this tutorial, we will not go into details here, so check out the quick guide for hosting the ROFL bundle directly.

Deploy on ROFL Marketplace

The Oasis CLI has built-in support for renting a machine on the ROFL marketplace and deploying an app. You can get a list of the default Oasis-managed ROFL providers with this command.

oasis rofl deploy --show-offers

Using provider: oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz (oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz)

Offers available from the selected provider:
- playground_short [0000000000000001]
  TEE: tdx | Memory: 4096 MiB | vCPUs: 2 | Storage: 19.53 GiB
  Price: 5.0 TEST/hour

If you want to select a different provider and offer, you can do so by using the --provider and --offer parameters, respectively.

For this tutorial, let us proceed with the default.

oasis rofl deploy

Using provider: oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz (oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz)
Pushing ROFL app to OCI repository 'rofl.sh/0ba0712d-114c-4e39-ac8e-b28edffcada8:1747909776'...
No pre-existing machine configured, creating a new one...
Taking offer: playground_short [0000000000000001]

The result of this command is threefold.

It copies over the ROFL bundle .orc to an Oasis-managed OCI repository rofl.sh
It pays offer playground_short with ID 0000000000000001 to provider oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz
It returns the machine ID and stores it in the manifest file

You can check the status of your active ROFL machine.

oasis rofl machine show

Name:       default
Provider:   oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz
ID:         00000000000000a2
Offer:      0000000000000001
Status:     accepted
Creator:    oasis1qpupfu7e2n6pkezeaw0yhj8mcem8anj64ytrayne
Admin:      oasis1qpupfu7e2n6pkezeaw0yhj8mcem8anj64ytrayne
Node ID:    bOlqho9R3JHP64kJk+SfMxZt5fNkYWf6gdhErWlY60E=
Created at: 2025-05-22 15:01:47 +0000 UTC
Updated at: 2025-05-22 15:01:59 +0000 UTC
Paid until: 2025-05-22 16:01:47 +0000 UTC
Proxy:
  Domain: m162.test-proxy-a.rofl.app
  Ports from compose file:
    5678 (frontend): https://p5678.m162.test-proxy-a.rofl.app
Resources:
  TEE:     Intel TDX
  Memory:  4096 MiB
  vCPUs:   2
  Storage: 20000 MiB
Deployment:
  App ID: rofl1qpjsc3qplf2szw7w3rpzrpq5rqvzv4q5x5j23msu
  Metadata:
    net.oasis.deployment.orc.ref: rofl.sh/0ba0712d-114c-4e39-ac8e-b28edffcada8:1747909776@sha256:77ff0dc76adf957a4a089cf7cb584aa7788fef027c7180ceb73a662ede87a217
Commands:
  <no queued commands>

The details of the machine will show:

Machine status and expiration date
Provider information
Proxy URLs for any published ports
Resource allocation (TEE type, memory, CPUs, storage)
Deployment details

To view the logs of the app, you need to use this command and sign the request with the app's admin account.

oasis rofl machine logs

Although only the app admin can access the logs, the data here is stored unencrypted on the ROFL node. So, during the production stage, you should never print any confidential data to the standard or error outputs.

GitHub Actions

We briefly touched on this during the build process. This is applicable for ROFL apps from CI/CD pipelines. Recap of the build-deploy-rofl-action automation.

Validate

You can identify configuration errors on every push and pull request with this command, and you don't need to run a full build.

- uses: oasisprotocol/build-deploy-rofl-action@master
  with:
    network: testnet
    only_validate: true

Build and Verify

You can verify that your build is reproducible and that enclave IDs match the on-chain state. Any mismatch will fail the build.

- uses: oasisprotocol/build-deploy-rofl-action@master
  with:
    network: mainnet
    skip_update: true
    skip_deploy: true

Full Deployment

- uses: oasisprotocol/build-deploy-rofl-action@master
  with:
    network: mainnet
    wallet_account: deployer
    wallet_import: true
    wallet_secret: ${{ secrets.WALLET_SECRET }}
    wallet_algorithm: secp256k1-raw

Now, it is time to check that the app is running. It does not matter which deployment path you take; the command is the same.

oasis rofl show

App ID:        rofl1qqn9xndja7e2pnxhttktmecvwzz0yqwxsquqyxdf
Admin:         oasis1qrydpazemvuwtnp3efm7vmfvg3tde044qg6cxwzx
Staked amount: 10000.0
Policy:
  {
    "quotes": {
      "pcs": {
        "tcb_validity_period": 30,
        "min_tcb_evaluation_data_number": 17,
        "tdx": {}
      }
    },
    "enclaves": [
      "z+StFagJfBOdGlUGDMH7RlcNUm1uqYDUZDG+g3z2ik8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==",
      "6KfY4DqD1Vi+H7aUn5FwwLobEzERHoOit7xsrPNz3eUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=="
    ],
    "endorsements": [
      {
        "any": {}
      }
    ],
    "fees": 2,
    "max_expiration": 3
  }

=== Instances ===
- RAK:        AQhV3X660/+bR8REaWYkZNR6eAysFShylhe+7Ph00PM=
  Node ID:    DbeoxcRwDO4Wh8bwq5rAR7wzhiB+LeYn+y7lFSGAZ7I=
  Expiration: 9

This shows that there is a single instance of the app running on the given node. It also displays its public runtime attestation key (RAK) and the epoch at which its registration will expire if not refreshed. So, if you want to continue working with the app, you will need to periodically refresh the registration.

You can also check out the status of your app on the Oasis Explorer → Sapphire → ROFL.
Mainnet
Testnet

Test

While discussing the initialization phase, I outlined several ways to do so. So, the testing process will vary based on which option you took.

TDX ROFL containers

No appd and Localnet Required
If your app doesn't rely on appd, you can export any secrets required by compose.yaml and execute podman compose up with a simple command.

export SECRET=some_secret
podman compose up --build

Testing with appd and Localnet
If your app is connected to a functional appd, you will need to spin up the sapphire-localnet Docker image and bind-mount the folder that contains your rofl.yaml.

docker run -it -p8544-8549:8544-8549 -v .:/rofls ghcr.io/oasisprotocol/sapphire-localnet

It will run for a few moments and give an output like this.

* TDX ROFL detected. Localnet appd service will be accessible via UNIX socket and TCP port

UNIX socket (Linux)

Shell

curl --unix-socket ./rofl-appd.sock http://localhost/rofl/v1/app/id

TCP port (macOS, Linux)

Shell

curl http://localhost:8549/rofl/v1/app/id

ROFL clients can connect to the TCP port using one of three ways.

Python

from oasis_rofl_client import RoflClient
client = RoflClient(url="http://localhost:8549")

TypeScript

import { RoflClient } from '@oasisprotocol/rofl-client';
const client = new RoflClient({ url: 'http://localhost:8549' });

Rust

use oasis_rofl_client::RoflClient;
let client = RoflClient::with_url("http://localhost:8549")?;

Once all this is done, you can now spin up your services and run tests. Usually we use the same compose.yaml for production and testing. So, the following command is useful to point a service to an alternate Localnet's rofl-appd.sock location.

compose.yaml

    volumes:
      - ${ROFL_APPD_SOCKET:-/run/rofl-appd.sock}:/run/rofl-appd.sock

Now, when you execute podman compose, it brings up your services in the Localnet environment.

export SECRET=some_secret
export ROFL_APPD_SOCKET=./rofl-appd.sock
podman compose up --build

In the final step, you are now ready to try out the app or execute your end-to-end integration tests as you see fit. Another option would be to use sapphire-localnet in the form of a GitHub action inside your CI service.

TDX ROFL raw

Local testing for this is currently not supported. So, if you have initialized with this option, you will need to deploy them on Sapphire Testnet and try them out.

SGX ROFL

To test this, the first step is to compile your SGX ROFL with debug option enabled. Invoke this command to create a separate localnet deployment in your ROFL manifest.

rofl.yaml

deployments:
  localnet:
    app_id: rofl1qqn9xndja7e2pnxhttktmecvwzz0yqwxsquqyxdf
    network: testnet
    paratime: sapphire
    admin: test:bob
    debug: true

oasis rofl build --deployment localnet --offline

Running this command produces a bundle named your-app-name.localnet.orc.

Now, when you execute the sapphire-localnet Docker image and bind-mount the folder that contains the ROFL manifest, the image will automatically register the ROFL on Localnet and execute it inside the Localnet ROFL node.

docker run -it -p8544-8548:8544-8548 -v .:/rofls ghcr.io/oasisprotocol/sapphire-localnet

To verify that the Localnet .orc bundle was loaded and you can test, look out for this output.

 * Detected SGX ROFL bundle: /rofls/rofl-appd-localnet.localnet.orc

This concludes the detailed workflow of how to ROFLize an app. However, other aspects of this process also deserve a tutorial. For example, you may wonder what features a ROFL app has or how to troubleshoot, should you need to. I will write up a bonus guide for these topics next time.

For a quick chat with the Oasis engineering team for help with specific issues, you can drop your comments in the dev-central channel in the official Discord.

Better AI Context Management With Privacy. Case Studies: Plurality, Ekai.

DC — Wed, 24 Jun 2026 07:15:54 +0000

Earlier this year, I had discussed at length about AI memory challenges and potential solutions. I mentioned a couple of names there who had been working on AI context management, as I firmly believe that is how we solve the memory constraints.

Here, I will further explore two projects that have progressed in this aspect and offer a glimpse of the AI future that could take our experiences to the next level.

Plurality & portable AI context

Consider this: what if you did not have to start over constantly, or to reiterate and summarize previous conversations whenever you switch models or start a new session?

Plurality started by trying to answer this. Their aim: to develop an Open Context Layer. As a result, you could autonomously store your data and chats in specific memory buckets. This would not only help with better context management, but also enable sharing the context as needed.

AI Context Flow

Billed as a fix for the problem of portable AI memory, Plurality built AI Context Flow. The tool works with ChatGPT, Claude, Gemini, Grok, and Perplexity.

One of the USPs of AI Context Flow is the ingrained privacy control. It thus differs from most other solutions, where cloud storage and data mining are part of the deal, mostly without the knowledge or consent of the users. Plurality teamed up with Oasis for a TEE-based, privacy-first context management, where you can decide what AI can see, you can revoke access at your discretion, and have complete data ownership.

Let's now see how Plurality and Oasis address the privacy question.

Privacy problem

AI Context Flow solves one problem but opens up a new challenge - the infrastructure issue. Helping portable context flow through other servers is tricky and poses inherent trust gaps.

The easiest answer that springs to mind is adopting the Model Context Protocol (MCP). It enables agents to access tools, data, memory, and APIs. The infrastructure is powerful and growing as more and more AI products get built on top of it. But the privacy pain point lingers.

Most people, when they talk about AI privacy, are thinking about the model. But the underlying infrastructure is where most privacy is exposed. When a tool uses MCP, the MCP operator can see everything running through the server. So, you get the portable context but without privacy guardrails. Plurality faced this issue while building AI Context Flow, where user intent, history, and sensitive information were vulnerable to third-party access.

Oasis solution

Oasis comes into the picture by offering its Runtime Off-chain Logic (ROFL) for confidential computation to fix the infrastructure exposure dilemma. Now, the context can flow through the MCP server running inside a Trusted Execution Environment (TEE). This means:

The operator cannot read context in memory
The host OS cannot tamper with execution
Code running is provable with remote attestation

So, when Plurality runs its MCP server on ROFL, the confidentiality of the infrastructure layer is not rooted in mere trust assumptions but actually verifiable. Context is stored and processed within the secure enclave away from prying eyes, and visible and accessible only to the model as needed.

Plurality next

Privacy-focused context management opens up new opportunities. In the next phase, Plurality is focusing on building a context marketplace on top of this foundation.

Simply stated, the context marketplace aggregates the information and knowledge that usually stays fragmented and in silos to be available in packages that anyone can opt to inject into any AI tool. Here, too, the privacy constraint is the potential deal-breaker. And Oasis, with its privacy layer, enables sharing and monetization of context without accessibility to the parties facilitating the transaction in the marketplace.

Ekai & AI context layer

The trade-off of using AI extensively is our dependency on the context that we have built meticulously over time, fine-tuning prompts and accumulating layers of responses.

Ekai has built a developer-focused solution that can seamlessly and cost-efficiently switch among various AI models via smart model routing without losing precious context. Oasis provides the trustless and verifiable privacy engine that such a context engine needs to function.

It addresses two major pain points in AI today.

Access control: Access sharing is a common practice among users. They let friends and colleagues share access to AI models for ease of use. This is most prevalent while collaborating on projects. Divulging your actual credentials is a high-risk proposition.
Agent context: Sharing access is easy; sharing context is the real challenge. Say, you are working with an agent for an hour, and it has accumulated patterns, decisions, contents, outputs, and the logic connecting everything. This context lives in plaintext and is shareable. But whenever there is a new session, the context is gone, or it is a nightmare to locate and reference it. Sometimes, even within a single session, the context degrades as the session timing progresses, leading to hallucinations. Summarization works with limitations, as compressed details tend to get lost in the AI's memory architecture.

Ekai is trying to solve this by becoming the context engine for AI agents.

Contexto

Designed as the context layer for AI agents, Contexto currently works with OpenAI, Anthropic, Google, xAI, OpenRouter, and Groq, while the gateway runs on ROFL. Since it is built as an OpenClaw plugin, migration is not necessary.

From an architectural point of view, Contexto works by keeping the main thread clean by storing and indexing older work. So, when the agent calls for it, the tool retrieves the relevant context automatically.

All tasks and subtasks run in isolation and are handled by scoped sub-agents who will return contextualized outputs and assembled context in short and simple results. However, nothing gets thrown out, and if you need to trace the full details, they are recoverable on demand.

What Oasis adds

Ekai's Control Plane enables storing encrypted API keys on-chain via Oasis Sapphire, so that you can delegate access with granular controls such as model restrictions, spending limits, and instant revocation. As decryption takes place only within the secure enclave or the TEE, it allows access sharing without credential sharing.

Now, context. As our session windows with AI models grow, the more we have to lose if trust fails, since the context plaintext is recorded for anyone with access to see or manipulate. This context confidentiality issue is solved with ROFL running the context layer inside a TEE. Result: context is stored, indexed, and retrieved within the secure enclave without ever exposing the plaintext.

Ekai next

As of now, both the Control Plane and the context layer as an OpenClaw plugin are live on mainnet. The next phase involves making persistent context private by default as they design the bringing of the context store into the ROFL enclave.

This would set the stage for agent-to-agent context routing. When this becomes possible, your agent will be able to collaborate with agents belonging to anyone. These disparate agents can then share relevant context with baked-in rules and privacy policies.

Final words

I am reminded of Oasis AI head, Marko Stokić's discussion about AI memory in his Forbes article.

We need confidentially computed, and verifiable portable AI context where the user can decide if and when they want to move across AI models, and the interoperable memory layer is subject to the user's data sovereignty and privacy. Both Plurality and Ekai, adopting a privacy-first approach with Oasis's tech stack, demonstrate their commitment to that future.

What is your take on these projects working to solve AI's persistent memory problem? Let's hit the comments section.
And if you would want to explore more about how Oasis can help you deploy verifiable agents, the journey starts here.

Privana Is Coming. Private DeFi, No Catch.

DC — Fri, 19 Jun 2026 09:29:25 +0000

When web3 started its journey, one of the earliest use cases was decentralized finance (DeFi), and it quickly earned popularity among crypto enthusiasts. Over the years, DeFi has evolved in its scope and impact, and is still the best use case of web3 that invites adoption. However, DeFi has not been an unmitigated success and has its own set of challenges that frustrate users and discourage wider adoption.

The dark side of DeFi

The biggest pain point in DeFi is MEV, or maximal extractable value. For a long time, users had to accept MEV as an invisible tax, although by definition, it is an oversimplification to call it bad. Yet many veteran users cannot escape the clutches of MEV's ugly side, and inexperienced users fall prey to it unwittingly as they navigate the world of DeFi.

Here are the most prevalent MEV exploits.

In a sandwich attack, bots profit like this: notice the user awaiting a swap, buy the token, push the price up, then execute the user's trade at a worse price, and immediately sell so that the user gets fewer tokens.
In frontrunning, when bots notice a pending transaction, they copy and submit the same trade with higher gas fees, thus jumping the queue at the user's disadvantage.
In back-running, bots execute transactions immediately after a large trade to cash in on the arbitrage opportunity.

Researchers have noted how users lose hundreds of millions of their funds due to poor defence against such attacks.

It is not that solutions don't exist. But protection against MEV is still optional, and if users don't know exactly what to do or how, the bots will collect their dues. Public mempools and lack of privacy are the other side of the coin.

Enter private DeFi

Oasis, which has been perfecting its privacy-first infrastructure, has joined the fray in offering an alternative to old, flawed DeFi with a new application - Privana.

In tech-savvy speak, it combines Sapphire (only production-ready confidential EVM), secure enclaves as in TEEs, encrypted mempools, liquefaction, key encumbrance, and smart privacy to create a consumer-facing, user-friendly private DeFi solution. Let's unpack the user benefits instead of decoding jargon or justifying technical excellence.

What is Privana

Simply stated, Privana offers private swaps, automated yields, and zero MEV in multi-chain operations (Ethereum, Base, HyperEVM).

USPs:

Privacy-first - All user transactions are TEE-protected, and as they never hit the public mempools, bots can neither see nor target the trades. Result: protection from the adversarial effects that MEV inevitably causes.
Automation - Users can set the operational rules and let everything execute in auto-mode. Their keys remain private, so no sharing, no exposure, no exploit risks - all in 3 steps.
Deposit into the vault - Users send their tokens to the Privana vault, a secure enclave.
Set preferences - Users choose their swap conditions, yield settings, and app permissions.
Activate strategy - Once users approve, they can sit back and forget about manual intervention. Swaps, yield allocation, and rebalancing all run in the background without exposing any of the activity.
Self-custody - Applying the concept of key encumbrance, self-custody design is achieved through non-extractable keys, so no one can access or move the key outside the policy set by the users, not even by Privana developers in the backend. This also redefines self-custody as it empowers users to govern the keys instead of holding them.
Multi-chain - Users don't need the expertise or headache of hopping between chains as one interface, no bridges, no wallet-switching leads to a seamless experience.

A quick overview of Privana's capabilities and what other major protocols offer, showcasing its versatile advantages with structural privacy design.

Why Privana

Privana does not claim to be the only solution in the DeFi space. So, when we do a deep dive into comparing what is available right now, it clearly indicates that no one else combines everything. It is particularly interesting to see the trade-offs, even when tools have baked-in privacy.

Privana checks all the boxes.

No decentralized exchange (DEX) so far has been immune to MEV attacks, and Privana aims to counter this with the idea of encrypted mempools. When transactions are on-chain and public, they sit exposed in the mempool, and any malicious bot on the network can take advantage and undercut even a simple swap. Private RPCs and relays do work with limitations. They successfully hide transactions from the network, but reveal full swap intent to the relay operators.

A centralized exchange (CEX) solves this particular trust gap of the DEX with internal books, but as the users' keys are in their custody, it opens a new can of worms. In truth, both DEXes and CEXes offer partial solutions with trade-offs. If there is some degree of MEV protection, then on-chain full transparency becomes an issue. If private swaps are possible, they don't come with automation and self-custody. Users usually get either cross-chain swaps or privacy-focused swaps, but not both.

As a trading interface, Privana does the serious legwork with its privacy-first approach - designed specifically to be private by default and automated without giving up control. This is a long-awaited solution that promises to plug the holes while delivering the optimal DeFi experience for users.

Privana is coming

The Privana roadmap comprehensively lists what users can expect from the product in the coming days.

The impending launch of Privana is also in sync with the new strategic direction adopted by Oasis. The protocol already has the underlying infrastructure for implementation. So, instead of solely relying on ecosystem partners to build the dApps, it is now focusing on shipping products that directly bring the benefits of the tech stack to the users.

Privana promises to be the vanguard. For users, this is a new opportunity as well to transform their DeFi experience for the better.

There are already several incentives announced for early joiners of Privana:

Zero fees for 90 days
Founding Member status
Priority queue at launch

Do not miss out.

Let's discuss in the comments your take on Privana and private DeFi, and what aspects you like the best, and what else you want to be incorporated down the line.

ROFLize an App? Part 1: ROFL Workflow To Initialization

DC — Thu, 18 Jun 2026 08:16:32 +0000

Recently, I shared a quickstart guide titled "How To Enhance Your App With Oasis ROFL". While the tutorial was complete in itself, I skipped some of the finer implementation details to keep it streamlined. Here, in this new 2-part series, I will unpack those sections step by step.

Rather than covering old ground from the post, which already features a short explainer video and visuals of the architectural breakdown and the workflow overview of the ROFL (runtime off-chain logic) framework, let's dive straight into the developers' POV here.

Workflow

As this visual shows, there is a dedicated Trusted Execution Environment (TEE) for every app that runs inside ROFL. An Oasis node provides the TEE from its ORC bundle, consisting of a zip archive containing the program binaries and metadata required for execution.
As a result, the ROFL apps registering on Oasis's network can easily authenticate to on-chain smart contracts and also transparently gain access to the decentralized per-app key management system.

The TEE ensures app security and enables secure communication with the outside world. The function of the light client here is to establish a fresh view of the Oasis consensus layer. This not only provides a source of approximate time references but also acts as an integrity gatekeeper for the verification of all on-chain states.
In addition, the app also generates a set of ephemeral cryptographic keys, used in remote attestation and on-chain registration, and then discarded at the end of the session to provide forward and backward secrecy.
The authentication process for on-chain modules is completed by signing and submitting special transactions. As a result, the app can now perform any arbitrary task and interact with the outside world through network connections, authenticated via HTTPS/TLS, or other methods such as light clients for other chains.

Prerequisites

We need 2 tools for ROFL development and deployment.

Oasis CLI: The Oasis command-line interface (CLI) is an all-in-one tool, handling wallet management, app registration, building, deployment, and replica management. For a detailed overview and installation instructions, check out the oasis command.
Docker: Having a containerized build environment is an essential prerequisite, as it ensures that you do not have to install a handful of Intel-specific libraries and dependencies on your system. Moreover, the Compose function will help test the ROFL locally before you deploy it on-chain.

You can choose any of the 3 following ways to continue.

Preferred

This method uses Oasis CLI and a container for building and testing.
First, you need to download and install the Oasis CLI on your platform.
Next, test the functionality by building the ROFL app.

oasis rofl build

Conservative

In this method, there are containers everywhere.
If there are any issues while installing the Oasis CLI locally, or perhaps you want to skip the Oasis CLI step altogether, the workaround is to run the oasis command from the rofl-dev image.

Note: You must be careful when you bind-mount the Oasis CLI config folder, which contains your wallet. Otherwise, there is a risk of losing access to your (funded) accounts.

Invoke oasis from the rofl-dev image.

For Linux:

docker run --platform linux/amd64 --rm -v .:/src -v ~/.config/oasis:/root/.config/oasis -it ghcr.io/oasisprotocol/rofl-dev:main oasis

For MacOS:

docker run --platform linux/amd64 --rm -v .:/src -v "~/Library/Application Support/oasis/":/root/.config/oasis -it ghcr.io/oasisprotocol/rofl-dev:main oasis

For Windows:

docker run --platform linux/amd64 --rm -v .:/src -v %USERPROFILE%/AppData/Local/oasis/:/root/.config/oasis -it ghcr.io/oasisprotocol/rofl-dev:main oasis

This step here is optional. You can choose to add oasisalias to your shell start-up script. This will mimic as if Oasis CLI was installed locally.

For Linux:
~/.bashrc

alias oasis='docker run --platform linux/amd64 --rm -v .:/src -v ~/.config/oasis:/root/.config/oasis -it ghcr.io/oasisprotocol/rofl-dev:main oasis'

For MacOS:
~/.bash_profile

alias oasis='docker run --platform linux/amd64 --rm -v .:/src -v "~/Library/Application Support/oasis/":/root/.config/oasis -it ghcr.io/oasisprotocol/rofl-dev:main oasis'

Advanced

This method uses native Oasis CLI and ROFL build utils.

Note: It is for linux/amd64 only.

The first step is installing the Oasis CLI locally.
Next, you need to install tools for creating and encrypting partitions and Quick Emulator (QEMU). For a Debian-based Linux, this can be done by running this command:

sudo apt install squashfs-tools cryptsetup-bin qemu-utils

Finally, you may be looking to build SGX and TDX-raw ROFL bundles. In that case, it will require the installation of the Rust toolchain and Fortanix libraries. It is a separate detailed process involving Oasis Core prerequisites, which I will elaborate on in a later post. For now, you just follow the steps outlined here.

Note: You do not need a working SGX/TDX TEE when building ROFL natively. Even an Intel-based CPU and the corresponding libraries will suffice.

Containerize

We have often mentioned that an ROFL app needs to be containerized. What does this mean? A container is basically a controlled environment that includes the exact version of the operating system, both system and user libraries, as well as your configured service. The image of the container is uploaded to an OCI file server, such as docker.io or ghcr.io. The server hosting your app can then download it, consisting two files.

my-bot
├── bot.py           # A python bot script
└── requirements.txt # Python dependencies

Now, we will use Docker to containerize. However, you can choose to go with Podman instead of Docker, as once the app is deployed to a ROFL node, the containers there will be orchestrated by Podman anyway.

Dockerfile

Here we will create a file called Dockerfile inside the project folder. This will tell Docker to compile a python-based image and add the python bot script on top of it.

Dockerfile

FROM python:alpine3.17

WORKDIR /bot
COPY ./bot.py ./requirements.txt /bot
RUN pip install -r requirements.txt

ENTRYPOINT ["python", "bot.py"]

Compose

The function of Docker Compose is to orchestrate the containers you will be using. This ensures correct sequencing, defining storage points, networking, and other functionalities. You can create compose.yaml with the following command.

compose.yaml

services:
  python-bot:
    build: .
    image: "docker.io/YOUR_USERNAME/YOUR_PROJECT"
    platform: linux/amd64
    environment:
      - TOKEN=${TOKEN}

You may need to adjust the image: field(s) to fit your needs. The image: field must always point to a publicly accessible OCI registry from where your image will be downloaded for execution.
If you are replacing the image: field with a fully qualified domain of the OCI server you use, followed by your username, the field will look like:

docker.io/your_username/my-bot
ghcr.io/your_username/my-bot

Note: Always specify the container image URL with a fully qualified domain name, e.g., docker.io/ollama/ollama and not just ollama/ollama.

Build and Push

Now, you can build the container image and tag it using docker compose.

docker compose build

To check the compose setup locally, test it with this command.

docker compose up

To stop once done, use this command.

docker compose down

After you have completed building and tagging the images, the next step is to push the container images to a publicly accessible OCI registry that we referred to earlier (docker.io or ghcr.io).
For first-time use, you need to perform an authentication step by running this command.

docker login

Once done and for all those already logged in before, this command will upload the container images to the registry.

docker compose push

Note: For first-timers, when pushing the image to GitHub containers, please ensure public package visibility is properly configured.

Pin Your Image Hash

This is the final step in the containerizing process. It helps prevent another container image from being pulled inside ROFL. You do it by pinning the image digest inside compose.yaml. To fetch the sha256:... digest, try invoking:

docker images --digests

Then you need to append @ and the digest next to the image tag in your compose.yaml. Example:

    image: "docker.io/MY_USERNAME/my-bot@sha256:9633593eb9e8395023cb0d926982602978466ec003efa189d94a34e7bea6ec0d"

Init

In the final section of this tutorial, we will see how to initialize the ROFL app. Before starting, you need to choose from the 3 options below. Notably, whatever you choose, it would likely be a trade-off between the Trusted Computing Base (TCB) size and ease of use.

TDX containers ROFL (default): A Docker compose-based container service packed in a secure virtual machine.
Raw TDX ROFL: A Rust app compiled as the init process of the operating system and packed in a secure virtual machine.
SGX ROFL: A Rust app with fixed memory allocation compiled and packed into a single secure binary.

Init App Directory and Manifest

The first step is to create the basic directory structure for the app using the Oasis CLI.

oasis rofl init my-app

You now have a my-app directory and have also initialized a ROFL manifest file. As noted above, the default is a TDX container-based ROFL. To select one of the other options, you need to use the --kind parameter.

As a result of the init command, you will get the following output summary.

Creating a new ROFL app with default policy...
Name:     my-app
Version:  0.1.0
TEE:      tdx
Kind:     container
Git repository initialized.
Created manifest in 'rofl.yaml'.
Run `oasis rofl create` to register your ROFL app and configure an app ID.

The directory structure (omitting git artifacts) will look like this.

myapp
├── compose.yaml        # Container compose file.
└── rofl.yaml           # ROFL app manifest.

Note: The manifest that this step initialized is a ROFL feature that contains metadata, secrets, and requested resources. These can be modified either manually or by using the CLI commands and require to be discussed in detail separately. For now, we have finished initialization.

In the concluding part of the series, I will guide you through the next steps in ROFLizing your app, involving create, build, deploy, and test processes.
Until then, if you encounter any issues, you can have a quick chat with the Oasis engineering team for help by dropping your comments in the dev-central channel in the official Discord.

Guide To Deploying A Trustless Eliza Agent With Oasis ROFL

DC — Thu, 28 May 2026 06:53:48 +0000

Oasis introduced the framework for runtime off-chain logic (ROFL) to help build and run apps off-chain while ensuring privacy and maintaining trust with on-chain verifiability. For most people, this explainer video would be enough. But for developers and dApp builders, who want to try things out themselves, a deeper dive is worth it.

In this tutorial, I will demonstrate how to build and deploy a trustless Eliza agent with Oasis ROFL.

Objective

The objective is to have a working Eliza agent running inside a ROFL Trusted Execution Environment (TEE). I will also show how to get it registered and validated as a trustless agent in the ERC-8004 registry. The agent's code will be fully auditable, and anyone can verify the authenticity of the origin of the deployed instance, which is immutable and tamper-proof.

Prerequisites

Refer to the prerequisite section in the ROFL quickstart tutorial for setup details.
So, right now, we need these to get started.

Docker (or Podman) with credentials. It can be on docker.io, ghcr.io, or any other public OCI registry.
Oasis CLI and at least 120 TEST tokens in your wallet. Since we are building in the testnet environment, you can get these tokens for free from the official faucet.
Node.js 22+. It is for Eliza and helper scripts.
OpenAI API key
RPC URL. It is to access the ERC-8004 registry (e.g. Infura).
Pinata JWT. It is to store agent information in IPFS.
At least 2 GiB of memory and 10 GB of storage.

Eliza Agent Creation

The first step is to initialize a project using the ElizaOS CLI. Next, prepare it for ROFL.

# Install bun and ElizaOS CLI
bun --version || curl -fsSL https://bun.sh/install | bash
bun install -g @elizaos/cli

# Create and configure the agent
elizaos create -t project rofl-eliza
# 1) Select Pqlite database
# 2) Select the OpenAI model and enter your OpenAI key

# Test the agent locally
cd rofl-eliza
elizaos start
# Visiting http://localhost:3000 with your browser should open Eliza UI

Containerize

In this step, you will need to containerize both the app and the ERC-8004 wrapper.
You will notice that the Eliza agent startup wizard has already generated:

Dockerfile - this packs your agent into a container.
docker-compose.yaml - this automatically configures, connects, and manages the interdependent postgres and elizaos containers.

The next step is to make some changes to docker-compose.yaml.

In the PostgreSQL section, you need to replace relative image: ankane/pgvector:latest with image: docker.io/ankane/pgvector:latest.
You need to name the elizaos image with a corresponding absolute path, e.g. image: docker.io/YOUR_USERNAME/elizaos:latest.
You need to register the Eliza agent as a trustless agent in the ERC-8004 registry using the rofl-8004 snippet. Ensure that the environment variables are mapped as is.

docker-compose.yaml

  rofl-8004:
    image: ghcr.io/oasisprotocol/rofl-8004@sha256:f57373103814a0ca4c0a03608284451221b026e695b0b8ce9ca3d4153819a349
    platform: linux/amd64
    environment:
      - RPC_URL=${RPC_URL}
      - PINATA_JWT=${PINATA_JWT}
    volumes:
      - /run/rofl-appd.sock:/run/rofl-appd.sock

The validation flow looks something like this:

Once you have edited docker-compose.yaml, it is time to build and push.

docker compose build
docker compose push

If you are looking for full verifiability, you need to pin the digest by appending image: ...@sha256:... to all images in docker-compose.yaml.

Init & Create

Once all previous steps are complete, you will find that the agent is running in a container within a TEE. In this setup, ROFL handles the startup attestation of the container and the secrets in the form of environment variables. As a result, the TEE is completely transparent to the Eliza agent app.

oasis rofl init
oasis rofl create --network testnet

You can check out on-chain activity and app details in the Oasis Explorer.

Build ROFL bundle

This is where the memory and storage prerequisites come in handy.
First, you need to update the resources section.

rofl.yaml

resources:
  memory: 2048
  cpus: 1
  storage:
    kind: disk-persistent
    size: 10000

Now, you can build the ROFL bundle by invoking this command.

oasis rofl build

Secrets

In this step, we take care of encryption. It involves:

End-to-end encrypting of OPENAI_API_KEY and storing it on-chain.
Providing the RPC_URL and PINATA_JWT values for ERC-8004 registration.

echo -n "<your-openai-key-here>" | oasis rofl secret set OPENAI_API_KEY -
echo -n "https://sepolia.infura.io/v3/<YOUR_KEY>" | oasis rofl secret set RPC_URL -
echo -n "<your-pinata-key-here>" | oasis rofl secret set PINATA_JWT -

Then comes the important step of storing the secrets as well as the previously built enclave identities on-chain.

oasis rofl update

Deploy

This completes the building of the Eliza agent. Now, we need to deploy it to an ROFL provider.

oasis rofl deploy

The Oasis-maintained provider is selected on Testnet, which rents a node for 1 hour by default. You can extend the rental period for more hours, say for 6 hours, by invoking oasis rofl machine top-up --term hour --term-count 6 command.

Test

You have successfully built and deployed your very own Eliza agent. You can test if it is running properly with this CLI check.

# Show machine details (state, proxy URLs, expiration).
oasis rofl machine show

A successful agent boot means the Proxy: section will show the URL where the agent is accessible. So, for example if it shows:

Proxy:
  Domain: m1058.opf-testnet-rofl-25.rofl.app
  Ports from compose file:
    3000 (elizaos): https://p3000.m1058.opf-testnet-rofl-25.rofl.app

In this case, the app would be accessible at https://p3000.m1058.opf-testnet-rofl-25.rofl.app.

ERC-8004 Registration and Validation

This is not an automatic step and needs to be completed to get this Eliza agent registered and validated as a trustless agent in the ERC-8004 registry. When you are running the agent for the first time, the rofl-8004 service will derive the Ethereum address for registering it. To go ahead, you will need to fund that account with some ETH to pay for the gas fees.

Use this command to fetch your app logs.

oasis rofl machine logs

The Please top it up line will show the derived address. After funding it, your agent is registered and validated, and ready to go.

Please note: All logs here are accessible to the app admin, as they are stored unencrypted on the ROFL node. So, remember not to put any private information here.

Demo

This guide shows how you can build your own agent, but if you need to check out a full-fledged demo of how it looks and works, there is an example in the official Oasis repository.
Trustless Agent Demo

For a quick chat with the Oasis engineering team for help with specific issues, you can drop your comments in the dev-central channel in the official Discord.

Key Encumbrance: The Primitive That Makes Programmable Privacy Possible

DC — Wed, 27 May 2026 08:34:18 +0000

Over the years, blockchain technology has unlocked key primitives that drive utility and adoption. Multisigs, multi-party computation, ERC-4337 (account abstraction), smart wallets, etc., have all contributed to making it more accessible and user-friendly.

But problems persist. Public blockchains mean absolute transparency and on-chain visibility, leading to constant exposure and risk of exploitation. Then there is the need to always coordinate among people to enable the "multi" aspect for security. Most of the major chains are also siloed, and interoperability is still very limited in application. Moreover, key custody is binary, making private key management both challenging and often trust-dependent. And this does not inspire user confidence or mass adoption.

Key Encumbrance

Oasis has been at the forefront of privacy-first blockchain technology and utility, and has actively supported the development of primitives to advance this.
Last year the protocol collaborated with researchers at IC3 and Cornell Tech to explore practical implementations of Liquefaction on Sapphire.

Key encumbrance is a core benefit of Liquefaction that proposes an elegant solution for the pain points discussed earlier. Here, the private key is generated inside a TEE enclave and can only be interacted with through programmable policies.
As a result, the key is completely secure and tamper-proof, with neither the end users nor the delegates nor the operators and developers ever having access to the keys.

So, when users try to sign with their keys, that is only possible when the signature request satisfies the policy conditions. Simply stated, the key never leaves the secure enclave, and the policy enforcement is end-to-end encrypted and processed only inside the enclave. Therefore, the assets linked to the key enjoy complete security and privacy, and can be moved, traded, shared, or pooled without on-chain exposure or tracking.

How It Works

The major question now is whether this is actually implementable. Short answer, yes.

The USP is adding programmable policies that must be passed before the key inside the TEE encrypts and signs the transaction on the target chain. Interestingly, this does not need a multisig solution, and a single entity can operate under multiple policy scopes.
As a practical application of this concept, Oasis has developed encumbrance-powered vault infrastructure for DeFi, bringing privacy, security, and ease of use together.

The architecture is simple, with a user interface where the application interacts with the functionality via an SDK. Any request or intent passes into the enclave, consisting of:

A policy engine
The encumbered key
A transaction executor

In this setup, the request encounters the policy engine that stores the policies in a confidential smart contract. If and when the request satisfies the policy conditions, the key signs and authorizes the request. In case the policy conditions are not met, the request fails, and there is no further action. Simply put, instead of the user accessing and potentially exposing the private key, the key remains inaccessible within the enclave, and only meeting the policy criteria triggers the smart contract to sign the transaction.

This system becomes particularly powerful when other chains are involved. Even though Oasis has its own network, users do not need to deposit the assets to Oasis, which simplifies interoperability. The assets are stored in a confidential container where the users can generate wallets for target chains and sign with them over programmable policies. So, the user assets stay where they are, while Oasis functions as the ultimate security layer.

Why Encumbrance? Why Not Multisig?

Multisigs have been useful for a long time, but come with limitations.

Every action lives on-chain
Users are locked to a single chain
No action is possible without coordination and a quorum
Enforcement needs a dedicated contract
Delegation entails adding/removing signers, which also requires authorized signatures

Key encumbrance does away with these limitations.

Adding or revoking access can be done by updating a policy. As the keys are never shared and truly private, the rules are enforced only through the policy engine.

The programmable policies are the definitive point of difference, making encumbrance a groundbreaking and powerful primitive for future utility and user convenience. In practice, these policies come with tangible capabilities and benefits.

Non-custodial automatic execution. If an asset's price threshold is breached, the enclave verifies with the policy condition, and the key signs a trade/sell. Neither manual approval is needed, nor is there a need for a bot with private key access.
Composable policy chains. Multi-chain functionality is in-built. So, profit from a sale or trading into a stablecoin can be routed to a different chain where it can earn passive yield - the entire process is maintained by using the policy engine without manual intervention or signing.
Scoped bot access. By adding policies to an encumbered key - it can be anything, such as assigning a dollar value threshold, specifying transactional time windows, or assets whitelisted with pre-set criteria, bot usage can be streamlined. Here, the bot will access the signature via an API without ever having key access.
Delegation without quorum. Policy access can be programmed to have an expiry date of 30 days. With no key sharing, and keys managed and enforced inside TEEs, no human coordination or quorum criteria are needed.
Session-based gaming. Application in gaming and related use cases where policy can pre-determine a threshold and time window, and handle signatures accordingly without needing to leave the game to approve transactions.

Final Takeaway

Current user experience in the blockchain and web3 space is riddled with poor key management and compromised access control. Encumbered keys make it possible for the next generation of applications to integrate programmability, privacy, and permissionless utility.
The proof of concept is already under development by Oasis using its own tech stack and primitives - private DeFi with Privana.

Further reading: Primitives by Oasis

How To Enhance Your App With Oasis ROFL: A QuickStart Tutorial

DC — Wed, 22 Apr 2026 14:34:03 +0000

I have mentioned the Oasis ROFL (runtime off-chain logic) framework on several occasions. For most people, this explainer video would be enough. But for developers and dApp builders, who want to try things out themselves, a deeper dive is worth it. In this guide, I will give a quick introduction to ROFL and then share a QuickStart tutorial to help build a ROFL-powered app.

ROFL in a nutshell

The ROFL architecture consists of these distinct components: the hardware, the application, the remote attestation, the blockchain layers, and user interaction.

Further, this 5-part process lays out how ROFL works.

From a developer's perspective, ROFL-powered apps run on Oasis nodes inside a Trusted Execution Environment (TEE), managed through the protocol's unique production-ready EVM runtime - Sapphire.

When you use ROFL, you get the following support:

Docker-like containers or single executable apps, based on what Trusted Compute Base (TCB) you are using, and what your threat model is
Intel SGX/TDX ensures privacy and integrity, and also provides a full update history and auditability
Your app is registered, managed, and deployed on a permissionless pool of ROFL nodes, which means it is not censorable
There is a built-in Key Management Service (KMS) that stores your app's secrets as well as secures key derivation inside the TEE
Verifiable ROFL transactions originating from integration with Oasis Sapphire that enable EVM-compatible confidential smart contracts

Moreover, you don't need to build from scratch - you can just wrap your existing app into a ROFL-powered app. Let's see how.

QuickStart

There are 5 steps to enhance an app with ROFL power:

Initialize the ROFL manifest
Create a new app on blockchain
Build a ROFL bundle
Encrypt secrets and store them on-chain
Deploy your app on a ROFL node

Prerequisites

Containerized App
First thing you need is a containerized app with a downloadable Docker-like image. Any public Open Container Initiative (OCI) repository works; however, you might like to choose from Docker or GitHub container registry.

If your app is not already running inside a container and you don't know how, follow this step-by-step mini tutorial.

Oasis CLI
Next, you need the latest version of the Oasis Command Line Interface (CLI). Install it from here.

Tokens
Lastly, you will need about 150 tokens to cover ROFL registration, renting a machine, and paying for the gas fees.

Now, you can either create a new account or import an existing one. Let's check out both processes.

Create a new account ->

oasis wallet create my_account --file.algorithm secp256k1-bip44

Later, you can choose to import this account to Metamask or other Ethereum-compatible tooling, e.g. Hardhat.

Import an existing account ->
You need to export the secp256k1 private key or mnemonic from your existing wallet before running this command:

oasis wallet import my_account

Note: If you are working in a test environment, you can get free testnet tokens from the official faucet.
If you are building on the mainnet, you will need to buy ROSE tokens.

Initialize

This is the first step. You start by running oasis rofl init using compose.yaml inside your app folder. This will generate the ROFL manifest in the form of rofl.yaml.

oasis rofl init

Now, based on your requirement, you can change the memory, specify the number of cpus, and the root filesystem storage section that comes under resources.
rofl.yaml

name: my-app
version: 0.1.0
tee: tdx
kind: container
resources:
  memory: 512 # in megabytes
  cpus: 1
  storage:
    kind: disk-persistent
    size: 512 # in megabytes
artifacts:
  firmware: https://github.com/oasisprotocol/oasis-boot/releases/download/v0.6.2/ovmf.tdx.fd#db47100a7d6a0c1f6983be224137c3f8d7cb09b63bb1c7a5ee7829d8e994a42f
  kernel: https://github.com/oasisprotocol/oasis-boot/releases/download/v0.6.2/stage1.bin#e5d4d654ca1fa2c388bf64b23fc6e67815893fc7cb8b7cfee253d87963f54973
  stage2: https://github.com/oasisprotocol/oasis-boot/releases/download/v0.6.2/stage2-podman.tar.bz2#b2ea2a0ca769b6b2d64e3f0c577ee9c08f0bb81a6e33ed5b15b2a7e50ef9a09f
  container:
    runtime: https://github.com/oasisprotocol/oasis-sdk/releases/download/rofl-containers%2Fv0.8.0/rofl-containers#08eb5bbe5df26af276d9a72e9fd7353b3a90b7d27e1cf33e276a82dfd551eec6
    compose: compose.yaml

Create

The next step is to create a new app on-chain. You can use the oasis rofl create command for this.
Please note that any newly created app in this process is registered by default on the Sapphire mainnet. If you are using a test environment, you will need to change the setting. So, you will be required to pass --network testnet parameter.

oasis rofl create --network testnet

The check whether this transaction was successful is to find your app on the Oasis Explorer.

Build

In this step, we will build the ROFL bundle.

oasis rofl build

This command results in the generation of a new .orc file inside your project folder.

Secrets

This is the step where privacy is enforced. So, if there are environment variables that your app is using, you can store them on-chain privately using the oasis rofl secret command. It would look like this:

echo -n "my-secret-token" | oasis rofl secret set TOKEN -

This command populates the TOKEN secret. You can now use it in your compose file like this:
compose.yaml

services:
  python-telegram-bot:
    build: .
    image: "ghcr.io/oasisprotocol/demo-rofl-tgbot:ollama"
    platform: linux/amd64
    environment:
      - TOKEN=${TOKEN}

If you want to submit the secrets and the ROFL bundle information on-chain, you can do so with the oasis rofl update command.

oasis rofl update

Deploy

This is the final step of the process. Here, you use the oasis rofl deploy command so that your app gets deployed to a ROFL provider.

oasis rofl deploy

The command triggers the bootstrapping of a new machine that fits the required resources provided by Oasis. You can check the status of the machine using the oasis rofl machine show command.

Oasis rofl machine show

You can now also check your application logs to verify how everything works. You will need the oasis rofl machine logs command for this.

oasis rofl machine logs

Parting words

If you are a developer who likes the hands-on approach, I hope you had a good time trying out this tutorial and successfully deploying your first ROFL-powered app.
You will note that in this guide, I have provided several links to the Oasis documentation instead of elaborating on them.

containerize your app
latest Oasis CLI release
oasis rofl init
oasis rofl create
oasis rofl secret
oasis rofl update
oasis rofl deploy
oasis rofl machine show
oasis rofl machine logs

That's because I wanted to focus on the topic here without going into details on these commands, which require separate attention, and I will prepare other tutorials explaining them later on.

For a quick chat with the Oasis engineering team for help with specific issues, you can drop your comments in the dev-central channel in the official Discord.

Need Truly Secure Digital Storage? The Answer Is Decentralized Storage + Privacy Layer

DC — Mon, 20 Apr 2026 10:42:08 +0000

As our digital footprints expand, our data floats around the internet, unsupervised and unprotected. Cloud storage is a practical solution, but it does not focus on data security. Moreover, you no longer truly own your data. This is the pain point that decentralized storage tries to tackle. But privacy is not automatic, even in decentralized systems. An intentional architecture with privacy-by-design is the only answer.

Defining Decentralized Storage

Traditional cloud storage uses location addressing. Here, the uploaded files, when they need to be accessed, can be retrieved from specific server URLs. In case of server outage or authorities implementing a takedown, the links stop working, and data becomes inaccessible, maybe lost forever. Now, some context: almost two-thirds of the global cloud infrastructure is currently handled by the Big 3 - AWS, Azure, and Google Cloud.

This data concentration is what decentralized storage evolved to solve. Here, the content of the files is identified by cryptographic hash generation. This is a unique digital identifier and, being decentralized, there is no dependence on a single server. All nodes in the system will always produce the same content, thereby securing the data and its integrity.

Top Decentralized Storage Protocols

All the protocols dealing with decentralized solutions have different approaches to digital storage. Let's take a look at the top 5 - IPFS (InterPlanetary File System), Filecoin, Arweave, Storj, and Sia.

IPFS - This is the earliest solution in the form of peer-to-peer (P2P) protocol. Every uploaded file is broken into blocks, cryptographically hashed, and organized into a Merkle DAG. These generate a unique Content Identifier (CID) for the file, which can be accessed thanks to any of the 20k+ active peers in the IPFS public network. However, this does not guarantee data perpetuity, as none of the nodes may commit to storing the file over time.
Filecoin - This tries to solve the problem of persisting data by rewarding the nodes. It adds an economic incentive layer to IPFS. Two cryptographic proofs enhance the system. Proof-of-Replication verifies the storage provider has created a unique physical copy of the data, while Proof-of-Spacetime then continuously audits the provider to verify that they still hold the data over time. Filecoin stores almost 1,110 PiB of data, with clients that include the Smithsonian Institution and the Internet Archive.
Arweave - This is the next-level solution. One-time payment funds a storage endowment that pays out to the storage providers gradually over 200 or more years, assuming a declining storage cost of at least 0.5% annually. Here, a "blockweave" structure links each new block to both the previous block and a randomly selected older block, incentivizing historical data storage. Arweave processes over 30 million transactions daily out of approximately 300 million data requests per day.
Storj and Sia - These specifically cater to privacy-oriented decentralized solutions. Storj encrypts all data with AES-256-GCM. It is then sharded into 80 pieces and distributed among independent nodes. Any 29 out of 80 pieces coming together retrieves the data. For Sia, the sharding is in 30 pieces, and reconstruction needs only 10 pieces, with on-chain smart contracts enforcing the model, and performance review maintaining host standards.

Centralized Systems Lack Privacy

Privacy failure is a constant threat in traditional cloud solutions, as the data handled in centralized data centres is huge and unwieldy, making it vulnerable to hackers and ripe for government tracking.

According to an IBM report, the global average breach cost, especially in cloud environments, is close to the $5 million mark. It slightly improved in the 2025 report, but healthcare continues to remain the top vulnerable sector, and breaches originating in the US alone crossed the $10 million mark.

Legally authorised surveillance, typically without users' knowledge, combined with the ease with which providers can censor or erase data, makes true ownership an illusion.

5 Layers of Privacy In Current Decentralized Systems

Decentralized storage that includes privacy mechanisms offers a solution to the problems posed by centralized systems.

Client-Side Encryption - Here, the data is encrypted in the user's device before being uploaded to the network. Storj and Sia do this automatically, but users of IPFS, Filecoin, or Arweave need to do it themselves. Centralized systems like AWS also encrypt data, but they own and hold the keys. Decentralized solutions give the key to the data owner upon encryption, which translates into no key, no data. But it also eliminates data loss through backdoor access.
Sharding - Here, the information in the encrypted files is split and shared across nodes in multiple locations. Individual hosts can view only the encrypted fragment stored with them. The data owner has sole access to the information, which is reconstructed together with the decryption key and the minimum number of fragments.
Erasure Coding - Here, the user data is secured through resilience and redundancy without storing complete copies. So, in the case of the Storj model, 51 nodes (63% of the shards) can go offline simultaneously, and still, data can be retrieved. It is more efficient than three-copy replication without adding to the storage overhead.
Encryption in Transit and at Rest - Here, Transport Layer Security (TLS) is used to protect the encrypted data as it moves between user devices and storage hosts. Encryption at rest also enhances data protection, so even if the physical device is stolen, the information remains unreadable. It is often combined with client-side encryption to ensure maximum data security.
Zero-Knowledge Proofs (ZKP) - ZKP enables the storage providers to prove data storage without revealing the data itself. For example, Filecoin uses Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge (zk-SNARKs) to cryptographically prove the presence of information without exposing the content.

Privacy Gaps That Privacy-Preserving Blockchains Solve

Decentralized storage without privacy-by-design is not truly secure, despite its advantages.

For example, IPFS, being the foundational protocol, is most at risk. Anyone who knows a CID can access the associated file. Besides, the CIDs, being deterministic, can be tracked.
Same problem with Filecoin, which also uses the IPFS model. In addition to the risk run by unencrypted files, it is vulnerable to traffic pattern analysis due to publicly available metadata.

Arweave's perpetual data storage has its own risk - immutability. Unencrypted data is exposed forever; encrypted data is only secure with current encryption standards and is breakable with future advancements in cryptography and quantum computing.

The answer lies in adding a privacy layer to the decentralized storage concept.
Result: users can enjoy cheap, persistent, censorship-resistant data hosting services, with the privacy layer managing encryption keys and authorization logic, and also providing access control in a confidential environment.

Oasis provides a unique and substantive solution, adding programmable privacy and access control policies to traditional decentralized storage.

Trusted Execution Environments (TEEs) ensure data is encrypted at both input and output states, and any decryption and processing happens only inside the protection of hardware-isolated secure enclaves. So, a confidential smart contract is applied to the storage and runs on Oasis Sapphire. The TEEs hold encryption keys and access policies in a private state. The decryption key is accessible only for authorized users who have been verified inside the enclave. This effectively rules out any interference from node operators, storage providers, or validators.

The access issue is handled by implementing the Liquefaction primitive. It is a level up from standard access control. Anyone can thus see access being granted or denied, but they will not know why. As a result, it is impossible to game the conditions and manipulate access.

Oasis is, however, not the only protocol that is working on a privacy-focused infrastructure. Lit Protocol also provides decentralized key management through threshold multi-party computation.

Here is how plugging the privacy gaps works.
First, implement client-side encryption using keys managed by a privacy layer.
Next, upload the encrypted data to a decentralized storage protocol.
Then, register the CID and key metadata inside a confidential smart contract with clearly defined access policies.
Finally, the result is a system where the privacy layer verifies and authorizes access requests inside a TEE or multi-party computation network.
Bottom line: Data is encrypted, on-chain but confidential, and access is controlled, so no data exposure even if anyone somehow procures the CID, thus mitigating the risk of a single point of failure.

Real-World Use Cases

NFT metadata - One of the first mainstream utilities. Solved broken hosting issues common to centralized servers. Case in point, in 2025, over 12k NFTs were delisted. Now, Solana’s Metaplex framework uses Arweave as the default storage option, benefiting over 10k NFTs. Also, Yuga Labs migrated Bored Ape Yacht Club (BAYC) metadata away from centralized cloud to IPFS.
AI and data infrastructure - The fastest growing segment. Filecoin’s Onchain Cloud launched as an official alternative to AWS for AI workloads. Also, Arweave’s AO hyper-parallel computing layer handles permanent data storage and computation of decentralized AI agents.
Healthcare - One of the highest stakes for private digital data storage. Examples include projects like BurstIQ, Medicalchain, and Patientory using IPFS for encrypted patient data storage and blockchains for access and audit purposes. Also, Estonia’s national healthcare system uses blockchain-based infrastructure for record integrity.
Financial data - Another high-stakes private digital data storage. Decentralized finance uses confidential computation and encrypted data for better privacy without needing a complete overhaul of existing architecture.

Final Takeaway

IPFS, Filecoin, and Arweave are better than traditional cloud systems in terms of censorship resistance, redundancy, and data integrity, and still, they are too public. Client-side encryption and sharding (Storj and Sia), ZKPs (Filecoin), and confidential access control (Oasis and Lit Protocol) provide viable privacy solutions for the future decentralized storage systems.

Decentralized storage holds the key to secure digital storage of the future. The solution is production-ready, and awareness is the only missing piece of the puzzle. So, next time you go looking for truly secure digital storage, you know which door to knock.

Agentic Economy With x402 Gets A Boost From ROFL's Verifiable, Private Compute Layer

DC — Mon, 23 Mar 2026 06:15:16 +0000

Autonomous AI agents can do a lot of things, but for a long time, internet-native payments were out of their purview. So, when I first learned about x402, I was intrigued by the possibilities. But the privacy-first blockchain, Oasis, raises an important question: Is the agentic economy adequately addressing verifiable privacy?

In this piece, I will explore x402, the value added by ERC-8004 in this context, as the standard for agent discovery, and the role Oasis's expertise in offering verifiable privacy with off-chain compute and on-chain trust can play.

x402 101

Let's start with some context. x402 is not a recent discovery related to web3 or AI. It pre-dates even the privacy narrative, going back to those days when the internet (also known as web2 in web3 terminology) was still using "HTTP" rather than "HTTPS". The code 402 simply designated 'payment required'.

The code was a stepping stone to internet-native payments, heralding a future in which servers could charge per request. But as long as online payment was not viable beyond theoretical discourse, this remained practically unused.

How does web3 fit in this conversation? The answer lies in what web3 made possible. Stablecoins, sub-second settlement, no chargebacks, and scalable blockchain protocols have become quite the norm. This is when HTTP 402 can evolve into x402. This ensures an open standard, enabling web2's request-response loop and allowing any service to charge for API or content access over HTTP.
Result: zero dependency on traditional accounts, sessions, or credentials.

It is interesting to note how awareness of x402 emerged in the cryptoAI space. It was triggered as a ERC-8004 utility. There is a close correlation between x402 and ERC-8004, enabling autonomous agents to trustlessly discover and transact. I will revisit this later.

x402 Functionality

So, how does x402 work? You start with a human/agent client, a server with the desired resource, and a facilitator (infra for payments). The following steps then unfold.

A request is made to a server, which could be anything, such as an API call or a piece of content
This resource needs to be paid for
The server responds with an HTTP 402 code
The code comes with payment instructions, specifying the token type, the amount, the network, and the destination address
The client-side wallet reads the 402 response and generates a signature authorizing the payment

The variation in this process would depend on whether the client is human or an agent.

If human, a pre-programmed policy in the wallet's smart contract can eliminate the need for manual signature steps.
If an agent, a pre-programmed policy in the wallet's smart contract can ensure that pre-set limits and rules are obeyed.

An overview of the process flow (source: https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works):

Key Takeaways

Signature uses the transferWithAuthorization function (EIP-3009). This means the client doesn't need to manage gas and private keys. This permission transaction, combined with a facilitator, enables seamless client sign-off on the transfer. Since anyone can submit it to the blockchain, the facilitator plays that role here.
The client's signed payment goes back to the server. There are a few steps before trust is established. First, the signature is forwarded to the facilitator's /verify endpoint. Then, the signature's legitimacy is authenticated. Next, the facilitator's /settle endpoint executes payment transfer. Finally, with all these steps complete, the server responds to the client's resource request.
This entire sequence of events occurs within a second or less with x402, ensuring smooth, composable payments. For the client, it is a simple HTTP code; for the agent, it is another API call.

x402 In Practice

Universal design -> seamless UI/UX. x402 uses HTTP's standard operating procedure (SOP). So, there is no need to add additional tools or software development kits (SDKs) when integrating with existing infrastructure.
Web2-native. Since x402 uses HTTP's SOP, it is also compatible with every major programming language, framework, and hosting platform on the internet. The seamlessness of web2 is thus replicated in web3.
Lightning-fast settlements. Payment authorization only involves a single request-response and is completed in sub-seconds. The settlement is asynchronous and has instant finality, with the server trusting the facilitator for on-chain execution.
Micropayments. Pricing granularity and tiny charges are made possible thanks to the zero-fee protocol and extremely low-cost transactions that only comprise of gas fees for the facilitator.

Traditional solutions are closed systems, needing constant customization every time the platforms or API providers change. This is exactly the pain point x402 solves.
Additionally, x402 enables micropayments, which were problematic earlier when everything would be bundled, by default, with subscriptions. Live example of the benefit includes pay-per-crawl APIs, where agents pay nano-payments to scrape content.

Another crucial advantage of x402 is understood when we consider how this protocol can logically extend its functionality with agents on both sides of the request-response pairing.
All this leads to setting up a new agentic future involving an autonomous agent economy. Consider this:

Agent 1 queries the data API, then hires Agent 2 to process the output, while paying a compute node to run simulations.
Zero human intervention needed at any stage of the process.
No restrictions by traditional payment rails.
Result: All transactions conditional (payment only when valid response) and composable, running at thousands of fractional payments per minute/hour.

x402 x ERC-8004 x ROFL

The potential of x402 grows when integrated with other crypto primitives.

As I mentioned earlier, x402 and ERC-8004 share a connection. X402 standardizes agentic payment, and ERC-8004 standardizes agentic discovery and introduces the need-for-trust factor. This is a critical factor we need to examine, as the data is exposed no matter what, whenever there is API access or inference.

The agentic trust gap is solvable.

We know that ERC-8004 gives us the agent coordination/discovery layer, involving on-chain registries for identity, reputation, and validation, but it is neutral about establishing trust. The solution comes from the Oasis ROFL (runtime off-chain logic) framework for trustless compute, providing data privacy, decentralized key management, and verifiable, tamper-proof execution.
Together, the setup ensures code verification, key isolation, and end-to-end confidentiality.

As we have seen in this x402 discussion, the facilitators play an important role. ROFL offers the opportunity to move away from highly centralized and opaque facilitators to a decentralized trustless TEE cloud for running the x402 facilitator. This can ensure that the payment layer is decentralized and verifiable even as the entire stack operates without extra, unnecessary trust assumptions.

Check out this example of a live public testnet deployment of a trustless and verifiable facilitator. There is also a sample implementation including a document summarization service that runs Ollama inference inside an ROFL container. And then there is a demo using multiple LLM models with cross-validation for oracle consensus. All of these being open-source, anyone can replicate or tweak for further developments.

So, what is the final takeaway? x402, ERC-8004, and Oasis ROFL each solve a distinct layer of the agentic stack. Together, they make a trustless, private, composable agent economy not just conceivable but ready to be developed.