Coin Voting / Shielded Airdrop / Proof of Balance

Here’s a proposal for a Proof of Balance protocol. It can be used to organize shielded coin voting and airdrops too.

Explainer Video: https://www.youtube.com/watch?v=8o1pr99qVpU

Thanks
–h

Edit: Added YT link

29 Likes

This looks very cool. A clever solution to show that you hold coins without having to send them to a T address.

I would be interested in some sort of feedback from ECC, ZF or an independent auditor about the security of this method = that it can’t be gamed somehow by shifting funds around.

Or what happens if only a small % of ZEC in circulation are measured at the time of vote, is that “enough” for a valid data point?

Overall, love the concept, this could be a solution for things like the Namada airdrop.

8 Likes

very nice. did you develop this for the ycash fork?

Amazing work.

@hanh single handedly saving the namada airdrop for ZEC holders

1 Like

Sure. The first milestone is to write up a ZIP.
Essentially, a double vote would be detected as a double spend.

No, ycash is not involved in this proposal at the moment.

5 Likes

@hanh Thanks for the YT link :heart:. Thinking out loud below.

  1. Do we need to worry about a DOS against the cost of receipts? Could an actor with 10,000s of micro wallets conceivably attack/drive-up-costs for every election? Do we required a min voting balance to solve this?
  2. This solution doesn’t include a proof of age? Could/should it?
1 Like
  1. The protocol considers that. Though there is no cost associated with receipts.
    The voter:
  • sends a p2p message to the organizer
  • makes a payment to cover the fees. The memo must contain a hash commitment to the message.

The organizer will only emit a receipt if both conditions are met. This ensures that the organizer cannot omit ballots and the voter cannot claim the organizer did.

  1. This solution doesn’t include a proof of age? Could/should it?

No proof of age. IMO, it shouldn’t, because for me, new money is as good as old money.

3 Likes

Can “elections” be bought with flash (or short timeframe) loans?

2 Likes

Might be a good idea for vote organizers to allow vote for those who held $ZEC prior to the voting announcement. Say, announcing a vote on Jan 10th. This vote will accept $ZEC held on Jan 2nd and it will be closed on Jan 20th.

So in this example, a valid vote needs to fulfill 2 conditions:

  1. Held on Jan 2nd
  2. Vote submitted before end of Jan 20th

I personally would like to see the ability to weight the length of time $ZEC held in shielded pools. For example, 1 ZEC held in shielded pools for 1 million blocks before voting starts has the same voting power as 1000 ZEC held for 1000 blocks. I understand that it’s out of scope in this proposal.

1 Like

This could be made difficult by setting a “flexible” start date. The organizer could say that the freeze height will be some time between A & B. An honest voter would have his coins ready by A. A dishonest voter would have to borrow coins for the duration of [A, B], or he could miss the actual freeze height.

5 Likes

This would likely require new ZKP circuits. For Orchard, it could be done but for Sapling it would mean another trusted setup.

3 Likes

Very exciting proposal, thank you @hanh.

  • For me, delegation is critical. Please clarify whether delegation would be possible,and practical “out of the box”, once you have delivered this project.

  • Can anyone audit a vote at any time? It is important that anyone can do so without asking any permission.

  • Would it be based on Zebra or zcashd?

Thanks again!

1 Like
  • Delegation of not supported.
  • Once the vote is over and the results are published. Anyone can audit the election.
  • This doesn’t change the core protocol. It uses p2p messages and standard transactions with memos. Neither zebra nor zcashd need modification.
3 Likes

Thank you for your answer @hanh.

Probably I am misunderstanding something but, how would a vote look like? Is it a transaction with a memo like “Vote 208: Option C”? In which case, couldn’t we just have something like this for delegation: “Vote 208: Delegated to u1xxxxxxxxxxx”?

Imo, we should first clarify how delegation will eventually be implemented before moving forward with this proposal. Without it, it may likely push users to vote by themselves in stuff they have no understanding about. We really have to think long term here.

And to me long term means that I’d like to be able to delegate my decisions for a period of one year. Most people don’t have time to follow the governance and they will miss most votes, which will give us low turnout. Could a memo such as “Delegate to u1xxxxxxxxxxx until 20250101” work?

1 Like

Yes, something like that should work.

Edit: I thought you meant delegating and then not having to vote at all.

2 Likes

That is indeed what I mean in my ideal vision:

So I see my initial suggestion as a bare minimum for delegation, where indeed, one would have to participate to each vote:

1 Like

But this only works for a single election right? It doesn’t work across elections assuming freeze height changes?

1 Like

If I “Delegate to u1xxxxxxxxxxx until 20250101” today, and in six month you freeze the blockchain, my memo would still exist, so I assume it could be applied?

1 Like

You can only prove that you held X ZEC today. Not that you’ll still have those funds in 6 months time for some future election.

Edit: It might be better if long term delegations are a voting client thing (e.g. repeat delegation button for each vote). Need to be super careful with delegated transactions/memo as they might be hard to undo.

1 Like