Index Coop Resource Center
  • Welcome to The Index Coop.
  • Products
    • Trade
      • Index Coop Leverage Suite
      • Leverage Token Parameters
      • Leverage Token Keepers
      • Trading Interface Guide
      • Ripcord Guide
    • Earn
      • High Yield ETH Index (hyETH)
      • Interest Compounding ETH Index (icETH)
    • Asset Management
      • Product Development Process
      • Product Revenue Tokens (PRTs)
    • Legacy Products
      • How to Redeem Legacy Products
      • DeFi Pulse Index (DPI)
      • Bankless BED Index (BED)
      • Metaverse Index (MVI)
      • Diversified Staked ETH Index (dsETH)
      • Index Coop CoinDesk ETH Trend Index (cdETI)
      • Index Coop Large Cap Index (ic21)
      • ETH 2x Flexible Leverage Index (ETH2x-FLI)
      • BTC 2x Flexible Leverage Index (BTC2x-FLI)
      • Flexible Leverage Index- Polygon (FLI-Ps)
        • ETH 2x Flexible Leverage Index (ETH2x-FLI-P)
        • Inverse ETH Flexible Leverage Index (iETH-FLI-P)
        • BTC 2x Flexible Leverage Index (BTC2x-FLI-P)
        • Inverse BTC Flexible Leverage Index (iBTC-FLI-P)
        • MATIC 2x Flexible Leverage Index (MATIC2x-FLI-P)
        • Inverse MATIC Flexible Leverage Index (iMATIC-FLI-P)
      • Market Neutral Yield ETH (MNYe)
      • Bankless DeFi Innovation Index (GMI)
      • Data Economy Index (DATA)
      • Legacy Contract Addresses
      • Gitcoin Staked ETH Index (gtcETH)
  • Protocol
    • Index Protocol
      • Core Contracts
        • Set Token
        • Set Token Creator
        • Controller
        • Integration Registry
        • Price Oracle
        • Set Valuer
      • Modules
        • Basic Issuance Module
        • Debt Issuance Module v2
        • NAV Issuance Module
        • Trade Module
        • Streaming Fee Module
        • Wrap Module
        • Airdrop Module
        • Claim Module
        • Governance Module
        • Compound Leverage Module
        • Aave v2 Leverage Module
        • Aave v3 Leverage Module
        • Auction Rebalance Module
    • Set Protocol v2
    • Security and Audits
    • Contract Verification
    • Programmatic Redemptions
  • Resources
    • Governance
      • $INDEX - Governance Token
      • Index Improvement Proposals (IIP) Overview
        • IIP Step-by-Step
        • Governance Representatives
        • IIP Template
        • Product (DG) Template
      • Meta-Governance
      • Delegation
    • Data & Analytics
    • Multisigs
    • Press Kit
Powered by GitBook
On this page
  • Overview
  • Mainnet Production Addresses
  • Integration
  • Resources

Was this helpful?

  1. Products
  2. Trade

Leverage Token Keepers

PreviousLeverage Token ParametersNextTrading Interface Guide

Last updated 11 months ago

Was this helpful?

Overview

This document contains information on setting up a keeper bot to rebalance the FLI product.

Similar to yVaults, off-chain keeper bots are required to ping the smart contracts to maintain the ETHFLI strategy. Under the hood, the smart contracts will calculate whether the FLI should lever or delever according to the methodology and execute rebalances in 1 transaction via DEXs (initially Sushiswap or Uniswap).

There is an emergency delever function built in that will reward the caller with 1 ETH if leverage ratio goes above 2.7x in the ETH2x-FLI or 2.4x in the BTC2x-FLI. Scroll to the ripcord() section below for information on integrating.

For a technical introduction of the FLI system, view the slide deck .

If you have any questions, join the #dev channel in our .

Mainnet Production Addresses

View the latest contract addresses here.

Integration

All keeper interactions will be through the FlexibleLeverageStrategyAdapter contract ().

