Authors: @afromac, @sidhemraj, @jackiepoo, @Ahuja, @emault, @allan.g, @tgreco & @Mringz
Summary:
Developing leveraged product methodologies using the existing smart contracts creates a number of challenges and trade-offs. However, using the existing technology that is available to us with no modifications, enables us to bring products to market quickly. These circumstances have resulted in the creation of two methodologies and products that can be deployed immediately, and that have comparable performance to the FLI products, while also being safe to launch. In some circumstances they will underperform the FLI methodology, but due to reduced gas costs can result in significant savings for Index Coop
In parallel to this work, the Pod can focus on developing new methodologies for launching future leveraged products that will utilize a purpose built smart contract and enable greater flexibility and performance. Crucially, the code for the methodology (Strategy Adapter) sits above the core smart contracts and can be updated without requiring major overhaul of the underlying infrastructure.
This enables IC to continue with the deployment of future products based on the available smart contracts and strategies, while having the ability to upgrade these products to improved strategies once the methodologies have been decided upon.
Challenges of using the FLI Smart Contracts
The central difficulty with launching new leveraged products that use the existing smart contracts with no modifications, is that we have a limited number of parameters that we can effect:
- Upper and Lower Bounds
- Rebalance Interval
- Rebalance Speed
Because the central feature of the FLI methodology is the rebalance speed, we have set out to create a methodology that does not rely on using that parameter. Instead, we set it to 100%, effectively executing a full rebalance back to the target leverage ratio (2.0x) each time one is called. The primary advantage of the FLI methodology is that minimizing the size of the rebalance transactions significantly reduces the cost of rebalancing. Because we are not using this parameter, we must adapt our strategy to make savings in other ways.
This gives us 2 potential strategies:
1. Hard rebalance at regular intervals (like FTX)
- In shorter periods (days and hours), this strategy should match FLI performance on average
- Over longer periods it will underperform due to NAV decay from larger daily rebalances
- Suitable for deployment on L2 where it can be frequently traded.
2. Hard rebalance with no predefined intervals, and with wide upper and lower bounds (like Binance)
- In short periods (days and hours), this strategy should also be comparable to FLI on average
- In a strong bull run it will underperform FLI
- Over longer periods of time it will outperform FLI due to less rebalancing and NAV decay
- Suitable for deployment on L1 where this strategy can significantly reduce gas cost.
In addition to these considerations, Set Labs has indicated that we need to launch on Aave L1 before we launch on Aave L2, in order to ensure the Aave-specific smarts contracts are secure and stable
These circumstances have translated into the following plans for the team:
- Launch LINK2x on L1 with bounded 2x strategy - LINK LVG2x-B (similar to Binance)
- Launch MATIC2x on L2 with simple 2x strategy - MATIC LVG2x-S (similar to FTX)
Each present different challenges:
LINK LVG2x-B on L1
We are suggesting this product and methodology on L1 because gas costs incentivize us to keep rebalancing to a minimum. This strategy seems to lead to many days where no rebalance transaction was executed. In the simulations we developed, an ETH product using this strategy would only have rebalanced on 18 days out of 150 since launch. For a product that we expect to have a comparable AUM to BTC2x-FLI, this can have a significant impact on profitability.
We can see from recent data that despite the run up to a 50K USD price for BTC, elevated gas costs made BTC2x-FLI a loss-making product for Index Coop for several days last week. This is net revenue after fee split and gas.This kind of potential outcome, strongly incentivizes the Coop to minimize rebalance transactions on L1.
We have modelled the LVG2x-B strategy on ETH to compare to ETH FLI. There is a tradeoff between short term and long term performance based on how we set the rebalance bounds.
Bounds of 1.5-2.5 give us an underperformance of FLI during a bull run, but over the long term and higher volatility it can pull ahead (2x-B strategy is the orange line):
Tightening the lower bound of the range (for example 1.75-2.5) gives us better performance in the uptrend but then seems to fall behind over a longer timeframe. The Pod recommends using the 1.5-2.5x strategy for this reason.
Daily simulated returns on 2x-B vs FLI show 2x-B (1.5x-2.5X) performance is comparable in short bursts of 24 hours, making the product appealing to customers who trade frequently, while the lower rebalancing costs lead to reduced NAV decay and make the product appealing for longer term hodlers and LPs
Fig. Daily returns in the test period plotted over time
Fig. Histogram of daily returns in the test period
The above chart is a histogram of the excess daily returns from FLI relative to 2x-B. So, a positive number means that day FLI gave a better return. This shows that 88% of time, the two strategies are within a band of +3 to -3%.
MATIC LVG2x-S on L2
The simple 2x strategy (LVG2x-S) will be easier to implement on L2 because of reduced gas costs, but NAV decay should be pronounced compared to FLI as there will be larger rebalances during each period. However, we can still reduce price impact by setting a safe max trade size and rely on iterate rebalance for larger rebalance transactions without incurring much additional expense.
From the perspective of traders who wish to trade frequently in a low gas environment, they can expect this strategy to perform extremely close to a FLI strategy during short periods of time.
Fig. Daily returns in the test period plotted over time
Fig. Histogram of daily returns in the test period
The above chart is a histogram of the excess daily returns from FLI relative to 2x-S. So, a positive number means that day FLI gave a better return. This shows that 86% of time, the two strategies are within a band of +3 to -3%.
Liquidity & Safety
Our main focus when researching this product has been the available liquidity and how that might affect the risk profile of the product. Gas costs, leverage costs, and price impact from rebalance trades are parameters that might cause NAV decay, but don’t make the product unsafe. What makes the product unsafe is if the product is large enough relative to liquidity to cause a death spiral. This is when the price impact of a ripcord rebalance would be large enough to move the market price by enough to trigger another ripcord rebalance.
In terms of available liquidity, MATIC-WETH is a larger pool on both Sushiswap on Polygon and Quickswap on Polygon, when compared to MATIC-USDC. For this reason, we suggest using multistep trades.This can be revisited at a later date as liquidity grows on MATIC-USD pools over time, but for now the limiting factor is ETH-USDC liquidity. Below is a recent measure of liquidity available.
- Sushiswap:
- WETH:USDC = $50M
- WETH:MATIC = $62M
- Quickswap:
- WETH:USDC = $137MM
- WETH:MATIC = $127MM
Reaching an AUM of ~12% of the size of the available liquidity would put the product at risk. For this reason, we suggest restricting AUM of this product to be equal to 5% of the pool size to avoid this risk. In the event that we are going to reach this level of AUM too quickly, we can limit the Supply Cap and stop any incentives. Hitting the supply cap can cause a dislocation from the NAV, so monitoring the product to ensure this does not happen will be a priority during its early roll-out.
Combined liquidity across both relevant pools (from a recent measurement) is $187MM, enabling us to safely grow to an AUM of about $10MM (equivalent to BTC2x-FLI) with near zero gas fees and 100% revenue to Index Coop. It took many months for BTC2x-FLI to reach this milestone on L1. In future, access to concentrated liquidity on Sushi Trident (L2), as well as general migration of liquidity to L2s, will enable us to vastly grow AUM safely.
The safety features we use to manage price impact today are also suitable for helping to reduce this risk. We define a max trade size that will enable trades up to 1% price impact, based on recent data for the AUM liquidity pool. If the required rebalance size exceeds that max trade parameter, the smart contract will execute multiple rebalance transactions that are spaced about 30 seconds apart. This parameter can also be adjusted to optimize performance over time. Our thinking is that any large price impact (large enough to yield a profit after gas) will quickly be arbitraged away, especially for popular tokens. Also we also have the option to split trades across multiple DEX on L2 - so a combined Sushiswap and Quickswap trade would be possible, and that is also optimized at the time the trade is executed to minimize the price impact.
Trade Offs and Suggestions for New Methodology
Coming back to the original point, it is very challenging to create a product that will beat FLI using the SCs that were designed for FLI but not using it’s central feature - rebalancing speed.
The long term goal is to develop new methodologies and custom smart contracts that will enable more performance and efficiency. One potential solution that has been discussed is provided here, although the team will look to research strategies and may use a different approach.
Rebalancing logic
- Divide the allowed leverage range into bands. The number of bands is a design choice and can be determined based on factors such as implementation complexity, rebalance speed, etc. More bands make the size of actual rebalance smaller but also as a trade-off make the move towards 2x leverage slower.
- At the time of rebalance, move the current leverage ratio to the center of the adjacent band in the direction of the dark green band (straddling 2.0).
- When the current leverage ratio is in the dark green center band, we can choose to make no adjustment and call it the allowed “free-float” band.
- If the leverage ratio hits the max or the min allowed leverage ratio (2.3 and 1.7 in this example), it triggers a rebalance event to move the leverage to the center of the adjacent band towards 2.0. At other times, rebalance events follow the logic outlined in “Time of Rebalance” below
- The width of individual bands can be made non-uniform to follow a function where the size of rebalance steps are a function of how far we are from 2x. Other creative ideas are possible here.
Time of Rebalance
- The implementation keeps track of the gas cost as a function of time of day (in 1, 2 or 4 hour slots) and also the source of liquidity
- At every rebalance event, we determine the next time of rebalance as the time slot with minimum gas cost in the past over some “memory period”. Memory period is the duration of time used for comparing gas costs across time slots to determine the slot with minimum gas costs.
- Time gap between 2 rebalance events can be arbitrary within a time range (say 24 hours) based on such a gas cost criteria.
Crucially, methodologies are encoded a level above the core contracts and can be migrated over time. This enables us to launch products now with the existing smart contracts and upgrade them to improved methodologies with custom smart contracts at a later date.
For example, we have already migrated ETH2x-FLI to a new methodology twice:
Questions from Forum
An ETH LVG2x-B product would only have rebalanced about on about 20% as many days as ETH2x-FLI since launch. While not a perfect comparison, we summed the costs of rebalancing the FLI product for the days on which we would have expected a rebalance to occur to arrive at a total cost of $ $36,000 which is equal to ~50% of the same cost for the FLI product. Of note, while recent daily gas costs can be anywhere from $200-$500, the majority of gas expenses are around periods of high volatility
In the short term, this is not possible with the existing smart contracts. Optimizing the timing of rebalance transactions to minimize gas cost is a future feature we are planning to include in our own methodologies. See the above section on Time of Rebalance for one possible implementation we are considering.