[DIP-40] Introducing “Split Delegation” and Optimized Voting Parameters

Abstract and Motivation

This proposal outlines a new delegation strategy, “Split Delegation”, designed to enhance decentralization and improve the efficiency of the delegation and voting process within the DAO. Split Delegation allows delegators to assign their voting power to multiple delegates without splitting the token sources (i.e., creation of dedicated addresses for each delegation target) and allows for cascading delegation (delegate on behalf of someone else)

This initiative is sparked by the need for a more flexible delegation due to increased DAO dynamics and the interest of partners to participate in DAO governance. We aim to:

  1. Increase decentralization: Reduce the concentration of voting power by providing a flexible approach to delegation, fostering a more distributed governance structure.
  2. Improve delegation efficiency and security: Enhanced efficiency and security through cascaded delegation and improved security through reduced interaction with the underlying SSV tokens.
  3. Optimize voting parameters: Implement adjustments to existing voting parameters and interfaces to ensure the new split delegation mechanism integrates seamlessly and efficiently with current DAO operations, and existing DAO parameters and guidelines become more transparent and enforceable.

This proposal seeks to approve the implementation of Split Delegation and the necessary adjustments to the voting parameters to support this new functionality.

Proposal Particulars

  • Abstract and Motivation
  • Proposal Particulars
  • Split Delegation
    • Upgrading from existing Delegation Registry
    • Tooling Upgrade
      • Karma Grant
      • Snapshot Subscription
    • Mechanics and Effectiveness
    • Optimize Voting Parameters

Split Delegation

The DAO aims to upgrade the existing delegation strategy and the contracts used to a so-called “Split Delegation”, a general-purpose delegate registry with the following relevant features:

  • Delegate to multiple addresses from a single EOA or Smart Contract (by specifying the percentage of vote-weights for each).
  • Cascading delegations (Delegate A → Delegate B → Delegate C = Delegate C’s total voting power = A + B + C)
  • Expiring delegations
  • Automatic vote weight adjustment based on token balance changes.
  • Delegation revocation at any time.

For this, the DAO proposes to use split delegation developed and deployed by Gnosis Guild alongside the current delegation implementation. The contract is battle-tested, used by prominent DAOs like the Safe DAO, and audited.

Upgrading from existing Delegation Registry

Split-Delegation lives side-by-side with the current delegation strategy (hereinafter “v1”) and can be used simultaneously with v1. This means that delegations made with v1 and Split-Delegation will both be used when calculating total vote power. Delegation through v1 will remain unaffected. The DAO will continue to support v1 delegation.

The DAO will migrate its own delegation program, as defined in DIP-25, to split delegation over time. The DAO will also recommend upgrading to split delegation to other larger entities. It’s up to the entity to decide how to delegate.

For the avoidance of doubt, there is no change in the “1 token, 1 vote” principle by adding any new strategy or implementation of Split Delegation.

Tooling Upgrade

Karma Grant

To ensure accurate representation of the DAO’s governance dynamics, the SSV Grants Committee should allocate funds from its grant budget to negotiate and execute a grant agreement with Karma for the implementation of a feature that indexes and displays the total voting power across both the current v1, still-supported delegation mechanism and the new split-delegation within the Karma platform. This feature must ensure that the aggregated voting power is correctly reflected in Karma’s API as well as in all relevant user interface sections. Importantly, the delegation UI flow shall remain limited to the current v1 delegation strategy, while split delegation will not be accessible through the UI, but through direct smart contract interaction.

Snapshot Subscription

In order to support all presented delegation scenarios, it is necessary to upgrade the SSV DAO’s Snapshot space to the pro tier. To facilitate this, the SSV DAO should allocate 6,000 USDC annually from its Grants budget and assign these funds to the SSV Foundation, which will be responsible for subscribing to the required plan with Snapshot.org. Furthermore, should the cost or tier of the necessary subscription change in subsequent years, the allocated budget shall automatically adjust accordingly, with the amount to be requested by the SSV Foundation through a signed message.

Mechanics and Effectiveness

