DEV Community: DC

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

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

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

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

x402 101

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

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

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

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

x402 Functionality

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

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

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

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

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

Key Takeaways

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

x402 In Practice

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

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

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

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

x402 x ERC-8004 x ROFL

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

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

The agentic trust gap is solvable.

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

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

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

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

The Flashback Labs Case Study On Privacy-first AI Training

DC — Fri, 20 Mar 2026 07:27:08 +0000

Our interactions with AI and our shared experiences are growing exponentially. We know AI needs extensive training for all this, but how much thought or effort is put into ensuring data privacy?

Oasis, as a privacy-first blockchain, has taken essential steps in bringing confidentiality to decentralized AI (DeAI). So, no wonder that Flashback Labs adopted the game-changing technology of runtime off-chain logic (ROFL) to integrate verifiable privacy into their AI training setup. The result of that collaboration is the basis of this case study.

Decoding Flashback

Flashback Labs helps train AI to understand people through lived human experiences. On their platform, a conversational AI app, people can interact with the AI to talk about their lives and preserve memories.

How this works is: say you type in a prompt with a personal piece of conversation, or run a stream-of-consciousness with a voice assistant. The chatbot, like any other conversational AI model, will pick up the cue and ask follow-up personal questions. The data that flows as a result is structured around you personally - places, emotions, and timelines.

The Flashback app can then generate a short animated video from your inputs, using photos, text, and voice narration like a call-back memory. As you go through multiple sessions, a sort of graph forms in the AI database, and the more you use it, the more enriching your personal experience becomes.

Flashback x Oasis

Flashback's platform deals with extremely sensitive information, from personal memories to relationships, even health-related or finance-related conversations, as a personalized experience is directly dependent on personal shares with the app. It is, therefore, critical that there is implicit trust.

Opaque systems or even fully transparent decentralized solutions are ill-equipped to handle this.
Oasis enters the equation here by becoming the encryption layer and plugging the trust gaps.

The result is both elegant and crucial. Now, all the inputs ever made into the platform - photos, videos, stories, etc, are wallet-owned, processed and secured by TEEs (trusted execution environments), and stored on-chain after being consented to by the user.

Now, let's look at the AI training aspect. It entails dealing with massive datasets and processing them. Flashback uses 0G, BNB Greenfield as storage networks, but they do not offer data privacy. Oasis provides the ideal confidentiality solution to encrypt the data files before storing them. Users can verify on-chain that their encrypted data is safe and secure.
Interestingly, Oasis has also been developing a dedicated solution for privacy-enabled decentralized storage with programmable access control, which the ecosystem urgently needs.

Scaling Progress

Flashback Labs has focused little on marketing hype or gimmick. Still, their initiative has struck a chord and fuelled a wide response and active participation. Some of the key milestones achieved include:

more than 1k users with close to 1k early contributions
3k+ on-chain, encrypted files at the rate of almost 200 per day
almost 10k on-chain transactions generated at the rate of almost 700 per day

The metrics, growing as more users come in, tell a clear story - private AI is getting scaled.

Flash Forward: What Future Promises

The case study of Flashback Labs and its success is a huge step forward for DeAI, as its target is the mainstream audience, and its use cases are not part of traditional crypto utility.

At the moment, as Flashback goes through its roadmap for 2026, the team has multiple products underway. One is related to Alzheimer's care, while another is a product developed in collaboration with notable bereavement non-profits in the US to help people cope with the process of loss of a family member.

There are also plans to develop an agentic framework that empowers Flashback's AI rendering to proactively reach out to users for memory collection and preservation. Hardware integration, like in robotic companion devices, to assist in hospice and elder care settings, is another promising development.

The bottom line: personalized AI is going to be more and more an integral part of our memorable experiences, and the data confidentiality that this undertaking must assure is non-negotiable, both during training and in storing the processed data. And, Oasis is the industry expert for this solution - verifiable privacy.

Do You Vibe Code? A DeAI Primer By Oasis

DC — Wed, 18 Mar 2026 07:40:56 +0000

AI integration is moving fast, and the accessibility to develop AI is becoming easier by the day. The decentralized AI (DeAI) space has also picked up momentum as the new-gen web3 solutions all come with an AI edge. So, if you are a web3 developer, it is no longer imperative that you be a Solidity expert or know the ins and outs of building on-chain applications. Vibe coding is your friend.

In this guide, I will show you new tools and help you learn how to build with AI on Oasis, with privacy by default. We will be using an llms.txt file, a Context7 MCP integration, for the purpose of this tutorial.

AI context

AI is prone to forgetting, and its way of remembering needs some understanding. To understand AI memory and context, check out this Oasis Academy course.

Suffice it to say, large language models (LLMs) need context to respond to any prompts, especially when you are asking them to build something. So, patchy memory or outdated context might result in a code that looks correct on a quick review but fails in practice. There are two possible solutions so that the AI tool can directly access Oasis docs to correctly consult instead of hallucinating, and I will outline them both.

llms.txt
Model context protocol (MCP)

llms.txt

For anyone familiar with AI, this is a standardized file format. It functions like a sitemap and is specifically designed for AI so that it can access a project's documentation as a structured index. It provides a brief description of the documentation and links to detailed markdown files for the AI to find and read.

For our purpose, we will be referring to these files:

https://docs.oasis.io/llms.txt — a curated index with page titles, descriptions, and URLs
https://docs.oasis.io/llms-full.txt — the complete documentation content consolidated in one file

If the AI supports project context, such as Cursor's docs feature or a CLAUDE.md file, good. Alternatively, copy-pasting the URLs in the LLM chat directly works too.

The usefulness of having two versions is dictated by AI memory and context limits. llms.txt is designed for a quick overview, and llms-full.txt is when you need the AI to know everything, unabridged.

MCP

MCP is an open standard. If you don't use MCP, then AI will only read the prompt submitted at face value. Using MCP not only gives AI structured access to all external context - documentation, codebases, tools, and runtime information- but also enables the AI to refer to them on demand and query external tools if and when needed.

As mentioned earlier, Oasis documentation is indexed on Context7, an MCP server that serves docs to AI coding assistants. The library ID is llmstxt/oasis_io_llms_txt.

Setting Up

I will show here Cursor and Claude as primary tools, as they are the most popular among vibe coders.

Using Cursor

The first step is to add the following snippet to your .cursor/mcp.json:
json

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

This will prompt Cursor to connect to Context7. So, now when you generate code, you will have full access to the Oasis documentation.
Pro tip: It is advisable to add a rule to your Cursor settings so that the AI always consults the Oasis docs. It can be phrased like this - Always use Context7 MCP with library ID llmstxt/oasis_io_llms_txt for Oasis documentation reference.

Using Claude

Run:
bash

claude mcp add --transport http context7 https://mcp.context7.com/mcp

The next step is to verify configuration is correctly done:
bash

claude mcp list

When you see context7 listed, you are good to go.
Pro tip: The same rule applies for your project's CLAUDE.md - Always use Context7 MCP with library ID llmstxt/oasis_io_llms_txt for Oasis documentation reference.

Other AI tools

Even though Cursor and Claude are popular choices, you may be using other AI tools such as VS Code, JetBrains, Windsurf, Zed, etc. Context7 supports 40+ clients, and you can refer to the full list here to check the setup instructions specific to your tool of choice.

Before We Start

If you are set up, there are still a few things you will need before starting to vibe code.

Node.js: This is required for Hardhat. You can check if your terminal has it installed by running node -v. It will show a version number, if it is already available. If not, download the LTS version from https://nodejs.org/en, install it, then reopen your terminal and recheck to confirm successful installation.
Wallet: Since we are working with DeAI, you will need a wallet with its private key.
If using CLI, refer to this: https://docs.oasis.io/build/tools/cli/wallet. The best approach is to create a new MetaMask wallet.
Testnet tokens: You will need testnet tokens, too, in the wallet to proceed with your vibe coding. First, you need to add the Sapphire testnet to your MetaMask wallet. You can then request free TEST tokens from https://faucet.testnet.oasis.io/. Remember to select Sapphire from the network dropdown and provide the wallet address created above.

Example: Deploying a Confidential Smart Contract

I will use a basic example here to demonstrate how this will all work. Once you have connected your Integrated Development Environment (IDE) with the Oasis MCP, start a fresh project. Let's use this prompt:

