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:
- Calculate exact token amounts needed based on liquidity provision bands above;
- Transfer available tokens to PWG multi-sig and swap if necessary;
- Deploy LP positions on v3;
- Monitor range; and
- 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:
-
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 -
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 -
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:
- 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);
- Next block an arb bot paid 4.5 ETH in gas to swap 78.28 INDEX for all 187.38 MVI;
- There were some expletives as loss was on the order of $17,500;
- Removed remaining INDEX in position;
- 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);
- 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;
- Next block, arbed as expected (enjoy your 0.22279 ETH you beacon of market efficiency);
- 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.
