[RFC] Delegation Increase Incentives System

[blockful]

TL;DR: ENS is safer when voting power sits with active delegates, not idle wallets. We propose a 90-day pilot that pays incentives to both active delegates and their delegators. Guardrails: (1) a time-held factor for delegators (capped at 180 days) to reduce sybils, (2) a 1 ENS minimum payout per address to avoid inefficient micro-transfers, and (3) payout caps per-delegate and per-delegator to avoid concentration and strengthen long-term capture cost.

---

Why this matters

• More active voting power raises capture cost and reduces capture risks.
• A strong base of active delegates reduces reliance on emergency mechanisms.
• We incentivise for sustained activity, not outcomes, particular vote choices, or one-time votes.

---

Proposal (Pilot v1)

Scope: 90 days, three monthly rounds.
Funding: One proposal of 90k ENS to be managed by the metagov stewards for distribution. Usage can range from 15k to 90k ENS, any remainder will be sent back to treasury after the program.
Payout cadence: Monthly, with public snapshots and distribution files.
Metric for allocation amount: Voting power increase MoM on active delegates (more that 7 votes in the last 10 proposals)

Active VP Increase	ENS Total	Dollar value*	Delegate Cap	Holder Cap
0-10%	5000	$75k	50	250
10-20%	8000	$120k	80	400
20-30%	10000	$150k	100	500
30-50%	15000	$225k	150	750
50-75%	20000	$300k	200	1000
75-100%	25000	$375k	250	1250
Above 100%	30000	$450k	300	1500

Dollar values are figurative just to give perspective of cost, at $15/ENS on Oct 21st.

Who earns?

• Active Delegates and their Delegators.

Active Delegate threshold

• An active delegate is an address that voted on at least 7 of the last 10 on-chain proposals (rolling).

---

ENS DAO Birthday Launch (November)

We propose launching the pilot in November to celebrate 4 years of ENS DAO creation, with 5 ETH of sponsored gas via delegateBySig, and a visibility campaign to bring long-time holders back into governance.

Reasoning:

1. Visibility: Tying redelegation to the birthday concentrates community focus, provides a clear “why now”, and grants social legitimacy for holders to review/update their delegate choices, especially toward active delegates.

2. Friction removal: With sponsored gas + simple redelegation flows, we can remove cost/UX friction to convert passive holders into increased attack costs. Combined with time-held weighting for the incentives, this promotes durable active voting power rather than a one-off spike.

Details

• Sponsored gas for redelegations using delegateBySig.
• Featured list of active delegates (meeting thresholds) with transparent stats.
• Progress dashboard: live redelegations, active VP growth, and countdown to Round distributions.

---

How rewards are split

Let R be the monthly reward pool (in ENS).

1) Delegate pool — 10% of R

• Split among Active Delegates, proportional to the voting power they actually cast that month.
• Per-delegate cap: min(delegate_reward, 1% of R).
• Excess from caps is redistributed pro-rata within the delegate pool to those still under cap (repeat until no one breaches the cap).

2) Delegator pool — 90% of R

• Split among delegators to Active Delegates using voting power adjusted by a time-held factor.
• Definitions:
  • DVP(i) = delegator i’s delegated voting power.
  • H(i) = hold modifier = min(hold_days, 180) / 180 (continuous days since the address last went from 0 to >0 ENS; capped at 180).
  • W(i) = H(i) * DVP(i) (weight).
• Reward formula: delegator_reward(i) = W(i) / ΣW * (90% of R)
  • Plain English: Take your time-held-adjusted voting power, divide it by the total of everyone’s time-held-adjusted voting power, then multiply by 90% of the monthly ENS pool.
• Per-delegator cap: min(delegator_reward(i), 5% of R).
• Excess from caps is redistributed pro-rata within the delegator pool to those still under cap (repeat until no one breaches the cap).

Rewards are viewpoint-neutral, meaning they don’t benefit a specific type of voting behavior. Only activity and time variables matter.

---

Pool size increases and expected APY

To make the program interesting for holders to re-engage governance, we have aimed for high APYs, using the holders that don’t reach the individual reward cap as reference.

Our goal is to make the program more rewarding as delegations increase, so every delegate and delegator is incentivised to support this growth. Without the result based increase, holders would be better off trying to avoid delegation growth to keep more of the pool for themselves.

All APYs mentioned here are approximates, as they will vary by many influences such as new delegates qualifying as active, new holders delegating and specially by whales hitting the individual reward caps.

We’ve run simulations on past datasets of the ENS token and governor contracts activity, and identified the following from the scenario:

