Skip to main content

Oasis Network

Oasis Network (ROSE) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Oasis Network — a Layer‑1 blockchain (PoS) with a modular architecture of consensus layer + ParaTime layer (parallel runtimes). In Tier‑1 sources the focus is on confidential computing (TEE/secure enclaves), “smart privacy”, EVM‑compatible ParaTimes (e.g. Sapphire) and the offchain compute framework ROFL.

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an L1 network for smart contracts with privacy: parallel runtimes (ParaTimes) + tools for confidential dApps.
  • Who it’s for: dApp developers (especially EVM), teams that need data/state privacy; validators/delegators.
  • Why onchain/token: onchain is needed for consensus/smart contract execution; the ROSE token — for fees, staking/delegation and governance (per Tier‑1).

How it works (very briefly)

  1. The user does: sends transactions or calls smart contracts in the chosen ParaTime (e.g. Sapphire).
  2. The system does: the consensus layer (PoS validators) orders and confirms updates; ParaTimes execute transactions in parallel and commit the results.
  3. The user gets: confirmed onchain operations; in confidential ParaTimes — the ability to execute logic over private data.
  4. Where the blockchain is: base consensus and accounting of balances/staking — on the consensus layer; computation/smart contracts — in ParaTimes.
  5. Token role: ROSE is used for gas/fees, staking/delegation and participation in governance.

Quick links: AI thesis fit

Project passport

Field Value
Project name Oasis Network
Also known as (aliases) Oasis Protocol | ROSE
Logo (logo) ../assets/oasis_logo.svg
Token symbol (ticker) ROSE
Category AI/Other | Infra
Primary chain (chain) Oasis Network
Type Appchain
Network status mainnet
Consensus (consensus) PoS (CometBFT)
Launch date (launch_date) —
Project status (status) active
Token (standard) native
Token contract —
Token model (token_type) utility (gas + staking + governance)
Max supply 10000000000
Issuance fixed (capped) + staking rewards
Tokenomics (tokenomics, brief) cap 10B; ~2.3B are distributed as staking rewards (per docs/website)
Governance onchain governance (proposals/voting)
Admins/keys —
Audit —
Bug bounty yes (Immunefi)
Team (team) Oasis Foundation | Oasis Labs (claimed)
Funding (investors/funding) raised $45M+ (2018–2020; per docs)
AI component (ai_component) confidential compute for verifiable AI (infra)
Use‑case (use_case) confidential EVM + parallel runtimes
DecAI Fit — AI thesis fit 3/6 — medium alignment with the Decentralized AI thesis
DecAI Fit component summary 1 / 3 / 3 / 3
Last verified 2026-02-11

General project overview

Oasis Network is an L1 smart contract platform that, in Tier‑1, describes itself as a “privacy‑first” network with a modular architecture: separation of consensus (PoS validators) from execution/compute (ParaTimes). ParaTimes can be “regular” (without privacy), “confidential” (based on TEE), as well as EVM‑compatible (e.g. Sapphire) — this lets different applications choose the trade‑offs they need between privacy/performance.

Features/modules

  • Consensus layer: PoS consensus, staking/delegation, basic network operations.
  • ParaTime layer: parallel runtimes with shared state and the ability to isolate according to application requirements.
  • Confidential computing: the TEE mechanism for confidential ParaTimes described in the docs (data is decrypted/processed/encrypted inside the enclave).
  • EVM ParaTimes: positioning of Sapphire as a confidential EVM (per the website/docs).
  • ROFL (offchain compute): a framework for “verifiable off-chain compute” with onchain guarantees (per the website).

Typical scenarios

  • Scenario 1: a developer deploys a Solidity contract on Sapphire → users interact as on an EVM network, but with the option of confidentiality.
  • Scenario 2: a validator/delegator stakes ROSE on the consensus layer → receives staking rewards.
  • Scenario 3: a dApp uses the ParaTime approach to separate “heavy” computation from other workloads and improve scalability.

Getting started (wallet/network)

  • What you need: a wallet for the Oasis consensus layer (ROSE Wallet / Oasis CLI) for staking/delegation and an EVM wallet (e.g. MetaMask) for Sapphire.
  • Network/chain: Oasis Network (consensus layer) and the chosen ParaTime (Sapphire, etc.).
  • Fees: gas/fees are paid in ROSE; operations differ between the consensus layer and ParaTimes.

