Discreet Log Contracts: Bitcoin-Native Derivatives and Oracles

Bitcoin's scripting language is intentionally constrained. It can verify signatures, enforce timelocks, and check hash preimages, but it cannot fetch external data. It has no concept of asset prices, sports scores, or election outcomes. This creates a fundamental obstacle for anyone trying to build derivatives, insurance contracts, or prediction markets on Bitcoin: the oracle problem.

Discreet Log Contracts (DLCs), first proposed by Tadge Dryja of the MIT Digital Currency Initiative in a 2018 paper, offer an elegant solution. DLCs enable two parties to enter into a conditional Bitcoin contract that settles based on real-world data, without revealing any contract details on-chain. To the blockchain, a DLC looks like an ordinary 2-of-2 multisig transaction. The oracle that attests to the outcome never learns that a contract depends on its attestation.

The Oracle Problem on Bitcoin

Smart contract platforms like Ethereum solve oracle integration by allowing contracts to read from on-chain data feeds. Chainlink nodes post prices to a contract, and other contracts read those values. Bitcoin has no such mechanism. Bitcoin Script is a stack-based language that intentionally lacks loops, state, and external data access.

Earlier approaches to Bitcoin oracles required the oracle to actively participate in the contract. A 2-of-3 multisig with both parties and an oracle could work: the oracle signs with whichever party it determines should win. But this approach has significant problems:

• The oracle knows a contract exists and understands the stakes involved
• The oracle can be bribed, coerced, or compromised since it knows who benefits from each outcome
• Every contract requires a unique oracle interaction, creating scalability bottlenecks
• Contract details are visible on-chain through the multisig structure

DLCs solve all of these problems by using a cryptographic construction called adaptor signatures, built on the properties of Schnorr signatures.

Why "discreet"? The name is a double meaning. DLCs use discrete logarithm cryptography (the mathematical foundation of elliptic curve signatures). They are also discreet in the everyday sense: the oracle does not know a contract exists, and observers cannot distinguish a DLC from a regular multisig transaction on-chain.

Adaptor Signatures: The Core Mechanism

The cryptographic foundation of DLCs is the adaptor signature (sometimes called a signature adaptor or pre-signature). An adaptor signature is an incomplete Schnorr signature that can only be completed when a specific secret value is revealed. In the context of DLCs, that secret value is derived from the oracle's future attestation.

Here is the high-level construction. Suppose Alice and Bob want to bet on whether BTC will be above $100,000 at the end of the month. They agree on an oracle that publishes a Schnorr signature over the outcome. The oracle announces ahead of time: "I will sign the message 'above' or 'below' using nonce R."

Before the event, Alice and Bob can compute what the oracle's signature point will be for each outcome. From the oracle's public key and announced nonce, they derive anticipated signature points: S_above and S_below. These points are public, deterministic, and available before the oracle ever signs anything.

Building the Contract Execution Transactions

Alice and Bob lock funds into a 2-of-2 multisig funding transaction. They then pre-sign a set of Contract Execution Transactions (CETs), one for each possible outcome. Each CET distributes the locked funds according to the agreed-upon payout for that outcome.

The key innovation: each CET is signed with an adaptor signature that incorporates the anticipated oracle signature point for the corresponding outcome. Without the oracle's actual signature, neither party can complete any CET. Once the oracle publishes its attestation for the real outcome, exactly one CET becomes completable.

To make this concrete with the BTC price bet:

1. Alice and Bob each deposit 1 BTC into a 2-of-2 multisig (the funding transaction)
2. They create CET_above: sends 2 BTC to Alice (she wins if price is above)
3. They create CET_below: sends 2 BTC to Bob (he wins if price is below)
4. CET_above is signed with adaptor signatures using S_above
5. CET_below is signed with adaptor signatures using S_below
6. The oracle publishes its attestation for "above", revealing the discrete log of S_above
7. Alice uses the oracle's signature to complete CET_above and broadcast it

