asset-loan-liquidation-oracle-plus-leverage-protection

This is the sketch of the loan contract that allows price-dependent liquidation via oracle signature,
but with leverage-enforced protection from malicious oracle 
Author: Dmitry Petukhov (https://github.com/dgpv/)

----
Other sketches:
  - Price-dependent loan liquidation without involving an oracle:
    https://gist.github.com/dgpv/49bba5ac33764301204493f2837be270
  - Asset price bet contract that allows price-dependent outcome without involving an oracle:
    https://gist.github.com/dgpv/6ec715a4f38d61cc9058c2619ca44b89
  - "Option with security deposit" contract:
    https://ruggedbytes.com/articles/osd/OSD-spec-prose.pdf
----

Concrete implementation of this contract is not yet thought out.
This sketch does not take into account the fees that the debtor has to pay, for simplicity of illustration.
Fees will make calculations more complex, but the basic principle should still work.

Loan contract:
  - Alice puts 1 btc collateral,
  - Bob gives 10K usdt loan
  - the price of 1 btc at the start of the contract: 20K
  - the LTV is 50%
  - liquidation at LTV 90.9%
  - an oracle will release a signature when 1 btc price falls to 11K usdt
  
During the loan term, the price of 1 btc falls to 11K, LTV is 90,9%, oracle releases his signature, Bob wants to liquidate

Replenishment or liquidation:
  - Using the oracle signature, Bob moves the contract that holds the collateral to the 'pre-liquidation' state.
    The pre-liquidation state is limited in duration
  - in the 'pre-liquidation' state, Alice can:
      - add more collateral to the contract, and move it to 'decreased LTV' state
      - do nothing and lose the collateral after the duration of the 'pre-liquidation' state ends
      - challenge the liquidation event, by moving 100K usdt to the contract to put it into the 'challenge' state,
        and then:
          either:
            - Bob adds ~8.09 btc to the contract and takes 100k usdt, and Alice gets 9.09 btc, contract is closed
              (note that we are not taking loan fees into account here)
          or:
            - 100k usdt and 1 btc are sent to Alice, and the contract is closed,
              punishing Bob for improper liquidation attempt

If the price is 11K and Alice challenges Bob:
  - Bob accepts the challenge by moving 8.09 btc to the contract
  - In effect, Bob just sold 1 btc of collateral plus 8.09 btc he added,
    at the price ~11K usdt for 1 btc, the current price.
    He recovered his funds, because that additional 1 btc was a collateral for 10K usdt
  - Alice has bought back her 1 btc collateral at ~11K usdt
    she lost ~1K usdt because she got the 10K loan for it.
    This can be seen as 1K penalty to fail to increase the collateral.
    The sums can be adjusted to lessen or eliminate this penalty,
    but for illustration purposes lets leave it as-is.

If the price is 12K at the liquidation event:
  - Alice challenges the liquidation event
  - If Bob accepts the challenge and moves 8.09 btc to the contract, in effect he just sold
    9.09btc at the price of ~11K usdt per 1 btc, losing about 9080 usdt
  - If Bob ignores the challenge, he does not receive collateral at all (1 btc equivalent of 12K usdt)
  - If Bob acepted the challenge, Alice just bought 9.09 btc at ~11K usdt while
    the price was 12K usdt. She can sell it for the profit of 9090 usdt.
    She can pay off the liquidity provider from this profit.
   
If the price is 9K at the liquidation event:
  - Alice does not challenge the liquidation event
  - If alice does not want to default, she adds btc to the collateral
  - If she defaults, Bob recovers only part of his loan.
    Bob should have acted before the price went below 10K.
    
The duration of the 'pre-liquidation' state has to be short, for the price to not fall too low.

At the same time, Alice needs to be able to come up with 100K liquidity in-time,
and to detect the malicious liquidation attempt in time.

Alice may want to outsource the 'challenge' part of the contract to the liquidity provider,
by giving them the right to challenge the liquidation on her behalf.
This liquidity provider is incentivized to monitor the state of the contract to detect malicious liquidation attempts,
from which they can profit.

If the liquidity provider gets the ability to challenge autonomously from Alice,
there is a risk of the creditor and the liquidity provider colluding to steal the collateral.

The "watchtower" contract shall send 1 btc back to alice in case of successful challenge to avoid this risk.
But this means that it will not be profitable for the "watchtower" to challenge
unless the malicious liquidation attempt was made at the price above 12360 usdt per 1 btc.
Still, this corresponds to about 80% LTV, and this can be a high enough bar for liquidation.
We can say that the 80% LTV is the liquidation threshold and below that, Alice does not have protection of a watchtower
(but she can still do the challenge herself, or with liquidity provider who she trust to not collude with creditor)
There can be a margin call at 75% LTV where Alice should be increasing collateral. At 80% LTV she is losing protection
of the watchtower, and at 90% the oracle releases the signature. Between 80% and 90% LTV she would still be able to defend
by doing the challenge herself, if the oracle happens to be malicious and releases the signature too early.

The "watchtower" that is colluded with creditor can just not do its job, and do not initiate a challenge for
malicious liquidation. The debtor can then miss the malicious liquidation event and lose the collateral.
The oracle needs to be colluding with the creditor, too, for the malicious liquidation to be possible.
Creditor, "watchtower", and oracle can not know if the debtor is watching, or hired another watchtower.
If the debtor is watching and has liquidity to challenge, the creditor will lose if they attempt malicious liquidation.
Using multiple watchtowers for protection is better than using a quorum of multiple oracles for allowing the liquidation,
because only one watchtower needs to be working, and the debtor themself can take the role of a watchtower.

The oracle can happen to be malicious the other way - do not release the signature when the price drops.
To protect the creditor from this, the contract described above needs to be combined with the
"Price-dependent loan liquidation without involving an oracle" that is described
at https://gist.github.com/dgpv/49bba5ac33764301204493f2837be270, to allow the creditor to initiate the liquidation
without the oracle (but they will need liquidity)