In this case study, you’ll learn how Snapshot
(opens new window)works and how it uses IPFS to lower the barriers to entry for voting and community governance.
Overview
What is SnapshotSnapshot by the numbers
The story
How Snapshot worksParticipants vote on proposals
Calculating results
How Snapshot uses IPFSUploading to IPFS pinning services with Pineapple
Open access via IPFS Gateways
IPFS benefits
Snapshot & IPFS: the future
#What is Snapshot
Snapshot is an open-source voting platform for Web3 projects, DAOs, and communities that uses IPFS as its main storage layer.
Snapshot works with projects deployed to Ethereum and EVM compatible chains and allows the use of governance tokens as a means to distribute voting power and eligibility.
Snapshot is unique in its use of IPFS to store proposals and user votes using a technique known as ‘off-chain’ voting, where the cryptographic signatures proving user votes are persisted to IPFS instead of being stored on the blockchain.
This means that voting with Snapshot is practically free since voters don’t need to pay gas for transactions, i.e. gasless voting. In doing so, Snapshot lowers the barrier to entry for voting, increases governance participation, and allows projects and communities to scale their voter base.
Transparency, one of the core tenets of governance in the Web3 space, is achieved by having all proposals and votes persisted using content addressing on IPFS, thereby allowing anyone to view, audit, and replicate a copy of the CIDs containing the cryptographic signature.
Web3 projects and Decentralized Autonomous Organizations (DAOs) are typically characterized by their bottom-up approach to governance, where control is spread out across the participants (or token holders), rather than being built on a top-down hierarchy. While there are many different approaches to bottom-up community governance, almost all involve voting as a mechanism to engage the community and distribute control.
In essence, Snapshot allows projects and DAOs aiming for decentralization to poll their community over which direction a project should move in.
#Snapshot by the numbers
Snapshot was originally built while Fabien, Snapshot’s founder, was working for the automated market maker Balancer
(opens new window). The goal was to create a voting platform that would be flexible enough to grant BAL tokens within Balancer pools
(opens new window)voting power. However, doing this on-chain turned out to be too computationally heavy to be feasible. That’s when he realized that doing it off-chain with IPFS could provide them with the flexibility needed.
While free (“gassless”) voting was not one of the initial requirements for Balancer, it came as a serendipitous bonus of the off-chain design with IPFS.
Two weeks later, Fabien began generalizing his gas-efficient implementation using IPFS so that could be used by projects and DAOs beyond Balancer – and Snapshot was born.
After open-sourcing an early version of Snapshot, it was quickly adopted by early DeFi projects like Yam and Yearn and has since taken over the governance landscape.
Today, Snapshot is the leading voting platform used by over 9,645 projects. Their users include many of the leading Ethereum projects, including Gitcoin, Ethereum Name System (ENS), Aave, Uniswap, and Sushi.
#How Snapshot works
In Snapshot, all proposals and votes are associated with a space, where each space is an organization’s (or project’s) page on Snapshot. Voters can access spaces by using the project’s Ethereum Name System (ENS)
(opens new window)name, e.g.
https://snapshot.org/#/gitcoindao.eth, where gitcoindao.eth is the ENS name.The only requirement for using Snapshot is to have an ENS name. To create a space, you create an ENS text record
(opens new window)with the key
snapshot pointing to an IPFS CID containing the JSON configuration for the space. For example, GnosisDAO with the gnosis.eth ENS name has the snapshot(opens new window)text record set to
ipfs://QmWUemB5QDr6Zkp2tqQRcEW1ZC7n4MiLaE6CFneVJUeYyD(opens new window)which contains the JSON configuration for the space.
Who can participate in voting, e.g. token holders of an ERC-20 token or NFT tokens (ERC-721, and ERC-1155.)
The voter’s voting power, e.g. one vote per token.
Who submit proposals to be voted on, e.g. token holders with a given minimum number of tokens.
For example, the ENS project requires holding the ENS token to vote on proposals and at least 10k ENS tokens to create proposals.
#Participants vote on proposals
Once a space is created, voting happens through proposals. A proposal describes the issue of a vote and also has a voting system that determines the choices voters can select, and how the results will be calculated.
Importantly, each proposal includes a Snapshot block number pointing to an Ethereum (or any other supported blockchain) block number. The block number is the snapshot where the balance of voters will be counted. This prevents manipulation by the temporary acquisition of tokens after a proposal is made.
#Calculating results
To calculate the results of a vote, each proposal employs one of the following voting systems:
Single choice
Approval voting, where a voter can select multiple choices
Quadratic voting
(opens new window)
Weighted voting
and others
(opens new window)
These voting systems are used to calculate the results of a vote based on the voting power. For example, the following proposal
(opens new window)) in the Decrypt Media
(opens new window)space, grants Decrypt NFT holders the right to choose a single topic for the content they will write next. Voting power for this proposal is relative to the number of Decrypt NFTs held by the voter at block number
12,811,388.
Snapshot uses IPFS to make the whole voting process fully transparent and auditable. Every space, proposal, vote, and user action is added to IPFS and has a content identifier (CID).
Additionally, the Snapshot UI is also available on IPFS
(opens new window)and linked using the ENS name
shot.eth which is accessible via any ENS resolution service, e.g. shot.eth.limo(opens new window), and shot.eth.link
(opens new window)(see the
x-ipfs-path and X-Ipfs-Roots headers when making an HTTP request.)To understand how Snapshot uses IPFS, it’s useful to understand how the whole architecture was designed. Snapshot is a hybrid app combining design patterns common to Web2 and Web3 apps, and is based on the three-tier architecture:
Presentation tier: The Snapshot UI
(opens new window).
Logic tier: The snapshot-hub
(opens new window)node.js server that exposes a GraphQL API.
Data tier: A combination of a MySQL database for indexing and querying and IPFS as its storage layer for space configuration, proposals, user actions, and votes.
Note: Even though MySQL is used for querying, all data stored on MySQL is available on IPFS. Tables in the database schema
(opens new window)have an
ipfs field holding the IPFS CID.
To make it easier to persist data to IPFS, Snapshot built a microservice called Pineapple
(opens new window)and a client library called pineapple.js
(opens new window). Together they abstract the details of uploading content to multiple IPFS pinning services.
pineapple.js exposes a
pin method that takes a JSON object and sends it to the microservice over HTTP. The Pineapple microservice, races uploading the JSON to multiple IPFS pinning services and returns a response as soon as at least one of the services responds with a success. Additionally, the data is also uploaded to AWS S3.#Open access via IPFS Gateways
After data is added to the IPFS network via pinning services, it is also made available for viewing by users via an IPFS Gateway. Links to the signed messages for proposals
(opens new window)and votes
(opens new window)are integrated into the Snapshot UI.
#IPFS benefits
When the Snapshot team set out to build openly auditable voting systems, they chose IPFS because it’s the standard for storing data that must be fully verifiable, but is too large to store on blockchains.
The combination of user-controlled keys (via non-custodial crypto wallets), cryptographic signatures that prove the authenticity of user actions, and content addressable storage via the IPFS network have proven to be critical to Snapshot’s success.
Moreover, IPFS has several properties that enable that mission:
Proof of data integrity via IPFS content addressing
Ability to store data, even in perpetuity, without having to rely on a single centralized cloud storage platform.
Interoperability with multiple storage providers and pinning services. Once the data has been uploaded to a single pinning service on IPFS, it can move around easily and be stored on multiple pinning services to ensure redundancy.
Transparency and availability of data give anyone the ability to also pin and audit that data.
A thriving ecosystem of pinning services and open-source tooling
As Snapshot continues to evolve, the team looks forward to decentralizing its tech stack so that anyone can run a node, reducing the dependency on the Snapshot Node.js servers. Thanks to IPFS’s integral role in Snapshot, a significant part of their data layer is already decentralized.
Note: This case study was originally published in the IPFS docs
(opens new window). Metrics and other details in this case study are current as of August 2022. Details may change in the interim.
https://blog.ipfs.tech/2022-08-25-snapshot-ipfs-case-study/
Chinese 
English