Based on the above abstract and motivation, the following changes shall be made to integrate Split Delegation into the DAO governance framework:

  1. Snapshot Strategy Upgrade: The existing delegation strategies will be adjusted to support Split-Delegation following the documentation here. This will involve modifying existing strategies and their parameters. It will also result in new strategies being deployed.
  2. User Interface Modifications: The DAO’s Karma user interface will be updated to allow:
  • View the total voting power across both delegation strategies.
  • View who delegated to whom.

This change aims to be effective immediately after the passing of this vote, with development and deployment scheduled to begin promptly to ensure a smooth transition. The initiative shall be overseen by the Master of Coin in close collaboration with the SSV Foundation. The community shall be informed and introduced to the new Split-Delegation once fully tested and available.

Optimize Voting Parameters

To ensure the optimal functioning of the DAO with Split Delegation and maximum transparency on votes, the following adjustments to voting parameters are proposed:

  1. Quorum Requirement: The minimum required quorum and its progress shall be made observable and visually indicated on snapshot per each vote by introducing a quorum tracker.

  2. Voting Guidelines: The standard voting guidelines as defined in the voting guidelines for proposals shall be set as default and enforceable settings on Snapshot if technically possible. This includes the minimum voting duration and other parameters.

  3. Continuous Improvement: The goal is to make DAO-defined voting parameters enforceable, transparent, and observable. Governance Parameter enforcement and UI features shall be frequently visited and updated under the discretion of the Master of Coin and the multi-sig.

All adjustments above will be communicated publicly and will undergo a thorough review process by the Master of Coin before final implementation.

For avoidance of doubt, the governance guidelines and parameter values themselves remain unchanged and are always subject to a DAO vote.

1 Like

What does “cascading delegation” solve?

I am feeling cautious about it, because it can make things opaque: I mean to delegate to phiz, because he’s super; but then actually end up with moxie.

If a delegate wants to stop engaging, being able to expire their delegations seems better.

I can see value in saying “I delegate to A and B - if A stops being active, then use B”. But even that is niche.

1 Like

agreed. nothing wrong about keeping things as simple as possible, imho.

Hello @flo
Hello @Yorick

Thank you for your feedback. To be honest, Cascading Delegation was not the primary reason we explored this topic. Our main interest lies in the delegation to multiple addresses from a single EOA (Externally Owned Account) or Smart Contract.

The Gnosis Contract/API we intend to use offers additional features, but currently, there are no known use cases for them, and we do not plan to actively promote these features. In fact, the list of features included in our proposal is a direct copy from their documentation.

We will check with the team to see if we can disable some functionalities, but I doubt it will be possible, as doing so could complicate matters. We’re looking into it.

Even if all features go live, the Foundation and MoC will certainly monitor the situation to assess whether these features are being utilized or if they are being used in unexpected ways.

Thank you!

Thanks for the feedback @Yorick @flo :folded_hands:

What does “cascading delegation” solve?

Cascading delegation can provide some security/operational improvements such as delegating to a “delegation manager” address. That way you can avoid having to sign multiple times from a sensitive address. Together with split delegation you could imagine a dedicated delegation committee or similar setups.

The feature is definitely something to keep in mind for delegators.. but trust assumptions do remain the same e.g. If Phiz wanted to let Moxie vote on their behalf this could currently happen out of protocol, through dm or similar.

But yes likely a good idea to keep an eye on your delegates actions, I would say that’s true regardless :man_shrugging:. As usual it’s always possible to overrule a delegates vote (while a vote is ongoing) or revoke delegation.

1 Like

Voting is now live :vertical_traffic_light:

https://snapshot.box/#/s:mainnet.ssvnetwork.eth/proposal/0x15774ff8818d7b471b82aa0cde141f549221e07a726ef48695dec6814f97b909

@fod
@spookyg
@derfredy
@h.m.23-0neinfra
@markoinether
@axblox
@flo
@thomasblock
@yuting
@damon
@lemmagov
@llifezou
@monitorssv
@sigmaprime
@kenway
@hashkeygov
@Ethernodes
@p2pgov
@chainupgov
@kiln
@Allnodes