PROPOSED: IIP-109: Deploy Protocol-Owned INDEX/ETH Liquidity into Managed Visor Vault on Uniswap v3

Governance Proposal
1

Status: PROPOSED
Author(s): @jdcook (Index Coop) @bp333 (Visor)
Discussions-to: PROPOSED: IIP-109: Deploy Protocol-Owned INDEX/ETH Liquidity into Managed Visor Vault on Uniswap v3
Created: 19 November 2021

Summary

There is (at the time of writing) ~$1.55m TVL in the INDEX/ETH 1% Uniswap v3 pool. Roughly ~80%+ of that liquidity is placed above the current price. A 10 ETH buy comes with a 2.51% price impact. Capital is discouraged from entering positions in INDEX due to the lack of liquidity. The INDEX token is susceptible to major price swings caused by relatively minor buys and sells. We need to facilitate a more liquid INDEX market.

We also have an opportunity to build protocol-owned liquidity - this gives us more control to manage INDEX liquidity as well as turns INDEX and ETH into fee-earning assets for the Treasury.

We propose the following:

  1. Exchange ETH2x-FLI currently in the Operations Account for ETH
  2. Pair ETH with the requisite amount of INDEX
  3. Deploy INDEX/ETH concentrated liquidity into a managed Visor vault on top of the INDEX/ETH 1.0% Uniswap v3 pool

Visor will manage our protocol-owned INDEX/ETH liquidity to optimize for price impact, yield, and availability of liquidity.

This will allow us to:

  • 2-4x the INDEX liquidity on the most capital efficient INDEX/ETH pool we have (targeting ~$3m in liquidity post strategy)
  • Build protocol-owned INDEX liquidity (targeting ~40-50% of the pool post strategy)

Motivation

Why focus on INDEX liquidity now?

INDEX liquidity is a problem right now for a variety of reasons (want to credit @tradespot and others who have highlighted some of these in an initial post and discussion here):

  • A 10 ETH buy on 1inch (aggregator) comes with a 2.51% price impact - capital is discouraged from entering positions in INDEX due to the lack of liquidity
  • INDEX is susceptible to major price swings caused by relatively minor buys and sells
  • The more illiquid and suppressed INDEX is the less healthy our treasury is - the less healthy we are overall as a project.
  • INDEX drives momentum to our products
  • INDEX doesn’t realize its gov and meta-gov power if it is illiquid
  • Facilitating trading will increase flow to INDEX and outside liquidity provision - providing liquidity now can kickstart a more sustainable foundation for INDEX liquidity

Why Uniswap v3?

  • Capital Efficiency - by concentrating liquidity around the current price we can lower price impact much more significantly with the same amount of capital (when compared to non-concentrated pools such as Sushi, Uni v2). The example below shows that by concentrating liquidity around a +/- 50% band, as opposed to providing liquidity at all prices, you can achieve ~4x capital efficiency.

730×346 33.9 KB

  • Higher Fees - by concentrating liquidity, the liquidity provider can potentially earn a higher fee multiple than on Uni v2 or Sushi. Additionally, the added TVL to the Uni v3 pool will absorb more volume as price impact is lowered for traders. This will signal to outside LPs to bring more capital to the pool - concentrated liquidity becomes much more sustainable.
  • Uniswap v3 Price Oracle - the performance of TWAP oracles has improved significantly. It is faster and cheaper to check the recent prices of assets. If requested, all the recent TWAPs calculated within the last nine days can be checked.

Why protocol-owned liquidity?

Historically, we have been at the mercy of the decisions of others to facilitate strong liquidity for INDEX and Index Coop products. We will likely always have that dynamic to an extent, but our past experiences incentivizing and migrating liquidity should prove that those are not sustainable patterns. By owning and/or controlling liquidity we have levers to pull and push to ensure we meet our liquidity targets. We also open up an additional revenue stream that can create a sustainable liquidity flywheel as we re-invest revenue from trading fees back into protocol-owned liquidity.

Why Visor?

Visor is an active liquidity management protocol. Concentrated liquidity pools bring increased capital efficiency, but they also bring increased sophistication and management. Visor takes on the overhead of managing liquidity such that it stays effective and continues earning trading fees. Visor takes 10% of earned fees, which get distributed to VISR stakers - the other 90% of earned fees will be automatically invested into the LP position upon each rebalance. Visor covers all gas fees for rebalancing positions and re-investing earned fees.

As we set off on our protocol-owned liquidity journey - it is paramount to have a quality partner such as Visor to help us ensure our liquidity stays effective and efficient, as well as to help us minimize impermanent loss.

Specification

Exchange ~$700k USD worth of ETH2x-FLI (or all ETH2x-FLI if USD value is below $700k) in the Operations Account to ETH. The requisite ETH and matching INDEX (in rough USD amount, estimating around ~34,000 INDEX and ~170 ETH) will be sent to the Operations Account from where the liquidity will be deployed.

