How to Integrate Social Tokens with Snapshot Voting

Social tokens are a class of digital assets that represent membership, reputation, or influence within a community. Unlike fungible governance tokens, they are often non-transferable (soulbound) or have transfer restrictions to align ownership with participation. Integrating these tokens with Snapshot—a leading off-chain, gasless voting platform—allows communities to implement governance models based on real engagement rather than mere capital. This creates more sybil-resistant and meaningful decision-making processes.

The core technical integration involves configuring a Snapshot space to read token balances from a custom strategy. A strategy is a JavaScript function that queries a data source to determine a voter's voting power. For social tokens, this typically means querying an on-chain registry like an ERC-721 contract for NFTs, an ERC-1155 for badges, or a contract with a balanceOf function for non-transferable ERC-20 tokens. The strategy returns the number of tokens a user holds at a specific block number, which becomes their voting weight.

For example, a DAO might issue a non-transferable CommunityBadge ERC-721 NFT. A Snapshot strategy to use this badge for voting would call the balanceOf function for the voter's address. If a member holds one badge, they get one vote. The strategy code, deployed to a platform like GitHub Gist or IPFS, is referenced in the Snapshot space settings. Key strategy parameters include the symbol (e.g., BADGE), the contract address, and the network (e.g., 1 for Ethereum Mainnet).

Advanced implementations can create more nuanced voting power. A strategy can calculate power based on multiple token contracts—such as combining a base social token with reputation points from a separate staking contract. It can also implement time-based weighting, like granting more power for longer-held tokens, by checking historical balances via The Graph subgraph. This flexibility allows for complex models like quadratic voting using social token balances or veto power for core contributors holding specific "founder" badges.

Before going live, thoroughly test the strategy using Snapshot's Testnet space feature on a network like Goerli. Verify that the voting power returned matches the expected on-chain state. Security considerations are paramount: ensure the token contract is immutable or governed by the DAO, and audit the strategy logic for manipulation. Successful integration decentralizes governance authority to your most engaged community members, fostering more legitimate and sustainable collective decision-making.

To begin, you must have a deployed ERC-20 or ERC-1155 token contract on a supported EVM-compatible network like Ethereum, Polygon, or Arbitrum. This token will represent your community's social currency. You will need the contract address and the ability to sign transactions from the deployer wallet, as you will need to grant voting power to Snapshot's strategy contracts. Ensure your token has a mechanism for distribution, whether through a claim site, airdrop, or bonding curve, as the token holder list defines your electorate.

Next, create a Snapshot Space for your community. Visit snapshot.org, connect your wallet (typically the same one that deployed the token), and create a new space. You will configure basic settings like the space name, avatar, and admins. Crucially, you must define a voting strategy. For a simple token-weighted vote, you would use the erc20-balance-of strategy, pointing it to your token's contract address. More advanced integrations may require custom strategies written in TypeScript.

Your technical environment should include Node.js (v18 or later) and npm or yarn. You will use these to install the Snapshot SDK (@snapshot-labs/snapshot.js) and potentially develop custom strategies or off-chain vote validation scripts. Familiarity with JavaScript/TypeScript and basic Ethereum concepts like ABI, JSON-RPC calls, and wallet signing is essential. For testing, use a testnet like Goerli or Sepolia to deploy your token and configure your Snapshot space without spending real funds.

Finally, understand the data flow. Snapshot is an off-chain gasless voting platform. When a user votes, they sign a message with their wallet, which is sent to Snapshot's hosted service or your own Snapshot Hub. The system then uses your defined strategy to calculate the user's voting power by querying the blockchain state at a specific block number. Ensure your frontend application can interact with the Snapshot API or SDK to create proposals, fetch votes, and display results.

Integrating a social token with Snapshot allows a community to use its native token for governance without paying gas fees. Snapshot is an off-chain voting platform that uses signed messages to record votes, which are stored on IPFS and indexed by the Snapshot Hub. The core integration involves configuring a voting strategy that defines which token holders are eligible to vote and how their voting power is calculated. For social tokens, this typically means using the ERC-20 or ERC-721 token standard to determine membership and stake.

The primary technical step is creating a custom space on Snapshot. A space is a dedicated governance page for your project. During setup, you define the network (e.g., Ethereum Mainnet, Polygon) and the voting strategy. For a simple social ERC-20 token, you would select the erc20-balance-of strategy. This strategy calculates a voter's power based on their token balance at a specific block number (the snapshot block). You must provide the token's contract address and, optionally, a multiplier for weighted voting.

