How Bitcoin Bridges Work: SPV Light Clients Explained

An Ethereum smart contract can't see Bitcoin. It can't open a socket to a Bitcoin node, read the mempool, or query a block explorer. Even so, some contracts mint tokens only after confirming that a particular Bitcoin transaction exists, with no custodian vouching for it. How?

Knowing how bitcoin bridges work mostly comes down to one question: who tells the destination chain that BTC was locked? Custodial bridges answer "a company" or "a multi-sig committee." Trustless bridges answer "Bitcoin itself": a light client contract checks Bitcoin's proof-of-work on 80-byte block headers, then checks a Merkle proof showing the deposit is inside one of those blocks. The short version: an SPV bitcoin bridge swaps trust in people for trust in accumulated hashpower. It works well for minting. Redemption is harder, and that's the part to scrutinize in any bridge you use.

Key Takeaways:A trustless Bitcoin bridge runs a Bitcoin light client inside a smart contract that stores 80-byte block headers and checks their proof-of-work, as described in a16z's light client primer.A Merkle proof shows a Bitcoin transaction is in a block using about log₂(n) hashes, so a block with 3,000 transactions needs only 12 sibling hashes (384 bytes).Fooling an SPV client takes roughly half of current Bitcoin hashpower, which makes SPV security economic, not absolute.Verifying Bitcoin headers on the EVM is cheap compared with proof-of-stake chains, because SHA-256 is an EVM precompile while one Cosmos header costs about 64 million gas, according to the zkBridge paper.SPV makes minting trustless, but Bitcoin Script can't enforce what happens on another chain, so redemption needs economic guarantees such as slashable collateral.

Table of Contents

• Why Can't BTC Just Move to Another Chain?
• How Does an SPV Bitcoin Bridge Verify Block Headers?
• How Do Merkle Proofs Prove a Deposit?
• Who Relays Headers, and What Stops Them Lying?
• The Full Peg-In and Peg-Out Flow
• Trustless Bitcoin Bridge Trust Models Compared
• Worked Example: What It Costs to Prove a 0.1 BTC Deposit
• Attack Vectors Against Bitcoin Light Client Bridges
• How to Evaluate a Trustless Bitcoin Bridge
• Frequently Asked Questions
• Next Steps
• Conclusion

Why Can't BTC Just Move to Another Chain?

BTC can't leave Bitcoin. Every bridge locks BTC on Bitcoin and creates a claim on it somewhere else. A UTXO (unspent transaction output) only exists in Bitcoin's ledger. What a bridge actually builds is a lock-and-mint system: BTC is locked under some spending condition on Bitcoin, and a matching token is minted on the destination chain.

That leaves two engineering problems:

1. The oracle problem (peg-in): how does the destination chain learn that the lock happened?
2. The custody problem (peg-out): who controls the locked BTC, and what makes them release it when the token is burned?

Custodial wrapping answers both with an institution. WBTC relies on a custodian to attest to deposits and hold the coins, and cbBTC relies on Coinbase. As Mt Pelerin points out, a wrapped token is only as good as the locked collateral and the bridge's ability to redeem it. For a deeper look at that gap, see WBTC Bridge Custody Risk vs Trustless Bitcoin Bridges in 2026.

Trustless bridges solve problem #1 cryptographically. As NUFI's bridging explainer puts it, they implement light clients so a chain can verify another chain's state on its own. Problem #2 is where designs split, and we'll return to it.

How Does an SPV Bitcoin Bridge Verify Block Headers?

An SPV bitcoin bridge stores Bitcoin block headers in a contract and accepts each new one only if it extends a known header and meets the proof-of-work target. SPV (Simplified Payment Verification) comes from Section 8 of the Bitcoin whitepaper. The idea is that you can check a payment without a full node if you keep the chain of headers and ask for proof that a transaction is in one of those blocks.

Anatomy of the 80-byte header

Every Bitcoin block header has exactly six fields, per the Bitcoin developer reference:

The four checks a header must pass

