When our team recently implemented governance for the RootstockCollective DAO, we encountered some fascinating nuances about how delegation works in OpenZeppelin’s Governor contracts. What initially seemed straightforward revealed important distinctions between account-level and token-level governance that every DAO developer should understand.

What is Delegation?

Delegation is a cornerstone mechanism in DAO governance that enables token holders to participate in decision-making, either directly or through trusted representatives. It allows accounts to transfer their voting rights while retaining ownership of their tokens, creating a flexible system for community participation.

Common Use Cases for Delegation

  • Passive Participation: Investors holding governance tokens primarily for value appreciation can delegate voting power to active community members who closely follow proposals and governance discussions.
  • Multi-Wallet Management: Users with tokens spread across multiple wallets (e.g., cold storage and hot wallets) can consolidate voting power in a single wallet for convenience.
  • Expert Delegation: Community members can delegate to subject matter experts for specific types of proposals, ensuring informed voting.

The Importance of Initial Delegation

A critical aspect often overlooked is that tokens must be delegated to have voting power. In our implementation of the stRIF contract for RootstockCollective, we modified the mint function to automatically self-delegate tokens to the minting address if no delegation exists. While this increases gas costs slightly, it ensures immediate voting capability for new token holders.

The following is a simplified snippet from the contract:

function mint(address to, uint256 amount) public {
    _mint(to, amount);
    if (_delegates[to] == address(0)) {
        _delegate(to, to);
    }
}

Understanding Account-Level Delegation

One of the most important distinctions in OpenZeppelin’s Governor implementation is that delegation operates at the account level, not the token level. This has several implications:

  • All tokens owned by an account share the same delegate
  • New token acquisitions automatically inherit the existing delegation
  • Token transfers automatically adjust delegation voting power

Voting Power Mechanics

Calculation and Timing

Your total voting power is the sum of:

  • Tokens you’ve self-delegated
  • Tokens delegated to you by other accounts

Snapshot Mechanism

Once a proposal becomes active, voting power for that proposal becomes immutable:

  • Changes in token balance don’t affect existing proposal voting power
  • Revoked delegations don’t impact previous proposal voting rights
  • New token acquisitions only affect future proposals

Example Scenario

At the submission of a proposal:

  • You own 1,000 tokens (self-delegated)
  • Others delegated 500 tokens to you
  • Total voting power: 1,500 tokens

After proposal activation, this power remains fixed at 1,500 votes regardless of:

  • Delegation changes
  • Token transfers
  • New acquisitions

Delegation Chains and Limitations

A common misconception is that delegation can create “chains” of voting power. Let’s clarify with an example:

Account A (100 tokens) → delegates to →
  Account B (50 tokens) → delegates to → 
    Account C

In this scenario:

  • Account C receives only 50 votes from B’s delegation
  • A’s 100 token delegation to B doesn’t “flow through” to C
  • Each account can only delegate voting power equivalent to their token holdings

Advanced Delegation Strategies

For DAOs

  • Implement graduated delegation limits based on reputation or stake
  • Create delegation committees for specific proposal categories
  • Establish delegation timelock periods for stability

For Token Holders

  • Consider splitting holdings between active and delegated portions
  • Regularly review delegate voting history to make sure their decisions align with your own
  • Set up delegation alerts for important proposals

Technical Implementation Considerations

When implementing delegation in your DAO:

  1. Consider gas optimization strategies for delegation changes
  2. Implement clear delegation tracking and visualization
  3. Add safeguards against delegation attacks
  4. Provide clear UI/UX for delegation management

Conclusion

Understanding delegation mechanics is crucial for both DAO developers and participants. While our implementation for RootstockCollective revealed some complexities, these mechanisms ultimately create a more flexible and participatory governance system. Whether you’re designing a DAO or participating in one, understanding these nuances will help you make more informed decisions about governance participation.