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 balance-per-second 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.
We are moving forward with our ENS incentives program that we requested feedback last year. After many discussions and incorporating feedback from the community, we ended up with a few changes:
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 | $50k | 50 | 250 |
| 10-20% | 8000 | $80k | 80 | 400 |
| 20-30% | 10000 | $150k | 100 | 500 |
| 30-50% | 15000 | $150k | 150 | 750 |
| 50-75% | 20000 | $200k | 200 | 1000 |
| 75-100% | 25000 | $250k | 250 | 1250 |
| Above 100% | 30000 | $300k | 300 | 1500 |
Dollar values are figurative just to give perspective of cost, at $10/ENS on Jan 16th.
We propose launching the pilot with a redelegation campaign, with 5 ETH of sponsored gas via delegateBySig, and a visibility campaign to bring long-time holders back into governance.
Reasoning:
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
Let R be the monthly reward pool (in ENS).
Split among Active Delegates, proportional to the average voting power they held 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).
Split among delegators who are delegated to an Active Delegate at distribution time, using time-weighted ENS balance over the last 180 days.
A delegator is eligible if, at the distribution cutoff, their address is delegated to an Active Delegate.
This is measured based on the initial balance and each transaction in the period, the resulting balance of the address after that transaction is used with the total time until it changes again, ensuring a balance per second average over the 180 days window.
If you are delegated to an Active Delegate at distribution time, your reward is based on your average ENS balance over the last 180 days. Your share equals your 180-day average balance divided by the total sum of 180-day average balances of all eligible delegators, multiplied by 90% of the monthly ENS rewards 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-weighted balance variables matter.
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(as of Jan 16th):
| % increase | ENS Total | Dollar value | Delegate Cap | Holder Cap | Uncapped Holder APY |
|---|---|---|---|---|---|
| 0-10% | 5000 | $50k | 50 | 250 | 4% |
| 10-20% | 8000 | $80k | 80 | 400 | 5,75% |
| 20-30% | 10000 | $100k | 100 | 500 | 6,5% |
| 30-50% | 15000 | $150k | 150 | 750 | 9% |
| 50-75% | 20000 | $200k | 200 | 1000 | 10,5% |
| 75-100% | 25000 | $250k | 250 | 1250 | 11,28% |
| Above 100% | 30000 | $300k | 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 $900k in rewards, this scenario would also mean an increase to the capture cost of ENS DAO at the time of the simulations from $11M to $94M.
We find this scenario unlikely to play out - and a good one if it does - as it would take about 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.
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.
(Effectively, smaller balances get a fair shot at a meaningful payout now, instead of many insignificant transfers.)
We will be tracking some metrics to improve our learnings over this first version. The main goal here is to increase security, and it's a pilot of something we could leverage in the future, so it's important we find what works or not. We'll be tracking and reporting, at least:
Does this over-reward whales?
It pays for getting voting power used. Inactive VP earns zero. The time weighted balance 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.
This pilot pushes VP into active hands. The design is simple, auditable, and harder to game thanks to time weighted balance, 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.