Privacy guarantee: The oracle never learns that Alice and Bob have a contract. It simply publishes its attestation for all subscribers. The funding transaction on-chain is indistinguishable from any other 2-of-2 Taproot output. No observer can determine that a DLC existed, what its terms were, or who the counterparties are.

Oracle Attestation in Detail

DLC oracles operate differently from traditional blockchain oracles. They do not push data to a contract or interact with any specific users. An oracle's role is limited to two actions:

1. Announcement: before the event, the oracle publishes its public key, a nonce point (R), and a description of the event and possible outcomes
2. Attestation: after the event, the oracle publishes a Schnorr signature over the outcome using the pre-committed nonce

The oracle model in DLCs has a crucial property: the oracle's attestation is a general-purpose broadcast. It does not target any specific contract. Thousands of contracts can depend on the same oracle attestation, and the oracle is unaware of all of them. This is what makes DLC oracles fundamentally different from the 2-of-3 multisig approach: the oracle cannot selectively cheat because it does not know who depends on its data.

Numeric Outcomes and Digit Decomposition

A binary outcome (above/below) only requires two CETs. But what about continuous values like "the exact BTC price at settlement"? If the price could be anywhere from $0 to $200,000, creating a CET for every dollar value would require 200,000 transactions: clearly impractical.

The DLC specification addresses this through digit decomposition. Instead of signing a single message for each possible outcome, the oracle signs individual digits. For a price expressed in 6 decimal digits, the oracle commits to 6 nonce points and signs 6 individual digits (0 through 9 each). The number of oracle signatures grows linearly with the number of digits rather than exponentially with the range of outcomes.

The number of CETs also becomes manageable through interval grouping. Rather than creating a CET for each dollar, the contract can define payout intervals: "if the price is between $90,000 and $95,000, Alice gets 1.5 BTC and Bob gets 0.5 BTC." This reduces the CET count to a practical number while preserving fine-grained payout curves.

DLC Lifecycle: Step by Step

A complete DLC follows a structured lifecycle from negotiation to settlement.

The total on-chain footprint is two transactions: one to fund, one to settle. Both appear as ordinary Bitcoin transactions. A cooperative close (where both parties agree on the payout without waiting for the oracle) is even more efficient, as it avoids the CET structure entirely.

Multi-Oracle and Threshold Schemes

Relying on a single oracle introduces a single point of failure. If the oracle goes offline, the contract cannot settle. If the oracle is compromised, it could attest to a false outcome. The DLC specification addresses this with multi-oracle configurations.

k-of-n Oracle Schemes

In a threshold oracle setup, a contract specifies n oracles and requires k attestations to agree before settlement. For example, a 2-of-3 oracle scheme might use three independent price feeds. The contract settles based on any two oracles that agree on the outcome.

Implementation uses combinatorial CET generation. For a 2-of-3 scheme with oracles A, B, and C, the contract creates CETs for each possible agreeing pair: (A,B), (A,C), and (B,C). Each CET requires adaptor signatures incorporating both oracles' anticipated signature points.

Median-Based Settlement

For numeric outcomes, a common approach is to settle on the median value across multiple oracles. This eliminates outliers automatically: even if one oracle reports a wildly incorrect value, the median remains unaffected as long as a majority of oracles are honest. This is directly analogous to the oracle manipulation defenses used in DeFi price feeds.

DLC Channels: Reusable Contracts

Standard DLCs require a new funding transaction for every contract. DLC channels, analogous to Lightning payment channels, allow two parties to open a long-lived channel and execute multiple DLC contracts sequentially without additional on-chain transactions.

The construction works similarly to Lightning's commitment transaction model. Each new contract produces a new set of CETs that spend from the channel's funding output. Previous contract states are invalidated using revocation mechanisms comparable to Lightning's revocation keys. If a party attempts to settle using an old, revoked contract state, the counterparty can claim all channel funds as a penalty (a justice transaction).