Architecture/tech (non‑AI)

  • Components: consensus layer validators; ParaTimes as separate replicated compute environments; key manager components for confidential ParaTimes (per the whitepaper).
  • Participant roles: users; ParaTime/dApp developers; validators; delegators.
  • Where logic runs: consensus provides ordering/commit; ParaTimes execute transactions and form state updates.
  • Dependencies: TEE hardware/attestation (for confidential ParaTimes); the network/validator stack; wallet/CLI tools.

Token/economics (expanded, no forecasts)

  • Token utility: ROSE is used for transaction fees, staking, delegation and governance voting (Tier‑1 docs/website).
  • Protocol necessity drivers: without ROSE it is impossible to pay fees and participate in securing the network via PoS.
  • Who pays fees: users (gas) and participants performing operations on the network/ParaTimes.
  • Where fees go: into the design of the PoS network (validators/network economy; the specific parameters depend on protocol rules).
  • Issuance/burn: capped supply of 10B; a separate amount of tokens is distributed as staking rewards (per docs).
  • Security/incentive mechanisms: staking/delegation; slashing for double‑signing (described in token metrics & distribution).
  • Distribution and token issuance schedule: the docs publish the distribution by category and a circulation/release schedule; fundraising and pre‑mainnet distributions are mentioned.
  • Treasury: the docs describe allocation categories (including the Foundation Endowment and ecosystem programs).

Governance

In Tier‑1 sources ROSE is used for participation in governance (voting on network decisions). The docs also describe stake‑weighted voting power and the link to the Tendermint/CometBFT block‑signing model.

Security and incidents

  • Bug bounty: an official bug bounty via Immunefi; also security policies/a reporting process for oasis-core.
  • Security advisories: the GitHub security section of the repository states that there are no published advisories (at the time of verification).
  • TEE risks: Tier‑1 emphasizes the dependence of confidential ParaTimes on TEE and remote attestation, as well as a layered approach (TEE + cryptography).

Project status and timeline

  • Current status: the network and ParaTimes are available on mainnet (per the website/docs).
  • Key releases/milestones: releases of the core client and ParaTime components are published on GitHub.
  • Roadmap: the official roadmap blog section.

Ecosystem/integrations

  • Integrations: ROSE Wallet, Oasis CLI; MetaMask for EVM ParaTimes; dApps on Sapphire (per the website/tokenomics).
  • Where it’s actually used: the website shows examples/“featured apps” and use cases (agents/DeFi/DAOs/Responsible AI).

AI component of the project

  • What is real AI here? Tier‑1 sources position the network as infrastructure for “AI privacy” and mention verifiable AI/agents as use cases (ROFL), but do not describe a proprietary AI model/inference product at the protocol level.
  • What is truly onchain? L1 consensus + ParaTimes, including an EVM ParaTime (Sapphire); addresses/accounts/ledger and operations — on the Oasis network.
  • Why is a token needed? ROSE is needed for fees, staking/delegation and governance — this is the basic “native token” function of the network.
  • Red flags (based on the information found): AI‑washing (mentioning AI as a use case is not the same as having an AI product); TEE dependence (threat model/attestation); what to double‑check: the specific governance/economic parameters on the current protocol version and the real onchain artifacts of ROFL/ParaTimes.

DecAI Fit component summary

  • DecAI Fit: 3/6 — medium alignment with the Decentralized AI thesis