1. Linkage: hashPrevBlock points to a stored header.
2. Proof-of-work: SHA256(SHA256(header)), read as a little-endian 256-bit integer, must be ≤ the target decoded from nBits.
3. Difficulty correctness: nBits stays the same within a 2,016-block epoch. At each epoch boundary the contract recomputes it as old target × actual timespan ÷ 1,209,600 seconds, with the change capped at 4× either way. Without this check, a relayer could submit a valid-looking header mined at trivial difficulty.
4. Fork choice: the contract adds up each header's work (≈ 2²⁵⁶ ÷ (target+1)) and treats the branch with the most cumulative work as canonical. Longest chain is the wrong rule here.

The contract never checks transaction validity, scripts, or the 21 million supply cap. The Nervos light-client guide spells out the assumption SPV makes: the most-work chain is the valid chain.

That assumption is acceptable because, per a16z, building a fake heavier chain takes close to half the network's current hashpower.

How Do Merkle Proofs Prove a Deposit?

A Merkle proof is the short list of sibling hashes needed to rebuild a block's Merkle root from one transaction ID. If the rebuilt root matches the hashMerkleRoot in a stored header, the transaction is in that block.

Bitcoin builds the tree by double-SHA-256 hashing each transaction's txid, pairing neighbors, hashing each pair, and repeating until one root is left. A level with an odd number of nodes duplicates its last node. To verify, the contract needs:

• The raw transaction, which it hashes to get the txid and parses for outputs.
• The transaction's index in the block, whose bits tell the contract whether each sibling goes on the left or the right.
• The sibling hashes, ⌈log₂(n)⌉ of them for a block with n transactions.

One detail developers often miss: the header commits to txids, which are the non-witness serialization. SegWit witness data is committed separately in the coinbase under BIP141. A bridge only needs to read outputs (amount, scriptPubKey, OP_RETURN data), and those sit in the non-witness part. So the txid tree is enough, and the bridge never handles witnesses.

When the proof checks out, the contract parses the transaction and confirms three things:

• An output pays the bridge's deposit address.
• The amount is correct.
• An OP_RETURN output (or the address itself) encodes the destination-chain recipient.

That last check ties a Bitcoin payment to a specific EVM address without any off-chain matching.

Who Relays Headers, and What Stops Them Lying?

Anyone can relay headers. A relayer can't lie because the contract re-checks every header's proof-of-work itself. The relayer is a courier, not a trusted oracle. ChainSafe's bridge overview notes that if the light client is initialized correctly, invalid headers are rejected on-chain and relay messages don't even need signatures.

Three design issues still matter.

1. Initialization (the checkpoint problem)

The contract can't verify back to genesis economically, so it's deployed with a trusted checkpoint header, usually an epoch boundary well behind the tip. That checkpoint is the one manual trust assumption. Auditors should confirm it's a real mainnet block hash.

2. Liveness

Honest relaying is free to verify but not free to submit. ChainSafe flags that many designs pay nothing for relaying headers, which raises the risk of the light client stalling. Better designs make relaying a paid role, so the client keeps up with Bitcoin's ~144 blocks per day.

3. Confirmation depth

A header at the tip can be reorged away. Bridges typically wait until the deposit's block has k headers stacked on it before minting. The depth varies by bridge, and Bitcoin's own convention of six confirmations (roughly an hour) is a common reference point.

k should grow with the value at risk. Six confirmations protects a small deposit comfortably. For a single nine-figure mint, the economics of renting hashpower look very different.

The Full Peg-In and Peg-Out Flow

Peg-in is fully verifiable with SPV. Peg-out isn't, because Bitcoin Script can't read Ethereum. This asymmetry matters more than anything else about Bitcoin light client bridges.

Peg-in (BTC → destination chain)

1. The user sends BTC to the bridge's deposit address, with the destination address and any swap instruction in an OP_RETURN.
2. Miners include the transaction. Relayers submit the block header and the headers after it.
3. Someone (the user, or a service on their behalf) submits the raw transaction plus Merkle proof to the light client contract.
4. The contract checks the proof against the stored header, confirms depth ≥ k, and checks that the txid hasn't been used before (replay protection).
5. The contract mints the wrapped BTC, or mints and routes it straight through a DEX swap.

