Anyone can write a Bitcoin rule. Almost no one can make the network enforce it.
BIP-110 is a draft Bitcoin Improvement Proposal that would add a temporary consensus rule limiting oversized, arbitrary on-chain data, the category that carries Ordinals inscriptions, BRC-20 tokens, Runes, and large OP_RETURN payloads. As of 13 July 2026 it is a live, contested proposal in Bitcoin's official repository, not an activated rule, and miner support for it sits near zero.
I work in the crypto self-custody space. When a consensus fight like this hits the news, the question I get is rarely "who is right." It is "do I need to do anything," and for most holders the answer is no. What follows is the mechanics of the proposal and the shape of the disagreement, without picking a side.
TL;DR
BIP-110, titled Reduced Data Temporary Softfork (RDTS), is a draft soft fork that would temporarily tighten Bitcoin's rules on arbitrary on-chain data, expiring roughly a year after activation. It is a soft fork, so it tightens rules rather than breaking them, and it grandfathers UTXOs created before activation. As of mid-July 2026 miner signalling is near zero, with only low single-digit node adoption, mostly on Bitcoin Knots rather than Bitcoin Core. The realistic outcome is that it either fails to activate or splits off a small minority chain, not that it changes Bitcoin network-wide. For most holders the required action is nothing.
What BIP-110 proposes
BIP-110 targets one thing: the volume of arbitrary, non-financial data that transactions can commit to the chain. That is the data layer behind Ordinals inscriptions and the token schemes built on top of them.
| Field | Detail |
|---|---|
| Title | Reduced Data Temporary Softfork (RDTS) |
| BIP number | 110 |
| Author | Dathon Ohm (pseudonymous) |
| Type | Consensus soft fork |
| Target | Oversized and arbitrary on-chain data (Ordinals inscriptions, BRC-20, Runes, large OP_RETURN) |
| Duration | Temporary. Auto-expires roughly one year after activation |
| Scope | Grandfathers UTXOs created before activation. Applies going forward |
| Status (13 Jul 2026) | Draft in bitcoin/bips. Miner signalling near zero |
"Limit data fields" in plain terms means capping how much a transaction can stuff into the parts of a Bitcoin transaction that were designed to carry small amounts of script or metadata, not media files. Ordinals use the witness area of a Taproot spend to inscribe arbitrary content such as images and text directly onto satoshis. BIP-110 would tighten the consensus rules so transactions carrying oversized arbitrary payloads become invalid under the new ruleset, for as long as the temporary rule is active.
Two design choices soften the blow. The rule is temporary and auto-expires about a year after it activates, so it is framed as a circuit breaker rather than a permanent change. And it grandfathers existing UTXOs, so coins and outputs that already exist before activation are not caught by the new restriction. The spec is the authority on the exact fields and thresholds, and it is the primary source you should read before acting on any figure here.
How activation works
BIP-110 uses a modified version of the BIP-9 version-bits signalling mechanism on bit 4. Miners set that bit in the blocks they mine to signal readiness, and once enough blocks in a retarget window signal, the rule locks in and then activates.
The unusual part is the threshold. Traditional soft forks used a 95 percent miner signalling bar within a 2016-block window. BIP-110 sets an unusually low 55 percent threshold, which is 1109 of 2016 blocks. The proposal also specifies a mandatory-signalling window around blocks 961,632 to 963,647, with projected activation near block 965,664, which maps to roughly 1 September 2026 at current block cadence. These block heights and dates are moving targets tied to how fast blocks are found, so treat them as estimates from the spec rather than fixed calendar entries.
One thing to keep separate. Around the same period, Paul Sztorc has scheduled a distinct eCash-style hard fork near block 964,000, roughly 21 August 2026. That event is not BIP-110. It is a different proposal with different mechanics and different backers, and the calendar proximity is a coincidence, not a connection. Do not conflate the two. BIP-110 is a temporary soft fork about data limits; the Sztorc event is a separate hard fork.
The two camps
The disagreement is not really about a single technical parameter. It is about whether Bitcoin should use a consensus change to settle what one side calls spam and the other side calls valid, fee-paying use of block space.
| Camp | Core argument | Notable voices |
|---|---|---|
| Against | A consensus change to filter data would invalidate transaction types that are valid and fee-paying today, and that precedent is the real danger. Bitcoin has no spam problem to solve this way. | Michael Saylor (publicly critical) |
| For | Arbitrary data is degrading Bitcoin as money, and a temporary limit is one of the few remaining levers to curb it before it entrenches further. | Supporters on community forums (general) |
On the against side, Michael Saylor criticized the proposal publicly. As reported from his post on X, he characterized it as turning "a spam dispute into a consensus change that would invalidate some currently valid, fee-paying transactions," argued that "that precedent is the danger," and said Bitcoin has "no spam problem." His objection is procedural as much as technical: the worry is less about this specific rule and more about setting a precedent that consensus changes can be used to filter which valid transactions the network accepts.
On the for side, supporters frame BIP-110 as one of the few remaining chances to curb what they see as data-spam crowding out Bitcoin's use as money. A note on sourcing. Much of this debate lives in Reddit threads and X posts I could not independently verify, and Saylor's quote is corroborated through news reporting. So I describe the camps in general terms on purpose. I attribute a specific position only to Saylor, and I do not put words in the mouths of other developers.
How Bitcoin actually changes its rules
Here is the part that the headlines skip. A BIP is just a document. Anyone can write one, assign it a number, and open a pull request. That act changes nothing about the network by itself.
A rule only becomes real when the people who run Bitcoin choose to enforce it. Those people are the economic full nodes and the miners. No committee, foundation, or company can push a consensus change onto the network, because there is no one in charge who could. This is the point people miss about why Bitcoin changes slowly: the absence of a central authority is a feature that makes coordinated change genuinely hard.
The two kinds of change matter here.
A soft fork tightens the rules. Blocks that are valid under the new, stricter rules are still valid under the old rules, so nodes that never upgrade keep following the same chain. SegWit and Taproot both activated this way, through node and miner adoption over time, without forcing anyone off the network. BIP-110 is designed as a soft fork.
A hard fork loosens or breaks the rules. Blocks valid under the new rules are rejected by old nodes, so unless everyone upgrades together, the network can split into two chains. This is exactly another contested consensus change worth reading for contrast, where the debate is about freezing coins rather than limiting data.
If you run your own node, this is where you hold actual power. Your node enforces whatever ruleset its software encodes. If you run your own node, the software you choose to run is your vote on which rules Bitcoin follows, and that choice, aggregated across thousands of node operators, is what activation actually measures.
Soft fork or hard fork and the split risk
BIP-110 is a soft fork. That framing matters for the split question, because the two fork types carry different risks.
| Soft fork | Hard fork | |
|---|---|---|
| Rule direction | Tightens rules | Loosens or breaks rules |
| Old nodes | Still follow the chain | Reject new blocks |
| Split risk | Low if adoption is broad | High unless everyone upgrades |
| Examples | SegWit, Taproot | Chain splits like eCash |
The split question runs opposite to the usual fear. A soft fork is not designed to split the chain, and if BIP-110 achieved broad activation it would leave a single chain. The risk sits at the other end. As of mid-July 2026, miner signalling for BIP-110 is near zero, roughly 0 to 1 percent, and node adoption is in the low single digits, carried mostly by Bitcoin Knots rather than Bitcoin Core. Those are moving figures from reporting, not fixed values, so verify current signalling before drawing conclusions.
With adoption that thin, the realistic outcomes are two. Either the rule never reaches its activation threshold and simply fails, or a small minority of nodes enforce it and separate onto a minority chain that most of the network ignores. Neither of those is Bitcoin changing network-wide. A minority soft fork with almost no economic weight behind it does not reshape the main chain; it either fizzles or forks off a fringe.
What this means for you
The calm read for most holders.
- Most holders need to do nothing. The proposal is a draft, miner support is near zero, and normal payments are not the target of the rule.
- The actors who decide are node operators and miners, not holders, exchanges, or commentators. Activation is measured in signalling and node adoption.
- If you run a node, understand what software you run. Bitcoin Core and Bitcoin Knots encode different default policies, and the software you choose is the rule set you enforce.
- UTXOs that exist before any activation are grandfathered, so a pre-existing balance is not the thing the rule reaches for.
- This is a live and shifting debate. Numbers cited here move block by block, so check current status before acting on any of them.
This is not investment advice, and it is not a prediction about whether BIP-110 activates. It is a map of the mechanics and the disagreement.
References
- BIP-110 Specification: Dathon Ohm. "Reduced Data Temporary Softfork (RDTS)." Bitcoin Improvement Proposals. bips.dev/110 and the raw source in the bitcoin/bips repository.
- BIP-9 Version Bits: The signalling mechanism BIP-110 modifies. bitcoin/bips BIP-9.
- CoinDesk: Reporting on BIP-110 status and the consensus debate, mid-July 2026. coindesk.com
- news.bitcoin.com: Coverage of miner signalling and node adoption figures. news.bitcoin.com
- NewsBTC: Reporting on the community split and Michael Saylor's public criticism. newsbtc.com
Status and signalling numbers (near-zero miner support, Bitcoin Knots-carried node adoption, block heights, and projected dates) are drawn from reporting as of mid-July 2026 and are moving figures. Technical and design claims are cited to the BIP-110 specification.