Create a confidential smart contract on Sapphire with Hardhat. It should store a secret message that only the owner can set. Anyone can submit a guess, but the actual secret should never be visible on-chain.

Your chosen AI tool will immediately pull the documentation and perform the following steps seamlessly:

Identify the correct Hardhat config.
Infer that the contract state on Sapphire is private by default.
Generate a working contract with a full project structure, including a deploy script, interaction examples, and tests.

Note that Claude will ask for permission before running commands. So, you might want to select "don't ask again" if you prefer.
There will also be a .env.example file generated in the process. You need to copy it to .env and add your wallet's private key.

cp .env.example .env

For those developers who are new to the decentralized setup, the private key can be found on your MetaMask wallet account with these steps: click the three dots next to the account name → account details → reveal private keys → enter password.
This private key will have to be added to the .env file as PRIVATE_KEY=0x..., and then deployed:
bash

npm run deploy:testnet

When you see a contract address returned in your terminal, it confirms the successful deployment of a confidential smart contract live on the testnet, using just the prompt mentioned at the start of this segment.

You can further test the confidentiality of the contract when you try calling eth_getStorageAt on your contract at Oasis Explorer.

As Oasis enables verifiable privacy and confidential computation, this is the gateway to developing private applications. You can start exploring the possibilities at https://oasis.net/ and start vibe coding to build the next-gen dApps. With your AI coding tool connected to the docs, it will be the model doing all the work.

Sources referred: https://docs.oasis.io/build/tools/llms/
Help needed? Ask the dev team: https://oasis.io/discord

AI Has a Memory Problem. Decentralization and Privacy Might Have a Solution. Part 3

DC — Mon, 23 Feb 2026 11:26:51 +0000

In the first part of this 3-part series, I covered AI memory and its classification, while in the second part, I discussed in detail the types of AI memory and security risks associated with the architectures.
Here, I will refer to Oasis technology for a potential solution to AI memory pain points through the decentralization and privacy approach. I will also talk about some working use cases for portable AI memory.

Zero-Trust and DeAI Solutions

There are two distinct pain points of the AI memory architectures: security threats, and data silos and redundancy.

As a believer in decentralized AI (DeAI), I think the solution to attack risks is best addressed by security-first architectures that adopt a Zero-Trust model.
How does this work? Basically, all data is monitored at the ingestion stage, and any sensitive information is identified and redacted before it moves to the vector storage phase. Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) are enforced at the retrieval layer. Result: the system only considers document subsets that the specific user is authorized to see.

Now, what about the other pain point - information silos and redundant work? Simple answer: it is preventable. Let's understand how, with reference to the multi-agent collaboration we discussed regarding stateful memory loops.
DeAI ensures a shared workspace allowing different agents (for example, an Architecture Agent and an Implementation Agent) to work in tandem, querying and updating the same memory instance. This is also the seed for AI context flow, where data silos do not result in context loss.

Role of Confidential Computing and Oasis Tech

A serious bottleneck in ensuring secure AI memory is protecting the data being computed. Traditional encryption can handle data at rest and in transit. But what about the information that is decrypted during the actual retrieval and inference processes?

Hardware-Backed Privacy via TEEs

Confidential Computing is the answer to this security gap, utilizing hardware-backed Trusted Execution Environments (TEEs). The secure enclaves isolate memory as the content is made cryptographically inaccessible to any unauthorized access, even by the infrastructure operators. For the AI systems, the prompts and embeddings are only decrypted inside the enclave's black box. As a result, the vector searches and inference building can occur smoothly without exposing any raw data.

The reason to use Oasis technology as a reference to a potential solution for secure AI memory is how it combines and optimizes on-chain and off-chain components - the first production-ready confidential Ethereum Virtual Machine (EVM), Sapphire, and the Runtime Off-chain Logic (ROFL) framework. By utilizing hardware isolation (Intel SGX/TDX), it is ensured that transaction inputs, return values, or the internal state of the smart contract remain confidential at all times.

For complex AI memory systems requiring computation-heavy processing, Oasis utilizes the ROFL framework instead of wholesale on-chain logic. So, model training and inference can be done securely off-chain while verifiable settlement can happen on-chain. This combination is the foundation for trustless AI agents that can manage private keys and sensitive user context within a secure enclave. The personal information and sensitive data consequently become a portable, secure asset.

Industry-Specific Implementations of AI Memory

What AI memory architectures need vary across regulated industries needing dynamic blueprints for solutions. Let's talk about healthcare and finance as the two most highly impacted areas.

Healthcare

Here, AI systems must adhere to strict standards like the Health Insurance Portability and Accountability Act (HIPAA) and Health Information Trust Alliance (HITRUST) to protect electronic Protected Health Information (ePHI). Such a memory architecture must include:

Zero-Retention Architectures: Data is isolated and cannot be reused for any other training purpose. A volatile memory approach is ideal where data is processed in-memory and immediately discarded.
FHIR-First Data Foundations:The Fast Healthcare Interoperability Resources (FHIR) standard helps create a standardized operational data layer. This eliminates schema chaos and enables AI assistants to retrieve clinical facts using a shared, consistent language.
Auditability and Explainability: Verifiable audit trails for agentic workflows ensure that we know which medical databases were accessed and why. This is critical for regulatory compliance.

Finance

Here, there needs to be a fine balance between collaborative analytics and exposure to private and proprietary data through transparency.

Secure Multi-Party Computation (SMPC): An example would be where multiple banks are analysing transaction data for fraud detection, but no single institution can access another’s private customer records.
Homomorphic Encryption: Financial institutions use this to perform computations directly on encrypted data, ensuring that sensitive financial parameters are never exposed during processing.

Working Use Cases

There are already a few companies that are working on solutions for AI memory problems and tackling how to implement portable memory systems.

Plurality is developing the Open Context Layer. It allows users to autonomously store their data and chats in specific memory buckets for better context management, and also for sharing.
MemSync is building the Unified Memory Layer. It allows users to create a persistent “digital twin” based on personalized conversation and knowledge. This enables the AI system to know the user, track their evolving ideas, and serve as a private sounding board for reflection and decision-making.
Ekai is offering a developer-focused solution. It allows users to switch among various AI models via smart model routing without context loss.

Final Takeaway

The future of AI memory? A portable context model. This means that you, as a user, are not obligated to commit to a single model or AI assistant, or have your digital history trapped in large platforms like OpenAI or Anthropic. When you move and switch as you need and choose, the memory travels with you, encrypted and under control, working like a neutral, interoperable memory layer.

Realizing this vision requires a fundamental reimagining of memory as infrastructure. We can combine stateful memory loops, DeAI, and confidential computing technologies like Oasis ROFL and Sapphire to build AI systems that are smarter and personalized while also being fundamentally secure and user-owned. Result: Private, portable AI memory that is a sovereign asset, free from data privacy liability.

Resources referred:

AI Has a Memory Problem. Decentralization and Privacy Might Have a Solution. Part 2

DC — Mon, 23 Feb 2026 09:11:35 +0000

In the first part of this 3-part series, I covered AI memory and its classification.
Here, I will start with a deep dive into the types of AI memory, and then discuss the pain points in AI memory architectures.

A Deep Dive Into AI Memory Classification

As I mentioned in the first part, how human and AI memory work is different. The broad classification of short-term and long-term AI memory requires further analysis.

Short-Term Memory: Managing Ephemeral Context

This spans a single conversation session. The memory is preserved temporarily across a few prompts and responses. The context window, thus, encompasses the whole chat in the session, utilizing sliding windows or token-based buffers.

Short-term memory can be hence defined as the system’s ability to maintain continuity within a specific session or task. Working memory is a subset of short-term memory. While working memory only deals with tokens being processed immediately, short-term memory can strategically manage continuity to a certain extent as the conversation grows.

Implementation Strategies

Let's start by understanding why short-term memory fails. Simply because it outgrows the context window and hence cannot remember beyond the model's token limit. To counter this, the system can delete and overwrite earlier information or, because it is full, fail to add new information, leading to memory failure and possible hallucination.
There are three techniques to manage this:

Conversation Buffers: These maintain a list of recent messages. There are two types of buffers - full, which remembers everything, and windowed, which retains the last few turns, ensuring the model works within its limits and the earlier context is not totally lost.
Summarization: This technique compresses the conversation history into a concise summary of essential facts by forgetting redundant details. While this can extend the session limits, nuances from earlier context might get filtered out.
Token Budgeting: This optimization technique is a variation of summarization where only the system prompt and the latest five turns are preserved, pruning the rest. Research suggests this middle data is often ignored by models anyway, and hence discarding that portion of the context is an acceptable approach.

