Overview

As a decentralized protocol, DoubleZero requires public goods — around processing the DoubleZero chain, managing the routing logic, running the activator service, calculating the rewards distribution to network contributors, and more — to function and thrive. These public goods in turn require both compute and security, provided by a system of validators and stakers. Inflation is the mechanism to incentivize them holistically, as the broad transfer of value from the token community to the specific actors who generate protocol-wide benefits.

While inflation is needed to finance public goods, it should also be determined in a market-based way and face reasonable constraints. Above all, it should react to the actions of staking participants’ to avoid being too stingy or too generous: overly generous inflation crowds-out broader innovation with the token, while overly stingy inflation leads to an underprovision in public goods. Moreover, in addition to a few operational constraints, inflation should counterbalance burning of tokens by the network over the long run, so that the total token supply remains stable asymptotically.

This system of market signals and constraints governs the ultimate inflation rate in DoubleZero, such that it serves a purpose but does so sustainably.

Proposal

We propose that the inflation rate i in epoch t be set as a fraction of contributors rewards rate, with that fraction determined by the proportion of tokens staked. This is the same formula found in SIMD-0228 (before it was modified to be more generous on the left tail of the distribution).

$$ i_t = \left(1 - \sqrt{\text{Stake Percent}_t}\right) \frac{\text{Contributor Rewards}_t}{\text{Token Supply}_t} $$

This proposal bounds the inflation rate between zero and the contributor reward rate, such that the cost of providing overhead for the system never exceeds the cost of actually provisioning the system. It further responds to market signals in determining inflation: a high inflation rate is offered to offset a low stake percent, and a low inflation rate can be used when the stake percent is high.

In addition, there is one hard bound that limits the inflation rate, which is a function of past and current token supplies S and the past burn rates b. While it may look complex, it is easiest to reason about if the parameter $\delta_t = 0$. In this case, the number of newly-minted tokens is strictly bounded by the difference between the number of previously-burned and previously-minted tokens, plus the number of currently-burned tokens.

$$ i_t \le \max\left[0, \frac{1}{S_t} \left(\sum_{j \le t} S_j b_j - \sum_{j < t} S_j i_j\right)\right] + \delta_t f $$

When $\delta_t$ is allowed to be positive rather than non-zero, then there is some tolerance to diverge from this strict constraint, due to the second term (where f is a fixed constant).

We recommend that $\delta$ starts positive but asymptotes to zero as more epochs elapse. This allows DoubleZero to have long-run inflation that counterbalances long-run burning in the long run, but gives inflation the flexibility to fit the protocol’s needs in the short run.

Note that this proposal is modified from an original version, that tried to target a specific stake percent and used a system of three constraints rather than one. The proposal herein is simpler and thus more preferable.

Alternate Formulations

Inflation can take alternate formulations. Here are two that have been considered:

  1. Yield Metrics: rather than reacting to a percentage of stake, inflation could react to or target a certain yield on staked tokens, that is either constant or time-varying (e.g. high initially and low as DoubleZero matures). However, it is hard to know what a suitable yield should be over long periods of time, when the benchmark rate in crypto and elsewhere changes.
  2. Value Staked: inflation could react to or target a dollar amount of staked tokens, rather than a percentage of stake. This is perhaps the purest in terms of theory — as placing a dollar value on the integrity of the system is the easiest to do — but it is the hardest to operationalize, because it involves an oracle dependency. In addition, given the historical volatility in general token prices, this might lead to large inflation shifts on a daily basis (which can be self-reinforcing).