BIP-110 Bitcoin Protocol: How It Changes DeFi Bridges

On July 12, 2026, a soft fork activation deadline passed with miner support at exactly zero percent — and that near-miss exposed something critical about how Bitcoin protocol governance changes can break cross-chain infrastructure without a single transaction being malformed. BIP-110 is a proposed Bitcoin protocol change that would restrict large data payloads embedded in transactions, targeting non-monetary uses of the blockchain. It is a live stress test of whether arbitrary data restrictions on Bitcoin can co-exist with the bridge protocols that move billions in Bitcoin liquidity into DeFi.

This article breaks down the cryptographic mechanisms, activation architecture, and specific on-chain data structures that BIP-110 would constrain — and traces exactly where those constraints collide with the transaction patterns DeFi bridges depend on.

Key Takeaways:BIP-110 proposes restricting large witness data blobs and OP_RETURN outputs on Bitcoin, targeting non-monetary data embedding. The enforcement fallback, where nodes unilaterally reject non-compliant blocks if miners don't hit a 55% signaling threshold, creates direct chain-split risk.As of July 12, 2026, actual miner support for BIP-110 stood at approximately 0%. According to CoinDesk, no major mining pool signaled readiness, meaning the unilateral node enforcement path became the only activation vector.Bitcoin Core v30 unilaterally removed the 83-byte OP_RETURN cap in April 2025. BIP-110 seeks to reimpose restrictions as a consensus rule, creating a direct conflict between two major implementation camps in the bitcoin governance debate 2026.Bridge protocols that embed transaction verification data in SegWit witness fields or OP_RETURN outputs face potential transaction invalidation under BIP-110 enforcement rules. SPV proof-based systems are particularly exposed to consensus-layer rejection.TeleSwap's SPV light-client bridge has processed over $420.3M in total volume across 424,685 transactions. Per TeleSwap network stats, Bitcoin bridge security architecture is directly relevant to real user exposure in a contested fork scenario.

Table of Contents

• What Is BIP-110? The "Reduced Data Temporary Softfork" Explained
• The Cryptographic Mechanisms BIP-110 Targets
• Activation Architecture: Why 55% Is the Danger Number
• How BIP-110 Affects DeFi Bridges at the Protocol Level
• The Bitcoin Governance Debate 2026: Stakeholder Map
• Bridge Protocol Risk Exposure: A Technical Comparison
• What Comes Next for Bitcoin Protocol Governance
• Frequently Asked Questions

What Is BIP-110? The "Reduced Data Temporary Softfork" Explained

BIP-110 was formally introduced on December 3, 2025 by pseudonymous developer Dathon Ohm, with authorship subsequently disputed — SimpleMining.io reports that Greg Maxwell alleges Ocean Mining actually drafted the proposal, a claim Ocean Mining denies. The dispute itself is instructive: it signals how fractured the Bitcoin development community has become around the question of what data belongs on the Bitcoin blockchain.

The formal specification classifies BIP-110 as a Standards Track Bitcoin Improvement Proposal targeting three categories of on-chain data:

• Large witness data blobs embedded in SegWit (Segregated Witness) transaction inputs
• OP_RETURN outputs exceeding size thresholds (previously capped at 83 bytes in pre-v30 Bitcoin Core)
• Taproot script paths used to embed arbitrary non-monetary data via the Tapscript execution environment

The stated goal is eliminating what proponents call "blockchain spam" — data inscriptions, token protocol metadata, and arbitrary byte payloads that have no direct function in UTXO (Unspent Transaction Output) transfers. Critics contest that labeling is itself a governance position, not a technical fact.

The Cryptographic Mechanisms BIP-110 Targets

To understand how BIP-110 affects DeFi bridges, you need a precise picture of the mechanisms it restricts. These are not abstract policy categories — they are specific transaction fields that bridge protocols actively use for cross-chain coordination.

SegWit Witness Data and the Witness Discount

SegWit (activated in August 2017 via BIP-141) moved cryptographic signature data out of the transaction's base data field into a separate "witness" structure. Witness bytes are discounted in weight calculation — 1 witness byte = 1 weight unit, vs. 4 weight units for a base transaction byte. This discount made it economically attractive to embed large payloads in the witness field, since they cost roughly 75% less in fee-per-byte terms than equivalent base data.

