DLC Oracle Markets: How Attestation Services Enable Trustless Bitcoin Contracts

Bitcoin lacks native smart contracts that can reference external data. There is no on-chain price feed, no weather API, no election result endpoint. Yet since 2020, people have been settling financial contracts on Bitcoin that depend on exactly this kind of real-world information. The mechanism that makes this possible is the Discreet Log Contract oracle: an attestation service that signs outcomes without ever learning what contracts depend on its signatures.

This article covers how DLC oracle attestation markets work, the cryptographic primitives that make them trustless, the oracle services operating today, and where this technology is heading as Bitcoin's programmability expands.

What Is a DLC Oracle?

A DLC oracle is an entity that commits to attesting the outcome of a future event. It publishes a public key and a nonce commitment in advance, then, when the event occurs, publishes a Schnorr signature over the outcome. This signature is a scalar value: the discrete logarithm of a point that contracting parties computed in advance. Anyone holding an adaptor signature locked to that point can now complete it into a valid Bitcoin signature and claim their funds.

The critical property is blindness. The oracle does not know who has created contracts, how many contracts exist, or what the terms are. It simply publishes an attestation for a predefined event. This stands in sharp contrast to smart contract oracles like Chainlink, where every oracle interaction is recorded on-chain and contract terms are publicly visible.

Key property: A DLC oracle never holds or controls funds. It cannot steal from any party. Its only power is to attest honestly or dishonestly to an outcome. Dishonesty is cryptographically detectable: signing two different outcomes for the same event reveals the oracle's private key.

Cryptographic Mechanics

The protocol was proposed by Thaddeus Dryja at MIT's Digital Currency Initiative in 2017. Dryja, co-author of the Lightning Network whitepaper, designed DLCs to bring conditional contracts to Bitcoin without modifying the consensus layer. The construction relies on three primitives: Schnorr signatures, adaptor signatures, and oracle nonce commitments.

Setup Phase

Before an event, the oracle (Olivia) announces a public key O and a nonce R for the event. For each possible outcome, any party can derive an anticipated signature point:

S_outcome = R + hash(O, R, outcome) · O

Two counterparties (Alice and Bob) fund a 2-of-2 multisig output on Bitcoin. They then exchange adaptor signatures for every possible outcome. Each adaptor signature is a valid Schnorr signature missing exactly one scalar: the oracle's attestation value for that outcome.

Attestation Phase

When the event occurs, Olivia signs the outcome using standard Schnorr signing, producing a scalar s_outcome. This scalar is the discrete logarithm of the anticipated point S_outcome. Olivia publishes this scalar publicly. She does not know who Alice or Bob are, or whether any contracts depend on this attestation.

Settlement Phase

The winning party takes the oracle's scalar and adds it to the adaptor signature's incomplete scalar:

s_valid = s_adaptor + s_outcome

The resulting value is a complete, valid Schnorr signature that can be broadcast to Bitcoin's network to claim the contract funds. The losing party's adaptor signatures remain incomplete because they were locked to a different outcome point. On-chain, the settlement transaction looks like an ordinary Taproot spend: no observer can determine that a DLC existed, what its terms were, or who the oracle was.

Equivocation detection: If an oracle signs two different outcomes for the same event, it reveals two distinct scalars for the same nonce. Anyone can subtract them to recover the oracle's private key. This makes fraud provable and self-punishing: a cheating oracle loses control of its key pair entirely.

Oracle Services Operating Today

The DLC oracle ecosystem is still early but includes several active projects spanning general-purpose attestation, specialized data feeds, and bridge infrastructure. The dlcspecs repository defines the interoperability standard that most implementations follow.

General-Purpose Oracle Services

Specialized Oracle Services

Beyond general-purpose attestation, purpose-built oracles serve specific data domains:

• noaa-oracle: attests to National Oceanic and Atmospheric Administration weather data, enabling parametric insurance contracts on Bitcoin
• pow-attest: emits BIP-340 Schnorr attestations for GitHub events, demonstrating that any verifiable data source can serve as a DLC oracle
• p2pderivatives-oracle: reference Go implementation by Crypto Garage for numerical event attestation (price feeds, indices)

The barrier to running an oracle is intentionally low. Any entity with a data source and a signing key can publish attestations that others consume without coordination.

The DLC Trust Model vs. Smart Contract Oracles

DLC oracles and smart contract oracles like Chainlink solve the same fundamental problem: bringing off-chain data on-chain. But they differ in almost every architectural dimension. Understanding these differences is essential for evaluating which model fits a given use case.

The tradeoff is privacy and minimalism versus composability and expressiveness. DLC oracles are ideal for bilateral contracts where privacy matters: derivatives, insurance, and peer-to-peer wagers. Smart contract oracles are better suited for multi-party protocols that need on-chain composability, like DeFi lending pools or automated market makers.

Notably, these models are not mutually exclusive. DLC.Link received a Chainlink grant to bridge Chainlink oracle data into DLC attestations, combining the privacy of DLCs with the data breadth of Chainlink's network.

