Delegation in DAO contracts refers to the ability of token holders to delegate their voting power to another address or entity. This allows token holders to participate in the decision-making process of the DAO without having to actively vote on every proposal themselves.

MolochV3 and Governor style DAO contracts, by default, handle delegation the same. Token holders can transfer their voting power to another account while still holding the tokens in their account. Delegation can be revoked or changed at anytime.

On a more technical level, this delegation is controlled by the actual token contract (flavor of erc20), this contract keeps track of a users balance and who they have delegated to, themselves or another account. Delegation can be changed at any time, and the voting power for every delegate is recorded in a “snapshot” at the start of each proposal. This is probably the most simple implementation and how most DAOs work today. I’ll go into some of the flavors of delegation later.

Delegation can be beneficial for token holders who may not have the time or expertise to actively participate in the decision-making process of the DAO. By delegating their voting power to a trusted delegate, they can still have a say in the DAO's decisions while freeing up their own time and resources.

Delegation is pretty cool… but there are problems

“Set it and forget it” mindset - many times (maybe most times) people use delegation as a completely passive way to interact with the DAO. So, delegate your tokens and then never check in on the delegate. For delegation to work best, all holders should actively be involved with their delegate and how they are representing their “constituents”

Protocol politicians - Professional delegates get really good at the campaigning and politicking. Take a look at some of the larger DAOs, you will see many of the same faces as top controlling delegates. These cross protocol “politicians” and whales end up as gravity wells of power. It equates to something like 10 people that have the most power across all the big DAOs.

Rot and Entropy - these two above problems combined. People initially set delegation to a well known and trusted protocol politician, and then walk away. That delegate changes their platform or disappears altogether. Locking up large chunks of influence in an inactive, or potentially evil, account.

DAOhaus Summoner

In Moloch V3, the voting tokens (Shares) are non-transferable, and the DAO always has control over transferability through proposal or a special Shaman role. Even though the token is non-transferable by default, token holders can always delegate. Also the shares token contract, the one that handles delegation, is upgradeable. The upgradability adds the flexibility for the DAO, through proposal, to upgrade their delegation flavor or turn off upgradeability all together, makeing it immutable. These are the default setting in the DAOhaus summoner, the Moloch V3 contract is flexible though, a different summoner may use a different default delegation flavor. try it here

https://summon.daohaus.club/

PublicHAUS

PublicHAUS is the DAO that manages the DAOhaus protocol, parameters, contracts, ecosystem treasury along with the general strategy and mission. It uses this delegation in a few ways. It has a form of a more liquid delegation with 2 different proposal types: One for direct on chain execution (delegates) and another proposal type to handle more nuanced decisions around mission (objective setting, wayfinding, and retroactive rewards). This second proposal type has delegation turned off, so members can and should directly participate. The other thing PublicHAUS does is maintain a curated list of recommended and verified delegates (Champions), this is a onchain registry managed by current delegates.

https://publichaus.club/

So that is kinda the baseline for delegation but it is flexible and there are a lot of different ways it could be extended or changed. There are a bunch of interesting experiments around this, here are a couple examples:

Liquid delegation

This allows a token holder to delegate to multiple different accounts. So you could delegate 10% to one account and 90% to another. https://github.com/voteagora/liquid-delegator

Flexible Voting

Allows transfer of tokens to a whitelisted “vault” (something like a yield barring defi protocol). But still allows delegation by the original holder while tokens are locked up. https://github.com/ScopeLift/flexible-voting

Delegation Forwarding

This is a request by a lot of the protocol politicians, mainly to avoid the rot problem. For example Delegates practice sec ops and would like to forward their current delegation to a new address. Or they want to quit, or go on vacation, or get hit by a meteor. There are some problems with this though, for one this may reduce transparency, ie: you delegate to someone and they then forward delegate to another address (history lost). Transparency could be addressed through a chain history of all moves but this greatly increases complexity.

Delegation Decay

With this delegation slowly decreases over time without some action to “recharge” it. This might keep token holders more engaged with their delegation choice, so they get the most value out of it as possible.

**Quadratic Liquid Delegation **In this delegating to a single address cost more. This one is susceptible to the Sybil problem. (Many interesting delegation flavors are killed by Sybil)

Vesting Delegation

This type of delegation vests over time, so the longer the member is participating the more voting power they get. One way to do this does not have to equate to the member getting more actual Shares in the DAO (maybe until some cliff at least) because it could be a proxy account that just delegates power, and may after some condition actually release the Shares. This is an idea i might dive into deeper in a follow up article “The Power Purse”

