4 Ways DLC.Link’s Bitcoin Attestors Enable Finance on Bitcoin

Bitcoin is the most successful asset in the history of mankind. However, its functionality is largely restricted to storing value (by holding it in a wallet) or payments (by sending it to another party). Without an expressive smart contract layer, it has not been possible to build more advanced logic into the Bitcoin chain itself. 

Meanwhile, other chains such as Ethereum have solved for smart contracts but use a consensus mechanism that isn’t nearly as safe as Bitcoin’s. Ethereum and other chains use validator networks that are more centralized, geographically and otherwise, than Bitcoin’s decentralized miners and mining pools. The Ethereum Foundation requires its validators to adopt mandatory version upgrades and makes decisions in a centralized manner. When these policy decisions are wise, they speed up progress. But they introduce the traditional risks of central planning: censorship, mistakes and political bias.

As a result, Bitcoin remains the largest and most widely-adopted cryptocurrency. However, its limited programmability has had an undesirable side effect: reliance on custodians. In order to use Bitcoin in a complex transaction such as that of taking a loan, the Bitcoin must first be sent to a third-party custodian. The custodian locks the Bitcoin in their vault and issues a token or a receipt that can be used to borrow against. This negates the decentralized benefit of Bitcoin, and cedes all control to the custodian in question. Web3 has a very challenging history with custodians, as over $100Bn has been lost to date due to custodial bad behavior or hacks.

The solution is to build a self-custodied Bitcoin that can be used elsewhere. Enter Discreet Log Contracts which promise exactly that.

What are DLCs?

Discreet Log Contracts or DLCs were invented by Tadge Dryja, the co-creator of the Lightning Network. They are special multisigs that enable conditional payments with Bitcoin. When two parties enter into a DLC, a third-party Bitcoin Attestor generates all potential conditional outcomes, which the users pre-sign (pre-approve) in their respective wallets. 

Later, when the outcome is known, the Bitcoin Attestor attests to the correct signature, which allows the parties to execute that transaction. This simple if-then logic is simple enough to maintain the decentralization and safety benefits of Bitcoin while being powerful enough to support advanced behavior such as that of powering a loan. Throughout the transaction, the Bitcoin stays in its native, decentralized state and does not need to be moved to any custodians or third-parties.

What are DLC Bitcoin Attestors? 

Oracles are off-chain services that bring real-world data to the blockchain. Bitcoin Attestors allow for the communication of data between the Bitcoin ledger and other systems, such as smart contract systems on other chains, to enable programmatic payments.

The Bitcoin Attestor itself is a service that opens DLCs and attests to them when the outcome is known. DLC.Link has developed infrastructure that offers a secure and decentralized way for smart contracts to interact with the Bitcoin blockchain using this approach. In DLC.Link’s platform, Bitcoin Attestors receive instructions from smart contract logic. These smart contracts can live on any chain and can take real-world data from data feed oracles such as those provided by Chainlink or Pyth.

4 Ways DLC.Link Enables Bitcoin DeFi

DLC.Link designed a decentralized network of attestors that listen to events from numerous other blockchains which leverages the trustless and decentralized nature of the greater blockchain ecosystem. As a result, DLC.Link creates a solution for trustless Bitcoin DeFi in four ways:

1. Facilitates Non-Custodial Escrow Functionality 

The parties involved in a contract, including any third party, cannot steal nor compromise the contract since the funds are held in decentralized vaults. This restriction prevents the mismanagement of the underlying BTC collateral. Practically speaking the BTC collateral is held in an escrow wallet.

2. Minimizes Online Attacks

Vulnerabilities in bridges have led to exploits that have cost the industry hundreds of $Billions. Discreet Log Contracts present a promising alternative. Unlike custodial approaches, DLCs hold collateral in decentralized “escrows” without introducing a central point of failure. Bitcoin is kept on-chain throughout.

Furthermore, at DLC creation, the two participants’ addresses are locked in and cannot be changed. There is no opportunity for a third-party hacker to alter an address and redirect funds to their wallet. If the Bitcoin Attestor is hacked and an incorrect outcome is transmitted, the Bitcoin can only go to one of the original participants. If any deposit tokens are minted using a DLC, by design, the existence of the token provides a cryptographic guarantee that real Bitcoin is locked in an escrow.

3. Eliminates Counterparty Risk

Due to interoperability limitations, smart contract applications integrating Bitcoin today need to introduce an intermediary that can hold the funds. Generally the Bitcoin is either sent to a custodian directly and locked in their vaults or is sent to a bridge secured by smart contracts. Either solution introduces various forms of counterparty risk, including black box risks (risks associated with trusting an external system), regulatory and censorship risks (potential loss of funds stemming from having to comply with a custodian’s regulatory requirements) as well as the risk of human error, fraud or negligence. In contrast, bridges pool funds in centralized locations, which reduces the possibility of fraud but adds significant risk of losses due to hacks. Since much of Bitcoin’s inherent value stems from its decentralization and censorship resistance, these options are all generally seen as problematic.

In contrast, DLCs hold the BTC collateral in decentralized “escrow accounts”, implemented as multisig unspent transaction outputs (UTXOs) on Bitcoin chain. This removes the need for intermediaries and shifts the risk to code that can be readily inspected on-chain.

4. Provides Bitcoin Base-Level Security

Since DLC.Link is built on Bitcoin, all applications, assets, and transactions inherit Bitcoin’s base-level security. The funds escrowed into a DLC are in fact UTXOs that live directly on Bitcoin’s ledger. This means that collateral held through DLC.Link’s platform is still controlled no differently than regular Bitcoin balances are controlled within a wallet such as Xverse. Essentially, the transactions which move the collateral are 100% secured by Bitcoin’s base-level network of mainnet nodes and miners.

DLCs Provide a Safe Way for Bitcoin to be Used on Other Chains

Without access to financing, Bitcoin’s growth will be limited. Various intriguing technologies have been proposed, such as Taro on Lightning, that may one day provide other safe avenues of using Bitcoin. But until those are developed, DLCs remain the only way to keep Bitcoin on-chain while enabling it in financial applications.

Xverse wallet is the first production wallet to integrate DLC.link’s signing technology. Going forward, Xverse can be used in applications on any blockchain that can support DLC functionality. We’re excited about the next chapter in Bitcoin’s evolution as a safe, censorship-resistant asset that can now be used in advanced financial applications.

Read more about DLC.link here: https://docs.dlc.link

Author: 

Aki Balogh is an entrepreneur who builds decentralized technologies that empower society. He's currently the Co-founder & CEO of DLC.link, a Web3 company that provides infrastructure that lets apps on any blockchain accept native Bitcoin. He's also Co-founder & President at MarketMuse, an AI-based content optimization platform. Aki also advises Dakai.io, a Web3 software development firm. He holds two patents around the use of topic modeling for search.

Join us as we enable a Trillion dollars of Bitcoin capital to be used in smart contracts. Contact us:

url = getTweetURL(text, settings.extra, settings.via); $(settings.node).addClass(settings.cssClass