Skip to content

Instantly share code, notes, and snippets.

@RubenSomsen
Last active May 2, 2022 13:10
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save RubenSomsen/bf08664b3d174551ab7361ffb835fcef to your computer and use it in GitHub Desktop.
Save RubenSomsen/bf08664b3d174551ab7361ffb835fcef to your computer and use it in GitHub Desktop.
P2P Loans on Liquid

Liquid P2P Loans

This is a variation of the Hodl Hodl contract design for Liquid, but without an arbitrator (not counting Liquid itself). It's pretty simple and similar ideas exist, but it seemed interesting enough to write up and spur some conversation.

I'll begin by explaining the high level concept. For the full details, please examine the steps in the diagram below.

Concept

A contract where the Borrower puts up 1.5x collateral (e.g. 1.5 L-BTC) in order to borrow another asset (e.g. $10k USDT, if we assume that's the price of 1 L-BTC). The borrower can reclaim the collateral if they pay back the loan before expiry. If expiry is reached, the collateral goes to the Lender.

Use cases

  • Spending L-BTC without necessarily selling, which may trigger a taxable event in some regions
  • Leveraging your L-BTC position by buying more L-BTC with the USDT you borrowed

Risks

  • Borrower loses the collateral (likely to be overvalued) if they fail to repay the loan
  • Lender loses money if the collateral is no longer worth enough to cover the loan at expiry

The Lender's risk can be minimized by increasing the collateral. The Borrower's risk can be minimized by creating multiple "Repay Loan" transactions (see diagram) which pay back to a multisig with a potential buyer of the collateral. This way the Borrower can agree to give part of the collateral to the potential buyer, provided they pay back the loan in their stead. The same agreement could be made with the Lender, but they may not be willing to cooperate, as they'll receive the full collateral if the Borrower fails to pay.

Market Place

This concept still needs a market place where the Lender and Borrower can find each other. At a minimum, a contract can be achieved in 3 communication rounds:

  • Borrower makes an offer (e.g. revealing a 1.5 L-BTC UTXO for $10k USDT)
  • Lender takes it and signs "Initiate Loan" and "Repay Loan" (see diagram) (We forego the "Forfeit Collateral" tx in favor of having the "Initiate Loan" tx contain a timelocked script, saving a communication round)
  • Borrower signs "Initiate Loan" and sends it to the blockchain

-- Ruben Somsen

See also my other work.

Display the source blob
Display the rendered blob
Raw
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@ecurrencyhodler
Copy link

Thanks for the write up Ruben! Glad this is being thought about for the Bitcoin ecosystem. Here are a few questions:

  1. What would be used as oracles in this system? I wonder if future DLC oracles could be re-used for a system like this.
  2. One of the crucial parts to decentralized lending is some sort of exchange to sell the collateralized BTC. Do you have any thoughts as to whether this should be provided by a centralized exchange or if there are any dex's planned for the Liquid network that could be leveraged?
  3. Is there any bail out mechanism in the event the loan becomes undercollateralized?

@RubenSomsen
Copy link
Author

@ecurrencyhodler Thanks for reading :)

  1. The beauty is that no oracle is required. If the collateral is insufficient, the Lender would never agree to the position.
  2. These contracts would take place on top of Liquid, but the market place for Borrowers and Sellers to find each other would have to take place elsewhere. Maybe you can do some kind of on-chain signaling, but it would not be very efficient.
  3. There is not. This is a risk the Lender takes on (and could hedge against on other platforms). If Borrower and Lender agree, they can add more collateral or allow the Lender to liquidate the collateral, but this all needs the explicit agreement of the Borrower, and is thus not guaranteed.

@ecurrencyhodler
Copy link

ecurrencyhodler commented Oct 24, 2020

The beauty is that no oracle is required. If the collateral is insufficient, the Lender would never agree to the position.

Okay so this seems to be just a pure lending contract that doesn't allow people to sell prior to the expiration date of the loan. Therefore the lender is exposed to a significant amount of risk. Due to the volatile nature of the price of Bitcoin, I would argue this exposes the lender to too much risk especially when compared with already existing lending platforms. With where the current lending ecosystem is at with centralized lending services like BlockFi and decentralized lending platforms like Compound, I think a project like this would need a more robust and vertically integrated offering to really take off.

IMO, the bare minimum a decentralized Bitcoin lending platform built on top of Liquid would need in order to really thrive would require:

  1. Oracle to trigger selling of the collateral.
  2. Automated selling of the collateral.
  3. Bail out mechanism of some sort for under collateralized loans.

But I think this is a great first step and foundation to build off of.

@RubenSomsen
Copy link
Author

RubenSomsen commented Oct 25, 2020

@ecurrencyhodler

this exposes the lender to too much risk especially when compared with already existing lending platforms

And Bitcoin is not as cheap, fast, and reliable as online banking, but that's the price you pay for decentralization. The point here is to explicitly not rely on third parties.

Of course you can get any behavior you want if you do. Namely, with an oracle you can:

  • Ensure the Lender learns the private key of the Borrower once a certain price is reached (by revealing LiquidationKey = BorrowerKey - OracleKey)
  • Ensure that part of the collateral goes back to the buyer in case the loan is not paid back on expiry (via a DLC on the "Forfeit Collateral" tx)

Note that this latter point can also be somewhat mitigated without oracles if you read the section of this gist under "Risks".

But then again, there are many more interesting things you can do once you accept the presence of oracles: https://twitter.com/SomsenRuben/status/1301941083715362821

@Kukks
Copy link

Kukks commented Jun 1, 2021

Have you seen the research paper from Dmitry also on Liquid loans? https://ruggedbytes.com/articles/ll/

@RubenSomsen
Copy link
Author

@Kukks thanks for the link, yup, it's actually linked in this write-up in the top paragraph: "similar ideas exist"

His method is ultimately more powerful, because covenants can do more than these relatively straight-forward payment conditions, but this one's more simple to implement and results in smaller transactions.

@Kukks
Copy link

Kukks commented Jun 1, 2021

@Kukks thanks for the link, yup, it's actually linked in this write-up in the top paragraph: "similar ideas exist"

His method is ultimately more powerful, because covenants can do more than these relatively straight-forward payment conditions, but this one's more simple to implement and results in smaller transactions.

Doh, missed the link!
Let me try this again:
Have you seen this implementation:

Dmitry also has some additional sketches around the loans concept in his gist profile which are quite interesting:
https://gist.github.com/dgpv

@RubenSomsen
Copy link
Author

@Kukks I had seen a few of the sketches, but not the other links. Nice.

Generally speaking covenant stuff like this is quite interesting and powerful. Really cool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment