Dynamic Reward Emission Schedule
Authors: Dr Laurence E. Day, blurr, Lito Coen
Introduction
Now that the initial ‘burst’ of NDX emissions has ended (in order to wrest majority control of liquid NDX from the core team vesting Gnosis), a longer-term solution needs to be put in place for buying ‘loyalty’ insofar as liquidity provision goes.
As is the case with several other protocols out in the wild at present, this loyalty is rewarded via the protocol token itself as a hedge against any impermanent loss (IL) that may arise due to fluctuations in the underlying assets.
This is the first in a series of longer-term proposals aimed at stabilising the emission of liquid NDX, increasing the ‘stickiness’ of NDX as ‘more than just’ a governance token (in the form of value accrual), and generally establishing a solid footing for NDX’s tokenomics going forward.
Objectives & Parameters
The primary objective going forward is to maintain sufficient liquidity in each of the index pools to incur a maximum of 0.5% slippage on a 10 ETH buy. Indices are (unsurprisingly) the prime focus of the Indexed platform, and so our priority should be making them easily purchaseable. We could target a dollar value here instead (such as targeting slippage against a US$10,000 buy), but all of the LPs are currently against ETH, and massive swings in the value of Ether would - for lack of a better term - wreak havoc with our targeting, without leaving anything in our wheelhouse to fix it.
The amount allocated for this purpose is 2.4 million NDX over a 2 year period (initially 2.5 million, minus the 100,000 designated as the stop-gap for the CC10, DEFI5 and ORCL5 Uniswap LP pools over the course of March: see here for details).
On a purely linear basis, this sets a maximum daily emission of ~3,287 NDX. However, we propose imposing a linearly decaying modifier on this cap from 1.5 - 0.5x over the duration of the program, thus setting the maximum daily emission to ~4,931 NDX on the day of launch, gradually decreasing to ~1,643 NDX on the final day per the following formula:
rewards(d) = 4931.50684932 - 4.5036592231233*d; 0 <= d < 730; d ∈ ℤ
Our reasoning for this decay is twofold - firstly we need to continue prioritising loyalty for liquidity provision from the get-go, and secondly (as detailed below), the price of NDX is an independent variable in this targeting, and we anticipate a steady rise in said price as the protocol matures, overall TVL rises, value accrual measures are put in place and the Indexed brand gains traction.
Methodology
The key mechanism that we intend to use to make this happen is a fork of the Masterchef contract used by Sushiswap. In effect, Masterchef operates in much the same way as the rewards contracts that we currently have in place, but enables multiple reward pools to be administered from a single location. This is a significantly more scalable solution - given our intent to push out several more index products over time, maintaining a distinct reward pool for each one (or more than one, in the case of multiple DEXes or L1/L2) is a surefire way to guarantee death by a thousand cuts.
More to the point, rewards for pools handled by Masterchef are handled by a single ratePerBlock(poolID, rewardsPerBlock) function: the distribution on a per-pool basis.
In conjunction with this, we would need to implement a contract controlled by a keeper bot (or something of the sort) to loop through the various pools on a retarget - likely daily - and update the Masterchef to reflect the new reward rate. The logic calculating reward rates per pool would be performed off-chain, and retrieved by oracle.
This methodology de facto requires that we include the current NDX price as part of these off-chain calculations, as what we’re truly targeting here (in order to reach optimal slippage) is an APY high enough to attract sufficient liquidity. We don’t yet know what that is, so this would be something of a Bayesian process (i.e. we wouldn’t get it all bang-on on day one, but each day would update our priors and allow us to ‘do better’ subsequently).
The way that this would be implemented in practice is by allocating a ‘flat’ amount per pool per day such that the sum of these amounts is less than the maximum daily emission, as determined by the decay modifier. Any ‘remaining’ NDX not accounted for by these flat rate allocations will be pro-rata’d towards pools with lower TVL as an additional incentive to provide liquidity for them.
Done properly, we can ensure that we aren’t overpaying for liquidity on a given pool for longer than a day, with the option of adjusting rewards ad-hoc. We’re aiming for the most automated and scalable way of handling this going forward.
Note that this proposal would only apply to core indices (DEFI5, CC10, ORCL5 and any others that we introduce in the future) - we want to retain the flexibility of experimenting with the community index reward structures with the pool allocated to the Sigma committee, before migrating these products to ‘core’ after sufficient time has passed for them to become well-established.
An Example
Consider the following hypothetical numbers for TVL/liquidity for three different index pools, assuming these were the only ones that existed:
* DEFI5: US$30m TVL, US$19m liquidity
* CC10: US$20m TVL, US$10m liquidity
* ORCL5: US$10m TVL, US$ 6m liquidity
Assume that it’s day 318 of this emission program: that sets the maximum daily cap of NDX just shy of 3,500 per the equation above. Further, let’s assume that the following daily allocations of NDX as determined off-chain, factoring in the price of NDX at the time of reward calculation, were as follows:
* DEFI5: 600
* CC10: 900
* ORCL5: 1400
Note that the calculation of each amount is considered independent to the others. The above figures allocate 2,900 NDX as ‘flat’ amounts across the three pools, leaving 600 to be pro-rata’d across the pools in a way that favours the smaller pools (by TVL), setting ‘final’ rates for day 318 - which we would then pass along to the Masterchef in order to adjust the appropriate rewards-per-block ratios - as:
* DEFI5: 600 + 100 = 700
* CC10: 900 + 200 = 1100
* ORCL5: 1400 + 300 = 1700
A subsequent retargeting for day 319 might observe that the slippage for DEFI5 failed to meet the target - and rewards should therefore be increased, in order to attract more liquidity via a higher APY. Similarly, we might observe that in fact, we’ve overpaid for ORCL5 liquidity for the day - the slippage target was exceeded, and really we’ve just provided free alpha. It might further be observed that the price of NDX itself tanked somewhat during day 318, and therefore more needs to be allocated via flat amount, using up the pro-rata ‘buffer’ present in order to bolster APYs accordingly.
As we’ve already mentioned - this process isn’t one that we’ll get right off the bat. There’ll be days where we’re basically giving NDX away for effectively no reason (since the liquidity was already present and we didn’t really need to incentivise anything), and others where we’re just trying to bolster the walls due to negative price action of NDX itself throwing our APY targets off-course and making liquidity provision unattractive to yield farmers. However, the ability to retarget daily - and factor in the price of NDX itself - grants us room to manouvre that we will substantially benefit from.
General Observations
Finally, some observations about both the future, and an alternative to this proposal:
Migrating To L2 Pools
In our opinion, the best move to make regarding L2 liquidity is - at present - to wait. Once a clear winner has been established (and at the time of writing, it’s looking like it’ll be Optimism, although that may change fast), multiple pools per index can be introduced, with rewards gradually shifted from the L1 to L2 variants in order to encourage migration. Again, our primary focus here is to enable painless, inexpensive transfer of the index LPs themselves on DEXes: and that is an action best supported via L2.
An Aside Re. A Potential Vote-Escrowed NDX
The ‘other’ major way of handling this allocation of rewards to pools is the way that veCRV handles it: allowing members of the DAO who have vote-escrowed their governance tokens to determine the rates per pool.
Should this proposal be enacted, and a later decision is made by the DAO to migrate towards this model, control of the reallocation contract can easily be handed over to a contract owned by ‘veNDX’ governance.
Call For Comments/Discussion
As you can imagine, this is a fairly substantive shift, enacted over a significant time-period. Technically, this isn’t that hard to make happen, but we’d be remiss if we didn’t give this proposal time to air in public first in order to address any comments or concerns.
We might be suffering from the curse of knowledge here, whereby concepts that we take as things that people are intimately acquainted with are actually completely new to most of the general population. So, as an appeal - if there are things that aren’t clear here, ask us.
Let’s hear it!
(LOL)
