Bitcoin Escrow
Mechanisms

karliatto · freedomtechsummit.com · Prague 2026

> What is an escrow?

Value held by a neutral mechanism until agreed conditions are met — then released to the right party.
Historically a person. Today, increasingly, just code.

> A concrete example

Bob is selling his house to Alice. Carol holds Alice's BTC and Bob's deed until both sides fulfil their obligations — then releases each to the right party.

> Outside Bitcoin: escrow = pay a licensed gatekeeper

// the fiat escrow stack buyer │ ▼ [ bank | law firm | title co ] │ regulated, licensed, │ bonded, audited ▼ seller cost: % fee + days/weeks trust: institution + courts

> Bitcoin's escrow evolution

Three distinct models — each one reduces trust a step further.

01 · Custodial trust

A person or platform holds the funds and decides. Reintroduces the trusted third party Bitcoin was built to remove.

Silk Road · Web of Trust

02 · Multisig escrow

m-of-n address — classically 2-of-3. No single key moves the funds. Bitcoin's first non-custodial escrow primitive.

P2SH · 2012

03 · Protocol-native escrow

Release conditions enforced by Script or Layer 2 itself — HTLCs, DLCs, shared-UTXO. Escrow stops being a service.

Atomic · trust-minimized

> Before cryptography: Bitcoin's first "escrows" were just trust again

Silk Road — 2011

Buyers sent BTC into Silk Road's internal "bank." The platform held funds, released on confirmation, and kept an 8–15% cut.

Pure custodial trust — the very thing Bitcoin was meant to make obsolete.

> 2012: the first native escrow primitive

2011

BIP 11 — OP_CHECKMULTISIG defines standard m-of-n transactions.

2012

BIP 16 / 17 — P2SH, proposed by Gavin Andresen, activates weeks later. The "3..." address is born.

since

Multisig escrow goes mainstream: 2-of-3 — buyer, seller, arbiter. No key holder can move funds alone.

// the 2-of-3 guarantee buyer + seller agree → funds move. happy path — arbiter not even needed buyer + arbiter agree → funds move. dispute resolved for the buyer seller + arbiter agree → funds move. dispute resolved for the seller but no single party, ever → can move funds alone. arbiter included.

> HTLCs — two spending paths, one script

script.btc

OP_IF
    OP_SHA256 <hash-of-secret> OP_EQUALVERIFY
    <recipient pubkey> OP_CHECKSIG          // hashlock: reveal secret → claim
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <sender pubkey> OP_CHECKSIG             // timelock: silence → refund
OP_ENDIF

Hashlock path

Recipient claims only by revealing the preimage. Revealing it on one hop hands the key to claim every linked hop too.

Timelock path

No reveal before <timeout> → sender reclaims. A built-in refund, enforced by the chain itself.

Powers Lightning routing (one hash, every hop settles atomically — all or nothing) and submarine swaps like Boltz (on-chain + Lightning HTLC, same hash, complete or revert together).

> Discreet Log Contracts — Tadge Dryja's answer, 2018

DLCs

Contract protocol
2 or more parties agree on exchange money
dependent on the outcome of an event
the oracle publishes commitments to the outcome of the event
The oracle does not need to know anything about the contract

> The oracle problem — Script can't see the outside world

Bitcoin's scripting language is deliberately small — predictable, auditable, hard to break. That restraint draws a hard line around what a contract can ever know.

Script can

Verify signatures
Enforce timelocks
Check a hash preimage

Script cannot

Know an asset's price
Know a sports score
Know an election result

> DLCs — how the contract actually settles

An on-chain transaction → locking the contract collateral in an output that can only be spent by mutual consent. Before event → the oracle advertises a public nonce that will be used to later produce a signature Oracle Public key → The public key used for signing must also be known in advance Once the event has occurred → an oracle releases a signed message over the event outcome using the previously advertised nonce (and public key).

Important detail: signatures can be used without an explicit request from the contract participants

>Pre-signed PSBTs

Payer pre-signs: payer_happy (0), payer_dispute (1), payer_cancel (2)
Payee pre-signs: payee_happy (0), payee_dispute (1)
Arbiter pre-signs: arbiter_payee (0), arbiter_payer (1)

>Pre-signed PSBTs - The escrow address = a Taproot tree with 4 leaves

Leaf	Script (miniscript)	Who must sign	Condition
Happy path	`and(pk(payer_happy), pk(payee_happy))`	Payer + Payee	mutual agreement
Dispute, payee wins	`and(pk(payee_dispute), pk(arbiter_payee))`	Payee + Arbiter	—
Dispute, payer wins	`and(pk(payer_dispute), pk(arbiter_payer))`	Payer + Arbiter	refund
Cancellation	`and(pk(payer_cancel), older(timelock))`	Payer only	only after timelock blocks

>Pre-signed PSBTs - Lifetime cycle

Happy path

Payer and payee agree the deal is complete
They co-sign the happy-path PSBT (2-of-2)
No arbiter, no timelock
This is the common case and is placed at the cheapest leaf

Non-happy paths

Dispute – payee wins: the parties disagree, the arbiter rules for the payee. Payee + arbiter co-sign. Funds go to the payee's chosen destination.
Dispute – payer wins (refund): arbiter rules for the payer. Payer + arbiter co-sign. Funds are refunded.
Cancellation (timeout safety valve): if nothing gets resolved, the payer can unilaterally reclaim funds, but only after the relative timelock.

> Lightning Hodl invoices — escrow with a ticking clock

Best for small amounts, short windows. Mostro builds its decentralized P2P exchange on exactly this — hold invoices + Nostr messaging, no accounts, no KYC.

Hold invoices are LN invoices where the receiver doesn't immediately release the preimage upon receiving a payment. Instead, the receiver performs some action and then either accepts the payment, explicitly rejects it, or lets it time out.

Every block the HTLC stays locked ties up liquidity for every hop on the route — and edges closer to a costly on-chain force-close.

> Lightning Hodl invoices — how they work

Bolt11 normal flow

The receiver generates a random preimage and computes its hash (payment hash)
The receiver creates an invoice containing this payment hash
The sender routes an HTLC locked to this hash through the network
When the HTLC reaches the receiver, they reveal the preimage
The preimage propagates back, settling the payment at each hop

Hodl invoices

The receiver generates a random preimage and computes its hash (payment hash)
The receiver creates an invoice containing this payment hash
The sender routes an HTLC locked to this hash through the network
~~When the HTLC reaches the receiver, they reveal the preimage~~
Stop until the conditions are met to reveal the preimage
The preimage propagates back, settling the payment at each hop

>Beyond - Ark and others

TBD

> Where this runs in production today

P2P fiat ↔ BTC

Hodl Hodl · Bisq (2-of-3) · Mostro (hold invoices + Nostr)

Cross-layer swaps

Boltz submarine swaps — linked HTLCs, on-chain ↔ Lightning, same hash: complete together or revert together

BTC-backed lending

Firefish — 3-of-3 escrow, pre-signed recovery paths

Conditional contracts

DLCs — multisig + oracle attestation as escrow for outcome-based payouts: prediction markets, hedges, synthetic loans

Commerce

Silk Road's custodial "bank" — the trusted-third-party model everything since has been built to replace

From a "bank" you had to trust
to math you can verify

karliatto@freedomtechsummit:~

Thank You

Bitcoin EscrowMechanisms