I’ve thought about this problem a lot recently, the following post (warning - long!) is my best attempt at summarizing my thoughts.
Introduction
Epoch rewards are a tool that the Celo network uses to incentivize certain behaviors. Specifically:
- A staking yield incentivizes CELO holders to stake.
- cUSD rewards incentivize validators to validate.
- The community fund allows CELO holders to incentivize actions at their discretion.
- The carbon offsetting fund ensures Celo contributes to, rather than extracts from, Earth’s natural capital
If you assume that the total network value does not change with token supply (e.g. stock splits don’t change the value of a company), these incentives are paid for in the following ways:
- Staking rewards are funded by diluting non-stakers
- Validator rewards are funded by diluting non-validators
- The community fund is paid for by diluting everyone
- Carbon offsets are paid for by diluting everyone
Short term recommendations
In this section I will discuss my view on the current state of epoch rewards in Celo and recommend some simple and (hopefully) non-controversial actions that we can take in the short term to ensure the protocol achieves, or continues to achieve, its goals wrt epoch rewards.
1. Staking yield
For (1), I agree with the general sentiment that things are working well enough. A staking rate north of 50% seems “secure enough” to me, though I would like to see the rate pushed further north to 67%.
However, at present staking competes with all other uses for the CELO token. As other opportunities for yield on Celo (e.g. defi) become more attractive, we may see the staking rate drop. Building out more support for staking derivatives may allow defi and staking to complement each other rather than compete (more on this to come!), but in the meantime it’s important for the security of the network for staking to be sufficiently attractive wrt defi.
Recommendation
To ensure that users continue to stake in the face of a growing Celo defi ecosystem, I would recommend we increase the target staking fraction to 60%, and to activate the staking yield feedback mechanism.
2. Validator rewards
Similarly, I agree with the general sentiment that the protocol is achieving its goals here. Unlike (1), where the protocol is competing with other uses for CELO, here the protocol competes for other uses of Validator human capital (e.g. spending time validating on other networks).
Unfortunately it’s harder to automate the feedback loop here, as the on-chain signals are not as high with staking. It’s seems to me that the protocol is doing “good enough” for now, but it’s hard to say how big the margin of safety is. As the rewards multiplier continues to drop, we may see validators start to reconsider. It’s worth noting that a few months ago the recommended machine spec was bumped up, and so validator costs are actually higher than they started out.
Recommendation
To ensure that Celo continues to be a desirable network on which to validate, we bump the target annual rewards up to 85k cUSD, which, with a rewards multiplier of 87%, roughly restores the original 75k cUSD validator rewards. It’s worth noting that the total value being paid to validators is less than a quarter of what’s paid to voters, and so a 13% increase here is small wrt the total CELO issuance.
3. Community fund
Once again, I agree with the general sentiment that this is the area in which the protocol is falling most short of its goals. The problem (and solution) here seems to pertain more towards human coordination rather than anything protocol related. That’s a big area that I think warrants its own, separate discussion, and so I will refrain from commenting too much on this in this thread.
At the moment, it’s clear that the community fund is growing far faster than it’s being put to work. A desirable steady state, IMO, would be for the community fund to grow at roughly the rate at which it’s being deployed to projects that provide sufficient net utility to the Celo network, for however CELO holders decide to define “sufficient” and “utility”.
Recommendation
Until we see signals that the community fund is growing too slowly to achieve that goal, we reduce the community fund share from 25% to 5% and kick off a working group to investigate how this can be used more effectively.
4. Carbon offsetting
Haven’t seen this one discussed much, probably because the numbers are so small, but Celo is solidly net-negative wrt CO2. I don’t think we need to do much here.
Long term recommendation
In the longer term, I believe we should work to remove the rewards multiplier and target issuance schedule.
Adding a target schedule and the rewards multiplier feedback mechanism adds a fifth goal to the four outlined above:
- New CELO should be be issued at a predetermined rate.
It seems to me that this goal is in direct tension with the ability to efficiently achieve goals 1-41.
To illustrate this, let’s imagine that yi represents the total CELO issuance needed in order to achieve goal i.
- If y5 > y1 + y2 + y3 + y4, the target issuance schedule will cause more CELO to be issued than is needed to achieve goals 1-4. This essentially results in “unproductive” dilution of various stakeholders, which feels to me to be inherently undesirable.
- On the other hand, if y5 < y1 + y2 + y3 + y4, the target issuance schedule will cause less CELO to be issued than is needed to achieve goals 1-4, causing the protocol to un or under achieve on one or more of those goals.
The only way for goal 5 to be fully compatible with efficiently achieving goals 1-4 is for y5 to equal y1 + y2 + y3 + y42.
To justify the target issuance schedule, I think we need to be able to argue that having a target issuance is worth the cost of over-diluting CELO holders when we’re in scenario (1), and under-achieving goals 1-41 when we’re in scenario (2).
I don’t feel strongly about over-dilution one way or the other, but would have trouble defending choosing to sacrifice on goals 1-4 in favor of 5.
1 And future goals that the protocol may aim to incentivize with CELO issuance
2 And if that’s how the target issuance schedule is defined, there’s no need to actually define a target issuance schedule, you just need to define protocols for efficiently achieving goals 1-4