Bitcoin DLC Use Cases and Implementations Compared

What Are Discreet Log Contracts?

Discreet Log Contracts (DLCs) enable two parties to execute conditional Bitcoin payments based on real-world data without revealing contract details on-chain. First proposed by Tadge Dryja of the MIT Digital Currency Initiative at Scaling Bitcoin Stanford in 2017, DLCs use Schnorr signature-based adaptor signatures to create contracts that are indistinguishable from ordinary multisig transactions to outside observers.

The core innovation is how DLCs handle oracles. Unlike traditional oracle models where the oracle actively participates in the contract, a DLC oracle simply broadcasts its attestation (a Schnorr signature over the outcome) to anyone listening. The oracle never learns that a contract depends on its data. This separation between oracle and contract is what makes DLCs "discreet": the name is a double meaning, referring to both the discrete logarithm cryptography and the privacy of the construction.

For a deeper technical breakdown of the cryptographic mechanism, including adaptor signatures, Contract Execution Transactions, and digit decomposition, see our research article on DLCs.

How DLCs Work: A Practical Summary

A DLC follows a structured lifecycle. Two parties (Alice and Bob) agree on an oracle, an event, and a payout curve. They lock funds into a 2-of-2 multisig funding transaction, then pre-sign a set of Contract Execution Transactions (CETs) covering every possible outcome. Each CET is signed with an adaptor signature that can only be completed using the oracle's future attestation for that specific outcome.

When the event occurs, the oracle publishes a Schnorr signature over the result. This signature reveals the discrete logarithm needed to unlock exactly one CET. The winning party completes the adaptor signature, broadcasts the transaction, and claims their payout. The entire process produces only two on-chain transactions (fund and settle), both of which look like ordinary Taproot spends.

Privacy guarantee: The oracle never knows a contract exists. On-chain observers cannot determine that a DLC was executed, what its terms were, or who the counterparties are. If both parties agree on the outcome, they can settle cooperatively with a single-signature key-path spend that reveals nothing about the underlying script.

DLC Use Cases in Production

DLCs have moved beyond theory into production applications across several categories. The following table compares the major use cases, their maturity, and notable projects building in each area.

Bitcoin-Backed Lending

DLC-based lending is the most commercially successful use case to date. Liquidium has processed over 102,000 non-custodial loans using DLCs, generating more than $8 million in lender interest across $450 million in borrowing volume. Users borrow BTC against Ordinals, BRC-20 tokens, and Runes as collateral. The DLC locks the collateral, and the oracle attests to repayment conditions.

Lygos Finance, formed through the acquisition of Atomic Finance's DLC technology, targets institutional bitcoin-backed lending with loan sizes from $100,000 to $100 million at 60-75% loan-to-value ratios. Atomic Finance had previously processed approximately $140 million in options vault volume using DLCs without any security incidents.

OTC Derivatives and Trading

DLC Markets, built by the LN Markets team, transitioned to Bitcoin mainnet in September 2024. The platform enables trustless OTC derivatives trading including Bitcoin futures, options, and hashrate products. Contracts settle via DLC oracles, eliminating exchange counterparty risk. DLC Markets raised $3 million in seed funding.

Self-Wrapped Bitcoin for DeFi

DLC.Link uses DLCs as a trust-minimized locking mechanism: BTC is locked in a DLC on Bitcoin L1, and a tokenized representation (iBTC) is minted on Ethereum or Arbitrum. The attestation condition is tied to events on the destination chain (such as loan repayment). This approach avoids the centralized custody models used by wBTC or other wrapped Bitcoin variants. DLC.Link integrated Chainlink CCIP and Proof of Reserve for cross-chain verification.

Prediction Markets

The first-ever DLC executed on Bitcoin mainnet was a prediction market contract: on September 8, 2020, Chris Stewart (Suredbits) and Nicolas Dorier (BTCPay Server) wagered on the outcome of the US presidential election. Ticketed DLCs, a protocol designed by Conduition, extend this to multi-player wager contracts where a market maker fronts on-chain capital and participants buy in via Lightning or Fedimint.

Parametric Insurance

