Forem: Manav

Building Privacy-First Web3 & AI Apps with Oasis Sapphire and GetBlock

Manav — Sun, 25 Jan 2026 16:10:00 +0000

As AI-driven applications move onchain, one issue keeps resurfacing: how do you handle sensitive data without breaking decentralization or compliance? Most EVM chains expose all state by default, which makes them a poor fit for identity, AI agents, and regulated DeFi.

This is where Oasis Network and GetBlock come together.

GetBlock now supports Oasis Sapphire, Oasis’s confidential EVM runtime, making it easier for developers to deploy privacy-aware smart contracts and AI-enabled applications using familiar tooling.

Why Oasis Sapphire Is Different

Oasis Sapphire is a production EVM with programmable privacy built in. Developers can choose which parts of state or execution are confidential, instead of forcing everything to be public or fully private.

Key technical properties:

Smart contracts run inside Trusted Execution Environments (TEEs)
Sensitive inputs and state remain encrypted end-to-end
Privacy is optional and composable, not all-or-nothing
Solidity-compatible, no custom language required

This makes Sapphire particularly well-suited for:

AI agents handling proprietary strategies or user data
Identity and access control systems
Compliance-aware DeFi
Applications that require private logic but public settlement

What GetBlock Adds for Developers

With GetBlock’s Oasis support, developers don’t need to self-host or manage infrastructure to get started.

You get:

JSON-RPC and WebSocket endpoints
Mainnet and Testnet access
Shared or dedicated nodes
Archive data support
99.9%+ uptime SLA

From a workflow perspective, this means you can plug Oasis Sapphire into existing tooling (Hardhat, Foundry, wallets, indexers) the same way you would with any other EVM chain.

Privacy Meets UX and Security

Oasis’s privacy model also extends to user authentication. Sapphire supports modern security patterns like:

Passkeys
TouchID / biometric auth
TOTP-based 2FA

This makes it possible to build applications where users don’t need to choose between usability, privacy, and compliance.

When Does This Matter?

If your application:

processes sensitive user inputs
runs AI or agent logic onchain
needs selective disclosure instead of full transparency
targets enterprise or regulated environments

then a confidential EVM is no longer a “nice-to-have,” it’s infrastructure.

With GetBlock providing managed access to Oasis Sapphire, the barrier to building these systems drops significantly.

Final Thoughts

Web3 and AI are converging quickly, but most onchain environments were never designed for private computation. Oasis Sapphire fills that gap by bringing confidentiality to the EVM itself, and GetBlock makes it accessible without operational overhead.

For developers building the next generation of AI-driven, privacy-aware dApps, this combination is worth a serious look.

Docs and RPC access are available directly via GetBlock’s Oasis integration.

checkout more about it here: https://getblock.io/nodes/oasis/

Why Portable AI Memory Needs Confidential Compute?

Manav — Sun, 25 Jan 2026 16:00:14 +0000

AI models are getting better at reasoning, but their memory model is still fundamentally broken. Context is siloed per provider, tied to proprietary storage, and lost the moment you switch tools. For developers working across agents, IDEs, and models, this isn’t just annoying, it’s a hard architectural limit.

Crypto-native infrastructure offers a way out, and this is where Oasis Network becomes particularly relevant.

The Structural Problem: Stateless Intelligence

Most LLMs are effectively stateless. They infer from a bounded context window and discard everything else. Increasing context size helps marginally, but doesn’t solve the core issue: there’s no durable, user-owned memory layer that models can safely and selectively access.

Instead, memory is emulated via:

chat logs
proprietary retrieval systems
provider-controlled embeddings

From a systems perspective, this creates tight coupling between memory, model, and vendor which kills portability and composability.

Why Centralized AI Memory Fails

Treating memory as a platform feature introduces several problems developers already recognize:

Lock-in: memory only works inside one provider’s ecosystem
Opaque access: no clear guarantees on how memory is processed
Compliance risk: centralized storage becomes a liability
No interoperability: switching models resets accumulated context

For agents or long-lived workflows (trading strategies, coding styles, research context), this is a dead end.

Reframing Memory as Confidential Infrastructure

The real challenge isn’t storing memory, it’s processing it safely.

A usable AI memory layer must support:

user ownership of data
selective disclosure
confidentiality during inference
verifiable execution

This is exactly the problem space Oasis was designed for.

Oasis provides confidential compute, where data remains encrypted not just at rest, but during execution. Memory can be processed inside trusted execution environments (TEEs) without being exposed to the host, operator, or even the application developer.

Where Oasis Fits Technically

On Oasis, memory doesn’t have to live inside the model provider at all.

Using Sapphire and ROFL, developers can:

store sensitive memory encrypted
process it inside TEEs
enforce access rules programmatically
generate attestations proving how memory was used

This decouples three layers that are currently entangled:

memory (user-owned, portable)
models (replaceable, routable)
execution (verifiable, confidential)

An agent running on ROFL can query memory, reason over it, and act—without leaking raw context to the model provider or infrastructure operator.

What This Enables

With a confidential, portable memory layer:

switching AI models doesn’t reset context
agents can operate across tools without loss of state
long-term strategies compound instead of reset
curated memory becomes a reusable asset

This is especially relevant for crypto-native agents, where memory often encodes real economic behavior and competitive edge.

Closing Thought

Bigger models won’t fix AI’s memory problem. Better architecture will.

By separating memory from models and anchoring it in confidential, verifiable compute, platforms like Oasis make persistent AI context technically feasible without sacrificing privacy or control.

For developers building agents, tools, or workflows that need continuity over time, portable memory isn’t a nice-to-have, it’s infrastructure.

Check out this Article by Marko Stokić: https://www.forbes.com/sites/digital-assets/2025/12/12/why-crypto-needs-portable-ai-memory/

Remote Attestation Is a Signal, Not a Trust Model

Manav — Sun, 25 Jan 2026 15:27:19 +0000

Trusted Execution Environments (TEEs) are increasingly used as building blocks for confidential smart contracts, off-chain agents, and privacy-preserving infrastructure. Most designs lean heavily on remote attestation as the mechanism that “proves” correctness.

This is a category error.

Remote attestation is useful, but it is not sufficient. Treating it as a trust primitive rather than a low-level signal leads to fragile systems that appear verifiable but fail under real adversarial conditions.

This post looks at attestation from a systems perspective: what it actually guarantees, where it fundamentally stops, and what additional structure is required to make it operationally meaningful.

What Attestation Actually Gives You

At its core, a TEE provides:

Isolated execution: memory confidentiality and integrity enforced by hardware
A hardware root of trust: per-CPU cryptographic material
A signed statement: a quote asserting (measurement, platform state, signer)

That signed statement, remote attestation is often interpreted as “this application is trustworthy.”
Formally, it is nothing more than evidence.

Given an attestation, a verifier can conclude:

At time t, code hash H executed on CPU C, under TCB version V, and this claim was signed by the manufacturer.

Nothing in that statement implies:

correctness over time
freshness of state
operator accountability
alignment with an application’s threat model

Those properties must come from somewhere else.

The Verification Burden Is Misplaced

In most TEE-based systems today, verification is pushed to the edge:

clients parse raw quotes
security logic is embedded in SDKs
users are expected to trust dashboards or static attestations

This is backwards.

Quote verification is not only complex (TCB interpretation, collateral validation, revocation checks), it is context-free. A quote does not encode:

acceptable CPU generations
acceptable upgrade paths
acceptable re-attestation frequency
acceptable operator behavior

Without a policy layer, attestation is ambiguous. Two verifiers with different assumptions can reach opposite conclusions from the same quote.

Attestation Fails at the System Boundary

Most failures arise not inside the enclave, but around it.

State is not attested

Attestation covers code, not data. Without an external anchor, an enclave can be restarted with stale encrypted state and still produce a valid quote. From the verifier’s perspective, rollback is indistinguishable from normal execution.

Time is not attested

Freshness is not inherent. Quotes do not expire unless the system enforces expiration. Replay attacks are trivial unless liveness is continuously checked.

Identity is not attested

Attestation identifies hardware, not operators. Without binding enclaves to slashable identities, misbehavior carries no economic consequence.

History is not attested

Even a perfectly attested enclave today says nothing about what ran yesterday. If an earlier version leaked secrets, current correctness is irrelevant.

These are not implementation bugs. They are structural limitations of attestation as a primitive.

Trust Requires Coordination, Not Quotes

To make TEEs usable in adversarial environments, attestation must be embedded into a larger verification system.

A robust design has three properties:

Continuous verification
Attestations are checked repeatedly, not once.
Policy-driven validation
Security assumptions are explicit, versioned, and enforced automatically.
Shared agreement
Verification outcomes are determined by a fault-tolerant set of economically aligned verifiers, not individual clients.

In other words: attestation must feed into consensus.

Instead of asking every client to interpret hardware evidence, a verifier network does the hard work:

validating TCB status
enforcing freshness and rollback protection
binding enclaves to operators
tracking upgrade history and code provenance

The result is a consensus-signed statement that represents a collective judgment:

“This enclave is valid under current network policy.”

This turns attestation from an opaque artifact into a usable on-chain signal.

Why This Matters for Crypto Systems

Blockchains already solve one half of the problem: global agreement under adversarial conditions.

When TEEs are integrated into that model rather than treated as standalone trust anchors, they become far more powerful:

enclaves can be time-bound to chain state
operators can be held accountable
policies can evolve without breaking trust
users can verify outcomes without understanding hardware internals

Systems like Oasis Network take this approach by embedding attestation verification, operator governance, and policy enforcement into protocol consensus. Its ROFL extends this model to off-chain execution, where correctness and privacy must coexist.

The key insight is not Oasis-specific:
attestation is only meaningful when interpreted by a trusted process, and in decentralized systems, that process must itself be decentralized.

Closing Thought

Remote attestation answers a narrow question: “What ran, where, and when?”
Trust systems ask a much broader one: “Why should anyone believe this result?”

Bridging that gap requires more than quotes. It requires policies, incentives, history, and agreement.