BIP-110 proposes to restrict witness blob size beyond signature-necessary data. The practical mechanism: a new consensus rule that counts witness bytes above a threshold toward block weight at the non-discounted 4:1 ratio, making large witness payloads prohibitively expensive and eventually excluding them from valid blocks under BIP-110-enforcing nodes.

What lives in those witness fields for bridge protocols? SPV (Simplified Payment Verification) proofs. An SPV proof is a Merkle branch cryptographic path from a specific Bitcoin transaction up through the block's transaction Merkle tree to the block header. Bridge light clients on destination chains (Ethereum, BNB Chain, etc.) verify these proofs to confirm that a Bitcoin deposit transaction is real without running a full Bitcoin node. SPV proofs for a single block can run several kilobytes depending on Merkle depth, placing them directly in BIP-110's target range.

OP_RETURN: The Standard Data Carrier Output

OP_RETURN is a Bitcoin script opcode that marks an output as provably unspendable. It's the sanctioned method for embedding arbitrary metadata in Bitcoin transactions without bloating the UTXO set (since OP_RETURN outputs are prunable — they never enter the spendable coin database). The previous standard cap was 83 bytes: 1 byte for the OP_RETURN opcode, 1 byte for the data push, and 80 bytes of payload.

Bitcoin Core v30, released following an April 2025 pull request, unilaterally removed this 83-byte cap from the default relay policy. This was a non-consensus change (nodes can still reject oversized OP_RETURNs via configuration), but it effectively opened the door to kilobyte-scale OP_RETURN payloads propagating across the default mempool. BIP-110 explicitly seeks to reimpose the restriction — now as a consensus rule rather than just a relay policy, which is a materially different enforcement level.

For bridges: cross-chain messaging protocols frequently use OP_RETURN fields to embed destination chain addresses, swap parameters, and nonce data. A bridge deposit transaction might encode: OP_RETURN [destination_chain_id][recipient_address][slippage_bps][nonce]. Even compact encodings of a 20-byte EVM address plus metadata approach or exceed the historical 80-byte payload limit.

Taproot and the Script Path Spending Problem

Taproot (BIP-341, activated November 2021) introduced MAST (Merkelized Abstract Syntax Trees) via a Tapscript execution framework. A Taproot output commits to a key-path spend (simple single-key signature) and optionally a script tree — a Merkle tree of possible spending scripts. When spending via the script path, the entire script and its witnesses are revealed on-chain.

BIP-110 would impose restrictions on Tapscript witness size, targeting the pattern of using script path reveals as data publication mechanisms. Some newer bridge designs use Taproot commitments to encode cross-chain state, relying on the spend-time data reveal as a form of on-chain proof publication. BIP-110 could invalidate those transaction patterns at the consensus layer.

Activation Architecture: Why 55% Is the Danger Number

This is where BIP-110 diverges most sharply from historical Bitcoin protocol changes — and where the chain-split risk becomes concrete.

Historical Bitcoin soft forks have used BIP-9 or BIP-8 activation mechanisms requiring a signaling threshold of 95% of blocks within a retarget period (roughly two weeks) to trigger lock-in. The rationale: near-unanimous miner consensus ensures economic majority support before any enforcement begins, minimizing the risk that significant hashpower mines a chain that enforcing nodes reject.

BIP-110 proposes a 55% miner signaling threshold. That is not a minor adjustment — it's a structural inversion of the safety model. Here's the activation flow:

1. Signaling Period: Miners signal BIP-110 readiness by setting a specific version bit in block headers.
2. Threshold Check: If ≥55% of blocks in a retarget window signal readiness, the soft fork activates normally — enforcing nodes begin rejecting non-compliant transactions.
3. Fallback Enforcement (the critical path): If miners fail to reach 55% by the activation deadline, BIP-110 nodes do not simply fail to activate. Instead, they unilaterally begin rejecting blocks containing restricted data — regardless of miner signaling.

That fallback is the mechanism that concerned analysts most. Under standard soft fork logic, non-signaling miners produce blocks that enforcing nodes would eventually reject if the threshold is met — but the economic majority of miners determines which chain accumulates the most proof-of-work, and therefore which chain economically survives. BIP-110's fallback inverts this: a minority of enforcement nodes could reject blocks mined by the overwhelming hashpower majority, creating two competing chain tips.

As HTX Insights documents, the risk profile is binary: enforcement nodes above 50% of economic validation but below economic majority creates conditions where neither chain has clear finality. Bridge protocols that assume Bitcoin transaction finality after N confirmations face the scenario where "confirmed" transactions on one chain tip are invalid on another.