• There are 44 qualifying delegates
• There are 7 holders above 50000 ENS delegating to active delegates
• There are 54 holders above 1000 ENS delegating to active delegates
• There are 976 holders above 100 ENS delegating to active delegates
• There are over 2700 holders delegating to active delegates
• With 5000 ENS being distributed for that scenario, we’d achieve an expected APY of ~4%
• With a 10% increase, that APY would already fall to around ~3%
• With a 10% increase threshold to increase the rewards pool from 5000 to 8000, that APY would already reach ~5.7%
• The same logic was applied to each range in the table below

% increase	ENS Total	Dolar value	Delegate Cap	Holder Cap	Uncapped Holder APY
0-10%	5000	$75k	50	250	4%
10-20%	8000	$120k	80	400	5,75%
20-30%	10000	$150k	100	500	6,5%
30-50%	15000	$225k	150	750	9%
50-75%	20000	$300k	200	1000	10,5%
75-100%	25000	$375k	250	1250	11,28%
Above 100%	30000	$450k	300	1500	—

This increase is calculated month over month, with those number representing the results after the first month.

Although the total cost could reach 90000 ENS, meaning over $1.3M in rewards, this scenario would also mean an increase to the capture cost of ENS DAO at the time of the simulations from $22M to $176M.

We find this scenario unlikely to play out - and a good one if it does - as it would take over 20% of the current circulating supply getting delegated to active voters for it to happen.

Delegation can be observed across most DAOs to have a stickiness to it, meaning its common for tokens that are delegated to stay so, or more precisely slowly get undelegated over a large period of time. Even if holders engage in the program to farm the rewards, we should see an increased resting point of security.

---

Minimum payout and lottery for very small payouts

In order to avoid over expending on transfer costs as we are talking of a mainnet airdrop to thousands of addresses, every allocation below 1 ENS will be turned into a “lottery chance” of getting 10 ENS. This allows for small participants to have a reason to be delegating anyway.

Without any increase, and looking at an APY of 4%, that would mean anyone delegating ~290 ENS tokens or less. With delegation increases leading to pool increases those numbers will change, with a 10% increase having address under ~200 ENS getting in the lottery and at 30% addresses under ~125 ENS.

• Minimum payout: If an address’s calculated payout (delegate or delegator) is < 1 ENS, it is not sent as a separate payment because such micro-transfers are operationally negative (gas/ops overhead and dilution of attention).

• Lottery mechanism (executed together with the normal distribution):

  • All sub-1 ENS calculated payouts are pooled together into groups that approach 10 ENS each.
  • Each pool awards a single prize of up to 10 ENS.
  • Draw method: Within each pool, a random draw weighted by each address’s original (sub-1 ENS) calculated payout selects the winner.
  • Execution: Lottery prizes are added to the same distribution list and included in the same transaction batch as the standard monthly payouts.
  • Publishing: We publish the pool compositions, weights, draw outputs, and final recipient list alongside the monthly files.

(Effectively, smaller balances get a fair shot at a meaningful payout now, instead of many insignificant transfers.)

---

Notes and guardrails

• Only on-chain votes count.
• No allowlist. Self-delegation is eligible if active.
• No preference on vote direction.
• Payout caps apply after base calculations and before the small-payout check and lottery ticketing.

---

Implementation

Front end

• Lightweight delegation UI: highlights active delegates, shows countdown to next distribution, displays prior round results, and features delegation flows.

Indexer & data (on blockful’s Anticapture stack)

• Track proposal participation and votes cast per delegate.
• Track delegation events.
• Track hold_days per address (as defined above).
• You can already see most of the data that will be used on anticapture.com
• Publish monthly CSV/JSON: active set, vote-power shares, delegation-days, hold factors, payouts (ENS), lottery pools/results, and round artifacts.

Distribution

• Monthly manual transaction by blockful, executed by the MetaGov multisig, with public files. Claimless.
• Lottery prizes are drawn and paid together with the normal monthly distribution.

Transparency

• All rules, data, and formulas are published each round and reproducible from on-chain data.

---

Anticipated questions

Does this over-reward whales?
It pays for votes actually cast. Inactive VP earns zero. The time-held factor reduces the impact of creating sybils. Caps (1% for delegates, 5% for delegators) further limit concentration on whales.

Why a 1 ENS minimum?
Sub-1 ENS transfers are inefficient (gas/ops) and create many tiny payouts. The lottery turns those into meaningful prizes without operational drag.

---

Parameters to confirm in this thread

• Monthly budget R and ramp conditions.
• Active Delegate threshold (keep 70% in the last-10).
• Payout caps as defined: 1% of R (per delegate) and 5% of R (per delegator).

