[DRAFT FOR DISCUSSION] Sustainable Direct Liquidity Provision for Simple Indices

IIP: [to be assigned]
Title: Index Coop Sustainable Direct Liquidity Provision for Simple Indices
Status: [Draft]
Author: @mel.eth
Created: September 17, 2021
Requires IIP-59
Implementation: TWG, PWG

‌Request for discussion:

Simple Summary

‌Deploy $1MM of equivalent liquidity on UNI v3 at the 0.05% fee level across five total pairings:

Two INDEX pairs to introduce high liquidity:

  • INDEX:ETH (0.05%) at $200k
  • INDEX:USDC (0.05%) at $200k

And three INDEX:product pairs to capitalize on the increased liquidity:

  • INDEX:DPI (0.05%) at $200k
  • INDEX:MVI (0.05%) at $200k
  • INDEX:DATA (0.05%) at $200k

This will:

  • Make the fee for retail-trading no more than 0.1% for any hop from ETH or USDC to an IC simple index product and make the hop from ETH or USDC to INDEX only 0.05%;
  • Provide ongoing operational revenue for the PWG; and
  • Reduce or eliminate the need for providing LP incentives on mainnet.


Abstract

‌This proposal, if enacted, would deploy the equivalent of $1MM in liquidity across five pairs comprised of approximately $500k in INDEX, $100k in ETH, $100k in USDC, $100k in DPI, $100k in MVI, and $100k in DATA.

Motivation

‌Currently there is low-liquidity and high-slippage related to the INDEX token and a strong push otherwise to increase liquidity (reduce slippage) among IC core simple-index products. The UNI v3 interface allows for enhanced capital efficiency as compared with other DEXes, allowing IC to leverage a small amount of capital in tokens that are either readily available or easy to swap into with low slippage.

This strategy has the dual benefit of increasing swap routes (the 0.05% fee level of these pairings does not exist yet with the exception of approximately $20k in INDEX:ETH liquidity), thus reducing slippage, while simultaneously increasing IC’s revenue/holdings of both INDEX and core products over time.

Additionally, given that the revenue due to market growth will increase as spot price of the underlying assets increases, this pool will likely not require additional funding to support all simple-index products and should still be able to accommodate future product launches. Tying INDEX to our products is a show of faith on our part, and will reduce volatility as the amount of INDEX on the open market would be increased while diversifying it across non-ETH pairings that are expected to increase in price over time.

A 0-∞ liquidity provision would require no maintenance; however, it would not provide the level of capital efficiency that renders the subject pools more useful than v2. The goal here is to strike a balance between a set-and-forget LP strategy and one that improves swap efficiency and generates some self-sustaining yield. Beyond the initial deployment and monitoring phase to ensure that bands are effective and ranges hold, the effort to monitor should be on the order of hours per month, and a redeployment (in the case of bands being deemed too constrictive or addition of a simple index product) should take less than a day in terms of calculation and execution and would otherwise occur at intervals of approximately 3-months.

Specification

Overview

As it stands, INDEX is widely regarded as a low-liquidity token and a great deal of INDEX have been expended in an attempt to incentivise less-than-ideal liquidity provisions across simple index products. While directly providing liquidity places capital at risk instead of spending a known amount of INDEX tokens directly, it offers the chance to earn fees and deploy liquidity with greater accuracy than an incentive structure.

Although liquidity providers and The Index Coop are both motivated by profit, liquidity providers tend to be agnostic to other externalities, whereas Index Coop also wants to minimize fees and hassle for users of our products. As it stands, the capital efficiencies offered by Uniswap v3 are currently unmatched in the DEX space, allowing relatively small amounts of capital to be deployed yielding a large impact to the liquidity profile that a token offers, especially when considering that most users are routing through DEX aggregators or using Uniswap directly.

