Liquidation Bot

How does the Liquidation Bot work?

The liquidation bot comprises two distinct processes: one utilizes Mirai to source accounts, while the other involves conducting liquidation simulations on accounts with a health score below 1.

1. Sourcing of Accounts

To obtain a comprehensive list of accounts utilizing Mirai, the liquidation bot employs two steps:
The bot utilizes an Apollo client, executing a query to retrieve all account IDs, thus providing a complete list of accounts utilizing Mirai.
  1. 1.
    Mirai leverages Subgraph to monitor all accounts interacting with its protocol. Subgraph specifically tracks entities identified as "Account," enabling the identification of all accounts associated with Mirai.
  2. 2.
    The bot utilizes an Apollo client, executing a query to retrieve all account IDs, thus providing a complete list of accounts utilizing Mirai.
query accounts {
accounts {
id
}
}
  1. 3.
    After compiling a list of accounts, the bot proceeds to employ MiraiLens, a smart contract, to obtain the health score of each account. MiraiLens includes a function named getAccountStatus. This function requires an account address as a parameter and returns the health score of the account along with other pertinent details.
  2. 4.
    In order to minimize waiting periods, it is possible to utilize multicall to obtain the health scores of all accounts through a single smart contract call.
  3. 5.
    Aside from health scores, acquiring data pertaining to the markets that Mirai Protocol users are utilizing is crucial for liquidation purposes. To accomplish this, the doQueryAccountLiquidity function available through the Mirai General view Contract can be employed.
  4. 6.
    The second parameter of this function involves submitting an array of account addresses alongside the Mirai address. Upon execution, it returns the corresponding market data for the specified accounts.
  5. 7.
    All of the aforementioned data is stored in Redis, a database optimized for swift and effective data storage and retrieval. This approach facilitates easy and rapid access to the information whenever it is required

Liquidation Simulations

  1. 1.
    Getting Account Details
    The bot begins by gathering account details using Redis read functions, which enable it to obtain information on all the accounts it needs to monitor.
  2. 2.
    Cartesian product of the user's collateral and liability markets It then generates the Cartesian product of the user's collateral and liability markets with each other. For example, if the user's collateral markets are ["USDT", "DAI"] and liabilities are ["WETH", "WMATIC"], the resulting Cartesian products would look like this:
[
["USDT", "WETH"],
["USDT", "WMATIC"],
["DAI", "WETH"],
["DAI", "WMATIC"]
]
  1. 3.
    Getting Repayment Amount Next, the bot loops through this array and calls the checkLiquidation function on the Mirai liquidation contract for each pair of collateral and liability addresses. This function returns the amount that needs to be repaid to settle the debt.
  2. 4.
    Generating Swap Path
    In Mirai Liquidation happens as follows
    1. 1.
      Liquidator receives the appropriate amount of both collateral tokens and debt tokens of user
    2. 2.
      Liquidator swaps collateral into debt tokens using Uniswap handler
    3. 3.
      Swapped debt tokens are used to repay loans
    4. 4.
      Uniswap v3 introduced multiple pools for each token pair with different swapping fees
    5. 5.
      Four fee tiers: 0.01%, 0.05%, 0.30%, and 1%
    6. 6.
      You can find more information here Uniswap Pool Fees Tiers
  3. 5.
    After creating an array of swap paths for each pair in the Cartesian product of the user's collateral and liability markets that we already generated in step 2
    Bot Loops through an array of swap paths to simulate the Liquidation process by doing the static calls to contract
    1. 1.
      An array of swap paths is created for each pair in the cartesian product of the user's collateral and liability markets
    2. 2.
      Bot loops through an array of swap paths to simulate the liquidation process by doing static calls to contract
    3. 3.
      Static Calls made to contract:
    4. 4.
      1. 1.
        balanceOfUnderlying function on eToken Contract: returns eToken balance before liquidation
      2. 2.
        Liquidate function on liquidation contract: after executing, liquidator receives appropriate e-tokens and d-tokens
      3. 3.
        swapAndRepay function on swapHub contract: converts e-tokens into the appropriate amount of d-tokens to cover debt and pays debt
    exitMarket on markets contract