New Default Delegate Field: Enhancing Cross-Protocol Governance Resilience

šŸ’¬ General Discussion
1

Proposal Overview

This proposal introduces the Default Delegate as a global delegation feature integrated into ENS records. The goal is to allow any wallet to assign a Default Delegate that can be referenced by all token governance protocols utilizing delegation. This provides a fallback mechanism in case the primary delegate is inactive or unresponsive, ensuring continuous governance participation and protocol stability. The Default Delegate can be set as either an Ethereum address or another ENS identifier, enhancing flexibility for users.

Motivation

The proposal addresses several critical needs:

  • Continuity in Governance Participation: In many decentralized systems, governance suffers from delegate inactivity. By enabling a Default Delegate, wallets can ensure their voting power is always represented, regardless of delegate inactivity.
  • Protocol Interoperability: The feature would serve as a standardized solution across all protocols supporting delegation. Any protocol could reference the Default Delegate, enhancing the resilience of governance across DeFi, DAOs, and other decentralized platforms.
  • Simplified Delegation Management: Allowing users to set a single fallback delegate for all protocols reduces the complexity of managing delegation settings in multiple ecosystems.

Key Features

  1. Default Delegate Field in ENS
  • Each ENS profile will include a new field: default_delegate_address.
  • The address can be either an Ethereum address or another ENS identifier, enabling flexibility in how users assign their default delegate.
  1. Cross-Protocol Compatibility
  • This Default Delegate feature can be referenced by any governance protocol that allows delegation. Protocols will integrate this feature by querying a userā€™s ENS profile for the default delegate and activating it when necessary.
  1. Use Case Scenarios
  • EOAs and Multisigs: Both externally owned accounts (EOAs) and multisigs benefit from this system by ensuring governance participation even if signers are inactive or unresponsive.
  • Automated Delegation Strategies: Users can implement cascading delegation chains where voting power dynamically transitions through multiple backup delegates based on defined conditions, such as activity levels or specific proposal types.
  • Liquid Staking: Stakers in liquid staking systems can delegate governance while staking their tokens. The Default Delegate could ensure governance power continues to be utilized even when the stakerā€™s primary delegate is inactive, unlocking the potential for integrated staking-governance redundancy-based safety solutions.
  1. Activation Conditions
  • The Default Delegate could be activated when:
    • The primary delegate has not been set, defined by the protocol.
    • The user manually triggers the transition.
    • Protocol conditions (such as inactivity thresholds) trigger the transition automatically.

Technical Implementation

  1. ENS Record Modification
  • A new default_delegate_address field will be added to ENS records. This will be an optional field where users can specify their Default Delegate.
  • The default delegate can be another ENS name or a direct Ethereum address.
  1. Protocol Query and Fallback Logic
  • Protocols query the ENS record to check for the default_delegate_address.
  • DAOs will set conditions under which governance power will automatically transition to the Default Delegate.
  • This ensures that voting power remains active, reducing governance inefficiencies.
  1. Security and Gas Considerations
  • Gas Costs: Updating the Default Delegate field will involve minor gas costs for users, similar to updating other ENS records.
  • Security: Users must carefully select trustworthy default delegates to avoid potential governance misuse. Additionally, protocols must enforce robust delegate validation to ensure governance integrity.

Governance Proposal Lifecycle

This proposal follows the standard ENS governance process:

  • Phase 1: Temperature Check: A discussion will be opened in the ENS DAO forum to gather community feedback on the proposal. [THIS DOCUMENT]
  • Phase 2: Draft Proposal: Once community feedback is incorporated, a detailed draft proposal will be posted on GitHub for further review.
  • Phase 3: Active Proposal: After refining the proposal, it will be submitted for a formal vote through the ENS governance portal.

Conclusion: Does the Default Delegate Feature Make Sense?

The introduction of a Default Delegate mechanism within ENS sets the stage for advanced delegation strategies and creates a standardized solution for improving governance participation across decentralized protocols. This upgrade fosters resilience, automates delegation processes, and enables new functionalities like cascading delegation chains and liquid staking integration, positioning ENS as central infrastructure for future governance systems.

The Default Delegate field brings significant advantages in terms of automation, governance continuity, and cross-protocol interoperability. While there could be valid concerns about usability, security, and adoption, these can be addressed with thoughtful implementation, robust user education, and careful protocol integration.

In summary, the Default Delegate offers a promising solution to a real problem in decentralized governance. With the right safeguards and community support, it could lead to more efficient governance systems and better user experiences across the Web3 ecosystem. This proposal is now open for detailed discussion and feedback from the community. Your thoughts, questions, and constructive criticisms are welcome!

1 Like
2

Like this a lot! I just did this myself, to delegate to myself =)
https://etherscan.io/tx/0xc84ba3e16c0baf406be0ff4c538205fb905789d90dbc41f5aad3250e7ea489d1

1 Like
3