As of July 12, 2026, per CoinDesk, actual miner support remained at approximately zero percent. No major mining pool signaled. This means only the fallback enforcement path was live — the most dangerous activation vector, with the least economic support.

Node adoption tells a similar story: Bitcoin Knots (the alternative implementation that supports BIP-110 enforcement) peaked at approximately 5,300 nodes and had declined to around 5,100 by February 2026, representing roughly 5% of reachable nodes. BIP-110-running nodes crossed 2% of the network, according to CoinTelegraph — meaningful, but nowhere near a threshold that could enforce a chain split with any economic weight.

How BIP-110 Affects DeFi Bridges at the Protocol Level

Let's trace a specific bridge transaction flow and identify exactly where BIP-110 restrictions would engage.

Standard SPV Bridge Deposit Flow (Pre-BIP-110)

A user deposits BTC to a bridge by sending to a monitored Bitcoin address. The bridge then needs to prove to a smart contract on the destination chain (say, an EVM network) that this Bitcoin transaction genuinely occurred and reached sufficient confirmation depth. The proof mechanism — SPV — works as follows:

1. User broadcasts a Bitcoin transaction locking BTC to a bridge address. The transaction is mined into block N.
2. A relayer collects the transaction's raw hex, the Merkle branch connecting it to the block's txid Merkle root, the block header (containing that Merkle root), and a chain of subsequent block headers proving confirmations.
3. The relayer submits this proof bundle to the destination chain smart contract. The contract's light client verifies: (a) the block header chain is valid by checking proof-of-work on each header, (b) the transaction is in the Merkle tree by recomputing the path, (c) the transaction output matches the expected format.
4. On verified proof, the smart contract mints wrapped BTC (or equivalent) to the destination address.

The Merkle branch for step 2 alone — assuming a block with ~3,000 transactions — requires approximately log₂(3000) ≈ 12 hash values × 32 bytes = 384 bytes. Add raw transaction bytes, block headers, and encoding overhead, and a full SPV proof submission can easily exceed 1–2 KB of data that must be published on-chain for verification.

Under a BIP-110 regime where large witness blobs are consensus-invalid, the relayer transaction that anchors this proof on the Bitcoin side faces rejection risk. More precisely: if the bridge architecture publishes any portion of the proof data back onto Bitcoin (some designs do this for trustless finality signaling), those transactions could be invalidated by BIP-110-enforcing nodes.

OP_RETURN Bridge Encoding: The Immediate Impact

The more immediate and universal impact involves OP_RETURN. Consider a standard bridge deposit instruction.

A user sends BTC and encodes their destination in the transaction's OP_RETURN field:

OP_RETURN
  [4 bytes]  chain_id (e.g., 0x00000001 for Ethereum mainnet)
  [20 bytes] recipient EVM address
  [32 bytes] swap_hash (keccak256 of swap parameters)
  [4 bytes]  nonce
  [8 bytes]  min_output_amount
  [4 bytes]  deadline
= 72 bytes total payload

This 72-byte payload fits within the historical 83-byte OP_RETURN limit. But if BIP-110 reimposed a tighter cap — or if a future iteration targeted even standard-size OP_RETURN outputs — the encoding breaks. Bridges that need to pass additional parameters (multi-hop route data, referral codes, slippage tiers) already push against 80 bytes in practice.

The deeper issue: if BIP-110 as implemented in enforcement nodes treats OP_RETURN outputs above any reimposed threshold as consensus-invalid, Bitcoin transactions carrying bridge deposit instructions would be rejected by those nodes — and potentially orphaned if enforcement nodes constitute any significant portion of block validation. The bridge relayer would have no way to distinguish between a legitimate deposit and a BIP-110-rejected transaction without monitoring both chain tips simultaneously.

Asset Freeze Risk: The Non-Hypothetical Scenario

The asset freeze scenario occurs when a user initiates a bridge deposit, the Bitcoin transaction is valid under Bitcoin Core v30 but invalid under BIP-110 enforcement nodes, and the transaction receives confirmations on the "permissive" chain tip while BIP-110 enforcement nodes reject it — potentially causing the wrapped tokens to be minted without backing if the chain resolves in favor of enforcement. The user initiates a bridge deposit. The Bitcoin transaction containing their deposit instruction is valid under Bitcoin Core v30 (no OP_RETURN cap) but invalid under BIP-110 enforcement nodes. The transaction propagates through part of the network, gets mined into a block by a non-BIP-110 miner, and receives confirmations on the "permissive" chain tip. The bridge relayer, monitoring that chain tip, triggers the destination chain mint.