The Key-Value (KV) cache plays a vital role in short-term memory. It preserves the exact attention patterns of recent turns and can sometimes perform better than standard Retrieval-Augmented Generation (RAG). There is, however, a trade-off between speed and memory capacity.

Long-Term Memory: Shift to Persistent and Adaptive Knowledge

This spans multiple conversation sessions. The memory is preserved for longer periods, resulting in better context. External databases (vector databases, key-value stores) help to refer to persistent data outside the model.

Long-term memory can be hence defined as the system’s ability to maintain continuity across sessions and days, sometimes even weeks, months, or years. It builds relationships rather than transactions, as external databases synchronize with the model’s built-in knowledge, and RAG is the single-most critical technology to achieve this.

RAG Pipeline and Role of Vector Databases

A typical RAG architecture computes information only one-way. Documents are converted into high-dimensional vector embeddings and stored in a vector database. The advantage of the RAG system is that the data is organized based on semantic meaning instead of literal matches.

So, when a user submits a prompt, the system embeds the query and retrieves a chunk of data that is most similar. This information is pulled into the context window, and the AI can generate answers based on private, proprietary, or real-time data, not necessarily part of its original training. Research suggests this can cut down factual errors and increase efficiency.

From Stateless RAG to Stateful Memory Loops

An essential point to note here, if it has not been apparent, is that RAG is fundamentally stateless. What does this mean? It means that every query is independent, and its significance lies in the fact that the system does not learn anything from interacting with the user. The next logical step is, therefore, moving towards stateful AI memory architectures that can operate as a continuous loop of learning.

There are 4 critical components of a truly stateful memory system.

Extraction: First, the LLM evaluates user interactions to identify and filter salient facts or user preferences.
Synthesis and Learning: Next, synchronization between new information and existing knowledge takes place. The system determines whether new information is a new addition entirely or an overwriting of older, redundant data.
Conflict Resolution: Next, any contradiction arising from the new data addition is resolved by the intelligent agentic system so that consistency and continuity are maintained.
Consolidation: Finally, all knowledge deemed as significant is moved from the short-term context to a long-term Memory Graph or relational store.

It stands to reason that such a stateful loop needs multi-agent collaboration.

Since we are discussing the various types of AI memory, there is another that deserves mention - User Profile Memory. It is usually a subset of the long-term memory with particular emphasis on the user and their preferred language, time zone, conversational and response style, etc. These structured user profiles are stored in databases and injected into prompts, giving the appearance of personalized conversations.

Security and Privacy Risks in AI Memory Architectures

AI memory is built over time, processing through huge and complex datasets that can encompass critical and sensitive information. As vector databases and RAG pipelines become live memory, there is an inevitable vulnerability to severe, crippling security threats.

Data Leakage and Unauthorized Access

This is related to the exposure of Personal Identifiable Information (PII) or proprietary content. RAG systems pull context from a vast range of documents and sources. All the data needs to be properly cleaned, classified, and scoped so that the AI models do not reveal sensitive facts by mistake. This type of context leakage is common when prompts by one user retrieve another user’s private embeddings due to misconfigured access controls.

Embedding Inversion and Data Poisoning

Embedding Inversion occurs when embeddings in the vectors, which are essentially high-dimensional semantic relationships, are inverted, leading to the reconstruction of the original source text, compromising anonymity.
Data Poisoning occurs when malicious actors inject false or adversarial data through subliminal texts hidden in documents into a knowledge base accessed by the model, leading to erroneous or harmful responses.

In the concluding part of the series, I will discuss a potential solution in decentralized and privacy-first AI, along with a mention of working use cases of portable AI memory.

AI Has a Memory Problem. Decentralization and Privacy Might Have a Solution. Part 1

DC — Mon, 23 Feb 2026 06:21:45 +0000

We are on the cusp of an AI revolution. AI agents today are building social networks, negotiating contracts, and even contributing to creativity, like making music. All aspects of our lives are affected every day, as we can choose from a range of AI models and assistants for our interactions and experiences. But there is a chronic problem with AI that often flows under the radar. AI has a memory problem.

Anyone who uses an AI solution has faced it. It does not matter whether you are using Claude, GPT, or anything else; it does not matter whether you are a developer or an end user. If we ever need to switch models, we have to start again from scratch, rebuilding the context of our conversations every time. The same forgetfulness can also happen across different sessions or between different chats in the same model.

Here in this 3-part series, I will discuss what AI memory is, how it works, what types there are, the pain points regarding its architecture, and a potential solution through decentralization and privacy, with Oasis technology as a reference. I will also mention a few working use cases tackling the AI memory problem.
In the first part, I will cover AI memory and its classification.

What is AI memory?

AI memory is the ability of an AI system to retain, recall, and use information from past interactions. While human memory is associative due to being organic, AI associations come from data engineering and code-based architecture. In other words, Large Language Models (LLMs) do not and cannot remember anything. Every interaction is processed fresh. So, what appears to be memory is basically an association achieved through engineering and algorithms.

Human brain: a biological organ where memory is always on, where learning, remembering, and forgetting happen organically.
LLM: a codebase that learns and forgets, but can be made to remember by being given contextual refreshers manually or by smart engineering on a short-term basis.

The Context Window

Before expanding on the different types, it is useful to note that the context window is the most basic form of AI memory. This is quantifiable and measured in tokens or the amount of text that any given model can process in a single interaction. Approximately 150 tokens can constitute about 100 words. And every word in an interaction, those you send and those the AI responds with, together make up the context window limit.

How Context Works

Most conversations with an AI model consist of multiple prompts. What we do not know as an end user is that the system does not remember previous messages. So, what happens? The system typically resends the entire conversation history as part of each new request. Take this example.

You send “Hello” -> AI sees: [Hello]
You send “How are you?” -> AI sees: [Hello, AI reply, How are you?]
You send “Tell me about crypto” -> AI sees: [Hello, AI reply, How are you?, AI reply, Tell me about crypto]

As the conversation carries on, the token count also increases. On reaching the context window limit, the older messages get dropped. This is where AI forgetfulness and hallucination begin.

Context Window Sizes (Typical in 2025)

Any long, detailed conversation can thus stretch and exhaust even high token capacity models. That is why we need more advanced memory systems.

In 2026, the trends indicate that 1M+ token capacity is going to become common, with more focus on scale and performance. For example, top-tier models (e.g., potential Llama 4 iterations) can reach up to 10 million tokens.

Active Models:

Qwen3-Coder-480B: Designed for coding with a 256K to 1M token range.
Gemini 2.5 Pro: Offers 1M+ token windows, with 2M+ expected.
GPT-4.1 Turbo: 128K–1M tokens with advanced "Context Compression" to manage efficiency.

The context window size increase without "smarter" context management is, however, also problematic, as it can lead to "needle in a haystack" failures where models struggle while searching for specific information within a vast context.

The Taxonomy of AI Memory

The analysis of AI memory architecture reveals the various components according to their temporal duration and functional purpose. All modern systems use a multi-tiered memory hierarchy that can balance real-time processing speed with the need for vast, durable storage.

Working memory is at the vanguard of this architecture. Its capacity is limited and critical for achieving coherence through raw token processing and immediate inference building.
Short-term memory is the next stage that strings together working memory. It builds and maintains context across a specific session through sliding windows or summarization techniques.
Long-term memory is the embodiment of continuity. It can be externalized into durable storage systems, acting as an unbounded index of knowledge.
Interesting to note that long-term memory can encompass and go beyond procedural memory, which is fixed within learned logic and inference.

In the next part of the series, I will discuss at length the short-term and long-term AI memory, and also the security and privacy risks associated with AI memory architecture.

Guide To Cross-Chain Key Generation (EVM / Base) With Oasis ROFL

DC — Fri, 20 Feb 2026 12:26:19 +0000

Oasis introduced the framework for runtime off-chain logic (ROFL) to help build and run apps off-chain while ensuring privacy and maintaining trust with on-chain verifiability. There are many moving parts to building with ROFL.
In this tutorial, I will demonstrate how to build a tiny TypeScript app, generating a secp256k1 key inside ROFL. It will be using the @oasisprotocol/rofl-client TypeScript SDK, which talks to the appd REST API under the hood. The TypeScript app will also:

