Adding Snapshot to The Graph Governance process

Hi Everyone,

We have created a Snapshot page for The Graph!
This post will explain what Snapshot can do, with some explanation on how it can fit into the larger picture for governance of the protocol.

Snapshot was created by Snapshot Labs, and it is an open source project that allows voting based on specific data stored on a blockchain. Over 500 projects have integrated with it, including well known protocols like Yearn and Synthetix. The voting is free, as opposed to on chain voting where gas must be paid. Here is how it works at a high level:

  • Voting is done by signing a message with your ethereum wallet, which verifies you are the owner
  • Score is calculated by using strategies. The most common strategy is counting a vote as an ERC-20 balance, but you can create a strategy based on any on-chain data. In this snapshot page, there are 3 strategies, which will be explained below.
  • The score is based on a “snapshot” of a block. This is great, as it prevents people from buying up tokens just to influence a vote.
  • The strategies are run based on the code that exists here.
  • The UI is hosted by Snapshot Labs, and thus is a point of centralization. They have a hub where all the IPFS files are stored, and then the UI calculates the scores in the users browser. The good thing about the strategy code being open source is that anyone could verify themselves if Snapshots hub was returning false data. As you can see, this isn’t a perfect decentralized solution, but it is a step in the right direction on the path to full decentralization.

This is how it works at a high level. Now, let’s describe the 3 strategies that Edge and Node has created for this page:

  • There is a strategy for delegated GRT, indexer staked GRT, and GRT sitting in a wallet.
  • Delegated GRT is based on any tokens that are currently delegated, as well as locked delegated tokens.
  • Indexer staked GRT that is in the protocol, regardless if it is being used for an allocation or not. Also any thawing indexer tokens are included.
  • Each of these three groups are worth exactly 33.33% of the scoring. For example in the network today we have these rough numbers:
    • There are ~7,800,000,000 GRT in wallets. This is always the baseline, and is worth 7.8 Billion Votes and 1 GRT == 1 vote.
    • There are ~550,000,000 GRT staked by Indexers. Indexer staked GRT is also worth 7.8 Billion votes, meaning each GRT represents ~14.18 votes.
    • There are ~1,650,000,000 GRT Delegated. Delegated GRT is also 7.8 billion votes, meaning each Delegated GRT represents ~4.73 votes.
    • If you hover over any of the votes in the UI, you will see them as B-GRT, I-GRT, and D-GRT. Each one of them is a different Snapshot Strategy.
  • If you own a token lock wallet, all of it’s voting score will be attributed to the beneficiary wallet.

Now let’s discuss how the community can use Snapshot:

  • In general, Edge and Node wanted to provide this Snapshot page as a starting point for the community. The good thing is anyone can submit a proposal on the page. We can also implement a threshold amount of GRT a user would need to create a proposal, which is something we could discuss right in this forum to decide on. The threshold would be used to prevent someone from spamming the page with useless proposals.
  • Feedback on the strategies would be great. The 33% scoring for Delegators, Indexers, and GRT holders is a starting point which is also open to feedback.
  • New strategies will be needed to represent curators and subgraph developers. Anyone in the community could work on these right now and submit a PR to the snapshot repository. The Snapshot team reviews the PRs to make sure they won’t break anything, and I would personally be happy to review anyones PR that adds another strategy :slight_smile: .
  • Voting on proposals can basically get started this week, I just need to set up one or two more configurations. Something to remember is that if you are creating a proposal, it is good to get support through the other public channels like Discourse, Discord, and Twitter, in order to have people actually come out and vote on your proposal. So far the community of The Graph has been incredibly active in the months since launch, it is one of the best I have personally seen as someone who pays attention to a lot of different protocols in crypto. People will be happy to come out and participate, as long as they are aware there is a proposal! :smiley:

Please ask any clarifying questions in this post, as I may have missed some explanation. Thank you!


Using Snapshot for the governance process is uncomplicated, user-friendly and does not cost gas. Thanks for suggesting Snapshot and for setting it up Dave, it’s great for voting and I like it very much.

It’s going to be interesting how the governance process plays out and I’m curious about the results of voting on a live proposal. In the sample vote shown during the Townhall, more than 90% of the participants were Indexers (or claimed to be one). Ideally, we find ways to also get token holders and delegators more involved in the voting process.

Happy voting everyone! Be sure to make your vote count!


Incredible work, Snapshot is such a great governance tool!

A few questions on the governance process, is more about that know/defined already? As in, how exactly proposals pass through it, how long a proposal lasts, what (if any) the voting quorum is, etc.?

Regarding the threshold amount: would you see that as a deposit that is returned e.g. when a vote passes? There is a similar thing in Cosmos, where the deposit is paid into the community fund when it fails (see e.g. my post on the entire process on Cosmos here). I personally believe a deposit, if there is any, should be returned to the proposer for any proposal that passes quorum.

1 Like

Hey Felix,

Thanks for your questions! I will try to answer below:

  • The town hall explains the governance system pretty well. It will be posted on our youtube within a day or two. We have documents as well that will supplement that video, but I am unsure the status on those
  • Thresholds and vote lengths are things we could discuss in this forum. Simply, we could start 1,000,000 GRT Indexed, and a vote length of 1 week.
  • However the voting quorum is non-existent because the votes are non-binding. The vote results are a data point that is provided to the council to help make their decision.

The video will describe a bit more as to how it all works! I will link to it in the post when it is available. :slight_smile:

Here it is! The Graph’s Town Hall Feb 23rd, 2021 - YouTube


1 Like

HI Dave,

Thank you for setting this up, I like the idea a lot! Out of curiosity (and maybe I just need to play around with the UI a bit more) is it possible to put a topic to voting that is contained to one specific subclass of voters?

If for instance, a delegator sought to gauge the opinion of other verified delegators on a particular topic, is there any way to restrict the voting to just that class? Obviously you can take to social media platforms to see what delegators might think but this has two disadvantages. First, different delegators hang out in different corners of the internet, and even a well intentioned canvasing can be time consuming and incomplete. Second, you lose the benefit of wallet verification, to ensure that input is coming from real participants and not internet trolls/ sock puppet accounts attempting to skew your findings.

I suppose one could simply pose the question to all parties and only look at the votes of the segment they were interested in surveying, but if there’s a way to limit voting within subclasses this tool could be very cleanly used to help organize consensus positions (within stakeholder classes) that should help focus the debate and inform advocacy going forward.


The way it is set up now you can’t limit the voters from participating. But the UI would show the portion of delegators that voted. So you could do some simple math to remove the other votes and figure out the results.

Snapshot is limited in its flexibility which is why we can’t force the UI to count delegators score. It might be something available in the future, but for now separating the scores with some simple math would be the way to go.

Fair enough, thanks for that explanation. It seems everyone might benefit from stakeholder classes getting a little pre-organized behind improvement ideas before we bring them to this space.

Thanks for everything the team is doing to provide us tools!