The 4-Hour BIP: Why Bitcoin's Base Layer Lost the HTTP 402 Race | Bitcoin Index

On March 4, 2026, someone tried to bring Bitcoin to the HTTP 402 party. Four hours later, the invitation was revoked.

A Bitcoin Improvement Proposal went live at 10:28 UTC proposing a standardized protocol for Bitcoin payments over HTTP using the long-dormant 402 status code. By 14:35 UTC, it was closed by BIP maintainers. The rejection wasn’t just about process violations. The proposal contained a critical security flaw that would let anyone steal funds, and it tried to solve a problem that Bitcoin’s base layer physically cannot handle.

But this isn’t a story about one bad proposal. It’s a snapshot of Bitcoin’s infrastructure growing pains as the ecosystem wrestles with “agentic payments” (AI agents making autonomous transactions), competing standards, and the fundamental question: what is Bitcoin’s base layer actually for?

What happened: the timeline

May 6, 2025: Coinbase launches x402, an HTTP 402-based payment protocol using stablecoins (USDC) on the Base blockchain. It’s designed for APIs, apps, and AI agents that need instant payments.

March 4, 2026, 10:28 UTC: Shiva Sitamraju, founder of Bitcoin payment processor Blockonomics, opens pull request #2112 on the bitcoin/bips repository proposing an “Internet Payment Protocol for Bitcoin Payments.”

March 4, 2026, 14:24 UTC: BIP maintainer Murchandamus posts technical concerns pointing out security vulnerabilities and scalability issues.

March 4, 2026, 14:35 UTC: BIP maintainer jonatack closes the PR, citing process violations.

Total lifespan: four hours and seven minutes.

The proposal: Bitcoin’s answer to x402

The draft BIP (called “x402b”) attempted to create a Bitcoin version of Coinbase’s x402 stablecoin protocol. Here’s how it was supposed to work:

A client requests a resource from a server
Server responds with HTTP 402 Payment Required, including Bitcoin payment details
Client creates a Bitcoin transaction signed with SIGHASH_SINGLE (a special signature flag)
Client sends this partially-signed transaction to the server without broadcasting it
Server adds its own receiving address, completes the transaction, and broadcasts it
After confirmation, client requests the resource again with proof of payment

The stated goal: enable “agentic payments” where AI agents conduct thousands of automated transactions per hour while maintaining privacy through unique addresses per order.

It sounds clever. It was fatally broken.

Why it died: three fatal flaws

Flaw 1: Process violation

The Bitcoin Improvement Proposal process explicitly requires submitting ideas to the public mailing list first to gather feedback before writing formal specifications. This isn’t bureaucracy for its own sake. It’s a safeguard to prevent wasting everyone’s time on fundamentally broken ideas.

Sitamraju skipped this step entirely. Jonatack’s closing comment was direct:

“It doesn’t appear to have followed the workflow described in the README and in BIP-0003, and particularly the sections below. People wishing to submit a BIP should first describe their idea to the bitcoindev@googlegroups.com mailing list to gather feedback on viability and community interest before working on a formal description.”

If the proposal had gone through mailing list review, the technical issues would have surfaced before a formal submission.

Flaw 2: Critical security vulnerability

Murchandamus identified a devastating problem with the proposed use of SIGHASH_SINGLE:

“Using SIGHASH_SINGLE is also completely insecure and would allow anyone that sees the transaction to attempt diverting the funds to their own wallet by creating a conflicting transaction. The expected outcome is that the sender has no guarantee that the payment actually goes to the recipient.”

Here’s the technical breakdown: SIGHASH_SINGLE is a Bitcoin signature flag that signs specific inputs and outputs but leaves other parts of the transaction modifiable. The proposal relied on this flexibility to let the server add its receiving address after the client signed.

The problem? Anyone who intercepts that partially-signed transaction can replace the server’s output with their own address, broadcast the modified transaction, and steal the payment. The sender loses funds. The merchant receives nothing. There’s even tooling designed to exploit exactly this vulnerability.

