Liquidation Protector

Liquidation Protector

Liquidation Protector is a Knock-In Option protocol. If the underlying asset price hits the barrier, the option token's payoff will be automatically added as collateral to protect the liquidation.

Carousel Gallery Item: 1
Carousel Gallery Item: 2
Carousel Gallery Item: 3

Last updated: 11 August 2022 08:08 AM

Updated favicon image

The problem Liquidation Protector solves

the liquidation risk of leveraged position.

Building leveraged position has been common knowledge as crypto derivatives and DeFi markets grow from 2021.
Highly leveraged positions caused a lot of liquidation in the recent bear market, we have witnessed many liquidation cases, and many investors suffered from their losses. A considerable amount of dollars was liquidated every day.

It also led to default risk with more extensive market loss and caused a significant decline in the overall market. Nevertheless, the instrument for hedging the liquidation risk is not enough.

Therefore, we firmly believe there is a greater market need for liquidation protection instruments and trading infrastructure.
So we designed a market with a Knock-In option, where investors can handle the liquidation risk of their leveraged position. Not only the liquidation protector will manage individual investors, but also the systematic risk of the market.

Various market participants can use the Liquidation Protector.

  • Long Knock-In Option holder (= Buy position) :
    • Investors who want to hedge their liquidation risk. Primarily futures or collateral-based lending users.
    • Investors want to prepare for an event in which major market players are liquidated.
  • Short Knock-In Option holder (= Sell position) :
    • Investors who do not expect a particular event to occur and want to earn a premium by selling Long Option Tokens.

When our protocol works as liquidity protection appropriately, it can be integrated with futures and lending protocols as collateral or insurance.

  • Futures CEX/DEX, Collateral-based DeFi.
    • Protect investors from losing all investment capital by using the options as insurance
    • Secure sales commissions by selling the Knock-In option on their platforms
    • In excessive market volatility, Liquidation Protector can reduce the systematic default risk.

Challenges we ran into

Implementation of Option Position and Trade

  • Options include long and short positions. Long position is paying a premium to buy the right to exercise the option, and short position is to sell the right for a premium. We adopted a method in which plus and minus tokens are issued together when an option is published. Minus tokens, meaning short position, belong to the option publisher, and plus tokens, meaning long position, are traded in the market. If the underlying asset’s price reaches the barrier price before the option expires, the plus token holders can take the payoff. If the price does not reach the barrier, the minus token holders get the collateral back.
  • Position management using tokens also simplified options trading. Ownership of plus tokens means the right to exercise options. Accordingly, we were able to safely implement option trading in 3 days, which can be complex, through the P2P trading method.

Implementation of the Bot

  • Knock-In(KI) option Execution transactions which sent concurrently reverted since new sending transactions have the same nonce as that pending transactions. We sent transactions sequentially. Furthermore, we will have a nonce manager that specifies the nonce in each transaction and make parallel transactions.
  • We needed to retry only failed options when options failed to execute. We created a dead letter queue for KI options that can’t be processed successfully. The bot periodically polls the queue and retries the failed options until they execute successfully.
  • How can we define each user’s KI option balances when we trade the options? We used the Graph to display each user’s option trading from the KI option market contract events. We defined data source templates in a contract subgraph to listen to Transfer events for dynamically created KI option token contracts. Using data source templates, we handled all Transfer events of the token contracts and computed each user’s balances to display in UI.

Discussion