---

Timeline

• Now (October): Program discussion in this thread; finalize parameters and budget.
• Early November: Publish the proposal on the forum.
• End of November: Program start aligned with ENS DAO Birthday Redelegation Program (5 ETH sponsored gas).
• End of Month 1: First distribution + results.
• Months 2–3: Two more rounds.
• Month 3 review: Evaluate (i) % of supply delegated to actives, (ii) number of actives, (iii) dispersion improvements (Gini/Nakamoto), (iv) delegator churn/time-in-delegate, (v) incidents.

---

Closing

This pilot pushes VP into active hands and keeps it there. The design is simple, auditable, and harder to game thanks to time-held weighting, a 1 ENS floor, ENS-only accounting, per-recipient caps, and a lottery that converts many tiny payouts into targeted 10 ENS-scale prizes—executed in the same batch as standard rewards.

[Zeptimus]

I love this initiative to incentivize token utility because rewarding active delegates and long-term holders makes a lot of sense for strengthening governance and improving participation. It should even encourage people to buy ENS and hold their tokens to get that APY, which builds a more engaged community and gives the DAO more legitimacy over time.

That said, there’s a tradeoff when you’re distributing 90,000 ENS or what ever is the final number over three months. If a bunch of recipients just cash out right away, you’re creating sell pressure of around 30k ENS per month with not much to balance it out. There’s also the risk of people jumping in just to farm rewards and then bailing once the pilot ends, which could create a temporary price drop.

[Arnold]

Good stuff guys thanks for sharing. At Edge so will be slower to deep dive on the mechanics.

Thanks for stating the upper-bound could be 90000 ENS, meaning over $1.3M for a 3 month experiment.

Are there some guardrails we put in place, as it seems like an expensive attack vector for a 3 month experiment.

@blockful

Although the total cost could reach 90000 ENS, meaning over $1.3M in rewards, this scenario would also mean an increase to the capture cost of ENS DAO at the time of the simulations from $22M to $176M.

We find this scenario unlikely to play out - and a good one if it does - as it would take over 20% of the current circulating supply getting delegated to active voters for it to happen.

Again awesome for posting the proposed mechanic and look fwd to reviewing in detail.

[zeugh.eth]

Appreciate the support @Zeptimus and @Arnold, and the questioning as well!

To defend the program against farmers and instant dumping we have added the time modifier as one of the metrics for calculating the rewards. That means that anyone getting a big reward has already been holding their ENS bag for a good period of time - maximum value reached at at 6 months.

Of course there will be a portion of the rewards that will be sold, but the incentives here are maximized for long term holders who are in the ecosystem and are either not delegating or delegating to an address inactive in the votes.

Assuming we reach the maximum amount of tokens distribution, we will be looking at around 12% APY, which in 3 months will give around 3%. There’s no big incentive for ENS holders that have been holding for over 180 days to just sell their whole bags after a 3% gain. Farmers joining now(before program starts) should be able to get less than 50% of that.

Supposing someone holding 10k ENS since 2024, now getting 300 ENS, it’s hard to imagine that will be the incentive that gets them to sell.

That’s not to say that market manipulation of multiple players buying a lot of tokens and distribution is impossible, but it’s held at bay both for big bags by the individual caps as well as for multiple small bags by the minimum reward value.

We are very open to hear ideas on how to improve this further and risks we should be aware, but so far in our simulations and observing who would get rewarded, it seems that we can get more voting power directly in the hands already delegating and holding long term.

—-

I’ll try to get a clearer explanation of those system in here soon!

[estmcmxci]

Solid move toward strengthening governance resilience. Curious whether vesting contracts were considered for incentive delivery, or if that adds too much operational overhead.

Since rewards already scale with active voting power, what about adding a small APY boost for delegates who’ve set a delegate record (eth.ens.delegate)?

It’s an existing, verifiable signal of long-term ENS alignment — and could strengthen incentives for delegates to formalize their presence onchain.

[BCV]

Reinforcing the protocol’s governance is non-negotiable for a critical protocol like ENS. Right now, the DAO complements its security with a centralized multi-sig wallet (Security Council) but such measures shouldn’t be necessary in a mature, evolved DAO. ENS’s ultimate goal should be to have 25-30% of the circulating supply actively participating in governance.

However, the incentives mentioned here risk rewarding random participation rather than meaningful contribution. The real challenge is evaluating governance participation objectively, so that incentives go to valuable contributors, not bots.

Hopefully, DAOs will find better and more innovative ways to identify their most valuable contributors and attract new talent.

