Using Snapshot to Improve Signaling and Polls

Governance
#4

Well, it’s important for governance polls. And we might get a lot more participation with gasless voting.

Yeah, maybe not everyone’s a whale. But there’s a lot of holders. Actually 27k addresses hold MKR, top 1k address holds 17.66 MKR which is worth more than $10k. All the shrimps and dolphins can make a difference for governance polls. And it’s not a stretch to say that some of those holders are active here. :smile:

But it is an interesting mix currently, our signal requests that we have now combined with governance polls on chain which is 1 coin 1 vote.

1 Like
#5

I’d be interested to contrast the security differences between between our current on-chain polling and snapshot. @fabien are there any points of centralization, trust assumptions, or operator risks with using off-chain polling?

Also, am I thinking correctly that this will work even when tokens are deposited into our governance contract?

#6

@Jtathmann with Snapshot there isn’t any on-chain settlement, it’s what we call soft-voting or vote signaling. The proposals and votes are just signed messages using the eth_sign format and stored on IPFS. The signed messages are made available for the user through the interface so that’s easy for him to verify it.

Here is an example of a signed message for vote on a Balancer governance proposal:
https://gateway.pinata.cloud/ipfs/QmeVwGtp4YxKaCGZM3jPSd7VKXTEAxXj74Xjnn1c8F4ifh
You can copy paste the message payload here to verify it:

There isn’t any smart contract risk because there isn’t any smart contract. The result of the proposal votes is easy to verify and hard to contest.

We use a server that we call “hub” to upload user signed messages to IPFS. We also use it to store an index of IPFS hashes for all the proposals per tokens and all the votes per proposals on a database to make interface load faster. We plan on making it possible for anyone to run a hub but at the moment i would say that it’s a point of centralization.

Also, am I thinking correctly that this will work even when tokens are deposited into our governance contract?

Currently votes will be considered if the voting address is also the address who hold MKR or a selected token. If the governance contract is holding the token for the users there might need some small change on Snapshot to make it work.

6 Likes
#7

I’ve create a space on the demo instance here: https://beta.snapshot.page/#/maker
Feel free to play with it, you can create proposal and vote for them using MKR (for free!).

4 Likes
#8

This is awesome @fabien. Any suggestions on how this voting method could be further decentralized/trust minimized?

#10

@Aaron_Bartsch Yes, i got these 2 options to minimize trust:

A: One option is to link each IPFS signed messages to each others, sort of we don’t need an index to get the full list of hashes, we can just load IPFS hashes in serie from the interface and remove the hub completely. But because it’s loaded in serie one by one, it might be very slow and not scale well when loading hundred of votes.

B: The other option is to make it possible for anyone to run a hub. The hub db may not need to know ordering, its designed more like a graph database similar than IPFS. The client should have a way to set the hub url (or array of hub url) of his choice, and hubs should be able to talk to each others and stay sync. I could ask few protocols that are using Snapshot to run their own hub to keep some kind of trusted network.

I would prefer go for plan B, the project Snapshot is very new there must be others options to explore, i’m confident that with time we will be able to reduce that trust needed, happy to discuss if you have some suggestions or ideas.

3 Likes
#11

Very cool. Option B definitely makes the most sense. I could envision Maker governance electing several hub maintainers to shepherd this infrastructure kind of like a multi-sig.

One more question. Is it possible to add comments to a signed transaction so voters could anonymously comment as to why they voted a certain way?

2 Likes
#12

@Aaron_Bartsch Great! Now there isn’t any way to comment on a vote but that’s something we want to implement in the short term. There will be a way for anyone to comment (even if you haven’t voted) and comments will be linked to votes.

2 Likes
#13

I’m now thinking, how would this work with MKR in the dschief contract? Is it possible to sign a transaction if your MKR is in another contract?

#14

@Aaron_Bartsch It will not work if the address who sign the message doesn’t hold the token defined on Snapshot, from my understanding staking MKR in the contract doesn’t mint another token so it will not work out of the box, but we can imagine having custom logic to be implemented for specific use case like MKR.

1 Like
#15

Here is an update from our friend @fabien. Snapshot now using MKR locked up in DSChief

You can test it here!

Strategy setup: https://github.com/balancer-labs/snapshot/pull/58/files#diff-d45e9fc817dd9f4950aa966ea99f5b56R10-R22

And this is the DSChief strategy: https://github.com/balancer-labs/snapshot/pull/58/files#diff-1b6072936c35d66437c3197aadb614bb

2 Likes
Maker Relay Ep 11
#16

Hey @fabien, what causes the Oops, wrong timestamp error… and how fix?

#17

@fabien Hm, I think I usually vote with 0x273BF243219D31c4096c00e156c1d8a8ff9731D9. I use the two address hot/cold setup. When I try to vote, it says that I have 0 MKR. The regular vote site shows 400 MKR.

#18

Is snapshot censorship resistant? I don’t think how it could without doing anything on chain, so it’s probably very helpful to have on the forum but not a suitable replacement for on chain signalling. The other problem with it is that it won’t be supported by custody providers and any non-standard smart contract as it requires an EOA (Ethereum accounts owned by a cryptographic key instead of say a smart contract). I’m not sure how much better we’d actually be with this mechanism.

How is it working out for balancer labs? Are large institutional holders participating in it?

#19

@Jtathmann Did you used Metamask?

@Joshua_Pritikin When i call the function “deposits” on DSChief for this address “0x273BF243219D31c4096c00e156c1d8a8ff9731D9” i got a response of 0 MKR, this is most likely the reason why you don’t see the MKR in the interface. Is there some kind of delegation? There might be a logic that i am missing, if someone can explain to me i could implement it on the strategy.

1 Like
#20

@spin I will not say it’s censorship resistant if we don’t have the network of hubs that i’ve discussed in earlier messages here but the proposals and votes are stored on IPFS, the hub expose all the IPFS hashes, anyone can already pin and replicate the content. I’m not sure to understand the issue with custody providers, is it something that is working already in Maker on-chain governance?

How is it working out for balancer labs? Are large institutional holders participating in it?

Snapshot is a side project that i’ve initiated with the support (non-monetary) of Balancer Labs. There is no investors participating, no token, no business model and no plan for all of it. Ideally i want Snapshot to become a common good tool for governance maintained by open source contributors.

#21

Thanks on clarifying the multiple hub fact, indeed, if multiple hubs exist and at least one of them is honest then censorship becomes harder.

As for the “institutional investor” question, that was not asking about whether investors invested in Snapshot but whether funds that hold tokens with a professional custodian (such as anchorage or coinbase custody) could still participate because they don’t actually have a private key that they could use to sign.

Even myself I keep most of my stuff in a Gnosis Safe Multisig where it’s not a simple 1:1 relationship between signing keys and accounts.

1 Like
#22

Ok got it! Thank you for the details and sorry for the misunderstanding. For the funds held in professional custodian it will not work indeed. I wonder if the funds from each of these investors have a specific address in Coinbase custody or if it’s mixed. If each investor have their own address we can imagine Coinbase custody enabling some kind of delegation to make the fund usable for vote on Snapshot. For multi-sig wallets we can imagine having a strategy that count a vote only if a multi-sig threshold is reached, or a way to delegate this ability to vote to a single address. These are just some ideas, there might be better way to solve this, happy to brainstorm on this.

#23

@fabien Yeah, currently some delegation is supported. There’s a voting proxy, and you let your hot wallet be able to vote for your cold wallet.

Not sure how to implement that into a strategy but other people might know how.

1 Like
#24

I’ve deployed the “strategies” feature on prod, now you can test it here directly: https://demo.snapshot.page/#/maker

1 Like