Vault liquidation bot

👉 Apply Here!

Overview

As part of Interlay’s mission to unlock Bitcoin's full potential in a decentralized ecosystem, we offer a grants program focused on funding software development and research efforts related to Interlay and Kintsugi. Our focus mainly lies on strong technical projects that add value to the ecosystem.

Interlay Grants will be awarded to teams and individuals who bring value-added projects to Interlay, creating a strong community of incentivized tech contributors.

Problem

While vaults need to over-collateralize their outstanding locked BTC (= issued kBTC/iBTC) with other tokens such as KSM, price fluctuations of both, the collateral as well as the outstanding BTC, can lead to situations where the locked BTC might be worth more than the supplied collateral. At this point, an economically rational vault operator would run away with the locked BTC leaving users and the ecosystem with a loss. Such an event would likely lead to a depeg of kBTC to BTC.

To prevent this from happening there are two measures in place: Premium redeems and burn events.

1. Premium redeem: Once the ratio of collateral to debt falls below the premium redeem threshold, users can redeem kBTC against the vault to receive the full amount of BTC plus a 5% premium in the form of collateral.
2. Burn: If the ratio falls below the liquidation thresholds, the total collateral will be seized and users can redeem kBTC against the collateral at a very beneficial rate (currently 130% for KSM).

Solution

The above process only enforces full coverage of the issued kBTC/iBTC as long as users actively make use of premium redeems and liquidations. To ensure that this happens, we are looking for applications that build a bot to monitor existing vaults and execute the respective actions in a timely and profitable manner.

Product Requirement

• Feature 1:

  • CEX connection: Use an open source library such as ccxt to connect to any of the whitelisted exchanges and allow executing private API calls for trading.
  • Kintsugi/Interlay DEX connection: Subscribe to events to read the recent price of kBTC/iBTC on-chain and implement exact input and exact output swap methods.

• Feature 2:

  • Monitoring: Constantly monitor the collateral ratio of vaults and assess the profitability of a premium redeem or liquidation redeem, taking into account the slippage and transaction costs to (a) buy kBTC and (b) sell the received collateral.
  • Execution: If the transaction would be profitable, do the following steps:
    1. Mint the required amount of kBTC or buy it on Kintsugi DEX
    2. If premium redeem threshold> collateral ratio > liquidation threshold
       1. Call redeem.requestRedeem to receive BTC + collateral
       2. Sell BTC + collateral on a CEX (collateral can also be sold on Kintsugi DEX)
    3. If liquidation threshold > collateral ratio
       1. Call redeem.liquidationRedeem to receive the collateral
       2. Sell the collateral on a CEX or Kintsugi DEX
  • Thorough tests are a must.
  • If implementing in TypeScript, you can fork https://github.com/interlay/bridge-bot and upgrade to the latest version of https://github.com/interlay/interbtc-api. Then, use the interbtc-api library to send extrinsics and read chain state. It should be possible to reuse logic from the integration tests and docker setup in https://github.com/interlay/interbtc-api.
  • If implementing in Rust, you can use https://github.com/paritytech/subxt to communicate with the parachain. It should be possible to reuse the setup in https://github.com/interlay/interbtc-clients to write integration tests.

• Feature 3:

  • In the case of a premium redeem, the received BTC must be sold on a CEX. The premium, received in the form of collateral, can either be sold on a CEX or DEX.
  • In the case of a liquidation redeem, the received collateral must be sold on a CEX or DEX
  • Ideally, the user can set the quote currency of the trade, for which the bot will sell the received BTC and collateral

• Feature 4: Create an easy to follow Readme that:

  • 1. allows for easily setting up the bot
  • 2. explains how the bot works and how the code is structured in case someone wants to contribute.

  The readme also serves as a project report for the submission.

• Additional Requirements: Edge case fixes and additional functionality than those mentioned above are encouraged. The bot should be highly configurable using command-line arguments. The code must be properly refactored, such that it is easy to understand and extend.

Scoring Criteria