This isn’t a theoretical attack. It’s a well-documented pattern of SIGHASH_SINGLE misuse that’s been known for years.

Flaw 3: Physical impossibility

Even if the security issues were fixed, the proposal couldn’t work at scale. Bitcoin’s base layer processes roughly seven transactions per second globally. Block time averages ten minutes. Confirmations take up to an hour for reasonable security.

The proposal claimed to target scenarios with “thousands of order requests per hour” from a single merchant. Let’s do the math:

1,000 payments per hour = 16.67 payments per minute ≈ 0.28 transactions per second

That’s 4% of Bitcoin’s entire global transaction capacity for one merchant. And that’s the best case. If each payment needs confirmation before delivering the resource (which the BIP requires), you’re waiting ten minutes for every API response.

Murchandamus put it bluntly:

“It is unreasonable to expect that you will be able to add thousands of payments per hour to the Bitcoin network on chain.”

The missing context: L402 already solved this

Conspicuously absent from the BIP draft: any mention of L402, a mature Lightning Network protocol that has been solving this exact problem since 2020.

L402 (formerly LSAT) was developed by Lightning Labs to enable micropayments over HTTP using the Lightning Network. It combines authentication tokens with instant Bitcoin payments and uses the same HTTP 402 status code. Key differences from the failed BIP:

Instant settlement (milliseconds, not minutes)
Unlimited throughput (off-chain scaling)
Micropayment-friendly (can pay fractions of a satoshi)
Secure by design (Lightning’s atomic payment guarantees)
Production-ready and deployed (Lightning Loop, Aperture, and others)

According to a BingX explainer article from late 2025, Cloudflare was processing over one billion HTTP 402 responses per day using L402-compatible systems.

The BIP draft reads like it was written in a vacuum, unaware that the Bitcoin ecosystem already solved this problem years ago using the Lightning Network. That suggests either inadequate research or a fundamental misunderstanding of Bitcoin’s layer architecture.

The bigger picture: the battle for “agentic payments”

This rejected BIP is one data point in a larger competition to define how AI agents will make autonomous payments. Three standards are emerging.

Coinbase’s x402 uses stablecoins (USDC) on the Base blockchain. Launched in May 2025, it’s fast, cheap, and designed explicitly for API monetization. It trades Bitcoin’s properties (fixed supply, decentralized, censorship-resistant) for speed and price stability.

Lightning Labs’ L402 uses Bitcoin via the Lightning Network. The public specification has been available since 2020. It offers instant settlement, unlimited throughput, and genuine decentralization while maintaining Bitcoin’s core properties.

The rejected x402b proposal would have used on-chain Bitcoin. It combined the worst of both worlds: slow like base-layer Bitcoin, but with a fatal security flaw and no real advantages over either competitor.

The rejected proposal tried to compete where Bitcoin’s base layer is weakest (speed, throughput) while ignoring where it’s strongest (security, decentralization). Lightning already occupies the “fast Bitcoin payments” niche. On-chain Bitcoin is a settlement layer, not a payment rail for AI agent API calls.

What this tells us about Bitcoin’s layers

Bitcoin is often misunderstood as a single thing. It’s not. It’s a settlement layer with multiple payment layers built on top.

The base layer is slow and expensive, but maximally secure and decentralized. It’s good for final settlement of large amounts. It’s bad for buying coffee or paying for API calls.

The Lightning Network is fast, cheap, and scales well. It’s good for payments where speed matters. It trades some base-layer guarantees for practicality.

Sidechains and other layers take various approaches with different tradeoffs.

The rejected BIP tried to force a payment-layer use case onto the settlement layer. That’s like trying to use international wire transfers for vending machines. The problem isn’t that wires don’t work. It’s that they’re the wrong tool.

