Delegation
Which Voting Strategy to choose to enable users to vote on behalf of their delegators?
Delegation enables you to delegate your voting power to another wallet. Unlike other actions in Snapshot, the delegation itself is an on-chain behavior, requiring some gas fees to execute a delegation transaction. Within this page we will be using two terms: - delegator - user who delegated their Voting Power to another address - delegate - the user who was delegated the Voting Power and can vote on behalf of others
How can users delegate their Voting Power?
Before we jump straight into the Voting Strategies setup, let's first understand how users can delegate their Voting Power to others through Snapshot.
<UPDATE FOR NEW DELEGATION UI>
Voting Strategies
In order to take the delegated Voting Power into account, your space has to use one of the delegation Voting Strategies.
If the delegation-based Voting Strategies are not set for your space, even if users have delegated their VP or are delegates themselves, their Voting Power will be calculated only on the basis of their own assets. This means 👉 Delegation will not work.
In Snapshot, based on whether the delegated power can be taken back by the delegators when they vote, there are two main delegation strategies:
with-delegation- the delegator cannot vote, only the delegate can participate in votingdelegation- allows the delegator to vote despite having delegated their Voting Power
Let's have a look at both in detail:
This strategy is a combination of delegation + own Voting Power (if not delegated to anyone), moreover, it prevents the delegators from taking back their delegated VP.
By using this strategy, one can no longer vote if he delegated to another one, and the delegatee's voting power will be his own VP + delegated VP.
cannot vote on proposals if this strategy is used in the Space and if they have delegated their VP to another address (for the current space or all spaces). If delegators wish to participate in voting themselves, they have to revoke their delegation for the current space or all spaces before the creation of the proposal.
The sub-strategies are used to define the source of own VP and delegation.
Strategy setup
Note that you can pass the **delegationNetwork**as the optional parameter so that the strategy can read delegation from one network and Voting Power from other networks.
This is useful when the space has multiple strategies across chains and wants to enable delegation for all the relevant tokens.
The space can specify the same delegationNetwork in all strategies so users will only need to delegate once in one network instead of delegating respectively on each chain to have all vp delegated
You can test it out in the Playground on Snapshot:
This strategy returns the delegated Voting Power only.
In order to count delegate's full Voting Power including their own holdings and the delegation, you need to set up regular strategies for the space, like for example erc20-balance-of or balance-of-woth-thresholds.
Now, what's the deal with both delegate and delegator casting a vote?
In the delegation strategy, if A delegates to B and both of them vote, then the delegated voting power is not calculated. Only the vote of A will be calculated.
The vote of B will be counted if A does not vote.
It can include a list of sub-strategies (erc20-..., erc1155-..., whitelist, etc) to calculate the user's Voting Power based on the delegation.
Strategy setup
The below example shows that the space allows YFI balance as the delegated voting power in yam.eth space.
The parameter delegationSpace is optional in space settings. By default it takes delegations of current space.
However, if you're testing delegation in the playground, you have to specify the space ENS name to let it know from which space you're fetching one's delegation.
You can test it out in the Playground on Snapshot:
Last updated
Was this helpful?
