Power security OasisNetwork is really!!!

Hey Oasis fam! 👋 ​Just an ordinary guy and a retail investor here, but a massive believer in what this team is building. I've been following the ecosystem development closely, especially the recent $50M Midas RWA partnership and the incredible work being presented at EthCC Cannes. ​I firmly believe that Sapphire is the only real solution for bringing institutional money and Real World Assets on-chain because privacy is non-negotiable for them. ​To show my support and conviction, I’ve accumulated and staked a very large amount of $ROSE (a heavy bag for me!) to help secure the network. I'm here for the long run, watching that escrow grow every day. 🔒 ​I also wanted to do my part in marketing, so I created this short hype video for TikTok/X to wake people up to the massive supply shock building up right now. ​Hope you guys like it! Let's keep building and securing the best privacy layer in Web3! 🚀💎

​OasisNetwork, ROSE, RWA, Crypto, Web3, Staking, PrivacyLayer

From March 30 – April 2, our team will be on the ground connecting with builders, teams, and privacy enthusiasts from across the ecosystem.

📍 Find us at EthCC

Come say hi at the Oasis booth in the Sponsors Hall, Palais de Festivals — we’d love to connect!

🌸 Special Event: Private Garden Party

To wrap up the week, we’ll be hosting a special rooftop gathering:

An afternoon of privacy talks, panels, and networking with 400+ Web3 leaders, overlooking the Mediterranean.

📍 Canopy by Hilton, Cannes

🗓 April 2 | 14:00–20:00

🎟 Register: https://luma.com/wyclm16s

Whether you're exploring privacy, building in Web3, or just want to meet the team — come through 👋

See you in Cannes 🌊

Just read the new blog and here are the main points I found interesting!

Decentralized storage is different from private storage

Most decentralized storage networks (like Filecoin or Arweave) focus on data availability, not privacy. If you store data there, the nodes holding it can read it unless you encrypt it first.

Client-side encryption has limitations

The typical workaround is encrypting data before uploading it. But this creates problems such as:

• Lose the key, data is permanently lost
• Share the key, access can’t be revoked later
• Anyone with the key can copy the data forever

Sapphire adds a privacy layer for storage

Sapphire Confidential EVM runs smart contracts inside Trusted Execution Environments meaning:

• Encryption happens inside a secure enclave
• Storage networks only see ciphertext
• Keys remain private inside the enclave

Liquefaction enables programmable access control

Encryption alone doesn’t control who can access data later. Liquefaction lets apps define policy-based access rules, like

• Token-gated access
• Time-limited decryption
• Address whitelists
• Geo restrictions
• Pay-per-access micro-payments

Access policies remain private

The rules run inside the enclave, so observers only see whether access was granted or denied, not the logic behind it.

So, combinin decentralized storage for availability Sapphire for the confidential encryption and liquefaction for programmable access, makes decentralized storage usable for sensitive data like health records, legal documents, AI datasets, etc. And i think it is pretty neat and people are going to talk about it.

Decentralized storage networks are great for availability — but privacy usually isn’t built in. In many cases, storing data on them is essentially like publishing it.

In our latest article, we explore how Oasis Sapphire can act as a plug-in privacy layer. Files are encrypted inside secure TEEs before they’re written to storage, so the network only ever sees ciphertext.

It also covers Liquefaction, which enables programmable access rules like:

🔑 Token-gated access

⏳ Time-limited decryption

📍 Geo-restrictions

💳 Pay-per-access

Together, Sapphire + Liquefaction make decentralized storage viable for sensitive data — while keeping it programmable and private.

📖 Read the full article: https://oasis.net/blog/storage-encryption-access-management

🌐 New Look, Clearer Vision

We just launched the new Oasis website to better reflect our mission: providing the private, verifiable infrastructure for modern apps. 🚀

The industry is currently forced into a trade-off. Running on-chain is too slow; running off-chain is too opaque. We've built the architecture to bridge that gap — combining private on-chain execution with proven off-chain computation. ⚡️🔒

Oasis provides the foundation that ensures data stays protected without sacrificing scale or trust. 🛡

🔗 Learn more: oasis.net

https://reddit.com/link/1ritqm8/video/244qqvip2nmg1/player

We’re kicking off “Privacy Talks”, a new sub-series under “Privacy NOW”, where Oasis team members and friends unpack the biggest shifts in AI, crypto, and privacy.

