IIP-50 Upgrade FLI to Support Multiple Exchanges

Governance Proposal
1

IIP: 50
title: Upgrade FLI to Support Multiple Exchanges
status: Proposed
author: Noah Citron (@ncitron), Richard Liang (@richard)
created: 2021-6-23

Simple Summary

Update both ETH2x-FLI and BTC2x-FLI to support levering and delevering using multiple exchanges.

Abstract

The Flexible Leverage Index uses a smart contract called FlexibleLeverageStrategyAdapter to execute rebalances. This contract currently only executes trades through a single exchange (Sushiswap). This upgrade allows us to pass in a list of enabled exchanges that our keeper bots may use. Initially, we will enable Sushiswap and Uniswap V3.

Motivation

As FLI products grow larger, we increasingly have to consider slippage on our trades. This is because as AUM grows our rebalancing trades must also scale. To combat this, we set a maximum trade size, and lever/delever the product slowly over multiple trades. While this solution has been sufficient under normal operation, it is a slow process since we must also set a minimum delay period between trades to allow the Sushiswap pool to be arbitraged back to the correct price. During rapid price changes, this bottleneck can prevent us from delevering fast enough, leading to liquidation risk. This constraint is part of the reason why FLI supply caps must be maintained.

Enabling FLI to use a list of whitelisted exchanges to rebalance has several advantages. First, minimum trade delays can be enforced on a per-exchange basis. This means that we can execute a rebalancing trade for each exchange simultaneously, increasing our rebalancing speed. Secondly, having access to multiple exchanges allows us to make use of Uniswap V3. Uniswap V3 almost always will allow us to execute large trades with low price impact, but occasionally produces suboptimal trades for brief periods when price moves outside of liquidity providersā€™ preset range, and high gas prices are preventing them from redeploying their liquidity. By utilizing multiple exchanges, we can easily direct our keeper bots to use Uniswap V3 as the primary exchange, with Sushiswap as a backup. By utilizing Uniswap V3 in this way, we will be able to achieve a 3-6x increase in our existing trade size and delevering speed.

Overall, this change significantly improves FLIā€™s safety and will allow us to have more confidence when increasing the FLI supply caps.

Specification

Overview

The FlexibleLeverageStrategyAdapter is responsible for controlling FLIā€™s rebalancing operations. This change will require deploying two new versions of this contract (one for each FLI product).

Technical Specification

The proposed changes to the contract can be viewed on GitHub here:

Additionally, we will have to execute five transactions per FLI product from the Index Coop multisig to enable these adapters. A table detailing them is provided below:

To Description
Old FLI strategy adapter Withdraw ripcord incentive
BaseManager Add new adapter to BaseManager
New FLI strategy Adapter Whitelist the keeper bots
New FLI strategy Adapter Send ripcord incentive
BaseManager Remove old FLI strategy Adapter
8 Likes
2

Huge engineering win!

Very much voting for!

3

awesome proposal! going to be super beneficial for FLI products going forward :slightly_smiling_face:

one question I do have tho:

will this list consist of many different DEXs or does ā€œexchangesā€ refer explicitly to sushiswap & uniswap?

4

Cool! Good change for safety and usability. Will support.

1 Like
5

The whitelisted exchanges can be any exchange that Set Protocol has an adapter for (and we can build new adapters easily), which gives us a lot of flexibility in the future as the landscape around DEXs change.

1 Like
6

all this technical aspect is new to me, but from what i gotā€¦ this is a good proposal as it will improve its usability especially as weā€™re moving towards DEXs agnosticā€¦ >.< Will support this.

7

Amazing work guys. This is a huge win for the scalability and safety of the products.

I have a couple of questions, mostly on how the update will operate in tight liquidity conditions:

How much of the process of selecting DEX is manual or automated?

For example, how does the keeper bot determine when to execute a trade on Uni V3 or Sushi? Is it capable of monitoring liquidity conditions on Uni in some way, or does someone need to make a decision and manually redirect trades to Sushi?

If it is automated, what are the thresholds it is programmed to redirect to Sushi at? How does it get that data and how often?

If this is more of a manual flip a switch situation, what does that process look like and how long does it take? Who is able to do it?

Once again, incredible work by everyone involved. I know how critical this update was and how quickly you have delivered on it. This kind of rapid response to a key limiting factor is huge for the FLI products, but is also bigger than that, and will have a positive impact across the entire Index Coop universe.

Being able to deliver on these projects sends a massive signal of how effective the engineering team is when under pressure, and gives me enormous confidence in our collective ability to overcome any challenges we are currently facing.

Thank you.

3 Likes
8

Great question.

First Iā€™ll start with why the keepers have to make this decision in the first place. The main issue at play here is gas efficiency. Receiving a trade quote in Uniswap V2 / Sushiswap during a transaction is incredibly cheap gas-wise. Unfortunately, this is not the case with Uniswap V3, where fetching a quote is nearly the same price as actually executing a trade. By having the keepers compute the best quote using just read-only functions, we will be saving a lot of gas.

As for how we will have keepers select which exchange to use, we are planning on doing a phased rollout. To start, we will direct the keepers to only use Sushiswap during a brief trial phase. For the second stage, we will be writing a smart contract that contains a view function (costs no gas to call), that will tell keepers which exchange to use by comparing the expected price impacts of each exchange. This means that the selection can happen automatically. We are also considering a third change to the keeper system that we can work on after that, which is to have the keeper bots blast trades across all available exchanges if the product is at liquidation risk.

1 Like
9

Great. That sounds like an excellent solution.

Voting strong yes on this.