Simple Summary

A standard for ranked delegated voting in DAOs that allows token holders to create ordered delegation lists and point their token votes to these lists. Voting power cascades down the list to the highest-ranked delegate who voted on a specific proposal. This improves voter participation and ensures delegated tokens are actively used without compromising user control.

Abstract

This EIP introduces a mechanism to extend token-based delegation (as in ERC20Votes) to support ranked fallback delegation. Users can assign a prioritized list of delegates to vote on their behalf. On a per-proposal basis, the system checks if the token holder voted; if not, it checks the delegates in order until it finds one who did vote. The first such delegate receives the token holder's voting power for that proposal.

The voting mechanism is compatible with single-option yes/no proposals and can integrate with ranked-choice voting schemes like Instant-Runoff Voting (IRV). The standard is designed to work with OpenZeppelin's ERC20Votes and Governor contracts.

Motivation

In DAOs such as Optimism, a vast majority of voting power is under-utilized:

• ~2.7% of OP tokens are actively delegated
• ~33% of delegates miss proposals

This leads to governance capture and apathy. Traditional delegation is fragile: if your delegate is inactive, your vote is lost. A ranked delegation system ensures votes find the most active trusted representative and reduces vote wastage.

Limitations of Existing Standards

Existing contract standards Governor.sol, Votes.sol, GovernorVotes.sol are incapable of supporting ranked delegation as-is:

1. Dynamic vote resolution during voting period
2. Multiple delegate storage per account
3. Conditional vote power transfer based on delegate activity
4. Per-proposal delegation resolution rather than global delegation

These requirements are fundamentally incompatible with the checkpoint-based, pre-calculated voting power model used by OpenZeppelin's Governor system in the following ways:

Specific Blocking Functions

ERC20Votes/Votes.sol:

• delegates() - Returns single delegate, not ranked list
• _delegate() - Overwrites delegation, no ranking concept
• _moveDelegateVotes() - Immediately transfers power
• getVotes() - Returns pre-calculated power, not dynamic

GovernorVotes.sol:

• _getVotes() - Calls token().getPastVotes() for static lookup
• Cannot override without breaking checkpoint system

Governor.sol:

• Vote counting extensions expect fixed voting power
• Proposal lifecycle assumes static delegation

Detailed Limitations

Possible Solutions

There are several delegation strategies that could address the limitations of existing standards:

Specification

WIP

Reference Implementation

See the DelegationRegistry.sol tab for the complete implementation.

Open Questions

1. Should each delegation list exist as a contract that lives at a single address or should a single registry hold all lists?
   The factory pattern costs approximately 2-3x additional gas per delegation list due to contract deployment overhead. However, it provides the benefit of maintaining ERC20Votes compatibility by giving each delegation list a unique address that can be used with existing delegate(address) functions. Storing all lists as arrays within a single registry contract centralizes management and can be more gas-efficient, but may limit flexibility and upgradability.
2. Should delegation list updates use full array overwrite or support incremental add/remove operations?
   Gas analysis shows full overwrite is more efficient for most scenarios:

   • Full overwrite wins for any changes involving 2+ delegates
   • Incremental operations only cheaper for single additions at list end (~16k gas savings)
   • Position matters significantly: adding at beginning costs ~72k gas vs ~31k at end
   • Operation cost scales with list size: 10 delegates = 42k gas, 50 delegates = 99k gas

   Conclusion: Simple full-array replacement provides better UX and gas efficiency for typical use cases.