Discreet Log Contract (DLC)

A Discreet Log Contract (DLC) is a type of smart contract for Bitcoin that uses oracles and adaptor signatures to enable conditional payments based on real-world events, such as sports scores, price feeds, or weather data, without exposing the contract's logic on-chain. The contract terms are agreed upon and signed off-chain by the involved parties, creating a set of possible transaction outcomes. A trusted oracle, or a federation of oracles, then publishes a cryptographic signature attesting to the real-world outcome, which allows only the correct spending transaction to be broadcast and settled on the Bitcoin blockchain.

The core cryptographic mechanism enabling DLCs is the adaptor signature, a modified digital signature that is encumbered with a secret value related to the oracle's attestation. When parties set up the contract, they collaboratively create a series of possible Bitcoin transactions, each corresponding to a different contract outcome, and sign them with these adaptor signatures. These partial signatures are useless on their own. Only when the oracle reveals its signature for the actual outcome does it provide the missing cryptographic piece, allowing the winning party to complete and broadcast the single, valid settlement transaction.

This architecture provides significant privacy and scalability benefits. Because the contract's logic and the full set of potential outcomes are never recorded on-chain, transaction graph privacy is preserved—external observers only see a simple, final settlement. Furthermore, by keeping the bulk of the contract negotiation and computation off-chain, DLCs avoid congesting the base Bitcoin layer, making them a highly scalable solution for complex conditional logic. This positions DLCs as a leading layer-2 technology for prediction markets, options contracts, and hedging instruments on Bitcoin.

The security model of a DLC hinges on the trustworthiness and correct execution of the oracle(s). While the protocol is trust-minimized regarding the counterparty (they cannot cheat the outcome), participants must rely on the oracle to publish a correct and timely attestation. To mitigate this, DLCs can be designed to use multiple oracles in a threshold scheme, requiring a consensus of signatures before a settlement is possible, thereby reducing reliance on any single point of failure. This makes the system robust against oracle manipulation or downtime.

In practice, a DLC for a Bitcoin/USD price bet would involve two parties locking funds in a 2-of-2 multisig address. They would pre-sign transactions for outcomes like "BTC > $70,000" and "BTC ≤ $70,000," using adaptor signatures tied to an oracle's future signature. When the oracle publishes its signed data point for the price at the contract's expiry, the party whose condition was met can combine the oracle's signature with their adaptor signature to create a valid Bitcoin transaction, claiming the locked funds. The entire process, except for the final settlement, remains private and off-chain.

A Discreet Log Contract (DLC) is constructed using a combination of adaptor signatures and an oracle. The two contracting parties first agree on a set of possible outcomes for a future event (e.g., "BTC price > $70,000" or "BTC price ≤ $70,000"). An oracle, which is a service that will later publish a cryptographic signature attesting to the real-world outcome, provides a set of nonces or signature points corresponding to each potential result during the setup phase. The parties use these points to create a series of partial signatures for a multisignature transaction that can only be completed with the oracle's final signature.

The core cryptographic mechanism is the adaptor signature, which is a partial signature encrypted with a secret tied to the oracle's future announcement. When setting up the DLC, the parties collaboratively create a funding transaction that locks funds into a 2-of-2 multisig address. They then generate a set of Conditional Execution Transactions (CETs), one for each possible contract outcome. Each CET is signed with an adaptor signature, meaning it is incomplete and cannot be broadcast until the oracle reveals the secret corresponding to the actual event outcome.

Execution occurs when the oracle publishes its attestation for the real-world event. This attestation contains the cryptographic secret needed to complete only one of the pre-signed adaptor signatures. The winning party can then take this secret, complete their signature on the corresponding CET, and broadcast the transaction to claim the funds according to the contract terms. Critically, only the single, executed CET is ever seen on the blockchain; all other potential outcomes and the full terms of the contract remain entirely private.

This design provides significant advantages over other Bitcoin smart contract methods. Unlike hashed timelock contracts (HTLCs), DLCs can handle complex, multi-outcome logic. Compared to executing contracts on a separate layer or sidechain, DLCs settle directly on the Bitcoin base layer, inheriting its security. The privacy benefit is paramount: external observers cannot determine what the contract was about, how many outcomes were possible, or which party "won," seeing only a simple multisig settlement.

An adaptor signature is a cryptographic construction that encodes a secret value within a digital signature, making the signature valid only if the secret is revealed. It is a foundational primitive for conditional payments and off-chain protocols, acting as a cryptographic "lockbox" for information. The signer produces a signature that is incomplete or "adapted" to a cryptographic puzzle; completing the signature to make it valid on the blockchain requires solving the puzzle by revealing the hidden secret, known as the witness or adaptor point.

The core mechanism relies on elliptic curve cryptography. The signer creates a signature that is offset by a secret value t, represented by its public point T = t*G. This produces an adaptor signature σ'. To verify and broadcast a valid signature σ, the solver must provide t. Crucially, anyone who sees the valid signature σ can subtract the adaptor signature σ' to compute the secret t = σ - σ'. This property, called signature adaptor, ensures that the act of completing the payment automatically and trustlessly reveals the pre-image secret.

This technology is the engine behind Discreet Log Contracts (DLCs). In a DLC, an oracle commits to outcomes (e.g., "BTC > $60K") using adaptor signatures. Each possible outcome is tied to a unique secret. The contract is a set of adaptor-encrypted transactions that can only be completed with the secret corresponding to the real-world outcome. When the oracle publishes its signature for the correct outcome, it inadvertently reveals the secret, allowing only the winning party to claim the funds. This keeps all contract details off-chain until settlement.

Beyond DLCs, adaptor signatures enable a wide array of Layer 2 protocols. They are key to atomic swaps between different blockchains, where the secret revealed by one chain's transaction is used to claim funds on the other. They also power payment pools, coinjoins, and other collaborative transaction schemes where participants need to prove knowledge of a secret to contribute to a signed transaction without revealing it prematurely to their peers.

The security model of adaptor signatures inherits from the underlying digital signature scheme, typically Schnorr or ECDSA. For Schnorr signatures, the construction is more elegant and efficient due to linearity. Critical considerations include ensuring the adaptor point T is properly integrated and that the protocol guards against signature malleability and replay attacks. When implemented correctly, they provide a powerful, trust-minimized tool for embedding complex logic into Bitcoin and other cryptocurrency transactions.