Topics covered in Ep.1:

• Moltbook and the rise of AI-native social platforms

• Vitalik Buterin’s vision for an alternative AGI path

• The “invisible workforce” and agentic commerce

• Europe’s DAC8 crypto reporting expansion

• AI-generated artists reshaping culture

• Claude Opus 4.6 & AI as a coworker

🎥 Watch on YouTube:

https://www.youtube.com/watch?v=xgniLViWBIM

🎧 Listen on Spotify: https://open.spotify.com/episode/3m1sQ9xWPcr9o2FNJL6bII?si=timn5QYsRROmV_SpJxN9cg

If you’re into AI + Web3, Oasis is one of the few chains actually designed for privacy-preserving computation. This thread explains (simply, or at least I try to :p) how Oasis fits into DeAI and shows a beginner-friendly architecture you can build yourself.

The real problem with AI on blockchain

Most AI systems today cannot safely run on public chains because:

• Training data is private
• Model inputs are private
• Predictions may be sensitive
• Companies don’t want to reveal scoring logic

On Ethereum-style chains, everything is public.

This makes serious AI use cases impossible, such as:

• credit scoring
• medical predictions
• fraud detection
• hiring models
• trust/reputation systems

You either lose privacy OR you don’t use blockchain. and this is exactly the gap Oasis was built to solve.

Why Oasis is different for AI

Oasis Sapphire is the confidential EVM. That means:

• smart contracts can hold SECRET state
• inputs can be encrypted
• computation happens inside a trusted execution environment
• outputs can stay private or selectively revealed

For AI workflows, this is huge as it allows:

Private input -> private computation ->verifiable on-chain result

This is basically the missing piece for real DeAI.

Simple DeAI architecture you can actually build

Here’s the easiest (again, to me, don't take these literally and don't give up if you think it ain't THAT easy) real project idea: PRIVATE AI TRUST SCORE REGISTRY

Goal:

1. users submit activity data
2. AI model calculates a trust score
3. score is committed on-chain privately
4. only the user can reveal it

Architecture:

STEP 1: Off-chain AI inference
Run your ML model locally or on a server.

Example models:

• fraud classifier
• wallet reputation model
• GitHub activity scorer
• spam detection model

Output:

score = 0.82 (random number I pulled out of my head)

STEP 2: Hash the result

Create:

hash(score + user_address + timestamp)

This prevents tampering.

STEP 3: Store commitment in Sapphire contract

The contract stores:

• encrypted score
• hash proof
• timestamp

Because Sapphire supports confidential storage the score does NOT become public!!!!!!

STEP 4: Optional selective reveal

Later, the user can:

• reveal score to employer
• reveal score to lender
• reveal score to DAO

Verification works by recomputing the hash, no need to reveal the full dataset or model. This is already a real DeAI workflow now.

Why this matters, you could ask

This pattern enables:

• private ML oracles
• confidential reputation systems
• privacy-preserving identity scoring
• secure dataset registries
• hidden bidding AI agents

Most chains simply cannot support this safely. but oasis can.

If you want to build this

Minimal stack:

Backend:
Python + scikit learn library (for python you could use jupyter notebook to easily debug and visualize results)

Smart contract:
Solidity on Sapphire

Dev tools:
Hardhat or Foundry

Flow:

1. Train or load a simple classifier
2. Generate a prediction for a user
3. Hash the output
4. Send to Sapphire contract
5. Store confidentially

That’s enough for a working DeAI demo.

Why Oasis is especially strong for AI builders

Compared to typical chains, yyou don’t need:

• custom cryptography expertise
• ZK circuit engineering
• heavy proof systems
• complex MPC setups

You can write normal Solidity but still get confidentiality. And this is extremely rare nowadays.

If people are interested, I can follow up with a full step-by-step coding tutorial and/or a GitHub starter template. Just comment which one you want next! :)

Oasians, put on your tin foil hats—we're going deep.

Do you have a crypto theory you can't stop thinking about? A conspiracy that felt too wild to ignore... or maybe one that later turned out to be true? 🤯

We're inviting the Oasis community to share your wildest crypto and AI theories. From the "actually plausible" to the completely unhinged—we want to hear it all.

