the Lava Loans Protocol (Version 2) It is a scheme designed by Lava based on confidential ledger contracts (DLCs) to facilitate a trustless Bitcoin-backed lending system. The massive market crash in the last cycle caused by centralized platforms facilitating Bitcoin-backed loans showed that leaving such products and services unchecked can pose a massive systemic risk to the entire market in the ecosystem.
Lava seeks to provide the same user benefit of such centralized platforms that are searched in a decentralized and atomic manner, using DLCs.
For those unfamiliar with the concept, DLCs are smart contracts designed to settle in a certain way depending on the outcome of an event outside of the Bitcoin protocol, such as the price of Bitcoin, the outcome of a sports game, etc. This is done by relying on an oracle, or a group of multiple oracles, who sign a message attesting to the actual outcome of the real-world event. These signed messages are used as the basis for switch signatures that open specific pre-signed transactions that settle the contract in a certain way.
The benefit of DLCs is that they can be implemented privately. As long as oracles publish the keys they will use to sign outcomes for specific events at specific times, any user can take that information and create pre-signed transactions to settle correctly based on the set of possible outcomes without the oracle ever knowing that the contract exists. Simply put, the oracle broadcasts the signed message publicly at the appropriate time, giving both users all the information they need to settle the contract correctly.
Lava is designed to leverage a modified variant of DLCs, as well as stablecoins on other networks, in order to facilitate a Bitcoin-collateralized loan that can be entered into atomically and trustlessly (i.e. ensuring that the lender cannot control the Bitcoin without ceding control of the stablecoin to the borrower).
representation
DLC funding is a two-step process in the Lava protocol, due to the requirement that stablecoins offered in exchange for collateral locked in the contract must be atomic. In the first stage, the borrower creates a script that allows them to reclaim their coins after a set period of time, or allows the lender to complete the funding with a pre-hash and signature from the borrower. They then sign a transaction that moves the coins from this staking address to the DLC. The lender then exchanges a hash for later use in the protocol with the borrower.
From this point, the lender needs to fund a similar atomic swap contract with the borrower on the chain that hosts the stablecoin. This contract allows the borrower to claim the stablecoin in the same initial form used to complete the DLC on Bitcoin, or for the lender to reclaim the stablecoin after the deadline. The contract on the alternate chain is also collateralized with additional stablecoins that remain in the contract, and the lender cannot claim them back until after the contract is completed. This will be explained later.
After the setup phase, the borrower releases the initial image to the hashlock, claims the stablecoins, and enables the lender to transfer the bitcoin from the staging address to the final DLC. At this point, the contract becomes active.
to implement
During the life of the contract, there are three ways in which the loan can be settled, either at expiration or during its life. First, the lender can execute the DLC agreement with the signature of the borrower’s transferor, and a certificate of the current price from the oracle. Second, the borrower can execute with the signature of the lender’s transferor, and a certificate from the oracle. Finally, the borrower can repay the loan on the alt chain, which allows him to claim the Bitcoin collateral when the lender demands repayment and the stablecoin collateral. All of these execution paths distribute the appropriate amount of Bitcoin to both parties based on the market price as witnessed by the oracle.
The repayment path uses the second hash image generated by the lender during setup. The DLC text is modified to allow the borrower to reclaim the collateral at any time during the life of the contract as long as they have the hash image generated by the lender. On the alt chain, the stablecoin contract is also created to require the lender to disclose this hash image in order to reclaim their repayment and collateral.
This repayment structure was added to address the incentive in the event that the loan is repaid, but the lender does not complete the repayment because the interest payments on the outstanding loan are greater than the interest that could be earned from issuing a new loan. This is also why the lender is required to collateralize the alternative chain contract with additional stablecoins, creating an incentive for them to redeem the repayment. Without doing so, they cannot claim the collateral back, thus creating an incentive for them to honor the repayment and release the Bitcoin collateral even when there is a financial incentive due to the interest payments not to do so.
Once the lender issues the initial image to claim the repayment and the stablecoin collateral, the borrower is then able to unilaterally spend the DLC output using the issued initial image. This ensures that the borrower is able to unilaterally redeem the Bitcoin collateral after the lender takes possession of their loan repayment.
Liquidation and guarantees
Like DLC Markets’ proposal, Lava supports a liquidation procedure. If the oracle proves the price is below a pre-determined liquidation level, the lender can use the pre-signed transactions corresponding to the liquidation event to claim the entire collateral. This ensures that during massive price fluctuations that reduce the value of the collateral beyond the value of the loan, the lender is able to liquidate it when necessary to cover the value of the stablecoin claimed by the borrower. Otherwise, they risk waiting until the contract expires and defaulting on a Bitcoin that is worth less than what they lent, resulting in a financial loss for the lender.
In addition to the liquidation procedure, there is also an emergency redemption option available long after the contract expires. During the setup, signatures are exchanged for previously signed transactions long after the contract expires. These are used in the event that the fortune tellers fail to deliver signatures on the price certificates, or in the event that the borrower stops cooperating with the lender, or vice versa.
The lender can use one of these methods to claim the entire collateral of the bitcoins if the fortune tellers do not confirm the price, or in this case the borrower does not cooperate. This is to ensure that the bitcoins in the DLC are not at risk of being burned. For similar reasons, the transaction is locked for a long period after the lender’s collateral is available. This allows the borrower to eventually claim their collateral if the fortune tellers and the lender do not respond.
conclusion
By slightly modifying the DLC protocol to include a core hash lock, and introducing a liquidation mechanism similar to DLC markets, the Lava Protocol has created a different type of DLC that is well-suited for Bitcoin-collateralized lending. While the oracle reliance is still there, as with any DLC protocol or implementation, the entry and exit of a loan is completely atomic and does not rely on trust between borrower and lender.
This demonstrates that there is a tremendous amount of value in subtly modifying existing Bitcoin contract structures to suit specific use cases, and offers a path to meeting a broad need in the ecosystem that does not pose the risk of systemic instability that centralized equivalents have created in the past.
Comments are closed, but trackbacks and pingbacks are open.