Until those pieces exist, attestation remains a low-level signal—powerful, but incomplete.

Verifiable Compute for Onchain Prop Trading: How Carrotfunding Uses ROFL

Manav — Thu, 25 Dec 2025 15:33:38 +0000

Onchain prop trading has always promised transparency, but in practice most platforms still rely on opaque offchain engines for order execution, trader evaluation, and payout logic. Capital may be secured onchain, yet the most critical decisions, who gets funded, how performance is measured, and when payouts trigger, often happen in black-box infrastructure.

Carrotfunding.io is taking a concrete step to eliminate that gap by integrating ROFL, bringing cryptographically verifiable compute into its trading and evaluation pipeline.

The Trust Gap in Prop Trading

Traditional prop firms are built on trust: traders trust execution, firms trust evaluation logic, and investors trust payout calculations. Even many “onchain” platforms replicate this model by anchoring capital onchain while keeping decision logic offchain.

Carrot already minimizes several of these assumptions:

Capital is secured using rethink.finance vaults
Trades are executed via gTrade

The remaining trust dependency lies in the AWS-based engine responsible for:

order orchestration
trader performance evaluation
risk metrics
payout calculation

This is exactly where ROFL is being introduced.

How the ROFL Integration Works

Instead of replacing its existing infrastructure immediately, Carrot is deploying ROFL as a parallel verification layer.

The production engine continues to run for performance and latency reasons.
A ROFL instance independently re-executes the same computations inside a Trusted Execution Environment (TEE).
ROFL produces cryptographic attestations that prove:
- which code was executed
- which inputs were used
- what outputs were produced

These attestations are posted onchain, allowing traders and capital providers to verify that:

evaluation rules were applied exactly as defined
no discretionary changes were made
payouts were calculated deterministically

Over time, this architecture supports a gradual path toward ROFL-only execution, without sacrificing system reliability today.

Why This Matters Technically

ROFL provides properties that standard offchain infrastructure cannot:

Execution integrity: Code runs in hardware-isolated enclaves.
Reproducibility: Identical inputs produce provable outputs.
Auditability: Verification happens onchain, not via logs or dashboards.
Key isolation: Sensitive keys never leave the enclave.

For a prop trading system, this means trader scoring, drawdown checks, and payout logic become provable protocol behavior, not operator promises.

Implications for Traders and Capital Providers

For traders:

Evaluation criteria become transparent and verifiable.
Disputes can be resolved cryptographically, not socially.
Funding decisions are no longer subjective or opaque.

For capital providers:

Funds are governed by immutable logic.
Risk controls are enforced exactly as specified.
Performance claims can be independently validated.

A Broader Signal for DeFi Infrastructure

This integration is a strong example of how verifiable compute can unlock new classes of financial applications. Prop trading requires:

high-frequency logic
complex evaluation rules
strict fairness guarantees

ROFL shows how such systems can remain performant and trust-minimized.

While full onchain execution is often impractical for this class of workloads, cryptographically verified offchain compute offers a realistic middle ground.

Looking Ahead

Carrotfunding’s roadmap includes deeper reliance on ROFL over time, potentially eliminating centralized execution entirely. More broadly, this pattern,

parallel verification → gradual migration → full verifiable execution

is likely to become standard for complex DeFi systems.

As onchain finance matures, trust assumptions will increasingly move from people and servers to code and cryptography. This integration is an early but meaningful step in that direction.

Why Oasis Is Backing Custody-Native Credit Infrastructure

Manav — Thu, 25 Dec 2025 14:58:09 +0000

The next phase of blockchain adoption isn’t about more throughput or cheaper gas, it’s about making onchain systems usable for institutions without forcing them to give up custody, confidentiality, or compliance.

That context explains why Oasis has launched a strategic investment arm, and why its first investment targets a very specific problem: credit activation on tokenized assets that never leave custody.

The Problem Institutions Actually Care About

Tokenized real-world assets are growing fast, but credit markets around them are still thin. The blocker isn’t demand, it’s structure.

Most DeFi credit models assume:

assets move freely between contracts,
counterparties are visible,
enforcement is public.

That works for crypto-native assets. It doesn’t work for custodians, asset managers, or regulated funds. Once assets leave custody, you’ve already lost the battle.

This is the gap SemiLiquid is addressing.

What SemiLiquid Does Differently

SemiLiquid’s approach starts from a hard constraint: collateral must remain inside existing custody frameworks.

Instead of wrapping assets or moving them into lending pools, SemiLiquid activates credit on top of tokenized collateral that stays put. Credit terms, margin logic, and liquidation conditions are enforced programmatically — without exposing positions or counterparty data.

From a systems perspective, this requires:

confidential policy evaluation,
automated enforcement logic,
verifiable state transitions,
and strict separation between what’s public and what must remain private.

This is not something generic smart contracts handle well.

Why Oasis Infrastructure Fits This Use Case

SemiLiquid is built on Oasis Sapphire, using confidential compute to enforce credit logic while keeping sensitive financial data encrypted.

