How to Launch a dApp on Oasis Network in 2026

Oasis Network is a layer-1 blockchain built around separate execution environments called ParaTimes. Each ParaTime runs its own smart contracts and shares the network's consensus and staking layer, so builders can choose the environment that fits their app instead of forcing every feature onto one chain.

Two ParaTimes matter most for many new projects. Sapphire is an EVM-compatible confidential ParaTime, where selected contract data can be kept private using confidential computing. Emerald is a public EVM-compatible ParaTime with transparent execution, similar to other EVM chains. Both let teams write Solidity and use familiar tools.

The native token is ROSE. It is used to pay transaction fees and for staking, so your deployment wallet and your users will need some ROSE on the network you choose. Prices and fee levels change, so check the official Oasis documentation and a live block explorer instead of relying on a figure written in a guide.

Before committing, decide whether your app needs privacy features such as sealed bids, private balances or hidden strategy logic. If it does not, a public EVM ParaTime is often simpler to audit, index and explain to users.

Choosing a ParaTime is the first real design decision. Write down your must-have features, then check each option against them in the official documentation, since capabilities can change over time.

Question	Sapphire	Emerald
Execution model	Confidential EVM	Public EVM
Contract state visibility	Can be kept private for selected logic	Transparent, as on other EVM chains
Typical fit	Sealed auctions, games, private strategies	Public DeFi, NFTs, consumer apps
Tooling	Solidity and common EVM libraries	Solidity and common EVM libraries

A few checks help avoid rework later:

• Confirm which oracles, bridges, indexers and wallets you need are available on that ParaTime.
• Check how privacy features affect your user experience, including how users prove ownership or view their own data.
• Estimate gas use for your core actions on a testnet, not from assumptions.
• Ask whether your audit firm and your monitoring tools support the chain you pick.

If you later need liquidity or users from other networks, plan for bridging from the start. Treat any bridge as a major risk surface and review its trust assumptions before linking it to your contracts.

A clean setup prevents most early mistakes, especially accidental use of mainnet keys. Follow these steps in order:

1. Create a dedicated developer wallet. Write the seed phrase down offline and never type it into a website or share it with anyone.
2. Use separate wallets for testing, deployment and admin actions. Do not reuse a deployer key for daily browsing.
3. Add the Oasis testnet to your EVM wallet using the chain details published in the official documentation. Copy them carefully and verify them against the docs.
4. Request testnet ROSE from the faucet listed in the docs. Faucets can be rate-limited, so plan your test transactions.
5. Install a current LTS version of Node.js and a framework such as Hardhat or Foundry.
6. Initialise a project, store private keys in a local environment file, and add that file to your ignore list so it is never committed to version control.
7. Send one test transaction from your developer wallet and confirm it appears on the testnet block explorer.

Keep your tooling documentation in your repository. When you return to the project after a break, reinstall dependencies from a lock file so your build matches what you tested.

Your contracts are the foundation of the launch, so testing needs to go beyond a few happy-path examples. Start with small contracts. Reuse widely audited open-source libraries for standard features such as token handling and access control rather than writing your own versions.

A practical test plan includes:

• Unit tests for every public function, including zero amounts, maximum values and invalid addresses.
• Fuzz or property tests that try random inputs and check invariants such as total balances matching deposits.
• Tests for reentrancy, rounding errors, and unexpected token behaviour if you accept outside tokens.
• Fork tests against live contracts you integrate with, if the ParaTime and the target protocol support that workflow.
• Static analysis with common open-source tools, with each warning either fixed or documented.

On a confidential ParaTime, add checks that private data does not leak through events, revert messages or logs. Encryption rules differ from public chains, so test what an outside observer can see.

Before mainnet, commission an independent audit and fix the findings. Publish the audit report and state what was and was not covered. A bug bounty can add ongoing scrutiny after launch. An audit reduces risk but does not guarantee safety, so keep the scope of what you claim modest.

Treat testnet as a rehearsal. Write a deployment script so every step is repeatable, and avoid manual deployments that are hard to reproduce or audit.

