He Lava Lending Protocol (v2) is a scheme designed by Lava that relies on discrete ledger contracts (DLC) to facilitate a trustless bitcoin-backed lending system. The massive market implosion in the last cycle caused by centralized platforms facilitating bitcoin-backed lending showed that if left unchecked, such products and services can pose a massive systemic risk to the entire ecosystem market.
Lava seeks to provide users of centralized platforms with the same utility they seek in a decentralized and atomic way, using DLC.
DLCs, for those unfamiliar with the concept, are smart contracts designed to settle in 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 relying on an oracle, or a set of multiple oracles, signing a message attesting to the actual outcome of the real-world event. These signed messages are then 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 oracles publish the keys they will use to sign the outcomes of 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 information needed to settle the contract correctly.
Lava is designed to leverage a modified variant of DLC, in addition to stablecoins on other networks, in order to facilitate a bitcoin-collateralized loan that can be made in an atomically trustless manner (i.e. ensuring that the lender cannot gain control of the bitcoin without ceding control of the stablecoin to the borrower).
Instantiation
DLC funding is a two-step process in the Lava protocol, given the requirement that stablecoins given in exchange for collateral locked in the contract must be atomic. In the first phase, the borrower creates a script that allows them to claim their coin after a temporary lock, or allows the lender to complete the funding with a hash preimage and the borrower’s signature. They then sign a transaction that moves the coins from this temporary storage address to the DLC. The lender then exchanges a hash lock for later use in the protocol with the borrower.
From this point, the lender must fund a similar atomic swap 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 get the stablecoins back after a timeout. The contract on the alt-chain is also collateralized with additional stablecoins that remain on the contract and cannot be claimed by the lender until after the contract is finalized. 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 bitcoins from the staging address to a finalized DLC. At this point, the contract is active.
Execution
During the contract term, there are three ways to settle the loan, either at maturity or during the term. First, the lender can execute the DLC with a signature from the borrower’s adapter and a certification of the current price from the oracle(s). Second, the borrower can execute it with a signature from the lender’s adapter and a certification from the oracle(s). Finally, the borrower can repay the loan on the alt-chain, allowing the borrower to claim the collateral in bitcoins when the lender claims repayment and the collateral in stablecoins. All of these execution paths distribute the appropriate amount of bitcoins to both parties based on the market price certified by the oracle(s).
The repayment path uses the second hash preimage that the lender generated during setup. The DLC script is modified to allow the borrower to claim the collateral at any time during the contract term, as long as they have the preimage that the lender has generated. On the alt-chain, the stablecoin contract is also set up to require the lender to reveal that preimage in order to claim their repayment and the collateral.
This construct for repayment 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 they could earn if they issued 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 redeem a repayment. Without doing so, they cannot claim the collateral, creating an incentive for them to honor the repayment and release the collateral in bitcoins even when there is a financial incentive due to the interest payments not to do so.
Once the lender releases the preimage to claim repayment and stablecoin collateral, the borrower can unilaterally spend the DLC output using the released preimage. This ensures that the borrower can unilaterally claim their bitcoin collateral after the lender takes ownership of their loan repayment.
Settlement and safeguards
Much like DLC Markets’ proposal, Lava supports a liquidation procedure. In the event that the oracle attests to a price that is below a predefined liquidation level, the lender can use the previously signed transactions corresponding to the liquidation event to claim the entire collateral. This is to ensure that in the event of a massive price swing that reduces the value of the collateral beyond the value of the loan, the lender is able to liquidate it when needed to cover the value of the stablecoin that the borrower claimed. Otherwise, they could face the risk of waiting until the contract expires and being left with bitcoins that are less valuable than what they have lent, 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 expires. During setup, signatures are exchanged for previously signed transactions long after the contract expires. These are used in case the oracle(s) fail to deliver signatures on price certifications, or in case the borrower stops cooperating with the lender, or vice versa.
The lender can use one of these to claim the entire collateral in bitcoins in case the oracle(s) fail to certify the price or the borrower fails to cooperate in that case. This is to ensure that the bitcoins on the DLC are never at risk of being burned. For similar reasons, a transaction is blocked for a long time after the lender's is available. This allows the borrower to eventually claim their collateral if the oracle(s) and the lender fail to respond.
Conclusion
By slightly modifying the DLC protocol to include a basic hashlock and introducing a settlement mechanism similar to that of DLC Markets, the Lava protocol has created a DLC variant 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 lender.
This demonstrates an immense amount of value in subtly tweaking existing bitcoin contract structures to fit specific use cases and offers a path to fulfilling a widely-demanded need in the ecosystem that does not present the systemic risk of instability that centralized equivalents created in the past.
