How to Build a Confidential Dapp on Oasis Sapphire

Oasis is inviting developers to build confidential dapps on Sapphire, its EVM-compatible network. The practical first move is to confirm the hackathon’s current status and rules, then choose a small application where privacy is necessary to the user experience—not just a feature added for the submission.

An invitation does not by itself confirm that registration is open, when entries close, who can participate, what prizes are offered or how submissions are judged. Check those points with Oasis before investing time or money. Also look for requirements covering team size, required network, source-code visibility, demo format and use of third-party services.

Sapphire supports EVM development, so many familiar Ethereum tools may fit the ordinary development workflow. But using those tools does not automatically give a contract confidential behavior. You need to configure for Sapphire and deliberately use its privacy capabilities, then demonstrate what information is protected and what remains visible.

Treat a hackathon prototype as a learning and demonstration project. Don’t use real funds or sensitive personal information unless the event’s requirements and your security review justify doing so.

Confidential computing is useful when an application needs to process information that users should not have to reveal publicly. Sapphire is designed to support dapps with confidential features while remaining EVM-compatible. The key design question is not simply “Can this run on Sapphire?” but “Which data must be private, from whom, and at what point in the workflow?”

Potential project directions include a game with hidden player choices, a sealed-bid mechanism, a private eligibility check or an application that keeps selected user inputs confidential while producing a verifiable result. These are examples, not promises about hackathon categories or judging criteria. Make sure your idea fits the event’s actual rules.

Before coding, write down:

• The user problem and why public data would make it worse.
• Which inputs and contract state should be confidential.
• What result can safely be shown to other users.
• What still has to happen on a public blockchain or through an external service.

A narrow design is easier to build and explain. For example, a prototype that hides a specific choice but publishes a final outcome can be more convincing than a broad claim that the entire application is private.

Confidentiality is a property of a designed system, not a blanket promise that every detail is hidden. Sapphire’s confidential features can support private processing, but an application may still expose information through public transactions, wallet addresses, timing, user interfaces, logs or services outside the chain.

Map the data path before relying on privacy. Follow information from the user’s device to the wallet, contract and any server, oracle or storage service. At each step, ask who can see the data, whether it must be retained, and what happens if a component is compromised. A contract cannot protect information that an app leaks through an unrelated API or an overly revealing transaction.

Be precise in your demo and documentation. Say what your prototype keeps confidential and what it deliberately reveals. Avoid absolute claims such as “fully private” unless you can support them across the whole system. Explain limitations in plain language so judges and users can understand the actual privacy boundary.

For sensitive use cases, minimise the data you collect in the first place. Don’t put real personal records, passwords, seed phrases or private keys into a hackathon demo. Use synthetic examples and make the prototype’s status clear to anyone testing it.

Start with a minimal EVM project and get a basic contract working before adding confidential behavior. Oasis documentation describes Sapphire as EVM-compatible, so common Ethereum tooling can be useful. However, confidential features require Sapphire-specific configuration; check current Oasis developer instructions for the correct network settings, libraries and testing approach rather than assuming an Ethereum setup is sufficient.

A practical setup sequence is:

1. Create a small contract and run its ordinary tests locally.
2. Configure your development tools for the Sapphire environment you intend to use.
3. Use a test network for deployment and interaction while the project is a prototype.
4. Add one confidential feature, then test it separately from the rest of the app.
5. Record the network, tool versions and steps needed for another developer to reproduce the demo.

Keep credentials and private keys out of source code, screenshots and shared logs. Use a dedicated development wallet, and check the destination network in your wallet before signing. A test deployment is useful only if you can explain which features were tested on Sapphire and which remain mockups or off-chain components.

Build the smallest working example that proves the privacy claim. A clear user flow is more useful than a large feature list: show the input, what is meant to stay confidential, what the contract does with it and what output becomes visible. Make the boundary easy to understand in the interface and in the submission notes.

A build-and-test checklist:

• Define the privacy goal in one sentence and identify the data it covers.
• Implement the ordinary contract path before adding confidential logic.
• Configure the Sapphire-specific features using current Oasis guidance.
• Test expected behavior, invalid inputs and failure cases.
• Check what appears in transaction data, application logs and external services.
• Deploy to the required test environment and capture a reproducible demo.
• Document known limitations, dependencies and any incomplete work.

If your application includes a web front end, test the full flow rather than only calling the contract directly. A privacy-preserving contract does not fix a front end that prints sensitive input to the browser console or sends it to an analytics service. Keep the demo data fictional, and tell testers not to enter real personal information.

Do not assume that an EVM-compatible contract behaves identically across networks. Network configuration, supported features, wallet setup and test conditions matter. Verify each against current Oasis developer guidance and the hackathon requirements. If your app depends on an external API, oracle or storage provider, include that component in your privacy and failure testing.

Check these cases before recording a demo:

• The app connects to the intended Sapphire network, not another EVM chain.
• Wallet prompts and transaction details match the action the user expects.
• Confidential inputs are not accidentally exposed in the interface, logs or external requests.
• The app handles rejected transactions, unavailable services and malformed inputs safely.
• The result shown to users does not reveal more than your design intends.
• Another developer can follow your setup and reproduce the core behavior.

Separate what you have verified from what you have not. If you have only demonstrated a local mock or a testnet flow, say so. A concise, honest account of limitations is stronger than suggesting that a prototype has undergone a production security review when it has not.

Avoid these common mistakes when building for a privacy-focused hackathon:

• Calling any EVM deployment confidential. Show which Sapphire features the app uses and what they protect.
• Making privacy claims without tracing data. Check the wallet, front end, contract, logs and third-party services together.
• Building too much. Prove one privacy-sensitive use case before adding optional features.
• Using real personal or financial data in a demo. Use synthetic data and a development wallet instead.
• Assuming dates, prizes or rules from an invitation headline. Confirm the live deadline, eligibility and submission requirements before committing.
• Treating testnet results as proof of production safety. A test deployment does not replace code review, security testing or a risk assessment.

There may be network transaction costs for deployments or interactions, and the event may have its own eligibility or submission conditions. Don’t assume entry, test assets or production use are free; check the current event rules and network requirements. Keep a small development budget and avoid moving funds to an address unless you have independently checked the network and recipient.

Before you submit, make sure your entry answers three questions: what problem does the dapp solve, what information does it keep confidential, and how can someone verify the demo? Include concise setup instructions, the target Sapphire environment, the user flow, and a clear explanation of what is public or outside the confidential boundary.

Then check the event’s current submission rules. Confirm the deadline and time zone, required repository or demo materials, team and eligibility conditions, and whether any specific testnet or deployment format is required. Don’t assume a previous Oasis event’s rules apply to this one.

If the hackathon is no longer accepting entries, the same work can still be useful as a learning project. Use the current Sapphire documentation to build and test a small confidential dapp, publish an accurate account of its limitations, and avoid describing it as an official hackathon entry. Whether you submit now or continue independently, keep the prototype separate from production systems until it has had appropriate testing and review.