[nick.eth]

@blockful

• Split among Active Delegates, proportional to the voting power they actually cast that month.

Can you clarify what “proportional to the voting power they actually cast that month” means? Is a delegate’s weighting the sum of their voting power for each vote they participated in?

@blockful

• Per-delegate cap: min(delegate_reward, 1% of R).
• Excess from caps is redistributed pro-rata within the delegate pool to those still under cap (repeat until no one breaches the cap).

How about a bonding curve rather than a hard cap? This would be simpler to compute and would also reduce the incentive to split one’s votes across multiple accounts.

@blockful

• Per-delegator cap: min(delegator_reward(i), 5% of R).

As above, but more so - even with a bonding curve we should expect to see protocols and yield farmers automatically splitting votes across multiple accounts in order to maximise rewards, making the cap ineffective for any but naive users.

@blockful

2) Delegator pool — 90% of R

Shouldn’t this be weighted by the participation rate of the account they delegated to? Otherwise, 90% of the pool could be allocated to accounts who delegated to inactive addresses.

@blockful

H(i) = hold modifier = min(hold_days, 180) / 180 (continuous days since the address last went from 0 to >0 ENS; capped at 180).

This would allow someone to seed one (or multiple) accounts with a single ENS token, then opportunistically top them up to whatever the current limit is in order to gain maximal benefit.

How about instead summing up each account’s delegated-vote-seconds (eg, the integral of their delegated vote totals over the last 180 days) and use that for weighting?

@blockful

Our goal is to make the program more rewarding as delegations increase, so every delegate and delegator is incentivised to support this growth. Without the result based increase, holders would be better off trying to avoid delegation growth to keep more of the pool for themselves.

Clever!

@blockful

• There are 44 qualifying delegates

With a cap of 1%, doesn’t this mean that over half of the tokens will go unallocated?

@blockful

Why a 1 ENS minimum?
Sub-1 ENS transfers are inefficient (gas/ops) and create many tiny payouts. The lottery turns those into meaningful prizes without operational drag.

Doesn’t the lottery eliminate the 1 ENS minimum?

@blockful

Front end

• Lightweight delegation UI: highlights active delegates, shows countdown to next distribution, displays prior round results, and features delegation flows.

Indexer & data (on blockful’s Anticapture stack)

• Track proposal participation and votes cast per delegate.
• Track delegation events.
• Track hold_days per address (as defined above).
• You can already see most of the data that will be used on anticapture.com
• Publish monthly CSV/JSON: active set, vote-power shares, delegation-days, hold factors, payouts (ENS), lottery pools/results, and round artifacts.

Are you volunteering to build this, inside your existing funding stream?

[zeugh.eth]

Fair concerns, and fair suggestions. Let me address that with our thought process and see if we can come to some improvements to the system.

@estmcmxci

Curious whether vesting contracts were considered for incentive delivery, or if that adds too much operational overhead.

No vesting was considered for this program. It could be done to improve the system and avoid sell pressure, but it’d have to be done in a way that lets governance participants use their new balances as voting power right away. Given that most of the rewards are aimed at delegators and not delegates, that would have to be set as delegation to the same addresses they are delegating, and if they wanted to change those, it would become a bit complex. I’m up to looking for an easy and effective way to do this, but I’m not sure it would be essential here.

@estmcmxci

Since rewards already scale with active voting power, what about adding a small APY boost for delegates who’ve set a delegate record (eth.ens.delegate)?

That’d be positive, but not sure if necessary, as it is again more workload for people to join the program, and only 10% of rewards are for delegates anyway.

@BCV

the incentives mentioned here risk rewarding random participation rather than meaningful contribution. The real challenge is evaluating governance participation objectively, so that incentives go to valuable contributors, not bots.

This program primarily rewards token holders that direct those tokens toward governance participation. It’s unbiased regarding bots or humans, as long as those addresses are helping make the DAO safer by delegating to active members. There are other types of delegate incentives programs that tackle other types of contributions, but we find its more importante right now to guarantee an increase in actively used delegated supply.

I’ll reply to nick.eth in a next post given that there are many questions in your reply.

[BCV]

It’s unbiased regarding bots or humans, as long as those addresses are helping make the DAO safer by delegating to active members.

But with that approach, you’re just incentivizing random delegates for random votes. I don’t think that’s a good way to boost governance participation. Here’s my proposed solution:

[RFC] Aligning Governance and Developer Incentives on Namechain

