DEV Community: DC

Your Guide to the Prerequisites for Running Nodes on Oasis (Part 2): Stake Requirements and Node Installation

DC — Wed, 28 Oct 2026 10:27:29 +0000

Before you can run a node for a blockchain protocol, there are several things to prepare. In this 4-part series, I discuss the prerequisites for running nodes on Oasis in detail. In part 1, we learned about hardware and cloud providers. Here, I will cover stake requirements and how to install the Oasis Node.

Stake Requirements

Based on your node role and whether you are on the mainnet or the testnet, you need to keep in mind the following requirements.

Registration of entity
Mainnet: 100 ROSE
Testnet: 100 TEST
Note: To get the latest entity registration requirement, you will need to run the command oasis network show native-token.
Registration of node
Mainnet: 100 ROSE
Testnet: 100 TEST
Size of the validator set
Mainnet: 120
Testnet: 110
Notes: The validator set is the consensus committee, and its size is capped by the max_validators committee-scheduler parameter. To view the current value, you will need to run the command oasis network show parameters.
For mainnet, to find out whether you are eligible to receive a delegation from the Oasis Protocol Foundation, check out the Delegation Policy.
For testnet, the faucet generates only a limited number of TEST tokens. If you need more, you will need to contact the team on the official Discord in the testnet channel.
Run a Sapphire or Emerald compute node
Mainnet: 5,000,000 ROSE + member of the validator set
Run a Cipher compute node
Mainnet: member of the validator set

Notes: The docs list no separate testnet figures.
To get the latest paratime-specific stake requirements, you will need to run the command oasis network show and specify the paratime ID for mainnet.
To know who the current top validators are, you can do that either with Oasis Explorer or with the CLI command oasis network show validators.

As mentioned, requirements vary according to your choice of node role. Here is a snapshot of the role-specific steps to set up a working node from scratch.

Note: There are no specific requirements for non-validator nodes.

To check whether you meet the requirements for your node role, you will first need to view the balance of your account. You can do that either with Oasis Explorer or with the CLI command oasis account show.

Installing the Oasis Node

The Oasis Node is a binary created from the Oasis Core repository's go/ directory. It is a single executable and contains the logic for running your node in various roles. Currently, the Oasis Node is only supported on x86_64 Linux systems.

Setting up the working directory

You need a place to store necessary files before installing the Oasis Node, so that is the first step. In this guide, /node refers to the working directory.

In the /node directory, start by creating the following subdirectories to allocate specific storage roles.

etc/: configuration and entity.json
data/: node's data
bin/: oasis-node binary
runtimes/: paratime .orc bundles

To establish the directory structure along with the corresponding permissions, you will need to execute this command.

mkdir -m700 -p /node/{etc,bin,runtimes,data}

Note: Creating directories under / usually requires root privileges. Make sure the account that will run the node owns /node afterwards, since the 700 permissions give access to the owner only.

Copying the Genesis file

You can find the latest Genesis file for mainnet and testnet as part of the network parameters. The next step involves downloading the latest genesis.json file and copying it to /node/etc/genesis.json on the server.

Once done, you can now get the oasis-node Binary.

Downloading a binary release

The Oasis Protocol Foundation builds and provides the binaries. Since the Oasis Node is part of the Oasis Core release, start by finding the network parameters linked earlier for the respective mainnet and testnet. Next, follow the Oasis Core version link to its GitHub release, where the downloads are listed under Assets.

Building from source

Building from source is highly suggested, but the Oasis documentation currently treats it as beyond its scope. You will need to check out Oasis Core's Build Environment Setup and Building documentation for more details.
Note: The code in the current master branch may be incompatible with the code used by other nodes on the network. It is thus essential that you use the version specified in the network parameters linked earlier for the respective mainnet and testnet.

Adding oasis-node binary to PATH

If you are installing the oasis-node binary next to your Oasis Node data directory, you will need to copy/symlink it to /node/bin. Now, if you are installing the binary for the current user, the copy/symlink needs to be to ~/.local/bin. To install it for all users of the system, you have to copy it to /usr/local/bin.

Running paratimes

This is applicable only if you are running a paratime node. You will then need to install some additional software packages.

You will need Bubblewrap 0.4.1+ to create process sandboxes.
On Ubuntu 20.04+, you can install it with this command.

sudo apt install bubblewrap

For Fedora, use this command instead.

sudo dnf install bubblewrap

This concludes part 2 of the prerequisites series. In the next part, I will discuss system configuration.

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 and other node operators are available in the node-operators channel on the official Discord.

Your Guide to the Prerequisites for Running Nodes on Oasis (Part 1): Hardware and Cloud Providers

DC — Wed, 28 Oct 2026 06:34:53 +0000

There are various ways to support a blockchain protocol. For example, tech-savvy users sometimes prefer to run nodes. Now, if you are planning to do so, specific hardware and software prerequisites must be in place. In this 4-part series, I will discuss them in detail for running nodes on Oasis. The first part covers hardware and cloud providers.

Hardware Requirements

As outlined in the introduction to Oasis nodes, the protocol consists of several distinct node types.

Consensus validator or non-validator node
Sapphire compute or client node
Emerald compute or client node
Cipher compute or client node

In this section, I will focus on the minimum and recommended system hardware requirements. Anyone planning to run more than one paratime (Sapphire/Emerald/Cipher) on a single node will need more resources.

If you configure a system with fewer resources than recommended, you run the risk of being under-provisioned. This can cause proposer node timeouts and synchronization delays. If your node exhausts its memory or storage, the node process is forcefully killed, which can result in state corruption. As a result, you risk losing stake and getting barred from participating in committees.

CPUs

Consensus validator or non-validator node

Minimum: 2.0 GHz x86-64 CPU with AES instruction set support
Recommended: 2.0 GHz x86-64 CPU with 2 cores/vCPUs with AES instruction set and Advanced Vector Extensions 2 (AVX2) support

Emerald compute node and all client nodes

Minimum: same as above
Recommended: 2.0 GHz x86-64 CPU with 4 cores/vCPUs with AES instruction set and AVX2 support

Sapphire/Cipher ParaTime compute node

Minimum: 2.0 GHz x86-64 CPU with AES instruction set and Intel SGX support
Recommended: 2.0 GHz x86-64 CPU with 2 cores/vCPUs with AES instruction set, Intel SGX, and AVX2 support

Notes:

If you are running regular workloads on your node, the minimum resources will suffice. However, if you plan heavier workloads, like a paratime client node behind a public Web3 gateway, you will need more cores/vCPUs.
The reason you need AES instruction set support is that it is required by Deoxys-II-256-128, a Misuse-Resistant Authenticated Encryption (MRAE) algorithm, for encrypting paratime state.
The reason you need AVX2 support is to enable faster Ed25519 signature verification. This will speed up node sync.
You need Intel SGX support only when you are running paratime compute nodes (Sapphire/Cipher). Check out Intel's comprehensive list of processors that support Intel SGX, and match it with Sapphire and Cipher requirements before proceeding.

Memory

Consensus validator or non-validator node

Minimum: 6 GB of ECC RAM
Recommended: 8 GB of ECC RAM

Each Emerald/Sapphire/Cipher compute or client node

Minimum: 12 GB of ECC RAM
Recommended: 20 GB of ECC RAM

In most scenarios, the nodes, even with less than the minimum amount of memory, will run regular workloads smoothly. To cover the more resource-intensive time points, such as the initial state sync, BadgerDB migration when upgrading a node to a new major version of the Oasis Core, generating storage checkpoints with BadgerDB, and periodic BadgerDB compactions, your nodes will need more memory than usual.

Storage

Consensus validator or non-validator node

Minimum: 400 GB of SSD or NVMe fast storage
Recommended: 700 GB of SSD or NVMe fast storage

Emerald compute or client node (in addition to the consensus storage requirements)

Minimum: 400 GB of SSD or NVMe fast storage
Recommended: 700 GB of SSD or NVMe fast storage

Sapphire/Cipher compute or client node (in addition to the consensus storage requirements)

Minimum: 200 GB of SSD or NVMe fast storage
Recommended: 300 GB of SSD or NVMe fast storage

Notes:

