Bitcoin Non Custodial Oracle - AtomicLoans/atomicloans-rfc GitHub Wiki
Atomic Loans Bitcoin Non-Custodial Oracle provides a mechanism for enabling smart contract-like capabilities on the native Bitcoin chain using an Oracle without signing capabilities.
There are three parties involved in the process. Alice, Bob, and Olivia. Alice the borrower, Bob the lender and Olivia the oracle. Olivia does not need to know of Alice or Bob and preferably does not have contact with Alice or Bob other than broadcasting information to them.
Alice and Bob do not need to trust each other. They must have a separate channel for communicating, and must be able to receive a preimage from Olivia.
Assuming that the Atomic Loans protocol in the other sections of this RFC remains the same, with the exception of the removal of Carol, the script for setting up the collateral takes the form of a 2-of-2 multisig.
OP_2 +--+
<borrower pubkey> |
<lender pubkey> | Liquidation by Lender or Borrower
OP_2 |
OP_CHECKMULTISIG +--+
When setting up the collateral to be locked, both Alice and Bob each use one key.
They sign for all the possible collateral values to be sent to HTLC's that can be claimed by the respective parties, with the preimage revealed by Olivia.
For example, say the current Bitcoin price is $10,000 and the collateralization ratio is 200% (collateral BTC amount being 2 BTC). Alice and Bob should sign for all possible pairs of HTLC's representing the principal + interest amount (i.e. seizable collateral, which can be seized by Bob in the case of liquidation) and the over-collateralization amount (i.e. refundable collateral, which can be refunded by Alice in the case of liquidation).
1.02 BTC to Alice, 0.98 BTC to Bob
1.01 BTC to Alice, 0.99 BTC to Bob
1.00 BTC to Alice, 1.00 BTC to Bob
0.99 BTC to Alice, 1.01 BTC to Bob
0.98 BTC to Alice, 1.02 BTC to Bob
Note: Alice signs for all the liquidations that can be initiated by Bob, and Bob signs for all the liquidations that can be initiated by Alice.
Say the current price of Bitcoin has fallen from $10,000 to $9000, and the loan is being liquidated. In this case, the seizable collateral Bob is entitled to would be 1.11 BTC (10,000 / 9000) to cover the loan, and the refundable collateral Alice is entitled to would be 0.89 BTC.
Once the signatures are generated, Alice or Bob can move the collateral to an HTLC by signing using PrivA or PrivB. They should do this once Olivia reveals the preimage for the observed price, allowing them to move the collateral to an HTLC, with a claim digest that correlates to the preimage revealed by Olivia. However, they can move the collateral to this HTLC at any time. If they do this however, they will not have the preimage necessary to claim the collateral, and the other party will be able to wait for the timeout and take all the funds.
As soon as the preimage is released by Olivia, Alice or Bob would sign using PrivA or PrivB, and would claim using this preimage. If Alice signed, she would use PrivA in order to move the collateral to two different outputs. One, to an HTLC with 0.98 BTC that could be claimed by Alice using the preimage revealed by Olivia, and slashed after a timeout by Bob if Alice did not in fact have the preimage from Olivia. The other output would go directly to Bob. By claiming using the preimage from Olivia, Alice would receive 0.98 BTC. The other output of 1.02 BTC, should be sent directly to the address corresponding to the pubkey of Bob.
Vulnerabilities
One concern is what happens if Alice locks her collateral and signs the necessary outputs, but Bob does not do the same.
To mitigate this, the parties should sign all the possible outputs prior to Alice locking the collateral into the script (by deriving the p2wsh address from the debt agreement information, for instance).
The script should follow the following format:
OP_IF
OP_SIZE +--+
[PUSH 32] |
OP_EQUALVERIFY |
[HASHOP] |
<lender digest> |
OP_EQUALVERIFY | Unlock after repayment
OP_DUP | by Borrower
OP_HASH160, |
<borrower pubkey hash> |
OP_EQUALVERIFY |
OP_CHECKSIG +--+
OP_ELSE
OP_IF
OP_2 +--+
<borrower pubkey> |
<lender pubkey> | Liquidation by Lender or Borrower
OP_2 |
OP_CHECKMULTISIG +--+
OP_ELSE
OP_IF
OP_SIZE +--+
[PUSH 32] |
OP_EQUALVERIFY |
[HASHOP] |
<borrower digest> |
OP_EQUALVERIFY | Seizure by Borrower or Lender
<liquidation expiration> |
[TIMEOUTOP] |
OP_DROP |
OP_DUP |
OP_HASH160 |
<seizable pubkey hash> +--+
OP_ELSE
<seizure expiration> +--+
[TIMEOUTOP] |
OP_DROP | Refund by Borrower
OP_DUP |
OP_HASH160 |
<borrower pubkey hash> +--+
OP_ENDIF
OP_EQUALVERIFY
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
This script is used twice. Once for refundable collateral and once for seizable collateral.
If the borrower doesn't withdraw the loan after the loan has been approved, then the lender can simply cancel the loan by revealing their preimage (Secret B1).
If the lender approve the loan after it has been locked, then the borrower can simply not reveal their preimage when calling withdraw. They will then be able to wait until the Refundable period to retrieve their collateral. During this time, the lenders funds will also be locked until they call cancel, in which case the Borrower can retrieve their collateral. Alternatively, Olivia can also reveal the necessary secret, acting as a state change oracle in order to allow the borrower to retrieve their collateral.
Note: Seizure by Borrower or Lender and Refund by Borrower is only necessary in the case that Olivia is offline for an extended period of time and should be seen as a last resort. Seizure by Borrower is only possible if Alice has not withdrawn the loan.
Liquidation Considerations
In most cases, even in the event of liquidations, the Lender who is lending out stablecoin on Atomic Loans would want to receive that stablecoin back, as opposed to Bitcoin. Hence, we propose a liquidation process that involves converting the Lender's share of the Bitcoin collateral to stablecoin. By giving a premium to the lender in the case of default or the minimum collateralization ratio being below 140%, the protocol will allow liquidators to buy the seizable collateral at a 7% discount. In the case that the lender does not accept the repayment of the borrower (in which they have 48 hours to do so), they should receive a penalty of 2% on the seizable collateral. Olivia is responsible for reading the state of the Ethereum chain, and revealing the proper preimage corresponding to this discount or penalty.
For example, say Alice has defaulted on the loan, and the refundable and seizable collateral should be 1 BTC and 1 BTC at current market price. Since Alice defaulted on the loan, Bob should be given a premium on the Bitcoin in order to ensure it can be liquidated at a discount so that he can ensure he receives his principal + interest back. In this case, the BTC should be split up such that there is a 7% premium on the 1 BTC allocated to the seizable collateral. That is, 1.07 BTC would be allocated to the seizable collateral, and 0.93 BTC to the refundable collateral. This allows Bob to still receive the principal + interest in stablecoin when the Liquidator buys this Bitcoin at a 7% discount.
In the case that Bob does not accept the repayment of Alice, Bob should be given a penalty of 2% for this action. Therefore, if the refundable and seizable collateral were 1 BTC and 1 BTC respectively at current market price, it should be split as 0.98 BTC as seizable collateral and 1.02 BTC as refundable collateral.
Improving decentralization of Oracle
In order to decrease the reliance on Olivia, it is preferable to have multiple unassociated oracles involved in the process. This can be achieved by creating a modified HTLC, with 5/10 preimages required to unlock the seizable or refundable collateral.
Inspired by: https://adiabat.github.io/dlc.pdf