A key component is Liquefaction, a research-backed primitive originating from Cornell Tech, which enables fine-grained control over information flow. Liquefaction allows credit systems to:

enforce policy without revealing inputs,
monitor breaches privately,
issue programmable credit receipts,
and still anchor outcomes onchain.

This combination of confidential execution & onchain verifiability is what makes custody-native credit feasible at all.

From Theory to Production

After an extended build phase, SemiLiquid is now running a live pilot with established players including:

Franklin Templeton,
Zodia Custody,
M11Credit,
Avalanche,
and Presto Labs.

The workflow covers collateral locking, credit issuance, monitoring, and repayment, all without exposing sensitive financial relationships or breaking custody guarantees.

That’s a meaningful signal that this isn’t just conceptual infrastructure.

What This Signals for Oasis

The launch of a strategic investment arm isn’t about picking winners randomly. It’s about backing teams that push confidential compute into real institutional workflows.

SemiLiquid sets the tone:

compliance-aware by design,
compute-heavy,
confidentiality as a requirement, not an add-on.

Future investments are likely to follow the same pattern across RWAs, settlement layers, identity systems, and agent-based infrastructure where verifiable but private computation is unavoidable.

Closing Thought

If tokenized assets are going to support real credit markets, the infrastructure has to meet institutions where they are, not ask them to compromise on custody or confidentiality.

This investment is a bet that confidential compute is the missing layer, and that custody-native credit is one of the first places where it actually proves itself.

Resources:

x402: Turning HTTP 402 into a Real Payment Primitive

Manav — Thu, 25 Dec 2025 14:45:47 +0000

HTTP has carried the status code 402 – Payment Required since the early days of the web. The idea was simple: servers could charge per request. The reason it never worked wasn’t conceptual, it was infrastructural. Payments were slow, expensive, and required accounts, sessions, and chargeback-heavy intermediaries.

x402 revisits this idea with modern primitives: stablecoins, fast settlement, and programmable authorization. The result is a web-native payment protocol that lets services charge for access directly in the HTTP request–response loop.

How x402 Works (At a Protocol Level)

x402 introduces a small extension to standard HTTP flows:

A client (human or agent) requests a resource.
The server responds with HTTP 402 plus payment metadata:
- token
- amount
- chain
- destination address
The client signs a permit-style authorization using transferWithAuthorization (EIP-3009).
A facilitator verifies the authorization off-chain and settles it on-chain.
Once settlement is confirmed, the server returns the requested resource.

From the client’s perspective, this feels like a normal API call.
From the server’s perspective, payment is verified before access is granted.
No accounts, no sessions, no API keys.

Why This Is Interesting for Developers

Micropayments become viable
The protocol itself has no fees. Costs are limited to gas, which on modern L2s makes sub-cent pricing realistic.

Stateless by design
Each request carries its own payment authorization. There’s no need to manage balances, subscriptions, or identity layers.

Web-native integration
x402 works with plain HTTP. Any backend capable of returning a 402 response can adopt it without special SDKs.

Machine-friendly payments
This model fits agents far better than traditional payment systems. An agent can pay per request, per inference, or per compute unit without human involvement.

Agent-to-Agent Payments

The real unlock isn’t just charging humans, it’s enabling autonomous economic activity.

An agent can:

pay an API for data,
pay another agent to process it,
pay a compute service to run a job,
all conditionally and programmatically.

These are high-volume, low-value, composable payments that traditional rails can’t support efficiently, but blockchains can.

Where Trust Comes In: x402 + ERC-8004 + ROFL

x402 handles payment, not trust.

For agent ecosystems, that matters. When an agent pays a service, it needs to know:

what code is actually running,
who controls the keys,
whether execution can be verified.

That’s where complementary primitives fit:

ERC-8004 provides on-chain registries for agent identity, reputation, and validation.
ROFL enables verifiable execution inside TEEs, with enclave-generated keys and cryptographic attestations.

Together:

x402 moves money,
ERC-8004 enables discovery and coordination,
ROFL provides execution integrity and confidentiality.

Even facilitators themselves can run inside ROFL, making the payment layer auditable and resistant to censorship.

Practical Examples

Early demos already exist:

pay-per-inference services where users pay cents per request,
multi-model AI pipelines with cross-validation,
document processing APIs with verifiable execution.

In each case, pricing tracks actual usage instead of subscriptions.

Closing Thoughts

x402 doesn’t try to reinvent payments. It makes them composable with the web itself.

By aligning HTTP semantics with on-chain settlement, it opens the door to pricing models and agent workflows that were previously impractical. Combined with verifiable execution and standardized agent discovery, it points toward a more granular, automated, and open internet economy.

For developers building APIs, agent systems, or compute-heavy services, x402 is worth paying attention to.

Resources:

x402: A Web-Native Payment Protocol for Micropayments and Autonomous Agents

Manav — Mon, 24 Nov 2025 16:31:15 +0000

For decades, the web has had an unused HTTP status code: 402 – Payment Required. It was reserved for a future in which servers could charge per request. That future never arrived, not because the idea was flawed, but because the infrastructure wasn’t ready.

