Oh, Snap! Setting up Snapshot Voting for Metagovernance

Metagovernance is all the rage now. The DAO space is moving at warp speed and becoming more professional by the hour. Governance has evolved and attracted dedicated professionals who play in multiple DAOs at the same time. Flipside Governance focuses on making DAOs better.

As part of our efforts to become more transparent and sophisticated, we’ve introduced a system to our governance efforts — a way to govern our governance, aka metagovernance.

We started with a humble Google Sheet to document ongoing polls, and every team member enters their vote in a column. Our Sheet had the advantage of having all active polls in one place, regardless of the blockchain where the voting takes place. Our system also helped us not miss anything important, which was a pain point. Some votes have only two days to run, and a busy week could lead to last-minute scrambles to get our vote in.

GIF copyright: tenor.co

Why we chose Snapshot

But we wanted to improve. And we wanted to vote the same way internally as we often do externally, on a dedicated voting platform. Our requirements were ease of use, a way to add or remove admins, and the ability to try different voting strategies. We chose Snapshot because it checked all our boxes, plus it was the industry standard, so we could get hands-on experience with something that our partners and clients needed. We decided against using DAOHaus or Aragon for the added transparency of Snapshot and the ability to extract reports via their excellent API.

Snapshot allows using any kind of voting strategy you can think of. If someone else has done it before, and they put the implementation in Snapshot’s GitHub, you can use it with minimal modifications. If it’s something completely new you need to implement it with JavaScript.

Documentation is in the form of an exhaustive GitBook and user support comes as a dedicated, free Discord channel, where competent contributors answered our questions in no time at all.

Let there be a token

The simplest two strategies on Snapshot are erc20-balance-of, where users vote with their balance of an ERC20 token, or erc721 where NFT holders can vote. We discussed which was cooler, and in the end decided to try both, but to start with a token. Tokens are what most of the projects we are active in use, plus we can use quadratic voting and other strategies where poll participants don’t drop all of their stash on a single choice.

Our token had to be non-transferable and have no value for safety and compliance reasons. We didn’t want to invite outside members to our voting party just yet. This might be interesting in the future, but for now, we wanted to get the voting going with the minimum amount of complexity and risk.

I dusted off my meager Solidity skills and headed over to the OpenZeppelin ERC20 docs to do some research about how to implement our bare-bones specification.

Step-by-Step, this is what I did to created the token:

1. Decided to launch on MATIC, because Snashot’s Mumbai RPC nodes weren’t performing when I tried. Thanks Laurent from customer support for saving me hours of searching.
2. Added the MATIC network to my MetaMask and loaded up 0.1 MATIC. Minting costed a few hundredth of one MATIC so I had a lot of tries to get it right with just this.
3. I copied the code from this amazing tutorial into Remix.
4. Customized the token name and ticker, our’s is called $GOV. How cool is that?
5. Overrode the transfer() and transferFrom() function with my own code that simply emits an event, but doesn’t change any balances. $GOV shall not be transfered!
6. Added an issueToken() function so I can give newbies tokens or top up as needed
7. Added a removeToken() function so I can burn tokens from people leaving the team
8. Modified both issueToken() and removeToken() to be onlyOwner so that only I can use them. No hacking here!
9. Deployed on MATIC by choosing Inject Web3 in Remix and confirming in MetaMask.
10. Copy the contract address of the freshly deployed $GOV token to a note
11. Added the token to my MetaMask and gave the address to my teammates so they could check their balances
12. Done

You can see a screenshot of Remix with the four functions I talked about right here:

And here’s the screenshot where you can see the deployed token contract address in Remix. We’ll need it later to define the Snapshot token voting strategy, so please copy it to a doc. Also for later interactions with the contract!

Notice the contract address starting with 0X in the screenshot

Initial Token Distribution

The Flipside Governance has five full-time members and three interns at the time of this writing, 27 June 2022. We decided to give team members 1,000 and interns 510 tokens each.

Two interns can override one full-time member if they pool votes, giving interns power to sway votes where full-timers aren’t aligned and incentivising them to participate.