For more complex social token mechanics, you may need a custom strategy. This involves writing a strategy contract in Solidity that implements the getVotingPower function. For example, a strategy could factor in time-locked tokens (veTokens), non-transferable badges, or cross-chain balances. After deploying your strategy contract, you reference its address in your Snapshot space settings. The Snapshot documentation provides template strategy contracts to customize.

Proposal creation can be gated using the same token rules. You can set proposal thresholds in your space's settings, requiring a user to hold a minimum number of tokens to submit a proposal. When a member votes, they sign a message with their wallet. The Snapshot relayer service then validates this signature against the strategy rules and records the vote. All data is stored decentrally on IPFS, making the process transparent and censorship-resistant while remaining free for voters.

Advanced integrations can leverage Snapshot's plugin system and Scores API. Plugins allow for custom frontends and notification systems. The Scores API lets you query the calculated voting power for any address and strategy combination off-chain, which is useful for building custom governance dashboards or verifying eligibility in external applications. This flexibility makes Snapshot a powerful tool for layering governance onto existing social token economies without disrupting the user experience.

Before going live, thoroughly test your integration on a testnet space. Use Snapshot's test instance at testnet.snapshot.org to create proposals and simulate votes. Ensure your token contract's balanceOf function or custom strategy logic returns the expected values. A successful integration empowers your token holders to steer the community's direction through a familiar, gasless voting interface, directly linking social capital to governance influence.

A Snapshot space is a dedicated page for your community's off-chain governance. It is not a smart contract but a front-end interface that uses signed messages to record votes. To create one, navigate to snapshot.org and connect your wallet. You will need to be the owner or a delegate of an ENS domain (e.g., yourdao.eth), which will serve as your space's unique identifier and web address. This domain ownership proves you control the space and is required for setup.

After connecting, click "Create a space" and enter your ENS domain. You will then configure the core settings in the Settings tab. The most critical setting is the voting strategy, which defines how member voting power is calculated. For social token integration, you will typically select the erc20-balance-of strategy. This strategy allows you to specify the contract address of your social token, and a voter's power will be directly proportional to their token balance at a specified block number.

You must also configure voting parameters that define proposal mechanics. Set the proposal threshold, which is the minimum token balance a member needs to submit a proposal. Define the quorum, the minimum percentage of total token supply that must participate for a vote to be valid. Finally, choose the voting period (e.g., 3-7 days) and the voting type, such as single-choice or weighted voting. These parameters enforce governance integrity and prevent spam.

For security, configure the admins and moderators of your space. Admins can change all settings, while moderators can only edit proposals. It is a best practice to use a multisig wallet (like Safe) as the admin to prevent a single point of failure. In the Strategies section, you will input the contract address, decimal count, and symbol of your social token. Snapshot will automatically fetch the token's ABI to query balances.

Before going live, thoroughly test your configuration using the Preview feature. Submit a test proposal and simulate voting with different wallet addresses to ensure the erc20-balance-of strategy correctly pulls token balances and that all parameters work as intended. Once verified, your Snapshot space is ready to host proposals, enabling token-weighted governance for your community.

A voting strategy is the core logic that determines voting power. For social tokens, this typically means a simple token-weighted strategy where one token equals one vote. In your Snapshot space settings, you select the strategy contract. The most common choice for ERC-20 tokens is the erc20-balance-of strategy, which checks a voter's token balance at a specific block number (the snapshot block). This prevents users from buying tokens after a proposal is created to manipulate the vote. You must provide the token's contract address and, optionally, a specific network if it differs from your space's default.

For more nuanced governance, you can combine strategies. A popular setup for social token projects is erc20-balance-of-with-delegation. This strategy respects token delegation, allowing users who have delegated their voting power to another address (like a representative) to have their votes cast automatically. Another advanced option is erc20-with-balance, which allows you to set a minimum token threshold required to vote, ensuring only committed community members participate. You can browse and verify strategies on the official Snapshot Strategies GitHub repository.

Configuration happens in the Strategies section of your Snapshot space settings. You add a strategy by providing its name (e.g., erc20-balance-of) and the required parameters as a JSON object. For a basic ERC-20 token named COMM on Ethereum, the parameters would be: {"address": "0xYourTokenContractAddress", "symbol": "COMM", "decimals": 18}. The symbol and decimals are for UI display. After adding the strategy, you can test it using the "Check" button with a sample voter address to confirm it returns the correct voting power.

