Taproot-Native DLCs: How Schnorr Signatures Enable Composable Bitcoin Contracts

Discreet Log Contracts (DLCs) let two parties make conditional Bitcoin payments based on real-world data without revealing contract details on-chain. Proposed by Tadge Dryja at the MIT Digital Currency Initiative in 2018, DLCs solve the oracle problem elegantly: oracles attest to outcomes without knowing which contracts depend on them, and the blockchain sees nothing but ordinary-looking transactions. But pre-Taproot DLCs carried significant overhead. Funding outputs exposed 2-of-2 multisig structures, settlement transactions required multiple ECDSA signatures with DER encoding overhead, and composing DLCs with other protocols was cryptographically awkward.

The activation of Taproot in November 2021 changed the equation. With Schnorr signatures (BIP-340), Taproot spending rules (BIP-341), and Tapscript (BIP-342), DLCs gain smaller on-chain footprints, stronger privacy, and something that was previously impractical: composability with other Schnorr-based protocols like PTLCs and FROST threshold signatures.

How DLCs Worked Before Taproot

A Discreet Log Contract follows a three-phase lifecycle: funding, execution, and settlement. Alice and Bob lock funds into a shared 2-of-2 output (the funding transaction), then pre-sign a set of Contract Execution Transactions (CETs), one for each possible outcome. When an oracle publishes an attestation, the party holding the winning CET can broadcast it to claim their payout.

The CET Explosion Problem

For enumerated outcomes (team A wins, team B wins, draw), the CET count is manageable. For numeric outcomes, it scales dramatically. A contract on Bitcoin's price with dollar-level precision across a $0 to $200,000 range would naively require 200,000 CETs. Numeric decomposition, where the oracle signs each digit of the outcome separately, reduces this through compression. But even with rounding intervals and digit-based attestation, complex contracts routinely require thousands of pre-signed transactions.

Pre-Taproot On-Chain Costs

Before Taproot, DLC funding transactions used P2WSH (Pay-to-Witness-Script-Hash) outputs. When spent, these revealed the 2-of-2 multisig script structure in the witness data: two public keys and two ECDSA signatures. Each ECDSA signature required 71 to 72 bytes due to DER encoding, and the witness included the full redeem script. A 2-of-2 P2WSH input cost roughly 218 to 250 virtual bytes depending on the implementation.

Beyond size, ECDSA had a cryptographic limitation: adaptor signatures built on ECDSA are fragile. The DLC specification noted that ECDSA adaptor constructions can unintentionally leak information, pushing early implementations toward "semi-scriptless" approaches that still relied on Bitcoin Script (OP_CHECKMULTISIG) rather than pure cryptographic protocols.

Why adaptor signatures matter for DLCs: In the original design, each CET requires a unique adaptor signature tied to the oracle's anticipated attestation point. The oracle's eventual signature completes the adaptor, making the CET valid. ECDSA adaptors work but introduce subtle security concerns. Schnorr adaptors are algebraically clean: the linearity of Schnorr signatures makes adaptor construction and verification straightforward.

What Taproot Changes for DLCs

Taproot introduces three upgrades that collectively transform DLC efficiency: key-path spending, Schnorr signature compactness, and key aggregation through protocols like MuSig2.

Key-Path Spending: The Happy Path

A Taproot output (P2TR) commits to both a key-path and an optional script-path. When both DLC counterparties cooperate (the common case for settled contracts), they can produce a single aggregated Schnorr signature via MuSig2. The resulting transaction looks identical to any single-signature Taproot spend: one 32-byte public key, one 64-byte signature.

No observer can determine that a DLC existed, what its terms were, or who the counterparties are. The funding output, the settlement transaction, and the payout all appear as ordinary single-party payments.

Schnorr Signature Compactness

A BIP-340 Schnorr signature is exactly 64 bytes: a 32-byte nonce commitment R and a 32-byte scalar s. ECDSA signatures vary between 71 and 72 bytes due to DER encoding, plus require a sighash byte. Per-signature savings of 7 to 9 bytes compound across the hundreds or thousands of CETs in a numeric DLC. For a contract with 5,000 CETs, the savings on pre-signed adaptor signatures alone reach 35 to 45 KB.

Witness Size Reduction

The most dramatic savings come from key aggregation. A cooperative settlement via Taproot key-path spend requires a witness of just 64 bytes (the single aggregated signature). Compare this to a P2WSH 2-of-2 multisig witness that includes two signatures, two public keys, and the redeem script.

This reduction applies to both the funding transaction output and the settlement transaction input. A DLC that funds and settles cooperatively saves on both legs.

MuSig2 and Multi-Oracle DLC Schemes

MuSig2 is a two-round multi-signature protocol that enables n participants to produce a single Schnorr signature indistinguishable from a solo signer's output. For DLCs, this unlocks multi-oracle configurations without proportional cost increases.

