Discreet Log Contract (DLC)

Due to the lack of a Turing-complete virtual execution environment on the Bitcoin network, building a smart contract that can truly manage users' collateral funds is impossible. When protocols such as lending, options, and futures require liquidation of user positions based on oracle prices, retaining control over user assets is inevitably necessary, which undoubtedly imposes a trust cost on users to trust that the protocol will not act maliciously.

Discreet Log Contracts (DLC) are introduced to address this issue. DLC utilizes a cryptographic technique called adaptor signatures, enabling Bitcoin scripts to create financial contracts programmatically dependent on external events. Adaptor signatures only allow a signature to become valid after adding a private key. Taking Schnorr signatures as an example, the standard form of a Schnorr signature is (R, s), where:

# The nonce value r used for signing is multiplied by the elliptic curve generator point G, also known as the public key of r.
R = r.G  

# p is the signing private key, and P is the public key.
s = r + Hash(R || m || P) * p 

# To verify the signature, we need to verify that: 
s.G = r.G + Hash(R || m || P) * p.G = R + Hash(R || m || P) * PK.

Suppose I provide a pair of data (R, s'), where:

R = R1 + R2 = r1.G + r2.G
s' = r1 + Hash(R || m || P) * p 

This is not a valid Schnorr signature as it does not pass the verification formula. However, I can prove to the verifier that if TA knows the private key r2 of R2, it can be turned into a valid signature:

s'.G + R2 = R1 + Hash(R || m || P) * P + R2 = R + Hash(R || m || P) * P

Adapter signatures make a signature's validity dependent on secret data and are verifiable. Here's how they can be applied using a simple example:

• Suppose Alice and Bob bet on the opposite outcomes of a sports match (assuming no draw), each betting 1 $BTC. The one who predicts correctly wins the entire 2 $BTC wager. Once the terms are agreed upon, they lock the wager in a multi-signature wallet that requires multi-party signatures to release the funds.

• The next step is to choose an oracle or even a network of oracles, which will publicly announce the match's result (typically, this information source is found off-chain. It could be a website that publishes match results or an exchange providing asset prices).

• It's important to note that the oracle doesn't need any details about the bet or who is involved in the DLC. Its job is strictly limited to providing the result. Once the event occurs, the oracle publishes an encrypted proof called a commitment, indicating that it has determined the event's outcome.

• To claim the funds locked in the multi-signature wallet, the winning party, Alice, uses the commitment provided by Oracle to create a valid private key. This allows her to sign a transaction and spend the funds in the wallet. This transaction is added to the Bitcoin blockchain, making it final and secure.

What does this have to do with the liquidation mechanism of the lending protocol?Assume Alice collateralizes $ORDI as collateral assets and borrows sBTC worth 0.15 BTC. The lending position will only transition to a liquidation state when the oracle reports a price for $ORDI below 225,000 SATS/ORDI. We want the liquidator to be able to liquidate the position without permission when it's in a liquidation state while ensuring that they cannot manipulate Alice's collateral assets until the price reaches the liquidation price. DLC can effectively solve this problem.In simple terms, in the above scenario, Alice essentially enters into a bet with the protocol on the price of $ORDI:

• If the price is below 225,000 SATS/ORDI, the protocol can seize Alice's collateral and assume the corresponding sBTC debt.

• If the price is greater than or equal to 225,000 SATS/ORDI, nothing happens, and asset ownership remains unchanged.

Here, we need the Oracle to commit to a signature s_c_i on the result with a nonce R_c when the price is below 225,000 SATS/ORDI. As the outcome of the above bet only requires execution when the price is below 225,000 SATS/ORDI, we have only one outcome: Execute Liquidation, and the collateral belongs to the protocol.

To this end, Alice and the protocol must create a commitment transaction for this outcome. However, the signatures created by Alice and the protocol for this transaction are not(R, s), but adapter signatures (R, s'). This means that the signatures exchanged between the parties cannot directly unlock this contract; instead, a secret value must be revealed. This secret value is precisely the pre-image ofs_c_1.G, the oracle's signature. Additionally, because the oracle's signature nonce value is already determined R_c, s_c_1.G can be constructed.

s_c_1.G = R_c + Hash(R_c || 'Execute Liquidation' || PK_c) * PK_c

The oracle will publish the signature when the price exceeds 225,000 SATS/ORDI (R_c, s_c_1). Then, the protocol can complete the opponent's adapter signature and add its signature, making the above transaction valid, broadcasting it to the network, and triggering settlement effects. Conversely, if the price is not below 225,000 SATS/ORDI, oracle will not publish s_c_1, and this commitment transaction will not become valid.

Essentially, DLC allows users and the protocol to use the Bitcoin blockchain as a medium for agreements, with both parties locking funds in a multi-signature address to construct a DLC script. These funds can only be used and redistributed according to certain rules when the oracle publishes specific information at a specified time. In Shell Finance, the protocol leverages DLC to implement a liquidation mechanism involving external price oracles without users needing to trust any entity.