“The Oasis Network: A Privacy-Enabled Blockchain Platform for Open Finance” is the 2020 whitepaper by Oasis Labs and the Oasis Foundation describing the Oasis Network — a Layer 1 designed by cryptographer Dawn Song (UC Berkeley) and her team. The network’s defining feature is its separation of consensus and compute into distinct layers: a BFT consensus backbone (the “Consensus Layer”) and modular execution environments called ParaTimes, which can optionally use Intel SGX Trusted Execution Environments (TEEs) for confidential computation.

The design targets a “responsible data economy” — enabling applications where sensitive data (medical records, financial data, user behavior) can be processed without being visible to the compute provider.

> Papers: Available at oasisprotocol.org/papers.

---

Publication and Context

In 2020, DeFi was exploding but entirely transparent — every trade, loan, and liquidation was visible to all on-chain observers. This transparency creates front-running (MEV bots seeing your transaction and inserting their own before it), loss of financial privacy, and constraints on enterprise adoption (businesses cannot share proprietary data with a public blockchain).

Oasis’s hypothesis: a blockchain with configurable confidentiality — where some execution environments are fully transparent and others are privacy-preserving via hardware enclaves — could attract enterprise and DeFi users who need privacy without sacrificing verifiability.

---

Consensus Layer

The Oasis Consensus Layer is a Delegated Proof of Stake BFT network using Tendermint-based consensus:

• Validators lock ROSE tokens (the network’s native token) as stake
• Delegators can delegate ROSE to validators to earn staking rewards
• The consensus layer finalizes blocks, commits transaction results, and manages ParaTime state root updates
• Consensus nodes do NOT execute smart contracts — they only finalize the results reported by ParaTimes

This separation means the consensus layer is deliberately simple and easy to audit.

---

ParaTimes: Modular Execution Environments

ParaTimes are independent execution environments that each define their own VM, state, and (optionally) confidentiality model. Multiple ParaTimes can run simultaneously:

Standard (Transparent) ParaTimes:

• Execute smart contracts with full state visibility
• Sapphire (EVM-compatible) and Cipher (WASM-based) are the primary transparent ParaTimes
• Any standard DApp can deploy here

Confidential ParaTimes (using SGX):

• Execution happens inside Intel SGX enclaves — isolated CPU memory regions where even the node operator cannot read the computation inputs/outputs
• The enclave produces a remote attestation certificate proving the code ran inside genuine SGX hardware
• State is encrypted; smart contract inputs and outputs are encrypted in transit and at rest
• Sapphire ParaTime (confidential EVM) allows Solidity contracts to declare variables as confidential

ParaTime-to-Consensus interaction:

• ParaTime nodes execute a batch of transactions and submit the resulting state root and execution receipts to the Consensus Layer
• If a ParaTime uses SGX, the receipts are accompanied by attestation proofs

---

Intel SGX Threat Model

The SGX security model is nuanced:

• Protected from: ParaTime node operators (they cannot read encrypted inputs/outputs or tamper with execution)
• NOT protected from: Physical hardware attacks, Intel itself (Intel controls SGX microcode and attestation root of trust), side-channel attacks (Spectre, Meltdown, cache timing attacks on SGX enclaves)

The whitepaper acknowledges these limitations. Side-channel attacks on SGX are a real risk — multiple academic papers have demonstrated leakage of SGX-protected secrets via timing and power analysis. Oasis mitigates some risks by encrypting enclave I/O and using memory-safe languages, but SGX-based confidentiality is not equivalent to cryptographic security.

---

ROSE Token Economics

• ROSE is the native token for staking, gas fees, and ParaTime compute payment
• Consensus validators earn ROSE rewards for block production
• ParaTime nodes earn ROSE fees for execution
• Initial supply: 10 billion ROSE, with ~2.3 billion allocated to foundation, team, and investors

---

Reality Check

Oasis’s architecture is technically interesting, but confidential compute via SGX has significant security caveats that the whitepaper undersells:

• SGX has been broken repeatedly via side-channel attacks (SGAxe, CrossTalk, PLATYPUS, etc.) by academic researchers. Running a financial protocol in SGX means trusting Intel’s hardware and firmware.
• Enterprise adoption of the confidential data economy has not materialized at scale. The “responsible data economy” narrative attracted little real enterprise usage.
• Developer adoption: The confidential EVM (Sapphire) is a novel offering but requires developers to reason carefully about what state is confidential vs. public, which is complex.
• Network activity: Oasis has not achieved significant DeFi or application activity relative to its market cap.

---

Legacy

Oasis provided an early production implementation of TEE-based confidential blockchain compute and influenced later thinking on privacy-preserving smart contracts. Sapphire’s confidential EVM is a unique offering that no other major EVM chain replicates. The ParaTime separation-of-concerns model influenced other heterogeneous execution architecture designs.

---

Related Terms

• Trusted Execution Environment
• Proof of Stake
• Confidential Computing
• Secret Network Whitepaper

---

Research

• Cheng, D., Lund, G., Yin, M., et al. (2020). The Oasis Network: A Privacy-Enabled Blockchain Platform for Open Finance. Oasis Foundation.

— Primary whitepaper. Section 3 defines the ParaTime model; Section 4 details SGX integration.

• Costan, V., & Devadas, S. (2016). Intel SGX Explained. IACR ePrint 2016/086.

— Comprehensive analysis of SGX architecture and threat model; essential context for understanding Oasis’s confidentiality guarantees.

• Van Bulck, J., et al. (2018). Foreshadow: Extracting the Keys to the Intel SGX Kingdom with Transient Out-of-Order Execution. USENIX Security 2018.

— Demonstrates a practical side-channel attack on SGX; context for the whitepaper’s security limitations section.