In the first week of August 2026, Gentoo's developers did something that would have been unthinkable a year earlier: they turned off their bug tracker. Not because it was compromised. Not because of a funding shortfall or a maintenance crisis. They took bugs.gentoo.org down because machines had made it unusable for humans.
Gentoo developer Michał Górny announced the shutdown in a single, exhausted sentence:
"I've taken #Gentoo Bugzilla down, because it was unusable anyway. No point in feeding the #LLM scrapers that are using thousands of different IPv4 addresses, with no obvious patterns I can see."
Read that second half carefully, because it is the whole story of modern web defense in one clause: thousands of different IPv4 addresses, with no obvious patterns. This is not a script kiddie hitting an endpoint from one server until it gets blacklisted. This is industrial-scale collection, distributed across more IP space than a human could ever enumerate, rotating fast enough that no blocklist can keep up. And it hit one of the oldest, most trusted public resources in open source — the bug tracker where twenty-five years of Gentoo's engineering problems, patches, and debugging discussions live.
What followed on Hacker News was a thread full of people who have clearly been watching this collision coming. And buried in it was the right answer — one that was already in the HTTP specification before most of the scrapers' operators were born.
Commenters immediately zeroed in on micropayments. One argued it was "time for micropayments integrated in the browser. Pay 5 cents to access each bug report." Another sharpened it: "0.05 cents even. The beautiful thing is, minuscule amounts of micropayments are already enough to fix the incentives."
That last sentence is the most important idea in the entire discussion. The point of micropayments here is not revenue. It is incentive correction. The problem was never that the scraper was malicious; it was that consuming the entire corpus was effectively free, while serving that corpus cost the operator real compute, bandwidth, and database load on both sides.
The thread's best objection came as a question: "do you happen to know a zero friction payment system that works internationally like the Internet itself?" The commenter's warning was sound — "even a minuscule amount of friction to access your service will cost you an overwhelming percentage of organic human visitors." Others raised the transaction-fee problem ("5 cents or less isn't enough to cover minimum transaction fees" / "Visa fees"), proposed GNU Taler and Chaum-style blind-signature e-cash, debated in-browser proof-of-work, and mentioned x402 — the HTTP 402 micropayment protocol — as a gate that would act "like a CAPTCHA," detecting bots on datacenter IPs and residential proxies "while humans living in peace without the site getting botted."
The thread ricocheted between these options and settled on none. That's the interesting part: the technical ingredients were all on the table. What was missing was a shared frame for what the gate is actually for.
To see why, it helps to name the structural problem precisely: cost asymmetry. Every request a scraper sends costs the operator something — compute, bandwidth, database queries, disk. To the operator it is pure cost with zero return. To the scraper, the same request costs essentially nothing: the marginal price of one more GET over an already-provisioned botnet is zero. The operator pays for both sides of every transaction. That asymmetry is the root cause, and every defense Gentoo tried was an attempt to raise the scraper's cost by adding friction. The problem is that friction is indiscriminate.
Every one of these is a hurdle. And every hurdle that deters a machine also deters a human, because humans are the ones who read CAPTCHAs, wait out proof-of-work, and get collateral damage on shared IPs. The zero-friction commenter was right: you cannot build a hurdle that only machines trip over. But you can build a price that only machines pay.
What if access cost is not a hurdle in front of the resource, but a property of the resource itself — priced into each request, so cheap that a human never notices it and so expensive in aggregate that a scraper cannot ignore it?
That is exactly what HTTP 402 Payment Required was designed for, and it has been sitting in the HTTP specification for nearly thirty years — since the HTTP/1.1 era. It was the joke status code: reserved, standardized, and used by nobody. A server could return it, but there was no client on earth that could respond to it. "Payment Required" had a status code but no protocol.
The x402 protocol is what finally gives 402 a wire format. Here is the flow, end to end:
GET /show_bug.cgi?id=752101.HTTP/1.1 402 Payment Required and a set of machine-readable headers:HTTP/1.1 402 Payment Required
X-402-Protocol: 1.0
X-402-Price: 0.0001
X-402-Asset: USDC
X-402-Chain: base
X-402-Receiver: 0x1a2b...c3d4
Content-Type: application/json
{ "error": "payment_required", "price": "0.0001", "asset": "USDC", "chain": "base" }Read the offer in plain English: "This resource costs 0.0001 USDC, to be paid on the Base chain, to this receiver address." That is a signed, self-describing price quote issued by the server itself. No signup, no API key, no checkout page — the offer is part of the HTTP response.
Authorization: x402 <signed-transaction>.200 OK with the resource. Settlement lands on-chain in seconds.Discovery is standardized too: a resource can advertise its price at /.well-known/x402, so agents and crawlers can fetch pricing before they even make the request, the way they fetch robots.txt today.
The entire exchange happens at the HTTP layer. No redirect to a payment page, no OAuth dance, no human entering a card number. The agent experiences it as a normal request/retry cycle — it asked, it paid, it got the data. The protocol was built for exactly the thing that caused Gentoo's shutdown: autonomous, non-human clients consuming resources.
This is the objection that comes up in every conversation, and it deserves a direct answer: humans shouldn't have to pay to read bug reports. True. And at these amounts, they won't.
A human browsing Bugzilla reads a handful of reports in a session. At 0.1 cent per request, that's under a cent — and it doesn't even need to be that, because the operator can simply not send 402s to traffic that looks human. Serve browsers with cookies and reasonable request rates 200 OK for free. Reserve the 402 for the clients that look like machines: datacenter IP ranges, no cookies, no referrer chain, request rates no human sustains.
Now do the arithmetic on the scraper's side. A training corpus run wants millions of pages. At 0.1 cent per page, a ten-million-page crawl costs $10,000. The economics invert completely: the operator is no longer paying compute and bandwidth to serve the scraper; the scraper is paying to consume. And here is the part that makes this fundamentally different from a paywall — the gate does not need to block anyone. It only needs to make mass consumption economically self-limiting. A bot that wants the whole corpus either pays for it, in which case the operator is compensated for the exact load it was absorbing for free before, or it decides the price is too high, in which case the load disappears. Either outcome is a win. The cost asymmetry is gone regardless.
That is the insight behind "0.05 cents even... minuscule amounts of micropayments are already enough to fix the incentives." The number is irrelevant. The pricing is the mechanism. You are not monetizing bug reports. You are metering the load back to the party that causes it.
The thread's best question — is there a zero-friction payment system that works internationally like the Internet — is the reason the answer is a protocol, not a payment company. x402's design puts the friction on the machine, not the human. A human does not hold a wallet, does not sign transactions, does not see a checkout. For a human visitor the experience is byte-for-byte identical: they request, they receive. The "friction" is entirely a property of the requesting client — the agent that carries the wallet. You get both desiderata at once — zero friction for humans and nonzero cost for scrapers — because you are not optimizing the gate; you are pricing it. The price is the gate.
This objection is correct for card rails, which is precisely why x402 settles in stablecoins on cheap L2s rather than through Visa. A USDC transfer on Base costs a small fraction of a cent, so a 0.1-cent price is economically coherent — and payments can be batched and aggregated to make the fee negligible against volume. The thread's detours into GNU Taler, Lightning, and mining-share schemes were all attempts to solve the same underlying problem: cheap, trust-minimized settlement with no third party standing in the middle. x402's bet is different and more pragmatic: reuse the stablecoins that already have liquidity, wallets, and fiat on/off-ramps, and let the settlement layer be boring. The innovation is not the money. The innovation is putting payment into the HTTP layer where the cost asymmetry lives.
The most important thing to say to anyone designing anti-scraper defenses in 2026: x402 is already deployed, at infrastructure scale, today.
cloudflare.pay identity handles. An operator can put an x402 gate in front of any endpoint at the CDN edge, with no new infrastructure of their own.This is not a whitepaper. It is working plumbing that an open-source project of Gentoo's budget could adopt in a day of work: a middleware rule that returns 402 for requests that look machine-like, a /.well-known/x402 endpoint announcing the price, and a wallet address to receive settlement. The pieces are all off the shelf.
Concretely, a Bugzilla-shaped deployment would look like this:
200 OK, exactly as today. Open-source ethos preserved.And crucially, this works even when the traffic is completely anonymous and distributed across thousands of residential IPs — which is the exact case that broke every other defense. The gate does not need to identify the scraper. It only needs to price it. That is the property CAPTCHAs, blocklists, and rate limits fundamentally lack.
Gentoo's Bugzilla is not an isolated incident. It is the preview of a pattern: every public, high-value corpus — bug trackers, wikis, mailing-list archives, documentation, forums — is sitting behind the same cost asymmetry, feeding the same industrial-scale collection. The reflexive response is to wall everything behind logins, IP blocks, and CAPTCHAs — to make the internet less open because machines made it unusable.
x402 offers a third path, and it is the rare case where the technically elegant answer is also the honest one: keep the resource free to humans and metered to machines. Not with a hurdle that punishes both, but with a price that only the load-causer pays. The status code has been there since the beginning of the web. The protocol that finally makes it usable is here now, and the largest infrastructure companies on the planet have standardized around it.
The question the Gentoo shutdown forces is not whether to charge. It's whether we'll keep quietly paying for other people's crawls — in compute, bandwidth, and shuttered public resources — or finally put the price where the load is. The machines that broke the web's openness can also be the ones that fund its maintenance. The wire format for that exchange is already in the spec.
Sources: Michał Górny's announcement, Hacker News discussion, Gentoo closes Bugzilla coverage, x402 protocol, Cloudflare Wallets announcement