Supply the ~$1.4m liquidity to the Visor position manager contract called the Hypervisor. The Hypervisor will mint fungible ERC-20 LP tokens to a whitelisted address provided by Index Coop. Only the whitelisted address provided by Index Coop will have the right to deposit / withdraw assets to and from the Hypervisor. The Hypervisor has the right to a few managerial functions which are to set price ranges, set range orders, collect fees, rebalance, and mint/burn LP tokens to the whitelisted address. Therefore, the Hypervisor contract is non-custodial in that only the provided whitelisted address may deposit/withdraw assets into and out of the contract. The vault will remain private initially at least until an APR can be established, after which, it will be open to the public on Visor’s UI for depositing by public LPs.

Gamma Strategies (Visor-funded research organization) will manage the price ranges according to an autoregressive strategy which will widen the bands during periods of high volatility and narrow the bands during low volatility periods.

In terms of price impact, the current price impact at the time of writing this proposal is 2.51% for a 10 ETH buy order. After this deployment, the buy-side price impact for a 10 ETH order will be approximately 0.7 - 1.7%, depending on price volatility and range. However, all of these approximations are subject to change based on the characteristics of external liquidity and the price of ETH relative to INDEX.

See and toggle calculations [here].(INDEX Calculations - Google Sheets)

Alternative

Outside of not provisioning any INDEX/ETH liquidity from the Treasury, one other alternative was strongly considered. If it turns out there is stronger appetite for this option - we believe it would also be an effective way at initiating a protocol-owned INDEX/ETH position. A simple summary (don’t want to distract too much but want to offer the alternative):

Place a single-sided range order from one tick above the current price tick to 20% above the current price tick. As the current price of ETH/INDEX moves into the range, the position will gradually convert to ETH. Once a 50/50 ratio of ETH to INDEX is reached, the position will be rebalanced over a wider range and managed. This would allow us to initiate a position using only INDEX from the treasury (no need to exchange any assets). It would also cause some short-term price suppression by creating a lot of liquidity above the current price.

Voting

For

Exchange ~$700k worth of ETH2x-FLI for ETH and pair with INDEX to deploy protocol-owned INDEX/ETH liquidity into a managed Visor vault on Uniswap v3

Against

Do not exchange ~$700k worth of ETH2x-FLI for ETH to pair with INDEX to deploy protocol-owned INDEX/ETH liquidity into a managed Visor vault on Uniswap v3

Temperature Check Poll

  • FOR
  • AGAINST

0 voters

12 Likes
2

Very excited to start seeing this go through the pipes and thank you @jdcook @bp333. I agree with the method of liquidity being sourced and provisioned so it’s a big FOR from me.

4 Likes
3

Also very excited to see this proposal – this is a must have. I hope it turns out that we’re selling the $DPI / $ETH bottom down here, but its no sure thing. Voting FOR.

2 Likes
4

Voted FOR but will just state for the record a DPI to ETH sale here would be crystalising the DPI:ETH underperformance to date. Obviously, there is no knowing where DPI:ETH goes from here and it could fall further but thought I’d at least point it out so everyone is aware.

$700k seems reasonable to deploy here given risk/reward

3 Likes
5

I am broadly in favour of this proposal, with a few questions to make sure I’m on the same page.

I would rather hold the DPI for creating DPI:ETH pools on L2. With that potential use case in mind, may I suggest using the ETH from the ETH2x-FLI position. Selling ETH2x-FLI is already IIP approved and is on going. I strongly suggest holding DPI and funding this proposal through selling ETH2x-FLI.

Can we confirm here the liquidity spread is optimised for traders over considerations for wider liquidity distribution which supports better oracle feeds? The later enables INDEX to be added to our Fuse pool, the trader optimised liquidity spread less so.

I am confident that if a robust oracle is created then we can unlock INDEX listings on Beta Finance and Rari Capital which gives more extrinsic use cases to the INDEX token.

@BigSky7 @Mringz - Does BDWG have any feedback what this could do to the Sushiswap relationship given Sushiswap incentivised the INDEX:ETH pair and now it appears we are directly increasing AUM on a competing DEX on the same pool. Conscious this may influence the SUSHI incentives that DATA:ETH receives as well as the broader relationship. Perhaps something we need to get ahead of and manage ahead of implementation…

5 Likes
6

I am all for using the ETH2x-FLI to exchange into ETH. The reason I proposed DPI originally was because I was under assumption we were slowly DCA’ing out of our ETH2x-FLI position, and this is intended to move quicker - but yes, if we can do so then let’s use the ETH2x-FLI and keep the DPI for POL on DPI pools.

I will let @bp333 speak to this as the expert on the strategy. My understanding is it will widen and narrow at different times, but should compromise pretty fairly between the two (thinking like an average of +/- 50% of the current price).

Happy to hear perspectives on this, although I will say upfront that I don’t believe this should be a strong consideration. Providing effective liquidity is our goal first and foremost. We already have more pools on Uniswap than Sushiswap in aggregate anyways.

5 Likes
7

This a great first experiment for the Liquidity Pod. Ultimately, would like for subsequent similar proposals to not go through a full IIP as these decisions will be made by the Liquidity Pod.

6 Likes
8

@Thomas_Hepner beat me to it. I’m FOR this proposal and hope in the future this will be an update from Liquidity Pod instead of an IIP!

