Bitcoin’s BIP-110 dispute is often described as a fight over spam, inscriptions and OP_RETURN. Its more consequential test is institutional: can a minority of upgraded nodes force a tighter consensus rule when most miners, exchanges and ordinary economic infrastructure continue to accept the old one? The answer is not simply that “users enforce the rules.” Users can enforce rules for themselves. To make those rules become Bitcoin’s practical, network-wide reality, they need enough economic weight, coordinated infrastructure and credible consequences to persuade hashpower to follow.
BIP-110, described by its advocates as a temporary reduced-data soft fork, proposes to make certain data-heavy transaction forms invalid for roughly one year. The restrictions would tighten OP_RETURN limits, constrain larger arbitrary data pushes and target script patterns associated with inscriptions, token protocols and other non-financial payloads. Supporters see that as a defensive intervention: miners collect a one-time fee, while node operators absorb the ongoing storage, bandwidth and validation burden. Critics see a very different precedent: a rule change that deliberately rejects transactions that were previously valid and fee-paying.
That disagreement matters, but it is not the key engineering question. Bitcoin can accommodate disagreement about what should be relayed, indexed, mined or displayed. The difficult moment comes when a faction attempts to translate its preference into consensus validity, then activate that rule without broad miner support.
“Two of Bitcoin's most influential figures came out against it on Saturday. Strategy founder Michael Saylor posted that “there are 110 things more dangerous to Bitcoin than spam,” arguing the proposal “turns a spam dispute into a consensus change that would invalidate some currently valid, fee-paying transactions.”
BIP-110’s August 2026 window is therefore a useful case study in what a user-activated soft fork actually requires. It shows why node count alone is insufficient, why miner signaling is informative without being sovereign, and why exchanges, custodians, payment processors and merchants can decide whether a proposed chain rule is real in practice.
The first distinction is simple: a minority can always run stricter software. It cannot automatically make the rest of the world treat that software’s rules as Bitcoin.
A rule change that narrows validity
A soft fork narrows Bitcoin’s set of valid blocks or transactions. Before activation, a transaction using a particular data-carrying construction may be valid under the network’s consensus rules. After activation, upgraded nodes can reject a block containing that transaction because their rule set has become stricter.
That is the defining property. A soft fork does not add a new type of transaction that older nodes cannot understand. Instead, it says that some activity older nodes still regard as valid must no longer be accepted by upgraded nodes.
This is why the word “temporary” in BIP-110 does not make the proposal operationally trivial. A one-year restriction still asks upgraded nodes to reject blocks that non-upgraded nodes can accept. It still creates a period in which two groups may disagree about which chain is valid.
The proposal’s target is not merely OP_RETURN. OP_RETURN is the clearest example because it provides an explicit place for small payloads in a transaction. But modern data publication can also be routed through witness data, scripts and transaction layouts that do not look like a conventional note field. CoinDesk reported that BIP-110 would restore a smaller OP_RETURN cap, limit most arbitrary data chunks over 256 bytes and restrict some script formats commonly used for data storage.
For supporters, that package is an anti-spam measure. The claim is that Bitcoin’s block space should prioritize monetary settlement and that permanent data storage externalizes costs onto every future full node operator. For opponents, the problem is not whether a particular payload is aesthetically valuable. It is whether a consensus rule should classify valid, fee-paying transactions by perceived purpose.
Michael Saylor’s public criticism has put that latter concern in unusually broad terms. His argument is that consensus rules should remain neutral toward valid uses and that Bitcoin should address objective validation or denial-of-service risks rather than impose a preferred interpretation of block space. The Block reported that BIP-110 supporters answer that neutrality does not require indefinitely accommodating arbitrary onchain storage that can increase costs for node operators and compete with payments for scarce space.
Neither side can settle that conflict merely by winning an argument on social media. The operative question is which rule set the network’s economically important actors will enforce.
Policy is a preference. Consensus is a refusal.
Much of the confusion around BIP-110 begins with a failure to separate relay policy from consensus validity.
Relay policy governs what a node is willing to accept into its mempool, forward to peers or package for miners. A node can refuse to relay a transaction because it is too large, uses an unpopular construction, pays too little fee or simply falls outside the operator’s preferred policy. That decision can make a transaction harder to confirm, but it does not necessarily make the transaction invalid.
Consensus validity is different. It determines whether a node accepts a block after it has already been mined. If a transaction is consensus-valid, then a node following the existing rules must accept a block containing it, even if that node would never have relayed the transaction itself.
That distinction creates several possible responses to unwanted data without a soft fork:
A wallet can decline to create those transactions.
A node operator can decline to relay them.
A block explorer can decline to index or display them.
A mining pool can decline to include them.
A merchant can decide not to accept assets or services tied to them.
Those actions can be commercially influential. They can change fee markets, reduce convenience and shape what applications get built. But they preserve a critical property: a miner that includes the transaction can still produce a block accepted by all nodes following the existing consensus rules.
BIP-110 crosses that boundary. Its backers are not merely asking nodes to ignore or refuse to forward certain transactions. They are asking upgraded nodes to reject blocks that contain them.
That is why the proposal has generated more risk than a conventional policy dispute. If the rule is adopted broadly, it becomes a network-wide restriction. If it is adopted narrowly, it becomes a filter enforced by one portion of the network, potentially on a chain that only that portion recognizes.
The practical lesson for readers examining any proposed soft fork is to ask one question before debating the proposal’s goal: Does the software change mempool policy, block template policy or consensus validation?
Only the last category creates a direct chain-split risk when adoption is uneven.
The BIP-110 timetable and its crucial trigger
BIP-110’s activation logic matters because it mixes miner signaling with a user-activated enforcement mechanism. Miner signaling is not treated as the final authority. Instead, it functions as an opportunity for the proposal to lock in early if enough hashpower visibly supports it.
CoinDesk reported in July that an earlier signaling period ran from block 957,600 through block 959,615, with a voluntary lock-in deadline at block 961,542. The Block later reported that the mandatory signaling window would begin near block 961,632, expected around August 7, 2026, while Decrypt described the same block as arriving around August 9. The variation in calendar estimates reflects Bitcoin’s variable block production, while the block height is the more meaningful trigger.
The important sequence is this:
Voluntary signaling phase: miners can include a BIP-110 signal in blocks. If enough hashpower signals, the proposal can lock in through its stated threshold.
Early lock-in threshold: reporting on the proposal identified a 55% signaling threshold, lower than the 95% threshold commonly associated with older Bitcoin soft-fork deployment approaches.
Mandatory signaling window: if voluntary support does not meet the threshold, nodes running the BIP-110 client begin rejecting blocks that do not carry the required signal.
Enforcement period: upgraded nodes follow only the chain of blocks they consider compliant. The intended restrictions are then expected to apply for those nodes around September 1, 2026.
The key event is not the miner vote itself. It is the moment upgraded nodes begin rejecting blocks from miners who did not signal.
Before that moment, low signaling tells the market the proposal lacks hashpower support. After that moment, low signaling becomes a chain-selection problem. A BIP-110 node may treat the dominant mined chain as invalid, while non-upgraded nodes continue to treat it as valid and follow its accumulated proof of work.
The numbers: signaling is far below the claimed path to lock-in
The public data reported before the mandatory window showed how wide the gap was between BIP-110’s activation target and actual miner behavior.
The Block reported miner signaling of 0.86% on July 19. Decrypt later reported 2.64% near the mandatory window. Both readings remained far from the 55% early lock-in threshold. CoinDesk’s earlier reporting said support had not risen above roughly 1% in prior observed periods, underscoring how little major mining-pool backing the proposal had attracted at that stage.
The chart is not a forecast. It is a measurement of a condition that determines what kind of event BIP-110 can become.
At 55% or more, a signaling mechanism can communicate that miners are already converging on the new rules. Businesses may reasonably expect the upgraded rule set to become the dominant chain, and the remaining holdouts face pressure to adapt.
At roughly 1% to 3%, the opposite is true. The majority of miners appear prepared to keep building blocks that upgraded BIP-110 nodes would reject once mandatory enforcement begins. In that case, the upgraded nodes do not gain control of the existing chain. They begin following a different history from the fork point.
A minority chain is not automatically worthless or illegitimate. It can have dedicated users, applications and miners. But it has very different operational properties from a successful Bitcoin soft fork. It may produce blocks more slowly, have less liquidity, expose users to greater reorganization risk and require separate ticker, wallet and custody handling.
That distinction should end the simplistic version of the claim that “miners do not matter.” Miners do not write consensus rules alone. But proof of work determines which valid chain non-upgraded nodes select, and it determines the speed and security budget available to any chain split.
What “users enforce the rules” actually means
The phrase “users enforce the rules” is true, but incomplete.
A fully validating Bitcoin node independently checks blocks. It does not need to trust a miner, exchange, mining pool or developer to tell it whether a transaction is valid. If its operator runs BIP-110 enforcement code, that node can reject a non-compliant block even if the block has enormous hashpower behind it.
That is a real power. It prevents miners from unilaterally changing the rule set for users who refuse to upgrade.
But it is a negative power first. A node can say, “I will not accept this chain.” It cannot, by itself, cause the rest of the network to abandon that chain.
To convert a user-activated rule into Bitcoin’s practical consensus, upgraded nodes need the miners who produce blocks to face a cost for ignoring them. That cost usually arrives through economic acceptance.
Imagine that major exchanges, large custodians, payment processors, merchants, wallet providers and long-term holders announce that after a specific activation block they will recognize only BIP-110-compliant Bitcoin. A mining pool that produces a non-compliant block might receive a block reward and transaction fees, but those coins could be unacceptable to the most valuable buyers, deposit systems and settlement channels. Miners would then have a powerful reason to mine the compliant chain even if they disliked the rule.
Now reverse the assumption. Suppose upgraded nodes are mostly hobbyists and a small set of ideologically committed operators, while major exchanges, custodians and merchants remain on the existing rules. A miner that rejects BIP-110 can still sell its block rewards, receive services from the dominant infrastructure and build atop the highest-work chain that most nodes accept. The miner’s economic incentive is to stay put.
This is the operational meaning of economic-node adoption. The important issue is not a raw count of reachable nodes on the internet. A small number of entities can handle a large share of bitcoin custody, trading, payments, lending, settlement or merchant activity. Their rule choices can create effects far beyond their numerical share.
The Block cited an estimate from Ocean executive Jason Hughes placing BIP-110 node support in a range of 7% to 15%, while CoinDesk characterized adoption as low single digits in its earlier reporting. Those figures should be treated cautiously because there is no perfect census of Bitcoin nodes, and measuring nodes does not measure the value or volume behind them. Still, the reports point to the same conclusion: visible adoption did not demonstrate broad alignment across Bitcoin’s economically central infrastructure.
How the two chains would behave
If mandatory enforcement occurs while most miners continue producing non-signaling blocks, the fork mechanics are straightforward.
An upgraded BIP-110 node receives a block from the majority chain. It checks the new requirements, sees that the block lacks the required signal or contains a prohibited transaction pattern, and rejects it. It does not extend that chain.
A non-upgraded node receives the same block, validates it under the old rules and accepts it. It follows the chain with the most accumulated work.
At that point, the two sets of nodes no longer share a single authoritative history. They may share blocks before the activation point, but they disagree after it.
Several consequences follow.
First, block production can become uneven. If only a small share of hashpower mines the BIP-110 chain, its blocks may arrive far less frequently than users expect. A ten-minute average is a property of network-wide hashpower and difficulty, not a guarantee for a lightly mined split.
Second, confirmation risk changes. A merchant that normally waits for several confirmations may need to reconsider what those confirmations mean on a chain with low hashpower. The cost of reorganizing a lightly protected chain can be materially lower than on the dominant chain.
Third, deposits become ambiguous. An exchange has to decide which chain its Bitcoin deposit system accepts. It must verify that wallet software, custody systems, blockchain analytics, transaction monitoring, hot-wallet operations and accounting all agree. If it supports both branches, it needs separate asset identifiers, replay protection analysis and a clear customer policy.
Fourth, miners face stranded-reward risk. A miner can produce blocks on a BIP-110-incompatible chain, but only if the economic market continues to recognize that chain as BTC. If the market instead recognizes the enforcing chain, the miner’s rewards can become difficult to sell or deposit. That is the lever a successful UASF needs.
Fifth, users must know which network they are on. A wallet can show a balance and confirmations without telling a user that the receiving service recognizes a different chain. During a contested split, infrastructure coordination becomes a safety feature, not a public-relations exercise.
This is why a chain split is not resolved by declarations that one side is “the real Bitcoin.” Markets, custodians and software determine operational reality one service at a time.
Hashpower is not governance, but it is infrastructure
Bitcoin’s design intentionally prevents miners from simply voting in arbitrary new consensus rules. If miners tried to create coins beyond the subsidy schedule, spend coins without valid signatures or violate other rules enforced by economic nodes, those blocks would be rejected by nodes that retained the old software.
But when a soft fork makes rules stricter, miners occupy a different position. Old nodes do not reject the new chain because the new blocks remain valid under the old rules. The upgraded nodes are the ones rejecting blocks. That gives miners an important practical choice: they can mine on the stricter chain, or they can continue mining a chain that only non-upgraded nodes recognize.
A UASF is an attempt to constrain that choice economically. It says to miners: if you do not follow the new rule, your blocks will not be accepted by the users who matter.
An enforcing minority makes a fork economically consequential only when exchanges, custodians and liquidity providers recognize its coins. Without that settlement layer, miners can continue mining the higher-work legacy chain and sell those rewards into the market that still accepts them.
That is why broad economic coordination is harder than broad rhetorical support. It requires exchanges to set cutover rules, custodians to upgrade validation, payment providers to test deposits and withdrawals, merchants to decide confirmation policies, wallet developers to communicate chain identity and mining pools to know where their rewards will be liquid.
The stronger that coordination, the less hashpower a UASF needs at the beginning because miners can rationally move to protect their revenue. The weaker that coordination, the more the enforcing nodes risk isolating themselves on a chain with little hashpower.
The BIP-110 test is about coordination, not slogans
BIP-110 is a particularly sharp test because it seeks to invalidate a class of transactions that many existing nodes and miners still regard as valid. It is not a quiet upgrade to a feature that has already achieved broad technical and economic agreement.
At 0.86% and 2.64%, observed signaling remains far below the 55% lock-in threshold, meaning the proposal is not close to assembling the miner support needed to activate. That snapshot does not prove its supporters are wrong about node costs, spam or Bitcoin’s intended use; nor does it show whether broader economic support could eventually change miners’ incentives.
That is where the anti-spam framing can obscure the real stakes. A network can choose to use relay policy against unwanted traffic without causing a consensus split. A temporary soft fork, by contrast, turns the disagreement into a test of which users, businesses and miners will recognize each other’s blocks.
Saylor’s critics may reasonably argue that leaving data storage unconstrained can impose costs on node operators and distort Bitcoin’s fee market. Saylor’s position, as reported by Decrypt, is that rewriting consensus rules to invalidate transactions creates a more serious danger to Bitcoin’s neutrality and economic rights.
The engineering takeaway is not that consensus should never change. Bitcoin has changed through soft forks before. The takeaway is that changing consensus requires more than a technically valid activation mechanism. It requires an ecosystem that will behave as though the new rule is already the accepted rule.
A checklist for evaluating the next soft fork
Any reader assessing a future Bitcoin soft fork can use five questions.
1. What exactly changes? Identify the transaction, script, block or validation condition that moves from valid to invalid. Avoid labels such as “spam” until after the technical condition is clear.
2. Is this policy or consensus? If the change affects only relay or mining templates, it can alter behavior without dividing the ledger. If nodes reject blocks after activation, it is a consensus change.
3. What triggers activation? Read the exact block heights, signaling bits, thresholds, timeout conditions and mandatory enforcement clauses. A miner signaling threshold and a node rejection rule are not the same thing.
4. Who will enforce it economically? Count more than public nodes. Ask which exchanges, custodians, payment companies, miners, merchants, wallets and liquidity providers will accept the upgraded chain.
5. What happens if adoption is partial? Model the minority-chain scenario. Estimate block intervals, liquidity, exchange support, confirmation standards, replay risks and reorganization exposure. If no one has a credible operational answer, the proposal is not ready for activation.
BIP-110’s central lesson is that Bitcoin’s rules are enforced locally but legitimized collectively. An upgraded node can refuse a block. A coordinated economic majority can make that refusal decisive. A minority without that coordination can still produce a principled fork, but it cannot assume it has changed Bitcoin for everyone.
That is the line between a user-activated soft fork and a user-activated minority chain.