Okay, I’ve read your post. This highlights one of the biggest problems facing DAOs today: the lack of incentives for governance participation. The main issue is evaluating which participants are genuine contributors and which are bots (or, as you said, ENS-aligned vs. not). If you simply incentivize all voters, it may attract bot-like activity, though I’m not entirely sure that would happen. Your PoH approach doesn’t fully prevent human-operated bots either, and I’m not sure that kind of verifi…

[zeugh.eth]

@nick.eth

Can you clarify what “proportional to the voting power they actually cast that month” means? Is a delegate’s weighting the sum of their voting power for each vote they participated in?

Great question, that was not put clearly. Both delegates’ and holders’ power will be weighted based on the average of their voting power/delegated voting power at the proposal snapshots for that month’s proposals.

All active delegates in that period, and all the holders delegating to them, will have their power counted in each proposal, not only in the ones “actually cast” as expressed before. Thanks for asking this; it was badly expressed in the goal of making it easier to grasp.

@nick.eth

How about a bonding curve rather than a hard cap? This would be simpler to compute and would also reduce the incentive to split one’s votes across multiple accounts.

@nick.eth

As above, but more so - even with a bonding curve we should expect to see protocols and yield farmers automatically splitting votes across multiple accounts in order to maximise rewards, making the cap ineffective for any but naive users.

Not sure what are you proposing that we do with a bonding curve here. Caps are very hard to reach - in our simulations, it’s mostly already established big holders and top delegates. Farmers will hardly interact with the cap because of the holding time modifier, unless they put in a huge amount of capital to farm only 40% of what they could.

Happy to hear more of a bonding curve model for this and its advantages, but I don’t see clearly a benefit or a model at this moment.

@nick.eth

Shouldn’t this be weighted by the participation rate of the account they delegated to? Otherwise, 90% of the pool could be allocated to accounts who delegated to inactive addresses.

Only holders delegating to active delegators qualify, so this is not an issue. Our first model had reward amounts based on the % of activity of delegates, but given the small amount of active delegates, we found it more interesting to have it binary active/non-active to avoid everyone concentrating delegations to the even fewer delegates with 90% or 100% activity in order to improve their yields.

@nick.eth

This would allow someone to seed one (or multiple) accounts with a single ENS token, then opportunistically top them up to whatever the current limit is in order to gain maximal benefit.

How about instead summing up each account’s delegated-vote-seconds (eg, the integral of their delegated vote totals over the last 180 days) and use that for weighting?

This would be a better model for filtering farmers, although more burdensome. Let me get that to a discussion internally and check how easy it would be to work with that data, if it actually improves the system, and get back to you.

My first thought is that it’s not necessary for the first implementation because, realistically, a farmer would have needed to get started on this seeding a good while ago to make it profitable, if we can keep close to our timeline goals.

@nick.eth

With a cap of 1%, doesn’t this mean that over half of the tokens will go unallocated?

No, because the supply for delegates is 10% of R. At the snapshot used for the simulation, there were 44 delegates to split 10%, and over 2500 holders delegating to them, splitting the other 90%. Only the top 3 delegates hit the cap and only the top 2 holders did. If concentration increases, those numbers should increase a bit too, but even our most intentionally skewed scenarios didn’t get more than 10 delegates hitting the cap before becoming very unrealistic.

@nick.eth

Doesn’t the lottery eliminate the 1 ENS minimum?

The lottery addresses the 1 ENS minimum. Everyone who would receive less than that gets put into the lottery. Meaning they get a chance to be rewarded 10 ENS proportional to their original reward, instead of getting the reward itself.

Everyone above 1 ENS receives it normally. Everyone below it gets in the lottery. We never send less than 1.

@nick.eth

Are you volunteering to build this, inside your existing funding stream?

I wouldn’t call it volunteering, as I see it as part of our current service provider proposal to improve ENS DAO governance resilience. But yes, we are saying we will build this inside the current funding stream we have.

[AvsA]

I support this initiative.

@nick.eth

How about instead summing up each account’s delegated-vote-seconds (eg, the integral of their delegated vote totals over the last 180 days) and use that for weighting?

I think this is worth exploring but it might complicate calculating as you need to have the balance over time of all accounts.

@zeugh.eth

But yes, we are saying we will build this inside the current funding stream we have.

Great clarification.

@blockful

Visibility: Tying redelegation to the birthday concentrates community focus, provides a clear “why now”, and grants social legitimacy for holders to review/update their delegate choices, especially toward active delegates.

I like the idea of promoting it as an anniversary thing, but maybe in order to be effective it needs to either be automated, constant or maybe more long duration. One concept could be to have the UI calculate live how much you’re probably getting when the distribution happens, so you can hop in every day and feel the amount gained.