Component Level Score
AI reality low 1
Onchain necessity high 3
Token necessity high 3
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 1
  • Claim (one line): in Tier‑1 the network declares a focus on “Web3 & AI privacy” and use cases such as verifiable AI/agents (as an application direction).
  • Evidence: Tier‑1 — https://oasisprotocol.org/
  • Why sufficient / why not (one line): there is direct positioning and a description of use cases.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): Tier‑1 sources do not describe a built‑in AI model/inference as part of the protocol; AI is mentioned as a possible application of the infrastructure.
  • Evidence: Tier‑1 — https://docs.oasis.io/general/oasis-network/
  • Why sufficient / why not (one line): the docs describe confidential computing and ParaTimes, not an AI model.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): no reproducible demo example of an “AI module of the protocol” (in the sense of a model/agent) was found in Tier‑1; there are only examples of dApps/use cases.
  • Evidence: Tier‑1 — https://oasis.net/rose-and-tokenomics
  • Why sufficient / why not (one line): the page mentions dApps and use cases, but not a demo of an AI module.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://oasisprotocol.org/
  • Why sufficient / why not (one line): no AI metrics are provided.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): there is no technical description of an AI architecture/model versions, since AI is not presented as a separate protocol component.
  • Evidence: Tier‑1 — https://docs.oasis.io/general/oasis-network/
  • Why sufficient / why not (one line): the docs describe the architecture of the network/ParaTimes/TEE, but not an AI model.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Oasis Network (consensus layer + ParaTimes)
  • Addresses/identifiers: native addresses in the oasis1… format (consensus) and 0x… (EVM ParaTimes, e.g. Sapphire).
  • Evidence: Tier‑1 — https://docs.oasis.io/general/manage-tokens/
  • Why sufficient / why not (one line): the docs describe the address formats and the separation of the ledger between layers.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: ParaTimes execute smart contracts, while the consensus layer commits updates (two‑layer architecture).
  • Evidence: Tier‑1 — https://docs.oasis.io/general/oasis-network/
  • Why sufficient / why not (one line): the consensus + execution architecture and parallel runtimes are described.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 1
  • “Replace the blockchain” test: the core value is the trusted onchain commit/consensus and smart contract execution; without a blockchain it ceases to be an L1 network.
  • Evidence: Tier‑1 — https://oasis.net/whitepaper
  • Why sufficient / why not (one line): the whitepaper directly describes an L1 PoS smart contract platform and a modular architecture.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): ROSE is the native token of Oasis Network.
  • Evidence: Tier‑1 — https://oasis.net/rose-and-tokenomics
  • Why sufficient / why not (one line): the website describes ROSE as the native token of the ecosystem.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 1
  • Claim (one line): ROSE is used for transaction fees (gas) on the consensus layer and ParaTimes.
  • Evidence: Tier‑1 — https://oasis.net/rose-and-tokenomics
  • Why sufficient / why not (one line): “ROSE is used for transaction fees…” is stated explicitly.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): ROSE is used for staking/delegation; staking rewards and slashing for double‑signing are described.
  • Evidence: Tier‑1 — https://docs.oasis.io/general/oasis-network/token-metrics-and-distribution
  • Why sufficient / why not (one line): there are staking/slashing parameters and a rewards economy.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): governance/voting are mentioned as a utility of ROSE and as a network function.
  • Evidence: Tier‑1 — https://docs.oasis.io/general/manage-tokens/
  • Why sufficient / why not (one line): the docs explicitly list governance proposal voting as a use of the native token.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): for an L1 network the token as gas/staking/governance is systemic and not replaceable without a change of design.
  • Evidence: Tier‑1 — https://docs.oasis.io/general/manage-tokens/
  • Why sufficient / why not (one line): it is described that the native token is used for PoS and fees.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.oasis.io/general/oasis-network/ consensus + ParaTimes architecture, confidential computing (TEE), scalability/privacy
Tier‑1 https://oasis.net/whitepaper L1 PoS smart contract platform, ParaTimes and the confidential computing approach
Tier‑1 https://oasis.net/rose-and-tokenomics cap 10B, utility of ROSE (fees/staking/delegation/governance), overall positioning
Tier‑1 https://docs.oasis.io/general/oasis-network/token-metrics-and-distribution token metrics, distribution, staking incentives, slashing, fundraising $45M+
Tier‑1 https://docs.oasis.io/general/manage-tokens/ the role of the native token (fees/governance/staking), address formats and the layering of the ledger
Tier‑1 https://oasisprotocol.org/ positioning as “Web3 & AI privacy”, ROFL/OPL/Sapphire as products
Tier‑1 https://oasis.net/security-and-tees layered security approach (TEE + crypto) and a link to the bug bounty

No comments to display

Back to top