Abstract
This proposal updates the DAO’s delegation framework to enhance decentralization, simplify operations, and combat voting fatigue.
By implementing Auto-Delegation, the DAO simplifies and automates operations and expands outreach to external members to grow the quality voter cohort.
As thresholds are met, locked SSV tokens will progressively unlock to fund incentives, cover expenses, and reduce emissions.
The proposal also introduces refined, transparent Community Scoring, the inclusion of Ethereum Communities outside of SSV, and a dedicated Delegation Portal UX/UI Grant to streamline the delegation interface.
Proposal Particulars
- Abstract
- Proposal Particulars
- Auto-Delegation
- Delegation Capital Unlock
- Delegated Policy Authority
- Scoring Updates
- Common Provisions
- Grandfathering and Transition
- Delegation Portal UX/UI Grant
- MC Delegate Removal Procedure
- Appendix 1: Scoring Specification
If this proposal passes, the following will be implemented:
- Enable Auto-Delegation to improve delegation efficiency by allowing delegators to assign voting power via the DAO to multiple delegates automatically.
- Unlock SSV tokens powering the current Delegation program in tranches when externally auto-delegated voting power hits certain thresholds.
- Update the Community Score to better reflect commitment and transparency and increase the number of delegates.
- Include members from other Ethereum Communities using the HighSignal Score across selected communities to increase outreach.
- Provide a UI/UX grant to build a Delegation Portal to support the proposed changes.
Auto-Delegation
Using “Split Delegation,” as technically implemented in DIP-25, the DAO itself can become the target of delegation to further distribute externally assigned voting power and voting power held by the DAO directly to delegates percentage-wise and automatically (hereby called “Auto-Delegation”).
Each cohort allocation is a target percentage of total available auto-delegatable voting power, scaling the program with participation. The following auto-delegation cohort allocations apply:
| Cohort | % of Auto-Delegation |
|---|---|
| SSV Community (Auto-Delegated by Community Score) | 45% |
| Verified Operators (Operator Committee) | 25% |
| Professional (SSV Foundation) | 10% |
| Grant Recipients (Grants Committee) | 15% |
| Ethereum Community (Auto-Delegated by HighSignal Score) | 5% |
| Total | 100% |
Selection of delegates under the SSV and Ethereum Community cohorts will be algorithmically determined by the proposed scoring and the resulting leaderboard, with no manual adjustments other than a removal by the MC under the Common Provisions, while all other cohorts are determined by the delegated policy authority for each responsible committee.
Delegation Capital Unlock
The DAO’s initial allocation of 150’000 SSV under DIP-25 for the community, verified operator, and grantee cohort is partially released back to the DAO’s treasury in equal tranches, unlocked progressively as Auto-Delegation reaches defined thresholds.
Auto-Delegation reaches its threshold when SSV or cSSV holders delegate their voting power to the DAO’s auto-delegation Safe wallet, measured as the absolute amount of auto-delegated cSSV + SSV on the first day of the following month.
On every 1st MSIG batch, the Master of Coin checks the auto-delegated amount and triggers the tranche release if thresholds are met.
A permanent floor of 50’000 SSV tokens is retained in the delegation program at all times as a base that the DAO always delegates directly via its own auto-delegation.
If the absolute number of auto-delegated tokens falls below the threshold that unlocked the most recent tranche by the same measurements, the DAO tops the program back up to the level of the recent tranche.
| Tranche | Auto-Delegation trigger (cSSV + SSV tokens) | Unlocked SSV tokens |
|---|---|---|
| 1 | 78000 | 20000 |
| 2 | 99000 | 20000 |
| 3 | 114000 | 20000 |
| 4 | 132000 | 20000 |
| 5 | 150000 | 20000 |
Delegated Policy Authority
If this proposal were to pass, the following authority is granted:
-
Policy Authority:
- The Operator Committee (OC) and the Grants Committee (GC) will each be granted the policy-making authority to define their delegate selection and removal for the cohort they manage based on a self-imposed, published framework.
- The SSV Foundation’s published framework for professional delegates remains unchanged from DIP-25.
-
Published Framework: Each committee must establish and publish a framework to select, nominate, rotate, and measure delegates, and report its selections:
- Any such policy must be published and voted on by a majority of the respective committee.
- The Grantee and the Verified Operator Cohort must have a minimum of 5 non-overlapping delegates each, nominated at any time.
- Acting committee members cannot be selected as targets by any committee delegation policy.
- The Committee’s delegate selection must be submitted at most once a month to the MC no later than the 1st of the following month. If none is submitted, the current selection remains active.
- Within each cohort, voting power is allocated equally and cannot be overridden by policy, save for a removal by the MC under the Common Provisions.
Scoring Updates
It is proposed to replace Karma Score with a new SSV Community Score (“Score”).
The new Score remains normalized to 0–100, but updates its calculation based on four independent, auditable pillars:
| Pillar | Measures | Source | Weight |
|---|---|---|---|
| Community Contribution | Contribution quality across Discord + Forum | HighSignal (app.highsignal.xyz) |
3 |
| Token Holdings | Skin-in-the-game cSSV + SSV holdings over time | On-chain balances | 3 |
| Snapshot Participation | Recent vote participation | Snapshot | 10 |
For the out-of-band Ethereum Community Cohort, the score is taken 1:1 from HighSignal for the selected communities, and doesn’t impact the general community scoring:
| Pillar | Measures | Source | Communities |
|---|---|---|---|
| Community Contribution | Discord + Forum + other quality participation across the non-SSV Ethereum Communities | HighSignal (app.highsignal.xyz) | Lido, Ethstaker, Rocketpool, Lighthouse, Eigenlayer |
Common Provisions
The following provisions apply to the Community and the Ethereum Community cohorts:
- SSV tokens in the Immunefiy Bug Bounty Vault delegate their SSV voting power to the auto-delegation pool, but do not affect the calculation of the Auto-Delegation trigger policy or the permanent SSV floor, and do not contribute to the unlocking of delegation capital.
- Auto-delegation to the SSV Community cohort will occur proportionally across all addresses with an SSV Community Score of 20 or greater.
- Auto-delegation is capped to 500’000 voting power. Excess delegated voting power will be voided and will not increase the cohorts’ and individual entities’ voting power.
- Auto-delegation to the Ethereum Community cohort will happen proportionally to all published high-signal users with a signal strength of mid or high who have their address shared with the SSV project on HighSignal or have made their address public.
- Delegation happens independently of the completion of any delegation profile as long as the required minimum score is reached.
- Addresses explicitly indicating they wish to opt out via a signed message are exempt from any delegation.
- Acting members of any DAO committees identified by the governance addresses are no longer exempted from delegation and are scored as any other member.
- A person may receive auto-delegated voting power under one cohort only. Membership of a cohort disqualifies that person, and any address it controls, from receiving auto-delegated voting power under any other cohort. Where a person would otherwise qualify under more than one, the cohort with the higher per-delegate allocation prevails.
- No connected person of a delegate may receive auto-delegated voting power under a cohort other than that delegate’s. A person is connected where, in the reasonable determination of the Multi-Sig Committee (“MC”), they are the same person as the delegate or under common control with it, an employee, officer, director, partner or contractor of the delegate or of an entity under common control with it, immediate family of the delegate, or acting in concert with the delegate on delegated voting power. A commercial, grant, operator or service relationship alone is not a connection.
- The MC may undelegate from any delegate, in any cohort, where it determines that either provision above is breached. The delegate remains ineligible for auto-delegation until the MC resolves otherwise. Voting power delegated directly by token holders outside Auto-Delegation is unaffected.
- The possibility for token holders to delegate their SSV or cSSV voting power directly to any delegate without using Auto-Delegation remains intact.
- For optimal operations, the Multi-Sig Committee (MC) is free to aggregate and organize funds across the DAO’s various Safes to maximize efficiency and align with the general treasury management practice introduced in DIP-52.
- The MC shall register matching ENS addresses in line with DIP-55 to make the resulting structure easily identifiable and interactions more secure.
Grandfathering and Transition
To provide a smooth transition between the old Karma-based scoring and the new scoring model, the following applies:
- A snapshot of the current leaderboard and cohort allocation is taken from Karma on the last day of the previous month in which this proposal passes.
- The selected delegates, as per the snapshot taken across all cohorts, shall remain active and unchanged, regardless of their voting participation under the old delegation system, until new policies are published and all systems are fully functional.
- Collected profile information from the Karma snapshot (such as mapping of the address to forum or Discord handles or other information) shall be seeded into the new system as static information and remain there until actively updated by the owner of the entity.
Delegation Portal UX/UI Grant
The Grants Committee shall spec and find an implementer to implement a Delegation Portal that supports all of the requirements above and enter, through the SSV Foundation, into an agreement under the current grants micro-grant regime.
MC Delegate Removal Procedure
Any MC member may call a removal vote. Votes are cast as under DIP-2, by signing a message reading “Yes” or “No” from the member’s designated wallet, and five (5) of nine (9) are required. The MC may act on its own initiative or on referral, need not investigate, and may decide on the information available to it. Each removal is published in the next monthly report with the cohort and the ground relied on. A removed delegate has no claim to the voting rights previously delegated to it.
Appendix 1: Scoring Specification
| Dial | Default | What it does |
|---|---|---|
| Community weight | 3 | How much community contribution counts |
| Holdings weight | 3 | How much stake counts |
| Votes weight | 10 | How much voting counts |
| Dial | Default | What it does |
|---|---|---|
| HOLD_REF | 10,000 | The holding that earns a perfect 100 |
| p | 0.5 | Whale flattening (square root) |
| T | 90 days | How much balance history is averaged |
| H | 90 days | How long a vote takes to lose half its weight |
| N | 10 | How many recent proposals count |
| Symbol | Meaning |
|---|---|
| w_i | weight of pillar i — 3, 3, 10 |
| c | HighSignal score, already 0–100 |
| b_t | SSV + cSSV held on day b_t is the average over T days (the TWAB) |
| Rp | reference holding 10,000 and concavity 0.5 |
| v_j | 1 if they voted on proposal j, else 0 |
| a_j | age of proposal j in days; H is the half-life |
. Also, best to set up your 