Using Snapshot to Improve Signaling and Polls

@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.


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?


@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.


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?

@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

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

You can test it here!

Strategy setup:

And this is the DSChief strategy:


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

@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.

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?

@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

@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.

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

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.

@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

I’ve deployed the “strategies” feature on prod, now you can test it here directly:

1 Like

Sharing for community awareness. Fabien, Josh and I had a great call yesterday - you’ve done some amazing work in a short amount of time, Fabien!

So we have a few options when it comes to integration. Paraphrasing from @jparklev :

  1. Link directly to . This however reduces the utility of the governance portal which isn’t ideal as we don’t want to further fragment the polling/exec voting of Maker Governance.
  2. Embed an iFrame in the portal. Also not ideal due to double headers and potential for wallet connection issues.
  3. Link directly to while maintaining a read-only page on our portal. Our read-only page would reference poll statuses allowing users to link to and vote directly on snapshot.
  4. Re-implement all the functionality in our own portal. We could fork and re-implement but would require work to stay up-to-date with enhancements.

Based on this, I feel like option 3, maintaining a read-only site with a link to voting on a poll in snapshot feels like a quality quick win, we would also look to become a hub/db host along with committing ranked choice voting enhancements to the broader community.

One important note, we still need to determine if this solution will support custody solutions such as Coinbase and Anchorage, following which, I will respond and let the community decide on whether or not we proceed based on a signal poll.

It is also worth mentioning, as you may be aware that internally we have been working on a batched polling solution that is weeks away from completion. Although a big improvement on what we have in production today, it is on-chain, so is not a free voting solution. We will continue to finish this work and have it as a complete but hidden on-chain fallback solution if it is ever needed, but for now with the pain-points around gas costs, the off-chain snapshot solution (with it’s proof/signature solution) seems like a winner.

I’m keen to hear community thoughts and appetite. Thanks all.


YESSSSSSSSSS. Options 3/4 definitely sound good. Having either link to the snapshot page or be the same portal as now but with snapshot functionality would be best imo. Sounds like you’ve considered all the possibilities in regards to custodial solutions. I’m looking forward to seeing this implemented ASAP!!!

I’m in even with 1 while waiting for 3/4.

We could also use 1 already with an on chain gov poll (the on-chain being the reference) in order to get a sense of the impact of this change. I guess using this tool will need a MIP update anyway so we have some time to test it live.

1 Like

Also a fan of #1, my bet is that we would gain more from gas-free participation than we might lose from fragmentation


In a little over a month Snapshot is now being used in some capacity by YAM, Yearn, Balancer, Sushiswap, Swerve, Aave, Rarible, Uniswap, and more!

It’s quite remarkable seeing the ecosystem pick up this new tool so quickly. If you participate in Gitcoin grants feel free to pass along the love