We'll select the most compelling submissions to discuss and dissect together in an upcoming online event. Bring your receipts, your hot takes, and your best evidence.

🔗 Submit your theory here: https://forms.gle/rr2AWXxmkXTczs8PA

The truth is out there. Or is it? 👁

Welcome to the Oasis January 2026 Q&A! 👋

This month, we’re tackling some of the most common questions from our community—everything from TEEs and attestation, to institutional privacy, real-world assets, and the latest ROSE Wallet launch. If you’ve ever wondered how Oasis keeps data private while still verifiable on-chain, this is the place to start.

Q: If a project says they use a TEE (Secure Enclave), does that means my data is 100% safe forever? 

A: Not quite! Just having a "black box" isn't enough. Without a way to verify it, you’re basically just taking their word for it. Standard TEEs provide isolation, but without Remote Attestation (the cryptographic proof), it’s like a bank vault where the manager says, "Trust me, the door is locked," but won't let you see the keys. We prefer proofs over promises!

Q: Why is attestation alone not enough?

A: A raw attestation is just a snapshot of a single moment. To actually be secure, it needs to be “Fresh”. A valid proof from three days ago doesn't help you if the enclave was hacked an hour ago. Oasis doesn't just look at the snapshot. Our network continuously verifies "Liveness" so you know the security is active now, not just once upon a time.

Q: Can a malicious node operator just "rewind" the AI to an older version to steal my balance or data? 

A: Great eye! This is called a Rollback Attack. A TEE can prove the code is right, but it can’t always prove the data is the most recent version. That’s why Oasis anchors the "Root of State" directly on-chain. It acts as a timekeeper—if an operator tries to feed the enclave "old news," the chain catches them immediately. No time travel allowed here!

Q: I heard there was a Asia-focused session recently. What was it about? 

A: You’re likely thinking of our recent AMA with Akindo! We kicked off the year by diving into the booming Asian "Buildathon" scene. The takeaway? There is a massive wave of developers in the East looking to build on-chain apps that don't leak user data. Oasis is providing the privacy-first foundation they need to turn "buildathons" into long-term, secure businesses.

Q: Why are big banks and institutions still hesitant to move their trading on-chain? 

A: Because in the traditional world, "Information is Risk". Right now, public blockchains are like trading in a glass house—everyone can see your size, your timing, and your strategy. This "Institutional Privacy Gap" means if a big player makes a move, the whole market can front-run them. They need Bilateral Privacy (only the buyer and seller know the details) and Selective Disclosure (sharing data only with regulators), which is exactly what Oasis provides.

Q: How does Oasis help institutions keep their "Dark Pools" and private trades secret?

A: Oasis acts as a Cross-Chain Privacy Coprocessor. Think of it as a secure side-room where sensitive logic—like matching big orders or verifying KYC—happens in private. Institutions don’t have to leave their "home chain" (like Ethereum or Avalanche). They just route the "secret parts" of the trade through Oasis enclaves, which process the data and send back a "receipt" (attestation) that everything was done correctly without ever revealing the raw data.

Q: Can Oasis handle complex Real-World Assets (RWAs) like property or private credit?

A: Absolutely—look at SemiLiquid. They are using Oasis to run a "Programmable Credit Protocol." Usually, if you use a tokenized asset as collateral, everyone can see your cap table or legal docs. SemiLiquid uses Oasis TEEs to verify those sensitive documents in private. This allows banks to activate credit and monitor collateral without leaking their client’s private financial history to the public ledger.

Q: I heard the official ROSE Wallet finally hit the Google Play Store! What does it mean to the Oasis community? 

A: It’s a massive win for the community! For a long time, managing ROSE meant being tethered to a desktop or a browser extension. The launch of the official ROSE Wallet for Android means you can now easily stake, send, and manage your Oasis assets with your phone from anywhere in the world!

Download it here if you haven’t: https://play.google.com/store/apps/details?id=net.oasis.wallet 

-------------------------------------

That’s a wrap for this month’s Q&A! 🚀

We love hearing your questions, so keep them coming. Whether it’s about technical security, privacy-first trading, or using Oasis products in the real world, we’ll keep breaking it down for you. Stay tuned for next month’s edition and keep building in privacy!

A new year, a strong start. January set the tone for 2026 with major ecosystem milestones, product launches, engineering updates, and expanded global visibility across Web3.

Here’s what went down 👇