Always excited to see more ENS features and fields as well as governance experimentation/furthering. However what is described above is more of an experiment around ā€œvote forwardingā€ than something ENS needs to integrate;

  • Iā€™m not sure i fully understand the idea of a ā€˜Default delegateā€™ means to a protocol;
    • If I hold ENS tokens; iā€™ve either delegated or not (and holding an ENS name or not), so, if i havenā€™t delegated then pointing to a default delegate is the same as delegating?
    • Then theres the example for other protocols; where iā€™m delegating to a user with an ENS name (with a default delegate field) - but at this point, arenā€™t i delegating to the ENS name itself and not the default delegate?
      • From initial thinking thereā€™s a bunch of edge cases where this field actually creates confusing onchain interruptions.
  • A final thought is about potential addresses with an ENS name with a default address field that holds multiple tokens with different delegation (holding ENS, OP, SCR, AAVE, etc) all in the same wallet - with different delegates for each token - how would the default delegate field interplay here?

Unsure of how this is achieved through the default delegate.

These sections all describe a future unknown world of more liquid governance and staked tokens. The proposal currently benefits professional delegates across ecosystems, creating a way for multi-protocol delegates ā€˜collectā€™ default delegation rather than encouraging protocol specific and high context delegates that might not be able to collect default delegation in the same way. Not opposed to experimentation but donā€™t think adding an ENS field as a first step makes sense here.

2 Likes
4

One approach would be to delegate to a smart account or safe that has more than one signer. This setup would allow any of the wallet accounts to vote on behalf of the smart account delegate.

1 Like
5

Iā€™m confused as to how this is supposed to work. Having a ā€œdefault delegateā€ across all DAOs a user might own tokens for seems doomed to fail, since no delegate will be active in every DAO.

1 Like
6

Appreciate the thoughtful feedback here @James! Youā€™re right that this feature does lean into ā€œvote forwardingā€ and might seem a bit out there - that said, Gnosis and Snapshot have largely solved infinite vote-forwarding (the term being used is ā€˜cascadeā€™, or cascading vote-capital accounting). The idea with the Default Delegate is mainly to help folks who havenā€™t set a DAO-specific delegate ensure their interests can still be easily represented; or self-to-self via broad EOA use. Itā€™s meant as a handy fallback rather than an override, allowing for one-stop delegation across protocols without needing to manage each one individually.

Portfolio investors and professional delegates, in particular, could benefit here by streamlining the management of multiple protocols, but not at the expense of overriding explicit delegation preferences. Weā€™re not looking to mess with righteous delegationsā€”more just ensuring that when thereā€™s no delegate specified, thereā€™s a sensible fallback option available other than those disparately and sometimes centrally managed and hosted at voting protocols or DAOs. The idea here is to position ENS as transparent and anti-capture, not facilitate dishonest or more negatively gameable governance structures.

Iā€™ll continue to build context - it was cool to see @paulofonseca already do this on the custom field above. I fully acknowledge that this adds complexity to implement for those that would use it, but a DAO or individual capable of setting it would likely be capable of making those considered trade-offs in light of the epistemic simplicity accompanies peopleā€™s sense of fairness around selecting our own representatives and backup voters with ease, whether globally or on a per-DAO basis.

image
image550Ɨ557 23.1 KB

Given Paulo proved the technical aspect readily, the ask seems to have shifted to whether ENS is capable of withstanding the ecosystem pressures that would be demanded of streamlining and hosting others delegation infrastructure, and if yes, is it valuable, onerous, or risky to do so? I donā€™t know, but the management and use of delegation registries will be an increasingly valuable service and the lift here seems to be near zero to position ENS at a global forefront. Delegation being a continuous election function will always bear risk, your feedback here goes to that and it is well considered.

Iā€™m going to consider this a chilly vibe on a temp-check, so I donā€™t plan to advance this course of action at this time as this was meant to be useful only. Thanks for the use of your forum, all feedback here and privately has been incredibly valuable and if I can pay it back more usefully, I will. Not an endorsement but Nick at Hats dropped me this which hits on similar things: x.com, created by the author of: ERC-5639: Delegation Registry.

@nick.eth you seem to fundamentally grasp the concept but are letting perfect be the enemy of useful in your assessment - having a trusted general backup that covers even some of the DAOs we vote on is more useful than not having the option to assign a backup at all, so the intent here was to responsibly establish and increase ENS utility in the advanced delegation space beyond registering Snapshot spaces, especially as more protocols are going to be distributing revenue to delegates and delegators along required-delegation lines.

Thanks all.

7

I donā€™t mean to be a damper - I just donā€™t think youā€™ve sold the use-case. I canā€™t think of anyone I would delegate my votes to across all DAOs because I donā€™t know anyone who participates in such a large variety of DAOs that it would be viable.

Iā€™d be much more inclined to get behind supporting an ENS-driven standard for delegation, covering delegate discoverability, delegation methods, etc.

2 Likes