Secret ledger contracts are an old concept in the industry at this point, and were proposed by Thaddeus Dryja (co-founder of the Accelerator Network Protocol) in 2017. The DLC is a smart contract structure designed to address three issues with contract schemes prior to the proposal: First, the scalability of the smart contract itself, which requires larger on-chain traces for a wider range of possible outcomes; Second, the issue of inputting external data into the blockchain “to the blockchain” to settle contracts; Finally, the privacy of smart contract users.
The basic scheme is very simple, where two parties create a multi-signature address consisting of the two, choosing an oracle. After doing this, they create a set of contract execution transactions that interact with the oracle. Suppose the oracle announces the price of Bitcoin, and the participants are betting on the price of Bitcoin. What the oracle does is publishes a set of commits to the messages that it will sign in order to “announce” the price of Bitcoin at a certain price. time. CETs are created such that the signature on each CET provided by one participant to another is encrypted using switch signatures. Each signature to settle a contract at any specific price can only be decoded with information from the signed oracle message proving that specific price. The oracle simply publishes its message commitments for any data it serves as an oracle for, and any participant can use this information non-interactively to create downloadable content (DLC). The last part is a time-bound refund transaction, if the Oracle never broadcasts the information needed to settle the DLC, after a period of time extending beyond the life of the contract has elapsed, both parties are simply refunded.
This solves the three main problems identified by Tadge (Thaddeus) in the original DLC white paper: It is scalable, only needing one transaction to fund the contract and one transaction to settle it; It provides a way to “bring” external data into the blockchain; It solves the privacy problem, as the way the oracle blindly broadcasts data to the public does not gain any insight into who is using it as the oracle in the contract. You can also use a union of several fortune tellers, where if the value they attest to is close enough to each other, the contract will be settled correctly. The last important thing to note with DLC is that oracles lying to incorrectly settle contracts is a very different model than the traditional multi-escrow model. In the escrow model, Oracle can choose to selectively harm a single user by signing an inappropriate settlement. There is potential to mitigate reputational damage there, but in the DLC model Oracle can't do that. When they sign a message, it is used to settle every DLC connected to that settlement message and time, and there is no way to selectively act maliciously toward one party because they don't know who is using it.
The only real flaw in this scheme, besides the inevitable trust in the oracle, is the issue of coordination. Depending on the nature of the contract, for example, a bet on the price of Bitcoin versus a bet on a sports game (Team X wins or Team Y wins), there can be either a handful of CETs or a huge pool of CETs to cover all possible outcomes. This opens up two problems: first, if the transaction pool is large enough, it creates the potential for network issues and denial of service (DoS) attacks, causing people to waste time by not completing contract setup; Second, there is the possibility of a free option issue that may require an on-chain transaction to deal with. A free option would be a problem if the contract was prepared and finalized, but the party who ended up signing full financing did not communicate it. This would allow them to only fund on-chain DLC if it is in their best interest and not otherwise, and the only way for the other party to escape this situation is to double-spend their funding output on-chain.
DLC Markets
LN Markets recently published an article describing a new DLC specification it designed to tailor the DLC mechanism towards institutional actors. The current crop of DLCs are geared more toward retail consumers, leaving room to tweak the design to meet the needs of larger enterprise players.
Some of the issues for institutional clients are: the problem of free choices, which is unacceptable in this type of environment; The second is no margin calls, i.e. either the position is closed if one party does not have enough margin capital to cover their side of the trade at the current price, or that party adds the additional margin required to keep it open; Finally, the ability to use capital more efficiently rather than keeping capital in one locked position from the beginning of the contract until the end.
To address all these issues, LN Markets introduced the concept of a Downloadable Content (DLC) Curator. Instead of contract peers directly coordinating each other to handle financing and negotiate the contract, a coordinator can sit in the middle and help facilitate this. This solves the free options problem rather elegantly, by having the coordinator facilitate the contract negotiations. Instead of each counterpart directly interacting with each other to sign off on contract execution and financing transactions, they submit their signatures on it all to the coordinator. At no time will any of the participants have access to the signatures needed to fund the contract, removing a person's ability to obtain a free option. Only the coordinator will have both signatures, and to address the issue of them colluding with one of the participants or being malicious and not submitting the financing transaction for some other reason, the financing transaction involves paying them a fee to act as coordinator. This gives them a direct incentive to submit a financing transaction after the DLC has been negotiated and signed.
Another huge efficiency is the coordination process of building the DLC in the first place. Without the participation of the coordinator, participants will have to communicate with each other, exchange addresses and UTXO information, and then coordinate the preparation of the DLC. With the Coordinator, users can simply register xpub and some UTXOs with the Coordinator, as well as their offers to the terms of the contract. When someone accepts an existing offer, the coordinator has all the information necessary to create CETs, and then can simply submit them to the person accepting the offer for verification and signature, and then send the signatures to the coordinator. The original bidder will then receive CETs to verify, sign and return once they come online and decide to accept the counterparty, sending them back to the coordinator who can then merge the signatures and send the financing transaction.
Liquidation
Involving a coordinator also provides a reliable point of contact for adding the final missing piece of DLC applied in a professional environment: filters and handling of adding additional margin.
There was a nice chart from the white paper included in the article written by LN Markets announcing the proposal, but I feel this is much easier to understand. In addition to all the CETs attached to Oracle messages for price announcements that can occur upon contract expiration, there are also special settlement transactions for periods preceding the actual contract expiration – the interval for which participants can specify in line with the frequency at which Oracle publishes price messages. Each party has one special CET for each of these “liquidation times”, where if the price is outside the scope of the contract (i.e. all the money is owed to one side) at any of those liquidation points, they can simply submit that transaction and settle the contract earlier.
If one party is ever close to liquidation time, they can use an orchestrator to coordinate adding margin to the contract, allowing the other party to realize some of their gains by withdrawing funds from the contract. This will involve both parties collaboratively spending multiple funds on new DLC which will receive more money from the under-collateralized party and allow the “winning” party to withdraw some of the money. The new DLC will be set to the same expiration time and with the same filter points as those set before.
This dynamic brings capabilities more in line with what institutional investors expect; The ability to manage liquidity more effectively, terminate the contract early if one party is short on collateral based on the current market price, and the ability to add more collateral in response to an upcoming liquidation event.
What is the big deal?
To some this may seem like a series of very small and ultimately irrelevant tweaks to the specs of the original DLC, but these small changes take something that due to its current flaws didn't have much potential outside of retail consumer use and put it in the league of potential Being able to meet the needs of much larger economic actors and capital groups. If the accelerator network is a big leap forward in the use of Bitcoin in transactions, I believe this has the potential to be a similar leap forward in the capital markets and financial markets' use of Bitcoin.
Not every use case for Bitcoin will be a use case that everyone likes or needs, and some may also have externalities that they create for other use cases, but as an open system it represents the reality of how Bitcoin works. Anyone can build on it. This suggestion may not be a primary use case for many people reading this, but that shouldn't lead us to ignore the fact that it can get pretty big.