derive an EVM address
sign messages
deploy a contract
send EIP-1559 transactions on Base Sepolia

There will be a simple smoke test that prints to logs.

Prerequisites

To do the steps described in this guide, you will need:

Node.js 20+ and Docker (or Podman)
Oasis CLI and a minimum of 120 TEST tokens in your wallet (Oasis Testnet faucet)
Some Base Sepiola test ETH (Base Sepiola faucet)

For the setup details, please refer to the documentation on Quickstart Prerequisites.

Init App

The first step is to initialize a new app using the Oasis CLI.

oasis rofl init rofl-keygen
cd rofl-keygen

Create App

At the time of creating the app on the Testnet, you will be required to deposit tokens. Assign 100 TEST tokens at this point.

oasis rofl create --network testnet

As output, the CLI will produce the App ID, denoted by rofl1....

Init a Hardhat (TypeScript) project

Now, you are ready to kickstart the project.

npx hardhat init

Since we are showcasing a TypeScript app, choose TypeScript when prompted, and then accept the defaults.
Next step would be to add the small runtime deps for use outside of Hardhat.

npm i @oasisprotocol/rofl-client ethers dotenv @types/node
npm i -D tsx

Hardhat’s TypeScript template automatically creates a tsconfig.json. We need to add a small script so that the app code can compile to dist/.

// tsconfig.json
{
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist"
  },
  "include": ["src"]
}

App structure

In this section, we will add a few small TS files and one Solidity contract.

src/
├── appd.ts               # thin wrapper over @oasisprotocol/rofl-client
├── evm.ts                # ethers helpers (provider, wallet, tx, deploy)
├── keys.ts               # tiny helpers (checksum)
└── scripts/
    ├── deploy-contract.ts  # generic deploy script for compiled artifacts
    └── smoke-test.ts       # end-to-end demo (logs)
contracts/
└── Counter.sol           # sample contract

src/appd.ts — thin wrapper over the SDK
Here, you will need to use the official client to talk to appd (UNIX socket). We will also need to keep an explicit local‑dev fallback when running outside ROFL.

import {existsSync} from 'node:fs';
import {
  RoflClient,
  KeyKind,
  ROFL_SOCKET_PATH
} from '@oasisprotocol/rofl-client';

const client = new RoflClient(); // UDS: /run/rofl-appd.sock

export async function getAppId(): Promise<string> {
  return client.getAppId();
}

/**
 * Generates (or deterministically re-derives) a secp256k1 key inside ROFL and
 * returns it as a 0x-prefixed hex string (for ethers.js Wallet).
 *
 * Local development ONLY (outside ROFL): If the socket is missing and you set
 * ALLOW_LOCAL_DEV=true and LOCAL_DEV_SK=0x<64-hex>, that value is used.
 */
export async function getEvmSecretKey(keyId: string): Promise<string> {
  if (existsSync(ROFL_SOCKET_PATH)) {
    const hex = await client.generateKey(keyId, KeyKind.SECP256K1);
    return hex.startsWith('0x') ? hex : `0x${hex}`;
  }
  const allow = process.env.ALLOW_LOCAL_DEV === 'true';
  const pk = process.env.LOCAL_DEV_SK;
  if (allow && pk && /^0x[0-9a-fA-F]{64}$/.test(pk)) return pk;
  throw new Error(
    'rofl-appd socket not found and no LOCAL_DEV_SK provided (dev only).'
  );
}

src/evm.ts — ethers helpers

import {
  JsonRpcProvider,
  Wallet,
  parseEther,
  type TransactionReceipt,
  ContractFactory
} from "ethers";

export function makeProvider(rpcUrl: string, chainId: number) {
  return new JsonRpcProvider(rpcUrl, chainId);
}

export function connectWallet(
  skHex: string,
  rpcUrl: string,
  chainId: number
): Wallet {
  const w = new Wallet(skHex);
  return w.connect(makeProvider(rpcUrl, chainId));
}

export async function signPersonalMessage(wallet: Wallet, msg: string) {
  return wallet.signMessage(msg);
}

export async function sendEth(
  wallet: Wallet,
  to: string,
  amountEth: string
): Promise<TransactionReceipt> {
  const tx = await wallet.sendTransaction({
    to,
    value: parseEther(amountEth)
  });
  const receipt = await tx.wait();
  if (receipt == null) {
    throw new Error("Transaction dropped or replaced before confirmation");
  }
  return receipt;
}

export async function deployContract(
  wallet: Wallet,
  abi: any[],
  bytecode: string,
  args: unknown[] = []
): Promise<{ address: string; receipt: TransactionReceipt }> {
  const factory = new ContractFactory(abi, bytecode, wallet);
  const contract = await factory.deploy(...args);
  const deployTx = contract.deploymentTransaction();
  const receipt = await deployTx?.wait();
  await contract.waitForDeployment();
  if (!receipt) {
    throw new Error("Deployment TX not mined");
  }
  return { address: contract.target as string, receipt };
}

src/keys.ts — tiny helpers

import { Wallet, getAddress } from "ethers";

export function secretKeyToWallet(skHex: string): Wallet {
  return new Wallet(skHex);
}

export function checksumAddress(addr: string): string {
  return getAddress(addr);
}

src/scripts/smoke-test.ts — single end‑to‑end flow
This is an important step as this script has multiple functions:

print the App ID (inside ROFL), address, and a signed message
waits for funding
deploy the counter contract

import "dotenv/config";
import { readFileSync } from "node:fs";
import { join } from "node:path";
import { getAppId, getEvmSecretKey } from "../appd.js";
import { secretKeyToWallet, checksumAddress } from "../keys.js";
import { makeProvider, signPersonalMessage, sendEth, deployContract } from "../evm.js";
import { formatEther, JsonRpcProvider } from "ethers";

const RPC_URL = process.env.BASE_RPC_URL ?? "https://sepolia.base.org";
const CHAIN_ID = Number(process.env.BASE_CHAIN_ID ?? "84532");
const KEY_ID = process.env.KEY_ID ?? "evm:base:sepolia";

function sleep(ms: number): Promise<void> {
  return new Promise((r) => setTimeout(r, ms));
}

async function waitForFunding(
  provider: JsonRpcProvider,
  addr: string,
  minWei: bigint = 1n,
  timeoutMs = 15 * 60 * 1000,
  pollMs = 5_000
): Promise<bigint> {
  const start = Date.now();
  while (Date.now() - start < timeoutMs) {
    const bal = await provider.getBalance(addr);
    if (bal >= minWei) return bal;
    console.log(`Waiting for funding... current balance=${formatEther(bal)} ETH`);
    await sleep(pollMs);
  }
  throw new Error("Timed out waiting for funding.");
}

async function main() {
  const appId = await getAppId().catch(() => null);
  console.log(`ROFL App ID: ${appId ?? "(unavailable outside ROFL)"}`);

  const sk = await getEvmSecretKey(KEY_ID);
  // NOTE: This demo trusts the configured RPC provider. For production, prefer a
  // light client (for example, Helios) so you can verify remote chain state.
  const wallet = secretKeyToWallet(sk).connect(makeProvider(RPC_URL, CHAIN_ID));
  const addr = checksumAddress(await wallet.getAddress());
  console.log(`EVM address (Base Sepolia): ${addr}`);

  const msg = "hello from rofl";
  const sig = await signPersonalMessage(wallet, msg);
  console.log(`Signed message: "${msg}"`);
  console.log(`Signature: ${sig}`);

  const provider = wallet.provider as JsonRpcProvider;

  let bal = await provider.getBalance(addr);
  if (bal === 0n) {
    console.log("Please fund the above address with Base Sepolia ETH to continue.");
    bal = await waitForFunding(provider, addr);
  }
  console.log(`Balance detected: ${formatEther(bal)} ETH`);

  const artifactPath = join(process.cwd(), "artifacts", "contracts", "Counter.sol", "Counter.json");
  const artifact = JSON.parse(readFileSync(artifactPath, "utf8"));
  if (!artifact?.abi || !artifact?.bytecode) {
    throw new Error("Counter artifact missing abi/bytecode");
  }
  const { address: contractAddress, receipt: deployRcpt } =
    await deployContract(wallet, artifact.abi, artifact.bytecode, []);
  console.log(`Deployed Counter at ${contractAddress} (tx=${deployRcpt.hash})`);

  console.log("Smoke test completed successfully!");
}

