Discreet Log Contract (DLC)

What Is a Discreet Log Contract?

A Discreet Log Contract (DLC) is a type of Bitcoin smart contract where two parties agree to exchange bitcoin based on the outcome of a real-world event. An external oracle determines the outcome by publishing a cryptographic signature, and this signature automatically settles the contract: the winning party can claim their payout without any further cooperation from the other party or the oracle.

The name is a deliberate double pun coined by Tadge Dryja, who introduced the concept at Scaling Bitcoin 2017. "Discrete" refers to the discrete logarithm problem that provides cryptographic security, while "discreet" refers to the privacy property: DLC transactions are indistinguishable from ordinary Bitcoin transactions on-chain. No observer can tell that a contract exists, what its terms are, or which oracle was used.

DLCs represent a fundamentally different approach to smart contracts on Bitcoin. Rather than encoding contract logic into Bitcoin Script or moving funds to a separate chain, DLCs use pre-signed transactions and adaptor signatures to achieve programmable payouts while preserving Bitcoin's simplicity and privacy.

How It Works

A DLC involves three roles: two contracting parties (Alice and Bob) and an oracle. The oracle's only job is to attest to a real-world fact. It never sees the contract, never knows the parties, and never touches the funds.

1. The oracle announces an upcoming event it will attest to (for example, "BTC/USD price on June 30"). It publishes its public key and a one-time nonce commitment R for that event.
2. Alice and Bob agree on the contract terms: how funds should be distributed for each possible outcome. They each deposit Bitcoin into a 2-of-2 multisig funding transaction.
3. For every possible outcome, they pre-build a Contract Execution Transaction (CET) that distributes the locked funds accordingly. A binary bet has two CETs; a price contract may have hundreds.
4. Instead of fully signing the CETs, the parties exchange adaptor signatures: cryptographically "encrypted" signatures that can only be completed using the oracle's future attestation for the corresponding outcome.
5. After the event occurs, the oracle publishes its Schnorr signature over the actual outcome. This signature serves as the decryption key.
6. The winning party uses the oracle's signature to complete the adaptor signature on the correct CET, turning it into a valid on-chain transaction. They broadcast the CET and claim their payout.

A time-locked refund transaction is also pre-signed as a safety net. If the oracle fails to attest (goes offline or malfunctions), both parties can recover their funds after the timelock expires.

The Adaptor Signature Trick

The cryptographic core of DLCs is the adaptor signature, which relies on a key property of Schnorr signatures on the secp256k1 curve. Given the oracle's public key A and its pre-committed nonce point R, anyone can compute the value s*G (the public key corresponding to the signature scalar s) for any possible message m, even before the oracle signs. This computed point becomes the adaptor point for that outcome.

// Schnorr signature verification equation
// s*G = R - H(m, R) * A
//
// Given: A (oracle pubkey), R (nonce commitment), m (outcome message)
// Anyone can compute: adaptor_point = R - H(m, R) * A
// But only the oracle knows: s (the scalar, revealed by signing)
//
// The adaptor signature is "locked" by the adaptor point.
// The oracle's signature scalar "unlocks" it into a valid signature.

Contract parties use adaptor points to create "encrypted" signatures on CETs. These encrypted signatures are verifiably correct commitments, but they cannot produce a valid on-chain transaction without the corresponding scalar from the oracle. When the oracle publishes its signature for the actual outcome, that scalar completes exactly one CET's adaptor signature, enabling settlement.

This design provides a strong anti-equivocation property: if an oracle signs two different outcomes for the same event (using the same nonce R), the two signatures mathematically reveal the oracle's private key. This makes double-signing detectable and catastrophically costly for the oracle.

What the Oracle Sees

Unlike 2-of-3 multisig escrow schemes where the arbitrator sees the contract and can collude with a party, a DLC oracle is completely blind to the contract. The oracle simply announces events and publishes attestations about real-world facts. It never knows whether anyone has built a contract around its attestations, who the parties are, or how much money is at stake. This separation of concerns is what makes DLCs "discreet."

Use Cases

Financial Derivatives

DLCs enable non-custodial futures, options, and contracts-for-difference on Bitcoin. Two parties can take opposing positions on an asset price, and the contract settles automatically when the oracle attests to the price at expiry. DLC Markets launched on Bitcoin mainnet in September 2024 for institutional OTC derivatives trading using this approach.

Prediction Markets

Binary and multi-outcome bets on elections, sports, weather, or any event an oracle can attest to. The first mainnet DLC, executed on September 8, 2020, was a bet on the U.S. Presidential Election between Suredbits founder Chris Stewart and Nicolas Dorier.

Bitcoin-Collateralized Lending

DLCs can serve as escrow for lending protocols. Borrowers lock Bitcoin into a DLC, and if the collateral value drops below a threshold (as attested by a price oracle), the lender can claim the collateral. Liquidium uses DLCs for peer-to-peer lending against Ordinals, Runes, and BRC-20 tokens on Bitcoin Layer 1.

Trust-Minimized Bitcoin Bridges

DLCs can anchor Bitcoin for use on other chains. DLC.Link uses this approach to let users lock BTC into a DLC and mint a wrapped Bitcoin token usable in DeFi on Ethereum and Arbitrum, providing a non-custodial alternative to centralized wrapped Bitcoin tokens.

Parametric Insurance

Insurance contracts that pay out automatically based on oracle-attested data. For example, a crop insurance contract could settle based on rainfall measurements: if rainfall drops below a threshold, the insured party automatically receives compensation without filing a claim.

DLCs and Taproot

Taproot (activated on Bitcoin in November 2021) significantly improves DLCs in several ways. BIP 340 activates native Schnorr signature support, which DLCs were originally designed to use. Before Taproot, developers had to create a more complex ECDSA-compatible adaptor signature variant with additional cryptographic proofs.

With BIP 341, DLC funding outputs and cooperative settlements use key-path spending, making them indistinguishable from single-signature P2TR transactions. An on-chain observer cannot tell whether a transaction is a simple payment, a Lightning channel close, or a DLC settlement. Schnorr key aggregation (via MuSig2) allows the 2-of-2 multisig to be represented as a single aggregated public key, reducing transaction size and fees.

Taproot also enables PTLCs (Point Time-Locked Contracts), which use adaptor signatures instead of hash-based HTLCs. This infrastructure benefits DLCs integrated with Lightning Network channels, enabling off-chain DLC settlement with smaller, cheaper, and more private transactions. For a deeper look at these cryptographic building blocks, see the Taproot and Schnorr signatures deep dive.

Why It Matters

DLCs are one of the foundational technologies for BTCfi: the effort to bring decentralized finance to Bitcoin without relying on other blockchains or custodians. They enable derivatives, lending, insurance, and synthetic assets directly on Bitcoin Layer 1, using Bitcoin's own UTXO model and self-custody guarantees.

Unlike Ethereum-style smart contracts that require a shared execution environment, DLCs are bilateral agreements settled with pre-signed transactions. This makes them inherently private and lightweight, but also means they lack the composability of account-based DeFi. More complex BTCfi applications often combine DLCs with other Bitcoin primitives like PSBTs, Lightning channels, and multisig escrow. For a broader view of the Bitcoin DeFi landscape, see the BTCfi landscape overview and the DLC research deep dive.

Risks and Considerations

Oracle Trust

DLCs reduce but do not eliminate oracle trust. A malicious or compromised oracle can sign a false outcome, directing funds to the wrong party. While equivocation (signing two different outcomes with the same nonce) is cryptographically detectable and exposes the oracle's private key, the oracle could still collude with one party by simply signing the wrong outcome once. Multi-oracle schemes mitigate this by requiring agreement from multiple independent oracles, at the cost of increased CET count and complexity.

CET Scalability

For contracts with many possible outcomes (a price that could land on thousands of values), the number of pre-signed CETs can be very large. Numeric outcome decomposition (where the oracle signs individual digits separately) and CET compression (grouping constant-payout ranges into logarithmic prefix patterns) reduce this burden, but the computational cost of generating and exchanging adaptor signatures remains significant.

Liquidity Lock

Funds locked in a DLC cannot be used for anything else during the contract period. There is no native mechanism for early exit without cooperative settlement between both parties. For long-duration contracts, this represents a meaningful opportunity cost.

Implementation Maturity

The DLC ecosystem is still evolving. The community-maintained dlcspecs specification remains a work-in-progress with no finalized v1 release. Several pioneering DLC projects have shut down or pivoted, citing challenges with UX complexity and market preference for custodial alternatives. While institutional-focused platforms like DLC Markets represent a maturing ecosystem, DLCs have not yet seen the broad adoption that would come from extensive battle-testing.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.