of Lava Loans Protocol (v2) is a scheme designed by Lava based on Discreet Log Contracts (DLC) to facilitate a trustless Bitcoin-backed lending system. The massive market collapse in the last cycle caused by centralized platforms facilitating Bitcoin-backed lending demonstrated that such products and services, if left unchecked, can pose significant systemic risk to the entire market in the ecosystem.
With DLC, Lava aims to provide the same utility that users of centralized platforms desire, but in a decentralized and atomic way.
A DLC, for those unfamiliar with the concept, is a smart contract that is designed to settle in a specific way depending on the outcome of some event outside of the Bitcoin protocol (such as the price of Bitcoin, the outcome of a sports game, etc.). It does this by relying on an oracle or set of oracles that sign messages that attest to the actual outcome of a real-world event. These signed messages are then used as the basis for an adaptor signature that unlocks specific pre-signed transactions that will settle the contract in a specific way.
The advantage of DLC is that it can be run privately. As long as the oracle publishes the key it uses to sign the outcome of a particular event at a particular time, any user can take that information and construct a pre-signed transaction that will settle correctly based on the range of possible outcomes. The oracle has no knowledge of the existence of the contract; it simply publishes a signed message at the appropriate time, providing both users with all the information they need to settle the contract correctly.
Lava is designed to utilize a modified version of DLC in addition to other on-network stablecoins, enabling Bitcoin-backed loans that can be concluded atomically and trustlessly (i.e. ensuring that lenders cannot gain control of Bitcoin without transferring control of the stablecoin to the borrower).
Instantiation
Funding DLC is a two-step process in the Lava protocol due to the requirement that the stablecoins offered in exchange for the collateral locked in the contract must be atomic. In the first step, the borrower creates a script to either get their coins back after a timelock or allow the lender to complete the funding using a hash preimage and signature from the borrower. Then, they sign a transaction that moves the coins from this staging address to the DLC. The lender then exchanges a hashlock with the borrower for later use in the protocol.
At this point, the lender must fund a similar atomic exchange contract with the borrower on the chain that hosts the stablecoin. This contract allows the borrower to claim the stablecoin at the same preimage used to finalize the DLC in Bitcoin, and allows the lender to recover the stablecoin after a timeout. The contract on the altchain is also collateralized with any additional stablecoins remaining in the contract, which the lender cannot claim until the contract is completed. More on this later.
After the setup phase, the borrower releases a preimage to the hashlock, claims the stablecoins, and allows the lender to move bitcoin from the staging address to the finalized DLC. At this point, the contract becomes active.
execution
During the life of the contract, there are three ways the loan can be settled, either at maturity or during the contract term. First, the lender executes DLC using the borrower’s adapter signature and a proof of the current price from the oracle. Second, the borrower executes using the lender’s adapter signature and a proof from the oracle. Finally, the borrower repays the loan on the alt-chain and the borrower can claim the Bitcoin collateral when the lender claims the repayment and the stablecoin collateral. All of these execution paths distribute the appropriate amount of Bitcoin to both parties based on the market price attested by the oracle.
The repayment path uses a second hash preimage that the lender generated during setup. As long as the DLC script is modified and the lender has the generated preimage, the borrower can claim the collateral at any time during the contract’s lifetime. On the alt-chain, stablecoin contracts have also been established that require lenders to reveal the preimage in order to repay and claim the collateral.
This repayment structure is added to address the incentive for lenders not to complete repayments, since even if a repayment is made, the interest payments on the outstanding loans are greater than the interest they would earn on issuing new loans. This is also why lenders need to collateralize their altchain contracts with additional stablecoins. This creates an incentive for lenders to redeem repayments. Otherwise, lenders cannot claim their collateral back, creating an incentive to honor repayments and release their Bitcoin collateral, even if they have a financial incentive from the interest payments.
When the lender releases the preimage to claim the repayment and stablecoin collateral back, the borrower can unilaterally spend the DLC output using the released preimage, ensuring that the borrower can unilaterally get their Bitcoin collateral back after the lender receives the loan repayment.
Liquidation and Safety
Like DLC Market ProposalLava supports a liquidation procedure. If the oracle proves the price below a predefined liquidation level, the lender can claim the full amount of the collateral using a pre-signed transaction corresponding to the liquidation event. This is to ensure that if the price fluctuates significantly and the collateral value falls below the loan value, the lender can liquidate it if necessary to cover the value of the stablecoins claimed by the borrower. Otherwise, the lender would face the risk of waiting until the contract expires and being stuck with Bitcoin worth less than the amount lent, which could result in financial losses for the lender.
In addition to the liquidation procedure, there are also emergency recovery options available even after the contract expires. During setup, signatures of signed transactions are exchanged even after the contract expires. These will be used in case the oracle is unable to send a Proof of Price signature or if the borrower stops cooperating with the lender or vice versa.
Lenders can use any of these to claim the full value of their Bitcoin collateral if the oracle does not prove the price or if the borrower becomes uncooperative in that case. This is to ensure that there is no risk of the Bitcoin in the DLC being burned. For similar reasons, lender transactions are time-locked for a long period of time after they are made available. This allows borrowers to eventually get their collateral back if the oracle and lender become unresponsive.
Conclusion
By slightly modifying the DLC protocol to add a basic hashlock and introducing a liquidation mechanism similar to DLC Markets, the Lava Protocol has created a variant of DLC that is ideal for Bitcoin-backed lending. As with other DLC protocols and applications, there is still a dependency on oracles, but originating and terminating loans is completely atomic and trustless between borrowers and lenders.
This could prove of great value by nuanced tailoring of existing Bitcoin contract structures to specific use cases, providing a path to meet widespread needs in the ecosystem without the systemic risk of instability that centralized equivalents have created in the past.