But BIP-110 enforcement nodes never acknowledge that block as valid — from their perspective, the locking transaction never happened. The user's BTC is locked on one chain tip; their wrapped tokens are minted based on a transaction that a portion of the network deems invalid. If the chain eventually resolves in favor of BIP-110 enforcement, the locking transaction is reorganized out, and the user has minted tokens backed by nothing.

This is not a hypothetical edge case in Bitcoin network topology — chain reorganizations following contested soft fork activations have historical precedent, including during the SegWit2x period in 2017, which the Crypto Briefing governance analysis cites as the closest modern analogue to the current BIP-110 dispute.

The Bitcoin Governance Debate 2026: Stakeholder Map

The bitcoin governance debate 2026 has produced unusually clear stakeholder positions. Rather than the usual ambiguity, major figures have committed to specific, opposing technical claims:

The Saylor "iatrogenic" framing deserves elaboration: his argument is that BIP-110's enforcement mechanism — unilateral node rejection creating potential chain splits — does more damage to Bitcoin's security model and price stability than the data-embedding activity it targets. From a protocol design standpoint, that is a coherent position: Bitcoin's value proposition rests partly on settlement finality guarantees, and a contested fork breaks exactly that guarantee.

Bridge Protocol Risk Exposure: A Technical Comparison

Not all bridge architectures face identical BIP-110 exposure. The risk profile depends on what data structures the bridge reads from and writes to the Bitcoin chain.

TeleSwap's TeleBTC architecture deserves examination in this context. TeleBTC is a 1:1 BTC-backed token secured by SPV light client proofs and collateral-backed Lockers rather than a centralized custodian or multi-sig committee. The security model — where custody is collateral-backed and Lockers can be slashed for misbehavior — means the economic backstop remains intact even if the Bitcoin transaction layer faces temporary validation ambiguity. That's a meaningful design advantage over custodial wrapped BTC solutions. Non-custodial Bitcoin exchange architectures face particular pressure in contested fork scenarios because they depend on a single entity's chain-tip choice.

TeleSwap has processed over $420.3M in total bridged volume across 424,685 transactions, per TeleSwap network stats — that's real user exposure to exactly the kind of protocol-level risk BIP-110 creates.

For context on why trust-minimized bridge design matters here: in a contested fork scenario, a custodian-based wrapped BTC issuer must make a unilateral decision about which chain tip they honor — and users on the wrong tip face losses. An SPV light client bridge, by contrast, can be configured to require proof from a specific chain tip explicitly, giving users and the protocol operator a defined, auditable standard for what constitutes a valid Bitcoin deposit.

What Comes Next for Bitcoin Protocol Governance

The July 12, 2026 deadline passing with zero miner support does not mean BIP-110 is dead. Bitcoin Improvement Proposals don't expire on a deadline — they can be re-proposed, modified, or activated under different mechanisms. What the failed activation deadline does establish is a data point: the 55% threshold + unilateral enforcement model failed to attract any mining pool support.

Several trajectories are plausible from here:

• BIP-110 revision: A modified proposal with a higher signaling threshold (closer to historical 95% norms) and without the unilateral enforcement fallback might attract broader support by eliminating the chain-split risk.
• Relay policy war: Bitcoin Core v30 removed OP_RETURN caps at the relay level. Bitcoin Knots maintains them. This creates a mempool policy split even without a consensus-level change — some transactions will propagate on some nodes and not others, creating confirmation uncertainty that bridges must navigate now, not after some future activation.
• Application-layer workarounds: Bridge protocols can move deposit instruction encoding off Bitcoin entirely, using pre-image commitments in standard P2PKH/P2WPKH addresses (the bridge derives routing from the specific address used) rather than OP_RETURN payloads. This approach eliminates OP_RETURN dependency but complicates address management.

From a protocol design standpoint, the cleaner resolution — regardless of where BIP-110 lands — is for bridge architectures to minimize their dependency on Bitcoin's arbitrary data layers. Bridges that treat Bitcoin purely as a settlement layer with all coordination data living off-chain or on the destination chain face no BIP-110 exposure at all. The SPV proof verification happens on the destination chain's smart contract; the only Bitcoin-side requirement is a standard value transfer to a watched address.