Single Oracle Limitations

A DLC using a single oracle has a concentrated trust assumption: if the oracle is compromised, malicious, or simply offline, the contract fails or produces an incorrect settlement. Pre-Taproot multi-oracle schemes required separate sets of adaptor signatures per oracle, multiplying the number of CETs and the computational cost of contract setup.

How MuSig2 Solves This

With MuSig2, multiple oracles can aggregate their attestation keys into a single combined point. A k-of-n threshold of oracles can attest to an outcome, and the adaptor signature construction needs only reference this single aggregated point. The CET count stays constant regardless of oracle count: the aggregation happens at the key level, not the transaction level.

The protocol requires two rounds of communication between oracles, but since oracles operate independently and do not need to interact with contract participants during attestation, this adds no latency to contract settlement.

Oracle independence preserved: A critical property of Dryja's original design is that oracles do not know which contracts depend on their attestations. MuSig2 multi-oracle aggregation preserves this: each oracle signs its digit independently, and the aggregation happens client-side by the contract participants. Oracles never learn about each other or about the contracts consuming their data.

Adaptor Signatures with Schnorr: The Composability Primitive

Adaptor signatures are the cryptographic primitive that makes DLCs work. An adaptor signature is an incomplete signature that commits to a hidden value (the adaptor point). When someone reveals the corresponding secret scalar, the adaptor can be completed into a valid signature. In DLC terms: the oracle's attestation secret completes the adaptor, making the winning CET broadcastable.

Why Schnorr Adaptors Are Superior

Schnorr signatures are linear: given signatures s1 and s2 on the same message, s1 + s2 is a valid signature under the sum of the corresponding public keys. This linearity extends to adaptor signatures. A Schnorr adaptor signature is computed as s' = k + e*x, where the adaptor point T = t*G locks the signature behind the secret t. Verification and completion are algebraically clean, with no special-case handling or security caveats.

ECDSA lacks this linearity. ECDSA adaptor constructions, as documented in the Blockstream scriptless scripts repository, require additional workarounds and carry a risk of unintentional information leakage. This made pre-Taproot DLCs harder to audit and compose with other protocols.

Scriptless Scripts in Practice

Scriptless scripts encode smart contract logic in signatures rather than in on-chain Bitcoin Script. The blockchain sees only a normal-looking signature; the actual spending conditions remain hidden between the parties. For DLCs, this means the entire contract lifecycle, from funding through settlement, can be executed without ever revealing a script on-chain.

Composing DLCs with PTLCs

The most significant unlock from Taproot-native DLCs is composability with Point Time Locked Contracts (PTLCs). PTLCs are the Schnorr-based successor to HTLCs, using point locks (elliptic curve points) instead of hash locks. Where an HTLC reveals the same hash preimage across every hop of a Lightning route, a PTLC uses adaptor signatures so each hop reveals a different secret, preventing correlation by intermediate nodes.

Conditional Payment Routing

Composing DLCs with PTLCs enables conditional payment routing: payments that complete only if a DLC oracle attests to a specific outcome. Consider a scenario where Alice wants to pay Bob 0.5 BTC if the price of bitcoin exceeds $150,000 by a certain date. Instead of locking funds in a traditional DLC funding output, Alice can route a PTLC-based payment through the Lightning Network where the adaptor point is derived from the oracle's anticipated attestation.

If the oracle attests that the condition is met, the attestation secret completes the adaptor signature chain, and the payment settles atomically across all hops. If the condition is not met, the PTLC times out and funds return. No on-chain DLC funding transaction is needed at all.

What This Enables

• Oracle-conditional Lightning payments that settle without any on-chain footprint
• Multi-hop DLC settlements routed through existing payment channel infrastructure
• Chained contracts where one DLC's outcome triggers another DLC's settlement
• Integration of DLC outcomes into broader payment flows without dedicated funding UTXOs

This composability was impractical before Taproot. ECDSA-based adaptor signatures could not cleanly chain across multiple protocol layers. The algebraic linearity of Schnorr makes it possible to compose adaptor points from different sources (DLC oracles, PTLC hops, multi-party signing sessions) into a single coherent cryptographic flow.

Privacy Analysis: What Observers See

Privacy is a first-order benefit of Taproot DLCs, not a side effect. The improvements affect every phase of the contract lifecycle.

The cooperative case (which is the expected resolution for most contracts) achieves full privacy. An external observer cannot distinguish a DLC settlement from a regular person-to-person Bitcoin payment. The non-cooperative case, where one party broadcasts a CET unilaterally, still reveals the taptree branch being spent, but even then, the other branches (including the key-path) remain hidden.

Current State of Taproot DLC Implementations

Several implementations are advancing Taproot-native DLC support, though adoption is still in active development.

rust-dlc and DlcDevKit

