Layer 1 blockchain
Oasis Network ticker ROSE
Summary
Proof-of-stake network whose consensus layer runs Oasis Core on an Oasis-maintained fork of the CometBFT engine (0.37 series), not the Cosmos SDK. ROSE holders stake or delegate to entities; validator voting power is proportional to escrowed stake, at most one node per entity sits in the validator set, and the set is capped at 120 seats. A block is final once validators holding more than 2/3 of voting power sign it. Smart contracts run separately in ParaTimes: elected compute committees execute each batch, sign commitments that the consensus layer checks for matching results, and hand any disagreement to a larger backup committee. Sapphire and Cipher execute inside Intel SGX enclaves so contract state stays encrypted from node operators. 23467122425
Design
- System
- Layer 1 blockchainOasis calls itself a layer 1 proof-of-stake network; the package class is kept. Its consensus layer orders transactions and records state commitments for separate execution environments called ParaTimes (Sapphire, Emerald, Cipher). ParaTimes have no consensus of their own and post no data or proofs to another chain, so they are neither rollups nor sidechains but execution lanes inside one network. Confidential ParaTimes add an Intel SGX requirement and on-chain admission rules for the machines that run them.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Economic finality
- Who makes blocks
- Validators propose consensus blocks in round-robin order weighted by voting power. On 2026-09-27 the Oasis Nexus indexer showed 73 entities in the validator set, below the 120-seat cap; the smallest held 200 ROSE in escrow, seven validators together exceeded one third of voting power and the largest held about 12%. In each ParaTime round one primary executor node is chosen as transaction scheduler, which plays the block-proposer role for that ParaTime.
- Fork choice
- No fork choice in the Nakamoto sense: each height is decided by more than 2/3 of voting power precommitting, and the Oasis docs say the network halts until enough signatures arrive rather than forking. Double-signing and light-client attacks are punished by a fixed 100 ROSE slash plus a permanent ban of the offending node, not by a share of the validator's stake.
Qualifications
- Paratime execution layers · Applies. Sapphire, Emerald and Cipher are execution environments on the same network. Each keeps its own ledger and commits state roots to the consensus layer every round; integrity comes from replicated execution with discrepancy detection and storage receipts, not from fraud or validity proofs, and they share the consensus layer's finality. They are recorded here rather than as layer 2 systems.
- Evm compatibility · Partial. Sapphire (chain ID 23294) and Emerald (chain ID 42262) accept EVM transactions and Ethereum wallets and count ROSE with 18 decimals. The consensus layer, where staking and most exchange deposits happen, uses ed25519 keys, oasis1 addresses and 9 decimals, and EVM wallets cannot sign its transactions. On Sapphire, contract storage reads return zero apart from a few standard proxy slots, and unsigned read calls have a zero sender.
- Confidentiality trust model · Contested. Sapphire keeps contract state, and optionally call data, encrypted inside Intel SGX enclaves; transaction status, logs and contract bytecode stay public. Physical memory-bus attacks (WireTap and Battering RAM in 2025, and TEE.fail) broke SGX, TDX or SEV-SNP protections used by other networks, and TEE.fail also forged Intel SGX and TDX attestation. Oasis stated on 2 October 2025 that its SGX version was unaffected by the first two, citing per-epoch key rotation and governance-gated key managers. That is its own assessment, not an audit, and it does not address TEE.fail.
- Equivocation penalty · Partial. Finality is backed by slashing, but the mainnet penalty for double-signing or a light-client attack is a flat 100 ROSE plus a permanent ban of the node, whatever the validator's stake; downtime is not slashed. A design record for slashing misbehaving compute nodes is marked accepted, but whether any ParaTime enables it was not verified.
- Throughput figures · Unknown. Oasis pages describe increased throughput for ParaTimes without a measured figure, method or window, so no throughput claim is recorded.
- Settlement family · Partial. Recorded as other: Oasis settles on its own consensus layer, where Oasis Core runs on an Oasis-maintained fork of CometBFT and records state commitments for the ParaTimes (Sapphire, Emerald and Cipher) that run contracts; nothing settles to another chain. None of the named settlement families describes this.
Tradeoffs
- Emphasizes
- Security and Scalability
- Gives up
- Decentralization of execution and some trust minimization. Confidential contracts on Sapphire and Cipher run only on compute nodes with Intel SGX hardware whose operators must also be validators, and Sapphire or Emerald compute nodes need 5 million ROSE of stake; Sapphire reported 40 active nodes on 2026-09-27. Joining the key-manager committee requires governance approval. Confidentiality depends on trusting Intel SGX, and the chain stops producing blocks if more than a third of voting power is offline.Scalability here is a design aim (several execution environments share one consensus layer, and each ParaTime's batches are executed by an elected compute committee rather than by every validator); no measured throughput figure was verified. Consensus-layer full nodes are practical to run, and on 2026-09-27 the validator set was not full, so joining it was limited mainly by running a reliable node rather than by stake rank. Privacy is not one of the three corners; it rests on hardware enclaves.
- Full node at home
- Practical at home 8910For a consensus validator or non-validator node Oasis recommends 2 cores with AES and AVX2, 8 GB of ECC RAM and 700 GB of SSD (minimums 6 GB and 400 GB); validators also need 200 Mbps to 1 Gbps. A ParaTime compute or client node needs 12 to 20 GB of ECC RAM plus 200 to 300 GB of extra SSD for Sapphire or Cipher, or 400 to 700 GB for Emerald; pruning helps. ECC memory is uncommon in home PCs. Confidential Sapphire queries need an SGX observer node that may need on-chain approval.
- Throughput claims
- No classified figure recorded
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | No hash-time-locked or equivalent trust-minimized swap between two parties was verified on the consensus layer or in a ParaTime. EVM contracts on Sapphire could implement one, but none was reviewed. |
| Authenticated data publication | Unknown | Not yet assessed under the current definitions; ROFL runs off-chain applications in hardware enclaves and lets Sapphire contracts check that a transaction came from an attested application. That authenticates who submitted data; the reviewed source does not describe publishing data against a commitment the chain records for others to retrieve and check, and absence was not exhaustively verified. 22 |
| Light clients | Built into the protocolFull scope | Consensus produces what a light client checks: blocks signed by validators holding more than 2/3 of voting power. Oasis Core uses the CometBFT light client for state sync, lets a client node read remote state checked by its light client instead of storing it (added in 25.5, reworked in 26.1), and has ParaTime enclaves verify consensus state with a light client. Light-client attacks are slashable. 724 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Oasis was found in the reviewed documentation. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Sapphire and Emerald run EVM smart contracts (Sapphire with encrypted state) and Cipher runs WebAssembly contracts; Oasis Safe offers multisignature custody on Sapphire. Consensus-layer accounts are plain key accounts with allowances. 5111218 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; no way for a sender to cancel or reclaim a payment, and no recovery path, was found. The consensus layer's allowance feature lets an owner authorize another account to withdraw up to a limit, which is delegated spending rather than recovery. Oasis described Privana policy vaults on Sapphire (spending limits, revocable delegation) in 2026, but a production release was not verified. 529 |
| Rollups | Unknown | Absence was not verified, so the rule that absence needs a source makes this unknown rather than not present. Earlier finding: no rollup settling to Oasis was found in reviewed sources; ParaTimes are execution environments inside the network, not rollups, and the Oasis FAQ says the design scales without sidechains. Trezor's Oasis page mentions native rollup support without detail. 1639 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | ThinThorn Protocol (status unclear), NEBY DEX (status unclear) | DefiLlama lists exchange contracts on Sapphire (Thorn Protocol, NEBY DEX) and older ones on Emerald (YuzuSwap, DuneSwap, ValleySwap, GemKeeper and others) with small remaining balances, and flags nearly all of their websites as dead. On 2026-09-27 the NEBY domain did not resolve and the Thorn domain showed an independent notes page that says it does not run a current service. The Oasis docs mention Neby only as an example user of a message bridge and name no current exchange. No currently maintained venue was verified. 2133 |
| Issuer-native stablecoins | ThinBitUSD (Bit Protocol, over-collateralized; small use on Sapphire) | Circle and Tether do not list Oasis, so USDC and USDT on Sapphire are bridged copies (Celer cBridge from Ethereum). Bit Protocol's own site lists Oasis among the networks for its over-collateralized BitUSD, and a BitUSDs token appears in the Sapphire indexer, but DefiLlama showed negligible collateral in it on Sapphire. 142730333435 |
| Algorithmic stablecoins | Unknown | DefiLlama lists one algorithmic stablecoin on Emerald (Tulip) with its website flagged as dead; no active algorithmic or hybrid stablecoin on Oasis was verified. 33 |
| Bridges | Established in the ecosystemCeler cBridge (Ethereum, BNB Chain, Polygon), Router Protocol, Hyperlane (messaging), Celer Inter-Chain Messaging, Wormhole (Emerald, deprecated) | The Oasis docs name Celer cBridge as the main token bridge to Sapphire, from Ethereum, BNB Chain and Polygon only, and list Router Protocol, Hyperlane and Celer messaging for cross-chain applications. Wormhole served Emerald and is marked deprecated. Moving ROSE between the consensus layer and a ParaTime is an in-protocol deposit or withdrawal, not a bridge. Risk: Bridged tokens such as USDC.e and USDT on Sapphire are claims on assets held by the bridge on the source chain. cBridge and Celer messaging depend on Celer's State Guardian Network validators, Router on its orchestrators and Hyperlane on its configured validators; a failure there, or a transfer sent to the wrong network, is outside Oasis consensus. 1419202136 |
| Block explorers | First-partyOasis Explorer, Oasis Nexus API (indexer), Covalent (indexer) | The Oasis team runs Oasis Explorer for the consensus layer and the ParaTimes. Oasis Scan, still listed in the docs as a separate explorer, redirected to Oasis Explorer when checked on 2026-09-27, so no independent explorer was confirmed. Encrypted Sapphire calls limit what any explorer can show. 12131540 |
| Hardware wallets | ThinLedger (through ROSE Wallet or Oasis CLI), Trezor (Sapphire and Emerald through MetaMask or Rabby) | See custody rows: both devices reach Oasis only through other wallets. Ledger works with the Oasis device app through the Oasis team's ROSE Wallet and command-line tool; Trezor reaches only the Sapphire and Emerald EVM networks, through MetaMask or Rabby. Neither vendor's own app manages consensus-layer ROSE. 17373839 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Through an intermediaryROSE Wallet (web or browser extension) or the Oasis CLI, with the Oasis app installed on the Ledger deviceSame as native: No | Can: Keep consensus-layer ROSE keys on a Ledger Nano S, S Plus, X, Stax or Flex with the Oasis device app Can: Send and delegate ROSE on the consensus layer through ROSE Wallet, approving each transaction on the device Can: Deposit to and withdraw from ParaTimes with a Ledger account in the Oasis CLI Cannot: Manage ROSE inside Ledger's own app: both Ledger's page and the Oasis guide point to third-party wallets Cannot: Sign ParaTime transactions with Ledger in ROSE Wallet web or extension, which the Oasis guide says is not yet supportedROSE Wallet uses a Ledger-specific key derivation by default, so restoring a Ledger recovery phrase in software may need Oasis's conversion tool. 151737 |
| Trezor | Through an intermediaryMetaMask or Rabby, for the Sapphire and Emerald networks onlySame as native: No | Can: Approve Oasis Sapphire and Emerald transactions on a Trezor Safe 3, 5 or 7 through MetaMask or Rabby Cannot: Manage consensus-layer (oasis1) accounts, which Trezor does not list Cannot: Stake from a consensus-layer account; Oasis says some ParaTime apps can delegate from a ParaTime account, but that route was not checked with Trezor Cannot: Sign ParaTime deposits or withdrawals, which the Oasis docs say EVM wallets cannot do; the ROSE App route for EVM wallets was not checked with Trezor Cannot: Treat the BNB Smart Chain token version of ROSE as Oasis custodyTrezor's page names Trezor Suite among compatible apps and lists BNB Smart Chain, Oasis Emerald and Oasis Sapphire. Trezor Suite's current EVM network configuration includes BNB Smart Chain but not Sapphire or Emerald, so Suite reaches only the BNB Smart Chain token version of ROSE, which does not count as Oasis custody. 15163839 |
Public data
iKnow Blockchain has no public-data lookups for Oasis Network yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
Oasis disclosed a simulation attack on upgradeable confidential contracts
An Oasis engineer described how someone holding upgrade rights over a confidential Sapphire contract could recover a stored private key bit by bit by simulating upgrades, because simulated calls never reach the chain. Oasis says it found the issue internally and held its deployments until it was remediated. The fix, a two-step upgrade that cannot complete within one block, shipped in version 0.2.18 of the sapphire-contracts library, and the post says the Privana services that prompted the work now run on it.
- Implementation:mitigation pattern released in a library
- Release:sapphire-contracts 0.2.18
- Activation:applies only to contracts that adopt the pattern
Sources: Oasis blog — Accessing a Vault Key With Simulated Upgrades (external site) · npm registry — @oasisprotocol/sapphire-contracts package metadata (external site)
-
Oasis Core 26.1 released and listed as the Mainnet node version
Oasis Core 26.1 added an explicit observer mode, a setting that lets a client node use remote state checked by its light client instead of local storage (replacing the earlier stateless-client mode), and released offline storage pruning and compaction commands. It also added a check of the runtime identifier on messages in the root hash service and updated its CometBFT fork. Its protocol versions are unchanged from 26.0.
- Implementation:Released
- Release:26.1 published 2026-06-08
- Activation:listed as the Mainnet version on the network parameters page at review
Sources: oasisprotocol/oasis-core maintainers — Oasis Core change log (v26.1) (external site) · oasisprotocol on GitHub — Oasis Core v26.1 release (external site) · Oasis documentation — Mainnet network parameters (external site) · oasisprotocol on GitHub — go/v0.2601.0 (Version 26.1) (external site)
-
Oasis announced a shift toward building its own applications
Co-founder Jernej Kos wrote that Oasis is realigning internally and focusing on the application layer. The post said the first result, Privana (private trading, yield and automation with self-custody), was live, and that Oasis would keep supporting third-party developers. The post announced no protocol or token change.
- Implementation:internal realignment announced
- Release:post called Privana live; its site showed a waitlist on 2026-09-27
- Activation:no network change
Sources: Oasis blog — Oasis: New Chapter (external site) · Oasis blog — Privana: A Practical Liquefaction Implementation (external site) · Privana — Privana (external site)
-
Oasis Core 26.0 released with an SGX quote-policy change and storage fixes
Oasis Core 26.0 is a node software release that keeps the consensus (7.0.0), runtime host (5.1.0) and runtime committee (5.0.0) protocol versions of 25.9. Its one listed breaking change adds an FMSPC whitelist field to the SGX quote policy used when checking enclave attestations. It adds a storage inspect command for offline maintenance, fixes a pruning edge case that could remove runtime light history too early, stops a node with pruning turned off from deleting data left from an earlier pruning run, corrects a PCE SVN check in SGX TCB validation and makes the scheduler skip key manager runtimes. The release notes thank Bluethroat Labs for responsibly disclosing several problems but do not say which changes address them.
- Implementation:Released
- Release:26.0 published 2026-03-12; superseded by 26.1 on 2026-06-08
- Activation:no network upgrade tied to the release; FMSPC whitelist entries accepted only once feature version 24.2 is enabled, not confirmed for Mainnet
Sources: oasisprotocol on GitHub — Oasis Core 26.0 (external site) · oasisprotocol/oasis-core maintainers — Oasis Core change log (v26.1) (external site) · oasisprotocol on GitHub — oasis-core pull request #6331: FMSPC whitelist in the SGX quote policy (external site) · oasisprotocol/oasis-core maintainers — go/common/sgx/quote/quote.go at v26.0 (external site) · oasisprotocol on GitHub — go/v0.2600.0 (Version 26.0) (external site) · Oasis documentation — Mainnet network parameters (external site)
-
Oasis said the 2025 memory-bus TEE attacks did not affect its SGX deployment
After researchers published the Battering RAM and WireTap physical attacks, which extracted secrets from enclaves used by other networks, Oasis stated that its key manager and Sapphire run on an SGX version with a different memory-encryption design that was not affected, and that user privacy was not compromised. It also pointed to governance-gated key-manager membership, per-epoch key rotation and an updatable CPU blocklist.
- Implementation:statement published; mitigations described as already in place
- Release:no software release tied to the statement
- Activation:no network change announced
Sources: Oasis blog — Oasis statement on the Battering RAM and WireTap TEE attacks (external site) · WireTap research team — WireTap: Breaking Server SGX via DRAM Bus Interposition (external site) · TEE.fail research team — TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (external site)
Topics your AI can explain
Your AI can explain these topics for Oasis Network through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Validator set size, voting-power shares and the Sapphire active node count are single readings from the Oasis Nexus indexer on 2026-09-27; they change with delegations and node registrations.
- The genesis parameter page shows older values (a 100-validator cap, 22 MB blocks, unlimited block gas) that differ from the 120-seat cap on other docs pages and from the 5 million gas and 4 MB block limits the indexer reported; current on-chain parameters were not read directly from a node.
- Whether slashing of misbehaving compute nodes is enabled for Sapphire, Emerald or Cipher was not verified.
- Who operates Sapphire compute and key-manager nodes today, and the exact admission policy, were not verified beyond Oasis's 2022 and 2025 statements and the stake requirements page.
- No independent assessment was found of Oasis's claim that its SGX deployment was unaffected by the 2025 memory-bus attacks, and no Oasis statement on TEE.fail's forged SGX attestation was found.
- No currently maintained exchange on Sapphire or Emerald was verified; most listed venues have inactive websites.
- Bit Protocol lists Oasis as a BitUSD network, but how much BitUSD is in use on Sapphire was not measured beyond DefiLlama's collateral reading.
- Oasis said in April 2026 that its first Privana product was live, but Privana's site offered only a waitlist on 2026-09-27, so general availability was not confirmed.
- Third-party paths for signing consensus-layer transactions with a Trezor were not checked; Trezor Suite's network configuration read on 2026-09-27 includes no Oasis network.
- The security of Celer's State Guardian Network and of the other message bridges was not reviewed in depth.
- No throughput figure with a stated method or window was found.
- No atomic swap mechanism, reversible-transfer or recovery feature, payment or state channel, or rollup anchored to Oasis was found; absence was not exhaustively verified.
- Usage of Emerald and Cipher, and whether Privana's policy vaults have launched, were not reviewed.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Frequently Asked Questions (Oasis Network) (external site)
- Token Metrics and Distribution (external site)
- Consensus Layer (external site)
- Committee Scheduler (external site)
- Staking (external site)
- Runtime Layer (external site)
- Genesis Document (external site)
- Hardware Requirements (external site)
- Stake Requirements (external site)
- ParaTime Observer Node (external site)
- Sapphire ParaTime (external site)
- Sapphire vs Ethereum (external site)
- Sapphire network information (external site)
- Contract Addresses and Deployments (external site)
- Manage your Tokens (external site)
- Staking and Delegating (external site)
- Ledger Hardware Wallet (external site)
- Custody Providers & Protocols (external site)
- How to Bridge Assets to Oasis Sapphire (external site)
- Frequently Asked Questions (Manage your Tokens) (external site)
- Oasis Privacy Layer (OPL) (external site)
- Runtime Off-Chain Logic (ROFL) (external site)
- ADR 0005: Runtime Compute Node Slashing (external site)
- Oasis Core change log (v26.1) (external site)
- Consensus validators (Oasis Nexus indexer API) (external site)
- Sapphire runtime status (Oasis Nexus indexer API) (external site)
- Sapphire token list, first 25 (Oasis Nexus indexer API) (external site)
- Oasis statement on the Battering RAM and WireTap TEE attacks (external site)
- Privana: A Practical Liquefaction Implementation (external site)
- BitUSD Protocol (external site)
- WireTap: Breaking Server SGX via DRAM Bus Interposition (external site)
- TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (external site)
- DefiLlama protocol list (filtered for Oasis, Sapphire and Emerald) (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
- cBridge documentation (external site)
- Oasis Network wallet (external site)
- Trezor Suite Ethereum-style network configuration (trezor-suite, develop branch) (external site)
- Oasis wallet (external site)
- Oasis Scan (redirects to Oasis Explorer) (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding