A Discreet Log Contract, or DLC, is an application protocol for constructing Bitcoin transactions whose payout depends on an event attested to by an oracle. Two contracting parties agree on the possible outcomes and payout rules, lock collateral in a jointly controlled Bitcoin output, and exchange signatures for possible closing transactions before funding the contract.
Bitcoin does not have a DLC consensus object. Nodes validate the funding transaction, the eventual closing transaction, its signatures, locktime, scripts, amounts, and UTXO spend. DLC software supplies the contract messages, oracle format, payout mapping, adaptor signatures, transaction construction, storage, and recovery logic.
The oracle reports; it does not normally hold the funds
A DLC oracle publishes signed information about an event. Examples could include an election result, weather observation, asset-price fixing, or another objectively encoded outcome. The oracle is not normally a co-signer of the DLC funding output and does not need to learn which parties used its announcement.
Before the event, the oracle publishes an announcement. The current specification describes an announcement containing the oracle public key, event identifier, expected attestation time, event descriptor, and one or more public nonces. The announcement is signed so clients can verify that it came from the stated oracle.
After the event, the oracle publishes an attestation: a signature over the encoded outcome using the previously announced nonce material. Contract participants use that signature data to complete the closing signature associated with the attested outcome.
This design can keep the oracle unaware of specific contracts, but “discreet” is not a guarantee of complete privacy. Network observation, counterparties, wallet behavior, reused addresses, distinctive transaction structures, or an oracle service's access logs can still reveal information.
Event descriptors define the outcome language
The parties must agree on exactly what the oracle can attest to. An event descriptor defines the outcome encoding.
An enumerated event lists a finite set of strings, such as sunny, cloudy, or rainy. A numeric event can use digit decomposition, in which an oracle signs digits in a specified base with a unit, precision, sign rule, and number of digits.
Encoding is part of the contract. Differences in capitalization, normalization, precision, time source, rounding, overflow behavior, or event identifiers can make an attestation unusable for a contract even when humans believe the oracle reported the expected fact.
The oracle announcement should therefore be treated as a cryptographic interface, not a natural-language promise. Wallets need to verify the exact serialized event, public key, nonces, and descriptor before accepting collateral terms.
Negotiation produces one shared transaction view
The current peer-protocol specification uses an offer, accept, and sign exchange. The offerer proposes contract information, oracle information, collateral, inputs, payout and change scripts, fee rate, and locktimes. The accepter validates those terms, contributes its own inputs and collateral, and returns adaptor signatures for the possible Contract Execution Transactions, or CETs, plus a signature for the refund transaction.
The offerer then sends its signatures. Only after both parties possess the signatures needed for safe closure should the funding transaction be broadcast.
This ordering protects against locking funds before a usable exit exists. A wallet that broadcasts too early can create a jointly controlled UTXO without having every required CET or refund signature. DLC implementations must persist negotiation state and verify the complete transaction set before funding.
The contract identifier and transaction ordering rules also matter. Both parties must construct byte-identical funding and closing transactions for signatures to verify. Input order, output order, serial identifiers, amounts, scripts, and locktimes cannot be treated as display-only metadata.
The funding transaction locks collateral
Under the current version-zero transaction specification, the funding transaction combines participant inputs and creates a two-of-two P2WSH funding output. Each party may also receive change. SegWit inputs are required by that specification to avoid transaction-ID malleability that could invalidate precomputed closing transactions.
Once confirmed, the funding output can be spent cooperatively by signatures from both funding keys. The parties have already prepared signatures for outcome-specific CETs and a time-locked refund.
Bitcoin consensus sees a standard Bitcoin output and later spend. It does not see the event descriptor or payout curve unless an application reconstructs them from the parties' stored contract data.
Collateral remains exposed to ordinary Bitcoin risks: lost keys, corrupted contract records, inadequate backups, fee miscalculation, confirmation delays, reorganizations, and implementation bugs. “Non-custodial” does not mean that recovery is automatic.
CETs encode possible payouts
A Contract Execution Transaction spends the funding output and pays the parties according to one possible outcome. For a simple enumerated event, the parties can construct one CET per outcome. Numeric contracts can require many possible payout points, so the specification includes compression and interpolation techniques to reduce the transaction and signature set.
Before the oracle attests, neither party should possess a complete ordinary signature that allows unilateral broadcast of an outcome CET. Instead, each party exchanges adaptor signatures. An adaptor signature is a cryptographic object that can be completed with a secret related to the oracle's eventual signature.
The oracle's public announcement lets the parties compute the adaptor points needed during setup. The later attestation reveals the value that completes the adaptor signature for the corresponding CET. The party with the completed signatures can broadcast that transaction.
The oracle does not choose a payout transaction after seeing the contract. Its signed outcome unlocks the pre-negotiated outcome path. If the parties disagreed about the payout curve during setup, the oracle's later signature does not repair the contract.
The attestation is an input to signature completion
It is tempting to say the oracle “executes” the contract. More precisely, the oracle publishes signed outcome data. DLC software verifies the announcement and attestation, identifies the applicable CET, and uses the attestation secret to complete an adaptor signature.
Bitcoin nodes verify the resulting ordinary signatures and transaction. They do not verify that the oracle was an appropriate source, followed a correct measurement method, or reported reality honestly.
This boundary explains the principal oracle risk. A cryptographically valid attestation can still be factually wrong. An oracle can also fail to publish, publish late, use inconsistent event parameters, or compromise its signing key.
Under the construction described by the DLC introduction, signing conflicting outcomes with the same committed nonce can expose the oracle's private key. That creates accountability and severe consequences, but it does not reverse an already confirmed incorrect payout.
The refund path handles non-attestation
The parties also sign a refund transaction during setup. It returns their respective collateral after a later locktime. The refund is intended for a situation in which the oracle does not provide a usable attestation.
The refund locktime must leave enough time for the event and expected oracle publication. If it is too early, a participant may attempt a refund before a delayed but legitimate outcome path is used. If it is too late, funds remain locked longer during oracle failure.
Fee planning is equally important. A fully signed refund that cannot confirm economically or before another valid spend is not a complete operational recovery plan. Implementations need current fee-management and rebroadcast procedures rather than assuming the fee rate chosen at setup will remain adequate.
A refund protects against non-attestation. It does not protect against an oracle signing the wrong outcome or colluding with one participant. The current DLC introduction explicitly notes that its described version does not prevent participant-oracle collusion.
Multiple oracles change the assumption, not eliminate it
A DLC can combine multiple oracles and require a threshold of attestations. This can reduce dependence on any single source, but it introduces coordination and agreement questions.
The contract must specify whether oracles use corresponding outcome sets, how numeric differences are tolerated, what threshold is required, and how conflicting or missing attestations map to CETs. More oracles can mean more announcements, nonces, adaptor signatures, storage, and closing possibilities.
A federation is only as useful as its independence and measurement design. Several public keys controlled by one operator do not provide the same failure resistance as genuinely independent sources. Correlated data feeds, shared infrastructure, legal pressure, or common software bugs can defeat a nominal threshold.
The current specification repository documents multi-oracle work but also preserves roadmap material and in-progress areas. Support must be checked against the exact implementation pair, not inferred from a general feature list.
Cooperative close can avoid revealing the contract path
If both parties agree, they can cooperatively spend the funding output with a mutually signed transaction rather than using an oracle-conditioned CET. This can reduce on-chain fingerprinting and permit a mutually accepted settlement.
A cooperative close depends on continued cooperation. It cannot be the only exit. The pre-signed CETs and refund transaction are what allow unilateral closure under the agreed conditions.
On-chain privacy is also relative. The current v0 funding output is designed to resemble other two-of-two P2WSH constructions, but spending patterns, timing, output amounts, and later analysis may distinguish it. Taproot DLC designs could change the fingerprint, yet the DLC specification lists Taproot support as future work rather than a universal current property.
Fees, dust, and payout curves are contract behavior
DLC transaction sets must account for funding fees, closing fees, and outputs that fall below the implementation's dust threshold. The current transaction specification describes fee allocation and omits a participant output from a CET when its payout would be below the stated threshold.
That can create a sharp difference between an economic curve and actual transaction outputs. Rounding, interpolation, dust handling, and fee assumptions should be shown to users before signing.
Numeric contracts can create large computational and storage requirements. Compression techniques reduce the number of CETs or signatures, but they also add algorithms that independently developed implementations must match exactly.
The funding transaction itself can remain unconfirmed, be replaced under applicable conditions, or be affected by a reorganization. A contract should define when it becomes active and how many confirmations are required before participants rely on it.
DLCs are an application protocol with uneven maturity
DLC papers, specifications, libraries, wallets, and applications have existed for years. That is evidence of implementation work, not evidence that every component is standardized, production-ready, or interoperable across current releases.
As of July 24, 2026, the official dlcspecs master branch at commit 9cd9148938c616690c79d99ec6f330e213c246c5 still labels the specification work in progress. Its README and roadmap describe future work including transfers, option-style DLCs, Taproot DLCs, and Lightning DLCs. Older roadmap sections record features as done or in progress at the time they were written, so they are historical development evidence rather than a current compatibility matrix.
The current rust-dlc master branch at commit 8e6a75fbc9685e6eafa348edd45a793fcb63fa4d implements transaction, numeric-contract, manager, message, Bitcoin-RPC, oracle-client, and storage components. Its README also says the library is early-stage, has not been thoroughly tested in production, recommends avoiding mainnet, and is not yet fully compliant with the DLC specification.
Bitcoin-S documentation provides evidence of another DLC implementation family. The official materials reviewed for this guide do not provide a current comprehensive cross-implementation report showing that present Bitcoin-S, rust-dlc, and other implementations interoperate across every message version, oracle format, numeric contract, fee path, and recovery case. Shared specifications and test vectors are interoperability targets; exact implementation pairs still require versioned cross-testing.
The reviewed dlcspecs, rust-dlc, and Bitcoin-S materials also do not identify a project-wide independent security assessment covering the entire current DLC stack. The original paper, specifications, adaptor-signature work, test vectors, implementation tests, and code review are relevant security evidence, but they are not equivalent to an audit of current wallet storage, oracle operations, key management, fee recovery, or released binaries.
A careful evaluation records the exact specification commit, implementation release, oracle software, network, contract type, and test vectors. It verifies backup and recovery, simulates oracle failure, confirms refunds and CETs, and does not put significant funds at risk merely because the protocol design is non-custodial.
DLCs demonstrate how existing Bitcoin transactions and cryptography can coordinate event-dependent payouts. Their security remains the combined result of Bitcoin validation, correct transaction preparation, sound adaptor-signature code, usable oracle attestations, safe key management, compatible software, and robust operations.