Discreet Log Contracts are an old concept in this space at this point, proposed by Thaddeus Dryja (co-creator of the Lightning Network protocol) in 2017. DLCs are a smart contract structure designed to address three issues with contract schemes prior to the proposal: firstly the scalability of the smart contract itself, which required larger on-chain footprints for a larger set of potential outcomes; secondly, the issue of getting data external to the blockchain “into the blockchain” for contract settlement; and lastly, the privacy of users of the smart contract.
The basic scheme is very simple, two parties create a multisig address composed of the two of them, and choose an oracle. After doing so, they create a set of Contract Execution Transactions that interact with the oracle. Say the oracle is announcing the price of bitcoin, and the participants are betting on the price of bitcoin, what the oracle does is publish a set of commitments to the messages it will sign in order to “announce” the price of Bitcoin at a certain time. The CETs are constructed so that the signature on each CET one participant gives to the other is encrypted using adapter signatures. Each signature for the settlement of the contract at any given price can only be decrypted with information from the signed oracle message attesting to that given price. The oracle simply publishes their commitments to messages for whatever data they are acting as the oracle for, and any participant can non-interactively use this information to make a DLC. The last piece is a timelocked refund transaction, if the oracle never broadcasts the necessary information to settle the DLC, after a timelock period extended beyond the contract lifetime has elapsed both parties are simply refunded their money.
This solves the three major issues Tadge (Thaddeus) delineated in the original DLC whitepaper: it is scalable, needing only a single transaction to fund the contract and a single transaction to settle it; it allows a way for external data to be “brought into” the blockchain; and it solves the privacy issue, in that the way oracles just blindly broadcast data to the public they gain no insight into who is using them as an oracle in a contract. You can even use a federation of multiple oracles, where if the value they attest to is close enough to each other the contract settles correctly. One last important thing to note with DLCs, is the oracles lying to settle contracts incorrectly is a very different model than with a traditional escrow multisig. In the escrow model, an oracle can choose to selectively harm a single user by signing for an improper settlement. There is the potential for mitigating the reputational damage there, but in the DLC model an oracle cannot do this. When they sign a message it is used to settle every DLC connected to that settlement message and time, there is no way to selectively act malicious towards a single party because they do not know who is using them.
The only real shortcoming of this scheme, aside from the inescapable trust in an oracle, is the coordination issue. Depending on the nature of the contract, say a bet on the price of Bitcoin versus a bet on a sports game (team X wins or team Y wins), there could either be a handful of CETs or a massive set of CETs to cover all potential outcomes. This opens up two problems: one, if the set of transactions is large enough this creates the potential for network issues and DoS attacks wasting peoples’ time by not completing the contract set up; secondly, the potential for a free option problem that would necessitate an on-chain transaction to deal with. A free option issue would be if the contract is set up and finalized, but the party who winds up with the complete funding signature didn’t broadcast it. This would allow them to only fund the DLC on-chain if it was in there favor and not otherwise, and the only way for the other party to escape this situation would be to double spend their funding output on chain.
DLC Markets
LN Markets recently published an article describing a new DLC specification they have designed to tailor a DLC mechanism towards institutional actors. The existing suite of projects building on DLCs have been tailored more towards retail consumers, and that left room for modification to the design to address the needs of larger institutional actors.
Some issues for institutional customers are: the free options problem, which is not acceptable in that type of environment; the second is a lack of margin calls, i.e. a position either being closed if one party does not have enough margin capital to cover their side of the trade at current price, or that party adding the additional required margin to keep it open; lastly the ability to use capital in a more efficient way rather than having capital in one position locked up from the start to finish of the contract.
To address all of these issues LN Markets have introduced the concept of a DLC coordinator. Rather than peers in a contract directly coordinating between each other to handle the funding and negotiation of the contract, the coordinator can sit in the middle and help facilitate this. This solves the free options problem rather elegantly, by having the coordinator facilitate contract negotiations. Rather than each peer directly interacting with each other to sign the contract execution and funding transactions, they submit their signatures for all of these to the coordinator. At no point will either participant ever have access to the signatures needed to fund the contract, removing the ability for one to have a free option. The coordinator is the only one who will ever have both signatures, and to address the problem of them colluding with a participant or being malicious and not submitting the funding transaction for some other reason, the funding transaction includes a fee payment to them for functioning as a coordinator. This gives them a direct incentive to submit the funding transaction after the DLC has been negotiated and signed.
Another massive efficiency is in the coordination process of constructing the DLC in the first place. Without the coordinator involved, participants would have to communicate with each other, exchange address and UTXO information, and then coordinate setting up the DLC. With the coordinator, users can simply register an xpub and some UTXOs with the coordinator, as well as their offers for contract terms. When someone accepts an existing offer, the coordinator has all the information necessary to construct the CETs, after which they can simply provide them to the person accepting the offer to verify and sign, then transmit signatures to the coordinator. The original offerer will then receive the CETs to verify and sign and return as soon as they come online and decide to accept the counterparty, sending them back to the coordinator who can then combine signatures and submit the funding transaction.
Liquidations
Having the coordinator involved also offers a reliable communication point for adding the final missing piece for DLCs applied in a professional environment: liquidations and handling adding additional margin.
There was a nice infographic from the whitepaper included in the article LN Markets wrote announcing the proposal, but I feel like this one is a lot more intuitive to understand. In addition to all the CETs attached to oracle messages for price announcements that could occur at the contract expiry, there are also special settlement transactions for periods before the actual contract expiry – the interval of which can be decided by the participants in line with the frequency the oracle publishes price messages at. Each party has one special CET for each of these “liquidation times”, where if the price is outside of the contract range (i.e. all of the funds are owed to a single side) at any of those liquidation points they can simply submit this transaction and settle the contract earlier.
If at any point approaching a liquidation time one party is at a liquidation point, they can use the coordinator to coordinate adding margin to the contract, and allowing the other party to realize some of their gains by withdrawing funds from the contract. This would involve both parties collaboratively spending from the funding multisig into a new DLC that would receive more funds from the under-collateralized party and let the “winning” party withdraw some funds. The new DLC would be otherwise set to the same expiry time and with the same liquidation points set leading up to that.
This dynamic brings the capabilities much more in line with what institutional investors expect; the ability to manage liquidity more effectively, to have a contract expire early if one party is under-collateralized based on the current market price, and the ability to add more collateral in response to a coming liquidation event.
What’s the big deal?
To some this might seem like a series of very small and ultimately irrelevant adjustments to the original DLC specification, but these small changes take something that because of its existing shortcomings didn’t have much potential outside of retail consumer use and put it in the league of potentially being able to meet the needs of much larger economic actors and pools of capital. If the Lightning Network was a huge jump forward for transactional use of Bitcoin, I think this has the potential to be a similar jump forward for capital and financial markets’ use of Bitcoin.
Every use case of Bitcoin isn’t going to be a use case everyone else likes or has need of, and some may even have externalities they create for other use cases, but as an open system that is the reality of how Bitcoin works. Anyone can build on it. This proposal might not be a primary use case for many people reading this, but that shouldn’t lead to you ignoring the fact that it could grow to be a very big one.