[RFC] 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 - VP based distribution

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 - Reward Caps

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 - Time Held modifier

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 as modifier to heavily cut gains from users trying to game the system, up to a limit of 5% of total pool.

(not a big) Problem:

• Incentives for new holders to get in will be smaller than for old holders to delegate
• Small dusted wallets can be used to game the program

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

Amounts

1. ​

Number goals

​

​

Questions and discussion

Soon™️, in an RFC on your favorite forum