dApps are changing the world, providing safe and verifiable operations, enriching people's lives, and enabling developers like you to innovate like never before. As a result, the dAppOcean has been created and grown by the Tradisys team to be an ecosystem for both developers and users. Whether you are a first-time developer or a large team of experienced programmers we are excited that you are creating dApps for the dAppOcean. We want to help you understand our guidelines so that you can be sure that your dApp will get through the review process successfully.
The guiding principle is simple: we want to provide a safe experience for users and a great opportunity for all developers to make their dApps successful. We do this by offering a curated portal where every dApp is reviewed by experts. In addition to this, the portal helps users to discover new dApps.
On the following page, you will find our latest guidelines arranged into four sections: Safety, Performance, Design, and Waves Keeper. The dAppOcean is always changing and improving to keep up with the needs of our customers. Your dApps should adjust accordingly to proceed being listed on the dAppOcean
Please note, that provided Guidelines are constantly reviewed and are subject to change without notice at any time.
1.1. When people launch a dApp on the dAppOcean, they want to be sure that it's safe to do so — that the dApp doesn't contain upsetting or offensive content, won't steal their assets in case of an appropriate dApp usage.
1.2 A dApp is a smart contract-driven app. A dApp has to be smart contract-driven or use smart assets functionality behind the scenes. The smart contract should be tested for all use cases in order to ensure that users funds are secured. The dApp output values must be in line with what was expected and what the user gets.
1.3. Applications that threaten users’ assets security shouldn’t be listed on dAppOcean.
1.4. A dApp cannot ask a user to provide their seeds, private keys or any other sensitive information. It is strictly forbidden.
1.5. A dApp has to use the Waves Keeper to perform the interaction between the user and the smart contract(s). It guarantees transparency in operations.
1.6. A dApps smart contract has to be written on Ride4DApps language. The invocation transaction style for the mutation contract state has proved its existence in terms of security and stability.
1.7. A dApp shouldn't ask a user to connect with the dApp owner in any case. All payment mechanics must be implemented according to the smart account logic using Invoke Script transactions.
1.8. A dApp should provide end-users with a link to the smart contracts that this dApp is using.
2.1. A dApp should have practical uses, any sense or value by its origin.
2.2. Submissions to dAppOcean should be final versions with all necessary metadata and fully functional URLs included; placeholder text and other temporary content should be scrubbed before submission. Make sure your dApp has been tested for bugs and stability before you submit it. Please don't treat the dAppOcean team review process as a software testing service. We will reject incomplete dApp that crash or exhibit obvious technical problems.
2.3. Customers should know what they're getting when they launch your dApp, so make sure your dApp description, screenshots/previews accurately reflect the dApp's core experience and remember to keep them up-to-date with new versions.
2.4. Don't include any hidden or undocumented features in your dApp; your dApp's functionality should be clear to end-users and our review. We work hard to make the dAppOcean a trustworthy ecosystem and expect our dApp developers to follow this; if you're dishonest, we don't want to do business with you and your dApp will be delisted.
2.5. Keep your Backend and Frontend up and running all the time to provide appropriate experience to your users. In case your services are offline, we'll limit access to your dApp.
3.1. We don't limit dApp's authors in terms of design at the moment, coming up with a great design is up to you. However, the core functions have to work and there have to be no bugs in the interface.
3.2. Your web part should be iFrame allowed or set with X-Frame-Options ALLOW-FROM URI option in order to be launched on the dAppOcean.
3.3. A dApp should be mobile optimized, as mobile traffic takes a big part nowadays.
3.4. A dApp should be iframe 16x9 aspect ratio optimized, so it is displayed correctly and without scrolls.
3.5. We encourage dApps to come with an original name and easy-to-remember LOGO.
3.6. If your design plagiarized others, you'll fail the review.
3.7. Screenshots or representative images. Maximum 5 files. Preferred ratio: 2:1. Size: from 600px x 300px to 1200px x 600px.
3.8. Thumbnail. Formats: *png, *jpg. Size: 370px x 250px.
3.9. Logo. 150x150, formats: *png, *jpg.
4.1. Waves Keeper shouldn't start and ask for authentication on a dApp first visit. Prepare your user experience to invoke Keeper when it is necessary, e.g. on clicking the Play button.
4.2. Waves keeper has to be switched to Mainnet. Otherwise, we encourage you to show the appropriate message.
4.3. A notification asking a user to install Waves Keeper should pops-up in case it is missing in your web browser.