Grant Discussion On-Chain Voting Protocol Grant: Milestone 1 Discussion

As some of you may have heard from the recent update of our sponsor @Alex, Sep. 9th is the deadline for the release of our first milestone: a draft specification of the on-chain voting protocol. Without further ado, you can find the spec here.

We welcome all feedback from the wider community, especially since this is a central piece of the future decentralized governance of the protocol and thus affects all eventual Standing Parties. Please feel free to comment directly in the document and/or provide feedback in this thread.

the on-chain voting grant team
Hey @sanchopansa , Im wondering if this thread shouldnt be moved outside the Grant Updates subforum. My original idea for this subforum was to have 1 thread per grant, and from that thread link to threads like this one here. That way we dont clutter up this subforum. It doesnt have to be that way, but I think that makes the most sense. Thoughts?
“voterId”: digital identity of the voter to add,
- This is what you're reliant upon Factom Inc for, yes?

The administrator can remove a voter by assigning a weight of 0 to a voter ID.
Is "weight" the voters standing in the protocol? I see you use weight percentages so I'm curious how this is calculated. Will voters be able to see their and others weight?

Upon commencement of the reveal phase, all participants can reveal their votes. The reveal is an entry in the vote-chain:
So a voter must in essence vote twice? Once in a hidden form and then to reveal their actual vote? The system doesn't do the actual reveal?

4. Will there be a simple UI for creating votes and voting? Or will all of this be CLI?

Thank you.
1. Yes exactly. I don't remember if it was mentioned in the update but myself and Sancho reviewed the specification on digital entities Factom Inc is working on. So they're working on it right now and the spec is well advanced, but there is still the implementation part on their side.

2. I think it's not clear enough in the doc, but there are kind of 2 modes of voting. One regular and one involving standing parties. If it is a standing party vote, the administrator cannot remove anyone from the list of participants, nor chose their weight or anything like that, it just takes the standing party attributes as it is defined by the Factom protocol at the time of the vote (staked EC, FCT, etc). Standing parties are being developed by Factom Inc., they are responsible to develop the formula of standing weight. Then there is the regular type of vote where the administrator decide the set of participants and their weights. Like a Guide-only vote for instance, with each guide an equal weight of 1. Btw weight is not a percentage, it is an integer.

3. Correct. That said the voting UI should make it easy for you to make the reveal and also not forget about it... We are not aware of any trustless way to do the reveal automatically, it would require to give your vote reveal to a trusted person (or a program) that would then reveal for you on time, but that person/program would know in advance your vote... That would be more user-friendly but less secure.

4. MyFactomWallet is developing a web UI to interface with the voting protocol that should hopefully make it easy to create, browse and participate in votes.
@DChapman to add a little bit to what Paul mentioned:

2. Indeed there are two different modes and this is (maybe too) briefly described on page 4. I'm putting this excerpt from the document here for reference:
For the special case of Factom governance related votes in which all Standing Parties can participate, the vote-participants-chain is not created. Instead, the participantsChainId in the vote proposal entry is set to the ID of the Standing Party Registration Chain. The weight for each voter is determined by their Standing Party weight at commitStartBlock.
Now getting to your question about whether voters will be able to see theirs and others weights. Weights are public, so everyone will be able to see each others weight. However, there is one small difference. If the administrator explicitly sets weights for each authorized voter, then everyone will be able to see those straight away when they view the poll. If, on the other hand, it's a vote for all Standing Parties, the weights will once again be public, however, due to the way that Standing Party weight is computed it is only available for past blocks (you can compute the Standing Party weight only for blocks which have already been recorded in the blockchain). So, in this case, voters will be able to see the effective weights for Standing Parties only after commitStartBlock. Before that block, the best one can hope for is a guesstimate of their actual weight.

3. We are considering providing an easy way for people to complete the reveal phase. One option discussed is to send an email with a special URL, which when opened would "automagically" fill out a lot of the information required for the reveal of the vote. This is still WIP and in discussion, though.
Last edited:
Thanks for the responses guys.

[3. We are considering providing an easy way for people to complete the reveal phase. One option discussed is to send an email with a special URL, which when opened would "automagically" fill out a lot of the information required for the reveal of the vote. This is still WIP and in discussion, though.
I think this is my only real concern after my first read through. Getting people to vote once is hard enough. Getting them to in essence do it again may prove much more difficult and lead to some issues, especially if their vote is discarded and it would have made a meaningful difference. I do understand the technical hurdle of not wanting to trust anyone or anything though. It's a tough situation.
Agree, it would be very beneficial for UX to have auto reveal possible. I'm envisioning it like a service that could be implemented by anyone and potentially seamlessly integrated with MFW UI: after committing your vote you're given an URL to reveal manually yourself but also a list of auto reveal services you could choose from, which will get your vote forwarded to and will be responsible to reveal your vote on time.

Now implementing that auto reveal service doesn't have any particular technical challenge, but it's still a non trivial piece of software to develop, it should be perfectly secure (to not leak votes) and reliable (so vote don't get lost/forgotten). I'll discuss it with other teams of the grant, but I'm afraid a proper implementation of it won't fit this grant in terms of time/resource. Also it has a cost of maintenance to run that service + a cost of EC as the service pay for the reveal entry. With my proposal it's a fairly independent component that could be plugged later as an upgrade (again I totally see its value and I do want to do it at some point).