While the fees earned at the 0.05% level proposed are not expected to be a significant source of revenue, they should be enough to at least reward a small team for managing the liquidity provision. The pool will grow over time, be equally redistributed among new and existing simple INDEX products, and as contemplated require no additional liquidity to be added in order to meet the liquidity needs of Index Coop simple index products over the coming years. A self-sustaining liquidity engine that helps power a positive user experience, forever.

The positions will be controlled via the PWG account [@overanalyser input needed on feasibility here] with revenue (less PWG contributor reward expenses) being redeployed in any subsequent liquidity redeployment.

Rationale

The multiverse of options available when considering liquidity are effectively infinite; however, the main factor leading to this proposal being put forth is retail-end-user-experience. This solution addresses the liquidity concerns of not only the INDEX token, but also the core simple index product offerings and effectively caps the fee for relatively small traders at 0.1%, well below the 0.3% and 1% provisions that are attractive to LPs. While gas fees are slightly higher on a multi-hop trade, that amount is negligible compared to the fee savings for most trades and initial research suggested that liquidity from most swaps was coming from more than one source already at the higher fee tranches.

Technical Specification

‌Approx $500-$1,000 per pair in gas for initial deployment (<$5k total); approx $300 per pair for rebalances (remove / swap / redeploy)

Simple steps to be expanded through discussion and prior to IIP submission:

  1. Calculate exact token amounts needed based on liquidity provision bands above;
  2. Transfer available tokens to PWG multi-sig and swap if necessary;
  3. Deploy LP positions on v3;
  4. Monitor range; and
  5. Redeploy in 3-6 months or when new product is launched.

The ranges utilized for each pair will be determined by the following process:

Determine the range of token ratios that have been realized over the previous 6-month period (when available) and calculate the upper and lower bounds of the liquidity provision as follows:

  1. Finding upper limits (UL) and lower limits (LL)
    a. Use tradingview or similar platform find the UL and LL values of the subject pair over the previous 6-month period

  2. Calculate position bounds

    a. Calculate the Upper Bound (UB) of the LP position
    UB = 2*UL
    b. Calculate Lower Bound (LB) of the LP position
    LB = 0.5*LL

  3. Using INDEX:DPI as an example (data as of 17 SEP 21)

    UL = High of 0.1427 on 9 SEP 21
    LL = Low of 0.0504 on 17 MAR 21
    UB = 2*UL = 0.2854
    LB = 0.5*LL = 0.0252

Test Cases

‌Multiple Uniswap v3 positions were deployed to test the UX as follows:

@mel.eth deployed a UNI v3 position for DPI/INDEX on 14 AUG 21 (Ethereum Transaction Hash (Txhash) Details | Etherscan and Uniswap Interface) and despite the fee level being set to 1%, arbitrage has the fee settling in at about 20% so far. While the period of time is short enough to be considered anecdotal, the resulting revenue is higher than could be achieved using other means and has the benefit of modestly reducing the slippage on both an IC product and INDEX.

@mel.eth also got absolutely wrecked by flipping the numerator and denominator on a 1% INDEX:MVI position:

  1. Deployed 80.76 INDEX and 187.38 MVI to a new UNIv3 LP position costing 0.169 in gas (gas only this high if the pair and fee haven’t been deployed before ever);
  2. Next block an arb bot paid 4.5 ETH in gas to swap 78.28 INDEX for all 187.38 MVI;
  3. There were some expletives as loss was on the order of $17,500;
  4. Removed remaining INDEX in position;
  5. Fired two test shots but at this point the arb had absolutely destroyed the ratio of the pairing and v3 uses market forces not oracles to determine pair prices (I had a convo w/ the Uniswap folks about this, they see oracles as a source of centralization in this regard);
  6. Ultimately I had to spend some INDEX to get things back in line, effectively setting a full range position that would be attractive to an arbitrager to flip the pairing back in line with market realities;
  7. Next block, arbed as expected (enjoy your 0.22279 ETH you beacon of market efficiency);
  8. With the ratio more accurate, yet still a little gun-shy I tried again with 95.58 INDEX and 10.02 MVI and didn’t get wrecked! So I filled up the position to the level I wanted, and have even started to see some action on the swap side.