The rust-dlc library is the reference implementation for DLCs in Rust, with active work on a Taproot branch (taproot-dlc) that integrates MuSig2 for key aggregation and Schnorr-based adaptor signatures. Built on top of it, DlcDevKit (DDK) provides application-level tooling for DLC creation, management, and storage, with a pluggable transport architecture supporting both Lightning gossip and Nostr messaging.

DLC Specification

The dlcspecs repository maintains the protocol specification, including numeric outcome decomposition and CET compression algorithms. These optimizations reduce thousands of potential CETs to manageable numbers through digit-based signing and rounding intervals: with numeric decomposition, an oracle signs each digit of the outcome separately, compressing many possible outcomes into fewer CETs by ignoring trailing digits.

Ecosystem Projects

Multiple projects have built on DLC infrastructure. Atomic Finance pioneered DLC-based Bitcoin options. Lightspark has explored DLCs as part of the broader smart contract landscape on Bitcoin. Bitlayer has published optimization research on OP-DLC constructions for Layer 2 integration. The ticketed DLC proposal extends the model to off-chain ticketing systems, reducing the number of transactions required for contract setup.

FROST, Schnorr, and the Shared Foundation

FROST (Flexible Round-Optimized Schnorr Threshold) is a threshold signature scheme that produces standard BIP-340 Schnorr signatures on the secp256k1 curve. In a t-of-n configuration, any t+1 participants can cooperatively produce a signature indistinguishable from a single signer's output. Published by Chelsea Komlo and Ian Goldberg in 2020, FROST has moved from academic research to production deployment, including an IETF standardization effort through the Crypto Forum Research Group.

FROST and Taproot DLCs share the same cryptographic foundation: the linearity of Schnorr signatures over secp256k1. Both protocols exploit the property that signature components can be aggregated, split, and adapted without breaking validity. This is not a coincidence: it is a direct consequence of designing protocols around BIP-340's algebraic structure.

Implications for Spark

Spark uses FROST threshold signatures as the foundation of its operator security model. The Spark Entity, a set of independent operators, collectively holds one key in a 2-of-2 multisig with the user via FROST signing. Because both FROST and Taproot DLCs produce standard Schnorr signatures compatible with BIP-340, the protocols operate in the same cryptographic design space.

This shared foundation suggests future composability between Spark payments and DLC-based contracts. A DLC oracle attestation could condition a Spark transfer, or a Spark leaf could participate in a DLC funding output. The cryptographic primitives are compatible: what remains is protocol-level integration work. Developers interested in exploring these intersections can start with the Spark SDK documentation and the DLC specification.

Technical Tradeoffs and Open Questions

Cooperative vs. Non-Cooperative Resolution

Taproot's privacy benefits only fully apply when both parties cooperate. If a counterparty disappears or disputes the outcome, the CET must be broadcast via the script path, revealing the taptree branch. Dispute resolution remains no more private than pre-Taproot DLCs in this scenario: the improvement is in making the happy path (cooperative settlement) indistinguishable from normal transactions.

Oracle Trust Assumptions

MuSig2 multi-oracle schemes reduce single-oracle trust, but do not eliminate oracle risk entirely. If a threshold of oracles colludes or produces incorrect attestations, the contract settles incorrectly. Oracle accountability remains an open research area: oracle reputation systems, fraud proofs for oracle misbehavior, and insurance mechanisms are all active areas of development.

CET Storage and Communication

Even with Schnorr compactness, a numeric DLC with digit decomposition across a large outcome space still requires parties to generate, exchange, and store thousands of adaptor signatures during contract setup. Taproot reduces the on-chain cost but does not eliminate the off-chain computation and bandwidth cost of CET pre-signing. Proposals like CET compression and off-chain ticketing aim to address this, but it remains a practical constraint for high-precision numeric contracts.

The Road Ahead for Composable Bitcoin Contracts

Taproot-native DLCs represent a meaningful step toward composable financial contracts on Bitcoin. The combination of Schnorr linearity, key-path spending privacy, and adaptor signature cleanliness creates a foundation that pre-Taproot Bitcoin could not support.

The most consequential development may not be DLCs themselves, but the composability they enable. When DLC outcomes can condition PTLC payments, when multi-oracle attestations aggregate into single points, and when threshold signing schemes like FROST and MuSig2 operate interchangeably in the same cryptographic space, Bitcoin gains a programmable layer that does not sacrifice its core properties of privacy and minimal on-chain footprint.

For developers building on Bitcoin, the practical takeaway is that Schnorr-based protocols compose. A DLC, a PTLC, a FROST signing session, and a MuSig2 key aggregation all operate on the same algebraic foundation. Understanding one makes the others accessible. For deeper exploration of these primitives, see our analysis of DLC oracle attestation markets, scriptless script applications, and Taproot and Schnorr signatures.

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.