Proposed Referendum Contract Process

After much thought on the issues we face in regards to the referendum contract and collaborating with many of the top minds working on this, I would like to bring forth a proposal for review that combines all of the best ideas presented so far.

Process for submitting a referendum proposal:

  • On-chain & Public Discussion - Until the EOS Forum is ready and all communications can be on-chain, anyone seeking to submit a referendum must first submit their full proposal for discussion here in the EOS Go forums, and provide a full copy of the text on-chain at You must include the cryptographic hash in your actual post as well, so it is recommended you submit it to the chain BEFORE posting it here for discussion.

  • Public Support & Validity of Referendum - To combat frivolous referendums from clogging up the system, your proposal must meet a certain number of comments and approval from key community members and have a clear path to execution. Ideas are great, but vetted, principled arguments that meet real world standards of public consensus are still relevant, even here in the land of EOS. An exact number of comments and what metrics meet this standard are up for debate.

  • Process For Submitting Referendum - Once there is ample support for your referendum, you must submit your proposal officially to a Google form in the short term (or relevant EOS public forum once that is set up) to be reviewed by the EMLG group (or perhaps several governing bodies tasked with submitting your referendum to ensure the system is not flooded with spam). The person submitting the proposal will be asked for their cryptographic hash and proof of the data points I outlined, as well as relevant contact information and some level of verification that they are in fact a real person. If that should be decided to beI suggest we appoint at least three competing interest groups who are appointed to do this at different vantage points in the ecosystem to combat the potential for favoritism and censorship of unpopular ideas with incumbent power structures taking shape in the ecosystem now.

  • Referendum Cost & Support - A fee should be associated with proposing a referendum of 20-40 EOS. This serves two purposes: if you cannot collect that much in public support financially, your referendum may not be worth reviewing in the first place. The other part is the fees paid into the system could be put toward RAM staking to run the actual Referendum forum / initiative. This both mitigates spam and provides funding to host the contract and referendums ongoing.

I believe this is a good start, please let me know your thoughts. We have many challenges ahead to make this work and we need the best and brightest from our community to make this a well thought out process end to end.

In the spirit of this process, I have registered this proposal on-chain here...

tx id: 119817b5d27ea44df62662a1c814f1ee7d7f703c86a8348f0628b6eaab99f2b7

UPDATE: Please see the latest thinking around the referendum proposal guidelines here -


  • Anyone must be able to post a suggestion for referendum....and if it gathers enough community support within a certain amount of time, put to the community for a vote. Proxies could play an important role here. A small cost should discourage spam.

  • Great proposal Steve, we need now to start the discussion around the putting numbers on 'Process For Submitting Referendum' We need a way to measure support that is fair and transparent

  • edited July 2018

    In MVP mode - Can I suggest the account proposing requires a minimum 1,000 staked tokens. Given it is easy to delegate stake this creates a higher bar, but something easily achievable with a little community support.
    We can report number of accounts that have provided stake and number of tokens as a reasonable indicator.

  • Thank Steve, good proposal

  • There are many good points made here, Steve. Food for thought that needs to be considered and I think, adopted. Brett, EOS the World.

  • Good points Steve. Not sure about the "approval from key members". It may be more helpful to use % of "support" indication measure from token holders. Maybe we start with 15% support criteria during this process. Fee is good measure to prevent most spammy request and junk. My 2 cents.

  • Pushing the main proposal on chain is a good start, and filtering for quality is also necessary. Thank you for starting the conversation Steve.

    We support an accessible, intuitive referendum process with a low barrier to entry for serious proposals.

  • To prevent too much centralisation it is crucially important that anyone can start a considered referendum (not only EMLG BPs). This process is an excellent start to assure referendum proposals can be submitted by anyone whilst preventing that too many low quality proposals clog the system. Many thank Steve !!! This has the full support of DutchEOS

  • I like the proposal. The top21 are there to produce blocks, not to decide where the chain is going to. Everybody should be able to propose a referendum not only the EMLG group.

  • 'approval from key community members' concerns me. Whilst I agree that we don't want to see frivolous or ridiculous proposals presented, I don't think we should restrict who can or cannot make proposals, this is a community blockchain after all.
    Simply proving you are an EOS token holder and that you have a well thought out plan and you have a proportion of community support should be enough.
    We need a structure, so I like a lot of what is presented, but most of all we need to make sure this is an open and transparent process without any 'Gatekeepers' deciding what can and can't go into the referendum.

  • How will all the sentences which have words like "must" and "should" be enforced? If it's done by a human instead of smart contract, how will that practically work and isn't that a concern for centralization of power? I'd much prefer everything being enforced on chain through code with competing mechanisms the community can review and choose from. We can then leave it up to competing interfaces to display the blockchain data accurately to users to obtain their votes. If there is obvious spam, then those who run the interfaces for viewing the referendums would use their best judgement to hide/display the spam (I'd imagine BPs would be incentivized to do this as a value add to the community). With competing interfaces, if different systems had different criteria, then we'd have a nice it of competition (ideally the interface would have a "show all" view as well). Spam can't fundamentally be stopped on EOS outside of someone's staked bandwidth and CPU. I don't think we can or should try to put something artificial beyond that.

    Discussions can happen anywhere. What matters is the on chain vote.

  • I wrote my last post in the EOSGO forms. How can I upload that for verification like you are asking me to do?

    I wrote stright to the fourm so I do not have a document on word or anything. Must I copy paste the text to a document or just straight paste to the As this is intended to supplement Dans new and improved constitution, must I include that text as well as my additions? Also, I would like some community feedback as to which definitions to include in the gloss, so it's not exactly a final draft. Must I wait for a final draft?

  • @urius said:
    Good points Steve. Not sure about the "approval from key members". It may be more helpful to use % of "support" indication measure from token holders. Maybe we start with 15% support criteria during this process. Fee is good measure to prevent most spammy request and junk. My 2 cents.

    Yes, "key members" sounds very arbitrary, and we should stick to code and good old math for this process.

  • I'm skeptical about the proposed way to combat spam as well. I don't know if your proposed fee would cover all RAM needs for referendum, but I think it should. If it's too big for someone to propose it, they should find more supporters who could help fund it. This should reduce spam. Plus there are plenty of ways for frontends to filter referendums: by number of votes they already received, by support from certain accounts... Ideally everything should be customizable for the user of course.

  • Relevant. I like these suggestions.

  • Hello friends, check out the latest on the direction we've been taking with the Referendum System:

    Would love to hear this community's thoughts.

  • Update:

    Check out the latest on the actual referendum proposal guidelines and process being developed...

Sign In or Register to comment.