DLCs are architecturally well-suited for parametric insurance, where payouts trigger automatically based on verifiable data rather than claims adjudication. The noaa-oracle project demonstrates this by providing NOAA weather data as DLC attestations. A contract could pay out automatically if a temperature threshold is breached or rainfall exceeds a defined level. This remains largely experimental, with no major standalone DLC insurance product in production yet.

DLC Implementation Comparison

Several open-source libraries implement the DLC protocol. The following table compares the most active implementations by language, features, and maturity.

The DLC specification (dlcspecs) defines the protocol messages, oracle standards, and transaction formats. It is approaching its v0 milestone, with enumerated outcome DLCs, numeric digit decomposition, and multi-oracle support largely complete. The bitcoin-s implementation serves as the reference for interoperability testing across implementations.

For developers evaluating Bitcoin Script programmability more broadly, see our Bitcoin Script programmability guide and the opcode reference.

DLC Oracle Providers

DLC oracles are fundamentally different from Ethereum-style oracle networks. A DLC oracle publishes two things: an announcement (public key, nonce, and event description) before the event, and an attestation (Schnorr signature over the outcome) after. It never interacts with any specific contract.

Several oracle implementations exist for different use cases:

• Kormir: a Rust-based DLC oracle by the dlcdevkit maintainer, also compiled to WebAssembly for browser use
• Krystal Bull: a full-featured oracle built on bitcoin-s by Suredbits, used in the first mainnet DLC
• Pythia: a Rust oracle implementation by the DLC Markets team for derivatives trading
• Ernest Oracle: built on Kormir within dlcdevkit, specializing in Bitcoin chain data (hashrate, difficulty, fee rates)
• noaa-oracle: provides NOAA weather data as DLC attestations for parametric insurance use cases
• Mycelia Signal: a sovereign oracle protocol providing price attestations over Lightning (L402), covering 11 feeds across 9 exchanges

Oracle trust is the primary security assumption in any DLC. If the oracle signs two different outcomes for the same event using the same nonce, its private key is mathematically extractable: a built-in equivocation fraud proof. Multi-oracle configurations (k-of-n threshold schemes) distribute trust across independent providers, tolerating up to n-k oracle failures.

Limitations and Tradeoffs

DLCs are a powerful primitive, but they come with constraints that developers should understand.

Oracle dependency: the oracle is a single point of failure in a basic DLC. If the oracle fails to attest, funds remain locked until a timelocked refund transaction becomes spendable. Multi-oracle schemes mitigate this but increase the number of pre-signed CETs combinatorially.

CET scalability: for numeric outcomes (like an exact BTC price), the number of CETs can grow large even with digit decomposition. Each CET must be pre-signed by both parties during setup, which is computationally expensive for high-precision contracts over wide ranges.

Counterparty discovery: DLCs require a willing counterparty. Unlike centralized exchanges with order books, DLC counterparty matching at scale remains an unsolved problem. Current solutions rely on dedicated market makers or peer-to-peer matching.

No composability: DLCs are bilateral contracts. They cannot be chained or composed like Ethereum smart contracts. Each DLC is a bespoke pre-signed transaction set between exactly two parties.

The shutdown of 10101 in November 2024 illustrates these constraints. Co-founder Philipp Hoenisch cited both lack of market traction and technical scalability limitations as reasons, noting that the self-custodial DLC model "won't scale easily to the masses."

Taproot and DLC Efficiency

The activation of Taproot and Schnorr signatures significantly improved DLC efficiency. Before Taproot, DLCs required ECDSA-based adaptor signatures with additional zero-knowledge proofs to ensure correctness. Schnorr's linearity property makes adaptor signatures simpler and provably secure under standard assumptions.

Taproot key-path spending means cooperative DLC closes appear as ordinary single-signature transactions, maximizing privacy and minimizing fees. Tapscript enables Merkleized script trees where only the exercised branch goes on-chain, reducing the footprint of complex contracts.

For more on how Taproot enables advanced Bitcoin contracts, see the Taproot use cases guide.

DLCs on Layer 2

On-chain DLCs inherit Bitcoin L1 constraints: miner fees on every funding and settlement transaction, variable confirmation times, and heavy CET pre-signing for complex contracts. Layer 2 protocols offer an alternative environment.