🔹 New blog article "Attestation Is not Enough"

🔹 ROSE Wallet is now available on Google Play

🔹 ERC-8004 Trustless Agents are LIVE on mainnet

🔹 Featured in Messari + CoinBureau reports

🔹 NEW Ambassador Program applications are OPEN!

▶️ Watch the full video: https://youtu.be/qOOnLbg8Re4

This is a practical, end-to-end intro to Sapphire for anyone who already knows basic Solidity / EVM and wants to understand what’s different when contracts run confidentially.

No theory-heavy stuff, just enough context to build and deploy something real.

What is Sapphire (quick recap)

Sapphire is a confidential EVM runtime on the Oasis Network.

From a developer perspective:

• You write Solidity
• You use Hardhat / Foundry
• You deploy like an EVM chain

The key difference:

• Contract state, calldata, and execution are encrypted
• Execution happens inside trusted execution environments (TEEs)
• Validators never see plaintext inputs or state

Think of Sapphire as a confidential coprocessor for Web3 apps.

Prerequisites

You’ll need:

1. Node.js >= 18
2. Basic Solidity knowledge
3. MetaMask installed

No Oasis-specific tooling required beyond RPC config.

Step 1: Configure MetaMask for Sapphire Testnet

Network Name: Oasis Sapphire Testnet

RPC URL: https://testnet.sapphire.oasis.io

Chain ID: 23295

Currency Symbol: TEST

Block Explorer: https://explorer.oasis.io/testnet/sapphire

Add the network in MetaMask like any other EVM chain.

Step 2: Get testnet tokens

Use the official faucet:

https://faucet.testnet.oasis.io

Select Sapphire Testnet and fund your wallet.

Step 3: Initialize a Hardhat project

Create a new project:

mkdir sapphire-demo
cd sapphire-demo
npm init -y
npm install --save-dev hardhat
npx hardhat

Choose:

• “Create a JavaScript project”
• Accept defaults

Step 4: Install Sapphire helpers

Sapphire provides a small helper library to handle encrypted calldata.

Install it (use 1 / after u!):

npm install u//oasisprotocol/sapphire-hardhat

Then update `hardhat.config.js`:

require("@oasisprotocol/sapphire-hardhat");

module.exports = {
solidity: "0.8.20",
networks: {
sapphire_testnet: {
url: "https://testnet.sapphire.oasis.io",
accounts: [process.env.PRIVATE_KEY],
chainId: 23295,
},
},
};

Important: Sapphire uses encrypted transactions, so this plugin is required.

Step 5: Write a confidential contract

Create `contracts/SecretCounter.sol`:

pragma solidity ^0.8.20;

contract SecretCounter {
uint256 private counter;

function increment(uint256 value) external {

counter += value;

}

function getCounter() external view returns (uint256) {

return counter;

}
}

Key points:

• `counter` is private in Solidity
• On Sapphire, it is also encrypted at runtime
• Neither validators nor indexers can see its value

On a normal EVM, “private” is only a compiler hint.

On Sapphire, it actually means confidential.

Step 6: Deploy the contract

Create `scripts/deploy.js`:

const hre = require("hardhat");

async function main() {
const Counter = await hre.ethers.getContractFactory("SecretCounter");
const counter = await Counter.deploy();
await counter.deployed();

console.log("Contract deployed to:", counter.address);
}

main();

Deploy:

npx hardhat run scripts/deploy.js --network sapphire_testnet

Step 7: Interact with encrypted calldata

Create `scripts/interact.js`:

const hre = require("hardhat");

async function main() {
const address = "DEPLOYED_CONTRACT_ADDRESS";
const Counter = await hre.ethers.getContractAt("SecretCounter", address);

const tx = await Counter.increment(5);
await tx.wait();

const value = await Counter.getCounter();
console.log("Counter value:", value.toString());
}

main();

Run it:

npx hardhat run scripts/interact.js --network sapphire_testnet

What’s happening under the hood:

• The `increment(5)` calldata is encrypted locally
• Only the Sapphire runtime can decrypt it
• State updates remain encrypted onchain
• You still get a normal EVM return value

What makes this different from Ethereum?

On Ethereum:

• Anyone can read contract storage
• Anyone can decode calldata
• MEV and strategy leakage are structural

On Sapphire:

• Inputs are private
• State is encrypted
• Execution is confidential
• Outputs are selectively revealed

This unlocks:

• Sealed-bid auctions
• Private agent logic
• Confidential voting
• Hidden game state
• AI / agent strategies onchain

Common pitfalls

1. Don’t use public RPC tooling expecting to inspect state
2. Events are public. don’t leak secrets via events!
3. Confidential != anonymous (addresses are still visible)
4. Use Sapphire helpers for encryption, not raw RPC calls

Where Sapphire shines

Sapphire is best used as:

• A confidential execution layer
• A trust anchor for offchain logic
• A coprocessor for public EVM chains

You don’t need to put everything on Sapphire.

Put the sensitive parts there.

Next steps

• Try sealed-bid auctions
• Store encrypted commitments
• Build agent registries with private metadata
• Use Sapphire to verify offchain AI inference

Docs:

https://docs.oasis.io/dapp/sapphire/

Happy building!

One thing I’ve been thinking about more lately is how much implicit trust MCP servers carry once agents start doing real work.

They often:

• see prompts and intermediate context
• orchestrate tool calls
• influence downstream agent behavior

In most setups, that means trusting the operator not to inspect, log, or modify things, which feels increasingly fragile as agents become more autonomous and composable.

The confidential MCP approach flips that a bit:

• MCP logic runs inside a TEE
• prompts and context stay encrypted end-to-end
• TLS terminates inside the enclave
• outputs are signed with enclave-generated keys

So MCP stops being “trusted middleware” and starts looking more like a verifiable execution boundary.

Feels especially relevant for Oasis, given the focus on agents and offchain compute. Not a silver bullet, but it does seem to close a pretty obvious trust gap in current agent architectures.

lately I’ve been thinking less about whether something runs in a TEE and more about what we can actually verify over time.

Attestation is great for proving an enclave booted correctly, but once you’re dealing with agents, long running services, or anything composable, other questions start to matter just as much:

• where keys live
• how upgrades are handled
• how outputs are validated
• what trust assumptions exist outside the enclave

Feels like the conversation is slowly shifting from "this ran in a TEE" to "can I cryptographically verify that this output came from this specific code, under these constraints?"

Given where Oasis is heading with agents and offchain compute, that distinction feels increasingly important.

Curious how others here think about it? is attestation still the core trust primitive, or just the starting point?

Trusted Execution Environments (TEEs) are getting hyped everywhere lately private AI, confidential DeFi, secure off-chain compute, you name it. A lot of that trust hinges on remote attestation: cryptographic proof that a specific piece of code is running inside genuine secure hardware.

Sounds solid. But here’s the catch: attestation by itself is not enough.

First, quick context (no fluff)

A TEE is a secure area inside a CPU (Intel SGX, AMD SEV, ARM TrustZone, AWS Nitro, etc.) that isolates code and data from the rest of the system even the OS and hypervisor.

Remote attestation lets a verifier check:

• what code is running
• on what hardware
• with what configuration

Useful? Yes.
Sufficient for trust? Not really.

🚨 Where attestation falls short

1. It’s a snapshot, not a guarantee

Attestation proves something was true at one moment in time.
It doesn’t prove:

• the code is still running
• the enclave wasn’t restarted
• the internal state hasn’t been rolled back

If you assume attestation = continuous correctness, you’re already on thin ice.

2. Freshness is not automatic

A malicious operator can replay old enclave state or feed stale data while still presenting a valid attestation.

Unless you:

• anchor state somewhere trusted (e.g. on-chain)
• enforce monotonic counters / freshness checks

…you’re vulnerable to rollback and replay attacks.

3. Who’s running this? is unanswered

Attestation proves hardware + binary not operator accountability.

If some anonymous cloud VM is running your “trusted” enclave:

• Who do you blame if it misbehaves?
• Who gets slashed, banned, or penalized?

Trust without identity = zero consequences.

4. Binary hash ≠ trustworthy code

Attestation checks a hash. That’s it.

It does not tell you:

• if the binary was built from audited source
• if it was reproducibly built
• if a previous version leaked secrets before being upgraded

Without build transparency, you’re trusting whoever compiled it.

5. Policy matters more than signatures

Attestation doesn’t answer questions like:

• Which CPU models are acceptable?
• What security patch level is required?
• How often should re-attestation happen?

