The opcode behind OP_IF — every place it shows up.

<witness chooses 1 or empty>
OP_IF
   <branch A — pubkey + OP_CHECKSIG>
OP_ELSE
   <branch B — different pubkey or hash check>
OP_ENDIF

The spender selects which branch executes by pushing 1 (or any truthy value) or an empty bytestring before the script runs. This is the foundational pattern; everything below is a specialization.

The single most consequential OP_IF pattern in Bitcoin's history. An HTLC says: "Either the recipient produces the preimage of a known hash and takes the funds, or after a timeout the sender can reclaim them."

OP_IF
    OP_SHA256 <H = SHA256(preimage)> OP_EQUALVERIFY
    <recipient_pubkey> OP_CHECKSIG
OP_ELSE
    <expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <sender_pubkey> OP_CHECKSIG
OP_ENDIF

Powers:

• Atomic swaps (Bitcoin ↔ Litecoin, Bitcoin Cash, etc.) — same preimage on two chains, different recipients on each side
• Submarine swaps (on-chain ↔ Lightning) — Loop, Boltz
• Pre-Lightning payment channels (Spillman, Decker–Wattenhofer)
• Cross-chain bridges that don't require federations

Every commitment transaction in every Lightning channel ever opened has one of these. Encodes "either the counterparty proves I cheated and steals everything (revocation), or I wait to_self_delay blocks and take my own money (delayed self-spend)."

OP_IF
    # Revocation: counterparty has the secret if we breached
    <revocationpubkey>
OP_ELSE
    # Honest delayed self-spend
    <to_self_delay> OP_CHECKSEQUENCEVERIFY OP_DROP
    <local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG

Witness paths:

• Revocation: push <revocation_sig> then <1> to take the OP_IF branch.
• Self-spend: push <local_delayed_sig> then <> (empty) to take OP_ELSE.

When a Lightning node forwards a payment, the outgoing-direction HTLC output has a nested OP_IF/OP_NOTIF. Three spending paths in one script.

OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG                                # Path 1: revocation
OP_ELSE
    <remote_htlcpubkey> OP_SWAP
    OP_SIZE 32 OP_EQUAL
    OP_NOTIF
        # Path 2: HTLC-timeout (we reclaim after timelock)
        OP_DROP 2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # Path 3: peer claims with preimage
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Mirror of Pattern 4 for the receiving side of a forwarded payment. Same nested-OP_IF shape with paths reversed:

OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
    OP_CHECKSIG                                # revocation
OP_ELSE
    <remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
    OP_IF
        # HTLC-success (we provide preimage)
        OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
        2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
    OP_ELSE
        # Peer reclaims after timeout
        OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
        OP_CHECKSIG
    OP_ENDIF
OP_ENDIF

Uses OP_IFDUP + OP_NOTIF (the sibling family). Anchor outputs let either party CPFP the commitment transaction without needing both signatures.

<funding_pubkey> OP_CHECKSIG OP_IFDUP
OP_NOTIF
    OP_16 OP_CHECKSEQUENCEVERIFY
OP_ENDIF

Reads as: "if you own the funding key, spend immediately; otherwise wait 16 blocks." OP_IFDUP keeps the value on the stack only when truthy — the trick that fits this in 30-something bytes.

A general two-path pattern: 2-of-3 multisig or 1-of-1 after timeout. Used by Bisq escrow, OpenBazaar, Lightning Loop, hosted-custody services with timeout fallback.

OP_IF
    # Cooperative — any 2 of {buyer, seller, arbiter}
    2 <buyer> <seller> <arbiter> 3 OP_CHECKMULTISIG
OP_ELSE
    # Buyer alone after timeout
    <expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <buyer> OP_CHECKSIG
OP_ENDIF

Proposed but not activated as of 2026. Vaults use OP_IF to express "either trigger the unvault delay path, or sweep to cold storage immediately."

OP_IF
    <unvault_template_hash> OP_CHECKTEMPLATEVERIFY OP_DROP
    <unvault_delay> OP_CSV OP_DROP
    <hot_pubkey> OP_CHECKSIG
OP_ELSE
    <cold_pubkey> OP_CHECKSIG
OP_ENDIF

Status: BIP 119 (OP_CHECKTEMPLATEVERIFY), BIP 345 (OP_VAULT), and related covenant proposals are in active discussion. None has activated.

The most surprising use of OP_IF in Bitcoin: it's the load-bearing structure of every Ordinals inscription, every BRC-20 token, every recursive inscription, every Runestone commitment that uses Tapscript-based metadata.

<inscriber_pubkey> OP_CHECKSIG
OP_FALSE
OP_IF
    OP_PUSH "ord"
    OP_PUSH 0x01
    OP_PUSH "image/png"           # MIME type
    OP_PUSH 0x00
    OP_PUSH <…content bytes…>
OP_ENDIF

The trick: OP_FALSE ensures the OP_IF branch is never executed. But the Script parser still reads the bytes inside to find the matching OP_ENDIF. So all the data pushes are syntactically present but semantically dead. The transaction signature only needs to satisfy OP_CHECKSIG at the top — the envelope is purely a witness-data carrier.

Why this works only inside Tapscript: the inscription is the script-path leaf of a Taproot output (P2TR, BIP 341/342). The witness discount means each byte costs 1 WU instead of 4 WU, making it economically viable to carry kilobytes of data. Pre-Taproot scripts have a hard 10,000-byte size limit and no witness discount.

Post-Taproot, many multipath conditions migrate from OP_IF to Taproot script-tree leaves — different leaves of the merkle tree replace different OP_IF branches, and the whole tree commitment is the merkle root. This is better than OP_IF for privacy: only the leaf actually spent gets revealed; unused branches stay hidden.

OP_IF still gets used inside individual leaves when the branching isn't worth its own leaf (e.g., a small revocation path bolted onto a single leaf).

DLCs use OP_IF only minimally — most of the conditional logic is encoded outside the script via adaptor signatures and Contract Execution Transactions (CETs). The on-chain OP_IF usage is in the refund path:

OP_IF
    <2-of-2 between Alice and Bob>
OP_ELSE
    <refund_locktime> OP_CLTV OP_DROP
    <2-of-2 same pubkeys>
OP_ENDIF

The interesting part of a DLC happens off-chain in adaptor-signature land; on-chain the script is mundane.

Pre-Lightning, Mike Hearn's Spillman channels and Jeremy Spilman's CLTV refund construction:

OP_IF
    2 <alice> <bob> 2 OP_CHECKMULTISIG
OP_ELSE
    <refund_locktime> OP_CLTV OP_DROP
    <alice> OP_CHECKSIG
OP_ENDIF

Effectively dead in practice (replaced by Lightning), but historically significant — these were the proof of concept that taught the community payment channels could work on Bitcoin without consensus changes.