BIP-110 is approaching its first consequential activation boundary. The proposal enters mandatory signaling at block 961,632, currently projected around August 9, 2026. It locks in no later than block 963,648, roughly in late August, and activates its new transaction rules at block 965,664, currently projected for early September. BIP-110 uses a 55% signaling threshold and would enforce its restrictions for 52,416 blocks, approximately one year.
Bitcoin resolves consensus changes through coordination among miners, users, and nodes (note that anyone can be any combination of these three things). Miners choose which valid chain to extend. Users decide which chain’s coins, deposits, and payments they recognize. Nodes independently choose which rules they enforce. Durable consensus emerges whenever these groups converge on the same chain.
BIP-110 restricts large data pushes, oversized output scripts, undefined witness versions, Taproot annexes, deep Taproot control blocks, OP_SUCCESS opcodes, and certain Tapscript conditionals. It grandfathers UTXOs created before activation, while standard monetary uses remain compatible with its rules.
Most corporations don’t have to do anything
For most corporations, BIP-110 requires no action. Today, the typical corporate Bitcoin utility is as a store of value, as a long-duration treasury reserve asset. This use case is basically unaffected by the transaction features targeted by BIP-110.
Corporations using Bitcoin for payments also face limited direct impact. Standard on-chain payments remain compatible (see below for specifics), while ordinary Lightning payments occur off-chain. A chain split can still affect Lightning channel monitoring, force-close behavior, and the chain source that a Lightning node treats as authoritative. However, even corporations using Bitcoin for payments normally use a third party provider like Square, so all of this abstracted away to be a non-issue.
A corporation that runs its own full node has a direct choice. Every user retains the right to run the Bitcoin implementation that matches its needs. A corporation that supports BIP-110 should therefore switch over to running BIP-110. All other node-running corporations can simply do nothing.
A BIP-110 node enforces tighter rules. During mandatory signaling, it rejects blocks that fail to signal bit 4. After activation, it also rejects blocks containing transactions that violate BIP-110. A non-BIP-110 node accepts BIP-110-compliant blocks as well as blocks that remain valid under the existing rules. Among all chains valid under its own rules, a node follows the branch with the greatest accumulated proof of work.
So the key factor to be aware of is a chain split. When miners build a chain that is not compliant to the BIP, BIP-110 nodes can separate from the broader network. Non-BIP-110 nodes may continue following the higher-work branch, while BIP-110 nodes could remain on a compliant branch with less accumulated work.
Corporations dealing with chain splits
Mining companies face the highest immediate economic exposure. Electricity and machine time are sunk costs. A miner should select the branch it expects other miners, nodes, and users to recognize and mine on it. A miner may also stop mining and wait for the chain split to resolve. If BIP-110 and non-BIP-110 chains develop independently, miners must track chainwork, signaling, validity under both rule sets, and their own mining pool’s stance, and the market value assigned to each branch.
Corporations operating exchanges and institutional custody should prepare for settlement uncertainty. During an extended split, the ordinary six-confirmation standard loses much of its value because each branch can show six confirmations independently. Operators should monitor both branches, raise confirmation requirements, pause large deposits or withdrawals when risk rises, and delay final settlement until one branch has decisively accumulated more work or the transaction has sufficient depth on all viable branches. Different validation rules can produce chain splits, false confirmations, and double-spend risk.
Let’s consider a chain split occurring at block height S.
Chain splits and determining overall global finality
Suppose a deposit appears on Chain A at S+4 and on Chain B at S+6. Once both chains reach S+12, the deposit has substantial depth on each branch (assuming we are still using six-confirmations). Now, this number of six confirmations should change depending on the work on each branch. And it might be the case that the number of confirmations one would like to see would be different for each branch. The main point is that the operator must wait until both branches reach the requisite confirmations. The operator can at that point be confident that the transaction remains, not matter which branch becomes canonical.
If the transaction appears on only one branch, the operator should wait for that branch to win or apply chain-specific accounting. That would be the only way to ensure no double spending happens. In practice, monetary transactions should always eventually appear on both branches, since the BIP-110 chain does not prohibit monetary transactions.
Conclusion
The main thing to be aware of is a chain split. If there is no split, then there is nothing that needs to be done differently. Even with a chain split, BIP-110 will not create insurmountable disruptions.
For corporations that may be impacted by a chain split, the main action to take is to lengthen confirmation times and monitor both branches. For node-running corporations that support the BIP, the main action is to start running it on their nodes, if they haven’t already.
Miners, as usual, should direct their hashrate based on their view of which branch will end up with the most accumulated proof of work. Exchanges and custodians should lengthen settlement procedures and maintain visibility into both chains, should a chain split occur. For the daily operations of most corporate Bitcoin users, BIP-110 changes very little, if it changes anything at all.
Disclaimer: This content was prepared on behalf of Bitcoin For Corporations for informational purposes only. It reflects the author’s own analysis and opinion and should not be relied upon as investment advice. Nothing in this article constitutes an offer, invitation, or solicitation to purchase, sell, or subscribe for any security or financial product.
Michael Saylor Opposes Bitcoin BIP-110 Over Censorship Concerns
Michael Saylor has come out against Bitcoin’s BIP-110 proposal, warning that the planned soft fork could introduce censorship risks into the network.
The debate centres on whether Bitcoin should restrict certain forms of non-monetary data storage, including activity linked to Ordinals and similar uses. Supporters of tighter limits argue that Bitcoin block space should remain focused on monetary transactions. Critics argue that protocol-level restrictions could set a dangerous precedent by deciding which types of data are acceptable.
Saylor’s intervention matters because he is one of the most visible corporate Bitcoin advocates in the world. When the MicroStrategy chairman weighs into a technical governance debate, the discussion moves beyond developer circles and reaches a wider market audience.
This is not just about one proposal. It is about what Bitcoin should be allowed to carry, who gets to decide, and whether efforts to reduce spam could accidentally weaken Bitcoin’s neutrality.
TL;DR
Michael Saylor has opposed Bitcoin’s BIP-110 proposal.
BIP-110 seeks to limit arbitrary data storage on Bitcoin.
Critics argue the proposal could create censorship risk and set a problematic precedent.
https://x.com/saylor/status/2078754106030649740
What BIP-110 Is Trying To Do
BIP-110, also known as the Reduced Data Temporary Softfork, is aimed at limiting non-monetary data stored on Bitcoin.
The proposal is connected to a long-running argument inside the Bitcoin community. Some users believe block space should be preserved primarily for financial transactions. Others believe Bitcoin’s rules should remain neutral, even when certain uses are unpopular or expensive.
Ordinals pushed that debate into the open. By using Bitcoin block space for inscriptions and other data-heavy activity, Ordinals created new demand for block space but also frustrated users who saw higher fees and congestion.
BIP-110 is one proposed response.
The proposal attempts to restrict arbitrary data while using miner signaling as the activation route. One of the most controversial details is the proposed 55% activation threshold, which is far lower than the traditional 95% supermajority standard often associated with major Bitcoin soft fork activation.
That lower threshold is part of why critics are uneasy.
If Bitcoin’s rules can be changed with a relatively narrow majority of miner signaling, opponents worry that the network could become more vulnerable to political, commercial, or social pressure over time.
Why Saylor’s Objection Matters
Saylor’s position is important because he has built his public reputation around Bitcoin as neutral, durable monetary infrastructure.
His criticism is not only about Ordinals. It is about whether Bitcoin should start filtering certain kinds of transactions at the protocol level. Once that door opens, the next debate becomes harder: who decides what counts as spam, abuse, or unacceptable data?
That is where censorship concerns enter the picture.
Bitcoin’s value proposition depends heavily on predictability and neutrality. Users may disagree about how the network should be used, but the protocol itself is supposed to enforce rules without caring who is transacting or why.
A rule designed to reduce unwanted data may seem harmless to some users. But to others, it creates a slippery slope. If one category of data can be restricted because enough people dislike it, future changes could target other categories.
That is why the debate has become sharper than a normal technical disagreement.
The Ordinals Fight Is Still Really About Bitcoin’s Identity
The Ordinals debate has always been bigger than JPEGs, inscriptions, or meme activity.
It asks whether Bitcoin is only money, or whether the protocol should remain open to any valid transaction that follows consensus rules. Purists argue that arbitrary data dilutes Bitcoin’s mission and makes monetary use more expensive. Neutrality advocates argue that filtering use cases damages Bitcoin’s permissionless design.
Both sides have a point.
High fees can hurt ordinary users. Spam can make the network harder to use. But protocol-level filtering is not a small fix. It changes the balance between open validation and social preference.
Bitcoin has survived partly because rule changes are difficult. That slowness frustrates people, but it also protects the network from fast-moving political or commercial pressure.
BIP-110 now sits inside that tension.
Activation Is Not Guaranteed
It is important not to overstate where this stands.
BIP-110 is not guaranteed to activate. Community support remains divided, and miner signaling would still have to reach the required threshold. Bitcoin’s governance process is deliberately difficult, and controversial proposals often fail to gain enough momentum.
That is part of the point.
For many Bitcoin supporters, the resistance to quick protocol changes is a feature, not a flaw. It means proposals must survive public scrutiny, technical review, and broad social consensus before becoming part of the network’s rules.
Saylor’s opposition adds weight to the anti-BIP-110 side of the debate, but it does not settle the issue. Developers, miners, node operators, businesses, and users will all continue to shape the outcome.
For now, the story is less about immediate activation and more about Bitcoin’s governance culture.
The network is again being forced to decide how it balances efficiency, neutrality, block space demand, and resistance to censorship. That is a hard debate, but it is also the kind of debate Bitcoin was designed to survive.
This article is based on Michael Saylor’s public statement and the BIP-110 GitHub repository.
This article was written by the News Desk and edited by Samuel Rae.
This report is based on publicly available market and on-chain data. at X
Login