This is all to say that if done correctly, v3 is a breeze, and if done improperly a significant amount of capital can be lost. Based on the two test cases above I would recommend that any initial deployment (the creation of the pair at a given fee-level) be done with a relatively small amount of tokens and additional liquidity added to that position once the pairing is seen to be stabilized.

Potential Risks and Challenges (added section)

‌* This would likely generate a lot of trade activity on the INDEX token as it would be acting as a bridge. While I don’t see this being problematic others may so noting it here.

  • If core products are added at a rate that exceeds the amount that would make sense based on a minimum liquidity threshold it could make for a less than ideal deployment strategy, meaning funds would need to be added if IC were to ship simple indexes at a rate that exceeds the organic growth of the pools.
  • INDEX from Treasury (it will be at more risk than sitting in treasury, is it worth it?)
  • Rebalance risk: An asset performing better means the amount of it is reduced in the v3 position, could have an impact re slippage if these pools grow and a rebalance requires buying a lot of one asset with low liquidity otherwise; mitigated partially through sufficiently wide banding.
  • The allocation of tokens within the position will not start at a ratio of 50:50 and could potentially end up being 100:0. Having a band that is effectively double the expected range over the coming 3-month period allows capital reallocation and redeployment well ahead of a range becoming lopsided and an interim process of capital redeployment could be implemented at around the 80:20 mark in either direction.

Additional Considerations (added section)

‌While some determinations were made as to ideal band width [sic] for liquidity provisions, the initial capital allocation is considered a minimum in order to have the desired effect of improving the swap experience for users. That said, this proposal was initially contemplated utilizing a $5MM provision at $1MM per pair and was pared back to help eliminate early objections to the amount of capital being put at risk, despite that risk being low. That said, increasing the amount of liquidity provided in this fashion would have a dramatic increase on swap efficiency at higher swap values.

Liquidity is a complex topic and if this proposal garners a sufficient level of interest I will schedule a community call to discuss, build context, and try to incorporate feedback to make this as safe and effective as possible.

Copyright and related rights waived via CC0.

7 Likes

A more fun chart and flagging some folks besides @overanalyser that may want to be part of the discussion. @afromac @puniaviision @oneski22 @BigSky7 @dylan

And thank you @MrMadila for the 1:1 feedback on the early version of this proposal; it was invaluable.

4 Likes

Love the idea! I have a few questions/considerations:

  • Do we feel the 0.05% tier is sustainable given the products in mind? Though it clearly be a lot better if we can get 0.05% going, my main concern is if the fees are too low then we will not be able to create organic interest to LP. Imo 0.3% feels more “natural” and then a 0.6% fee from USDC → DPI is pretty decent (for crypto standards).
  • Is it possible to calculate the expected liquidity/slippage at 200k$ liquidity? Eg is it enough with 200k$ to make a difference? I know this depends on the bands, but could we run the numbers on something that requires semi-frequent rebalancing?
  • Any examples of other DAOs implementing something like this we can point to/learn from?
1 Like

Thanks for the great questions @robdog, I’ll answer the best I can here:

I’m not sure exactly what is meant by sustainable in this context but I will try and address the concern. There may be some impermanent loss at points if there are large relative price movements, but given that this would be a long-term provision that IL wouldn’t be realized and would be offset by the accrual of fees. I will admit that establishing a few 0.05% pools for what are considered boutique pairings is unorthodox; once deployed there shouldn’t be any sustainability issues other than market risk, which we’re already exposed to by having the INDEX and product-native streaming fees sitting in our accounts, and protocol risk at Uniswap, which I would say is low given that v3 is well-tested at at this point.

You bring up an excellent point here: you state that it’s better to have a 0.05% pool but it feels more ‘natural’ to have a 0.3% pool and tie that to organic interest. This touches directly on competing motivations of liquidity providers and one of the guiding principles of Index Coop: “Indices are designed to help minimise fees and hassle, while maximising the breadth of choice for digital asset holders.

