The Lava Loans protocol (v2) is a scheme designed by Lava building upon Discreet Log Contracts (DLCs) to facilitate a trustless Bitcoin collateralized loan system. The huge implosion in the market last cycle caused by centralized platforms facilitating Bitcoin backed loans showed that left unchecked, such products and services can present a massive systemic risk to the entire market in the ecosystem.
Lava seeks to provide the same utility users of such centralized platforms sought in a decentralized and atomic fashion, using DLCs.
DLCs, for those unfamiliar with the concept, are a smart contract designed to settle a certain way depending on the outcome of some event outside of the Bitcoin protocol, i.e. the price of Bitcoin, the outcome of a sports game, etc. This is done by depending on an oracle, or a set 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 adapter signatures that unlock specific pre-signed transactions that settle the contract a certain way.
The benefit of DLCs is they can be done privately. As long as the oracle(s) publish the keys they will use to sign outcomes for specific events at specific times, any user can take that information and construct pre-signed transactions to settle correctly based on the range of possible outcomes without the oracle ever knowing that a contract exists. The oracle simply publicly broadcasts the signed message at the appropriate time, and that gives both users all the needed information to settle the contract correctly.
Lava is designed to make use of a modified variant of DLCs, in addition to stablecoins on other networks, in order to facilitate a bitcoin collateralized loan that can be entered into atomically and trustlessly (i.e. guaranteeing that the lender cannot gain control of bitcoin without releasing control of the stablecoin to the borrower).
Instantiation
The funding of the DLC is a two step process in the Lava protocol, given the requirement that the stablecoins given in exchange for the collateral being locked in the contract must be atomic. In the first phase, the borrower creates a script that allows them to claim their coin back after a timelock, or allows the lender to complete the funding with a hash preimage and signature from the borrower. They then sign a transaction that moves the coins from this staging address into the DLC. The lender then exchanges a hashlock for use later in the protocol with the borrower.
From this point, the lender needs to fund a similar atomic exchange contract with the borrower on the chain hosting the stablecoin. This contract allows the borrower to claim the stablecoins with the same preimage used to finalize the DLC on Bitcoin, or the lender to reclaim the stablecoins after a timeout. The contract on the alt-chain is also collateralized with extra stablecoins that remain in the contract, and cannot be claimed back by the lender until after the completion of the contract. This will be explained later.
After the setup phase, the borrower releases the preimage to the hashlock, claims the stablecoins, and enables the lender to move the bitcoin from the staging address into a finalized DLC. At this point the contract is active.
Execution
During the lifetime of the contract there are three ways that the loan can be settled, either at expiry or during its lifetime. Firstly, the lender can execute the DLC with the borrower’s adaptor signature, and an attestation of the current price from the oracle(s). Secondly, the borrower can execute with the lender’s adaptor signature and an attestation from the oracle(s). Lastly, the borrower can repay the loan on the alt-chain, enabling them to claim back bitcoin collateral when the lender claims their repayment and stablecoin collateral. All of these execution paths disperse the appropriate amount of bitcoin to both parties based on the market price attested to by the oracle(s).
The repayment path makes use of the second hash preimage that the lender generated during the setup. The DLC script is modified allowing the borrower to claim back the collateral at any time during the contract lifetime as long as they have the preimage to that the lender has generated. On the alt-chain, the stablecoin contract is also established to require the lender to reveal that preimage to claim back their repayment and collateral.
This construction for repayment is added to deal with the incentive where a repayment is made, but the lender does not finalize the repayment because the interest payment on the loan outstanding is greater than the interest that could be earned from them issuing a new loan. This is also the reason that the lender is required to collateralize the alt-chain contract with extra stablecoins, creating an incentive for them to redeem a repayment. Without doing so, they cannot claim the collateral back, thereby 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 to not do so.
Once the lender releases the preimage to claim back the repayment and the stablecoin collateral, the borrower is then capable of unilaterally spending the DLC output by using the released preimage. This guarantees that the borrower is able to unilaterally reclaim their bitcoin collateral after the lender takes possession of their loan repayment.
Liquidation and Safe Guards
Like the DLC Markets proposal, Lava supports a liquidation procedure. In the case that the oracle attests to a price that is below a pre-defined liquidation level, pre-signed transactions corresponding to the liquidation event can be used by the lender to claim the entirety of the collateral. This is to guarantee that during the event of a massive price swing that lowers the collateral value beyond the loan value, the lender is capable of liquidating it when necessary to cover the stablecoin value the borrower claimed. Otherwise, they could be faced with the risk of waiting until the contract expiry and being stuck with bitcoin that is less valuable than what they have lent out, resulting in a financial loss for the lender.
In addition to the liquidation procedure, there is also an emergency recovery option available long after the contract expiry. During set up signatures for pre-signed transactions long after the contract expiry are exchanged. These are used in the event that the oracle(s) fail to deliver signatures on price attestations, or in the event that the borrower stops cooperating with the lender, or vice versa.
The lender is capable of using one of these to claim the entirety of the bitcoin collateral in the event the oracle(s) don’t attest to the price, or the borrower becomes non-cooperative in that case. This is to ensure that the bitcoin in the DLC is never at risk of being burned. For similar reasons, a transaction timelocked for long after the lender’s is available. This allows the borrower to eventually claim back their collateral if the oracle(s) and lender become unresponsive.
Conclusion
By slightly modifying the DLC protocol to include a basic hashlock, and the introduction of the liquidation mechanism similar to DLC Markets, the Lava protocol has created a variant of DLCs perfectly suited for bitcoin collateralized lending. While the dependence on oracles still exists, like with any DLC protocol or application, the entry and exit of the loan is completely atomic and trustless between the borrower and lender.
This proves an immense amount of value in subtly tweaking existing Bitcoin contract structures to fit specific use cases, and offers a pathway to meeting a widely demanded need in the ecosystem that does not present the systemic risk of instability that centralized equivalents created in the past.