Oasis (ROSE)

Oasis (ROSE): A Layer 1 Built Around Confidential Compute

Oasis separates consensus from application execution and uses specialized runtimes to support private smart contracts, verifiable off-chain applications, and conventional blockchain services. ROSE pays for network activity, supports staking and governance, and connects the consensus layer with ParaTimes such as Sapphire.

A two-layer network rather than a single execution chain

Oasis is structured around a proof-of-stake consensus layer and a separate ParaTime layer. The consensus layer handles validator coordination, staking, governance, registry functions, and commitments from application runtimes. ParaTimes provide parallel execution environments, so different applications can process workloads without every transaction sharing one execution environment. This design is intended to separate network security from application-specific computation and allow runtimes to use different virtual machines, committee structures, and permission models.

The architecture creates a practical distinction for users: an account and balance on the consensus layer are not automatically the same as an account and balance inside a ParaTime. Moving ROSE between them is handled through deposits and withdrawals, while transfers generally occur either within the consensus layer or within the same ParaTime. This separation can support specialized applications, but it also adds operational complexity compared with a single-chain account model.

Sapphire supplies confidential EVM execution

Sapphire is Oasis’s official confidential ParaTime for Ethereum-compatible smart contracts. Its documented features include confidential contract state, end-to-end encryption, confidential randomness, cross-chain connectivity, and one-block finality. Developers can adapt familiar EVM tooling while adding privacy-oriented behavior to applications such as decentralized finance, games, non-fungible tokens, and other contracts that may benefit from hiding transaction inputs or contract state.

The privacy model relies on trusted execution environments rather than treating privacy as a property of ordinary transparent blockchain execution. Oasis documentation describes encrypted data entering a secure enclave, being processed there, and being encrypted before leaving. That approach can reduce exposure to node operators, but it makes hardware support, enclave configuration, attestation, key management, and implementation quality material dependencies. Privacy should therefore be assessed as a system of components rather than assumed from the presence of the Sapphire name alone.

ROFL extends the system beyond smart contracts

Runtime Off-Chain Logic, or ROFL, is designed for applications that need private or computationally intensive work outside ordinary blockchain execution. ROFL applications run on Oasis nodes inside trusted execution environments and are managed through Sapphire. The documented framework includes container-style deployment, encrypted application secrets, key derivation inside the trusted environment, update history, application billing, and a mechanism for Sapphire contracts to verify the origin of ROFL transactions.

This makes ROFL relevant to use cases such as oracles, automated agents, private bots, AI-related workloads, and interactive services. However, the result is not purely on-chain computation. Users and developers still depend on the ROFL node pool, the trusted hardware stack, application deployment controls, and the quality of external data sources. The system can make execution more auditable and private, but it does not remove every trust or availability assumption from an application.

What ROSE does

ROSE is the native token of the Oasis mainnet. Official documentation assigns it several network roles: paying transaction fees, participating in proof-of-stake validation and delegation, voting on governance proposals, distributing staking rewards, and supporting application-specific uses. Staking weight influences validator participation and voting power, while delegators can assign tokens to validators without operating infrastructure themselves.

The token also reflects Oasis’s multi-layer design. Consensus-layer ROSE uses Oasis-style addresses and signatures, while EVM-compatible ParaTimes such as Sapphire use EVM-compatible account formats. Users may need to deposit or withdraw assets between layers, and wrapped representations can be used on external networks. That means the token’s practical usability depends not only on its base-chain functions but also on wallets, bridges, exchange withdrawal support, ParaTime interfaces, and accurate network selection.

Supply, staking, and governance control

The project documents a fixed maximum supply of 10 billion ROSE and describes staking rewards as a long-term distribution mechanism. Its published allocation materials also warn that distribution percentages and logistics may change, so the historical allocation page should not be treated as a complete current ownership table. Delegated tokens are subject to a debonding period, and validator misconduct can result in slashing under the network’s rules.

Oasis describes governance as a hybrid process combining community discussion, technical proposals, off-chain coordination, and stake-weighted voting by network participants. Major changes can be proposed through Architectural Decision Records, reviewed by the community, voted on, and implemented through node upgrades. The governance documentation also says project committers retain final authority over what is accepted into the project, while the Foundation helps guide long-term development. This creates a formal route for upgrades, but it also leaves meaningful influence with technical maintainers, node operators, stakers, and Foundation-led coordination.

Practical limitations to investigate

Oasis’s main proposition depends on several layers working together: validator consensus, ParaTime execution, confidential-computing hardware, key management, bridges, wallets, and developer tooling. The official Oasis Core repository states that the software remains in active development and that the code has not yet been fully audited. That disclosure does not establish a specific vulnerability, but it means users should not interpret the project’s privacy or verification features as a blanket security guarantee.

The available official materials explain the intended architecture and supported mechanisms more clearly than they establish independent demand or durable application usage. Prospective users should separately verify current validator distribution, ParaTime activity, bridge security, enclave dependencies, governance participation, and the extent to which applications rely on centralized services or external data. These questions are especially relevant because privacy can increase technical complexity and because cross-layer movement can create additional failure points.

Key takeaways

• Oasis separates consensus from application execution through parallel ParaTimes.
• Sapphire provides EVM-compatible confidential smart contracts using trusted execution environments.
• ROFL adds verifiable, private off-chain applications managed through Sapphire.
• ROSE is used for fees, staking, delegation, governance voting, rewards, and application functions.
• Using ROSE across consensus and ParaTime layers requires compatible wallets, account formats, and transfer procedures.
• The system’s privacy and security properties depend on hardware, key management, bridges, software, and governance as well as the base protocol.

Risks and open questions

• Oasis Core documentation states that the code remains in active development and has not yet been fully audited.
• Trusted execution environments introduce hardware, firmware, attestation, and key-management dependencies that can affect confidentiality and availability.
• Moving assets between the consensus layer, ParaTimes, and external networks adds operational and bridge-related failure points.
• Governance is stake-weighted and the documented process gives substantial coordinating and acceptance authority to node operators, project committers, and the Oasis Protocol Foundation.
• The published token distribution materials describe historical allocations and warn that percentages and logistics may change; they should not be treated as a complete current ownership picture.
• Official materials provide limited independent evidence in this review about sustained user adoption, application revenue, or broad real-world demand.