Today, that infrastructure exists.
Stablecoins settle instantly, blockchains are programmable, and agents, both human-driven and autonomous need payments that can occur at machine speed.
x402 is the protocol that finally operationalizes HTTP 402 in a modern context.

What x402 Enables

x402 introduces a minimal extension to HTTP that allows any service API, model, dataset, or content endpoint to require payment within the request-response loop. No sessions, no accounts, no OAuth flows.

A server can respond with HTTP 402 along with:

Token type
Amount
Receiving address
Chain/network

The client then submits a signed authorization using EIP-3009 (transferWithAuthorization), enabling third-party execution of the transfer. A facilitator verifies and settles the transaction on-chain, allowing the server to return the requested resource.

This sequence takes sub-second for the client.

Why Developers Should Care

1. Micropayments Become Realistic

Facilitator costs are simply gas. For low-cost L2s, sub-cent pricing becomes economically viable.

2. Works With Existing Web Infrastructure

x402 is HTTP-native.
Any backend that can return a custom status code can support it. Framework-specific SDKs aren’t required.

3. Stateless Payments

No user accounts, no cookies, no stored balances.
Each request carries the authorization needed for settlement.

4. Machine-Readable Payments for Agents

Agents can consume, pay for, and chain services without human supervision:

Pay-per-inference
Pay-per-crawl
Pay-per-compute-cycle
Pay-per-task orchestration between agents

This pattern is impossible with traditional payment rails.

Trust Models: Where x402 Intersects With Web3

x402 enables payment, but it does not solve trust e.g., whether the model or service responding is authentic, private, or verifiable.
This is where ERC-8004 and ROFL come in.

ERC-8004

A neutral on-chain registry system for:

Agent identity
Reputation trails
Validation methods

It lets agents discover each other and negotiate trust assumptions.

ROFL

A confidential compute layer enabling:

Verifiable execution in TEEs.
Attestation of service code and models.
Enclave-generated keys and isolated signing.
End-to-end encrypted request processing.
Autonomous agents with tamper-proof state.

Together, x402 handles payment, ERC-8004 handles coordination, and ROFL handles trust.

This trio forms an interoperable stack for building autonomous services that transact, compute, and collaborate without intermediaries.

Example Implementations

Developers have already begun deploying x402-enabled confidential services, including:

Document summarization APIs where users pay cents per inference.
Multi-LLM verification oracles, with each inference paid through x402.
GPU compute tasks triggered programmatically by agents.

In all cases, the payment, execution, and verification layers compose cleanly.

Closing Thoughts

x402 brings the web much closer to a true pay-per-use model one that’s compatible with autonomous agents, micro-services, and global machine-driven commerce. When paired with verifiable computation (ROFL) and standardized agent discovery (ERC-8004), it forms the foundation for an emerging agentic economy.

If you're building APIs, autonomous systems, or compute-heavy services, this is a protocol worth watching.

ROFL Introduces Native Frontend Hosting: Confidential Apps Can Finally Go Full-Stack

Manav — Mon, 24 Nov 2025 16:12:42 +0000

One of the long-standing challenges with confidential computing has been building applications that do more than secure backend logic. TEEs excel at protected execution, secret key handling, and verifiable compute, but exposing a user-facing frontend from inside an enclave has always been awkward.

Developers typically had to rely on external proxies, manually managed TLS certificates, and domain routing pipelines that operated outside the TEE boundary. That meant extra tooling, inconsistent setups across providers, and, ironically, more opportunities for data to leave the secure boundary than most teams wanted.

The latest update to ROFL changes this dynamic in a meaningful way. ROFL now provides built-in proxy support and automated HTTPS endpoint creation, allowing applications to run both frontend and backend components entirely inside confidential environments.

This isn’t just a quality-of-life improvement, it shifts what “confidential apps” can practically look like.

A New Hosting Model for Confidential Apps

The new proxy layer in ROFL acts as the gateway between the public Internet and the enclave-based application. Instead of requiring developers to configure NGINX, Traefik, or bespoke proxy setups, ROFL now handles:

Public endpoint creation
Domain and subdomain assignment
Certificate provisioning
Routing to the correct enclave instance
Secure transport through encrypted internal tunnels

From the developer’s perspective, hosting a frontend in ROFL now resembles deploying to a modern PaaS, only with hardware-backed confidentiality at every step.

What Deployment Looks Like

ROFL’s deployment flow remains container-based, but with an additional annotation step to declare the domain an app should serve from. After redeploying, the CLI provides DNS instructions for whichever domain the developer wants to use.

Once DNS is configured, a quick restart triggers certificate creation. Importantly, certificate keys are generated inside the enclave, and never leave it.

The proxy infrastructure routes based on TLS handshake metadata, not plaintext preserving the enclave’s data-isolation guarantees.

Read the Docs here: https://docs.oasis.io/build/rofl/features/proxy/

Why This Matters

This feature closes one of the last major gaps in building production-grade confidential applications:

Developers no longer need external hosting for frontends.
TLS is managed automatically with no key exposure.
The entire app stack logic, state, and UI can live in a TEE.
The operational burden of using enclaves drops significantly.

Confidential computing becomes far more approachable when deploying a secure app is as simple as annotating a compose file and configuring DNS.

In practical terms, teams can now build:

Private DeFi dashboards.
Agent interfaces that expose no sensitive state.
Confidential admin panels.
Encrypted multi-tenant applications.
Verified compute services with secure user-facing UIs.

all running inside trusted hardware, with no external proxy infrastructure to maintain.

Closing Thoughts

ROFL has always focused on giving developers a general-purpose execution layer for verifiable, confidential off-chain logic. Adding native frontend hosting pushes it toward a true full-stack confidential compute platform.

The more that infrastructure fades into the background, the easier it becomes for developers to actually use these capabilities. This update moves the ecosystem one step closer to confidential applications that are secure by default—not secure with caveats.

Zcash vs. Oasis: Two Completely Different Visions of Privacy in Crypto

Manav — Mon, 24 Nov 2025 14:46:23 +0000

Not competitors, two architectures solving two very different problems.

Privacy in blockchain isn’t a single feature. It’s an entire design space.
And when you compare Zcash to Oasis, this becomes obvious fast.

Both projects care deeply about privacy, but the way they pursue it and the types of problems they’re built to solve, couldn’t be more different.
One protects transactions.
The other protects computation.

Understanding that distinction is the key to understanding why these two ecosystems exist at all.

How Zcash Thinks About Privacy

Zcash’s model starts with a simple premise: if you’re moving value on-chain, you should be able to do so without exposing yourself to the world.

Its foundation is zk-SNARKs, which allow a transaction to be proven valid without revealing anything else about it. Zcash intentionally keeps the surface area small: no complex smart contracts, no heavy execution layers, no programmable privacy logic.
Just money-made private.

This is why Zcash has been able to stay both elegant and efficient. It’s fast, fees are negligible, and the shielding mechanism is mathematically sound.
Its engineering goal is clear: private payments that scale.

Not private smart contracts.
Not private computation.
Not confidential AI workloads.
Just private transfers.

How Oasis Thinks About Privacy

Oasis starts from the opposite direction: what if privacy is not only about transferring value, but also about how applications process it?

This leads to a completely different architecture.

Sapphire: Confidential EVM

A full EVM runtime where contract state, storage, and user inputs remain encrypted, yet developers deploy using standard Solidity tooling. It’s privacy without rewriting the Web3 stack.

ROFL: Verifiable Off-Chain Logic

A TEE-backed execution layer where agents, apps, or AI systems can run complex logic privately while still producing on-chain, verifiable attestations.

Instead of hiding “the transaction,” Oasis hides the computation itself.
That’s an entirely different category of privacy.

This enables use cases that Zcash, by design, does not touch:

Private order books
Encrypted lending logic
Autonomous agents with isolated key management
Confidential governance
Enterprise-grade data pipelines
Cross-chain privacy layers

Where Zcash aims to be private cash, Oasis aims to be private infrastructure.

Threat Models: Math vs. Architecture

Zcash’s security model is pure cryptography: if zk-SNARK assumptions hold, privacy holds. The protocol does not lean on trusted hardware or off-chain execution. Its attack surface is intentionally minimal.

Oasis’s model is layered. The system assumes that hardware may fail which is why it relies on:

Confidential execution inside hardware enclaves
On-chain governance to restrict who can run key-critical roles
Ephemeral encryption keys that rotate continually
Verified TEEs with attestation and CPU blacklisting
Encrypted state transitions inside Sapphire

Zcash’s model says: trust the math.
Oasis’s model says: trust no single layer, verify them all.

What Each System Is Really Built For

It’s easy to compare these two systems as “privacy projects,” but their roles are fundamentally different:

Zcash excels at

Private value transfer
Low-latency, low-cost settlements
Strong cryptographic anonymity
Simple, predictable privacy guarantees

Oasis excels at

Confidential smart contracts
Private AI agents with verifiable logic
Encrypted stateful applications
Cross-chain privacy for existing EVM ecosystems
Confidential data processing for enterprise or DeFi

In modern Web3 terms:
Zcash is a private ledger. Oasis is a private compute layer.

Looking Ahead

As the ecosystem shifts toward agentic systems, AI integrations, and more complex financial primitives, the demand for private computation is rising. That’s where Oasis fits naturally.

At the same time, the need for private money simple, shielded, censorship-resistant value transfer, has never gone away. That’s where Zcash remains unmatched.

There is no single “winner” here because they are optimizing for very different goals.

One protects what you send.
The other protects how your applications think.

Both are necessary pillars in a privacy-first crypto stack.

ERC-8004: Building Trustless Autonomous Agents with TEEs

Manav — Thu, 23 Oct 2025 13:23:11 +0000

The concept of autonomous agents, software that can operate, transact, and make decisions on-chain without constant human supervision has been around for a while.

However, widespread adoption has been hampered by incompatible frameworks, isolated registries, and trust assumptions.

