Ordinals Lending
Ordinals: Digital Artifacts to build a liquid economy on top of Native Bitcoin
We are witnessing two types of lending in the BTC ecosystem using the Deep Lake APIs and Ordinals.
Collaborative escrow participation between lender and borrower
Two-Step Lending or Escrow chaining-based Lending
Sneak peek: V2 is so much more fun 😀 and is a clear optimization over V1
In this document, we will discuss a piece of the first approach; and how to implement it using the Deep Lake APIs and Oracle.
Collaborative lending represents the initial wave of lending protocols that emerged in the ecosystem following the advent of the Ordinal movement. People started looking at ways to use their ordinals or art assets to generate liquidity without selling them.
In this approach, all participants in the lending process (lender, borrower, and marketplace) collaborate to finalize the PSBT (partially signed Bitcoin transaction) and subsequently broadcast it to the Bitcoin blockchain...
Here is how it goes:
The borrower makes a borrowing request
The lender accepts the request
The marketplace adds its fee
The borrower signs the request
The lender signs the request
Request gets broadcasted
In this post, we will focus on the first item. Let us dive into how you can achieve this with the Deep Lake APIs.
Assumptions:
The borrower is going to pay for the miner’s fee.
Technical Background
We are going to be using a few endpoints in the Deep Lake Platform:
Escrow endpoints
Create Escrow
Asset endpoints
Create Asset
Outcome endpoints:
Create Outcome
For more information about these endpoints, please refer to this link.
Equipped with our technical tools, and magic APIs, let us get to it.
1. The borrower makes a borrowing request:
A borrowing request has three steps:
Create the Escrow
Prepare the Lock of the Ordinals as the collateral
There is something special happening here: the Lock
action.
The Lock
action is a fundamental feature of Bitcoin and the Deep Lake API, enabling users to securely escrow BTC (whether plain BTC or Ordinals) based on predetermined on-chain conditions.
In our current example, we would like to lock an Ordinal for a certain amount of time, after which we should have either repaid our loan or we were unable to repay the loan.
Repayment will allow the borrower to unlock and claim back his collateral (the ordinal in this case)
Non-repayment will result in a liquidation of the collateral to the lender
A lot to unpack in this action, let us break it down. It has:
Type
field: allows our APIs to identify which processing the caller is looking to apply on the asset he is creatingConfiguration
field: allows our APIs to configure the processing.
In this case, we would like to Lock
, and we would like our Lock
to either be:
Spendable upon a Repay event
Spendable after an expiry date if no Repay was witnessed on chain
It is only natural that our configuration has two paths, each path corresponds to a future possible outcome.
So question! How can we witness Outcomes on chain.
Long answer here. Short answer, by simply asking our Oracle to check for some condition, and verify that these conditions happen and here is how to do that:
This will return an outcome of the form:
Another special thing is happening here, publicKey
has the same shape as the first element in the args
array of the repay path, and the second element in the args
array of the liquidate path.
It does because it should go there.
The idea, here, is to create one outcome with tag: repay
and another with tag: liquidate
and use the publicKey
of each one in the corresponding path.
Pay for the miner fees
OK, so another action here: the Fee
action.
The Fee
action is a simple with:
Type
: the processing is pay for fee using the asset this action is attached to.Configuration
field: empty configuration, because it is a simple action.
The one thing that is special about this action is that it will automatically estimate for the network fees if the caller leaves the amount field
empty, otherwise the caller can set the amount of fees he is willing to pay.
That is a wrap! Rendezvous on the next post.
\
Last updated