DLC channels dramatically reduce on-chain costs for parties who trade frequently. A market maker and a regular counterparty could open a single channel and execute hundreds of contracts over weeks or months, only touching the chain twice: once to open, once to close.

Taproot and DLC Efficiency

The activation of Taproot and Schnorr signatures on Bitcoin significantly improved DLC efficiency. Before Taproot, DLC funding transactions used P2WSH (Pay-to-Witness-Script-Hash) outputs that exposed the 2-of-2 multisig structure when spent. With Taproot, the funding output is a single public key that reveals nothing about the underlying script.

Schnorr signatures also enable key aggregation through protocols like MuSig2. Instead of requiring two separate signatures in the settlement transaction, the two parties can produce a single aggregated signature. This reduces transaction weight and fees while further improving privacy: the settlement transaction is indistinguishable from a single-signature spend.

Additionally, Schnorr's linearity property is what makes adaptor signatures possible in the first place. ECDSA-based adaptor signatures (used before Taproot) were more complex and required zero-knowledge proofs to ensure correctness. Schnorr adaptor signatures are simpler and provably secure under standard assumptions.

Current Platforms and Use Cases

Several projects are building DLC infrastructure and applications today.

Platforms

Arcane Finance built one of the first implementations of DLC channels, enabling non-custodial Bitcoin derivatives. Their protocol allows users to enter leveraged long and short positions on BTC/USD using DLCs settled by oracles.

P2P Derivatives developed an open-source DLC implementation focused on peer-to-peer financial contracts. Their work contributed significantly to the DLC specification, which defines message formats, protocol flows, and oracle standards.

DLC.Link focuses on bridging DLCs to other ecosystems, enabling Bitcoin-collateralized DeFi positions. Their approach uses DLCs as a trust-minimized locking mechanism: Bitcoin is locked in a DLC on-chain, and the attestation condition is tied to events on another chain (like loan repayment on Ethereum).

Use Cases in Production

• Leveraged trading: non-custodial long/short BTC positions without exchange counterparty risk
• Bitcoin-collateralized loans: lock BTC in a DLC, borrow stablecoins, and the oracle attests to liquidation conditions
• Insurance: parametric insurance contracts where the oracle attests to weather data, flight delays, or other verifiable events
• Prediction markets: binary or scalar bets on any event an oracle can attest to
• Options contracts: call and put options on BTC/USD with DLC-based settlement

Limitations and Open Challenges

DLCs are not without limitations. Understanding these tradeoffs is important for developers evaluating the technology.

CET Scalability

Even with digit decomposition, complex contracts with many outcome intervals can require thousands of CETs. Each CET must be pre-signed by both parties during contract setup. For contracts with high precision over large ranges, this setup phase can be computationally expensive and bandwidth-intensive.

Oracle Availability

If all specified oracles fail to attest, a DLC cannot settle through the normal path. Contracts typically include a refund transaction with a timelock that returns funds to both parties after a specified period. This prevents permanent fund lockup but means the contract effectively expires without resolution.

Counterparty Discovery

DLCs require finding a counterparty willing to take the other side of a contract. Unlike centralized exchanges where an order book matches buyers and sellers, DLC counterparty discovery remains an unsolved problem at scale. Current solutions rely on dedicated market makers or peer-to-peer matching services.

Free Option Problem

Between contract negotiation and funding transaction confirmation, either party can walk away without penalty. If the BTC price moves significantly during this window, the disadvantaged party has an incentive to abandon the contract. Solutions include requiring collateral deposits or using zero-confirmation funding with SegWit transaction malleability protections.

DLCs vs. Other Bitcoin Contract Approaches

DLCs are not the only way to build conditional contracts on Bitcoin. Other approaches offer different tradeoff profiles.

