[Proposal] Proposal Submission and Voting Platform


#1

Proposal Submission & Voting System

To enhance the speed at which funds from Zen can be distributed to stakeholders, it is time to create an open source system to allow community members to submit formal proposals that can automatically be voted on and funded.

This is a WIP/RFC proposal. Please comment with ideas, feedback, concerns.

Overview

In accordance with the Zen Whitepaper, 5% of block rewards are to go to DAOs, but any future DAO currently has no way to allocate these funds. I would like to start and maintain the development of a web system to be used by DAOs to create, buy voting tokens for, and vote on proposals. This project will take some inspirations from Dash’s proposal system.

If the Zen Core team decides in the future that the route of multiple DAOs and the complexity of determining the fair split of financing between them too tedious, this system could be used as the foundation for the singular DAO governing body. However, this would require more discussion and possibly core zen protocol changes to allow these allocations to happen automatically as blocks are mined.

With acceptable funds, I would work full-time on this project in an open-source and transparent manner to provide consistent deliverables.

Scope

The proposal system will consist of a modular node.js API server and a React-based web interface.
The primary function of the web interface is to make the currently funded proposals transparent and easy to find while also facilitating the process of creating proposals.

The application will list all current proposals, accepted proposals and declined proposals.The application will provide a form to input proposal name, short description, overview, scope, configure deliverables with payout per deliverable or monthly allotment, and payout address. The deliverables field allows the user to set up specific amount of funding for reaching specific deliverable by said date.

The application will also allow users to sign up to receive notifications when new proposals are submitted or proposals are approaching the deadline.
Users with voting tokens will be able to cast a yes or no vote for open proposals.
Core team members will also be able to place their veto if need be.

The server will act as a proxy to the zen network; interfacing with a local copy of zend and zen-cli to submit the proposals to the network on behalf of the user. The UI would also allow the user to generate a command the user can input to their own zen-cli to submit the proposal.

Deliverables

  1. Research about infrastructure of the system and whether or not zen core protocol changes are required.
  2. UI implementation.
  3. Server implementation.
  4. Further refinements.

Schedule

Since this will be a fairly large ongoing project, narrowing down a concrete time frame is difficult. Ideally, some deliverables could be progressing even if blocked by others. For example, the UI can be created and mocked with fake data even if there are still unknowns about how the network will handle automatic fundings.

Budget

Since there are still lots of unknowns, it is difficult to price out a specific budget or payout scheme. I want to ensure that the Zen team and community are happy with what I accomplish with the given funds, so I must insist that payment be split out in payments in some form—whether that is monthly, per deliverable or a chunk of hours can be negotiated.
In the future, further work on the proposal system should be done through the proposal system itself!

Closing

Zen is a rocket ship waiting to launch. There are many features that still need to be created and a proposal system is absolutely core to attracting capable developers and community members to bring Zen to its next evolution in the form of a self-governing decentralized system.
tem.


#2

Definitely yes! however:

  1. governance is already planned on a protocol-level; team does not want to have control over the funds. whole system eventually should be automated
  1. core cut has been merged with DAO funding; meaning thats 8%. whitepaper/roadmap are still not updated

So I’d personally like to see some simple solution for a current environment, so that there’s transparency for ZEN holders as to where funds are going and a way to be engaged as well. Basically same thing we have today but in a better format with some steps taken against bad agents (maybe confirm ownership of ZEN by specifying your transparent address and validating ownership by sending 0.001 ZEN transaction? and possibly spam protection). As for functionality: different topics (development, marketing, community), track/reputation history, maybe some kind of miniblog where proposer posts updates on the project.
Should be integrated in some manner with a new upcoming website so you have to get in touch with team either on discord or slacks.
And if you’re interested in working on actual protocol-level governance solution that should be a separate project also discussed with team. I believe it’s a next major milestone we’ll attempt after secure nodes release.


#3

governance is already planned on a protocol-level; team does not want to have control over the funds. whole system eventually should be automated
core cut has been merged with DAO funding; meaning thats 8%. whitepaper/roadmap are still not updated

That’s great news! I had hoped it would eventually be something like that, but it looks like I was working off outdated information in the currently available white paper. I’m 100% on-board with a single, blockchain based application.

(maybe confirm ownership of ZEN by specifying your transparent address and validating ownership by sending 0.001 ZEN transaction? and possibly spam protection)

Dash requires 5 DASH to be completely burned in order to submit the proposal—those DASH never get restored regardless of whether the proposal succeeds. A year ago that wasn’t that bad, but now that’s over $1,300. It’s a good barrier to ensure high quality proposals, but I think that severely limits smaller proposals that—in large numbers—can greatly increase Zen’s outreach.

My current thoughts are to require a relative proposal fee that scales with how much zen you are asking for. Say, 10%? So if you are asking for 100 Zen total, it would require 10 Zen to be staked. However, I don’t think it should be burned like in Dash. I see no reason that 10 Zen couldn’t be returned back to the submitter IF the proposal is successfully completed. Otherwise the proposal fee gets burned.

In addition, I’m not keen on Dash’s very long voting and payout time. Keeping with the theme of being flexible and relative, the time proposals are open to vote should be again relative to the amount of Zen being asked for. Maybe scaling from 1 week for small proposals to 1 month for large proposals. The same could go for required number of yes votes; larger proposals would require more votes to be accepted.


#4

@dum any knowledge how it works for PIVX?


#5

Awesome idea. We’re scoping out the protocol-level voting system now and about to start work, but this could be an interim solution that we can roll into the protocol project.

Thanks for taking the time to dig into the project to focus on some big value-added stuff. Let’s talk in more detail.


#6

I’d like to see this get going as soon as possible. It has my support also.


#7

I also believe that this is an excellent idea.


#8

Quick update. I have most of the React UI, router, stores and models completed. I’ve now begun work on the backend api server using Loopback.io for easy persisted models. I’ll be at Dreamforce next week though which will sap a lot of my time. Shooting for a late November launch.


#9

Supported !

Any updates ?