As a liquidity provider I am motivated to, and have, provided liquidity at higher fee levels in an effort to earn passive income; this proposal makes a contemplated effort to place the fee consideration secondary to that of the end-user experience. Apologies for jumping on the wording to make a point here, but I believe The Coop should be targeting a higher standard than: pretty decent (for crypto standards).

In terms of organic interest, I’d agree to an extent, there will not be a lot of motivation for LPs to deploy liquidity on a boutique pairing at a low fee level, which is why I’m proposing that we do it. That said, seeding the pool (creating the pairing in Uni v3) costs about 10x+ the amount in gas of simply adding liquidity to an existing pair at a given fee-level, so when a potential LP surveys the landscape of liquidity providing options for a given token it may factor into their decision that a pool at a given fee-level is already created and seeing some action.

I’m woefully unsophisticated at attempting to calculate the likely impact of adding liquidity to the system, so I will flag @jdcook here for any insight that may be helpful. I will note that this intended to be additive to the existing liquidity in the system, and to my knowledge additional liquidity, especially at lower fee levels, is only going to reduce slippage. I will work on trying to quantify this; it’s a fair ask and one I want to at least try and answer better.

Maybe. I had a discussion with @oneski22 where he noted that NFTX has done something similar. I plan to go down that rabbit-hole this weekend and will report back on what I find in terms of performance and perhaps unintended consequences. Thanks again for the thoughtful feedback @robdog.

While I think the IC treasury directly seeding liquidity for our products is a good idea in general, I have some issues with this proposal.

To start, pairing our products with INDEX guarantees that the Uniswap frontend will not route any trades through these pools. This is because Uniswap whitelists coins that will be considered as the intermediate when calculating multi-hop trades. Since INDEX isn’t one of these tokens, this means that any swap that does not have INDEX as the final input/output token will not route through these pools. From past experience, I can tell you that the Uniswap team is not keen on adding new tokens to this whitelist. Uniswap has recently changed their routing API to a brand new system, but taking a quick look at their codebase, it appears that a whitelist is still in place.

Secondly, I think we should be much more deliberate when we consider LPing from the treasury. This proposal suggests that we LP for DPI and MVI. Currently, both these tokens have more than enough liquidity. We will likely be exposing ourselves to significant IL and operational overhead in maintaining the bounds of these positions while not significantly moving the needle in terms of overall liquidity.

5 Likes

Thank you @mel.eth for the detailed response! My point on sustainability of the pool was really purely about the below:

If we are going down a path, which we consider is unlikely to attract organic liquidity, then we will need to uphold the liquidity until other sources of liquidity are deemed sufficient. Though the investment return in this case might be worth it to do it anyways, so I think the second point on how much investment vs liquidity would really be the key question then. If we with 1m$ can add significant liquidity and reduction in fees, then as you say a significantly superior fee experience will make it worth it.

However, if it only buys a little bit of liquidity, then it could be more cost effective to shoot for a higher fee tier and with the proposed structure/logic attempt to bootstrap a pool that can be sustainable without our capital and be a long term solution to the liquidity issue. I would add that we can always incentivize a lower fee tier at a later stage.

So I am very much in favor of what you are proposing but would caveat it might be worth to consider alternative fee tiers if 0.05 is too costly.

1 Like

Really appreciate the technical expertise you bring to this @ncitron. Given we’re in agreement on the subject of directly seeding liquidity I hope we can keep the conversation going in this regard no matter the outcome on this proposal; I like to think that it all goes toward informing the best possible solution. Whether here or offline I’d like to get your thoughts on the desired outcomes for a liquidity provision and the best path to getting there.

