Oasis Network Guide: Privacy Layer 1 and Its Builder Grants

Oasis Network is a layer 1 blockchain designed around privacy. Most public blockchains make every transaction and every contract storage value visible to anyone who runs a node or browses a block explorer. That transparency is useful for verification, but it is a poor fit for payroll, medical data, trading strategies, identity checks or games where hidden information matters.

Oasis tries to solve this by letting applications run code in a way where inputs and state can stay confidential. The network still produces a shared ledger that everyone can verify, so the chain can confirm that the rules were followed without publishing every private detail.

The network is meant for developers who want to build applications that need both confidentiality and on-chain settlement. It is not a general replacement for every chain. A simple token that everyone should be able to inspect may not need confidential computing, and a project that does need privacy should weigh the trust model carefully against other options.

When reading about Oasis, keep three questions in mind: what data is private, who or what has to be trusted to keep it private, and what happens if that trust assumption fails. Those questions matter more than marketing terms like privacy-first or confidential by default.

The core privacy idea on Oasis is the trusted execution environment, usually shortened to TEE. A TEE is a protected area inside a processor where code and data are isolated from the rest of the machine, including the operating system and the node operator. Code running inside the enclave can process sensitive data, and it can produce results and cryptographic proofs that the computation followed the expected program.

For a smart contract, this means certain inputs and state can be handled inside the enclave rather than exposed in plain form on every node. Outside observers see the encrypted or committed data and the outcome the chain accepts, but not the underlying values.

There are important limits. TEE security relies on the hardware manufacturer, the firmware, the attestation process and the software running inside the enclave. Bugs in enclave code, side-channel leaks, or weaknesses in the hardware can weaken guarantees. Researchers have published attacks against TEEs across different vendors over the years, so the honest description is that TEEs raise the cost of snooping rather than making data impossible to recover.

Developers should check the current Oasis documentation for the supported hardware, attestation steps and any known issues, since these details change as the network evolves.

Oasis separates the network into layers. The consensus layer handles core chain functions such as staking, validator coordination, block production and the shared state that ties the system together. Execution happens in separate runtimes that Oasis calls ParaTimes. Each ParaTime can have its own execution model, privacy properties and developer tooling, while still relying on the consensus layer for security and settlement.

This design has practical consequences. A developer who needs a standard public environment can use a different runtime from one that needs confidential computation. Applications can also be designed around the strengths of each runtime rather than forcing every use case into a single model.

The layered approach also means the network has more moving parts than a simple single-chain design. Users and builders should understand which runtime they are using, which token pays fees in that runtime, and which bridge or messaging path, if any, connects it to other networks.

For a quick check, look at the network's current architecture page in the official documentation. Runtime names, supported features and roadmap items can change, so treat any summary, including this one, as a starting point rather than a final specification.

Oasis has used several runtime names over time, and builders should confirm which ones are currently supported before choosing a stack.

Sapphire is the confidential runtime aimed at Ethereum-style development. It supports Solidity-based contracts in an environment where contract state and some computation can remain private. This makes it the usual reference point for teams porting EVM applications that need privacy, such as private voting, sealed-bid auctions or applications that handle sensitive user data.

Emerald is an EVM-compatible runtime with public execution. It suits teams that want Ethereum-like tooling and do not need confidential state. Choosing a public runtime can keep the design simpler, since fewer privacy primitives are involved.

Cipher has been associated with confidential WebAssembly-based execution. WebAssembly support can appeal to developers who work in languages other than Solidity, although the tooling and maturity should be verified in the current docs.

A simple comparison helps:

• Need private contract state and Solidity compatibility: look at Sapphire.
• Need public EVM execution: look at Emerald.
• Need confidential WebAssembly workloads: check Cipher and its current tooling.

Always test the chosen runtime on a testnet before committing to a design.

ROSE is the native token of the Oasis Network. In general terms, a native token on a layer 1 chain is used to pay transaction fees, to stake for network security and to take part in governance decisions. ROSE is used in these roles on Oasis, and some runtime activity is priced in it.

Staking on a proof-of-stake network means delegating tokens to validators that help secure consensus. Stakers typically earn rewards according to network parameters, and they accept that validator performance and slashing rules affect their returns. The exact reward rates, unbonding periods and minimum amounts are parameters that change, so check the current staking guide and wallet interface rather than relying on an older figure.

