Bitcoin-native finance without bridges

Wonder

1. How can a financial contract settle in native satoshis without introducing a new token or chain?
2. What specific trust assumptions are introduced when using an oracle for price data versus verifying it locally?
3. Why is the ability to unilaterally exit back to the base layer considered the primary safety metric for Bitcoin-native finance?

Explore

1. Discreet Log Contracts, proposed by T. Dryja in 2017, enable financial contracts on bitcoin using only native coins. Both parties lock funds in a 2-of-2 multisig output and pre-sign one payout transaction per possible outcome, each made spendable by an adaptor signature that completes only with the oracle’s signature on that outcome. The oracle publishes its attestation without knowing the contract exists. When it attests, the matching payout becomes valid; if it fails or misbehaves, a timelock allows participants to reclaim their capital after a set period. This design avoids wrapping Bitcoin into another chain’s token but introduces a critical dependency: the user must trust the oracle not to sign maliciously and that the network will enforce the timelock.
2. Multisig and timelock structures facilitate lending protocols where the borrower retains custody of their keys while collateral is locked. In these designs, the lender holds one key and the borrower another; a third-party or script-based mechanism handles liquidation if collateral drops below a threshold. Unlike wrapped assets that require a custodian to mint tokens on another chain, this approach keeps all value within Bitcoin’s UTXO model. The trade-off is complexity in key management and the risk of bugs in the software that builds and signs these transactions.
3. Lightning Network channels allow off-chain payment streams that settle back to the base layer only when closed. This reduces congestion and fees for high-frequency transactions while maintaining Bitcoin’s finality guarantees. Ark lets many users share one on-chain output coordinated by an operator; each user holds a pre-signed path to exit to the chain alone if the operator disappears. The safety of these systems relies entirely on the underlying chain’s consensus; no new validator set is introduced, preserving the decentralized security model established in earlier lessons.
4. BitVM-style designs aim to verify arbitrary computation without modifying Bitcoin’s consensus rules. BitVM (Robin Linus, 2023) is optimistic: a prover claims a result off-chain, and if anyone challenges it, a dispute played out in bitcoin Script pins down a single wrong step and penalises the prover. Its main use is bridges whose safety needs only one honest verifier among many, rather than a trusted federation. It represents a significant shift from general-purpose Turing-complete chains toward selective, verifiable computation.
5. Each of these mechanisms introduces distinct trust assumptions that must be evaluated against Bitcoin’s core properties. Oracles require trust in external data feeds; multisig contracts require trust in code correctness and key management; state channels require trust in dispute resolution mechanisms. The common thread is the preservation of self-custody: users can always exit to native satoshis without permission from a foundation or admin key. This contrasts sharply with wrapped assets, where exiting requires bridging back through trusted intermediaries, reintroducing counterparty risk that native designs avoid.
6. Read the transaction structure in the DLC specifications (dlcspecs): a funding transaction with a 2-of-2 multisig output, one pre-signed execution transaction per outcome, and a refund transaction locked until a set time in case the oracle never attests. Mark which part each party, the oracle and the chain is trusted for.

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' (2017)
• R. Linus, 'BitVM: Compute Anything on Bitcoin' (2023); Discreet Log Contract specifications (github.com/discreetlogcontracts/dlcspecs)
• Lightning Network Whitepaper: J. Poon & T. Dryja (2015/2016)