We also need to combine this with some sort of outreach campaign to make sure users know this is going on.

Which creates the important question: what metric should we use after the first 3 months to judge either the proposal achieved its goals?

[estmcmxci]

@zeugh.eth

but it’d have to be done in a way that lets governance participants use their new balances as voting power right away

Someone check me on this if they want, but we can use Hedgey to give contributors vesting contracts that allow them to vote on day one.

—

I love the intention of this initiative, truly. Reimagining delegates as active security nodes (similar to the Ethereum validator set) is a powerful, proven framework to draw from.

One issue I take with it though is that there are several trust assumptions that the DAO would have to concede to in order to run the pilot.

→ offchain administration
→ fund custody
→ manual parameters

I’d say that, for the sake of experimentation, we should let this pilot rip. Long term, however, I’d love to see an onchain solution for this, such as the validator-style governance model I’m musing on here: [RFC] Aligning Governance and Developer Incentives on Namechain - #7 by estmcmxci

[Coltron.eth]

Questions
a. For the pilot, what amount of total voting power increase MoM is considered a success?
b. Can that amount of voting power increase be achieved in another ways?

[nick.eth]

@zeugh.eth

Not sure what are you proposing that we do with a bonding curve here. Caps are very hard to reach - in our simulations, it’s mostly already established big holders and top delegates. Farmers will hardly interact with the cap because of the holding time modifier, unless they put in a huge amount of capital to farm only 40% of what they could.

Happy to hear more of a bonding curve model for this and its advantages, but I don’t see clearly a benefit or a model at this moment.

With a hard cap of, say, 1% of rewards to any given delegate, you have to do multiple rounds of recomputation to reallocate any funds that would exceed the cap, you risk a situation where some funds cannot be allocated at all (because all qualified delegates reach the cap), and you strongly incentivize anyone who would reach the cap to split their delegation or their delegates across multiple accounts.

If you instead apply a sublinear function to each delegate’s score, such as taking the logarithm or exponentiating by a value between [0…1], you can achieve the same effect of preventing one delegate or delegator from receiving disproportionate amounts, with simpler implementation and with reduced incentive to split across accounts.

@zeugh.eth

My first thought is that it’s not necessary for the first implementation because, realistically, a farmer would have needed to get started on this seeding a good while ago to make it profitable, if we can keep close to our timeline goals.

There will already be plenty of accounts that have dust amounts of ENS sitting around delegated for >180 days right now. With the proposed model each of those becomes very valuable as a place to send a lot of extra ENS tokens and have them immediately earn more.

@zeugh.eth

The lottery addresses the 1 ENS minimum. Everyone who would receive less than that gets put into the lottery. Meaning they get a chance to be rewarded 10 ENS proportional to their original reward, instead of getting the reward itself.

Everyone above 1 ENS receives it normally. Everyone below it gets in the lottery. We never send less than 1.

Ah, I see. Why not set the minimum equal to the lottery amount, though?

@zeugh.eth

I wouldn’t call it volunteering, as I see it as part of our current service provider proposal to improve ENS DAO governance resilience. But yes, we are saying we will build this inside the current funding stream we have.

[simona_pop]

Thank you for posting this @blockful team and for the detailed presentations in the MG calls @zeugh.eth! Some thoughts:

• “Progress dashboard: live redelegations, active VP growth, countdown to next round” - who will audit this and how will the community trust the numbers - is there a process to challenge the data if things don’t look right/there are objections?

• on-chain / off-chain: are we pulling real-time chain data, or depending on curator updates?

• what signals (beyond “number of votes cast” and “voting power increase”) could be included to measure engaged and thoughtful governance vs than just busy governance?

• at Gitcoin we used of a “delegate scorecard” (voting participation, rationales shared, forum engagement etc) could that be something to think about and tie rewards to?

• how can we ensure that token holders don’t just pick “biggest reward delegate” but pick based on value alignment?

• after the pilot, how will the learnings feed into ongoing changes? Is there an exit plan, feedback/takeaways integration, program audit etc.?

• I think to start we are comfortable with the trust assumptions (offchain admin, custody, manual work etc) during the pilot as “learning stage”, but what happens when the workload scales? Or can this be addressed during a potential audit phase as above? (echoing @estmcmxci onchain solution mention above)

[zeugh.eth]

Before getting into the replies, I want to mention that we forgot to thank @AvsA and @James for the early feedback and iterations on this idea. We wouldn’t have the lottery system idea or the hold time cap (which was previously a time-delegated cap) without your feedback and this look much more solid now.