Governance mechanisms allow token holders to vote on proposals that change network parameters or upgrades. The mechanics and voting thresholds can evolve, so verify them in the official governance documentation.

For any token, confirm the contract or network identifier in the official source before buying, and be wary of copies, impersonators and unsolicited messages offering to double tokens or speed up staking. Legitimate project teams do not ask for seed phrases or private keys.

Oasis has run grant programs to encourage developers to build on the network. Grants are usually non-dilutive funding, meaning the project receives support without giving up equity, but the specific terms depend on the program. Typical grant structures include an upfront amount, milestone payments, a requirement to publish open-source work, and expectations for documentation, testing and community support.

The brief for this guide mentions a 50k grant for dApp builders. Treat that as a headline that may apply to a particular program, round or period, not as a permanent offer. A grant advertised in one period can have different eligibility, size and deadlines later.

To prepare a strong application, most teams do the following:

• Define the problem the application solves and why confidential computing is needed.
• Describe the architecture, runtime choice and planned integrations.
• Outline milestones with clear deliverables and a realistic timeline.
• Name the team members and their relevant experience.
• Explain how the work will be open-sourced or documented.

Reviewers generally look for a clear use case, technical depth and a plan that can be verified. Avoid overpromising, and keep the scope tight enough that you can finish it.

Because grant programs change, the most reliable approach is to check the source directly before planning your budget or timeline. Start with the official Oasis website and its grants or developer pages. Then review the developer documentation, community announcements and any official channels the project lists for program updates.

When you verify a grant, look for these details:

• Whether the program is currently open or closed.
• The eligibility rules, including project stage, location limits and team requirements.
• The size of awards and how they are paid out.
• Milestone and reporting requirements.
• Intellectual property and open-source obligations.
• Application deadlines and the review process.

Also check whether any sponsor, partner or ecosystem fund is involved, and whether it has its own terms. Be careful with links shared in social media replies, direct messages or unfamiliar websites. Scam operators often copy grant announcements and direct applicants to fake forms that collect personal data or wallet credentials.

If you cannot confirm a grant from an official source, do not pay fees or share sensitive information to apply.

Privacy features are valuable, but they come with trade-offs that every builder and user should understand. First, confidentiality depends on the trusted execution environment and the surrounding software. A flaw in enclave code, a compromised machine, a hardware vulnerability or a weak key management process can expose data. Second, a privacy layer does not protect information that a user chooses to reveal, such as posting a wallet address publicly or sharing a transaction hash.

Third, cross-chain movement can reveal information. If assets move between Oasis and another chain, bridge operators, relayers and public explorers on both sides may see parts of the flow. Bridges also carry their own smart contract and operational risks.

For developers, defensive practices include minimizing the data that enters the contract, separating test and production keys, using hardware wallets for significant funds, and getting independent security reviews before launch. Plan for upgrades and emergency response, and document how users can verify the contract addresses they interact with.

For users, keep seed phrases offline, confirm contract addresses from official sources, and avoid signing messages or transactions you do not understand. Revoke token approvals you no longer need using a reputable approval management tool.

If you are a user who wants to try Oasis, begin with small amounts and a testnet where possible. Install a wallet that supports the network, confirm the official network settings from the project's documentation, and back up your recovery phrase offline. Do not share it with anyone, including people who claim to be support staff.

If you are a developer, the sequence below is a practical starting point:

• Read the official overview and architecture documentation.
• Choose a runtime based on whether you need confidential state, EVM compatibility or WebAssembly.
• Set up a local development environment and run the example projects.
• Deploy to a testnet and test edge cases, including failed transactions and upgrade paths.
• Review the current grant terms if you plan to apply for funding.
• Commission an audit before handling real user funds.

It also helps to explore the ecosystem. Data and analytics services can show how much activity a network has, and developer infrastructure such as indexers and oracles can shorten build time. Compare what you find against official project data, because third-party dashboards can lag or count activity differently.

Finally, keep your expectations grounded. Confidential computing is a serious technical area, and good results come from careful design, testing and honest documentation.