These parameters are a first experiment. Our “alpha” token distribution, if you will. We can burn or issue tokens at will, and plan on experimenting with different distributions until we have a sweet spot. This is very much work in progress.

You can view the balances of our current iteration on Polygon Scan here.

Setting up Snapshot

Snapshot voting happens inside so-called Spaces. The documentation is pretty good and I don’t want to duplicate it here, so I’ll focus on the few things that didn’t work as described and refer to Snapshot’s excellent GitBook otherwise.

To set up a space, I needed:

• An ENS domain that you control, that will determine the URL of the space
• The address and the ticker symbol for your token contract
• The voting strategies you’ll want to use
• The addresses you want to allow to create new proposals
• The addresses you want to allow to administer the space

I simply followed the instructions in the GitBook to get up and running. One issue that I encountered was that no one could vote on a new proposal that I created. Turns out that was, because I switched from using MATIC Mumbai to MATIC Mainnet and deployed the token after the proposal was added. Snapshot determines who can vote according to who holds the necessary tokens at the time the proposal was created. Because I changed the contract address after the proposal’s snapshot time, no one had any tokens at the time used for determining vote weights, and the weights display and voting button remained grayed out.

Voting strategies

I’ve touched voting strategies a bit, and want to dig deeper in this subchapter. Snapshot allows any kind of strategy for voting as long as the strategy returns which options receive how many votes. Algorithms are coded in JavaScript and access Snapshots amazing SDK.

Thankfully many different ways to vote have already been implemented and anyone can browse through this repository on GitHub and likely find what they need. Every strategy needs to be customized a little. Uniswap uses $UNI to vote, for example, and we at Flipside Governance wanted to use our own token instead.

The initial strategy we wanted to play with is erc20-balance-of, where token holders vote with the weight of their holdings, which get added to determine the winner. ERC20 balance is the most popular voting strategy on Snapshot and is used in more than 7,200 spaces, which is why it is top of the strategies dropdown menu.

After selecting the strategy from the list a small window appears where I filled in the details of our token. See the screenshot below.

I could even test-drive strategies in the playground before rolling them out. Tell me again how can a tool as awesome as Snapshot be free?

Another popular strategy is erc721, where only holders of a specific NFT can vote. Once more, I’d need to specify the address of my NFT’s contract and the ticker symbol to get this running.

Then there are different types of delegation strategies, where users do not vote directly but instead delegate their tokens. This requires delegation contracts, and a delegation UI to make it comfortable.

For now, we’re experimenting with the token and want to use different methods of counting votes. You can set that up right below the strategy, see the screenshot below.

Instead of single choice voting I could select weighted voting where token balances can be assigned to votes instead of an all-in or quadratic voting where assigned balances are counted quadratically.

We will definitely experiment with quadratic voting, because we feel this is a very exciting frontier in making democratic processes more fair.

First impressions

We started voting on selected issues to give the whole process a spin, and it feels amazing. Voting is gas-free, we can experiment with strategies and we use the exact same process many of our partners use.

We’re currently considering whether to put all our votes up on Snapshot, and ditch the Google Sheet. The effort of adding a new proposal is about the same as entering a proposal into the Sheet. There’s little extra cost to that. But somehow putting in votes for non-EVM partners like Mango Markets or Osmosis feels a bit off.

Google Sheets also did a terrific job at having all the activity visible at a glance. Sheets would also allow us to use Apps Script and possibly pipe in vote data directly from the forums.

For now, we will use Snapshot for EVM voting and we have also set up Realms for Solana-based voting. Both are only fed with the most contentious of polls where we need to discuss and research more.

All votes are still entered in the Google Sheets so we have a single source of truth where we can find everything at a glance.

Conclusion

Our Snapshot and Realms experiment is fun and a massive learning experience for us as a team. We’re stepping up our metagovernance game, experimenting with token design and getting our hands dirty in processes that many of our partners appreciate a helping hand with.

We’ll continue to try different voting strategies and will of course be public about that in a future post.

Stay tuned for more…