Also, we are changing this topic to a [TEMPERATURE CHECK] so we can start moving it forward to implementation in the near future.

---

@AvsA

One concept could be to have the UI calculate live how much you’re probably getting when the distribution happens, so you can hop in every day and feel the amount gained.

We don’t have a design for the UI yet. The idea so far is to give an easy experience to delegate and keep track of the rounds, which could have the user gains included.

@AvsA

what metric should we use after the first 3 months to judge either the proposal achieved its goals?

Increase in delegated supply, % dumped, and its delegation stickiness over the following months.

@AvsA

I like the idea of promoting it as an anniversary thing, but maybe in order to be effective it needs to either be automated, constant or maybe more long duration.

Our proposal is to pilot this first before we automate it for the longer term if it’s successful.

---

@estmcmxci

One issue I take with it though is that there are several trust assumptions that the DAO would have to concede to in order to run the pilot.

→ offchain administration
→ fund custody
→ manual parameters

This should be improved for future versions in case the pilot is successful.

---

@Coltron.eth

a. For the pilot, what amount of total voting power increase MoM is considered a success?

Our goal, from point 4.1.5 of our SPP application is to get a 30% increase. Ideally, we achieve it in this pilot.

@Coltron.eth

b. Can that amount of voting power increase be achieved in another ways?

There are many paths to muse over, but this seems the most straightforward, and also rewards the community that contributed so far. We are planning non-financial mechanisms to add to this, but this one seems like the easiest win and reasonably priced for the results it can bring.

---

@nick.eth

With a hard cap of, say, 1% of rewards to any given delegate, you have to do multiple rounds of recomputation to reallocate any funds that would exceed the cap, you risk a situation where some funds cannot be allocated at all

It’s not impossible, but all of our simulations went only as far as 4 rounds of iteration, and never got even close to 20% of addresses reaching the cap. If in a scenario all addresses would reach cap, the remainder will return to the DAO treasury.

@nick.eth

There will already be plenty of accounts that have dust amounts of ENS sitting around delegated for >180 days right now. With the proposed model each of those becomes very valuable as a place to send a lot of extra ENS tokens and have them immediately earn more.

At this time there are very few holders that even touch that cap, and they are mostly active in the DAO and well known. This could indeed be exploited, but there will hardly be a big enough number of exploiters that would benefit from this without a big reputational damage.

@nick.eth

Ah, I see. Why not set the minimum equal to the lottery amount, though?

As the user will have a chance to win, rather than a guaranteed amount, we found it better to pool up to 10 ENS to provide a more substantial reward. Also, it reduces the number of transactions to send.

---

@simona_pop

“Progress dashboard: live redelegations, active VP growth, countdown to next round” - who will audit this and how will the community trust the numbers - is there a process to challenge the data if things don’t look right/there are objections?

We will post it ahead of time for auditing, as the execution is made by metagov stewards not our own team. There is no specific process in place right now, happy to include it to our specs, but one way or another stewards will need to review.

@simona_pop

• on-chain / off-chain: are we pulling real-time chain data, or depending on curator updates?

We are using the same indexer we use for Anticapture - ENS DAO built with ponder.sh to track ENS’s governor, timelock and token contracts

@simona_pop

what signals (beyond “number of votes cast” and “voting power increase”) could be included to measure engaged and thoughtful governance vs than just busy governance?

It is not a goal of this program to increase quality of delegates, but number of holders delegating to active voters. Would love to see/help something of that sort, but it is not in the goals here.

@simona_pop

how can we ensure that token holders don’t just pick “biggest reward delegate” but pick based on value alignment?

As long as the delegate is active (voted >7 in the last 10 props), there is no biggest reward delegate, it’s all the same. We removed the differentiation to avoid that effect.

@simona_pop

after the pilot, how will the learnings feed into ongoing changes? Is there an exit plan, feedback/takeaways integration, program audit etc.?

We are working on it after @Coltron.eth feedback on the call. Nothing is defined yet.

@simona_pop

I think to start we are comfortable with the trust assumptions (offchain admin, custody, manual work etc) during the pilot as “learning stage”, but what happens when the workload scales? Or can this be addressed during a potential audit phase as above?

I am not even sure we should be doing this multiple times, this will depend of results, stickiness and security improvements resulting from the pilot. The way to make this onchain seems straightforward but takes way more effort, so we are leaving this tbd if we make the pilot successful.

[clowes.eth]

Thanks for the effort here.

Would it be possible for you to briefly outline at a high level how this affects:

• A token holder who already delegates to someone else who is active
• A token holder who already delegates to someone else who is not active
• A token holder who does not currently delegate