ERC-8004 is a proposed Ethereum standard designed to address these challenges by providing a minimal yet extensible framework for agent discovery and trustless interaction.

How ERC-8004 Works

The standard defines three core registries:

Identity: Assigns each agent a unique ID and links it to off-chain metadata describing capabilities, supported protocols, and domains.
Reputation: Creates an on-chain audit trail of client-authorized feedback, enabling reputation tracking without storing all data on-chain.
Validation: Supports task verification through crypto-economic staking or cryptographic proofs using Trusted Execution Environments (TEEs) or zero-knowledge proofs.

By keeping the standard lean, ERC-8004 lets developers implement trust models appropriate for each use case, from social consensus for low-risk tasks to cryptographic validation for financial operations or sensitive data workflows.

Oasis’s ROFL: Enabling Trustless Execution

ROFL (Runtime Off-chain Logic) is a TEE framework built on the Oasis Protocol, enabling agents to execute off-chain computations securely and verifiably.

Key features include:

Confidential execution: Code runs inside hardware-isolated enclaves, keeping sensitive inputs private.
Cryptographic attestations: Outputs are verifiable on-chain, allowing other agents to trust results without relying on the developer.
Cross-chain key management: Supports native wallet operations across EVM-compatible chains, Solana, and more, removing bridge dependencies.

ROFL essentially decouples computation from coordination: ERC-8004 handles agent registration, reputation, and discovery on-chain, while ROFL ensures that sensitive computations and transaction signing remain trustless and private.

Adoption Path and Potential

ERC-8004 is moving toward a stable v2, introducing features like NFT-based agent ownership, flexible reputation storage, and integration with payment protocols like x402. The combination of ERC-8004 and ROFL enables developers to build verifiable, cross-chain autonomous agents, laying the groundwork for new applications in DeFi, trading, gaming, and beyond.

By standardizing identity, reputation, and validation while leveraging TEE-backed execution, ERC-8004 provides a foundation for trustless agent networks that can scale across ecosystems without requiring centralized control.

References

Oasis Launches “TEE Break Challenge”, One Bitcoin Bounty for Breaking Their Secure Enclave

Manav — Thu, 23 Oct 2025 13:13:47 +0000

Oasis, the team behind the Sapphire confidential EVM, has launched what might be one of the boldest blockchain security experiments in recent years: a public challenge to break their TEE-based system.

There’s one Bitcoin (wBTC) locked in a Sapphire smart contract.

If anyone can extract the private key controlling it, the funds are theirs.

No bug report. No triage. Just proof through action.

A Real-World TEE Security Test

The setup is simple but powerful: a smart contract deployed on the Sapphire Mainnet generates a keypair entirely inside an Intel SGX enclave.

The private key never leaves the TEE, never exists in plaintext, and has no API or function that can export it.

Only the derived Ethereum address: 0xCEAf9abFdCabb04410E33B63B942b188B16dd497 , is public and holds the 1 wBTC bounty.

The contract code is verified and live on-chain at: 0xc1303edbFf5C7B9d2cb61e00Ff3a8899fAA762B8

If anyone manages to move the funds without authorization, it’s a clear indicator that the TEE itself has been compromised, not the smart contract logic.

Why This Matters

Trusted Execution Environments (TEEs) have been a cornerstone for confidential computing in blockchain, used by projects like Phala, Secret, and Crust to keep on-chain data private. But recent research has shown that TEE hardware can be vulnerable too.

In 2025, two new physical attack vectors, Battering RAM and Wiretap were disclosed, successfully breaching Intel SGX (Scalable version) and AMD SEV-SNP enclaves. Several networks using these systems were forced into emergency upgrades.

Oasis, however, claimed that its architecture remained unaffected, largely due to:

Running on Intel SGX v1, which uses a different memory encryption design not impacted by the attacks.
A defense-in-depth model that adds additional on-chain and governance-based security layers beyond the TEE.

This public challenge seems designed to test those claims under real-world conditions.

Technical Architecture Highlights

The Sapphire contract uses the following design principles:

In-enclave key generation: Keypairs are generated using Sapphire’s secure randomness and stored only inside the enclave.
No off-chain dependencies: There’s no off-chain signing service or export function.
Hardcoded transaction paths: Even compromised owners can’t redirect withdrawals, outputs are fixed.
On-chain authentication: Every action requires Sign-In with Ethereum (SIWE) and enclave-verified signatures.
Production environment: This is live on Sapphire Mainnet, not a testnet or sandbox instance.

The challenge uses the same infrastructure as deployed applications — meaning it tests real production security, not a simplified simulation.

Why This Is Interesting

Most bug bounties offer rewards for vulnerabilities under specific reporting conditions. The TEE Break Challenge takes a different stance, it’s a binary outcome test.

Either:

The Bitcoin moves, proving a TEE-level compromise, or
It doesn’t, validating Sapphire’s enclave model under live conditions.

That approach is rare in blockchain security and the transparency of putting real funds on the line makes it especially compelling.

Duration and Participation