2 Likes
9

Strongly in favor of this proposal, and in favor of sourcing the ETH we need for the INDEX / ETH pair from the ETH2x-FLI position held by the treasury today!

5 Likes
10

Generally for this proposal. I would just like clarity around the safety of using Visor. They have been compromised before do we have an insurance solution or assurances that we cannot lose funds on their platform?

I agree with you here JD. I do not think it will affect the relationship. We are chasing capital efficiency and we do not get that with Sushiswap on mainnet. We are supporting Sushiswap on Polygon with other pairs and will probably continue to do so with the upcoming products coming out on Polygon.

5 Likes
11

Wasn’t aware of this. Do you have a link? Thanks

12
1 Like
13

@Mringz with regards to this point, the compromise was in the early beta days of launching our v3 vaults. We had included within vault functionality an emergency withdraw function, which should have been only callable by a multisig and that was our mistake. Since then, that functionality has been completely removed as indicated by the audit report here: Visor Finance - CertiK Security Leaderboard.

Now, our vaults are completely noncustodial in that only the LPs can deposit / withdraw to and from the hypervisor. These deposits and withdrawals can happen at any time when called. The hypervisor contract itself only has managerial functions such as rebalance, set limit orders, collect fees & reinvest fees. The worst that can happen is bad management, but at that point the funds may be withdrawn. Additionally, for further security measures, we are integrated with Nexus Mutual here: Nexus Mutual - Buy cover

4 Likes
14

Can we confirm here the liquidity spread is optimised for traders over considerations for wider liquidity distribution which supports better oracle feeds? The later enables INDEX to be added to our Fuse pool, the trader optimised liquidity spread less so.

I am assuming by optimizing the vault for traders, you are suggesting that slippage is minimized for trades. The strategy will be running an autoregressive strategy as described here: active-strategy-framework/2_AutoRegressive_Strategy_Example.ipynb at main · GammaStrategies/active-strategy-framework · GitHub

The main tenets of this strategy is to widen the bands (+/- 100%) during periods of high volatility and narrow the bands (~ +/- 30%) during periods of low volatility to minimize impermanent loss and generate high fee revenues during periods of low volatility.

We can, however, alter the strategy to optimize for traders by setting tighter bands; however, the tradeoff there would be that the LPs would likely suffer from larger impermanent loss. If the vaults were to remain public, we suggest using the autoregressive strategy as it does protect the LPs more from impermanent loss and having more liquidity within the pool would strengthen the robustness of the oracle.

5 Likes
15

As I suggested previously in the wintermute discussion we should have focused 1st on $INDEX liquidity before that proposal and deployed treasury capital in an LPI pool.

If you have no ETH in treasury then you can’t do anything. $DPI vs ETH is at a poor level to sell but why impact $INDEX price further with single sided order.

I track the sells and these look like a mix of contributors and LM. You either put these through the Treasury or own the bulk of the LP pool.

Personally I think liquidity is a core competency of Index Coop so should be managed in house. It’s really a Treasury function.

1 Like
16

UPDATE: I have updated the proposal to target ETH2x-FLI as the asset to exchange into ETH (from the Operations Account) rather than DPI (from the Treasury).

We have plans for Protocol-Owned DPI liquidity as well, so holding that DPI is advantageous in that regard.

@mel.eth can I get an IIP number assigned and get this scheduled to go to snapshot vote?

4 Likes
17

gm @jdcook,

IIP No. 109 has been assigned and the status has been changed from DRAFT to PROPOSED per the process outlined here. After 48-hours in the PROPOSED state you may call for a snapshot vote to be scheduled provided no changes have been made to the above post.

As IIP Editors we are generally amenable to scheduling the snapshot vote ahead of the close of the 48-hour discussion window (mainly an operational consideration to ensure timely posting to snapshot), however the the author must still make the ‘call for vote’ subsequent to the 48-hour period as this confirms that no changes have-been/will-be made and the author is formally making the request that the proposal be put forth for a vote after discussion has been taken into consideration.

cc: @sixtykeys @Mringz @Lavi
cc historic context: @anon10525910 @dylan @Pepperoni_Joe

3 Likes
18

Hey @mel.eth @Mringz @Lavi

Given 48 hours have passed in the proposed state with no changes, may we schedule the snapshot vote?

Thanks!

4 Likes
19

gm @jdcook and @bp333

This proposal has been queued for voting to commence on 29 November 2021 and will be open for 72 hours.

Please click Hootie to vote: :owl:

cc: @sixtykeys

4 Likes
20

Late to chip in but strongly in favour and will vote FOR. It feels like we’re grasping this nettle a touch late (no fingers pointed at anyone in particular), given where $INDEX is and the nature of the sell pressure driving it there, but I’m really excited to see how this goes - and have these strategies get conceived and deployed through the liquidity pod in time too.

Awesome work @jdcook - thank you.

Having thought this was something we should ‘pay the professionals for and forget about’ and focus on building products, I am thinking there’s a lot of be said for owning liquidity provision ourselves during times where our Treasury is a lot larger than the currently typical monthly sell pressures.

2 Likes