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.
Frequently Asked Questions
What is BIP-110? BIP-110 is a draft Bitcoin Improvement Proposal titled Reduced Data Temporary Softfork (RDTS), authored under the pseudonym Dathon Ohm. It proposes a temporary consensus rule that limits oversized and 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 proposal in the bitcoin/bips repository, not an activated rule.
What does BIP-110 actually propose to change? It tightens the rules on how much arbitrary data a transaction can commit to the chain, targeting the witness and script fields used to embed inscriptions and token data. The restriction is temporary and auto-expires roughly one year after activation. UTXOs created before activation are grandfathered in, so the rule applies going forward rather than retroactively.
Is BIP-110 a soft fork or a hard fork? It is designed as a soft fork. A soft fork tightens the rules, so blocks valid under the new rules stay valid under the old ones, and nodes that never upgrade still follow the chain. This is the same mechanism that activated SegWit and Taproot. A hard fork, by contrast, loosens or breaks rules and can split the chain into two.
Will BIP-110 split the Bitcoin chain? As a soft fork it is not designed to split the chain, and network-wide activation would leave one chain. The split risk comes from the opposite direction. With near-zero miner signalling and low single-digit node adoption as of mid-July 2026, the realistic outcomes are that it fails to activate or that a small minority of nodes enforce it and separate onto a minority chain. A network-wide split is not the base case.
Is BIP-110 dangerous to my coins? For an ordinary holder the direct risk is low. UTXOs created before activation are grandfathered, and a soft fork does not invalidate the ability to spend normal payments. The contested point raised by critics is that the rule would, going forward, reject some transaction types that are valid and fee-paying today. If you do not create Ordinals inscriptions or large data payloads, your ability to send and receive Bitcoin is not the target of the proposal.
Who supports and who opposes BIP-110? Supporters frame it as one of the few remaining chances to curb what they see as data-spam degrading Bitcoin as money. On the opposing side, Michael Saylor publicly criticized it, arguing the change would turn a spam dispute into a consensus change and that Bitcoin has no spam problem. Beyond Saylor, much of the debate has played out on community forums in general terms, and named positions there could not be independently verified as of 13 July 2026.
How does this compare to other protocol events like the halving? The halving is a protocol-level event that is already coded into consensus and happens automatically on schedule, with no debate required. BIP-110 is the opposite: a proposed rule change that only takes effect if node operators and miners choose to adopt it. One is automatic and settled, the other is contested and optional.
This article is educational and is not investment advice. All facts are stated as of 13 July 2026, and BIP-110 is a live and shifting debate. Signalling percentages, node counts, block heights, and activation dates move continuously, so verify the current status before acting on anything here. The primary source for every technical claim is the BIP-110 specification text linked below.
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.
