The Lava Loans protocol (v2) is a scheme designed by Lava that is based on Discreet Log Contracts (DLCs) to facilitate a trustless Bitcoin collateralized loan system. The massive market implosion last cycle caused by centralized platforms facilitating Bitcoin-backed loans showed that such products and services, if left unchecked, can pose a huge systemic risk to the entire market in the ecosystem.

Lava aims to provide the same functionality that users of such centralized platforms are looking for, but in a decentralized and atomic way, using DLCs.

DLCs, for those unfamiliar with the concept, are a smart contract 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 sporting event, etc. This is done by depending on an oracle, or a set of multiple oracles, signing a message that confirms 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 in a certain way.

The advantage of DLCs is that 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 use 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 broadcasts the signed message publicly at the appropriate time, and that gives both users all the information they need to settle the contract correctly.

Lava is designed to leverage a modified variant of DLCs, alongside stablecoins on other networks, to facilitate a bitcoin-backed loan that can be made atomically and trustlessly (i.e. with the guarantee that the lender cannot gain control of bitcoin without transferring control of the stablecoin to the borrower).

Instantiation

Funding the DLC is a two-step process on the Lava Protocol, given the requirement that the stablecoins given in exchange for the collateral tied up in the contract be atomic. In the first step, the borrower creates a script that allows them to reclaim their coin 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 to the DLC. The lender then exchanges a hashlock for use later in the protocol with the borrower.

From this point, the lender must 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 additional stablecoins that remain in the contract and cannot be reclaimed by the lender until the contract is completed. This will be explained later.

After the setup phase, the borrower releases the preimage to the hashlock, claims the stablecoins, and allows the lender to move the bitcoin from the staging address to a finalized DLC. At this point, the contract is active.

Execution

During the life of the contract, there are three ways the loan can be settled, either at maturity or during the term. First, the lender can execute the DLC with the borrower’s adapter signature and an attestation of the current price from the oracle(s). Second, the borrower can execute the DLC with the borrower’s adapter signature and an attestation from the oracle(s). Finally, the borrower can repay the loan on the alt-chain, allowing them to reclaim bitcoin collateral when the lender claims their repayment and stablecoin collateral. All of these execution paths distribute the correct amount of bitcoin to both parties based on the market price confirmed by the oracle(s).

The repayment path uses the second hash preimage that the lender generated during setup. The DLC script has been modified so that the borrower can reclaim the collateral at any time during the life of the contract, as long as they have the preimage that the lender generated. On the alt-chain, the stablecoin contract has also been set up to require the lender to reveal that preimage in order to reclaim their repayment and collateral.

This repayment structure is added to address the incentive when a repayment is made but the lender does not finalize the repayment because the interest payment on the outstanding loan is greater than the interest that could be earned by issuing a new loan. This is also why the lender is required to collateralize the alt-chain contract with additional stablecoins, creating an incentive for them to honor a repayment. Without doing so, they cannot reclaim the collateral, 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 releases the preimage to reclaim the repayment and stablecoin collateral, the borrower can unilaterally spend the DLC output using the released preimage. This ensures that the borrower can unilaterally reclaim his bitcoin collateral after the lender takes possession of his loan repayment.

Liquidation and guarantees

Similar to DLC Markets’ proposal, Lava supports a liquidation procedure. In the event that the oracle confirms a price lower than 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 ensure that in the event of a massive price swing that reduces the collateral value above the value of the loan, the lender is able to liquidate it when necessary to cover the stablecoin value that the borrower claimed. Otherwise, they could be faced with the risk of waiting until the contract expires and being stuck with 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 a disaster recovery option available long after the contract has expired. During setup, signatures for pre-signed transactions are exchanged long after the contract has expired. These are used in the event that the oracle(s) do not provide signatures on price attestations, or in the event that the borrower stops working with the lender, or vice versa.

The lender can use one of these to claim the entire bitcoin collateral in the event that the oracle(s) do not confirm the price, or the borrower does not cooperate 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 is blocked long after the lender is available. This allows the borrower to eventually reclaim their collateral if the oracle(s) and lender become unresponsive.

Conclusion

By slightly modifying the DLC protocol to include a base hashlock and introducing a liquidation mechanism similar to DLC Markets, the Lava Protocol has created a variant of DLCs that is perfectly suited for bitcoin collateralized lending. While the reliance on oracles still exists, as with any DLC protocol or application, the entry and exit of the loan is completely atomic and trustless between the borrower and the lender.

This is invaluable in subtly adapting existing Bitcoin contract structures to specific use cases, and provides a way to meet a broad-based need in the ecosystem without the systematic risk of instability that centralized equivalents have created in the past.