![A Proposed Referendum Tool for the EOS Mainnet - eosio.forum.jpg](https://cdn.steemitimages.com/DQmZkwECdLaxDDwTgM2U2oYqsxfzEm2jRv6KoyB8Eha3yKs/A%20Proposed%20Referendum%20Tool%20for%20the%20EOS%20Mainnet%20-%20eosio.forum.jpg) EOS Canada wanted to take a moment to give an update about what has been worked on for the referendum contract for EOS, how we got here, and some of the next steps. This has been a collaborative effort, with many Block Producer teams working hand-in-hand.

How We Got Here

Dan Larimer had proposed having an on-chain forum so that we could have token holders post something on-chain which could then be sniffed out and amalgamated into one place to tally the results. Dan whipped up a preliminary contract, leaving it to the community to build it out as we saw fit.

What Has Been Worked On

Alexandre from EOS Canada took Dan’s code and started to tweak eosio.forum. Michael from EOS 42 started to code a smart contract to have everything setup and tallied on-chain. It was realized that this would have been a much more involved process with an unknown timeline to completion, and would not provide the flexibility for changes and iterations as we progress and learn more about the parameters that we would need to modify once it is in use. From his learnings, Michael helped to lead design discussions to move towards a usable product.

Daniel from EOS Nation has been helping to lead and organize the team, acting as the project manager for those working on the referendum contract. From the EOS Nation team, Denis has also been helping out, working on building a ‘listener’. Further down, 'listeners' will be explained. (Here is a link to read Daniel's writeup on where this project currently sits, as well as the roadmap)

Aaron from Greymass has been very involved in ensuring that we're setting up with a proper JSON schema to ensure smooth integration by wallets and portals who wish to integrate functionality. As well, Nathan from GenerEOS has been helping to ensure that integration and usability is being kept in mind to help with adoption.

Some tools that are already setting up to integrate the usage of `eosio.forum` are GenerEOS’s toolkit and Greymass has said they would like to integrate voting through their wallet for referendum questions as soon as it is ready. MyEOSKit by EOS Asia is already set up to flag propositions, as well as associated messages to them. EOS Tribe is also very involved, and will be working at creating the UI for EOSportal.io . `eosc` by EOS Canada also has forum posting and voting integrated.

To see a user-generated use-case of `eosio.forum` at work, you can check out Novusphere, a Reddit-style forum.

Next Steps

The main next tasks are to build the ‘listeners’ that will pull the information from the chain, and run the tallying. These will be open source, and the security and decentralization will come through having many independent users/groups run the tallying on their own for cross verification.

We need to agree to a standard JSON schema, so that anyone who wants to pull data from this tool, will have a single and known format to read from. Adoption and usability will be paramount, as we want to see as much involvement from the community as we can get. So easy integration through standard formats will keep everything simple and scalable.

How It Works

Anyone can use the `forum` to push out a proposition or vote, however, it will only end up being the ones that we decide - as a community - to listen to that will matter. An analogy would be that there are currently thousands of transactions per day that happen over EOS. But now we’re trying to listen to only the transactions that go towards a specific account, and then within that account, that include certain key pieces of information.

The transaction will include: (note that we still need to finalize this structure, but this will give you a good idea)

proposer: [account]
proposal_name: [thequestion]
title: "EOSIO Referendum: [WhatWeWantToVoteOn]" # An English string, to be shown in UIs
proposal_json: '{
 "type": "bp-proposal-v1",
 "content": "TallyMethod, VotingPeriod, DescriptionOfWhatWeAreVotingOn, WhatTheDifferentVotePossibilitiesWillSpecificallyMean, TheActualQuestion”}'

The votes that are sent back would look like this:

voter: [myaccount]
proposer: [proposersaccount]
proposal_name: [thequestion]
proposal_hash: acbdef112387abcefe123817238716acbdef12378912739812739acbd # sha256 of "title + proposal_json" of proposal
vote: [votevalue]
vote_json: ''

How Does A Proposal Become A Referendum

For a question to be put out by the `eosio` account, it will need to be signed using the `eosio.msig` contract. Any user can submit a question under their account, but most wallets will only display by default the`eosio` account, which holds questions already signed by 15 of 21 BPs.

Who Decides What Questions Are Asked

For example, the Everipedia account could poll their community using this contract, and then the 'listeners' could retrieve proposal and voting information relating to that account. The global polls or referendums will be held by the `eosio` account, signed by 15/21 BPs. User interfaces will be able to view the referendum proposals of any such account, making this setup very broad and general purpose.

Off-chain Tally (The ‘Listeners’)

In order to create a super efficient, and easily iterable solution, it was decided to create off-chain tallying of the votes. This would not require RAM to run the tally, and is a great example of how to separate what you need to do on-chain and off-chain.

We would have the tools tally the votes every X amount of blocks and then update their displayed results which they can share in many ways, and do cross-verification against one another. Once the voting thresholds have been surpassed, and everyone agrees on the tally results, we can take action. It also means that different referendums can have different tally rules, like taking only votes that have previously interacted with a given contract. An example of this would be that the proposal itself could define different parameters like voting participation thresholds, or even to only accept votes from accounts that have already interacted with a certain contract. To tie in our previous example of Everipedia using this contract, they could decide to only listen to votes by users who have interacted with the Everipedia token contract. This would allow them to ensure they are listening to their engaged and active community members, if that was what they wanted.

For now though, we feel like this is the best way to get the referendum process bootstrapped, and then use it to make more official decisions about how to run it going forward.