DLC channels, analogous to Lightning channels, allow two parties to execute multiple DLC contracts sequentially from a single funding transaction. Previous states are invalidated via revocation mechanisms similar to Lightning's. A market maker and counterparty could trade hundreds of contracts over weeks, touching the chain only twice.

Spark, as a Bitcoin Layer 2 built on statechains, enables conditional off-chain transfers with logic that can incorporate oracle attestations. This means DLC-like contract semantics without on-chain funding and settlement transactions, making small-value contracts (micro-bets, low-premium insurance) economically viable where L1 fees would otherwise be prohibitive.

Frequently Asked Questions

What is a Discreet Log Contract in Bitcoin?

A Discreet Log Contract (DLC) is a Bitcoin-native protocol that enables two parties to make conditional payments based on real-world events without revealing contract details on-chain. The contract settles when an oracle publishes a cryptographic attestation over the event outcome. To blockchain observers, a DLC looks like an ordinary multisig transaction. DLCs were proposed by Tadge Dryja (MIT Digital Currency Initiative) and work with today's Bitcoin: no consensus changes are required.

How do DLC oracles differ from Chainlink or Ethereum oracles?

DLC oracles are fundamentally different from push-based oracle networks like Chainlink. An Ethereum oracle pushes data to a smart contract on-chain, where other contracts read it. A DLC oracle simply broadcasts a Schnorr signature over the outcome. It never interacts with any contract and never learns that anyone depends on its attestation. This isolation reduces bribery and collusion risk because the oracle cannot target specific contracts. Multiple DLCs can depend on the same oracle attestation simultaneously.

Can DLCs be used for prediction markets on Bitcoin?

Yes. Prediction markets are one of the original DLC use cases. The first mainnet DLC (September 2020) was an election prediction bet between Chris Stewart and Nicolas Dorier. Any event an oracle can attest to: sports outcomes, election results, price levels, weather data: can serve as the basis for a DLC prediction market. Ticketed DLCs extend this to multi-player wager contracts where participants buy in through Lightning. The main bottleneck is oracle availability for diverse event types.

What happened to 10101 and Atomic Finance?

10101 (formerly ItchySats), a self-custodial trading app using DLCs embedded in Lightning channels, wound down operations by November 3, 2024. The team cited insufficient traction and technical scalability limitations. Atomic Finance, which built DLC-powered options vaults processing approximately $140 million in volume, was acquired by Lygos Finance. Atomic's consumer app was sunset, and its DLC technology was integrated into Lygos's institutional bitcoin lending product.

Are Discreet Log Contracts secure?

DLCs have strong cryptographic foundations and require no modifications to Bitcoin's consensus rules. The primary trust assumption is the oracle: if the oracle lies or fails, the contract may not settle correctly (though timelocked refund transactions prevent permanent fund loss). Multi-oracle threshold schemes (k-of-n) reduce single-oracle risk. Equivocation fraud proofs are built in: if an oracle signs two different outcomes with the same nonce, its private key is mathematically extractable. Liquidium has processed over 102,000 DLC loans with $450 million in volume without reported security incidents.

What is the difference between DLCs and HTLCs?

HTLCs (Hash Time-Locked Contracts) condition payments on revealing a hash preimage, making them useful for atomic swaps and Lightning routing but limited to cryptographic conditions. DLCs condition payments on oracle attestations, enabling contracts tied to any real-world event. DLCs also offer stronger privacy: on-chain, they look like ordinary multisig transactions, while HTLC scripts are visible. Both share the adaptor signature foundation with PTLCs, which extend Lightning with similar point-based constructions.

What programming languages can I use to build DLC applications?

The most actively maintained DLC libraries are in Rust (rust-dlc and dlcdevkit) and Scala (bitcoin-s). dlcdevkit provides JavaScript and React Native bindings for frontend integration. Additional implementations exist in C++ (cfd-dlc), .NET (NDLC), TypeScript (dlc-btc-lib), Go, and Elixir, though these vary in maturity. For PSBT-based transaction construction, which DLCs rely on heavily, see the PSBT workflow guide.

This guide is for informational purposes only and does not constitute financial advice. DLC projects, implementations, and oracle services are evolving rapidly. Always verify current project status, review source code, and understand the risks before using any DLC protocol. Data is based on publicly available information and may not reflect the latest developments.