It's critical to understand the snapshot block concept. When a proposal is created, Snapshot records the block number. The voting strategy calculates every voter's balance at that specific block. This means tokens transferred after the proposal is created do not affect voting power for that proposal. You can set a custom snapshot block when creating a proposal, but the default is the block number when the proposal is published. This mechanism is fundamental to preventing vote buying and flash loan attacks on governance.

For social tokens that also incorporate non-transferable elements (like Soulbound Tokens or achievement badges), you would need a custom strategy. You could use the erc721 or erc1155 strategy for NFT-based voting power, or develop a custom strategy that reads from a merkle tree or an off-chain database. Developing a custom strategy requires writing a TypeScript function that returns a voting power number, which you then deploy to the Snapshot hub. This allows for complex logic like quadratic voting based on token age or multi-token governance.

To create a proposal that uses a social token for voting, you must first define the voting strategy in your Snapshot space settings. Navigate to your space, select Settings, then Strategies. Here, you will add a custom strategy. For an ERC-20 social token, the most common configuration uses the erc20-balance-of strategy. This strategy calculates a voter's power based on their token balance at a specific block number. You must specify the contract address of your social token and the network it's deployed on, such as Ethereum Mainnet or Polygon.

When drafting the proposal, the voting system will automatically reference the strategy you configured. The key parameter is the Snapshot block number. This is the block height used to query token balances, preventing users from buying tokens to manipulate a vote after the proposal is live. You can set this manually or use Snapshot's default, which is the block number when the proposal is created. Ensure your token's contract is verified on a block explorer and that the balanceOf function is publicly accessible for the strategy to work correctly.

For more complex tokenomics, you can use multiple strategies or a custom one. For instance, if your social token employs a time-based lock-up for increased voting power, you would need a custom strategy that queries a staking contract. Snapshot supports this via plugins. You can write a custom strategy in JavaScript that fetches data from your contracts or an external API. The strategy must return a list of addresses and their corresponding voting power. Example strategies are available in the Snapshot strategy repository.

After publishing, voters will connect their wallets to Snapshot. The interface will show their voting power derived from their social token balance at the snapshot block. They can choose options like For, Against, or custom choices you define. As the proposal creator, you can monitor votes in real-time. Managing the proposal includes communicating with your community, providing context, and ensuring a fair voting period—typically 3-5 days for social token communities to allow sufficient participation.

Once voting concludes, the results are immutable on Snapshot. The outcome is determined by the standard you set, such as single-choice voting (highest votes wins) or approval voting. You should then execute on-chain actions based on the vote, which may involve a multisig transaction or a smart contract call. Integrating this process with tools like Discord or Telegram bots can automate notifications for new proposals and results, keeping your token-holding community actively engaged in governance.

A Snapshot voting strategy is a smart contract or off-chain script that defines how voting power is calculated for a proposal. By default, strategies use token balances from a single ERC-20 contract. To integrate a social token, you must create a custom strategy that queries the relevant data source, which could be an on-chain balance, a staking contract, or an off-chain API for non-transferable reputation points. The strategy's core function, getVotingPower, must return an integer representing a user's voting power at a specific block number.

Developing a Basic On-Chain Strategy

For a simple, transferable social token (like an ERC-20), you can fork and modify an existing strategy. Start with the Snapshot strategy template. The key modification is in the strategy.ts file, where you change the contractAddress and decimals to match your social token's details. After deploying your strategy contract or publishing the script, you reference it in a Snapshot space's settings using its GitHub path (e.g., myorg/my-strategy-repo) or Ethereum address.

For more complex logic, such as quadratic voting based on token holdings or voting power that decays over time, you must implement the calculation within the getVotingPower function. An example of quadratic voting power would calculate the square root of the token balance: votingPower = Math.sqrt(balance). This must be done with care to handle integer math and prevent overflow. Strategies can also combine multiple data sources, like a user's token balance and their staked amount in a separate vault contract.

Many social tokens are non-transferable (soulbound) or their primary utility is tied to off-chain actions. For these, you need an off-chain strategy that fetches data from an API. The strategy would make an HTTP call to your service, which returns a score based on user activity, contributions, or attestations. Your API must return data in the format Snapshot expects. Ensure your endpoint is reliable and publicly accessible, as Snapshot's infrastructure will call it during proposal creation and voting.

