[Proposal] Dynamic Reward Emission Schedule

Dynamic Reward Emission Schedule

Authors: Dr Laurence E. Day, blurr, Lito Coen


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.


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!


I still believe we should incentivize long term holding of liquidity. I am not clear how MasterChef handles the length of time liquidity is provided & rewarded.

1 Like

I’m unfamiliar with Masterchef so does this rebalancing of rewards only affect the Sushiswap LP’s or does it also have the ability to manage Uniswaps LP’s?

I had never heard of vote-escrow so I just did a little research and this option actually looks very promising. Since we just had an issue getting the 400k votes for the stop-gap proposal wouldn’t the vote-escrow system incentivize more people to use their voting power? This option also seems to address the idea @Glueeater suggested by incentivizing long term holding. Also I’ll oust myself here but I did not vote for the stop-gap proposal because it was going to cost me $25 in gas to do so, i’m not sure how vote-escrow handles voting exactly but it seems like it also solves the issue of requiring gas to vote.

Hi, very clear and well explained !

But when you said :

Why don’t you wrote "d ∈ N " ? :thinking: (LOL)

Because 0 ∉ ℕ, sir. :wink:

Shame on me ! :man_facepalming:

1 Like

To answer this - Masterchef is used for Sushiswap, but could equally well apply to Uniswap. It was designed for the former, but easily ports to the latter.

For example, if - for whatever reason - it was desired that we ran L1 reward pools for Uniswap and Sushiswap, and also an L2 pool on Quickswap for the same index, we’d be able to handle that.

@blurr has more refined thoughts than me on the benefits of utilising vote-escrow rather than the current model, but I’d like to keep discussion in this thread about the reward emissions themselves rather than forking off into separate chats.

To @Glueeater’s point - this doesn’t encode any kind of restriction on rewards being ‘retained’ post-issuance subject to receipt - you can claim what you get, as you get it, on a block by block basis. I’m going to put myself in their shoes here and imagine that an ‘ideal’ fix to this is something akin to a “the amount of NDX that you actually receive for providing liquidity is subject to a sliding scale: you get the full amount after locking it in for a month, half if you do it for a week” system.

I don’t know if we want to go down that route, if only because it adds a layer of complexity in (or if that’s even the kind of idea you have in mind), but that’s the purpose of this being up for discussion!

1 Like

This is a very well-thought out proposal, and would definitely support it. But, might it be better to utilize the veCRV system right from the get go? I am not familiar with either enough to know the technical differences/implementation difficulty.

Curve’s tokenomics are widely praised (with token value holding up quite well given the substantial emissions), and the pool gauge voting mechanism alone gives good value accrual to the CRV token. Ideally we might consider borrowing the reward multipliers dependent on veNDX locked and the fee rewards mechanism at some point as well. I understand discussions/proposals are coming for NDX value accrual, but this could be an early/important element to it.

The veCRV system is also considerably more flexible in handling additional pools, in this case index tokens. Perhaps new index tokens launched could start with the Sigma rewards, and graduate to the veNDX (simplify to to vNDX?) rewards after a period of time or when a TVL threshold is met. The veNDX system may also solve much of the concerns you mentioned around providing rewards for ‘effectively no reason’, allowing index gauge votes to more rapidly deploy rewards where they are needed. It may however lose some of the ability to react to the reduced slippage objective.


I agree with the decaying model of NDX emission and utilizing Masterchef contract to allocate rewards across different pools. This feels like a solid way to allocate rewards in a fair manner.

On the other hand, I don’t see how your proposal can promote value accrual for NDX token (e.g. users still don’t feel a need to hold NDX tokens for long term). Others have suggested Curve’s vote escrow model, but I think it is quite complex and not suitable for Indexed. I imagine users who use Indexed are not power users (that’s why they bought index token in the first place), so adding a vote escrow model might confuse them, as they would need to think about different kinds of strategy to maximize their yield.

1 Like

I’ll focus on one point here: this proposal doesn’t deal with value accrual. That’ll be dealt with in a future, distinct proposal (hence the phrase “first in a series”). Don’t want to mix up the colours, as it were.

But, even though I want to keep the thread on topic, I disagree with you when it comes to the level of native knowledge we can assume from people regarding understanding of a potential escrow model, given who would be affected: there’s a vast gulf between those we’re ultimately targeting as a growth set (the “hey, want exposure to crypto without the research? grab these” population), and those who are crypto-native and familiar with the mechanics of yield-farming/staking et al.

We wouldn’t/shouldn’t expect the former group to feel a need to hold NDX or LP tokens: let them trade the assets we provide on the platform. The latter category are probably already familiar with Curve’s tokenomic model and might just need a refresher.

Anyway, I’m glad to hear you approve - thanks!

1 Like

This proposal incentivizes people to purchase the token with the lowest total value locked and provide added liquidity for it. Doing the same for the best-performing tokens is the least profitable. If these are all established indices, then a token’s TVL is probably low for a reason; perhaps this particular segment of the cryptosphere that the index tracks just isn’t destined to take off, or maybe the index size is too large and includes too many detrimental tokens. Encouraging people to buy the worst product available doesn’t seem like a productive venture.

If the point of the rewards is to incentivize providing liquidity, then the calculation should be based on how much of the TVL for each index token is actually in a liquidity pool. Based on the example in the proposal, the allotments would be a different.

* DEFI5: US$30m TVL, US$19m liquidity | 63.3% liquidity of total TVL
* CC10:  US$20m TVL, US$10m liquidity | 50.0% liquidity of total TVL
* ORCL5: US$10m TVL,  US$6m liquidity | 60.0% liquidity of total TVL

In that case it’s actually CC10 that is the most illiquid token and should have the greatest incentives.

As it is, the proposal seems to act as a bailout for the most unpopular tokens, and that philosophy is built in from the start and remains for the entire duration of the emission schedule. I think the best approach is to let the actual indices speak for themsevles in acquiring TVL, and, like any weak ETF, let them die if they fail to perform without focusing most of the attention on reviving them.


I have written a fork of MasterChef called MultiTokenStaking. This is a very generic contract based on MasterChefV2, meaning we can also enable dual token incentives for partnerships or future upgrades. The modifications include:

  • Tokens are assumed to already be held, rather than being minted.
  • There are no “bonus blocks” and there is no hard-coded emission rate; instead, you assign a contract which exposes getRewardsForBlockRange(uint blockFrom, uint blockTo).
  • The owner can withdraw the reward tokens (allows us to decide to migrate our staking rewards in the future)
  • The owner can set a pointsAllocator address which is able to assign allocation points, i.e. determine the distribution of each block’s rewards among the various staking tokens. This would allow us to use a smart contract or multisig to assign rewards without locking ourselves into a particular model.

This would allow us to try out various methods of allocating liquidity between pools and can be used without migration regardless of other protocol upgrades.

1 Like