Contracts on bitcoin: DLCs and keyless-custody lending

Wonder

1. How can a contract execute on Bitcoin without the oracle knowing who is betting?
2. Why does a DLC need no price feed on the blockchain at all?
3. What happens to a derivative position if the oracle goes offline or lies?

Explore

Part IDiscreet Log Contracts: oracles, Bitcoin’s way

1. Thaddeus Dryja proposed Discreet Log Contracts (DLCs) in June 2017 and presented them at Scaling Bitcoin in November of that year. The core innovation is a multi-party commitment scheme where participants lock funds in a multisignature output while pre-signing transactions for every possible outcome. No single participant holds the complete set of signatures required to spend the coins, ensuring no one can unilaterally claim the full amount.
2. The oracle announces in advance a public nonce for a future event. From that nonce and the oracle’s public key, anyone can compute, for each possible outcome, the point that the oracle’s eventual signature will correspond to. The parties use these points to lock each pre-signed contract execution transaction, so each can be completed only with the oracle’s signature on its own outcome. The oracle signs only the outcome, never sees the contract and need not know it exists.
3. When the oracle publishes its signature on the actual outcome, the matching transaction can be completed and broadcast, paying out as agreed. Transactions for other outcomes stay locked, because the oracle never signs those outcomes; signing two outcomes for one event would reveal its private key. A refund transaction with a timelock returns the funds if the oracle never signs at all.
4. In contrast, DeFi oracles on Ethereum typically push price data onto the chain, where contracts read it. Users depend on the feed’s operators, and a stale or manipulated feed executes contracts on bad data. DLCs avoid this by settling outcomes off-chain through signatures, leaving no manipulable price feed on the blockchain itself.
5. DLCs enable complex financial instruments like derivatives and collateralized loans directly on Bitcoin without custodial intermediaries. Since the collateral remains in a multisignature escrow controlled by the participants and verified by oracle signatures, counterparty risk is significantly reduced compared to centralized exchanges. The protocol handles the settlement logic through cryptographic commitments rather than relying on a central authority to enforce terms or release funds.
6. The primary trade-off is the dependency on oracle availability and honesty regarding the data itself. While an oracle cannot steal funds or learn contract details, it can still lie about the outcome by signing incorrect data. However, because this lie would be publicly verifiable against other sources, a malicious oracle faces reputational damage. This model shifts trust from custodial entities to cryptographic verification of external events.

Part IIBitcoin-backed lending without giving up the keys

7. DeFi established collateralized lending, but centralized platforms like Celsius and BlockFi held customer bitcoin in their own wallets. When both filed for bankruptcy in 2022, those funds were trapped in insolvency proceedings. The failure exposed the core risk of custodial lending: if the intermediary controls the keys, a balance-sheet collapse or operational error can freeze or destroy user assets regardless of loan status.
8. Bitcoin-native designs keep collateral in multisignature escrow on-chain; some use Discreet Log Contracts (DLCs), others multisig with pre-signed transactions. In these structures, funds are locked in outputs requiring signatures from multiple parties to spend. The borrower retains ownership until repayment is verified, and liquidation occurs only when predefined conditions—such as price thresholds—are met via oracle signatures. This eliminates the need for a custodian to hold the asset during normal operation.
9. Firefish uses a 3-of-3 escrow with five pre-signed transactions: collateral can move only along pre-agreed paths such as repayment, liquidation or refund, and Firefish, acting as price and payment oracle, adds the final signature. The borrower’s key signs once and is then discarded; lenders hold none. Holding a MiCA license, Firefish added USDT loans in Q1 2026. The design limits every party to pre-agreed outcomes rather than giving anyone free control.
10. Not all protocols maintained this architecture. In November 2025, Lava announced a shift away from DLC-based non-custodial designs toward traditional custody models. Users asked who now controlled their collateral. This pivot illustrates the tension between operational simplicity and the security guarantees inherent in self-custodial escrow mechanisms.
11. Three specific factors determine the safety of any bitcoin-backed loan structure: who can move the collateral, how liquidation is triggered by oracles, and what happens to user funds if the lender disappears. In a robust 3-of-3 design, no single entity has unilateral control. An oracle cannot take the collateral directly, but a false price can trigger a wrongful liquidation.
12. Open a block explorer and inspect a transaction involving a multisignature output. Identify the script requirements for spending that UTXO. Note how many signatures are needed and which parties control them. This concrete inspection reveals whether a lending protocol genuinely distributes key management or concentrates it in a single custodial entity, providing direct evidence of the collateral’s security posture.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• T. Dryja, 'Discreet Log Contracts' (June 2017)
• Scaling Bitcoin 2017 presentation by T. Dryja (November 2017)
• DLC specifications, github.com/discreetlogcontracts
• DLC specifications (github.com/discreetlogcontracts)
• Firefish Q1 2026 update
• Blockspace reporting on Lava (2025)
• Celsius bankruptcy reporting (2022)