Thank you for the explanation on the routing algo that Uniswap provides. I was not aware and thought the Uniswap protocol was agnostic within its own ecosystem. This consideration effectively limits the utility solely to DEX aggregator users (assuming they do not similarly whitelist multi-hop tokens). Overall this detracts heavily from the use-case being as effective as contemplated initially. Thank you for bringing this to light and I welcome your thoughts on an effective solution.

To your second point, I can assure you that this proposal being put forth for your consideration is deliberate, so I’ll speak to these points in more detail:

I don’t agree. Taking MVI as the example, over 96% of the v2 liquidity is incentivized:

. . . suggesting that there is just north of $200k in unincentivized v2 liquidity on the pair. With v3 having roughly the same amount of capital at the 0.3% fee level; granted, being utilized more efficiently. Assuming north of $400k of unincentivized liquidity on MVI/ETH, deploying just shy of 1/3 more at 1/3 the effective fee level would have a noticeable impact to the fees charged to users for a majority of swaps and help keep MVI closer to the peg. Who knows, maybe it turns out that most LPs stay when incentives end, but research by @overanalyser suggests that greater liquidity is necessary than would be organically provided, with arbitrage currently effective at the 1-2% range I believe that any reduction in liquidity would have an impact on spot/nav.

So when considering a strategy for increasing liquidity, I judged the best approach to be one that spreads the low-fee-level liquidity equally among simple index offerings. I think it sends the right message (that we have full and equal faith in our product offerings, equally deserving of a baseline liquidity level that’s not designed to capture fees, but rather improve the swap experience) and avoids extensive debate on what the right allocation strategy is. The proposed strategy is sufficiently complex, and while I agree that it could be even more effective than proposed, removing the complexities of a rebalance strategy debate and subsequent execution was a design consideration, not an oversight.

While estimates in terms of required contributor time and gas costs are included in the proposal, I welcome additional feedback as to the characterization of overhead costs as significant relative to the fees that would be generated. The typical rebalance is envisioned as quarterly, and the proposed strategy requires no engineering work. Contrast that to the current strategy requiring monthly contract fills and periodic contract creation, typically for each product offering in some different fashion. I view any process change that removes non-productive work from the EWG notion board as positive. Again I note that the bands proposed are very conservative and shouldn’t require frequent rebalancing.

In terms of Impermanent Loss, it is higher than v2 or a full-range position. v3 effectively provides a way to leverage liquidity in exchange for earning increased fees and that comes with risks, at which point it becomes a consideration of benefits vs the status quo; continue to spend INDEX to incentivize liquidity with no hope of a return, or provide the liquidity that is most useful and at least have a decent chance at growing that pot of tokens as our products perform well and INDEX valuation increases. I’d strongly prefer the latter as it’s not just about capital efficiency in a choice of liquidity provision, it’s about how efficiently The Coop wants to invest it’s INDEX in having the desired outcome this proposal is striving for, which the greatest improvement in user experience at the least cost to IC.

In terms of moving the needle on liquidity, I would again refer you to the example of v2 ($3.375MM in liquidity/$287k trade volume) vs v3 (96.11k in liquidity/$175k trade volume) on MVI. MVI has 2.8% the amount of liquidity available in v3 compared to v2, and sees over 38% of the trade volume. The proposed provision would double the amount of v3 liquidity available. The impact to the effective amount of liquidity in the system would be noticeable. At current INDEX valuations IC spent over $150k on MVI liquidity incentives from July to August and that’s just one product and the INDEX tokens are now gone; the proposed solution here would have a one-time cost of $1MM, likely be perpetual and grow, and be significantly more effective.

This is how I see it, I welcome feedback especially if I’m missing some technical nuance as I had above. I really enjoy that we’re trying to get to the same place and see multiple paths; I’m optimistic about where we’ll end up. Thanks again @ncitron.

1 Like

I think there may be a case for providing liquidity for MVI. The V2 LM program for MVI is about to expire, so I will be watching closely to see how much of that liquidity moves to V3 to chase higher fees. I suspect that more than enough liquidity will migrate in the next few weeks. If this is not the case, we should look into direct provision or incentivization.

