Initial NDX Liquidity Rewards Allocation Strategy
Per this vote on Snapshot, the Indexed DAO has agreed to fund the first few months of the new dynamic staking program via the remaining Sigma program token allocation, and grant the Sigma committee the role of points allocator to begin with.
In this thread, we present the model that the Sigma committee will initially be using to allocate points to the various LP pools and single-sided (“naked”) staking pools that will be introduced.
We’ll flesh out an example as we go, based on figures taken a few days ago, and currently available to play around with via this Google Sheet.
Note: I may make some edits to this post as I come back to it with fresh eyes. If I do, I’ll say as much here.
The TL;DR Up Front
To start, we will be allocating rewards to LPs parameterized by ‘base scores’ derived from the TVLs of each ETF and a modifier derived from the required delta between currently available and desired liquidity levels. All LP pools will target Uniswap V2 to begin with: at least until there’s a standard way of ‘doing’ liquidity mining for V3.
In addition, we will be allocating a proportion of rewards to single-sided staking for the three highest ETFs by TVL, subject to a scaling factor - the closer our ETFs are to their liquidity goals, the more rewards will be made available for single-sided staking, and vice-versa.
On ETF Tiers
We have observed that - naturally - some of our ETFs are more popular than others, either due to performance or the market sector that they target. The comparative TVLs of each of these ETFs is instructive, as they tell us which ones are being widely taken up by users.
We have decided that it is a better usage of reward tokens to target slippage levels relative to TVL, rather than set a flat slippage target of 1% for a 10 ETH buy across everything. For ETFs such as ORCL5, the required increase of liquidity to hit 1% would create perverse incentives, whereby people mint and provide liquidity to the LP pool simply to farm rewards (we have the single-sided pools to cater to the more mercenary amongst you!) .
Our initial thinking is to use the following levels to stratify ETF tiers:
| Tier | Base Score | TVL | Target Slippage @ 10 ETH |
|---|---|---|---|
| 1 | 10 | >= US$10,000,000 | 0.5% |
| 2 | 5 | >= US$5,000,000 | 2% |
| 3 | 1 | >= US$1,000,000 | 5% |
| 4 | 0.5 | < US$1,000,000 | 10% |
The above slippage numbers may seem alarming for the lower tiers, but it’s important to remember that they’re against 10 ETH trades: if someone wanted to trade that much of a Tier 4 ETF (i.e. has a TVL of under a million dollars) they’d be moving the market quite heavily anyway - it is far better for them to mint or burn in that case.
According to the above table, this would classify our six current ETFs as follows:
| ETF | TVL | Tier | Base Score |
|---|---|---|---|
| DEFI5 | 19,137,022.01 | 1 | 1000 |
| CC10 | 8,048,995.52 | 2 | 500 |
| ORCL5 | 776,167.81 | 4 | 50 |
| DEGEN | 8,897,568.89 | 2 | 500 |
| NFTP | 1,685,580.65 | 3 | 100 |
| ERROR | 1,810,365.72 | 3 | 100 |
On Real Versus Desired Liquidity
To beat a dead horse a bit more - the key goal here is to incentivize sufficient liquidity for these target slippage levels to be reached. The magic number for this liquidity in Uniswap AMMs (because of the 50/50 split) is the solution to the following:
slippage = (eth_in_trade - eth_fee) / eth_in_pool
In each case, we know the slippage (dependent on ETF tier), we know that eth_in_trade is always 10 and we know that eth_fee is always 0.03 (since Uniswap V2 fees are fixed at 0.3%).
As such, we can calculate an estimated amount of required liquidity in USD per the following:
desired_liquidity = 9.97 / slippage * eth_price * 2
Note: we could quote desired liquidity in ETH here, but V2 analytics pages show total current liquidity in USD, and it doesn’t really make much difference either way, as it’s just a shift in numeraire.
Given the desired liquidity for an AMM and the current liquidity available, it’s easy enough to calculate the delta between the two as follows:
delta = (target_liquidity - real_liquidity) / real_liquidity
Finalizing Liquidity Mining Allocation Points
With liquidity deltas in hand, we now calculate the allocation points for each LP pair as:
etf_alloc_points = round((1 + delta) * base_score)
Assuming an ETH price of US$3,500 and a snapshot of real liquidity values for the various {ETF}/ETH pairs, this gives us the following:
| LP Pair | Base | Real Liq. | Target Liq. | Liq. Delta | Points |
|---|---|---|---|---|---|
| DEFI5-ETH | 1000 | 13,111,907 | 13,958,000 | 0.06452859984 | 1065 |
| CC10-ETH | 500 | 2,241,946 | 2,791,600 | 0.2451682601 | 623 |
| ORCL5-ETH | 50 | 540,633 | 697,900 | 0.2908941925 | 65 |
| DEGEN-ETH | 500 | 3,686,602 | 2,791,600 | -0.2427715278 | 379 |
| NFTP-ETH | 100 | 1,153,150 | 1,395,800 | 0.2104236223 | 121 |
| ERROR-ETH | 100 | 2,389,709 | 1,395,800 | -0.4159121466 | 58 |
| Totals | 2250 | 0.1523310003 | 2311 |
On Reintroducing Single-Sided Staking
In addition to the above, we will be allocating a proportion of rewards to single-sided staking (i.e. rewarding DEFI5 rather than DEFI5/ETH LP) for the top three ETFs by TVL.
Our reasoning for this is twofold:
- We anticipate that this will increase TVL in the long-term, as mercenary farmers mint more ETF tokens to participate. This corresponds, ultimately, to an increase in unrealised protocol revenue (in the form of exit fees) and a long-term boost to protocol statistics.
- We would sooner that said mercenary farmers participated in single-sided staking than liquidity farming, as being beholden to whimsical liquidity (as farmers hop between the ‘best’ pools) is less than ideal. Give the mercs a sandbox, and let dedicated providers have the rest.
The way that we intend to do this is to allocate a flat number of allocation points to single-sided staking, which is split according to the relative TVLs of the top three ETFs and multiplied by a scaling factor <= 1 that is defined as:
scaling_factor = 1/(1 + abs(total_liquidity_delta))
That is to say - the closer the total liquidity delta is to zero (i.e. the closer we are to having exactly as much liquidity as required across the board), the closer to 1 the scaling factor will be. In the event that liquidity is thrown severely out of sync, the resulting scaling factor will reduce the amount of allocation points assigned to the single-sided staking pools in favour of buffering the liquidity pool rewards.
The Sigma committee reserves the right to shrink or increase the flat amount of allocation points allocated to single-sided staking based on shifts in the total liquidity delta, and - in extreme cases - temporarily terminate single-sided staking entirely.
A Full Example Allocation
As an example, if we set the flat allocation points for single-sided staking as 1,000, then using the figures given above we would end up with the following ‘final’ allocation points across the board for a given time period:
| ETF | TVL | TVL % | Init Points | Scaling Factor* | Points | Points % |
|---|---|---|---|---|---|---|
| DEFI5 | 19,137,022.01 | 53.03% | 530 | 0.8678062117 | 460 | 14.47% |
| CC10 | 8,048,995.52 | 22.3% | 223 | 0.8678062117 | 194 | 6.10% |
| DEGEN | 8,897,568.89 | 24.65% | 247 | 0.8678062117 | 214 | 6.73% |
| Totals | 36,083,586.42 | 1000 | 868 | 27.30% |
* Scaling factor: 1/(1 + |0.1523310003|) = 0.8678062117
| LP Pair | Base | Real Liq. | Target Liq. | Liq. Delta | Points | Points % |
|---|---|---|---|---|---|---|
| DEFI5-ETH | 1000 | 13,111,907 | 13,958,000 | 0.06452859984 | 1065 | 33.5% |
| CC10-ETH | 500 | 2,241,946 | 2,791,600 | 0.2451682601 | 623 | 19.60% |
| ORCL5-ETH | 50 | 540,633 | 697,900 | 0.2908941925 | 65 | 2.04% |
| DEGEN-ETH | 500 | 3,686,602 | 2,791,600 | -0.2427715278 | 379 | 11.92% |
| NFTP-ETH | 100 | 1,153,150 | 1,395,800 | 0.2104236223 | 121 | 3.81% |
| ERROR-ETH | 100 | 2,389,709 | 1,395,800 | -0.4159121466 | 58 | 1.82% |
| Totals | 2250 | 0.1523310003 | 2311 | 72.7% |
On Gaming The System
We do not expect to see mercs gaming the system by minting enough of a smaller ETF to push it into the top three for a single-sided allocation. This is because someone attempting to do this would more than likely lose more in the inevitable 0.5% burn fee once they exited than they’d receive from the associated reward pool (at least at present NDX prices). Nonetheless, we’re aware of the possibility.
In order to avoid people attempting to make adversarial moves, we won’t be publicising the frequency with which we will be reallocating points to start, or run updates on a set schedule. Remember that the Sigma committee will have to 3-out-of-5 approve any shifts to allocation points, and sometimes we’re just not all around at once!
It’s worth remembering that even with the proportions allocated above, the amount of tokens handed out over {X} time isn’t fixed day-in-day-out: the linear decay on emissions means that we’ll be slowly shutting off the tap from the second we start (it’ll just take us two years to stop it).
Conclusion
This is primarily a data-gathering exercise to start (as well as one in increasing the liquid supply of NDX), so we’ll be keeping a sharp eye on the figures and publicising them as they come out.
This isn’t… actually all that mathsy, so I’m hoping that we can get some detailed feedback from the community about their thoughts on all of it. We have a week to discuss this before the staking contract goes live, due to the timelock on the tokens within the Sigma vault (the countdown for which was triggered yesterday).
I’ll pop this up on Twitter and Medium once the vanguard is through the door and has had a look. If you have better ideas, or refinements/thoughts - I do want to hear them!
TL;DR of TL;DR
We’re back!