main().catch((e) => {
  console.error(e);
  process.exit(1);
});

contracts/Counter.sol — minimal sample

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Counter {
    uint256 private _value;
    event Incremented(uint256 v);
    event Set(uint256 v);

    function current() external view returns (uint256) { return _value; }
    function inc() external { unchecked { _value += 1; } emit Incremented(_value); }
    function set(uint256 v) external { _value = v; emit Set(v); }
}

src/scripts/deploy-contract.ts — generic deployer

import "dotenv/config";
import { readFileSync } from "node:fs";
import { getEvmSecretKey } from "../appd.js";
import { secretKeyToWallet } from "../keys.js";
import { makeProvider, deployContract } from "../evm.js";

const KEY_ID = process.env.KEY_ID ?? "evm:base:sepolia";
const RPC_URL = process.env.BASE_RPC_URL ?? "https://sepolia.base.org";
const CHAIN_ID = Number(process.env.BASE_CHAIN_ID ?? "84532");

/**
 * Usage:
 *   npm run deploy-contract -- ./artifacts/MyContract.json '[arg0, arg1]'
 * The artifact must contain { abi, bytecode }.
 */
async function main() {
  const [artifactPath, ctorJson = "[]"] = process.argv.slice(2);
  if (!artifactPath) {
    console.error("Usage: npm run deploy-contract -- <artifact.json> '[constructorArgsJson]'");
    process.exit(2);
  }

  const artifactRaw = readFileSync(artifactPath, "utf8");
  const artifact = JSON.parse(artifactRaw);
  const { abi, bytecode } = artifact ?? {};
  if (!abi || !bytecode) {
    throw new Error("Artifact must contain { abi, bytecode }");
  }

  let args: unknown[];
  try {
    args = JSON.parse(ctorJson);
    if (!Array.isArray(args)) throw new Error("constructor args must be a JSON array");
  } catch (e) {
    throw new Error(`Failed to parse constructor args JSON: ${String(e)}`);
  }

  const sk = await getEvmSecretKey(KEY_ID);
  // NOTE: This demo trusts the configured RPC provider. For production, prefer a
  // light client (for example, Helios) so you can verify remote chain state.
  const wallet = secretKeyToWallet(sk).connect(makeProvider(RPC_URL, CHAIN_ID));
  const { address, receipt } = await deployContract(wallet, abi, bytecode, args);

  console.log(JSON.stringify({ contractAddress: address, txHash: receipt.hash, status: receipt.status }, null, 2));
}

main().catch((e) => {
  console.error(e);
  process.exit(1);
});

Hardhat (contracts only)

At this stage, we will need minimal config to compile Counter.sol

hardhat.config.ts

import type { HardhatUserConfig } from "hardhat/config";

const config: HardhatUserConfig = {
  solidity: {
    version: "0.8.24",
    settings: {
      optimizer: { enabled: true, runs: 200 }
    }
  },
  paths: {
    sources: "./contracts",
    artifacts: "./artifacts",
    cache: "./cache"
  }
};

export default config;

Point to note is that local compilation is optional, so you can skip it if you want. Next step is a choice - either delete the existing contracts/Lock.sol file or you can update it to Solidity version 0.8.24.

npx hardhat compile

Containerize

This is an essential step. Here, you need to a Dockerfile that builds TS and compiles the contract. The file will also run the smoke test once, and then stand idle while you inspect logs.

Dockerfile

FROM node:20-alpine
WORKDIR /app

COPY package.json package-lock.json* ./
RUN npm ci

COPY tsconfig.json ./
COPY src ./src
COPY contracts ./contracts
COPY hardhat.config.ts ./
RUN npm run build && npx hardhat compile && npm prune --omit=dev

ENV NODE_ENV=production
CMD ["sh", "-c", "node dist/scripts/smoke-test.js || true; tail -f /dev/null"]

Next, you must mount appd socket provided by ROFL. Rest assured that no public ports are exposed in the process.

compose.yaml