Sitamraju has been running Blockonomics, a Bitcoin payment processor, since 2014. The company successfully processes payments using conventional methods: generate unique addresses, wait for confirmations, keep it simple. That approach works because merchants can tolerate confirmation delays for finalizing sales.

But this BIP attempted something fundamentally different. High-frequency automated payments for AI agents can’t wait ten minutes per transaction. That’s why Lightning exists. That’s why Coinbase built x402 on a fast blockchain. The use case demands speed, and Bitcoin’s base layer cannot provide it.

The HTTP 402 ghost code

HTTP status code 402 “Payment Required” has been waiting in the wings since 1997, when it was reserved in the original HTTP/1.1 specification. The spec simply said: “This code is reserved for future use.”

The web’s creators anticipated that digital payments would become native to HTTP. They were right about the need, wrong about the timeline. Until cryptocurrency, there was no viable way to implement instant, low-friction micropayments over HTTP. Credit cards are too slow and expensive. Traditional digital payment systems require accounts, KYC, and centralized intermediaries.

For 28 years, HTTP 402 sat unused. Bitcoin enthusiasts discussed it as early as 2011, imagining scenarios where websites could charge micropayments per page view or API call. But implementation attempts repeatedly failed because on-chain Bitcoin is too slow for synchronous HTTP requests.

Lightning changed the equation. L402 made HTTP 402 viable using Bitcoin’s payment layer rather than its settlement layer. Coinbase’s x402 took a different approach, using stablecoins for speed at the cost of Bitcoin’s properties. And now we have this rejected BIP, a reminder that some problems have already been solved.

Not a failure of Bitcoin

This story isn’t about Bitcoin failing. It’s about a misunderstanding of what Bitcoin’s base layer is designed to do.

Bitcoin’s blockchain is optimized for decentralization, security, and resistance to censorship. Those properties require tradeoffs: slow block times, limited throughput, high confirmation latency. Those aren’t bugs. They’re design choices that make Bitcoin what it is.

When people complain that Bitcoin is “too slow for payments,” they’re half right. It’s too slow for some kinds of payments. It’s perfect for others. Lightning handles the fast stuff. The base layer handles final settlement. Different tools for different jobs.

The rejected BIP tried to make Bitcoin’s settlement layer do something it was never designed to do. The security vulnerability and process violations just made the rejection faster. Even if those issues had been fixed, the fundamental physics problem would remain: you cannot fit thousands of transactions per hour from a single merchant onto a blockchain that processes seven transactions per second globally.

What comes next

As of March 2026, the competition for “agentic payment” infrastructure is heating up. AI agents are starting to make autonomous financial decisions, and they need payment rails that work at machine speed. Bitcoin’s ecosystem has an answer: Lightning. The traditional finance world has answers too: stablecoins, credit card APIs, payment processors.

The question isn’t whether Bitcoin can compete in this space. Lightning already proved it can. The question is whether the Bitcoin community can communicate clearly about which layer solves which problem.

This rejected BIP might have saved everyone time if its author had asked the Bitcoin development community “Is this a good idea?” before writing the specification. The answer would have been swift and educational: “No, but here’s why Lightning solves your problem better.”

Sometimes the fastest path to learning is through rejection. This BIP’s four-hour lifespan taught a lesson worth remembering: know your layers, respect the process, and check if someone already solved your problem before reinventing the wheel.

Sources: Bitcoin BIP Pull Request #2112, BIP Draft: x402b Internet Payment Protocol, Coinbase x402 Protocol Launch Announcement, x402 V2 Launch Coverage - The Block, Lightning Labs L402 Specification, L402 Documentation - Lightning Labs, Original LSAT Announcement - Lightning Labs, What Is L402: Payments for AI Agents on Lightning Network, Interview with Shiva Sitamraju - Private Internet Access, SIGHASH Flags Documentation - Bitcoin Developer Guide, SIGHASH_SINGLE Vulnerability Writeup. Data/status as of March 4, 2026.

Published March 4, 2026