Both consensus and paratime states are stored in an embedded BadgerDB database. As BadgerDB is designed to run on SSDs, it is highly recommended not to run a node that stores data on HDDs.
Both consensus and paratime states accumulate over time. The rate of storage growth varies by transaction count on the network and the paratimes. For example, a consensus non-validator node on the mainnet accumulated 280 GB of consensus state in approximately one year since the Cobalt upgrade, and 32 GB of consensus state in approximately one month since the Damask upgrade. Another example would be an Emerald client node on the mainnet, which additionally accumulated 260 GB of paratime state in approximately five months since Emerald's launch, and 25 GB of paratime state in approximately one month since the Damask upgrade.
Dump and restore upgrades, such as the Damask and Cobalt upgrades, include state wipes that free up node storage. If you need to access historical state, you can run a separate archive node. Also note, the latest is Eden
It is recommended not to keep a complete state from the genesis onward unless you are running a node to preserve historical state. This will also reduce storage requirements for both consensus and paratime states, as well as improve the overall latency of the storage-related operations. To enable storage reduction, you should check out consensus pruning and paratime pruning.

Network

Consensus validator node and all paratime compute nodes

Minimum: 200 Mbps internet connection with low latency
Recommended: 1 Gbps internet connection with low latency

Regular workloads use relatively little traffic. The higher bandwidth is recommended for bursts of transactions, when a node with too little bandwidth can time out.

Cloud Providers