Peg-out (destination chain → BTC)

1. The user burns the wrapped token and names a Bitcoin address.
2. Whoever controls the locked BTC must broadcast a Bitcoin payment to that address.
3. That payment is proven back to the contract with an SPV proof, and the request is marked fulfilled.
4. If no valid proof arrives before a deadline, the contract penalizes the operator, typically by slashing collateral to compensate the user.

Step 2 is the weak point. No smart contract can force a Bitcoin key to sign. So every Bitcoin bridge, "trustless" or not, has some party holding Bitcoin-side keys. SPV can't remove that party. What it can do is make that party's misbehavior provable on-chain, which lets collateral and slashing back it up.

TeleSwap is built this way. A light-client bridge verifies every Bitcoin deposit before minting TeleBTC, a 1:1 collateral-backed representation of BTC. Collateral-backed, slashable Lockers handle custody. Relayers keep headers flowing, and Teleporters cover destination-chain gas so users pay fees in Bitcoin assets. TeleSwap has processed 562,388 bridge transactions and $530.8M in total volume across 13 supported networks, according to TeleSwap network stats. Full mechanics are in the TeleSwap docs.

Trustless Bitcoin Bridge Trust Models Compared

Bitcoin bridges differ mainly in who attests to deposits and who controls the BTC. The Grid tracks 21 Bitcoin bridge projects (updated October 23, 2026). Many of them fit one of five models:

The distinction to take away: in custodial models, a fake deposit can be minted if the attester is compromised. In SPV models it can't, because nothing is minted without a verified Bitcoin transaction. What's left to trust is redemption, and that should be backed by collateral you can inspect.

Worked Example: What It Costs to Prove a 0.1 BTC Deposit

In this illustrative estimate, proving one Bitcoin deposit on an EVM chain costs on the order of 100,000 gas, not millions. The figures below are rough estimates from stated assumptions, not measurements of any specific bridge, and gas schedules can change.

Assumptions: a 0.1 BTC deposit, a 250-byte transaction, a block with 3,000 transactions, and Ethereum gas rules (16 gas per non-zero calldata byte; SHA-256 precompile at 60 + 12 gas per 32-byte word, per evm.codes).

The cryptography costs under 10% of that. Most of the gas goes to state writes and token logic. Header relay is a separate, shared cost: roughly 144 headers a day, amortized across every user of the bridge that day.

Compare the zkBridge paper's figure: about 64 million gas (around $6,300 when it was written) to verify a single Cosmos header on Ethereum, because ed25519 signature checks have no precompile. Many people assume Bitcoin is the hardest chain to light-client because it's the oldest. In practice, proof-of-work over SHA-256 is one of the cheapest consensus mechanisms to verify inside the EVM.

For the user, the Bitcoin-side cost is a normal Bitcoin network fee, which varies with mempool conditions. Bridge time depends mostly on confirmation depth. Fast swaps on TeleSwap settle in about 10 minutes.

Attack Vectors Against Bitcoin Light Client Bridges

Light client bridges are more likely to be exploited through implementation shortcuts than through 51% attacks. Past losses in the bridge category, catalogued in Biggest Crypto Bridge Hacks: What Went Wrong (2026), are a useful reminder. These are the bugs worth checking in an audit.

• Missing difficulty checks: if the contract only checks that hash ≤ nBits target and never checks that nBits is correct, an attacker can mine low-difficulty headers on a laptop. Retarget logic is required.
• 64-byte transaction ambiguity: a 64-byte transaction serializes to the same length as an inner Merkle node (two 32-byte hashes), so a crafted proof can pass off an inner node as a "transaction." Sergio Demian Lerner documented this in his 2018 leaf-node weakness write-up. The fix is to reject 64-byte transactions or require a matching coinbase proof depth.
• Duplicate-node trees: because Bitcoin duplicates the last node on odd levels, some different transaction lists produce the same root (CVE-2012-2459). Proof verifiers should check that the index is in range.
• Replay: each txid (or txid + output index) must be marked spent after minting.
• Shallow confirmations: minting at depth 1–2 leaves the bridge exposed to ordinary reorgs.
• Peg-out collateral shortfall: if the operator's collateral loses value against BTC, slashing may not cover a default. Collateral ratios and liquidation rules are where the real economic risk sits.