Use Cases Beyond Price Feeds

Price feeds for BTC/USD derivatives were the first DLC use case, but the oracle model supports any event with a verifiable outcome. Several categories have seen real-world implementation or active development.

Financial Derivatives

The most mature DLC use case. DLC Markets operates a non-custodial OTC derivatives platform on Bitcoin mainnet, using the Pythia oracle for settlement. LN Markets introduced an institutional-grade DLC specification adding margin calls, liquidation, and netting capabilities. Before sunsetting its consumer app in August 2025, Atomic Finance processed approximately $140 million in options vault volume using DLC-based self-custodial options.

Bitcoin-Collateralized Lending

DLCs enable non-custodial lending where the borrower retains their keys and the oracle's price attestation triggers liquidation or repayment. Lygos Finance (which acquired Atomic Finance's DLC technology in August 2025) operates institutional Bitcoin-backed lending with loan sizes ranging from $25,000 to $100 million. The DLC ensures neither party can unilaterally access collateral without an oracle attestation confirming the trigger condition.

Prediction Markets and Sports Betting

The first-ever DLC on Bitcoin mainnet was an election bet. On September 8, 2020, Suredbits founder Chris Stewart and BTCPay Server creator Nicolas Dorier settled a 1 BTC wager on the 2020 US presidential election, with Outcome Observer serving as the oracle.

More recently, the Ticketed DLC (dlctix) construction by conduition enables instant-buy-in wager contracts where participants purchase SHA256 preimage "tickets" off-chain via Lightning or Fedimint eCash. This extends DLCs from bilateral contracts to multi-party prediction markets without requiring each participant to interact with the on-chain funding transaction.

Parametric Insurance

Weather oracles like noaa-oracle demonstrate how parametric insurance can work on Bitcoin. A contract could pay out automatically when an oracle attests that rainfall in a specific region exceeded a threshold, or that temperature dropped below a critical point. No claims adjuster, no paperwork: the oracle's attestation directly settles the contract. This model is especially relevant for agricultural insurance in regions without reliable traditional insurance infrastructure.

Cross-Chain Bridges

DLC.Link uses a network of attestors to bridge Bitcoin to EVM chains. Their dlcBTC product locks BTC in a DLC on Bitcoin L1, and attestors provide signatures that mint or burn wrapped tokens on Ethereum, Arbitrum, and other chains. The BTC never leaves a self-custodial DLC: no centralized custodian holds the underlying Bitcoin.

DLC Tooling and Developer Ecosystem

Building DLC applications requires oracle software, contract libraries, and wallet integration. The ecosystem has converged around a few core implementations.

Core Libraries

Specification and Interoperability

The dlcspecs repository defines the protocol: oracle messaging formats, contract construction rules, and settlement procedures. It is jointly maintained by contributors from Suredbits, Crypto Garage, and the broader community. Interoperability between implementations remains a work in progress, but the specification provides a shared foundation.

The dlcdevkit project is notable for lowering the barrier to entry. It wraps rust-dlc with a Bitcoin Dev Kit (BDK) wallet integration and supports Nostr as a transport layer for peer-to-peer DLC communication and oracle attestation delivery (via NIP-88). This means developers can build DLC applications without running dedicated servers for peer discovery or oracle polling.

Market Evolution: From Consumer to Institutional

The DLC market has undergone a significant shift since 2024. Several consumer-facing projects have closed or pivoted, while institutional applications have gained traction.

Projects That Have Pivoted or Closed

• 10101 built the first self-custodial trading app using DLC channels over Lightning but shut down in November 2024, citing insufficient retail demand for self-custody trading
• Atomic Finance processed ~$140 million in options volume but sunset its consumer app in August 2025; its DLC technology was acquired by Lygos Finance for institutional use
• Lava Protocol used DLCs for bitcoin-collateralized loans but abandoned the self-custodial model in November 2025, switching to a fully custodial architecture

Active Institutional Platforms

• DLC Markets operates a non-custodial OTC derivatives platform on Bitcoin mainnet, spun out from LN Markets
• Lygos Finance runs institutional DLC-powered Bitcoin lending in private beta, with loan sizes from $25,000 to $100 million
• LN Markets introduced an institutional DLC specification with a coordinator model addressing the free-option problem, adding margin calls and netting
• DLC.Link continues developing its attestor network for Bitcoin-to-EVM bridging

The pattern is clear: the "self-custody premium" that DLCs offer has not yet generated sufficient demand at the retail level. Institutional actors, however, find the non-custodial guarantee valuable because it eliminates counterparty risk in large transactions. A $50 million Bitcoin-backed loan where neither party can unilaterally access collateral is a fundamentally different risk profile than one that relies on a custodian.

Technical Challenges and Open Problems

DLCs are not without limitations. Several technical challenges affect both oracle operators and contract participants.

Oracle Availability and Redundancy