DLCs occupy a unique position: they achieve strong privacy and minimize oracle trust without requiring any changes to Bitcoin's consensus rules. Everything works with today's Bitcoin, using only Schnorr signatures and standard transaction types enabled by Taproot.

Relationship to PTLCs and Lightning

DLCs share cryptographic foundations with Point Time-Locked Contracts (PTLCs). Both use adaptor signatures to conditionally complete transactions based on the revelation of a secret scalar. In PTLCs, the secret is a payment preimage passed along a routing path. In DLCs, the secret is derived from an oracle attestation.

This overlap means DLCs can be integrated into Lightning-like payment channels. A Lightning node could offer DLC-based derivatives directly within a channel, settling them alongside regular payments. The hodl invoice pattern already demonstrates conditional payment holds in Lightning; DLCs extend this concept to arbitrary oracle-attested conditions.

Research into combining DLCs with payment channel networks could enable routed DLC contracts, where an intermediary facilitates a contract between two parties who do not have a direct channel. This would bring derivatives functionality to the Lightning network's existing infrastructure.

DLC Concepts on Layer 2: The Spark Approach

On-chain DLCs work, but they inherit Bitcoin L1's constraints: every funding and settlement transaction pays miner fees, confirmation times vary, and the CET pre-signing phase requires significant computation for complex contracts. Spark, as a Bitcoin Layer 2 built on statechains, offers a different environment for oracle-conditional transfers.

Spark's programmable transfer model allows conditional logic to be attached to off-chain transfers. A transfer can be structured to settle only when specific conditions are met, including conditions derived from oracle attestations. This enables DLC-like contract semantics without the on-chain funding and settlement transactions.

The practical implications are significant. A derivatives contract on Spark would not require waiting for on-chain confirmations during setup. It would not pay miner fees for funding or settlement. And because Spark transfers are already off-chain, the privacy properties are inherent rather than requiring careful cryptographic construction.

For prediction markets and binary options, Spark's instant settlement and near-zero fees make small-value contracts viable: something that is uneconomical on L1 when transaction fees are high. A prediction market with thousands of participants making small bets becomes practical when each contract settlement costs fractions of a cent rather than dollars in miner fees.

Building with PSBTs and Miniscript

DLC implementations rely heavily on Partially Signed Bitcoin Transactions (PSBTs) for the contract negotiation phase. PSBTs provide a standardized format for passing unsigned or partially signed transactions between parties, which is essential when two counterparties need to collaboratively construct and sign CETs.

Miniscript is also relevant for DLC developers. While the core DLC mechanism uses adaptor signatures rather than complex scripts, the refund paths and timelock conditions in DLC transactions benefit from Miniscript's ability to compose spending policies in a structured, analyzable way. Miniscript makes it easier to reason about the security properties of DLC transaction scripts and to build tooling that can verify contract correctness.

The Road Ahead

DLC development continues across several fronts. The DLC specification is actively maintained, with ongoing work on standardizing oracle announcement formats, improving CET compression techniques, and defining interoperability requirements between implementations.

Proposed Bitcoin consensus changes could further improve DLCs. Covenant proposals like OP_CTV (CheckTemplateVerify) could simplify CET construction by allowing transaction templates to be committed on-chain. OP_CAT, if activated, would enable more expressive script-level conditions that could complement or partially replace the adaptor signature approach.

Oracle standardization remains an active area. The DLC oracle specification defines how oracles should format announcements and attestations, but the ecosystem still needs more production-grade oracle services covering diverse data types: financial prices, sports outcomes, weather data, and other verifiable events.

The combination of maturing DLC tooling, increasing oracle availability, and Layer 2 platforms like Spark that can host DLC-like contracts off-chain suggests that Bitcoin-native derivatives are moving from experimental to practical. The fundamental insight of Dryja's original paper: that oracles do not need to know about the contracts that depend on them: remains one of the most elegant constructions in Bitcoin cryptography.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.