ENS Delegation

Incentives Program

Goal

1. Increase cost of governance attacks
1. Right now the delegated supply is smaller than the ETH + Stables treasuries
2. Increase delegated supply and direct it to active delegates

Goal

2. Increase active delegates power

• Increasing active voting power - a.k.a. the power currently with delegates who vote

Delegation Incentives Program

1. Operation
1. Paid in ENS tokens granted on a proposal, still to be made
2. v1 manually managed by Blockful, possibility to automate if we see need for a v2
3. 3 month test, 3 manual distributions
4. Public reporting for auditing of the distributions�
2. Reward active delegates and holders delegating to active delegates
• Active delegates have voted in 7 or more of the past 10 proposals
• Reward proportional to amount of voting power amongst active delegates
• 10% of rewards to delegates, 90% to delegators

Mechanism I

Let R be the monthly reward pool.

1. Delegate pool (10% of R): Split among active delegates proportional to the voting power they actually cast in that month.�
2. Delegator pool (90% of R): First, attribute each active delegate a slice proportional to the voting power they actually cast; then split that slice among their delegators by delegated power.

Problem:

• Big delegate and holder concentration will make cost-efficiency of rewards too small.

Mechanism II

Let R be the monthly reward pool.

• Delegate pool (10% of R): Split among active delegates proportional to the voting power they actually cast in that month, up to a limit of 0.5% of total pool.�
• Delegator pool (90% of R): First, attribute each active delegate a slice proportional to the voting power they actually cast; then split that slice among their delegators by delegated power, up to a limit of 5% of total pool.

Problem:

• Easy to game with:
• holders splitting into multiple wallets to benefit from the limit.
• new addresses acquiring token to farm reward and sell again

With delegator cap set to 500

Mechanism III

Let R be the monthly reward pool.

• Delegate pool (10% of R): Split among active delegates proportional to the voting power they actually cast in that month, up to a limit of 0.5% of total pool.�
• Delegator pool (90% of R): First, attribute each active delegate a slice proportional to the voting power they actually cast; then split that slice among their delegators by delegated power, using time held and time delegated as modifiers to heavily cut gains from users trying to game the system, up to a limit of 5% of total pool.

(not a) Problem:

• Incentives for new holders to get in will be smaller than for old holders to delegate
• Holders that never delegates will get smaller rewards than those who did
• Possibly worth it adding difference of delegate activity as 60% and 90% are very different for security

Summary of versions

1. Simplest version
1. No limits
2. Big delegate/delegator rewards concentration�
2. Limits version
• Limit in % for gains
• Spread rewards to more governance participants�
3. Time balanced
• Counter-incentive for gaming the limits
• Reduce the gains for new token holders

Progression

1. Simple gradual 20k ENS
1. 4k, 6k and 10k months
2. Increases every month as delegations should be increasing too
2. Metric based gradual 20k ENS
• 4k, 6k, 10k lines
• Depend on the increase of delegations to increase amount
3. Simple 21k ENS
• 7k every month

Number goals (still under simulation, RFC soon)

• 0,5% to 3,5% APY
• Variable depending on modifiers added
1. Time held, delegated and delegate activity

​

​

Questions and discussion

Soon™️, in an RFC on your favorite forum