Here are some general guidelines for creating a valid proposal for this third DAO experiment. As a reminder, the topic is:
What dApps, tools, and/or services would you like to see built on top of the HOPR protocol?
Because this is such an open-ended question, it’s impossible to give precise validity requirements. But I can give some advice on what I’m looking for as a moderator.
When you’re happy that your proposal meets these guidelines, adjust the title to include [Proposal] and it will be moderated. You can read more about the different moderation outcomes here
[Note - these guidelines are for proposals to build dApps on top of HOPR, which is the most common proposal type we’re seeing. Proposals for tools and services to support the HOPR protocol have slightly different requirements - please scroll to the bottom to find these.]
dApp Proposals
First, if your proposal is just a few lines, it’s unlikely to be accepted as valid. Remember, the point of the different phases of the DAO is to allow different types of engagement. The Referendum and Vote phases are designed to allow people to jump into the process for the first time. They won’t have the context of everything that went on in the discussion phase. You’ll need to persuade them with your proposal alone.
We’re not looking for essays, or in-depth technical explanations, but at a minimum it needs to be clear:
- What your idea is
- What problem(s) it will address
- Who is the core user group for the dApp
- How your idea uses / benefits the HOPR protocol (NOT just the HOPR project in general)
- What other projects / types of technology will be required for this idea.
- Some details about how it will be built / implemented
These last two points don’t need to be massively technical (although the more technical details you can provide, the more likely the tech team will be impressed, and they have final sign off on all proposals). For the implementation, you should at least have considered basic questions like what platform(s) your dApp will appear on.
The point about other projects is a little more conceptual, but goes something like this: the core of web3 is composability, being able to mix and match different technologies and services to form a unified whole, rather than trying to build a behemoth which handles everything. For particularly far-reaching dApp ideas (e.g., "a HOPR social media network), it’s likely that HOPR would be just one part of the stack needed to make it work. Indicating what else would need to be combined with HOPR to make a dApp work will go a long way to ensuring your proposal meets the tech validity requirements.
If you need to learn more about what problems HOPR can help with, the HOPR Basics series is a good place to start. There are also some simple use case examples on the website.
Our D.E.R.P. tool and related material is also a very clear example of the kind of problems HOPR can solve.
Tools and Services Proposals
Proposals for tools and services are a little different. These are much more likely to be specific and technical than the dApp proposals. We’re looking for tools and services that will make it easier to develop on top of HOPR, visualize and work with the HOPR network, etc.
Here we’d expect to see:
- A clear description of the proposed / service
- An explanation of the problem the proposal solves, or the improvement it provides
- Implementation details, at minimum showing that this is feasible to build
Note that these proposed tools or services still need to be built separately from HOPR. There are many changes to the core protocol we want to make, from UX tweaks to architecture changes. We’re happy to hear about suggestions on these, but they won’t be valid proposals for this topic. Here is an example of a great idea which is unfortunately not valid.
If you need ideas for the kind of thing we’re looking for it might be worth checking out our bounties from ETHDenver and the current bounties in our bounty program (although note that not all of these would pass the requirement above about being built separately from HOPR).