Off-chain risks still apply. AirdropAlert warns about cloned bridge sites bought as search ads. Type the URL yourself.

How to Evaluate a Trustless Bitcoin Bridge

To see whether a bridge is actually trust-minimized, follow both the mint path and the redeem path. Use this five-step check:

1. Find the mint condition. Does the contract mint only after an on-chain SPV proof, or after a signature from a committee? Read the mint function, not the marketing page.
2. Check the header logic. Look for retargeting, cumulative-work fork choice, and a documented checkpoint.
3. Check confirmation depth. Is k fixed or scaled to value? Is it published?
4. Trace redemption. Who holds the Bitcoin keys? What collateral backs them, in what asset, at what ratio, and can a default be proven and slashed without a vote?
5. Check liveness incentives. Are relayers paid? A light client that falls behind freezes deposits even when the cryptography is sound.

To see the peg-in flow from the user's side, look at a route into a stablecoin such as BTC to USDC on Ethereum or into another wrapped BTC such as BTC to cbBTC. For a step-by-step walkthrough, see Trustless BTC Swap: 7-Step No-KYC Guide (2026).

Frequently Asked Questions

Is an SPV Bitcoin bridge completely trustless?

No. SPV makes deposit verification trustless, but redemption still depends on whoever holds the Bitcoin-side keys. Bitcoin Script can't check events on other chains, so peg-out relies on economic enforcement such as slashable collateral. The best designs make any operator default provable on-chain, which limits trust to whether the collateral is enough.

How many Bitcoin confirmations does a bridge need?

It varies by bridge. Six confirmations, about an hour, is a common reference point, and designs may require more or fewer. Each block adds roughly 10 minutes of expected proof-of-work on top of the deposit. Ideally the depth grows with the value being minted, since reorg attacks become more profitable as more value is at stake.

What is the difference between an SPV bridge and a zk bridge?

An SPV bridge verifies each header directly on-chain, while a zk bridge verifies a succinct proof that many headers are valid. For Bitcoin, direct verification is already cheap because SHA-256 is an EVM precompile. Zero-knowledge proofs matter more for chains with expensive signature schemes, such as Cosmos, where one header can cost about 64 million gas.

Does Bitcoin need a soft fork to support trustless bridges?

No. SPV bridges work today because the light client runs on the destination chain, not on Bitcoin. Proposed opcodes such as covenants could someday let Bitcoin enforce peg-out conditions directly, which would reduce reliance on collateral. Current designs don't need them.

Can a relayer submit fake Bitcoin blocks to a bridge?

Not successfully, if the contract is implemented correctly. The contract checks each header's double-SHA-256 proof-of-work, its link to the previous header, and its difficulty target. A fake header would need real mining work at full network difficulty.

Next Steps

• Read Garden Finance vs TeleSwap: BTC Bridge Comparison 2026 for fee and liquidity data across bridge designs.
• Read Atomic Swaps Explained: How HTLCs Settle Cross-Chain Trades for a non-bridge approach to cross-chain BTC settlement.
• Read Convert BTC to WBTC on Ethereum: 2026 Wallet Guide to see the custodial wrapping path in practice.

Conclusion

How Bitcoin bridges work comes down to two proofs and one guarantee. The header proof shows a block carries real proof-of-work. The Merkle proof shows your transaction is in that block. The redemption guarantee is where SPV stops and collateral takes over, and it's what decides whether you can get your BTC back.

When you assess any bridge, read the mint function and trace the peg-out path. SPV-based designs remove fake deposits as a risk. Collateral and slashing handle the rest. To see a light-client bridge in production, start a swap at teleswap.xyz, or read the verification details in the docs.