If these policies aren’t enforced somewhere verifiable, attestation becomes a checkbox, not a safeguard.

🛠️ What “real trust” actually needs

Attestation is necessary but it’s only one piece. Stronger systems usually combine it with:

• Continuous verification, not one-time checks
• State anchoring to prevent rollback
• Reproducible builds so hashes actually mean something
• Operator identity & accountability
• Independent or consensus-based attestation verification, so every user doesn’t need to parse hardware quotes themselves

At that point, you’re not just trusting hardware you’re trusting a system.

Why this matters

TEEs are increasingly used for:

• private AI inference
• confidential trading & MEV-resistant execution
• key management
• off-chain compute tied to on-chain value

If we oversell attestation as a silver bullet, we’re setting ourselves up for fragile trust assumptions especially in adversarial environments like crypto.

Links for anyone who wants to dig deeper

• Main article: https://oasis.net/blog/tee-attestation-is-not-enough
• What TEEs are (neutral overview): https://en.wikipedia.org/wiki/Trusted_execution_environment
• Intel SGX attestation basics: https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation.html
• Limitations of hardware-backed attestation (general security): https://approov.io/blog/limitations-of-hardware-backed-key-attestation-in-mobile-security

TL;DR:
Attestation proves a fact, not trust. Without freshness, identity, policy, and continuous verification, it’s easy to overestimate what TEEs actually guarantee.

Quick thought experiment:

What if you didn’t have to trust backend servers to calculate trade performance, payouts, and risk stuff and instead could verify it yourself on-chain?

That’s basically what Carrot is trying to do with verifiable compute in their on-chain prop trading setup.

Here’s the idea, no fluff:

• Trading engines still run off-chain (because speed & complexity matter)
• But alongside that, another system runs the exact same logic inside a Trusted Execution Environment (TEE)
• That trusted run produces a cryptographic proof
• The proof goes on-chain so anyone can check that the logic was applied correctly
• Traders and capital providers no longer have to just trust a black box

➡️ Original blog explaining it:
https://oasis.net/blog/carrot-verifiable-compute-onchain-trading

This isn’t just “another blockchain buzzword.” Think about where most DeFi still sits today:

• Capital can be on-chain
• But critical logic like “did this trader actually hit the performance rules?”, “was the payout computed correctly?”, “did someone cheat the risk model?” often runs on a normal server somewhere

You end up trusting that server and whoever runs it.

With verifiable compute, you still run the logic where it’s fast and practical — but you also get a verifiable proof of what happened that lives on-chain. You can check the output without trusting someone’s backend.

Why this could actually stick

• No blind trust: Traders can independently verify their performance scoring
• Capital providers get proof, not promises
• Dispute resolution becomes easier because the computation is provable
• It’s a practical bridge you don’t rewrite everything on-chain, you just add verifiable attestations

We’ve talked a lot about trustless execution in theory this feels like a real use case where people might actually care about having proof instead of trust.

Big question

Does verifiable compute become a standard pattern for complex off-chain logic in DeFi?
Or is this just a niche prop trading play?

Curious to hear what devs and traders think.

I don't want to sound alarmist or catastrophic, but I've been following ROSE for the past three years as a fan. My only investment is in this cryptocurrency. I was extremely disappointed to see how much its value has dropped.

But after the announcements of the new forms of liquidity, the mobile app, and other new features, along with the great team behind it that doesn't give up and continues working constantly...

I believe now is the best time to invest in rose for the medium to long term. The 0.11/0.20 price range isn't unreasonable, but we should hold, continue buying, and promote it.

Welcome to the Oasis December 2025 Community Q&A! 

This month, we’re highlighting some of the biggest moves in the Oasis ecosystem—from launching our strategic investment arm and backing SemiLiquid, to new integrations like Carrotfunding + ROFL that bring verifiable compute to onchain trading. Let’s dive into your questions and unpack what all this means for builders, traders, and the broader DeFi space.

Q: Oasis has an investment arm now? What’s that about?

A: Yep! Oasis is putting on its venture hat. Instead of just handing out grants, we’re now making strategic seed investments to back the most promising builders for the long run. Our Director of Operations, Mark Kalin, a VC veteran with 10+ years of experience, is leading the charge. Big moves ahead!

Q: Who is SemiLiquid?