If you plan to run a Sapphire or Cipher compute node, a crucial step is verifying processor compatibility and checking the status of Intel SGX support (refer to Note #4 in the CPUs section).

Limitations

You will come across several bare-metal or dedicated server providers using Intel processors that support SGX. However, you should also be aware of potential limitations.

BIOS configuration: Some providers restrict users from accessing or modifying BIOS settings, which might be essential to correctly configure Intel SGX.
Outdated firmware: SGX requires the latest firmware to function correctly. If the system provider is behind on updates, this is a problem.
Lack of SGX-specific offerings: Some providers do not advertise or specifically offer SGX-enabled servers. Users need to know specifically that their server is SGX-enabled, as this feature is non-negotiable for running some Oasis nodes.
Limited support: Sometimes even when an SGX-enabled server is available, the provider's support team might lack the expertise to handle SGX-specific issues or configurations.
Hardware provisioning: Use of keys, such as SGX sealing keys, involves them being bound to hardware to encrypt the data of an instance within an Intel SGX enclave. If the host of the instance is changed, the encrypted data cannot be decrypted.

Known providers

Alibaba Cloud
Product: (ECS) Bare Metal Instances
Documentation: Build an SGX confidential computing environment
Azure
Product: Some Dedicated Host SKUs
Documentation: Solutions on Azure for Intel SGX
Gcore
Product: Bare Metal
Documentation: Computing with Intel SGX
IBM Cloud
Product: Virtual Private Cloud (VPC)
Documentation: Confidential computing with SGX for VPC
OVH
Product: Bare Metal servers
Documentation: SGX for Confidential Computing
PhoenixNAP
Product: Bare Metal Cloud
Documentation: What is Intel SGX and What are the Benefits?
Vultr
Product: Bare Metal
Documentation: Intel SGX development on Vultr

Note: Provider offerings change, so the list above may not reflect each provider's current SGX support. So, it is recommended to check out the provider's own documentation and confirm Intel SGX availability with them directly.
If any cloud or dedicated server providers that actively support Intel SGX or Intel TDX are not in this list, or if you come across updated information about the providers listed above, you can let the Oasis team know by creating an issue on GitHub with the additional details.

This concludes part 1 of the prerequisites series. In the next part, I will discuss stake requirements and how to install the Oasis node.

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 and other node operators are available in the node-operators channel on the official Discord.

Introducing Privana: A Deep Dive into Underlying Technology

DC — Tue, 27 Oct 2026 12:36:43 +0000

In the world of privacy-first decentralized finance (DeFi), the upcoming Privana, built by and on Oasis, proposes a unique solution that deserves a deep dive. In the first part of this exploratory series, I detailed the core concepts of this private DeFi application. In this part, we will go deeper and look into the underlying technology that makes Privana tick.

Oasis Sapphire and ROFL

In the core concepts, Sapphire was mentioned several times, but why is this such an integral part of the technology that drives Privana? How does the Runtime Off-chain Logic (ROFL) framework fit in? The scope of Privana's functionality depends on both on-chain and off-chain components running in attested Trusted Execution Environments (TEEs).

As the confidential EVM runtime, Sapphire utilizes Intel SGX enclaves to ensure smart contract logic and its state are confidential by default. As a result, transactions and contract storage are encrypted, while validators and node operators, even though they are crucial to running the network, cannot access or alter them.

Running Privana's on-chain functionalities with Sapphire has advantages that underpin the application's privacy and security.

EVM Compatibility

Sapphire is EVM-compatible, so the smart contracts are written in Solidity. There is no need for prior or specialized TEE knowledge, and the confidential smart contracts can be independently audited, as the code is public. Anyone can thus verify whether the on-chain logic functions as claimed.

Confidential State

This is a critical property of Sapphire, as the encrypted contract storage stays on-chain and in memory. It guarantees that the state is accessible only to the executing TEE. This means that user balances, policies, and trade history are and remain private.

The diagram shows how each contract is encrypted with its own key, held by an isolated Key Manager. However, as it states, node operators are still able to view the access patterns.

Cross-chain signing

The core concepts highlight Privana as a multi-chain application. The architecture of Sapphire can help us understand how an EVM blockchain manages this.

A Sapphire contract holds the private key inside the enclave and signs cross-chain transactions on Oasis itself. The key thus never leaves the enclave, and the contract logic that decides what to sign remains confidential. So, the destination chain can only see the finished transaction, a regularly signed transaction made from the application's pooled vault address. As a result, there is no way to link the transaction back to the users.

ROFL

The chain-agnostic nature of Privana's vaults and the off-chain execution of application logic come from ROFL TEEs, attested on-chain by Oasis Sapphire. The application's functionalities that run inside a ROFL container are executed in an off-chain, attested, TEE-secured setting. In the subsequent stage, Sapphire verifies whether the EVM transactions originate from that specific ROFL instance.

In short, Sapphire holds the keys and handles accounting and signing, while the Privana service, running in ROFL, handles deposit verification, swaps, yield, and broadcasting.

Privana's Architecture

While discussing the core concepts of Privana, we briefly touched on the architecture. Let's look at it now in more detail.

There are five components. Integrators build with the Privana SDK, which then calls the service via the REST API. This service sits at the center of everything: it reads and writes the Oasis Sapphire contracts, which hold the keys and sign transactions confidentially, and it verifies and settles transactions on external chains, where deposits and pooled vaults sit.

Accounting block

Accounting here is the confidential ledger. The contract stays on Sapphire and holds a mapping of deposit addresses to asset balances. This is entirely encrypted. The Privana service maintains this system with various functions:

processing deposits on each source chain
ensuring balance change management works smoothly
implementing the Know Your Transaction (KYT) routine by screening transactions
validating balances before any trades can take place
ensuring finality reconciliation once execution has gone through
handling withdrawals taking place in all the supported chains

Microservices block

Microservices implement the execution logic for DeFi operations. Privana has two microservices: swaps and yield. These will be covered in detail later. Moreover, there is room to add new ones going forward if Privana decides to diversify its services in perpetuals or lending. This is possible because the core accounting logic stays the same for all microservices as they settle against the same wallet balance, using the same signature path.

Remote attestation

TEEs being the privacy-preserving core of both Sapphire (SGX) and ROFL (TDX), understanding how remote attestations work in Privana is important. The attestation reports are signed by Intel's hardware root of trust. As a result, anyone can remotely verify that the enclave is running exactly the code it claims to run.

The beauty of this verification engine is that it is all-encompassing, providing robust, in-depth auditability that regular audits could have missed. It covers the on-chain contracts, the off-chain Privana service, as well as the microservices running in attested ROFL containers. This means it is also possible to verify the swap and yield logic being executed by the application.

Not limited to DeFi

One of the core architectural strengths of Privana is that its SDK is composable. So, while Privana acts as the face of private DeFi, the applicability goes beyond it. As a result, any dApp that involves private balances or scoped, time-bounded access can use the underlying architecture of the vaults.

Fallback & Recovery

For the end users, there is a nagging question about any services, especially web3-related ones such as DeFi, given the crypto space has yet to achieve significant mass adoption. So, what happens if the enclave goes offline permanently, or if Privana stops its application and service?

A USP of Privana's architecture is that it has built-in fallback and recovery safeguards. This is not a run-of-the-mill service-level promise; it is embedded in the system and guaranteed by Oasis Sapphire.

As mentioned, Sapphire runs and executes the Accounting contract, which means it is not dependent on Privana's off-chain service. Since the contract state is on-chain, even if Privana's application and service go offline, the exit option remains open. Let's see how this works.

On-chain withdrawal

The Accounting contract allows two withdrawal paths independent of the downtime of the off-chain service in the ROFL container.

User balance: The user can submit a withdrawal request signed by their wallet. The contract will return a signed transaction after a short time lapse on-chain. This results in the transaction paying out the user to their own address on the source chain. Anyone can broadcast it for the user, which also minimizes the risk of the funds being lost or stolen.
Funds in user deposit address: This method is initiated if a deposit was never swept into the vault. The user can then call the contract directly to recover it. Following a short time lapse on-chain, the contract will return a signed transaction, the same as the first method. The difference here is that, in this case, the user can specify the destination in that call and will accordingly receive the payout.

The important aspect of both these methods is that the payout address is specified before the transaction is signed. So, it is fixed permanently, and even if there is an untrusted broadcaster, the funds will only route to the designated address.

Beyond service outage

A service outage is the easier case, since Sapphire stays live and the withdrawal paths above still work. A more serious scenario, like a permanently lost enclave, is where Privana's recovery model, informed by the sentinel-wallet design, comes into play.

Liquefaction, whose role in Privana is described later, outlines operator-independent recovery so that asset owners can reclaim control of their funds without needing to trust any single party. This is reassuring: user assets are not designed to be permanently lockable.

Trust Model

We glanced over this while discussing Privana's core concepts. Let's explore more here.

No system is or can ever be absolutely trustless. Privana is built using technology that minimizes trust requirements as much as possible, but some assumptions still remain.

Note from the table screenshot:

Research Basis: next section
Sapphire docs

Two risks cannot be eliminated for Privana, even with the best of preparedness.

Vulnerabilities in the TEE hardware itself, whether Intel SGX or TDX. This is inherent for all TEE platforms, although Sapphire, using SGX technology, has various mitigation steps added in the form of defense-in-depth design. Sapphire's SGX TEE resilience was demonstrated by its withstanding TEE attacks by Battering RAM and Wiretap.
Smart contract bugs in the external yield protocols that the user might choose to interact with.

Privana approaches this by mitigating potential fallout through conservative platform selection, audits, and protocol vetting.

Complete Knowledge proofs

Liquefaction is one of the crucial technologies on which Privana stands, as it introduces key encumbrance. The Liquefaction framework also discusses Complete Knowledge (CK) proofs, which are cryptographic proofs that a user has unencumbered access to a private key. They could become a valuable complement to Privana, for example, by letting centralized exchanges verify that a depositor's keys are not encumbered.

Research Basis

The groundwork behind Privana's architecture and technology is laid down by cryptographic research from Cornell Tech. Recommended reading starts with the Liquefaction paper as the primary research basis.

This paper introduces key encumbrance as the core primitive, demonstrating that TEE-based key encumbrance can break the Single-Entity Address-Ownership (SEAO) assumption. Let's now look at the four cornerstones of the research that help to understand how the Liquefaction framework is implemented by Oasis in Privana.

Key Encumbrance: Generating a private key and securely holding it inside a TEE, governed by programmable access-control policies, enabling automation without custody transfer.
SEAO Assumption: Challenging the assumption that one blockchain address can only be controlled by a single entity.
Asset-Time Segmentation: Implementing exclusive asset control by one sub-policy at any given time, thereby ensuring multiple policies don't end up competing amongst themselves, which could result in deadlock and double-spend.
Overlay Smart Contracts: Applying smart-contract-like logic to chains, such as Bitcoin, Litecoin, Dogecoin, etc., that don't support native smart contracts as an extension of the encumbered keys being managed off-chain in TEEs.

For interested readers, there are several references available in addition to the Liquefaction paper, if they want to do their own research on the security model.

Kelkar et al. on Complete Knowledge proofs (ACM CCS, 2024)
Jean-Louis et al. on privacy flaws in TEE-based platforms (ePrint 2023/378)
Van Schaik et al. on SGX security (IEEE S&P, 2024)

Integrations

The components of Privana are assembled from public, auditable infrastructure, chosen because of their popular adoption and independent operation.

These are the live integrations as of now. If any services become unavailable, they can be replaced by similar services with the same interface.

This concludes the deep dive into Privana’s underlying technology. Next time, I will discuss Privana’s features in detail. In the meantime, let’s continue the discussion in the comments section about what you think of these technological components that are the basis of Privana’s build.

Resources & references:

Privana
Oasis
For specific questions or feedback, connect on the Privana channel** on the official Discord.

Your Guide to the Nodes You Can Run on Oasis

DC — Thu, 24 Sep 2026 07:22:24 +0000

Tech-savvy users can get more involved in a blockchain protocol than the general community usually does - by running nodes that boost the network's security, robustness, diversity, and decentralization. In this guide, I will introduce the various types of nodes you can run on Oasis, with an overview of the distinctive roles they play in the protocol.

Validator Node

Oasis is a proof-of-stake (PoS) protocol, which makes the validator node the single most critical component of the network. If you are running such a node, your responsibilities will range from verifying transactions to proposing new blocks to be added to the blockchain.

Since Oasis has a modular architecture separating the consensus and the execution layers, where this node operates is an important indicator of its role in the network. Operating from the consensus layer, the validator node functions by staking the network's native token, ROSE. When you run this node, you participate in the consensus process by validating transactions, signing blocks, and ensuring the integrity of the blockchain.

Compute Nodes

As mentioned, the execution layer is separate in Oasis's architecture, and there are multiple parallel runtime instances possible, known as paratimes. So, compute nodes are those that participate in executing smart contracts and processing related transactions in the network.

If you are running such a node, your responsibilities will include handling computations, running decentralized applications (dApps), data processing, and executing privacy-preserving smart contracts.

Currently, there are three types of compute nodes on Oasis, based on operational paratimes.

Sapphire Compute Node - If you are running this node, you are helping execute privacy-preserving smart contracts and process transactions on Oasis's confidential EVM runtime, Sapphire. This type of node is crucial to maintaining the confidentiality of sensitive data that is run through trusted execution environments (TEEs). As a result, data remains encrypted and confidential while being processed, and enhanced security is enabled throughout.
Cipher Compute Node - Its role and functionality are the same as Sapphire, with only one exception: it is run on Oasis's WASM runtime, Cipher.
Emerald Compute Node - This pertains to Oasis's original, non-confidential EVM runtime, Emerald. The function of this node is limited to executing smart contracts, validating transactions, and other operations within the paratime. There is no privacy-preserving component here.

Client Nodes

The role of a client node is to enable an interface for users or other applications to interact with the network.

It is functionally different from compute nodes. If you are running such a node, your responsibilities will include performing blockchain queries, submitting transactions, and retrieving other data from the network.

There are half a dozen different types of client nodes on Oasis that you can run at the moment.

Non-Validator Node - This type of client node supports network operations and decentralization instead of taking part in the consensus process of validating and proposing new blocks.
Sapphire Client Node - This type of client node interacts specifically with the Sapphire runtime and its EVM-compatible privacy functionality.
Cipher Client Node - This type of client node interacts specifically with the Cipher runtime and its WASM-compatible privacy functionality.
ROFL Node - It is a specialized Sapphire client node that supports TEEs and can host ROFL apps integrating the runtime off-chain logic (ROFL) framework.
Observer Node - It is a specialized client node for confidential paratimes like Sapphire and Cipher. So, if you run this node, you help with confidential smart contract queries.
Stateless Node - It is a specialized client node that can operate without maintaining state, enabling instant bootstrapping, which makes it valuable for ROFL development.

Archive Node & Seed Node

These are a couple of specialized nodes on Oasis. The archive node stores the entire blockchain history. This is a critical function for in-depth analysis and development of the protocol, where you help ensure that all the past iterations of the network state remain accessible.

The seed node is like an address book for the network. By running this node, you ensure crucial support for other nodes so that they can discover peers and join the network. Like the non-validator node, it has no part to play in the consensus process.

Key Manager Node

Decentralized key management is an essential primitive on Oasis. This makes the Key Manager Node a highly specialized node on the network.

If you are running such a node, your responsibilities center around securely managing cryptographic keys used in confidential computing. As a result, the node becomes vital for the network's secure, decentralized, and privacy-focused operations. It helps maintain the myriad privacy-preserving features as well as ensure secure encryption and decryption of data processed within the TEEs.

Services

Sometimes the nodes you run come with optional add-on services or interface layers sitting on top of the nodes. Let's look at the services that you can bundle with your nodes.

Rosetta Gateway

The Rosetta Gateway is a specialized service that connects to a non-validator node. It implements the Rosetta API and provides a simplified, standardized interface to interact with the blockchain. If you opt for this service, it will ease the integration between Oasis and various external platforms, including exchanges, wallets, custodians, and blockchain-based applications.

Public gRPC

As a specialized service, this is a helpful management tool for developers that is not scoped to any single node type. The Oasis gRPC protocol provides an efficient, real-time, and cross-platform communication channel between the Oasis node and the network. As each node opens a gRPC socket, the public endpoints run a proxy exposing a small, safe subset of that API publicly. It thus acts as a filtering layer standing guard on what the node's raw gRPC socket would otherwise expose.

Web3 Gateway

The Web3 Gateway is a specialized service that connects to a compute or a client node with EVM compatibility. It interacts with Oasis via the standard Web3 protocol, thereby opening a bridge to external Web3-based applications. It enables developers to access and leverage the tools, libraries, and practices in line with Ethereum development while also benefiting from Oasis's features and functionalities of privacy and confidential computation.

This concludes the overview of the nodes you can run on Oasis. It is by no means comprehensive, as the prerequisites and the steps to run the nodes are too detailed to include here. So, I will follow this up with subsequent guides that cover them in the detail they warrant. Stay tuned.

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 and other node operators are available in the node-operators channel on the official Discord.

Introducing Privana: A Deep Dive into Core Concepts

DC — Mon, 21 Sep 2026 08:55:40 +0000

Privacy in blockchain and web3 is not a default setting. Because privacy must be designed in, decentralized applications (dApps), including decentralized finance (DeFi) solutions, often lack it. As a private, non-custodial DeFi interface, Privana aims to answer this need.

Built by the Oasis team, Privana runs on Sapphire’s confidential EVM runtime inside hardware-secured enclaves, better known as Trusted Execution Environments (TEEs). This setup enables the features of privacy, automation, and self-custody to coexist without trade-offs.

Before understanding in detail the core concepts behind Privana, it is useful to examine the privacy problem and how it is intended to be solved.

Finding the missing piece of the privacy puzzle

What users can do with Privana underscores this application's privacy-first commitment: swap tokens, earn yield on stablecoins, and automate trading strategies. At the same time, users have self-custody, and none of their activities are revealed on-chain. This is in contrast to any standard decentralized exchange (DEX), where trades are always public; transactions are visible to anyone, including bots, who can also intervene with sandwich attacks and front-running; and full transparency dictates that user wallet history is always accessible. Privana is designed to solve these problems.

Privana and Oasis combine to deliver the application’s multi-chain feature while maintaining the privacy setup.

Each layer has to play only its own part. Oasis takes on the responsibility for privacy and security with Sapphire's confidential smart contracts and encrypted contract storage. The external chains just enjoy the benefits, and they only see what they need to – signed transactions in final state. Privana’s contribution is the user interface: wallet connection, asset deposit, execution of swaps, rule setup for automation, and portfolio management.

It is crucial that privacy and security guarantees come from Oasis rather than from Privana because the assurances are backed by core hardware and blockchain levels instead of merely the application level.

An overview of Privana’s core functionality

Privana's core functionality can be stated in a single sentence. It operates pooled, policy-governed vaults that hold assets inside hardware enclaves and execute DeFi actions privately. Let’s see how this tracks.

Pooled vault model

When users deposit tokens in Privana, the funds are kept in a vault, a smart contract on Oasis Sapphire inside an Intel SGX enclave (more on this, rather than in individual wallets as usual. This model moves away from the system of individual wallet users holding their private keys and instead uses a single vault per chain to hold assets for multiple users. The obvious next question is how individual token holdings are then managed. The answer lies in a confidential accounting layer tracking the user balances. This layer is a set of encrypted smart contracts that privately map and maintain individual token holdings.

This design choice is deliberate and comes with several benefits.
• Privacy amplification – Every transaction originating from Privana has the same address – that of its pooled vault. Since any user’s personal wallet activity is not broadcast, no specific trade can be attributed to a specific person.
• Liquidity efficiency – The Privana vaults hold an inventory of commonly traded assets. As a result, internal liquidity can settle user trades instantly within the vault, eliminating the need for external transactions. This also augments privacy while being fast and cheap.
• Lower costs – Being a pooled model, there is no need for individual smart contracts for the users. This results in low complexity of the application, lower gas fees, and higher cost-efficiency.

The confidential accounting layer in Privana’s pooled vault model is unique to DeFi solutions but follows the same logic as traditional institutions where, for example, users keeping their gold would all be stored in a single secure vault while the ledger records will maintain individual holdings. Privana’s use of this accounting layer thus serves 4 purposes.

• When users deposit their tokens, this system verifies the deposit on the source chain and registers it to the balance in the user's name in the confidential ledger.

• When users initiate a trade or yield activity, the system does a quick balance check for fund sufficiency before processing any transactions.

• For every incoming deposit, the system runs Know Your Transaction (KYT) checks to verify that funds don’t originate from sanctioned sources. This filter is a compliance mechanism adding another layer of security to the vault without compromising its privacy mandate.

• After every successful trade execution, there is immediate balance reconciliation so that the latest state of the user's holdings remains updated in vault records.

A great advantage of Privana’s vaults is that they are chain-agnostic. The keys stay and run inside TEEs, while from the target blockchain's perspective, all logic is enforced off-chain. So, even a network like Bitcoin, without native smart contract support, can benefit from the model.

The three pillars of Privana’s core concepts

TEEs, key encumbrance, and the non-custodial model encapsulate the core concepts behind Privana’s build, so it is important to delve a little deeper into each of them.

TEEs

TEEs sit at the center of Privana's privacy and security architecture. It is hardware running code inside, like a locked room enforcing rules so that no one can view, access, or modify what’s inside. It keeps everybody out, even the operating system and the server operator. As mentioned before, for Privana, this locked room is an Intel SGX enclave on Oasis Sapphire.

The TEE protects vault keys, user balances, policy rules, and transaction history. Everything stays encrypted within the TEE, only gets decrypted during the duration of processing, and is re-encrypted when processing is complete.

There is never any exposure to external systems. So, the TEE prevents access to or reading of private keys or any attempts to bypass user policies. Moreover, no unauthorized transactions can get through or get signed. Not even an engineer with full server access can extract or alter what is inside the enclave.

Most users will be satisfied with guarantees, but anyone who is tech-savvy and wants to verify for themselves can use remote attestation to check that the code running inside the enclave is the one that was promised and whether it is really untampered.

From an applicability point of view, enterprise custody platforms often utilize TEEs for institutional users. Privana aims to provide the same security model for DeFi users.

Key encumbrance

In a standard wallet, users must manually approve every transaction by signing with their private keys, which increases the risk of exposure or compromise. With key encumbrance, users can pre-define rules and let automation take care of the rest. This is the practical application of the concept laid down in the Liquefaction research paper by Austgen et al. at Cornell Tech.

Key encumbrance thus lets the enclave execute on the user's behalf, bound or encumbered by user-defined policy that can be updated or revoked at any time at the user’s discretion.

Take this example.

// Example policy: delegate yield routing, keep direct swap control
{
  asset:            "USDC",
  spend_limit:      1000 USDC/day,    // max automated spend
  destination_lock: ["aave-v3"],      // only this protocol
  expires:          30 days,          // time-bound — auto-expires
  revocable:        true              // you can always cancel
}

// The enclave enforces these limits in hardware.
// No one — including Privana — can execute outside these rules.

Privana takes key encumbrance utility forward by introducing the principle of asset-time segmentation. It means that at any given time, only a single entity can exclusively control any specific asset position, and this entity can either be the user themselves or the user’s delegate. As a result, two policies cannot simultaneously claim the same asset, thereby preventing conflicts and ensuring user exit as and when they want.

The benefit of key encumbrance is best understood from how it counteracts the SEAO assumption model. Single-Entity Address-Ownership, or SEAO, dictates that one address must mean one corresponding user controlling it absolutely. In contrast, key encumbrance espouses programmable access-control policies that can function with complex rules, multiple delegations, time bounds, and asset limits. Everything is enforceable inside hardware without custody transference. This is the essence of automated, private DeFi without having to give up control.

Non-custodial model

The term “custody” is used often but not always clearly understood in DeFi. Let’s compare Privana with other prevalent custody models regarding their attributes to understand the difference.

This redefines the concept of non-custodial. Before, in standard wallets, users had to either manually sign every transaction for safety or give up control to bots for automation, leading to potential security risks. Now, with Privana, automation and self-custody are simultaneous, with privacy ensured throughout the whole experience.

This does not mean that there are no trust assumptions in Privana; it only means that the trust requirements are as minimal as possible. As long as Intel SGX hardware works as designed and Sapphire’s confidential smart contracts function as built and deployed, no one from Privana or Oasis’s side can access or tamper with the vault's private key or override the user’s policy rules. It may be useful to check out the Trust Model page in Privana’s docs for details on every assumption and its mitigation.

This concludes the deep dive into Privana’s core concepts. Next time, I will discuss Privana’s underlying technology in detail. In the meantime, let’s continue the discussion in the comments section about what you think of these concepts that are the pillars of Privana’s build.

Resources & references:
• Privana
• Oasis
• For specific questions or feedback, connect on the Privana channel** on the official Discord.

Zero-Trust Networking to Control-Plane Privacy: How Diode Scales on Oasis

DC — Tue, 25 Aug 2026 07:27:03 +0000

Enterprise integration of on-chain techniques is steadily growing, but is still far below blockchain's scope and potential. The main reason is that most crypto projects are built for users willing to jump through the hoops of complex interfaces and less-than-seamless experiences.

So, it is refreshing to see a project like Diode that aims to reach users who don't need to know or learn about underlying technologies to avail the benefits of some product or service. Along the way, Diode has fully embraced the privacy-first philosophy. This encompasses team communication, zero-trust networking, and AI, with Oasis doing the heavy lifting behind the scenes by bringing private data, verifiable execution, and programmable policies to the table.

This is especially beneficial for enterprise users who need to adhere to stringent regulations concerning data liability, and where high compliance levels mean zero tolerance for external access to their information.

Three Acts of Diode

What Diode is doing is best understood by looking at their three-layered approach.

In the first layer, they have introduced zero-trust networking (ZTN), which deserves a more thorough discussion later. Suffice here to say that Diode's WireGuard-native network is unique in its offering of blockchain-based identities, and is more cost-efficient than the alternatives, Tailscale or Zscaler. This is achieved by operating on bandwidth fees instead of traditional per-device charges.

In the second layer, Diode has improved upon team communication by creating a blockchain-defined communication perimeter. As a result, it works virtually like a private Slack where each user holds an identity contract. This is a multi-sig wallet linking their devices to a single verifiable identity, resulting in a secure "zone" of communication. Such zones then control who can read messages, share files, and access tunneled browsing or encrypted dashboards.

In the third layer, there is private AI, coordinated by a B2B system. It enables organizations to query their own data via an LLM interface. With no sensitive information ever going out to any public platforms, access control is the main focus here. Oasis-anchored access control lists (ACLs) set predefined parameters, governing which tools each team can connect, which LLMs are available for data query, and what filters can determine the output.

More on ZTNA

Before going any further, let's take a closer look at Diode's privacy-focused zero-trust network access (ZTNA) model, marking their first collaboration with Oasis. ZTN is an alternative to VPN and can replace it altogether as the future method for secure communication. This is an excellent example of a Decentralized Physical Infrastructure Network (DePIN) use case providing SaaS solutions.

Diode made the on-chain logic used in device onboarding and access permissions in the ZTNA model confidential and secure with Sapphire’s smart privacy infrastructure. This resulted in beefing up the encryption capabilities for decentralized messaging, p2p tunnels, and on-chain proxy services. Users can also avail benefits like connecting to servers, IoT devices, and remote workers to private network assets, all with zero data exposure risk.

The significance of this privacy-first ZTNA model as the fundamental layer of Diode's system is that both the other layers - team communication and private AI - are built on it.

Oasis Tech Integration

The role of Oasis in Diode's development has grown in scope and impact as the tech integration is crucial across all these different layers. Typical blockchain transparency means familiarity with contract structure can potentially let anyone identify which wallets are in a given zone or which device keys belong to an identity. Oasis prevents this with control plane privacy, hardcoded with data confidentiality and end-to-end encryption.

So now, to get even access to read the participating public keys in a Diode zone, a user needs to be a member of that zone contract. And the metadata always stays private by default. Moreover, for secure and seamless networking, WireGuard configurations, SSH keys, and device information are stored in Oasis perimeter contracts. The critical importance of going privacy-first is also demonstrated at the private AI layer, involving the Oasis-anchored ACLs.

Proof of Concept: On-chain Energy RWA With Trust Layer

Here is a proof of concept, applying the Oasis-Diode collaborative infrastructure scope to the real-world assets (RWA) space in a dynamic 3-way partnership that includes CleanConnect for oil and gas certification data.

Here, the AI-driven framework needs verifiable trust, which Oasis facilitates by bringing together Diode Nexus and CleanConnect's ProveZero multi-certification pathways. The partnership showcases the incorporation of adequate safeguards for regulated industrial data while delivering authenticated production proofs and ensuring the validity of on-chain RWA.

CleanConnect's ProveZero AI-powered camera systems monitor for physical breaches, detect liquid leaks using machine learning, flag hard hat violations, and image methane in the infrared spectrum. As an application of this monitoring system, Chevron qualified for a multi-billion-dollar drilling lease.

When verifiability at source is added to the mix, it becomes a crucial factor. With the cameras paired with blockchain-tied device identity, the generated data is routed via Sapphire smart contract-enabled ZTNA.

All this together carries significant regulatory weight, as auditors can review and confirm the footage and sensor outputs in an unbroken provenance trail. It also enables producers, traders, and buyers to access cryptographic proof that the attributes encoded in the certification data, including ISO 14067, ISCC, EO100, MiQ, OGMP, EUMR, etc, are real and verified. This also authenticates a secure, single, auditable chain of custody across major global standards simultaneously.

This is a scalable model for Oasis trust layer integration, assuring confidentiality, compliance, and control in private, automated, and cross-vendor AI systems. It also addresses the trust gap in current certification systems.

Final Words

Diode and Oasis coming together provides a working example for next-gen enterprise-grade privacy infrastructure. Diode is already working on making team communication and private AI products available for a wider user base. With Oasis's tech stack taking care of confidentiality, data is no longer entrusted blindly but is verifiably secure.

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

DC — Fri, 14 Aug 2026 06:12:11 +0000

In this 2-part bonus guide on the features and troubleshooting once you ROFLize an app, the first part covered in detail the marketplace, secrets, and persistent storage. Let's continue.

Public Variables

You will remember that we learned about secrets for confidential values. But an app may also consist of containers that need to access non-sensitive values and configurations. API endpoints, contract addresses, feature flags, etc are some examples of information that do not have or need any confidential attributes. This is when we use public variables. They are basically arbitrary key-value pairs that are exposed to containers as environment variables.

You can manage these public variables using the Oasis CLI. Take this example where we create a public variable called API_URL.

echo -n "https://api.example.com" | oasis rofl public-var set API_URL -

You will notice that this command only updates the local app manifest file. The public variable, however, is not yet propagated to the app. As a result, you will be able to easily configure as many public variables as you want without having to constantly update the on-chain app configuration.

Once the required public variables are created, you can update all of them in the on-chain configuration using the usual command.

oasis rofl update

The Oasis CLI documentation is useful if you need to consult comprehensive public variable management commands, including importing from .env files, removing public variables, and other advanced features.

Now, inside the containers, the public variables can be passed via environment variables. This is possible because each public variable is automatically exposed in the Compose environment and can be used in the Compose file.

services:
  test:
    image: docker.io/library/alpine:3.21.2@sha256:f3240395711384fc3c07daa46cbc8d73aa5ba25ad1deb97424992760f8cb2b94
    command: echo "API URL is $API_URL"
    environment:
      - API_URL=${API_URL}

rofl.yaml Manifest File

Before proceeding in this section, let's familiarize ourselves with the metadata in the yaml root, consisting of these valid fields.

name: A short name for your app that is readable by humans. e.g. my-app
version: The ROFL version you are using. e.g. 0.1.1
repository: A path to the git repository. e.g. https://github.com/user/my-app
author: The author name and the e-mail address. e.g., if you are John Doe, then it will show John Doe <john@doe.com>
license: The ROFL license in SPDX format. e.g. Apache-2.0
tee: The Trusted Execution Environment type that is being used. tdx is the default option, while sgx is also valid.
kind: As outlined in the initialization process of the workflow. Valid options for TDX TEE are containers, which is the default, or raw. If you use SGX TEE, then only raw is the valid option.

App Resources (resources)

Each containerized app running in ROFL needs pre-defined resources such as the number of assigned vCPUs, amount of memory, storage requirements, GPUs, etc, for its execution. In the app manifest file, these will be headed under resources.

resources:
  memory: 512
  cpus: 1
  storage:
    kind: disk-persistent
    size: 512

If you decide to change the requested resources, it will result in the creation of a different enclave identity for the app. Then you will have to update the policy accordingly.

Let's now see what these resources signify.

Memory (memory)
The amount of memory is specified in megabytes. It is initialized to 512 by default.
vCPU Count (cpus)
The number of vCPUs allocated to the VM. It is initialized to 1 by default.
Storage (storage)
You can choose different storage options for your ROFL app based on its utility. Currently, it can be one of four options.

disk-persistent: When the disk of the given size is persistent, it is encrypted and authenticated using a key derived by the decentralized on-chain key management system after successful attestation. This is what our example shows.
disk-ephemeral: When the disk of the given size is ephemeral, it is encrypted and authenticated using an ephemeral key randomly generated on each boot.
ram: Here, an ephemeral filesystem is entirely contained in encrypted memory.
none: Here, no storage provision has been made. This option is not valid for containerized apps, so you have to choose one of the previous three.

The size field defines the amount of storage to provision in megabytes.

Artifacts (artifacts)

This configures locations of artifacts used during the ROFL build process with builder, firmware, kernel, stage2, container.runtime, and container.compose as supported fields. If any fields are left unspecified, they will use the default artifacts from the CLI. For containerized apps, container.compose points to the Compose file included in the ROFL bundle.

artifacts:
  container:
    compose: compose.yaml

Deployments (deployments)

This contains ROFL deployments on specific networks.

The deployment you have defined will show as deployment_name.

Deployment artifacts are optional and merged field by field on top of global artifacts.

deployments:
  testnet:
    network: testnet
    paratime: sapphire
    artifacts:
      container:
        compose: compose.testnet.yaml

There are four components to policy under which your app will spin up.

quotes: Include TEE-specific policy requirements such as the TCB validity period and the minimum TCB-R number. This helps to indicate what security updates must be applied to the given platform.
enclaves: Include permissioned enclave IDs for running your app.
endorsements: Include a list of conditions defining who can run the app.
any: {} indicates any node can run the app.
node: <node_id> indicates only a specified node ID can run the app.
provider: <address> indicates nodes belonging to the specified ROFL provider can run the app.
provider_instance_admin: <address> indicates machines having the specified admin can run the app.

You can choose one or multiple conditions in a nested format by using and and or operators.

policy.yaml

endorsements:
  - and:
    - provider: oasis1qp2ens0hsp7gh23wajxa4hpetkdek3swyyulyrmz
    - or:
      - provider_instance_admin: oasis1qrk58a6j2qn065m6p06jgjyt032f7qucy5wqeqpt
      - provider_instance_admin: oasis1qqcd0qyda6gtwdrfcqawv3s8cr2kupzw9v967au6

This example indicates that the app can be run only on the specified provider, and on machines owned by either of the two admin addresses.

fees: <fee_policy> specifies who pays for the registration and other fees. It can be either endorsing_node when the node running the app pays, or instance when the app instance pays.

The final piece of this section is machines, where the specific app deployment takes place. If you remember the oasis rofl deploy tutorial, it creates a new default machine if there is no existing machine. If there is one, then the app is redeployed here.

<machine_name> is the name you choose for the machine.
provider: <provider_address> is the Oasis native address of the ROFL provider hosting the machine.
offer: <offer_name> specifies what offer you have chosen.
id: <machine_id> is the ID of the machine per provider.
permissions are optional, and when present, indicate ROFL scheduler-specific permissions.
log.view will list all the Oasis native addresses that can access machine logs.

`appd` REST API

Each containerized app running in ROFL runs a special daemon called rofl-appd. It exposes additional functions via a simple HTTP REST API. To enable easier access isolation, the API is exposed via a UNIX socket located at /run/rofl-appd.sock.

Let's consider this example where we have used the short syntax for Compose volumes.

services:
  mycontainer:
    # ... other details omitted ...
    volumes:
      - /run/rofl-appd.sock:/run/rofl-appd.sock

ROFL clients

For your ROFL app, it is strongly recommended that you follow the steps to bind the UNIX socket by accessing the ROFL REST API through one of the ROFL clients. You can choose any one of the following languages.

oasis-rofl-client for Python
@oasisprotocol/rofl-client for TypeScript
oasis-rofl-client for Rust

Note: Although the communication with rofl-appd is through UNIX sockets, the REST service still uses the HTTP protocol. In our examples, we will be using the http://localhost/<endpoint_path> format throughout. You are free to provide any name instead of a hostname.

Endpoints

App Identifier is where the endpoint is used to retrieve the app ID.
Endpoint: /rofl/v1/app/id (GET)
Example response:

rofl1qqn9xndja7e2pnxhttktmecvwzz0yqwxsquqyxdf

Key Generation

Here, each registered app automatically gets access to a decentralized on-chain key management system. Now, the keys can only be generated inside properly attested app instances. They remain unchanged even if the app is deployed elsewhere, or even if its state is erased.
Endpoint: /rofl/v1/keys/generate (POST)
Example request:

{
  "key_id": "demo key",
  "kind": "secp256k1"
}

key_id is used for domain separation of different keys. It is a unique identifier, with every key ID corresponding to a different key.
kind defines what kind of key should be generated. Options include:

raw-256 to generate 256 bits of entropy
raw-386 to generate 384 bits of entropy
ed25519 to generate an Ed25519 private key
secp256k1 to generate a Secp256k1 private key, as used in our example

The generated key is returned as a hexadecimal string.
Example response:

{
  "key": "a54027bff15a8726b6d9f65383bff20db51c6f3ac5497143a8412a7f16dfdda9"
}

Authenticated Transaction Submission

This is important if your app is registered with a different chain instead of Oasis. It enables your ROFL app to submit authenticated transactions to that chain. As these transactions are signed by an endorsed ephemeral key, they get automatically authenticated.

This also helps to easily authenticate the transaction origin in smart contracts by simply invoking an appropriate subcall.

Subcall.roflEnsureAuthorizedOrigin(roflAppID);

Endpoint: /rofl/v1/tx/sign-submit (POST)
Example:

{
  "encrypt": true,
  "tx": {
    "kind": "eth",
    "data": {
      "gas_limit": 200000,
      "to": "1234845aaB7b6CD88c7fAd9E9E1cf07638805b20",
      "value": "0",
      "data": "dae1ee1f00000000000000000000000000000000000000000000000000002695a9e649b2"
    }
  }
}

Let's decipher the fields before proceeding further.

tx describes the transaction content. Different transaction kinds are supported as defined by the kind field.

Ethereum-compatible calls (eth) use standard fields such as gas_limit, to, value, and data.

For gas_limit, you can input a JSON number (as used in the example), a decimal string, or a 0x-prefixed hex string. There should not be any whitespace, and irrespective of the input, it will be interpreted as a non-negative 64-bit integer.

For value, you can input a JSON number up to 2^64 - 1, a decimal string, or a 0x-prefixed hex string. There should not be any whitespace in the string forms, and the value must represent a non-negative integer up to 256 bits.

For hex-encoded fields such as to and data, you can input strings with or without a leading 0x prefix, but there should not be any whitespace or prefix-only input. Empty strings are accepted for contract creation or empty calldata, e.g. to: "" or data: "". If you are providing input for the to field, it must decode to exactly 20 bytes representing an Ethereum address.

Alternately, Oasis SDK calls (std) support CBOR-serialized hex-encoded Transactions to be specified.

encrypt is a boolean flag specifying whether the transaction should be encrypted. This field is true by default. When an ephemeral key is being used, the encryption is handled transparently for the caller, and any response is first decrypted before being passed on.

Now, as the outcome of the example request, the example response inside data is generated as a JSON response containing a CBOR-serialized hex-encoded call result that you will need to deserialize.

If the call result is successful:

{
  "data": "a1626f6b40"
}

It deserializes as {"ok": ''}.

If it is unsuccessful:

{
  "data": "a1646661696ca364636f646508666d6f64756c656365766d676d6573736167657272657665727465643a20614a416f4c773d3d"
}

It deserializes as {"fail": {"code": 8, "module": "evm", "message": "reverted: aJAoLw=="}}.

Replica Metadata

This allows apps to publish arbitrary key-value pairs included in the on-chain ROFL replica registration and automatically namespaced with net.oasis.app.

Get Metadata: With this, you can retrieve all user-set metadata key-value pairs. Endpoint: /rofl/v1/metadata (GET) Example response:

{
  "key_fingerprint": "a54027bff15a8726",
  "version": "1.0.0"
}

Set Metadata: With this, you can set metadata key-value pairs to replace all existing app-provided metadata. Endpoint: /rofl/v1/metadata (POST) Example request:

{
  "key_fingerprint": "a54027bff15a8726",
  "version": "1.0.0"
}

The parameters for metadata validation are the number of pairs, key size, and value size.

Upsert Metadata: With this, you can input or update metadata key-value pairs. However, if you did not specify it in your request but there is existing app metadata, that will not be affected. Endpoint: /rofl/v1/metadata (PUT) Example request:

{
  "version": "1.0.1"
}

Delete Metadata: With this, you can delete given metadata keys, while keys that no longer exist will be skipped. Endpoint: /rofl/v1/metadata (DELETE) Example request:

["version", "key_fingerprint"]

Whenever you use Set, Upsert, or Delete Metadata, any change in the metadata triggers a registration refresh.

Query

This runs arbitrary query methods defined in the Oasis Runtime SDK module and returns the result.

Endpoint: /rofl/v1/query (POST)
Example request:

{
  "method": "rofl.App",
  "args": "a16269645500694cb01f85408d624ea267f657bf285787a61db3"
}

Here, method refers to the internal name of query methods; in our example, it is rofl.App. You will recognize query methods by the #[handler(query = "...")] annotation in the Oasis Runtime SDK source.
args represent query parameters for the method serialized as CBOR and hex-encoded.

Example response:

{"data":"a76269645500ffe981cceff2d759d19fa926faebb7d90c0a59a56373656b582056c6d4841fa5ad24ad761088cb7053ad312ef13f3c2f405640fdba2bde4c14386561646d696e55007814f3d954f41b6459eb9e4bc8fbc6767ece5aa9657374616b658249056bc75e2d631000004066706f6c696379a56466656573026671756f746573a263696173f663706373a363746478a173616c6c6f7765645f7464785f6d6f64756c657380737463625f76616c69646974795f706572696f64181e781e6d696e5f7463625f6576616c756174696f6e5f646174615f6e756d6265721268656e636c6176657382a2696d725f7369676e6572582000000000000000000000000000000000000000000000000000000000000000006a6d725f656e636c6176655820bd4844a79a12ba365e890ddeaebbc4e4292797c7d956b42c2e25e4aefce3b124a2696d725f7369676e6572582000000000000000000000000000000000000000000000000000000000000000006a6d725f656e636c6176655820412c94a9baa0949f718dbba41ab89c38ea5c320345bba36b07e2ef857ffe2fb96c656e646f7273656d656e747381a163616e79a06e6d61785f65787069726174696f6e036773656372657473a26a50494e4154415f4a5754590327a462706b58207f88546291174f854a8ce2eb4bbfc8e62e40d60cdae2d600920a766d3006bf6c646e616d65581aad0460d0f742ad697b6d7c8462cc2b153deeb051a791553ef52b656e6f6e63654f8cbbe6631910d9a702e49bd30ee8f46576616c75655902c1352d823e54f75c846579066e2c1a750387f0630e3f29dba5524984712883bb33371ff017e507ae432b135312af64bfb85f3b17def05b2ac2744256f5accf1a26b29cd8cd412f08bfc9204f9bfa670b2d65972cfc4a8d4e2074402f21c18dfe554b1f0a8a731c077699f741807b3a4047ef4dc570958b8b46111a445259e93c9b92a5f72a23d32cbbef875efe586a8ddda38f1fa286d19b369a2022c3eae1cdbf6f6de4dc055bbab36a2c4830f8e2c64437f5f878f419e21f3a4c0f13c47b63697668b34722eaa61bdffa12e82be6d0266a41590254c9d70e9237475f6115c2867065c49afa8032acdfe0bc5dc671ef48ebc58d893937659243479e2eaa38815cd8665541e4c7e40349524cda15f2d410cba100ee27f0a59dc63534f7cff2444b57c7b74060cf8c3e21e1590b597384a89a463d6bb4a52fc52a4592889448a8f8e0c02fef1689c1efea58ddc08783f6d22d7a908cdf2a45bc46a79a3b73ff5f13bbbf7219973a7382eee84b3b4d48036b5e87fb24223e6387a3e37f9c1ac9722534adfef0201ec13db2e70fe9cd0336f020e50b59d7d32951378f568a4ef3a8117386ff0f1ba4b7d33dcf913daa696a6a7d64d20220b0e5eec994ea56aa9c01f56f5e12bf7d555b3f4a218ddbd8ae1586d5cb1e76802c90e26472b233686e8449284829378163acd77d1b65d4953a76cc497584580c1a5ac4fe6d97fd818fa53c2eb43c6f1b7a79211ef57f24036b1f8ed37f4c3d36873bbbd876769a5fde17add6926317afc96c9707e10b150735c63877ffd6475b1a27b6dd108940f0097375e422b1d308c6c8a0a83847368f5760778c54f2a70b44f9365c55c4b5d69341cad62d6fdb11aa25a9e26b4977adebd65718042bda1cbbf988298d293547107c2f5899352188179bc4d22febc66e8e351885498e707dee583d052c0b7c13f930e4529b59c36c20ee3ee6d29d1a3e2bb65bd489b7206cd45d2ae046f1e147d6407c166e494e465552415f4150495f4b45595899a462706b582074be2e227be81a5e35943ac1b79e238395b9bc367f7a0d1eed740c259ae23a37646e616d65581ee5190cda87688753f6f221890bfed8fe0e27b3ced4a9bc54537da1f4cd90656e6f6e63654fcf5411193abf4f4711f17179ea4b6f6576616c756558304675a29c8398bc94b5057063b4badeb9937a6e019ef7f8095d6b5a035106d4e8e7d710af9b6883848886481c1d180cbc686d65746164617461a7736e65742e6f617369732e726f666c2e6e616d656f76616c696461746f722d6167656e74756e65742e6f617369732e726f666c2e617574686f72782a4d61746576c5be204a656b6f766563203c6d617465767a406f6173697370726f746f636f6c2e6f72673e766e65742e6f617369732e726f666c2e6c6963656e73656a4170616368652d322e30766e65742e6f617369732e726f666c2e76657273696f6e65302e312e30776e65742e6f617369732e726f666c2e686f6d6570616765784f68747470733a2f2f6769746875622e636f6d2f6f6173697370726f746f636f6c2f6572632d383030342f626c6f622f6d61737465722f524541444d452e6d642376616c696461746f722d6167656e7478196e65742e6f617369732e726f666c2e7265706f7369746f7279782968747470733a2f2f6769746875622e636f6d2f6f6173697370726f746f636f6c2f6572632d38303034781a6e65742e6f617369732e726f666c2e6465736372697074696f6e787f4c697374656e7320746f2056616c69646174696f6e52657175657374206576656e7473206f6620746865204552432d383030342076616c69646174696f6e20726567697374727920616e642076616c696461746573207768657468657220746865206167656e7420697320706f776572656420627920524f464c205445452e"}

Inside data, the JSON response contains the CBOR-serialized method's return value in hex format.

If you want to try other examples, you can check out the relevant section of the ROFL demo repository for querying with curl directly.
There is also a production-ready Python example at hand - in the ROFL-8004 implementation where the query endpoint is used to fetch various app on-chain metadata for registration in the ERC-8004 identity registry.

Port Proxy

When you publish a port in your compose.yaml file, the ROFL proxy automatically makes your services accessible via public URLs. It also ensures the routed traffic is done correctly.

This uses TLS, which is terminated inside your ROFL enclave, maintaining confidentiality and integrity protection. As a result, even the provider cannot see or modify the traffic. Moreover, the default terminate-tls mode generates and configures a Let's Encrypt certificate in ROFL to authenticate your services.

To enable the proxy and expose a port from your container, you need to publish it in your compose.yaml file.

compose.yaml

services:
  frontend:
    image: docker.io/hashicorp/http-echo:latest
    ports:
      - "5678:5678" # Expose container port 5678 on host port 5678

After deploying your app, you can find the generated URL by running the usual command.

oasis rofl machine show

The output generated in this way will show a Proxy section with the public URL for each published port.

Proxy:
  Domain: m602.test-proxy-b.rofl.app
  Ports from compose file:
    5678 (frontend): https://p5678.m602.test-proxy-b.rofl.app

Configuration

You can use the annotations in your compose.yaml file to configure the proxy behavior.

The general format of an annotation is net.oasis.proxy.ports.<published_port>.<setting>: <value>.
Here, <published_port> is the external port exposed in your compose.yaml, and <setting> indicates the specific proxy configuration like mode or custom_domain.

Example:
Here I will configure port 80 to use the default terminate-tls mode with a custom domain and port 8080 to use TCP passthrough.

compose.yaml

services:
  myservice:
    image: docker.io/my/service:latest
    ports:
      - "80:80"
      - "8080:8080"
    annotations:
      net.oasis.proxy.ports.80.custom_domain: mydomain.com
      net.oasis.proxy.ports.8080.mode: passthrough

This shows:

The application container exposes ports 80 and 8080.
On port 80, the proxy terminates TLS for mydomain.com and forwards traffic to the application container.
On port 8080, the proxy forwards the raw TCP connection to your application container (mode: passthrough).

Annotation Reference

net.oasis.proxy.ports.<published_port>.mode defines how the proxy should handle connections for the specified port.

net.oasis.proxy.ports.<published_port>.custom_domain assigns a custom domain name to the published port.

Here, when using the default terminate-tls mode, you need to use special configuration for your custom domain to route through the proxy. Once the app is deployed, you can use Oasis CLI for instructions to configure A and TXT records in your DNS.

oasis rofl machine show

Proxy:
  Domain: m897.opf-testnet-rofl-25.rofl.app
  Ports from compose file:
    5678 (frontend): https://demo.rofl.build
      * Point the A record of your domain to: 131.153.241.25
      * Add a TXT record to your domain:
oasis-rofl-verification=4SKHCn4E2SNDB5tXayQeHZsvH/+kJSNGuQaTAPepYJc=

If you choose to go with passthrough mode, the proxy will not terminate TLS and your app will then need to handle it directly. Also, here the custom_domain setting is not needed, so you can configure the domain directly to the ROFL instance's address.

For the ignore mode, the port isn't published, so the custom_domain setting has no effect.

Troubleshooting

Here I will cover some common errors and the troubleshooting process.

Compilation

Sometimes you will see an error message if the aes and ssse3 compiler flags are not enabled during compilation of your SGX and TDX-raw ROFL.

error: The following target_feature flags must be set: +aes,+ssse3.
--> /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deoxysii-0.2.4/src/lib.rs:26:1
|
26 | compile_error!("The following target_feature flags must be set: +aes,+ssse3.");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The workaround is to add default flags to your .cargo/config.toml file.

[build]
rustflags = ["-C", "target-feature=+aes,+ssse3"]
rustdocflags = ["-C", "target-feature=+aes,+ssse3"]

[test]
rustflags = ["-C", "target-feature=+aes,+ssse3"]
rustdocflags = ["-C", "target-feature=+aes,+ssse3"]

Compose file

A couple of errors are possible here due to an upstream podman compose bug.

The first is when environment variables defined are not considered.

services:
  oracle:
    platform: linux/amd64
    environment:
      CONTRACT_ADDRESS: 0x5FbDB2315678afecb367f032d93F642f64180aa3
    entrypoint: /bin/sh -c 'python main.py $${CONTRACT_ADDRESS}'

In this type of error, the CONTRACT_ADDRESS field will return as empty in ROFL. You need to inject the variable value directly inside entrypoint as a workaround.

services:
  oracle:
    platform: linux/amd64
    entrypoint: /bin/sh -c 'python main.py 0x5FbDB2315678afecb367f032d93F642f64180aa3'

The other type of error that may occur is when depends_on is ignored.

services:
  contracts:
    image: "ghcr.io/foundry-rs/foundry:latest"
    platform: linux/amd64
    volumes:
      - ./contracts:/contracts
    entrypoint: /bin/sh -c 'cd contracts && forge create'

  oracle:
    platform: linux/amd64
    entrypoint: /bin/sh -c 'python main.py'
    restart: on-failure
    depends_on:
      contracts:
        condition: service_completed_successfully

In this type of error, instead of oracle spinning up once the contracts service successfully deploys the contracts and finishes, they start in parallel by ignoring the depends_on command.

There is no immediate workaround as of now. You can try to implement customized logic in your oracle service to crash it, and then trigger the restart mechanism and try again.

appd

If you encounter the 422 Unprocessable Entity error, when the provided request couldn't be decoded, you need to ensure all the required fields are present and correctly formatted in accordance with the appd REST API section described above.

ROFL Proxy URL is not working

Sometimes the app might be using outdated artifacts, which will result in the proxy URL returned by oasis rofl machine show being inaccessible. This is easily fixed by updating to the latest Oasis CLI version. The next step is to run oasis rofl upgrade in your project directory to update the artifacts in your rofl.yaml file, and finally, rebuild and redeploy your app.

oasis rofl build
oasis rofl update
oasis rofl deploy

This concludes our 2-part bonus guide describing the various features for your ROFL app, and some common troubleshooting hacks. Looking forward to your feedback in the comments section.

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.

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.

DEV Community: DC

Your Guide to the Prerequisites for Running Nodes on Oasis (Part 2): Stake Requirements and Node Installation

Stake Requirements

Installing the Oasis Node

Your Guide to the Prerequisites for Running Nodes on Oasis (Part 1): Hardware and Cloud Providers

Hardware Requirements

Cloud Providers

Introducing Privana: A Deep Dive into Underlying Technology

Oasis Sapphire and ROFL

Privana's Architecture

Fallback & Recovery

Trust Model

Research Basis

Integrations

Your Guide to the Nodes You Can Run on Oasis

Validator Node

Compute Nodes

Client Nodes

Archive Node & Seed Node

Key Manager Node

Services

Introducing Privana: A Deep Dive into Core Concepts

Finding the missing piece of the privacy puzzle

An overview of Privana’s core functionality

The three pillars of Privana’s core concepts

Zero-Trust Networking to Control-Plane Privacy: How Diode Scales on Oasis

Three Acts of Diode

More on ZTNA

Oasis Tech Integration

Proof of Concept: On-chain Energy RWA With Trust Layer

Final Words

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

Public Variables

rofl.yaml Manifest File

appd REST API

Port Proxy

Troubleshooting

Blockchain Interoperability, Decoded. And What Lies Ahead.

The Problem Of Chains In Silo

Building Bridges For Seamless Connection

Privacy As A Solution

The Off-chain Alternative

The Road Ahead

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

Robin Markets & verifiable yield with trustless oracle

Tradable & verifiable market intelligence

Final words

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

ROFL Marketplace

Secrets

Persistent Storage

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

Create

Build

Deploy

Test

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

Plurality & portable AI context

Ekai & AI context layer

Final words

`appd` REST API