As for DPI, I think spending anything on direct provision will be more or less useless. The DPI V3 LM program has been over for two weeks now, and DPI-ETH is comfortably sitting at $18M TVL. An extra $200k only increases total liquidity by ~1%.

For DATA, I think we should again wait and see. The product has yet to launch and we have no idea what the demand or the organic liquidity will be.

My main worry with this proposal is that it provides highly fragmented liquidity. It is generally most efficient to concentrate liquidity into a single pool. If liquidity is split between two pools, the larger pool will receive all of the non-aggregator trades (as it provides the best rate that utilizes a single pool). For aggregator trades, users will be able to take advantage of the liquidity in the secondary pool, but at the expense of doubling their gas cost (since they will need to perform two swaps). For whales, this may be a worthwhile tradeoff, but smaller traders will not be able to take advantage of this. Had all the liquidity been in a single pool, both small and larger traders would be able to take advantage of the increased liquidity.

Because of this, I believe that any liquidity provision done by the Coop should go into the current largest pool. For the cases of an unincentivized product, this will likely be the Uniswap V3 0.3% fee option paired with WETH.

4 Likes

Hi @mel.eth

This is an interesting idea, and I’m not sure how it would play out. Setting the range will be fundaments to success. If we have $200 k symmetrical over -50% to + 100%, then we would have ~$2 per 1% price impact (very rough calculation). Which is;t that much depth (MVI currently has ~$16k at 1% on a ~$7 M v2 pool).

I think the key blocker is the uniswap router as @ncitron highlighted (Which I wasn;t aware of).

Other challenges:

  • Sweet spot for range / depth / work to manage.
  • Work to monitor (can be automated) and manage the liquidity.
  • Gas costs
  • Understanding the IL to be expected.

I wonder how the fee level will impact the use, higher fees, will reduce the volume on these pools (as it will only be to toxic flow that is captured by arbitrage), but x20 the income. If we go with lower fees, we increase the volume (and external parties look at both volume and liquidity onchain).

At this time, I’m not sure the idea works on mainnet v3.

However, it could be a way to deploy coop liquidity on a single L2 chain (e.g. $2 M deployed on Arbitum in concentrated Sushiswap pools could work - [Assuming Trident allows routing via INDEX pairs…]).

1 Like

@mel.eth really appreciate all of the thought and effort put into this - really great to see such in-depth thinking.

I have been thinking about direct liquidity provisioning from the Treasury a lot lately - and I think my vision is based off a few main thoughts:

  • we need to boost liquidity in short terms to allow our products to go through sufficient demand discovery
  • new products require the most liquidity attention (when it comes to provisioning from our own treasury)
  • direct liquidity provisioning will be most effective if it is flexible, reactive, and focused

So I think that we (and this may feel simple) start with a $ amount - say $1mm - and we go through and IIP process to create a team, a multi-sig, a process, etc for that $ to be managed across whatever liquidity pools it will be most effective in. Right now, that might look like some in the MVI v3 pool, some in BED v3, some for the DATA launch, and a little kept in reserve for flexibility.

Liquidity is critical to our success - and as we are about to enter a stage of high product # growth - I think it is only appropriate that we devote more $, resources, and processes to managing our liquidity in this way - @overanalyser has served the community incredibly well, but he needs help! Not sure if this is a sub-function of PWG or if it is it’s own WG, but I think we need to start moving on a dedicated team here. And I actually think this should probably be its own account with its own multi-sig separate from the Operations Account - this team needs to be able to be active and agile.

I know this generalizes this specific proposal a lot - but I think the kind of thinking in this proposal is the kind of thinking that should be happening within a Liquidity WG type structure!

5 Likes

@robdog @overanalyser @ncitron @jdcook

I can’t thank y’all enough for your feedback here; I’ve learned a lot! Dropping this note to effectively pause discussion on the main thrust of this thread and rather allow this feedback to inform future liquidity discussions. :owl:

5 Likes