The challenge runs through the end of 2025, giving researchers ample time to attempt TEE-level extraction. It’s open to anyone: hardware security researchers, blockchain engineers, and academic teams interested in confidential computing.

The contract and related infrastructure are fully public. Discussion and coordination are happening in the Oasis Discord.

Closing Thoughts

Regardless of the outcome, this is one of the most practical demonstrations yet of TEE security in a live decentralized system. It’s part bounty, part experiment, and part statement, that the best way to test trust is to make it public and measurable.

If someone manages to extract the key, it’ll be a breakthrough moment in TEE research.

If not, it’s a strong validation of Sapphire’s design and Oasis’s defense-in-depth strategy.

Either way, the results will be valuable for everyone working at the intersection of hardware security and blockchain privacy.

Links:

When TEEs Fail Gracefully: How Oasis Survived the Battering RAM and Wiretap Attacks

Manav — Thu, 23 Oct 2025 12:55:41 +0000

In early October, 2025, two new physical attacks - Battering RAM and Wiretap, broke open the latest generation of hardware trusted execution environments (TEEs), namely Intel SGX Scalable and AMD SEV-SNP.

These attacks didn’t just expose theoretical vulnerabilities. They granted real attackers the ability to extract attestation keys, effectively nullifying the cryptographic guarantees of those TEEs. Within hours of disclosure, multiple blockchain projects built around them like Phala, Secret, Crust, and IntegriTEE began issuing emergency updates and migration plans.

One project didn’t have to: Oasis.

While others scrambled to patch, Oasis nodes kept running exactly as before. The reason has less to do with luck and everything to do with architectural philosophy, a belief that TEE security must never be a single point of failure.

Understanding What Broke

To understand why Oasis stayed online, we first need to look at what actually failed elsewhere.

Both Battering RAM and Wiretap exploited flaws in deterministic encryption schemes used in new SGX and SEV-SNP memory controllers. By monitoring predictable encryption patterns, attackers could reconstruct secret material including attestation and session keys from physical side channels.

Once the attestation layer is gone, the whole TEE trust model collapses:

Data sealed inside enclaves can be decrypted externally.
Remote attestation can be forged.
“Confidential compute” becomes just “compute.”

This chain reaction was precisely what many TEE-reliant blockchains experienced. Their node operators lost assurance that enclave nodes were genuine, effectively breaking consensus-level trust.

Why Oasis Didn’t Fall

Oasis took a different path years ago. Its team designed around the assumption that hardware will fail eventually, so every core system includes at least one independent layer that doesn’t rely on TEE integrity.

Here’s how that philosophy plays out in practice:

1. Architectural Separation

The key manager and Sapphire confidential runtime on Oasis run on Intel SGX v1, not the newer Scalable version. SGX v1 uses non-deterministic memory encryption and an attestation model that wasn’t impacted by the recent flaws.

More importantly, Oasis separates key access and execution. No single enclave or node ever holds the full cryptographic picture. A compromised enclave is isolated, not catastrophic.

2. On-Chain Governance as a Security Layer

Unlike networks that rely solely on enclave attestations, Oasis enforces on-chain governance rules around who can even run a key manager node.

Membership in the key committee requires:

Explicit governance approval;
A validator stake (≥ 5M ROSE);
Continuous compliance with network policies.

Even if someone could fake attestation with stolen keys, they still couldn’t bypass these governance requirements baked into consensus logic.

3. Ephemeral Cryptography

Each epoch, the network rotates ephemeral encryption keys used for transaction confidentiality. Once rotated, the old keys are deleted permanently. This means that even a perfect enclave compromise only affects future sessions — past data remains irreversibly protected.

4. Adaptive Response

Oasis also maintains a CPU-level blacklist mechanism. When a hardware vulnerability is disclosed, affected processor models can be banned through governance proposals. This allows the network to react in hours, not months.

Lessons for Developers

For developers building privacy-preserving dApps or agent systems, Oasis offers a valuable case study in graceful failure.

TEE technology enables confidential logic and data handling, but as we’ve now seen, the underlying hardware is far from infallible. Designing for resilience means assuming that even your most “trusted” environment might one day betray you.

In practice, that means:

Don’t rely solely on enclave attestations for authentication or access control.
Keep sensitive operations modular and separable.
Rotate encryption keys frequently, and expire them aggressively.
Build governance or consensus checks that exist outside the hardware trust domain.

Oasis’s continued uptime and data integrity during this incident show that these principles are not just theoretical — they work.

A Model for Future Confidential Systems

What happened with Battering RAM and Wiretap should serve as a wake-up call for developers working on confidential smart contracts, MPC frameworks, or AI inference enclaves.

Hardware isolation is an important tool, but not a guarantee. The safer path forward is layered trust, where no single failure (hardware, software, or governance) can fully compromise the system.

Oasis’s defense-in-depth design represents one of the first large-scale proofs that this philosophy works in production.

While other networks were rebooting enclaves and replacing attestation keys, Oasis simply continued to function. No data loss, no downtime, and no user impact.

For developers, that’s more than just good news, it’s a validation of how to architect secure, resilient confidential compute systems in the real world.

Further Reading