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

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

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

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

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

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

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

@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

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

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

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

1 Like

@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

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

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

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

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

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

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

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

@mel.eth @sixtykeys I would like to temporarily pause the snapshot vote while we work with Visor on security and parameter considerations.

6 Likes