On the strategy contract, there are 4 external getter functions that keepers can monitor:

  1. shouldRebalance()

    1. Interface: function shouldRebalance() external view returns(string[], ShouldRebalance[])

    2. Helper that checks if conditions are met for rebalance or ripcord. Returns a tuple of exchange name strings and enums with 0 = no rebalance, 1 = call rebalance(), 2 = call iterateRebalance(), and 3 = call ripcord()

  2. shouldRebalanceWithBounds()

    1. Interface: function shouldRebalanceWithBounds(uint256 _minLeverageRatio, uint256 _maxLeverageRatio) external view returns(string[], ShouldRebalance[])

    2. Similar to shouldRebalance, this is a helper that checks if conditions are met for rebalance or ripcord. Returns a tuple of exchange names and enums with 0 = no rebalance, 1 = call rebalance(), 2 = call iterateRebalance(), and 3 = call ripcord()

    3. Allows keeper bots to customize the min and max bounds to call rebalance. For example, you may not want to call at slightly above max leverage every time 2.31x leverage every time

  3. getCurrentLeverageRatio()

    1. Get current leverage ratio. Current leverage ratio is defined as the USD value of the collateral divided by the USD value of the SetToken. Prices for collateral and borrow assets are retrieved from the Compound Price Oracle.

    2. This function may be needed to toggle the threshold for calling rebalance() if the current leverage ratio goes above the max bound or below the min bound. E.g. if leverage ratio is 2.31x, shouldRebalance will return 1, but we may not need to call rebalance() to bring it to 2.3x leverage. Instead, keepers may wait until 2.4x or higher to save on gas.

  4. getCurrentEtherIncentive()

    1. Get current Ether incentive for when current leverage ratio exceeds incentivized leverage ratio and ripcord can be called. If ETH balance on the contract is below the etherReward, then return the balance of ETH instead. If not above the ripcord threshold, then it returns 0

Depending on which enum shouldRebalance returns, keepers will need to call the appropriate function:

  1. rebalance()

    1. Should rebalance returns 1

    2. Pass in an exchange name string. The exchange must be enabled on the adapter

    3. Only whitelisted addresses can call. Only EOA

    4. This is a regular rebalance according to the FLI methodology. If within the max and min leverage ratios, rebalances will only happen every 24 hours. If outside those bounds, keepers can call rebalance anytime to bring it to the max or min leverage.

  2. iterateRebalance()

    1. Should rebalance returns 2

    2. Pass in an exchange name string. The exchange must be enabled on the adapter

    3. Only whitelisted addresses can call. Only EOA

    4. This follows a rebalance() call only if the total notional trade size is greater than the max trade size or max borrow limit. This iterates through the TWAP and can be called every 30 sec until the notional amount is rebalanced

  3. ripcord()

    1. Should rebalance returns 3

    2. Pass in an exchange name string. The exchange must be enabled on the adapter

    3. Anyone can call, not just whitelisted addresses. Only EOA. This can only be called if the current leverage ratio is above the threshold (2.7x initially). This function typically would only be called if keeper bots have not been able to call rebalance() between 2.3x and 2.7x leverage.

    4. There is no TWAP when above the ripcord threshold (2.7x). Only need to continuously ping this function until we get below 2.7x

    5. Ripcord will use its own settings for slippage tolerance (5%), cooldown period (1 sec), and max trade size (1200 ETH)

    6. Caller is rewarded with 1 ETH

  4. Do nothing

    1. Should rebalance returns 0

Note: In the initial guarded launch, there will be a whitelist of addresses allowed to call the rebalance() and iterateRebalance() functions. Therefore, any keeper addresses need to be whitelisted prior to launch or go through Index Coop governance post launch. Ripcord() does not have this restriction, and will be callable by anyone.

Below are the estimated gas costs for calling each of the 3 functions above:

Parameter

Gas Cost

Rebalance

~625k

Ripcord

~665k

Iterate rebalance

~614k

Resources

  • Contract addresses

FlexibleLeverageStrategyAdapter ABI
Discord
here
Discord
ABI