Delegation in DAO contracts refers to the ability of token holders to delegate their voting power to another address or entity. This allows token holders to participate in the decision-making process of the DAO without having to actively vote on every proposal themselves.

MolochV3 and Governor style DAO contracts, by default, handle delegation the same. Token holders can transfer their voting power to another account while still holding the tokens in their account. Delegation can be revoked or changed at anytime.

On a more technical level, this delegation is controlled by the actual token contract (flavor of erc20), this contract keeps track of a users balance and who they have delegated to, themselves or another account. Delegation can be changed at any time, and the voting power for every delegate is recorded in a “snapshot” at the start of each proposal. This is probably the most simple implementation and how most DAOs work today. I’ll go into some of the flavors of delegation later.

Delegation can be beneficial for token holders who may not have the time or expertise to actively participate in the decision-making process of the DAO. By delegating their voting power to a trusted delegate, they can still have a say in the DAO's decisions while freeing up their own time and resources.

Delegation is pretty cool… but there are problems

“Set it and forget it” mindset - many times (maybe most times) people use delegation as a completely passive way to interact with the DAO. So, delegate your tokens and then never check in on the delegate. For delegation to work best, all holders should actively be involved with their delegate and how they are representing their “constituents”

Protocol politicians - Professional delegates get really good at the campaigning and politicking. Take a look at some of the larger DAOs, you will see many of the same faces as top controlling delegates. These cross protocol “politicians” and whales end up as gravity wells of power. It equates to something like 10 people that have the most power across all the big DAOs.

Rot and Entropy - these two above problems combined. People initially set delegation to a well known and trusted protocol politician, and then walk away. That delegate changes their platform or disappears altogether. Locking up large chunks of influence in an inactive, or potentially evil, account.

DAOhaus Summoner

In Moloch V3, the voting tokens (Shares) are non-transferable, and the DAO always has control over transferability through proposal or a special Shaman role. Even though the token is non-transferable by default, token holders can always delegate. Also the shares token contract, the one that handles delegation, is upgradeable. The upgradability adds the flexibility for the DAO, through proposal, to upgrade their delegation flavor or turn off upgradeability all together, makeing it immutable. These are the default setting in the DAOhaus summoner, the Moloch V3 contract is flexible though, a different summoner may use a different default delegation flavor. try it here

https://summon.daohaus.club/

PublicHAUS

PublicHAUS is the DAO that manages the DAOhaus protocol, parameters, contracts, ecosystem treasury along with the general strategy and mission. It uses this delegation in a few ways. It has a form of a more liquid delegation with 2 different proposal types: One for direct on chain execution (delegates) and another proposal type to handle more nuanced decisions around mission (objective setting, wayfinding, and retroactive rewards). This second proposal type has delegation turned off, so members can and should directly participate. The other thing PublicHAUS does is maintain a curated list of recommended and verified delegates (Champions), this is a onchain registry managed by current delegates.

https://publichaus.club/

So that is kinda the baseline for delegation but it is flexible and there are a lot of different ways it could be extended or changed. There are a bunch of interesting experiments around this, here are a couple examples:

Liquid delegation

This allows a token holder to delegate to multiple different accounts. So you could delegate 10% to one account and 90% to another. https://github.com/voteagora/liquid-delegator

Flexible Voting

Allows transfer of tokens to a whitelisted “vault” (something like a yield barring defi protocol). But still allows delegation by the original holder while tokens are locked up. https://github.com/ScopeLift/flexible-voting

Delegation Forwarding

This is a request by a lot of the protocol politicians, mainly to avoid the rot problem. For example Delegates practice sec ops and would like to forward their current delegation to a new address. Or they want to quit, or go on vacation, or get hit by a meteor. There are some problems with this though, for one this may reduce transparency, ie: you delegate to someone and they then forward delegate to another address (history lost). Transparency could be addressed through a chain history of all moves but this greatly increases complexity.

Delegation Decay

With this delegation slowly decreases over time without some action to “recharge” it. This might keep token holders more engaged with their delegation choice, so they get the most value out of it as possible.

**Quadratic Liquid Delegation **In this delegating to a single address cost more. This one is susceptible to the Sybil problem. (Many interesting delegation flavors are killed by Sybil)

Vesting Delegation

This type of delegation vests over time, so the longer the member is participating the more voting power they get. One way to do this does not have to equate to the member getting more actual Shares in the DAO (maybe until some cliff at least) because it could be a proxy account that just delegates power, and may after some condition actually release the Shares. This is an idea i might dive into deeper in a follow up article “The Power Purse”