1. Deploy all contracts to testnet with the script and save each address to a configuration file under version control.
2. Verify the source code on the block explorer so users can read what they are interacting with.
3. Transfer owner and admin roles from your deployer wallet to a multisignature wallet. Confirm the new owners can act and the old key cannot.
4. Run the full user journey on testnet, from wallet connection through the final withdrawal, using several wallets.
5. Fix anything that breaks, then freeze the code version you intend to ship.
6. Fund a fresh mainnet deployer wallet with only the ROSE needed for deployment. Check fee levels on the day you deploy.
7. Deploy to mainnet, verify the source, and compare each deployed address with the configuration file.
8. Make a small test deposit and withdrawal yourself before opening the app to users.

Publish the contract addresses only after you have checked them against your own records. Scammers often copy launch announcements, so an official list in your documentation helps users spot fakes.

Your frontend is where most users first meet your app, so connection problems can look like product failures. Use standard EVM libraries that work with common wallets, and keep the logic simple.

Key points to handle:

• Read the chain ID from the official documentation and check it before every transaction. Prompt users to switch networks when the wallet is on the wrong one.
• Show the user's ROSE balance and a clear note that transactions need ROSE for fees.
• Translate common revert reasons into plain messages, such as insufficient balance or paused contract, so users know what to do next.
• Display transaction status and link to the block explorer through your own interface, so users can confirm what happened.
• Use a reliable RPC provider and plan a fallback endpoint. A single endpoint outage should not take your app offline.
• Never place private keys, seed phrases or admin credentials in frontend code. Anything in a browser bundle is public.

Test on desktop and mobile wallets, and on the connection methods your users are likely to use. Serve the app over a domain you control, and publish that domain in your official channels so users can confirm they are on the real site.

Security work is ongoing, but a few controls matter most at launch. This checklist is defensive only.

• Access control: give each admin role the fewest permissions needed, and use a multisignature wallet for any action that moves funds or changes parameters.
• Timelocks: delay sensitive changes so users have time to react before they take effect.
• Pause mechanism: include a way to pause new deposits or actions, and document in advance who can trigger it and under what conditions.
• Key storage: keep signing keys on hardware wallets, with backups stored offline and in separate locations.
• Monitoring: set alerts for large transactions, admin calls, unusual balance changes and failed transaction spikes.
• Incident response: write a short plan listing who responds, how users are informed, and how you will communicate with your auditors.
• Disclosure: publish a security contact and a process for reporting vulnerabilities, and be clear about any bounty terms.
• User protection: tell users that official staff will never ask for seed phrases or private keys, and that they should check the domain before connecting a wallet.

Review this checklist again after every contract upgrade. A control that existed at launch can be bypassed by a later change if nobody re-checks it.

A technically sound app still needs users. Plan the launch around one clear user group and one main action you want them to take on day one.

A staged approach often works well:

1. Run a private beta with invited testers on testnet, and collect bug reports in one place.
2. Open a limited mainnet release with deposit caps, so you can observe real behaviour without exposing large sums.
3. Raise the caps only after monitoring shows stable operation over a defined period.
4. Publish plain-language documentation that explains what the app does, its risks and how to exit.

Oasis has run developer programs and hackathons. Public reporting describes the Oasis DevAccelerator Program as providing early access, technical guidance and support to small teams. They do not confirm whether a cohort is open now, so check official Oasis channels for current eligibility, deadlines and terms, and follow those terms exactly.

Be careful with incentive programmes. Avoid promising returns, and do not describe rewards as guaranteed income. If your app touches financial products, review the rules in each market you target before advertising to users there.

Launch is the start of operations, not the end of the project. Set up routine checks from the first day.

Useful tools and habits include:

• Dashboards for transaction counts, failed transactions, gas use and contract balances, reviewed at least daily during the first weeks.
• Event indexing for your frontend. Envio offers indexing and data APIs across many chains, so check whether it covers the chain and contracts you use before relying on it.
• Price feeds. If your app depends on market prices, Pyth Network provides oracle data for blockchain apps. Confirm which feeds and chains are supported, and decide how your app behaves if a feed is stale.
• Public metrics. DefiLlama aggregates total value locked and other data for DeFi protocols. Listing criteria and data methods vary, so read the site's guidance before assuming your protocol will appear.
• Cross-chain messaging. If you plan multichain assets, LayerZero V2 is one messaging option. Each cross-chain design adds trust assumptions, so document them clearly for users.

Plan regular updates to your dependencies, and track announcements from the Oasis team about network upgrades. Keep a changelog so users and auditors can see what changed and when.