The EOS Referendum Working Group is pleased to invite the EOS community to join us in testing the beta release of our referendum system.
The group has been hard at work on closing outstanding showstopper issues. While there’s still work to be done to get the tool ready for mission-critical referendum proposals, we’ve reached a point where we have a working product that’s ready to be put through its paces by the broader community.During the beta period, we’ll be focused on testing and refining. We’ll be monitoring the results of our tally tool and comparing them with snapshots to ensure consistent accuracy. And we’ll continue to chip away at smaller open issues in both our tally and UI. In the meantime, we’ll be soliciting feedback from the community to learn how we can improve the tool and iron out any issues we might have missed on our own. Critical issues will be prioritized to be closed before our full launch, less serious issues will go onto our backlog for future iterations.
Why does EOS need a referendum system?
EOS is a community-governed blockchain. Stakeholders launched it in June using the weight of their tokens to elect 21 Block Producers (BPs) to operate the network. Those BPs are the organizations that run the infrastructure and hold the keys to implement changes to the hard-coded rules that make it all work so magically. They’re held accountable through continuous voting and can be replaced by new organizations at any time.
As the network continues to evolve, BPs will be responsible for implementing the changes that make that evolution possible. And that might involve making some tough decisions with severe implications. Beyond the BP elections, there’s currently no sure way to gauge token holder appetite for change. While the mechanism doesn’t exist, article XI of the Constitution makes it clear: token holders have the right to vote for changes to the network directly through a referendum. And that’s where the referendum system comes in.
What it is
We’re providing the community with a tool to enable EOS token holders to vote on proposals with their staked tokens. The referendum system is made up of a forum smart contract for submitting proposals and casting votes, a tally system for counting the EOS staked towards each ballot option, a voting portal UI with support documentation to facilitate easy voting, and support for integration with wallets and alternative UIs so token holders can participate in the interface they’re most comfortable with. It’s all open source and available on GitHub.
What it’s not
We haven’t developed a process for creating or filtering proposals, nor have we defined any specific rules for how referenda should be ratified. We’ll provide suggested best practices, but we can’t control how the tool will be used, nor do we have the authority to impose our own rules outside of what’s outlined in article XI of the EOS Constitution. It’s up to the community to craft proposals and vote on them; and signatures from at least 15/21 top BPs to ratify and implement passed proposals. Thanks to the beauty of DPOS, a separate group has formed to develop proposal best practices of their own. You can find the Ballot Craft group on telegram.
Feature summary:
- eosio.forum (by EOS Canada)
- EOSvotes tally (by EOS Nation)
- EOSvotes portal (by EOS Tribe and GenerEOS)
- Support for alternative UIs (influenced by Greymass and EOS42)
- EOSvotes.io
- Greymass
- Bloks.io
- EOStoolkit.io
- myEOSkit.com
- eosauthority.com/polls
- eos-forum.org
How it works (in a nutshell)
- Proposals submitted through the eosio.forum smart contract can be displayed and voted on in any UI that chooses to display them
- Token holders and proxies can vote for proposals from their prefered UI (see supported UIs above)
- The weight of a vote is determined by the amount of EOS staked towards CPU or NET at the time the vote is being counted
- The vote is counted continuously until a designated threshold is met or until the proposal expires
- It’s up to a vote of 15/21 top BPs to confirm if a threshold has been met and to implement the will of token holders
Known issues to resolve before full release:
- 10 minute delay for votes to reflect in the tally and UI
- EOSvotes.io is available only in English
- No alternative tally exists currently
How you can help
Let’s see if we can break it. We invite all token holders to play around with our beta release by voting for some of the mock proposals that have already been submitted. You’re also welcome to try submitting some proposals of your own. But we don’t recommend attempting to propose anything of material consequence until it’s been put through its paces. In the meantime, please share your feedback in our telegram channel.
Background
This is the fourth in a series of updates on the EOS Referendum System. Catch up on the others below:
Expected Voting Behaviours
We wanted to outline some possible voting scenarios and what the expected outcomes should be, so that it is clear what a user should expect based on their voting status.
Clarifications:
- Vote will be used to describe voting using the referendum contract, not a vote for a Block Producer
- By default, the value 0 should be used for a negative vote (no) and 1 should be used for a positive vote (yes)
- Total weight staked is the sum of CPU and Net bandwidth that a user has staked towards themselves or towards another account (but that they still are in control of)
- When a user has bandwidth staked towards their account by another account, they are not in control of that voting stake
- The change to the tally amount may take up to 10 minutes to register through the current tally mechanism
- Votes (and removal of votes) are immediately registered on chain and are effective immediately
- Votes are not subject to the relative-strength decay seen on Block Producer voting
- To abstain from a vote, a user will need to utilize the command line, as there is no UI (yet) that allows this kind of vote
- An abstention will be necessary if a user wants to proxy their BP vote but not have any vote registered on a particular proposal
- For the purpose of this document, we will only look at how the “staked” field of the voting JSON is affected, as that is a sum of the “accounts” and “proxies” fields (see example output here: https://s3.amazonaws.com/api.eosvotes.io/eosvotes/tallies/24697186.json)
- For the purpose of this document, we will only outline 2-option votes
| Scenario ID | Scenario Description | Expected Result |
| 001 |
UserA does not cast a vote |
No change to vote tally |
| 002 | UserA casts a vote of No | Vote tally for 0 would increase by the total weight staked by UserA |
| 003 | UserA casts a vote of Yes | Vote tally for 1 would increase by the total weight staked by UserA |
| 004 | UserA, who had previously voted Yes, has voted again for No |
Vote tally for 1 will decrease by the total weight staked by UserA, while vote tally for 0 will increase by that same amount |
| 005 | UserA, who had previously voted No, has voted again for Yes | Vote tally for 0 will decrease by the total weight staked by UserA, while vote tally for 1 will increase by that same amount |
| 006 | UserA, who has voted for Yes previously, has voted again for Yes |
No change to the vote tallies |
| 007 |
UserA, who has voted for No previously, has voted again for No |
No change to the vote tallies |
| 008 |
UserA, who has a vote already registered, increases their stake |
The vote tally towards which they are currently voting will increase by the newly staked amount |
| 009 |
UserA, who has a vote already registered, decrease their stake |
The vote tally towards which they are currently voting will decrease by the unstaked amount |
| 010 | UserA, who has a vote already registered, removes their vote |
The vote tally to which they were staking will decrease by the amount UserA had staked |
| 011 |
ProxyX, a registered proxy, casts a vote of Yes |
The vote tally for 1 will increase by the total amount staked towards ProxyX, plus the stake amount that ProxyX has on their own account |
| 012 |
ProxyX, a registered proxy, casts a vote of No |
The vote tally for 0 will increase by the total amount staked towards ProxyX, plus the stake amount that ProxyX has on their own account |
| 013 | ProxyX, a registered proxy, casts a vote of Yes. Then, UserB who has ProxyX as their registered proxy, casts of Yes |
The vote tally for 1 will be unaffected as UserB’s weight has already been tallied when ProxyX originally voted |
| 014 |
ProxyX, a registered proxy, casts a vote of No. Then, UserB who has ProxyX as their registered proxy, casts of No |
The vote tally for 0 will be unaffected as UserB’s weight has already been tallied when ProxyX originally voted |
| 015 | ProxyX, a registered proxy, casts a vote of Yes. Then, UserB who has ProxyX as their registered proxy, casts of No |
The vote tally for 1 will decrease by the staked weight of UserB, while the vote tally for 0 will increase by the same amount |
| 016 |
ProxyX, a registered proxy, casts a vote of No. Then, UserB who has ProxyX as their registered proxy, casts of Yes |
The vote tally for 0 will decrease by the staked weight of UserB, while the vote tally for 1 will increase by the same amount |
| 017 |
ProxyX, a registered proxy, casts a vote of Yes. Then, UserB who has ProxyX as their registered proxy, removes their vote |
The vote tally will be unaffected |
| 018 |
ProxyX, a registered proxy, casts a vote of No. Then, UserB who has ProxyX as their registered proxy, removes their vote |
The vote tally will be unaffected |
| 019 | ProxyX, a registered proxy, casts a vote of Yes. Then, UserB who has ProxyX as their registered proxy, changes their vote to “2” (or any other non-Yes or non-No value) |
This is currently only available through the command line. This is a way to ‘abstain’ from a vote. UserB’s weight would be removed from 1, and placed on a new tally which only counts towards voter participation |
| 020 |
ProxyX, a registered proxy, casts a vote of No. Then, UserB who has ProxyX as their registered proxy, changes their vote to “2” (or any other non-Yes or non-No value) |
This is currently only available through the command line. This is a way to ‘abstain’ from a vote. UserB’s weight would be removed from 0, and placed on a new tally which only counts towards voter participation |
| 021 |
UserB, who has a registered proxy ProxyX, increases their stake |
The vote tally to which ProxyX has voted will increase by the amount that UserB has increased their stake by |
| 022 | UserB, who has a registered proxy ProxyX, decreases their stake |
The vote tally to which ProxyX has voted will decrease by the amount that UserB has decreased their stake by |
| 023 | UserB, who has voted on the proposal, then registers themselves towards ProxyX. ProxyX has no vote registered on the proposal |
The vote tally to which UserB has voted will be unaffected |
| 024 |
UserB, who has voted Yes on the proposal, then registers themselves towards ProxyX. ProxyX has no vote registered on the proposal, then it votes Yes on the proposal. |
The vote tally for 1 will increase by the total staked to ProxyX, plus the stake amount that ProxyX has on their own account, minus the stake weight of UserB (since their vote was already tallied) |
| 025 |
UserB, who has voted No on the proposal, then registers themselves towards ProxyX. ProxyX has no vote registered on the proposal, then it votes No on the proposal. |
The vote tally for 0 will increase by the total staked to ProxyX, plus the stake amount that ProxyX has on their own account, minus the stake weight of UserB (since their vote was already tallied) |
| 026 |
UserB, who has voted No on the proposal, then registers themselves towards ProxyX. ProxyX has no vote registered on the proposal, then it votes Yes on the proposal. |
The vote tally for 1 will increase by the total staked to ProxyX, plus the stake amount that ProxyX has on their own account, minus the stake weight of UserB (since their vote was already tallied in vote tally 0) |
| 027 |
UserB, who has voted Yes on the proposal, then registers themselves towards ProxyX. ProxyX has no vote registered on the proposal, then it votes No on the proposal. |
The vote tally for 0 will increase by the total staked to ProxyX, plus the stake amount that ProxyX has on their own account, minus the stake weight of UserB (since their vote was already tallied in vote tally 1) |
| 028 |
UserA, who has a vote cast on the proposal, changes/recasts their vote for Block Producers |
Vote tallies will be unaffected |
| 029 |
UserA, who has a vote cast, delegates bandwidth to UserC, who has no vote cast |
The vote tally corresponding to UserA’s vote will increase by the newly staked amount |
| 030 |
UserA, who has a vote cast, undelegates bandwidth from UserC, who has no vote cast |
The vote tally corresponding to UserA’s vote will decrease by the newly unstaked amount. |
| 031 |
UserA, who has a vote cast, delegates bandwidth to UserC, also who has a vote cast |
The vote tally corresponding to UserA’s vote will increase by the newly staked amount |
| 032 | UserA, who has a vote cast, undelegates bandwidth from UserC, who also has a vote cast | The vote tally corresponding to UserA’s vote will decrease by the newly unstaked amount |
If you have any other test cases that you would like defined above, please reach out and let us know, and we will add them in.