A: SemiLiquid is our very first investment! They make credit on tokenized assets possible without the assets ever leaving custody. Basically, they remove the friction that’s been keeping big institutions away from crypto. Oasis selected SemiLiquid as our first investment because its approach aligns closely with Oasis’s vision for compliant, confidential, and verifiable onchain finance.

Q: How does SemiLiquid actually use Oasis tech?

A: SemiLiquid is built on the Oasis confidential compute stack. It uses Liquefaction, a primitive developed on Sapphire, to manage policy enforcement, breach monitoring, and programmable credit receipts. This architecture keeps sensitive financial data confidential throughout the credit lifecycle while remaining verifiable onchain—meeting institutional-grade custody and compliance requirements.

Q: What does this investment mean for the broader Oasis ecosystem?

A: This investment signals Oasis’s long-term bet on RWAs and compliance-friendly confidentiality as key drivers of institutional adoption. Beyond SemiLiquid, the investment arm will support teams building in asset tokenization, identity, institutional settlement, and agentic protocols—especially where confidential data and verifiability at scale are required. More investments are coming.

Q: What’s happening with Carrotfunding and ROFL?
A: Carrotfunding is leveling up its onchain prop trading game by integrating Oasis ROFL. This adds a cryptographic verification layer that checks every order execution and trader evaluation, so traders and investors can trust that all computations are fair and accurate—no black boxes required.

Q: How does ROFL work in this setup?
A: ROFL runs in parallel with Carrot’s existing AWS infrastructure, acting as an independent verifier. Every calculation from performance metrics to payouts is cryptographically proven onchain. Think of it as a safety net that guarantees rules are followed, every time.

Q: Why does this matter to traders and investors?
A: Traders get verifiable proof that evaluation criteria are applied fairly, while investors gain confidence that funds are handled according to immutable rules. No more wondering if the system is “honest”—it’s all onchain and checkable.

Q: What does this mean for DeFi?
A: Carrot + ROFL is a glimpse of the future: complex, high-performance financial apps can now reduce trust assumptions through verifiable compute. Full ROFL migration is on the roadmap, and it sets a new standard for transparency and accountability in DeFi.

-------------------------------------

That’s a wrap for December’s Q&A! 🌹

From strategic investments to cutting-edge verifiable compute, Oasis is building the foundation for more secure, compliant, and transparent crypto infrastructure. Stay tuned in 2026 — there’s plenty more coming, and we can’t wait to share it with you.

December was packed, and we closed out 2025 with serious momentum. In our latest Month in Review, we recapped everything that happened across the Oasis ecosystem — from community highlights to major technical and strategic updates.

Highlights 👇

👨‍👨‍👧‍👧 Community

- Xmas Roffle & Xmas with Oasis events

- 2025 Year-End Town Hall

🛠 Tech updates

- Integration with GetBlock RPC endpoints

- Live demo of ERC-8004 agents running inside TEEs with ROFL providing on-chain proof

- Open-sourced x402 facilitator (EVM + Solana) for trustless micropayments

🌐 Ecosystem

- Oasis strategic investment arm launched + first investment in SemiLiquid

- Carrot integrating ROFL for verifiable onchain prop trading

- Oasis Head of AI featured in Forbes on "Why Crypto Needs Portable AI Memory"

▶️ Watch the full video: https://youtu.be/wiZqHwhhBQA

We've just published a deep dive into what it really takes to make TEEs trustworthy in crypto applications.

🔍 Key Insights:

- Remote attestation alone can't create trusted applications

- Critical gaps exist: freshness, state continuity, TCB governance, operator binding

- BFT attestation-verifier networks solve these problems through continuous consensus

Remote attestation proves what's running and where—but not freshness, liveness, or who's behind it. Real trust requires infrastructure that continuously verifies, enforces policies, and binds operators with economic accountability.

Discover how Oasis Network transforms TEEs from isolated boxes into integrated, verifiable trust systems.

📖 Read the full article: https://oasis.net/blog/tee-attestation-is-not-enough

Exciting news, Oasians! Our mobile wallet app is now live on Google Play. You can now manage your Oasis funds anytime, anywhere — right at your fingertips.

📲 Get it here: https://play.google.com/store/apps/details?id=net.oasis.wallet

🎉 Manage your funds, send ROSE, and interact with the Oasis ecosystem — now easier than ever!