A while back, Bitcoin-native decentralized finance (DeFi) was literally impossible. The Bitcoin blockchain couldn't accommodate complex financial contracts. Its simple language – optimized for security – could not encode smart contracts in single transactions.
Therefore, holders had to port Bitcoin to other blockchains every time they wanted to participate in DeFi and put them to work. To use Bitcoin on non-native chains, holders rely on custodians or crypto bridges to mint synthetic tokens, like wrapped Bitcoin (wBTC), that track the price of Bitcoin. Essentially, they lock Bitcoin on smart contracts or custodians to mint synthetic versions compatible with the non-native chains. Custodial wrapping and bridging of Bitcoin compromise the user's self-sovereignty, privacy, and security – the primary ideologies of the Bitcoin ethos.
In 2017, Thaddeus Dryja, the Bitcoin Lightning Network co-inventor, published a whitepaper on Discreet Log Contracts (DLCs). The whitepaper describes Bitcoin-native smart contracts with a small on-chain footprint compatible with the Bitcoin language. In addition, Dryja outlined that DLCs allow users to retain their private keys and financial sovereignty.
DLCs are conditional contracts or escrows between two participants. An event dictates the outcome of the DLC. That event consists of an announcement which sets up the details and potential outcomes and an attestation which identifies one of the outcomes as the official one. The Oracle's job is to build and sign the event announcement and attestation.
Since DLCs are new and complex, we want our users to understand our infrastructure before trying. Keep reading to learn more about the components of the DLC.Link.
Suppose Alice and Bob want to bet on the outcome of a football match. They have multiple ways to do it. First, they could bet off-chain. However, the winner must trust the loser to comply with the outcome. This sounds tricky since losers often need to honor agreements.
Secondly, they could bet with a 2-to-2 multi-sig. Here, Alice and Bob use a transaction to lock up the funds in escrow. The funds are unlocked with another transaction using the participants' private keys. However, this method can be more detrimental than the first one. If the loser fails to honor the agreement by not signing the transaction, the winner won't receive anything – not even their stake.
Thirdly, Alice and Bob can bet with a 2-to-3 multi-sig. In this method, they will use a transaction to lock up the winnings in escrow so that, in addition to a third party, at least one signs the transaction that unlocks the win. Alice and Bob could choose a trusted intermediary to intervene in case one doesn't cooperate. Nevertheless, the intermediary would know the bet's details by signing it. Therefore, apart from the participants losing their privacy, the third party could likely collude with one of them to spoil the bet.
Alternatively, Alice and Bob could utilize a blockchain like Ethereum, wrap their Bitcoin, and seek the help of a third party. The third-party sources data from off-chain systems about the match onto the network, acting as an automated oracle. The participants could encrypt the bet into one transaction that petitions the oracle. After the oracle provides the outcome, the contract performs the payout.
Apart from smart contracts and wrapping risks, the entire contract would be published in the Ethereum blockchain for all users. Information-dense contracts more quickly clog networks, attracting high gas fees and loss of privacy. This transactional prying is often associated with a miner-extractable value (MEV) – value that accumulates to miners who maximize their positions in the blockchain to front-run and exploit users for profit.
Perhaps Alice and Bob should leverage DLCs.
At their core, DLCs are like a 2 of 3 multisig where one of the signers is an "oracle." DLCs solve the issues highlighted above in a seamless way. They preserve user privacy, reduce users' on-chain footprint, and help prevent MEV, the value obtained from exploiting information-dense transactions. Furthermore, DLCs do not involve third parties. This sounds like magic. Doesn't it? Let's briefly discuss how DLCs work.
A simplified overview of a Bitcoin DLC.
First, instead of encoding the entire contract into one on-chain transaction, as in the case of Ethereum, DLCs spread the contract logic over multiple minor transactions – only a tiny portion appears on-chain. Secondly, the contract petitions one or more oracles to be incentivized to act honestly. This ensures the contract is not corrupted.
The oracle problem refers to the current issue of integrating off-chain data into smart contracts on the blockchain. Bitcoin transactions, which are a form of smart contracts, typically leverage limited data, including public keys, signatures, timestamps and block sizes, which is reliable as its validity is objective and trustlessly verifiable through the blockchain.
But integrating data, like the score of a football match, into a smart contract in a trustless way is yet to be practical. Currently, there are no proven methods of ensuring the data provided by either counterparty in a contract or intermediary is authentic. Some projects have tried to reduce the trusted nature of the oracle, but they have yet to succeed.
At DLC.Link, we are taking things a step further than anyone else in solving the oracle problem of decentralized systems or information theory in general. In essence, how can data be trusted? As the data powering the oracle's attestations are often from off-chain sources, this is an integral part of a DLC flow. We have designed our network of oracles to listen to events from various blockchains, therefore leveraging the trustless and decentralized nature of web3 systems.
We combine DLCs and time-proven oracle solutions like Chainlink to solve the issue of unlocking Bitcoin liquidity without the involvement of an intermediary. The DLC.Link infrastructure can serve anyone willing to use BTC as collateral to open, pay interest, or close a loan contract in a manner conforming with the Bitcoin principle of a trustless monetary system.
The components of the DLC.Link consist of the following.
The Bitcoin (DLC) Oracle (TM) plays the role of a mediator by confirming the outcome for the DLC participants. This is the main engine that powers the DLC.Link infrastructure. The Bitcoin DLC Oracle cryptographically attests to the outcome of events happening in the real world or other chains.
In the US election, DLC bet between Chris Stewart and Nicolas Dorier, the OutcomeObserver attested to who won the election. Every DLC needs an oracle. At DLC.Link, we acknowledge that the success of our infrastructure is determined by a vibrant ecosystem of a high-quality oracle attesting to outcomes of events outside the Bitcoin blockchain.
Smart contracts, from applications such as DeFi, betting, escrow, and more using DLCs, and the DLC.Link Management Contract. The smart contracts communicate between various on-chain sources, including data oracle systems, DeFi apps’ contracts, and more. DLC.Link makes smart contracts scalable and private and allows users to determine the outcome of a contract without involving a third party or trusting each other.
On-chain contracts bloat the size of the blockchain, complicating the requirements for operating a node in addition to higher fees and slow processing speeds. Besides, they are public, meaning all network users can see the interactions between parties. With DLC.Link, blockchain explorers and non-intended parties are unaware of the contract terms and transaction amounts. This way, DLC.Link succeeds in bringing private and scriptless smart contracts to the Bitcoin network.
Two participants with DLC-enabled BTC wallets are used to set up and sign the DLC event details. The parties can be users, institutions, smart contracts, or any entity with a Bitcoin address. DLC.Link works similarly to a 2-of-3 multisig wallet in that two signatures are required to execute a transaction. But unlike a wallet, DLC.Link does not track balances – so by analogy; it is more apt to describe it as a “2-of-3 multisig keychain.”
DLC.Link is building an infrastructure that offers a secure and decentralized way for smart contracts to interact with the Bitcoin blockchain without porting assets to other chains. At its core, the DLC.Link infrastructure:
Facilitates non-custodial escrow functionality: Our infrastructure enables functionalities such as lending, swapping, and betting in a trust-minimized way. The parties involved in a contract, or even a third party, can't steal or compromise it since the funds are held in decentralized vaults. This means that the collateral won't be mismanaged, like in the Celsius case.
Minimizes online attacks: DLCs act as multisig wallets where finality is achieved through an unbiased oracle network. The DLC.Link leverages oracle signatures of transactions as private keys to achieve finality and, by default, only permits the assets in the contracts to be spent.
Eliminates central points of failure: As mentioned, DLCs hold the collateral across multiple escrow accounts, preventing the creation of central points of failure. This implies there is no single vulnerability hackers can exploit or manipulate – even when one account is compromised, the other accounts can still achieve consensus.
Provides Bitcoin Base-Level Security: Since the DLC.Link is built on the Bitcoin network; applications, assets, and transactions inherit its base-level security. Throughout its 12-year history, the Bitcoin blockchain has never experienced any security breach, making it the most secure and reliable network.