After creating your strategy, test it thoroughly on a testnet space using Snapshot's demo site. Verify that the calculated voting power matches expectations for different addresses. Once confirmed, add the strategy to your main space. Governance proposals can then be created where voting weight is directly tied to social capital, moving beyond simple token-weighted voting to more nuanced, community-aligned decision-making.

Integrating social tokens with Snapshot allows decentralized communities to use their native tokens for off-chain governance. The core mechanism involves creating a custom voting strategy that queries token balances from a designated smart contract. Snapshot supports various token standards, including ERC-20, ERC-721, and ERC-1155. The integration is permissionless; you define a strategy that specifies the contract address, the method for fetching balances (like balanceOf), and the blockchain network. This setup enables token holders to create and vote on proposals based on their holdings, without spending gas.

For a basic ERC-20 token integration, you write a voting strategy in JavaScript. The strategy fetches voter balances at a specific block number, which is crucial for preventing manipulation through token transfers during a live vote. Here is a simplified example of a strategy file (strategies/erc20-balance-of.js):

javascriptCopy
export const author = 'your-handle';
export const version = '0.1.0';
export async function strategy(space, network, provider, addresses, options, snapshot) {
  const blockTag = typeof snapshot === 'number' ? snapshot : 'latest';
  const response = await provider.call({
    to: options.address,
    data: `0x70a08231000000000000000000000000${addresses[0].slice(2)}` // balanceOf call
  }, blockTag);
  const balance = BigInt(response);
  return { [addresses[0]]: balance };
}

This function calls the balanceOf method for a voter's address. In production, you would iterate over all addresses and handle decimals.

Security is paramount when linking financial assets to governance. Follow these best practices: Use a verified contract address to prevent spoofing. Leverage block snapshots to lock balances at proposal creation, preventing vote-buying. For tokens with transfer restrictions, ensure your strategy respects vesting schedules or lock-up periods by querying the correct contract view functions. Avoid strategies that rely on centralized APIs or off-chain data sources, as these introduce trust and availability risks. Always test your strategy on a testnet or Snapshot's playground before deploying it for a live space.

Advanced integrations can involve multi-token voting (e.g., combining an ERC-20 social token with an ERC-721 membership NFT) or delegated voting via systems like ERC-20Votes or ERC-721Votes. For delegation, your strategy must query the getVotes function instead of balanceOf. Furthermore, consider the legal and community implications: clearly communicate voting power calculations, and implement sybil-resistance measures if necessary, such as coupling token ownership with proof-of-personhood verification through services like Worldcoin or BrightID to ensure one-human-one-vote principles.

To deploy your strategy, fork the official snapshot-strategies repository, add your strategy file, and submit a pull request. Once merged, you can select it in your Snapshot space settings under 'Voting Strategies'. For ongoing maintenance, monitor for contract upgrades and ensure your strategy remains compatible. Proper integration empowers your community with transparent, on-chain verified governance while mitigating common attack vectors like flash loan exploits or snapshot manipulation.

You should now have a functional VotingPowerStrategy contract that calculates voting power based on ERC-20 token balances. The final step is to deploy your strategy contract to a network supported by Snapshot, such as Ethereum Mainnet, Polygon, or Arbitrum. After deployment, you must verify and publish the contract source code on a block explorer like Etherscan. This transparency is crucial for building trust within your community, as voters can audit the logic determining their influence.

Once deployed, register your new strategy on the Snapshot space settings page. Navigate to your space, go to Strategies, and add a new entry with your contract address and the required params (e.g., the token address). You can then create a test proposal to verify the integration works correctly. Use the Voting Power debug tool on the proposal page to check that member addresses return the expected power based on their token holdings in the designated ERC20Votes or standard ERC-20 contract.

For more advanced implementations, consider extending the basic model. You could develop strategies that factor in token vesting schedules (e.g., locked tokens in a platform like Vesting Contract), delegated balances from ERC20Votes, or even a time-weighted average balance to reward long-term holders. Each requires modifying the getVotingPower function to query additional on-chain data.

The integration of social tokens with Snapshot creates a powerful feedback loop: community engagement is quantified and directly influences governance. This model is used by DAOs like Friends with Benefits (FWB) and BanklessDAO to align incentives. To dive deeper, review Snapshot's Strategy documentation and explore existing community strategies on GitHub.

Your next project could involve building a custom UI plugin for Snapshot's off-chain voting interface or integrating the voting results with on-chain execution via a Safe{Wallet} transaction. By mastering this integration, you equip any tokenized community with a robust, transparent, and flexible governance system.