Subscribe to Snapshot Labs
>470K subscribers
Subscribe to Snapshot Labs
>470K subscribers
Share Dialog
Share Dialog
Snapshot is an open-source voting platform which enables organizations to vote easily and without gas fees. Its technical implementation guarantees transparency which is crucial for decentralized governance. In the further part of the article we will have a look at each layer of the Snapshot implementation and look into its usage of IPFS which enables easy verification of data stored off-chain.
Do you need to be crypto native to use the platform?
Not at all, the platform is straightforward and easy to use even for the newcomers in the web3 world.
It’s easy to use and can be customized to the needs of various projects.
If it wasn’t for Snapshot, each organization would have to come up with their own voting solution built specifically for their use case. Snapshot allows organizations to use a customisable solution and requires little effort from the organizations to set up. If you want to explore the most active spaces, Snapshot’s biggest integrators or proposal and voting details have a look at the Snapshot dashboard on Dune.
It’s free to use.
Thanks to its technical setup, voting on Snapshot can be performed off-chain and without any gas fees. This helps organizations increase governance participation in their communities and reward users for voting through plugins such as POAP.
It’s fully open source.
The codebase is fully open to the public and provides a trustless environment which is essential to the governance process. Anyone can view and audit the logic behind Snapshot’s voting system. Moreover, the data is stored in a decentralized manner off-chain and can be viewed, audited, or replicated by anyone at any given time.
First of all, any action on Snapshot requires users to connect to the platform with their wallet. At the moment Snapshot supports several wallets, including MetaMask, WalletConnect and Coinbase Wallet.
Voting can be conducted thanks to the three main elements of the platform’s structure: spaces, proposals, and votes.
Organizations and projects can create spaces, which you can think of as their profiles on the platform. To do so, they need an ENS name, which is used as a space identifier and allows users to access its page on Snapshot, for example https://snapshot.org/#/balancer.eth.
Space controller and admins, if they are defined, have the ability to define a custom voting setup which includes:
assignment of different space roles for the space (admins, moderators, authors),
a selection of voting and validation strategies,
quorum required for proposals to pass,
plugins that extend Snapshot’s core functionality,
and more.
Once the space has been created, the eligible users (as per space settings) can create proposals with one of the available voting systems, i.e. single choice voting, weighted voting or approval voting. You can learn more about the different solutions in Snapshot’s documentation.
Community members who fulfill the criteria (defined by the validation strategies selected for the space) can then cast their votes. The individual voting power is calculated on the basis of the voting strategies that define specific rules, for example checking for the balance of a specific ERC20 token or an ownership of a NFT token.
Why “Snapshot”?
Voting power is calculated at the snapshot of proposal’s creation. It means that if you acquired tokens after the proposal has been created they won’t be taken into account when calculating your voting power. This is where Snapshot’s name is coming for as this is the fundamental feature of the voting process on the platform.
The outcome of the proposal is calculated on the basis of the chosen voting system. Do not mistake it with the voting strategy though! While voting strategy is calculating the individual voting power of a voter, voting system is used to calculate the result of the proposal. Let’s have a look at the example of the weighted voting system.
Each user can spread their voting power across any number of choices, from one to all. Their voting power will be divided between their chosen options according to how much weight they attribute to each option by increasing or decreasing the voting power fraction.
What happens next? If a proposal has passed it is up to the DAO itself to execute it, as Snapshot is not involved in the actions taken by the organization.
Some of the Snapshot spaces are using SafeSnap, a Safe plugin which enables a trustless on-chain execution with the multi-sig account. As this topic deserves a separate article, I’d recommend you to read about it here.
If you are curious about how Snapshot looks like from the technical perspective, read on!
Snapshot is a protocol which combines multiple services in order to provide a seamless experience for its users. All repositories are open-sourced and can be viewed and audited by anyone at https://github.com/snapshot-labs.
The below wireframe gives a top level overview of the platform’s architecture:
Snapshot's infrastructure is designed with three main layers:
User facing: frontend application accessible at https://snapshot.org
Logic: backend server orchestrating the work of multiple services
Data: various storage solutions persisting information off-chain
Snapshot’s interface is a Vue.js application built with Typescript. All the actions (i.e. creating a new space, proposal or voting) are possible thanks to the implementation of Snapshot.js client, a JavaScript library available for anyone to use. Whenever a user wants to perform a specific action, for example cast a vote, it triggers a message signature request in user’s wallet.
The message is then sent to the backend service - Snapshot Sequencer.
The core element of the backend infrastructure is an Express.js server - Snapshot Sequencer. It is responsible for receiving, verifying and ingesting the information incoming from Snapshot’s UI or other applications which integrated Snapshot in their infrastructure. It also communicates with the Score API which is calculating voting power of users and lastly, Sequencer orchestrates the process of persisting the data off-chain and sends a response back to the UI. The response includes a receipt, which is a proof that user’s action was approved and registered in the protocol.
What does it mean though?
The receipt is an Ethereum signature issued by the Sequencer which holds a private key. If you are familiar with how asymmetric cryptography works, or in other words how thanks to your private key you are the only person that can trigger transactions from your wallet, you can apply this logic to the receipt. If you are still not sure what private key is, let’s have a look at its definition from Investopedia:
A private key is an alphanumeric code used in cryptography, similar to a password. In cryptocurrency, private keys are used to authorize transactions and prove ownership of a blockchain asset.
source: https://www.investopedia.com/terms/p/private-key.asp
Now, as Sequencer is using its private key to issue an Ethereum signature, it means that it can be easily proven and any potential censorship attempts can be uncovered. This allows for a trustless process and its transparency along the way.
Last but not least, why “Sequencer”? The service’s name is coming from one of its most important features. Each action approved by it is stored with an auto-incremented ID, which means that anyone can replay the entire history of actions taken on Snapshot in the correct order.
As I mentioned before the individual voting power depends on the selection of voting strategies used by a specific space. In technical terms a strategy is a JavaScript function that returns a score for a set of addresses. You can find them all here. At the moment or writing this article there are 427 voting strategies available on Snapshot. Some of the most commonly used are:
If none of them is addressing the needs of your organization, it is possible to create a new custom strategy by following this process.
Spaces can also select a validation strategy - a JavaScript function which will evaluate if a user is eligible to perform a specific action: create a proposal or cast a vote. A validation strategy is a JavaScript function that returns a boolean (true or false) for the connected account. What does it check? The possibilities are unlimited. It can use a combination of existing voting strategies, check how many POAPs an account owns or measure the on-chain activity of the account in order to assess if the account is a bot or a real human. All the existing voting validations can be found here and the collection can be enriched by the community by following this process.
The primary purpose of the Score API is to calculate the voting power of individual addresses at a specific block height. It achieves this by using on-chain data retrieved directly from EVM archive nodes or a subgraph, along with a selection of one or more strategies. In addition, the Score API is also responsible for validating addresses using validation strategies.
The Score API relies on a variety of archive nodes to ensure reliability and accuracy in data retrieval. A full list of supported nodes can be found here. It is compatible with all EVM-based blockchain networks, which allows it to work with popular chains like Ethereum and Arbitrum.
To integrate the Score API into third-party applications, developers should use the Snapshot.js NPM package. This package simplifies the integration process and provides a consistent interface for interacting with the API.
One of most important design choices in Snapshot is the data storage solution. Storing information on-chain is very expensive and could be a big bottleneck for users to participate in the voting process - we all try to avoid costs whenever we can, right?
The alternative solution, which guarantees transparency and gasless voting, allowing anyone to view, audit and replicate the data and participate in DAOs governance without any cost, is the content addressing on IPFS. In fact, every space, proposal, vote, and user action confirmed by a signed and verified message can be found on IPFS, has a content identifier (CID) and a receipt proving the action has been validated and stored on the protocol.
Snapshot has developed a microservice called Pineapple and a corresponding JavaScript library pineapple.js to simplify data persistence to IPFS. Combination of the two ensures that the data is pinned successfully and as fast as possible.
pineapple.js exposes a pin method that takes a JSON object (representing a user action, space object, message signature, etc.) and sends it to the Pineapple microservice over HTTP. From there Pineapple uploads the JSON to multiple IPFS pinning services, such as 4everland, infura and pinata, at the same time and returns a response as soon as one of the services responds with a success. You can have a look at the most successful (fastest) providers here. Additionally, the data is also uploaded to AWS S3.
Apart from IPFS, Snapshot is also storing the information in an organized manner in an MySQL database which is exposed on a public API, Snapshot Hub. Anyone can easily query the database through the GraphQL interface.
To recap and understand the infrastructure better let’s follow the process of casting a vote:
User connects their wallet on Snapshot’s interface at https://snapshot.org.
Once connected, the user heads to a proposal’s page, selects their choice(s) and clicks Vote. A modal with the vote summary opens up with the selected choice(s), snapshot of the proposal (a block number) and the user’s voting power calculated by the Score API. If the user confirms the vote, the wallet will open up in with a request to sign a gasless message.
The payload of a signed message is sent to Snapshot Sequencer for verification thanks to the Snapshot.js library.
A crucial part of the verification step is the voting power check. Sequencer sends a request to the Score API and awaits the response with the voting power and vote validation.
After successful verification, Sequencer then triggers Pineapple to pin the message details on IPFS and inserts the details to the MySQL database.
Upon successful response from the data persisting services, Sequencer sends back a response to the Snapshot UI with the vote receipt - a confirmation of the vote and its IPFS CID.
User can see that the vote has gone through and can now share that they have voted on the proposal on selected social media platforms.
As you can (hopefully) see, Snapshot’s infrastructure is pretty straightforward and is making it easy for the voters to participate in the governance of their organizations at no cost and without any technical understanding.
Moreover, the open-source ideology of the company guarantees transparency at every step of the process and enables the contributors to extend the possible customizations for spaces, by creating new voting and validation strategies, or even the core functionalities of Snapshot by implementing new plugins.
Lastly, Snapshot’s architecture allows the voting process to be censorship resistant thanks to the Sequencer. As the Ethereum signatures are issued with Sequencer’s private key, any attempt to maliciously alter the data can be easily spotted even though the service is not fully decentralized. When it comes to full decentralization - keep a lookout for the next article about infrastructure update.
Decentralizing the Sequencer is the next step for Snapshot to fully decentralize its voting platform, which would further enhance its censorship resistance. By doing so, Snapshot will eliminate a single point of failure and allow for more decentralized decision-making. This would also increase the platform's security and resilience against attacks or attempts at censorship.
If you have any questions about the Snapshot’s technical architecture, make sure to drop a message on the Discord server or connect with Snapshot on Twitter!
Mint the Snapshot’s Technical Architecture NFT to show your support for the Snapshot’s publication on Mirror and to be notified of future updates from us!
Snapshot is a voting platform that allows DAOs, DeFi protocols, or NFT communities to vote easily and without gas fees.The tool allows high customization of the voting process to cater to the diverse needs of the users and organizations.
https://dune.com/snapshotlabs/dashboard
Where decisions get made. Snapshot Labs has 62 repositories available. Follow their code on GitHub.
Snapshot is an open-source voting platform which enables organizations to vote easily and without gas fees. Its technical implementation guarantees transparency which is crucial for decentralized governance. In the further part of the article we will have a look at each layer of the Snapshot implementation and look into its usage of IPFS which enables easy verification of data stored off-chain.
Do you need to be crypto native to use the platform?
Not at all, the platform is straightforward and easy to use even for the newcomers in the web3 world.
It’s easy to use and can be customized to the needs of various projects.
If it wasn’t for Snapshot, each organization would have to come up with their own voting solution built specifically for their use case. Snapshot allows organizations to use a customisable solution and requires little effort from the organizations to set up. If you want to explore the most active spaces, Snapshot’s biggest integrators or proposal and voting details have a look at the Snapshot dashboard on Dune.
It’s free to use.
Thanks to its technical setup, voting on Snapshot can be performed off-chain and without any gas fees. This helps organizations increase governance participation in their communities and reward users for voting through plugins such as POAP.
It’s fully open source.
The codebase is fully open to the public and provides a trustless environment which is essential to the governance process. Anyone can view and audit the logic behind Snapshot’s voting system. Moreover, the data is stored in a decentralized manner off-chain and can be viewed, audited, or replicated by anyone at any given time.
First of all, any action on Snapshot requires users to connect to the platform with their wallet. At the moment Snapshot supports several wallets, including MetaMask, WalletConnect and Coinbase Wallet.
Voting can be conducted thanks to the three main elements of the platform’s structure: spaces, proposals, and votes.
Organizations and projects can create spaces, which you can think of as their profiles on the platform. To do so, they need an ENS name, which is used as a space identifier and allows users to access its page on Snapshot, for example https://snapshot.org/#/balancer.eth.
Space controller and admins, if they are defined, have the ability to define a custom voting setup which includes:
assignment of different space roles for the space (admins, moderators, authors),
a selection of voting and validation strategies,
quorum required for proposals to pass,
plugins that extend Snapshot’s core functionality,
and more.
Once the space has been created, the eligible users (as per space settings) can create proposals with one of the available voting systems, i.e. single choice voting, weighted voting or approval voting. You can learn more about the different solutions in Snapshot’s documentation.
Community members who fulfill the criteria (defined by the validation strategies selected for the space) can then cast their votes. The individual voting power is calculated on the basis of the voting strategies that define specific rules, for example checking for the balance of a specific ERC20 token or an ownership of a NFT token.
Why “Snapshot”?
Voting power is calculated at the snapshot of proposal’s creation. It means that if you acquired tokens after the proposal has been created they won’t be taken into account when calculating your voting power. This is where Snapshot’s name is coming for as this is the fundamental feature of the voting process on the platform.
The outcome of the proposal is calculated on the basis of the chosen voting system. Do not mistake it with the voting strategy though! While voting strategy is calculating the individual voting power of a voter, voting system is used to calculate the result of the proposal. Let’s have a look at the example of the weighted voting system.
Each user can spread their voting power across any number of choices, from one to all. Their voting power will be divided between their chosen options according to how much weight they attribute to each option by increasing or decreasing the voting power fraction.
What happens next? If a proposal has passed it is up to the DAO itself to execute it, as Snapshot is not involved in the actions taken by the organization.
Some of the Snapshot spaces are using SafeSnap, a Safe plugin which enables a trustless on-chain execution with the multi-sig account. As this topic deserves a separate article, I’d recommend you to read about it here.
If you are curious about how Snapshot looks like from the technical perspective, read on!
Snapshot is a protocol which combines multiple services in order to provide a seamless experience for its users. All repositories are open-sourced and can be viewed and audited by anyone at https://github.com/snapshot-labs.
The below wireframe gives a top level overview of the platform’s architecture:
Snapshot's infrastructure is designed with three main layers:
User facing: frontend application accessible at https://snapshot.org
Logic: backend server orchestrating the work of multiple services
Data: various storage solutions persisting information off-chain
Snapshot’s interface is a Vue.js application built with Typescript. All the actions (i.e. creating a new space, proposal or voting) are possible thanks to the implementation of Snapshot.js client, a JavaScript library available for anyone to use. Whenever a user wants to perform a specific action, for example cast a vote, it triggers a message signature request in user’s wallet.
The message is then sent to the backend service - Snapshot Sequencer.
The core element of the backend infrastructure is an Express.js server - Snapshot Sequencer. It is responsible for receiving, verifying and ingesting the information incoming from Snapshot’s UI or other applications which integrated Snapshot in their infrastructure. It also communicates with the Score API which is calculating voting power of users and lastly, Sequencer orchestrates the process of persisting the data off-chain and sends a response back to the UI. The response includes a receipt, which is a proof that user’s action was approved and registered in the protocol.
What does it mean though?
The receipt is an Ethereum signature issued by the Sequencer which holds a private key. If you are familiar with how asymmetric cryptography works, or in other words how thanks to your private key you are the only person that can trigger transactions from your wallet, you can apply this logic to the receipt. If you are still not sure what private key is, let’s have a look at its definition from Investopedia:
A private key is an alphanumeric code used in cryptography, similar to a password. In cryptocurrency, private keys are used to authorize transactions and prove ownership of a blockchain asset.
source: https://www.investopedia.com/terms/p/private-key.asp
Now, as Sequencer is using its private key to issue an Ethereum signature, it means that it can be easily proven and any potential censorship attempts can be uncovered. This allows for a trustless process and its transparency along the way.
Last but not least, why “Sequencer”? The service’s name is coming from one of its most important features. Each action approved by it is stored with an auto-incremented ID, which means that anyone can replay the entire history of actions taken on Snapshot in the correct order.
As I mentioned before the individual voting power depends on the selection of voting strategies used by a specific space. In technical terms a strategy is a JavaScript function that returns a score for a set of addresses. You can find them all here. At the moment or writing this article there are 427 voting strategies available on Snapshot. Some of the most commonly used are:
If none of them is addressing the needs of your organization, it is possible to create a new custom strategy by following this process.
Spaces can also select a validation strategy - a JavaScript function which will evaluate if a user is eligible to perform a specific action: create a proposal or cast a vote. A validation strategy is a JavaScript function that returns a boolean (true or false) for the connected account. What does it check? The possibilities are unlimited. It can use a combination of existing voting strategies, check how many POAPs an account owns or measure the on-chain activity of the account in order to assess if the account is a bot or a real human. All the existing voting validations can be found here and the collection can be enriched by the community by following this process.
The primary purpose of the Score API is to calculate the voting power of individual addresses at a specific block height. It achieves this by using on-chain data retrieved directly from EVM archive nodes or a subgraph, along with a selection of one or more strategies. In addition, the Score API is also responsible for validating addresses using validation strategies.
The Score API relies on a variety of archive nodes to ensure reliability and accuracy in data retrieval. A full list of supported nodes can be found here. It is compatible with all EVM-based blockchain networks, which allows it to work with popular chains like Ethereum and Arbitrum.
To integrate the Score API into third-party applications, developers should use the Snapshot.js NPM package. This package simplifies the integration process and provides a consistent interface for interacting with the API.
One of most important design choices in Snapshot is the data storage solution. Storing information on-chain is very expensive and could be a big bottleneck for users to participate in the voting process - we all try to avoid costs whenever we can, right?
The alternative solution, which guarantees transparency and gasless voting, allowing anyone to view, audit and replicate the data and participate in DAOs governance without any cost, is the content addressing on IPFS. In fact, every space, proposal, vote, and user action confirmed by a signed and verified message can be found on IPFS, has a content identifier (CID) and a receipt proving the action has been validated and stored on the protocol.
Snapshot has developed a microservice called Pineapple and a corresponding JavaScript library pineapple.js to simplify data persistence to IPFS. Combination of the two ensures that the data is pinned successfully and as fast as possible.
pineapple.js exposes a pin method that takes a JSON object (representing a user action, space object, message signature, etc.) and sends it to the Pineapple microservice over HTTP. From there Pineapple uploads the JSON to multiple IPFS pinning services, such as 4everland, infura and pinata, at the same time and returns a response as soon as one of the services responds with a success. You can have a look at the most successful (fastest) providers here. Additionally, the data is also uploaded to AWS S3.
Apart from IPFS, Snapshot is also storing the information in an organized manner in an MySQL database which is exposed on a public API, Snapshot Hub. Anyone can easily query the database through the GraphQL interface.
To recap and understand the infrastructure better let’s follow the process of casting a vote:
User connects their wallet on Snapshot’s interface at https://snapshot.org.
Once connected, the user heads to a proposal’s page, selects their choice(s) and clicks Vote. A modal with the vote summary opens up with the selected choice(s), snapshot of the proposal (a block number) and the user’s voting power calculated by the Score API. If the user confirms the vote, the wallet will open up in with a request to sign a gasless message.
The payload of a signed message is sent to Snapshot Sequencer for verification thanks to the Snapshot.js library.
A crucial part of the verification step is the voting power check. Sequencer sends a request to the Score API and awaits the response with the voting power and vote validation.
After successful verification, Sequencer then triggers Pineapple to pin the message details on IPFS and inserts the details to the MySQL database.
Upon successful response from the data persisting services, Sequencer sends back a response to the Snapshot UI with the vote receipt - a confirmation of the vote and its IPFS CID.
User can see that the vote has gone through and can now share that they have voted on the proposal on selected social media platforms.
As you can (hopefully) see, Snapshot’s infrastructure is pretty straightforward and is making it easy for the voters to participate in the governance of their organizations at no cost and without any technical understanding.
Moreover, the open-source ideology of the company guarantees transparency at every step of the process and enables the contributors to extend the possible customizations for spaces, by creating new voting and validation strategies, or even the core functionalities of Snapshot by implementing new plugins.
Lastly, Snapshot’s architecture allows the voting process to be censorship resistant thanks to the Sequencer. As the Ethereum signatures are issued with Sequencer’s private key, any attempt to maliciously alter the data can be easily spotted even though the service is not fully decentralized. When it comes to full decentralization - keep a lookout for the next article about infrastructure update.
Decentralizing the Sequencer is the next step for Snapshot to fully decentralize its voting platform, which would further enhance its censorship resistance. By doing so, Snapshot will eliminate a single point of failure and allow for more decentralized decision-making. This would also increase the platform's security and resilience against attacks or attempts at censorship.
If you have any questions about the Snapshot’s technical architecture, make sure to drop a message on the Discord server or connect with Snapshot on Twitter!
Mint the Snapshot’s Technical Architecture NFT to show your support for the Snapshot’s publication on Mirror and to be notified of future updates from us!
Snapshot is a voting platform that allows DAOs, DeFi protocols, or NFT communities to vote easily and without gas fees.The tool allows high customization of the voting process to cater to the diverse needs of the users and organizations.
https://dune.com/snapshotlabs/dashboard
Where decisions get made. Snapshot Labs has 62 repositories available. Follow their code on GitHub.
No comments yet