services:
  demo:
    image: docker.io/YOURUSER/rofl-keygen:0.1.0
    platform: linux/amd64
    environment:
      - KEY_ID=${KEY_ID:-evm:base:sepolia}
      - BASE_RPC_URL=${BASE_RPC_URL:-https://sepolia.base.org}
      - BASE_CHAIN_ID=${BASE_CHAIN_ID:-84532}
    volumes:
      - /run/rofl-appd.sock:/run/rofl-appd.sock

Build the image

It is important to remember that ROFL only runs on Intel TDX-enabled hardware. So, if you're compiling images on a different host, such as macOS, then passing the --platform linux/amd64 parameter is an essential extra step.

docker buildx build --platform linux/amd64 \
  -t docker.io/YOURUSER/rofl-keygen:0.1.0 --push .

An interesting point to note here is that you can opt for extra security and verifiability. You just need to pin the digest and use image: ...@sha256:... in compose.yaml.

Build ROFL bundle

There is a step that you must take before running the oasis rofl build command. Since building the image segment comes after containerization, you will need to update the services.demo.image in compose.yaml to the image you built.
For simple TypeScript projects, like this one, there is sometimes a possibility that the image size is larger than anticipated. It is thus advisable to update the rofl.yaml resources section to at least: memory: 1024 and storage.size: 4096.
Now, you are ready.

oasis rofl build

You can next publish the enclave identities and config.

oasis rofl update

Deploy

This is an easy enough step where you deploy to a Testnet provider.

oasis rofl deploy

End‑to‑end (Base Sepolia)

This is a 2-step process, although the second step is optional.
First, you view smoke‑test logs.

oasis rofl machine logs

If you have completed all the steps till now correctly, you will see in the output:

App ID
EVM address and a signed message
A prompt to fund the address
Once funding is done, a Counter.sol deployment

Next, local dev. Here, you need to run npm run build:all command to compile the TypeScript code and the Solidity contract. Skip this step if not needed.

 export ALLOW_LOCAL_DEV=true
 export LOCAL_DEV_SK=0x<64-hex-dev-secret-key>   # DO NOT USE IN PROD
 npm run smoke-test

Security & notes to remember

Provider logs are not encrypted at rest. So, **never **log secret keys.
The appd socket /run/rofl-appd.sock exists only inside ROFL.
There may be rate limits in public RPCs. So, it is advisable to opt for a dedicated Base RPC URL.

There is a key generation demo in the Oasis GitHub, which you can refer to as an example of this tutorial. https://github.com/oasisprotocol/demo-rofl-keygen

Now that you have successfully generated a key in ROFL with appd, signed messages, deployed a contract, and moved ETH on Base Sepolia, let us know in the comments section your feedback. 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.

Developing in Web3: Deploying Privacy-First dApps with Sapphire + ROFL

DC — Tue, 20 Jan 2026 06:28:08 +0000

TL;DR

Sapphire provides confidential EVM smart contracts. OPL lets existing dApps add privacy without migrating chains.
ROFL enables verifiable, privacy-preserving off-chain computation.
Together, Sapphire + ROFL form a full stack for building private, AI-ready web3 applications.

The crypto landscape today is flooded with web3 and AI dApps (decentralized applications). You need to choose the right chain and the right tools to develop and deploy your dApp, as it can make all the difference in attracting the right attention from the end-users. The choices are too many, and they often distract more than add value. It is also hard to come by solid, reliable information to make a decision.

I believe in Oasis as a pioneer of smart privacy for web3 and AI. Let me tell you point by point why I became a believer.

The Tech Stack: Sapphire EVM

In the blockchain trilemma scene, privacy has always taken the backseat, as most protocols emphasize decentralization and scalability. And then there is the debate and confusion of how to frame the rising privacy narrative - is it privacy coin or privacy blockchain?

Oasis has emerged as a pioneer in the field of smart privacy. It is a modular L1 blockchain that aims to finally complete the blockchain picture - decentralization, scalability, and privacy (and security) together.

Privacy-preserving techniques have garnered much attention in recent times. Long before zero-knowledge proofs (ZKPs), fully homomorphic encryption (FHE), and secure multiparty computation (sMPC) became trending, Oasis had adopted trusted execution environments (TEEs) for end-to-end encryption and confidential computation.

In Oasis Sapphire, you get the world's first and only production-ready confidential EVM. Its key features help you build better dApps that are privacy-first.

EVM compatibility
Private storage
Encryption precompiles
Free view calls
Web2 authentication
ROFL (runtime off-chain logic)

So, as a web3 developer, you get to work with smart privacy, cross-chain simplicity, and low technical overhead. How it differs from most other projects also offering privacy solutions is that you get the best of both worlds here - transparent when you need it, confidentiality when it matters. Further, you can build with full spectrum of confidentiality customization - 100% public to 100% private or anywhere in between.

Deployed already? Use the OPL hack

But what happens if you have already built your dApp on another EVM chain? It is unfeasible to dismantle everything there and start rebuilding from scratch for the sake of privacy. Acknowledging this dilemma, Oasis offers the services of the Oasis Privacy Layer (OPL).

OPL is simple to use - a few hundred lines of code, practically a plug-and-play solution. Behind the scenes, it uses a message passing bridge and a gas relayer.

It gives the flexibility to leverage Sapphire's features and functionalities for your dApp right from your home network, paying transaction fees with your chain's native token. What you assuredly get from this setup:

Customizable privacy
Cross-chain convenience
Productive transparency
Low complexity
Access to cryptographic primitives

Learn more about OPL's technical advantage and utility here, and start building.

The Framework: ROFL

Now, Sapphire is the runtime on-chain logic, but computation-heavy dApps, with end-to-end encryption and/or powered by AI, are a huge challenge. When you add the criteria that the privacy you get and the computations you process should be verifiable and trustless, the feasibility of doing everything on-chain plummets.

The challenges mount when dealing with cryptoAI, as it has two main problems - crypto's limited application layer and AI's trust issues. Off-chain computation is a viable answer in this situation. Oasis has thus developed the ROFL framework, essentially working like a decentralized TEE cloud with on-chain privacy and verifiability.

ROFL's 5-part architecture involves a hardware layer, an application layer, a remote attestation layer, a blockchain layer, and a user interaction layer. Key features include:

Uncapped computational power
Tamper-proof processing
Verifiable execution
Decentralized key management solution
Direct access to confidential virtual machines

The reason ROFL is so crucial and pivotal to the next-gen private and trustless web3 and AI dApps can be simply summed up by what it doesn't need, which you will definitely appreciate.

No chain dependency
No coding language dependency
No prior TEE experience

Start exploring the scope of ROFL with these resources:

Real-World Integrations

The applicability of the Sapphire + ROFL solution, with its impact and scope, is limitless. The features and primitives that ROFL unlocks are also significant.

Already, multiple live collaborations have transpired.

Zeph - developing AI companions empowered by DeAI and DeCC
Tamarin - empowering secure and private cross-border healthcare data analysis
Tradable - trading with privacy-preserving AI insights
Flashback - privacy-first AI training that lets users own and monetize their data
Plurality - confidential reputation scoring and AI context flow
Talos - combining DAO 2.0 and DeFAI in the form of a new model for on-chain sovereign intelligence
zkAGI - building PawPad, a privacy-preserving platform for trustless trading agents
Heurist - enabling privacy-first MCP servers for AI agents
Huralya - building private AI wellness assistants
Carrotfunding - servicing on-chain prop trading, introducing a new model for parallel verification of the risk and evaluation engine

Talos and Carrotfunding here deserve special focus, standing out as pathbreaking case studies redefining DeFi.

Final words

The takeaway from all this is that what Oasis offers to blockchain and web3 developers is not just some concept - it's something real and tangible.
In a space where half-baked or well-intentioned ideas sound promising but often don't deliver in their execution, a working blueprint for next-gen dApp builders stands out.

So, if you want to deploy your dApp in a web3 universe where privacy, scalability, trustlessness, and AI-ready performance all matter equally, take a moment to explore Oasis - and help shape what comes next.

Verifiable On-Chain Prop Trading & the Emergence of Trustless Market Infra: A Case Study

DC — Mon, 19 Jan 2026 13:44:45 +0000

TL;DR

Prop trading relies on opaque risk engines that traders cannot verify.
This creates structural incentives for payout denial and abuse.
Carrotfunding introduces parallel verification with Oasis ROFL to audit AWS-based execution.
The result is a hybrid architecture that brings verifiable compute, privacy, and trustless settlement to prop trading.

Introduction

Decentralized trading is one of the most popular applications of cryptocurrency technology. Have we become stagnant in our approach? For example, proprietary (prop) trading, despite being a $60 billion industry, faces a verification crisis common in the modern financial landscape.

Aspiring traders seek capital from centralized institutions. However, an opaque “black box” operational model widens the gap between the industry's assurances that skill earns reward of capital and the reality where proving performance and worthiness is erratic and arbitrary.

The web2 paradigm adjudicates trader performance and rewards on private servers that are not auditable. Moreover, the evaluating firms profit more when traders fail, as it means there is less capital disbursement.

Decentralized finance (DeFi) has blockchain's built-in transparency to solve the blind spots of the traditional web2 approach. However, adoption has been low over the years because on-chain trading has failed to match the speed and complex solutions that traditional institutional finance (TradFi) offers.

In this post, I will refer to the Carrotfunding case study to examine how it can serve as an example of an emergent trustless market infrastructure. I will first demonstrate the gaps in the incumbent systems, and then show how a framework like Oasis ROFL can elevate the process by bringing decentralization, verifiability, and privacy to the table.

Black Box Evaluation Engine

The evaluation engine is the backbone of any prop trading firm. This software logic monitors trader activity, calculates real-time equity, enforces parameters and limitation criteria, and, finally, approves or denies payout requests. Private cloud infrastructure, like AWS, Azure, etc hosts such a risk engine with its access and management entirely in the firm's discretion.

Sounds simple and is "trusted", right? But the traders can never verify the validity of the metrics on which they are observed and evaluated. Let's now take a look at how ambiguity in rules and retroactively applied rules can result in most payout denials.

Consistency Rule Exploitation

A common practice among firms is that a trader's most profitable day cannot exceed a certain percentage of their total profit. This creates an untenable bind for traders when centralized databases can arbitrarily change risk parameters and payout criteria without explicitly detailing them beforehand.

B-Book Model

A-Book is when the broker passes a trade to the market involving live liquidity providers and earns a commission.
B-Book is when the broker keeps the trade internal, where the firm acts as the counterparty to every trade. The broker here keeps the deposit if the trader loses money, and pays out of pocket if the trader wins.

The B-Book model creates an incentive system where a profitable trader becomes a liability. So, the incentive is on the firm to disqualify traders and disadvantage them, and without a verifiable infrastructure, regulators cannot do much.

Liquidity Illusion in Tokenization

Blockchain technology's initial solution of tokenizing trader performances is more theoretical than practical. Tokenization of trading activities can lead to an illusion of liquidity unsupported by reality. So, tokenization that lacks a robust legal and technical framework can result in zombie assets - tokens exist on-chain, but there is no genuine liquidity market or a reliable mechanism for value accrual.

Carrotfunding Case Study: Architecture and Implementation

Carrotfunding, even before integrating Oasis ROFL, had already implemented web3 solutions for its prop trading venture. Its on-chain liquidity adopts the Arbitrum's gTrade solution for trade execution, while utilizing Rethink Finance for on-chain investment vehicles with gamification mechanics and vault transparency for capital safety.

This takes care of the execution layer and the capital layer, but what happens to the verifiable compute and security layer? This is the domain of Oasis ROFL, and deserves a closer look.

Parallel Verification Model (Phase 1)

In this phase, Carrotfunding continues to use AWS infrastructure for its platform and strengthens it with parallel verification with an ROFL-based auditor. The workflow unfolds in five stages.

A trader executes a trade on the gTrade platform via the Carrotfunding interface.
This bifurcates into two distinct paths:
- Legacy: The trade data goes to Carrot’s AWS execution engine.
- ROFL: The data simultaneously goes to the ROFL node network.
The computation takes place independently.
- AWS calculates the impact on the trader's account, for example, the trader's daily profit and loss statement.
- ROFL, running inside a trusted execution environment (TEE), performs the same evaluation using the same code logic.
ROFL provides attestation and verifiability through comparison. This is based on the cryptographic proof generated from its calculation and submitted on-chain, where both the AWS and the ROFL results are matched.
The finality of the process is provided by ROFL. If the two results match, no problem. If they differ, then ROFL's result, having cryptographically verifiable proof, is accepted over the AWS result, which might be potentially compromised or based on an erroneous database.

The “Trustless AWS” Paradigm

We can call this architecture “Trustless AWS”. ROFL, often described as a decentralized TEE cloud, enables the best of both worlds in terms of developer experience - the benefits of a centralized cloud, involving deployment of Docker containers and running complex logic, while also having the advantages of the security properties of a blockchain.

A comparison of the computational models will clarify further.

Proxy-Based Frontend Hosting

Carrotfunding utilizes the ROFL primitive called proxy-based frontend hosting. Typically, a decentralized application (dApp)'s smart contract logic is on-chain, but the website, which is the frontend, is still hosted in a centralized cloud provider, for example, AWS. So, if the cloud server goes down, the UI is also down.

With ROFL, Carrotfunding can host the frontend inside the TEE. As a result, the node can automatically provision TLS certificates using a built-in ACME client inside the secure enclave. There is also end-to-end security as a user's connection via SSL terminates only inside the TEE. This protects user privacy, shielding IP addresses and login patterns from the node operator and infrastructure provider.

Secret Management and Proprietary IP

For any prop trading firm, keeping its internal risk algorithms secret is how it stays competitive. Full transparency of blockchain technology is counterproductive in this regard. The smart privacy feature of Oasis technology ensures that both transparency and confidentiality can co-exist.

So, with the code running inside the TEE, Carrotfunding can keep its algorithms private. Here, the hash of the code is accessible publicly for verification, but the source code remains encrypted, out of public viewing scope, and unrevealed to the node operator.

Security: Threat Model and Defense

Integrating TEE often opens up the question of security, as the SGX/TDX technology can succumb to various vulnerabilities.

Side-Channel Attacks: This is mitigated in two ways. The ROFL framework ensures that the latest microcode patches from Intel are used. So, any node that is found without a TEE trusted computing base (TCB) update is rejected by Oasis's confidential runtime on-chain logic, Sapphire's registry. Also, using “data-oblivious” code helps block pattern analysis of memory access.
Oracle Manipulation: This is mitigated by simultaneous TLS connections to multiple independent data providers for the price feed, computed inside the enclave for the median price, used to evaluate instead of relying entirely on a single on-chain oracle update.
Key Leakage: This is mitigated by a decentralized key management system where the master key is sharded across multiple nodes. So no single node ever possesses the full key. Also, ROFL enables ephemeral keys so that they exist only in volatile memory and will be wiped and lost whenever the enclave restarts or if any tampering is ever attempted.

In addition, the adoption of consensus as a verifier by a Byzantine Fault Tolerance (BFT) network like Oasis ensures that all potential gaps in remote attestations of the TEEs are addressed.

The Verifiability X-factor

This is crucial in understanding the role Oasis ROFL plays in upgrading the risk engine of Carrotfunding from what traditional models can provide. Any user can, therefore, audit the system by using the command:

oasis rofl build –verify

Reproducible builds allow users to download the source code, compile it locally using the deterministic build environment provided by Oasis, and obtain the MRENCLAVE hash.
Users can then query the Sapphire runtime for an on-chain check if their generated hash matches the one registered by active nodes. If yes, it is the immutable proof that the code on GitHub is the code running on the server.

From Prop Trading to Autonomous Agents (Phase 2)

Integrating Oasis ROFL to verify the AWS risk engine by Carrotfunding is just the stepping stone to a paradigm shift in prop trading. It aims to evolve into a self-sustaining infrastructure that can ultimately replace the AWS system altogether.

This full decentralization mode becomes viable only after there is sufficient stability and enough node operators in place to guarantee 99.99% uptime. With the transition to a ROFL-first architecture, the Carrotfunding platform can then use only ROFL nodes to authorize Rethink Finance's capital layer for fund release.

The evolution of the platform's architecture and functionality into autonomous trading agents is also part of the future roadmap. This envisions a marketplace for verifiable intelligence, where the AI agents compete for capital in a trustless environment, protected by the privacy guarantees of Oasis and the settlement assurances of Arbitrum.

Decentralized Identity (DID) is another key area to explore since ROFL can process sensitive personal data (KYC documents) inside the enclave to verify a trader’s identity and reputation score.

Conclusion

The study suggests that DeFi can hold its own against TradFi, which had a historical monopoly in the prop trading market. Now, there is a live example of how the limitations of web2 finance, where asset management meant opaque computation logic, can be improved with web3's verification layer to prove the process.

By removing trust assumptions and plugging the trust gap, Carrotfunding has engineered a system that aligns the incentives of traders, capital providers, and the platform itself. We now await the full decentralization and agentic future for on-chain prop trading, redefining the standards of transparency, security, and efficiency for the next-gen trustless digital asset market.

Resources referred:

Why I Believe Verifiable TEEs Can Become Essential For Blockchain Security & Privacy

DC — Thu, 15 Jan 2026 11:33:57 +0000

Last year, I began digging seriously into trusted execution systems (TEEs) as a foundation for blockchain security systems and as a privacy-preserving technique. The findings convinced me of the viability of TEEs. First, I will briefly recap my reasoning and then share fresh evidence that bolsters my belief in verified TEEs.

Privacy scorecard: TEEs and others

For a long time, thanks to the penchant for zero-knowledge proofs (ZKPs) by Ethereum and other L2s, TEEs remained in the periphery. With other privacy solutions as options in the mix, too, TEEs captured the attention of very few.

This perception has, gradually but surely, been changing with research demonstrating that TEEs play a crucial role as the optimal infrastructure in building the next-gen web3 and AI.
The success and popularity of the five editions of the Afternoon TEE Party - Devcon Bangkok in late 2024, and ETHDenver, Token2049 Dubai, EthCC Cannes, and Devconnect Buenos Aires across 2025 also are testament to how TEEs are finding recognition and acceptance steadily.

Remote Attestation: Integral TEE Component

How TEEs function is as simple as the image above. But verifiability is always essential, and this is where remote attestations come in. Attestation in tandem with reproducible builds critically enhances the integrity and trust for TEEs. So, you know that software built from the same source code always produces identical binaries.

We all know virtual machines (VMs) and cryptography are the backbone of blockchain technology, and the crux of the matter is that protocols need remote attestation to mitigate vulnerabilities. Oasis Foundation Director, Jernej Kos, did a deep dive technical analysis on the remote attestation process.

Attestation Is Not Enough

This is new research and consolidates how TEEs stand the test of being a prominent player in blockchain security and privacy. It underlines how attestation needs to be fortified with other aspects to make TEEs truly formidable.

What we get from TEEs are facts, and they are undisputed.

Privately run code with all fully-encrypted off-chip state gives isolated execution.
Cryptographic keys built in the CPU itself, used to encrypt data and sign attestation messages gives per-CPU root of trust.
Proof of a specific binary code running in a specific enclave from remote attestation, as mentioned.

Let's now examine why attestations may fall short of expectations, what the missing pieces are that need to be addressed, and a potential solution.

What Attestation Actually Proves

Now, unless you are a hardware security expert, verifying an SGX/TDX quote is a stiff challenge. It will involve parsing a multi-KB binary blob, extracting fields, fetching collateral, checking FMSPC, interpreting TCB status, validating cert chains, etc. And, all this leaves the entire security model at risk of collapse at any point.

Let's assume that you have managed to execute the whole process without failure, but still, the fact remains that the validation is true only for one moment, and not guaranteed for other times when the verification is not run:

So, the measurement was correct then
The hardware TCB was acceptable then
The quote presented by the operator was then

None of the assumptions in the right column is the default. This means what we usually get are the presentation of raw attestation data and a row of green checkmarks in the name of verification. So, the burden of proof simply rests on the user, and anyone who isn't an expert simply doesn't know any different.

Missing Pieces & Possible Solution

At least half a dozen critical gaps can often be found when taking a deep dive into any TEEs these days that claim to be verified.

Freshness & Liveness: A quote, once validated, is not refreshed automatically, and the old, pre-verified one is used unless a new one is specifically called for.
State Continuity & Anti-Rollback: Only by anchoring the enclave to a live ledger as the timekeeper can it be ascertained that the data is current for the attested code, and not the case where a malicious host simulates live data by restarting an enclave and feeding it an older version of its encrypted state.
TCB governance: As demonstrated by recent security exploits, manufacturers, like Intel in this case, might consider physical attacks (wiretapping, battering ram) out of scope. This calls for stricter threat models for verifiers, where continuous policy checks and additional on-chain measures can plug the trust gap left by outdated or insecure "trusted" CPUs.
Operator Binding: Attestation verifies what is running in the code, but there is no accountability for who is running that code. Binding the hardware’s cryptographic identity to a slashable, on-chain operator identity with economic cost for malicious acts can be the answer here.
Upgrade history: A transparent history must be a prerequisite to guarantee data confidentiality. It basically means that only a current secure version is not enough; there must be a track record of valid attested versions to check the code continuity, bug fixes and all.
Code Provenance: I already mentioned reproducible builds earlier. Without someone being able to independently compile the code and verify that its hash matches the deployed version, attestations are incomplete.
Policy enforcement: Only clearly defined policies and their enforcement can define without ambiguity what verified TEEs mean - which binary should run, which hardware is acceptable, re-attestation frequency, approved locations, etc.

Consensus as Verifier

The discussion so far underlines that the architectural design of the TEEs needs sufficient infrastructure support that addresses the gaps, and does it all automatically. A Byzantine Fault Tolerance (BFT) attestation-verifier network is very handy in this respect.

This takes into consideration that while every client parsing every code all the time might be ideal, that is not feasible. So, what then? The BFT model, where trust in attestation validity is established by the consensus of many. The process would be like this:
-> Stake-bearing, slashable nodes submit enclave attestations and verification evidence
-> A fault-tolerant set of validators collectively verifies hardware TCB, measurements, policies, freshness, etc
-> Consensus agreement on verified identities, operators, and attestation policies becomes the on-chain state

When it is made open for anyone to verifiably query the on-chain state, attestations stop being static and complex, and become usable on-chain signals.

Final words

Oasis is a prime example of the type of BFT attestation-verifier network I have been talking about. The fact is that it's just one example, but the principle applies more generally to all who use TEEs.

So, what makes TEEs truly secure enclaves? When we move away from mere isolated black boxes, and implement processes to get integrated, verifiable components within larger trust systems.

As a matter of fact, all this can go beyond simple attestations checks, and what I described for on-chain can be extended to trusted off-chain applications. But that is a story for another day.

ERC-8004 Brings Flexible Trust Models; Oasis ROFL Plugs The Gap

DC — Tue, 23 Dec 2025 06:22:51 +0000

TL;DR

Autonomous agents working in silos create incompleteness
Agent-to-Agent (A2A) is great in theory, but full of trust assumptions
ERC-8004 standardizes agent discovery and ideates flexible trust models, still missing out on security responsibility
ROFL stands up with a secure compute layer that implements trustlessness and verifiable privacy

Problem Statement

The rise of autonomous agents is all around us. Today, I will talk about the decentralized AI landscape. I think we can all agree that when everyone builds their own solutions without interacting with each other, it only leads to problems like siloed agent frameworks, marketplaces with incompatible schemas, etc.

Google's A2A starts the conversation on collaboration, as it was donated to Linux. But it has its own set of default trust assumptions, and its functionality is also limited within organizational boundaries.

So, how do we solve this? ERC-8004 is the answer.

Defining ERC-8004

ERC-8004 is the proposed standard that defines a discovery framework for autonomous AI agents on Ethereum. It builds upon A2A in a simplistic design. It consists of 3 on-chain registries serving as the basic primitives for flexible trust models. They lay the groundwork for agents to find, evaluate, and interact with each other trustlessly.

It is important to understand here that it is not enough. Why? Because the standard does not try to solve the concept of "trust" and only facilitates visibility. So, as a developer, you are left to choose any method to suit your needs. This is what a bootstrapping of the agent economy looks like. Here, discovery and trust emerge organically, but without the complex on-chain logic to guide it, there is no mandatory implementation criteria.

I will discuss this gap again later; for now, let us elaborate on what the standard does talk about at length.

Core Registries & Flexible Trust Models

The 3 core registries ERC-8004 introduces are:

Identity - Agents get a unique ID, an address, and a domain pointer. Their capabilities are stored off-chain in a JSON file. As a developer, you can register on-chain; however, the agent's skillsets, along with supported protocols and trust models, stay off-chain, flexible, and ready to update as and when needed.
Reputation - Whenever agents accept any task, by default, they pre-authorize the clients to leave feedback. What it signifies is that, irrespective of the fact that the actual data is off-chain, the authorization produces a permanent on-chain audit trail. This enables you, as a developer, to be able to go through the feedback and build your own reputation algorithms. Pretty nifty!
Validation - There are two independent validation mechanisms, and the agents can choose either.
a. crypto-economic validation - Here, validators stake capital and re-execute computations. However, if the validation turns out to be incorrect, the validators get penalised through slashing.
b. cryptographic validation - Here, privacy-preserving techniques like trusted execution environments (TEEs) and zero-knowledge proofs (ZKPs) provide correct execution and enable confidentiality.

The greatest USP of the ERC-8004 standard is how it defines the trust models as flexible. This is because the validation registry stays agnostic to implementation, without any preference or bias.

So, for simple tasks, the feedback model accumulates social consensus and provides the basic security as needed. For more complex tasks, such as financial transactions, however, one of the two validation methods outlined above would need to be chosen.

Is this tiered approach for matching the security level to the use case sufficient? Short answer, no.

The limitations of this system are fairly evident. The standard's minimalism fosters flexibility, but at the cost of low security and high risk when threats become increasingly complex. It will simply fail against MEV-style attacks on domain registration, feedback manipulation through missing authorization checks, and storage exhaustion from unbounded validation.

Validating With TEEs

As promised, in this section, I will emphasize how to plug the gaps that ERC-8004, despite its best intentions, leaves. I have already mentioned TEEs as one of the major ways of validating with the cryptographic method. Oasis is ideally positioned to step in here thanks to its runtime off-chain logic (ROFL) framework.

ROFL essentially functions as a decentralized TEE cloud, providing verifiable integrity to all computations. Agents execute inside secure enclaves that generate tamper-proof cryptographic attestations. And everything is verifiable on-chain. For sensitive AI workloads, ROFL processes data confidentially while ensuring correct execution.

Why I think ROFL is a great fit for adding value to the ERC-8004 standard is that it goes beyond basic validation and enables stronger trust minimization and greater autonomy for the agents.
It does so with primitives like decentralized key management, multi-chain wallet control, proxy support for frontend hosting, and a decentralized compute marketplace with granular control over who runs the agent and under what policies.

Adopting ERC-8004

As you may have gauged by now, ERC-8004, while very promising, is still in the early phase. You have to admit the problem it set out to solve and somewhat does, and, when paired with ROFL, the powerhouse it can potentially become is exciting. The scope of utility is wide-ranging with far-reaching impact.

You think of MCP support for broader compatibility, NFT-based agent ownership using ERC-721, more flexible on-chain data storage for reputation, cleaner integration with the x402 payment protocol - ERC-8004 can provide standardisation for all that.

In fact, with x402 already live in A2A, stewarded by the x402 Foundation and backed by Coinbase/Cloudflare, the distribution opportunity is not limited to Ethereum alone.
Remember that Cloudflare powers approximately one-fifth of all websites. So, its full-fledged support of x402 as the A2A payment primitive is already finding adoption, enabling a growing agent economy. The reason is simple - once discovery and trust are addressed, payments are the logical next piece of the puzzle. But this is a whole other story that would need to be told elsewhere.

Final Words

Bringing back focus on ERC-8004 as a standard, I believe there is still much room for improvement. Each implementation is also looking to test and prove out different trust models to further strengthen the standard.
If you are interested, you can check out the builder program in place. It is designed to support teams working on everything from DeFi trading agents to code review services to gaming.

In conclusion, ERC-8004 provides standardized identity and validation. A solid technical foundation for verifiable AI agents, using TEEs or ZKPs or a combination of both, is also in place already. Together, this heralds a new age of agents than we have been experiencing till now.

References

Oasis Resources

Oasis Academy course
ROFL a. Docs b. GitHub c. App
Sapphire a. Docs b. GitHub
CLI a. GitHub b. Homebrew

Not to be missed!

DC — Mon, 22 Dec 2025 07:34:29 +0000

TEEs As Digital Sanctums - Architectural Resilience In Untrusted Environments

DC ・ Oct 21

#blockchain #cryptography #privacy #tee