Oasis Sapphire Hackathon: How to Build Confidential dApps

Oasis Network announced a hackathon that invited developers to build what it called the first confidential EVM dApp on its Sapphire ParaTime. The sources available for this guide describe it as a September event, and they frame the goal around privacy-preserving applications that run on an Ethereum-compatible environment.

Hackathons like this one are usually a way for a blockchain team to attract builders to a new capability and to see what they create. The organisers typically set a theme, a submission process, a judging method and sometimes prizes or grants. In this case the theme was confidentiality, meaning applications where data and logic stay private while the contract still executes on a public network.

Because the event was tied to a specific season, its exact dates, prize pool and winners are the kind of details that change or become historical. This guide focuses on the lasting part of the story: what Sapphire is, why confidentiality is hard on public chains, what the hackathon asked developers to explore, and how anyone can start building a similar app now. For current event rules and any results, check the official Oasis Network channels directly.

Sapphire is a ParaTime, which means an execution environment that runs alongside the main Oasis Network consensus layer. The sources describe it as a confidential EVM ParaTime, so it accepts the same general smart contract model that Ethereum developers already use. Contracts are written for an EVM-style environment, which lowers the barrier for teams that already know Solidity-style development.

The difference is what happens to the data. On a typical public EVM chain, every transaction input and every storage value is visible to anyone who reads the chain. Sapphire is designed so that contract state and inputs can remain private. The sources say that sensitive logic and state can stay encrypted even from node operators, which is the main point of the platform.

Sapphire also supports offchain verification mechanisms, as noted in ecosystem summaries. In practice this means some computation can be verified without publishing every detail onchain. Developers should read the current Oasis documentation to understand exactly which features are supported on each network, because runtime capabilities can change between releases.

Confidential computation on Sapphire relies on trusted execution environments. The sources describe Sapphire as running on Intel SGX and TDX based enclaves. An enclave is a protected area of a processor where code and data are isolated from the rest of the machine, including the operating system and the node operator. Contract execution happens inside that protected area, and the results are returned in a way that keeps sensitive values hidden.

For a developer, the practical model is simple to state. Inputs are encrypted before they reach the contract. The contract reads and writes its state in protected form. Outputs that must be public are revealed deliberately, and everything else stays private. The contract code itself is still public, so the logic must be designed with that in mind.

The model is not magic. Privacy depends on the hardware, on how keys are managed and on whether the contract leaks information through its outputs, timing or gas usage. A confidential app can still reveal too much if its design is careless. Treat the enclave as one layer in a larger security model rather than a guarantee on its own.

The hackathon framed its challenge around confidential dApps, meaning applications where privacy is a core feature rather than an add-on. The sources mention the aim of building the first confidential EVM dApp, which suggests organisers wanted ambitious projects that could not be built as easily on fully transparent chains.

Useful ideas in this category include applications where a public ledger would expose too much. Examples include sealed-bid auctions, where bids should stay hidden until a reveal phase; private voting, where the tally is public but individual choices are not; games with hidden information; and treasury or payroll logic where amounts should not be broadcast to competitors. Each of these depends on keeping state or inputs private while still producing a verifiable public result.

A good hackathon entry explains the threat model clearly. It states what data must stay private, who the attacker is, what is revealed deliberately and what the user has to trust. Judges and users tend to respond well to projects that solve a real privacy need rather than adding encryption as a label.

Developers are the most obvious audience. Teams already comfortable with EVM smart contract development can explore Sapphire without learning an entirely new language or virtual machine, although they still need to learn the confidentiality model and its limits. Those who build games, auctions, identity tools or enterprise workflows may find the privacy properties especially relevant.

Product teams and businesses that handle sensitive data onchain may also want to study the platform. Compensation schedules, supplier terms, customer balances and internal approval flows are examples of information that companies often do not want to publish. A confidential runtime offers one way to keep such logic onchain while limiting exposure.

Users who care about privacy may benefit indirectly if more applications adopt confidential designs. Still, a private app is not automatically a trustworthy app. Users should check who built it, whether the contracts have been audited, what the enclave assumptions are, and whether the team is transparent about its limits.

Privacy features bring their own security questions, and the hackathon is a good reminder that they need to be tested as carefully as any other smart contract. The sources describe trusted hardware as the foundation, and hardware assumptions can fail. Developers should understand which parts of the system they must trust and design their applications so that a failure in one layer does not expose everything.

Several practical steps reduce risk. Keep sensitive data out of public events and logs unless it is meant to be public. Avoid revealing secrets through revert messages, timing differences or unusual gas patterns. Limit the amount of value held by any single contract during early testing. Plan for upgrades and emergency pauses, while documenting who controls them.

Independent audits remain important, and an audit should specifically cover the confidentiality design, not only ordinary contract bugs. Bug bounties and staged launches also help. Users should avoid depositing funds into any new confidential app until its design, its audit history and its operator are clear.

Getting started is mostly a matter of following the official path and building something small first. Begin with the Oasis documentation, which includes a quickstart tutorial for building and deploying a dApp that requires confidentiality. The tutorial is the best source for current network details, tooling versions and configuration.

A sensible sequence looks like this:

1. Read the documentation on Sapphire's confidentiality model and its supported features.
2. Set up a development environment with EVM tooling that the docs confirm is compatible.
3. Deploy a small confidential contract to a test network and interact with it using test tokens.
4. Write tests that check both the public outputs and the private state, including failure cases.
5. Review the design with peers and, before any real value is involved, commission an independent security review.

When the contract works in testing, document the threat model, the data flows and the known limits. Those notes help users, auditors and future contributors, and they make it easier to explain the project during a hackathon review or a funding conversation.

Because the hackathon was tied to a specific season, readers should separate the event from the platform. The event may have ended, and any prizes, winners or submission windows are historical. The platform, however, continues to be documented, updated and used by developers. Focus on the current technical material and treat event pages as dated records.

To check the current picture, start with the official Oasis Network website, its documentation and its announcement channels. Look for the date of each post, the network it refers to and whether it describes mainnet or testnet features. Community discussion can be useful for context, but it is not a reliable source for final rules or results.

Be cautious with third-party claims about token prices, grant sizes or partnerships. These change quickly and are often inaccurate in summaries. If a figure matters for a decision, verify it on an official source and on a data provider that shows its methodology and timestamp.

A useful design process for a confidential dApp starts with the data, not the code. List every piece of information the app handles and mark which parts must be private, which must be public and which can be verified without being shown. This step often reveals that only a small part of the logic needs confidentiality, which keeps the attack surface smaller.

Next, define the outputs. Confidential apps usually work because they reveal only the results the users need. An auction might reveal the winner and price but not the losing bids. A vote might reveal the total but not individual choices. Make sure these reveal rules are written down and tested.

Finally, plan the operational side. Decide who can upgrade the contract, how emergencies are handled, how users are informed of changes and what happens if the underlying trusted hardware assumptions change. Clear documentation on these points builds trust, and it gives reviewers something concrete to examine.