That architectural shift is already underway in next-generation bridge designs, and BIP-110's disruption — even at near-zero adoption — has likely accelerated it.

Frequently Asked Questions

What is BIP-110 in simple terms?

BIP-110 is a proposed Bitcoin protocol change that would restrict large data payloads embedded in Bitcoin transactions, targeting non-monetary uses of the blockchain. Formally called the "Reduced Data Temporary Softfork," it was introduced in December 2025 and proposes consensus-level limits on witness data sizes, OP_RETURN output sizes, and Taproot script path data — the mechanisms currently used to embed arbitrary information on the Bitcoin blockchain. The proposal aims to reduce what proponents call "blockchain spam" while critics argue it harms legitimate bridge and application layer protocols.

Why did BIP-110 fail to activate by its July 2026 deadline?

BIP-110 failed to activate because miner support was approximately zero percent as of the July 12, 2026 deadline, per CoinDesk reporting. No major mining pool signaled readiness for the 55% threshold required for standard activation. This left only the unilateral node enforcement fallback path active — the most technically risky activation vector, where BIP-110-enforcing nodes would reject blocks from non-signaling miners regardless of hashpower distribution. The absence of miner support effectively ended the soft fork's viability as a consensus change.

How does BIP-110 affect DeFi bridges specifically?

BIP-110 could invalidate Bitcoin transactions that carry cross-chain bridge deposit instructions or on-chain proof data, because many bridges use OP_RETURN outputs and SegWit witness fields to encode routing information and SPV proofs. If BIP-110-enforcing nodes reject those transactions, users face asset freeze risk: their BTC could be locked on one chain tip while their wrapped tokens are minted based on a transaction another portion of the network considers invalid. This creates double-spend exposure where the same BTC is simultaneously locked and freely spendable depending on which chain tip prevails.

What is the difference between BIP-110 as a soft fork vs. hard fork?

BIP-110 is technically classified as a soft fork because it tightens existing rules — old nodes would accept blocks that new nodes accept — but critics argue it functions like a hard fork because of its enforcement fallback mechanism. In a standard soft fork, non-compliant miners simply produce blocks that enforcing nodes ignore until the threshold is met. BIP-110's fallback causes enforcing nodes to actively reject blocks from non-compliant miners even without meeting the 55% threshold, which can create a chain split — the defining risk of a hard fork. This enforcement architecture inverts the normal soft fork safety model.

What is the OP_RETURN byte limit and why does it matter for bridges?

The OP_RETURN byte limit was historically set at 83 bytes (80 bytes of payload) in Bitcoin Core, and Bitcoin Core v30 removed this cap entirely in April 2025; BIP-110 seeks to reimpose restrictions as a consensus rule rather than just relay policy. For bridges, OP_RETURN fields carry deposit routing data — destination chain ID, recipient address, swap parameters. A 20-byte EVM address alone consumes 25% of the historical payload limit, leaving little room for additional cross-chain parameters before hitting the ceiling. Bridges that require encoded metadata (swap routes, referral codes, slippage settings) already operate at the limits of legacy caps.

What is an SPV proof and why is it relevant to BIP-110?

An SPV (Simplified Payment Verification) proof is a Merkle branch cryptographic proof that a specific Bitcoin transaction was included in a specific block, allowing a smart contract on another chain to verify Bitcoin transactions without running a full node. SPV proofs are a core mechanism for trustless Bitcoin bridges — they're how light-client bridge systems like TeleBTC verify that BTC was genuinely locked before minting wrapped tokens. These proofs can be several kilobytes in size when submitted on-chain, placing them in the range of data BIP-110 would restrict in witness fields. The proofs are essential for bridge security but directly conflict with BIP-110's data restrictions.

How does TeleBTC differ from WBTC in the context of a Bitcoin fork?

TeleBTC uses SPV light-client proofs and collateral-backed custody with slashable Lockers rather than a centralized custodian, meaning the security model doesn't depend on a single entity deciding which chain tip is authoritative during a fork. In contrast, custodial wrapped BTC solutions like WBTC require the custodian to make a unilateral chain-choice during a contested fork. TeleBTC's trust-minimized architecture gives the protocol a defined, cryptographically verifiable standard for what constitutes a valid Bitcoin deposit — the specific chain tip with the valid SPV proof — rather than relying on an institutional decision. This design makes TeleBTC inherently more resilient to governance disputes and chain splits.