I appreciate that the complex dynamics are necessary to avoid it being gamed, but for this to be a success it needs (IMO) to be immediately obvious to people what they need to do, and what they get for doing it.

Like “If i redelegate I get 10 ENS” simple.

[estmcmxci]

@blockful

Front end

• Lightweight delegation UI: highlights active delegates, shows countdown to next distribution, displays prior round results, and features delegation flows.

Indexer & data (on blockful’s Anticapture stack)

• Track proposal participation and votes cast per delegate.
• Track delegation events.
• Track hold_days per address (as defined above).
• You can already see most of the data that will be used on anticapture.com
• Publish monthly CSV/JSON: active set, vote-power shares, delegation-days, hold factors, payouts (ENS), lottery pools/results, and round artifacts.

Would it help to integrate the Multi-Delegate Manager smart contract with the proposed incentives program and build a UI that estimates delegators’ rewards?

The UI can be made “MDM Aware” and guide users through delegate flows where they can view their estimated rewards.

—

@clowes.eth

Like “If i redelegate I get 10 ENS” simple.

Goes to website > sees reward pool > connects wallet > display eligibility + rewards estimate

[nick.eth]

@zeugh.eth

At this time there are very few holders that even touch that cap, and they are mostly active in the DAO and well known. This could indeed be exploited, but there will hardly be a big enough number of exploiters that would benefit from this without a big reputational damage.

Based on a hacky BigQuery query, there are over 21,000 accounts that have at least a dust amount of ENS tokens and have had for >= 180 days. Each of these would become immediately valuable as a place to put ENS tokens and immediately earn significantly more rewards.

I think you’re being entirely too casual about this; to be resistant to gaming your calculation has to take either the minimum balance over the last 180 days, or (better, IMO) sum up the balance-seconds to use as a weighting factor instead.

BigQuery query

WITH
  transfers AS (
  SELECT
    block_timestamp,
    block_number,
    log_index,
    `from` AS account,
    -CAST(value AS BIGNUMERIC) / 1e18 AS value
  FROM
    `blockchain-etl.ethereum_ens.ENSToken_event_Transfer`
  UNION ALL
  SELECT
    block_timestamp,
    block_number,
    log_index,
    `to` AS account,
    CAST(value AS BIGNUMERIC) / 1e18 AS value
  FROM
    `blockchain-etl.ethereum_ens.ENSToken_event_Transfer` ),
  balances AS (
  SELECT
    block_number,
    log_index,
    block_timestamp,
    account,
    COALESCE(SUM(value) OVER (value_window), 0) AS balance_before,
    COALESCE(SUM(value) OVER (value_window) + value, 0) AS balance
  FROM
    `transfers`
  WINDOW
    value_window AS (
    PARTITION BY
      account
    ORDER BY
      block_number,
      log_index ROWS BETWEEN UNBOUNDED PRECEDING
      AND 1 PRECEDING ) )
SELECT
  block_timestamp,
  account,
  balance,
  LAST_VALUE(
    CASE
      WHEN balance_before <= 0 OR balance_before + balance <= 0 THEN block_timestamp
      ELSE NULL
  END
    IGNORE NULLS) OVER (PARTITION BY account ORDER BY block_number, log_index ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS last_zero
FROM
  `balances`
WHERE balance > 0
QUALIFY
  ROW_NUMBER() OVER (PARTITION BY account ORDER BY block_number DESC, log_index DESC) = 1
 AND current_timestamp - last_zero > INTERVAL 180 day
ORDER BY balance

@zeugh.eth

As the user will have a chance to win, rather than a guaranteed amount, we found it better to pool up to 10 ENS to provide a more substantial reward. Also, it reduces the number of transactions to send.

Why not set the minimum amount at 10 ENS also, though?

[liubenben]

@blockful

An active delegate is an address that voted on at least 7 of the last 10 on-chain proposals (rolling).

The Active Delegate threshold is a little simplistic. It only reflects recent activity and doesn’t capture the value of long-term activity. Furthermore, this standard lacks flexibility.

Therefore, the following standard might be better:

The voting rate of the last 10 on-chain votes + the voting rate of all on-chain votes >= 100%

in the last 10	in history	total	Active?
80%	20%	100%	Yes
70%	35%	105%	Yes
50%	60%	110%	Yes
70%	10%	80%	No
80%	15%	95%	No

Although currently, the active delegates in the near term and the active delegates in the long term are basically the same people, in the long run, this strategy is more likely to incentivize delegates to remain active in the community, rather than just being active during the incentive period.