Two Blocks, Then Nothing
BIP-110 tried to put policy into consensus. Bitcoin declined. There is a lesson in that for anyone building payments for agents.
On August 8, 2026, at block 961,632, a fork happened on Bitcoin. Nodes running BIP-110 began rejecting any block that did not signal support for the proposal, and a minority chain split off.
It produced two blocks and stopped.
By six in the morning UTC the BIP-110 branch sat at block 961,633 while the main chain had reached 961,681. Forty-eight blocks of difference, roughly most of a day’s activity on one side and almost none on the other. Miner support during the mandatory signalling window had come in at 51 blocks out of the previous 2,016, or 2.53 percent, against a threshold of 55 percent.
That is not a narrow defeat. That is a proposal being ignored.
We are not a Bitcoin company and we have no position in that fight. We are writing about it because the reason BIP-110 failed is a structural one, and the same structure shows up in agent payments right now, in the protocols being finalised this year.
What was actually proposed
BIP-110, the Reduced Data Temporary Softfork, was a one-year soft fork restricting how much arbitrary data a transaction could carry. It was written by a pseudonymous developer, Dathon Ohm, with technical advice credited to Luke Dashjr, and assigned its number in December 2025.
The technical content was specific. Most new scriptPubKeys limited to 34 bytes. OP_RETURN outputs capped at 83 bytes. Data pushes and witness arguments restricted to 256 bytes. Spending through undefined witness or Tapleaf versions blocked. Taproot annexes prohibited, control blocks capped, OP_SUCCESS opcodes disabled, Tapscripts executing OP_IF or OP_NOTIF rejected. Coins created before activation would be grandfathered, and the restrictions would lapse after a year unless extended.
The trigger was Bitcoin Core 30 relaxing its default OP_RETURN relay limits, which one camp read as the last policy-level defence against data embedding falling away. The underlying dispute went back further, to inscriptions in 2022 and Ordinals in early 2023, which made it practical to store images and NFT-style assets in witness data.
So the question underneath was never really about bytes. It was: what is Bitcoin block space for?
Everyone had a reasonable argument
This is the part worth sitting with, because it is what makes the outcome instructive rather than obvious.
The proposal’s supporters were not confused. Their claim was that a payment network optimised for monetary use is degraded when its scarce block space fills with data that has nothing to do with payments, and that policy-level filters had already proven insufficient. That is a coherent position, and plenty of serious people held it.
The opposition was equally substantive, and it did not mostly argue that data embedding is good.
Michael Saylor published a long critique arguing the cure was more dangerous than the condition, and made a point that generalises well beyond Bitcoin: the network cannot read intent. It cannot know whether a given blob of bytes is an image, a proof, a contract, metadata, an authentication record, or something nobody has invented yet. Banning what looks like spam means encoding a human judgement about purpose into protocol rules.
Adam Back argued that Bitcoin’s process is deliberately resistant to change and that supporters were free to run their own fork. Jameson Lopp argued the proposal would weaken censorship resistance and predictability. Samson Mow, who shares the concern about data bloat, opposed BIP-110 anyway on the grounds that protocol changes require broad consensus.
Even the BIP editor who assigned the number, Mark Erhardt, published it while describing it as misguided and careless, because the repository’s criteria are about process compliance rather than endorsement. A BIP number has never meant approval.
Get Saifuro’s stories in your inbox
Join Medium for free to get updates from this writer.
The critics converged on something narrower than “this is a bad rule.” They converged on: this is not the layer where that rule belongs.
Why the settlement layer refuses this kind of rule
A consensus layer has one job, and it is a strange one: to make everyone agree on what happened, forever, without anyone in charge.
That job has a property that makes it hostile to policy. Any rule the consensus layer enforces has to be accepted by essentially everyone, simultaneously, permanently, and it has to be evaluated mechanically without reference to intent. Those constraints are what make the layer trustworthy. They are also what make it a terrible place to encode a judgement about what money should be used for, because such judgements are contested by definition, change over time, and depend on context the protocol cannot see.
Notice the shape of the failure. BIP-110 did not lose because its rules were technically wrong. It lost because it asked a layer whose defining property is universal agreement to adopt a rule that a large part of the ecosystem disagreed with. The two-block chain was the mechanism working exactly as designed.
Policy that requires everyone to agree does not survive contact with a system where anyone can decline.
The same shape, in agent payments
Now look at where agent payment infrastructure stands in 2026.
The settlement standards have consolidated fast. x402 moved under the Linux Foundation on July 14 with 40 member organisations, premier members including AWS, American Express, Circle, Cloudflare, Coinbase, Google, Mastercard, Ripple, Shopify, Stripe and Visa. AP2 went to the FIDO Alliance. ACP is open source under Stripe and OpenAI. Card networks have shipped their own agent extensions.
Every one of these standards is, correctly, silent on policy.
x402 tells a server how to state a price and a client how to satisfy it. It has nothing to say about whether the buyer should be buying, from that vendor, at that moment, within what budget. AP2 handles provable authorisation, not whether the authorisation was wise. None of them will tell you that this agent has already spent its daily limit across four other rails.
Read that as a gap and you will try to fill it in the wrong place. Read it as scope discipline and you will notice that these protocols are doing exactly what BIP-110’s critics said a settlement layer should do: enforce what everyone can agree on, and leave contested judgement to the layer above.
Because the judgement genuinely is contested. Your daily limit is not our daily limit. Your approval threshold reflects your risk appetite, your regulator, your industry. A vendor allowlist is a business relationship, not a fact about the world. A protocol that encoded any of this would be wrong for most of its users on day one, and could not be corrected without everyone agreeing to correct it.
So the rules belong somewhere they can be specific, versioned, disagreed with, and changed on a Tuesday afternoon without asking a foundation for permission.
What this means in practice
The practical form of that argument is unglamorous.
Spending limits, allowlists and approval thresholds live above the rails, in a layer you own and can change. They are evaluated before settlement rather than discovered during reconciliation, because a limit found out about afterwards is a report, not a control. Escrow handles the delivery-risk case that no settlement layer will ever handle for you, releasing on delivery and refunding on failure. And every decision produces a record, so the audit trail is a byproduct of how payments are made rather than an archaeology project at quarter end.
None of that requires the protocols to change. It requires them not to.
That is the layer we build at Saifuro, and the argument for building it there rather than pushing rules downward into the rails is the same argument that just played out on Bitcoin, at a cost of two blocks.
Where to be careful
Analogies between Bitcoin governance and agent payment standards are useful up to a point and misleading past it, so let us mark the point.
Bitcoin’s consensus layer is permissionless and has no governing body. The x402 Foundation is a Linux Foundation project with members, working groups and a process. Those are different things. A standards body can adopt a contested rule in a way a permissionless chain cannot, and if enough premier members wanted policy in the protocol, it could plausibly get there.
Which is why the discipline is worth defending now, while these specifications are young, rather than assumed. The BIP-110 outcome is a useful precedent, not a guarantee.
And one honest caveat about the outcome itself: BIP-110’s rejection does not settle the underlying question about data on Bitcoin. The dispute that produced it is still there. What was settled was narrower, and more relevant to us: a rule about what payments are for could not be pushed into the layer that moves the payments.