If an oracle goes offline before attesting to an outcome, dependent contracts cannot settle. The multi-oracle construction addresses this: contracting parties can require attestations from k-of-n oracles, so that no single oracle failure blocks settlement. Suredbits demonstrated the first multi-oracle DLC settlement on Bitcoin mainnet in March 2021, using attestations from three independent sources.

Outcome Enumeration

For numerical events (like a price feed), every possible outcome requires a separate adaptor signature. A BTC/USD price oracle covering a range of $0 to $200,000 at $1 precision would require 200,000 adaptor signatures. Numeric decomposition (attesting to individual digits rather than the full number) reduces this to a logarithmic number of signatures, but it adds complexity to contract construction and verification.

On-Chain Settlement Costs

Each DLC requires at least one on-chain transaction to fund the contract and one to settle it. During periods of high fee market activity, small contracts become uneconomical. This is a limitation shared with all Bitcoin L1 contracts and is one motivation for exploring DLCs on Layer 2 networks.

ECDSA vs. Schnorr

The original DLC construction used Schnorr signatures, but before Taproot activated in November 2021, Bitcoin only supported ECDSA. Crypto Garage developed an ECDSA-compatible adaptor signature variant to enable DLCs pre-Taproot. Today, with Taproot widely deployed, new implementations use native Schnorr via BIP-340, which is simpler and more efficient.

Future Directions

Several developments could significantly expand the DLC oracle market in the coming years.

Off-Chain DLC Channels

DLC channels allow parties to create, settle, and renew contracts without touching the blockchain for each iteration. Instead of funding a new on-chain UTXO for every contract, parties open a channel once and execute many contracts within it. This "roll-along" model dramatically reduces on-chain costs for repeated interactions like recurring derivatives or rolling insurance policies.

Potential Soft Fork Improvements

Two proposed Bitcoin opcodes would benefit DLCs. OP_CTV (CheckTemplateVerify) would enable more efficient contract templates, and OP_CSFS (CheckSigFromStack) would allow on-chain verification of oracle signatures directly in Bitcoin Script, eliminating the need for adaptor signature constructions entirely. These proposals are still under discussion in Bitcoin's development community.

DLCs on Bitcoin Layer 2 Networks

Running DLCs on Layer 2 networks addresses the on-chain cost problem. A DLC constructed off-chain on a network like Spark could settle instantly when the oracle publishes its attestation, without waiting for block confirmations or paying L1 transaction fees. The combination of DLC-based conditional contracts with Spark's instant settlement model could enable a new class of products: parametric insurance that pays out within seconds of a weather event, derivatives that settle the moment a price threshold is crossed, or prediction markets where winnings are immediately spendable.

For developers interested in building on these primitives, the Spark SDK documentation covers the settlement infrastructure, while the dlcdevkit repository provides the DLC contract tooling. The intersection of these two stacks is largely unexplored.

Nostr-Native Oracle Discovery

The dlcdevkit project already supports Nostr as a transport layer for DLC communication. Extending this to oracle discovery would allow oracles to publish event announcements and attestations as Nostr events, making the entire oracle market decentralized and censorship-resistant. Users could subscribe to oracle feeds, verify attestations, and construct contracts without relying on any centralized oracle registry.

How to Evaluate a DLC Oracle

Not all oracles are equal. When selecting an oracle for a DLC contract, participants should consider several factors.

• Track record: how long has the oracle been operating, and has it ever failed to attest or attested incorrectly?
• Data source transparency: does the oracle disclose where it sources its data, and can that source be independently verified?
• Nonce management: does the oracle use deterministic nonces (reducing the risk of nonce reuse, which would compromise its private key)?
• Multi-oracle compatibility: does the oracle follow the dlcspecs standard, allowing it to be combined with other oracles in k-of-n configurations?
• Attestation frequency: for continuous data (like price feeds), how often does the oracle publish, and what is the lag between event occurrence and attestation?

The Suredbits Oracle Explorer provides a registry where users can discover oracles, review their event history, and verify past attestations. Running your own oracle using Kormir or Krystal Bull is also an option for parties who want full control over the attestation process.

Conclusion

DLC oracle attestation markets represent a fundamentally different approach to connecting Bitcoin with external data. Rather than building complex on-chain oracle networks, DLCs keep the oracle minimal and blind: it signs outcomes without knowing who cares. The cryptography ensures that dishonesty is detectable and self-punishing, while the bilateral contract structure preserves privacy that on-chain oracle systems cannot match.

The market is still maturing. Consumer applications have struggled to find product-market fit, but institutional platforms are demonstrating that non-custodial guarantees matter when the stakes are high enough. As tooling improves through projects like dlcdevkit, and as Layer 2 networks reduce settlement costs, the range of viable DLC applications will expand beyond financial derivatives into insurance, prediction markets, and conditional payments of all kinds. For a deeper technical treatment of the contract construction itself, see our research article on Discreet Log Contracts.

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.