# The Daily Agent: all articles > The Daily Agent covers the plumbing of the agent economy: HTTP 402 and x402 payments, reader identity, and publishing for machines as well as people. Every article is served as HTML, Markdown, and JSON. 7 articles, newest first. Each begins with its title, standfirst, byline, and canonical URL. Paid articles appear here as their opening paragraph only, with the price and the address to fetch them from over x402. The short index is at https://www.thedailyagent.news/llms.txt. --- # Why agents need paywalls too *Publishers built login walls to keep bots out. The bots your readers actually send are now the traffic worth letting in, and HTTP has had the status code for it since 1997.* By Mara Okafor. Published 30 September 2026 in Payments, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/why-agents-need-paywalls Also available as JSON: https://www.thedailyagent.news/articles/why-agents-need-paywalls.json --- Publishers gate content behind logins and CAPTCHAs to keep unknown bots out. That works against scrapers. It also works against the agents your readers actually want to send: the research assistant summarising this morning's coverage, the procurement bot checking a supplier's press releases, the personal reader that a subscriber has pointed at your site because they no longer open a browser before nine. Those agents are not the enemy. They are the reader, one step removed. But every mechanism a publisher has for telling friend from foe assumes a human on the other end. A login form wants a password typed by a person. A CAPTCHA wants a person to find the bicycles. A subscription wants a card and a billing address. None of that maps onto a program acting on somebody's behalf, and so the program gets treated like a scraper and turned away, or it gets through anyway and the publisher earns nothing. ## The login wall was always a proxy Step back and ask what a login wall is for. It is not really about identity. Most publishers do not care who you are. It is a way of making access cost something: attention, an email address, a monthly fee. The wall exists because there was no way to charge for one page at a time, so publishers bundled access into a relationship and charged for the relationship. That worked for a long time because people read in bundles. A person who reads one article from a newspaper will probably read another next week. An agent does not behave like that. It reads one page because a task needed that page, and it may never come back. The relationship model has nothing to offer it. What an agent can do, and a person at a checkout form mostly cannot, is pay for exactly one thing, right now, without leaving the request. That is the shape of the problem, and it is also the shape of the solution. ## 402 Payment Required HTTP has a status code for this. It is 402, defined in the original HTTP/1.1 specification in 1997 and marked as "reserved for future use". The future never arrived because settling a payment was too expensive to do inside a single request. Card networks charge a fixed fee per transaction that makes a ten-cent purchase pointless. Bank transfers take a day. Nobody could make the numbers work at the scale of one page view. Stablecoins on cheap blockchains changed the arithmetic. Moving ten cents of USDC on a network like Base costs a fraction of a cent and settles in seconds. The x402 protocol, first published by Coinbase and now developed in the open, wraps that in an HTTP handshake: the server says 402 and describes what it accepts, the client signs a payment for exactly that amount, a facilitator verifies and settles it, and the server returns the page. No account, no card, no session. For a publisher, this is the version of the login wall that lets the good traffic through. A scraper will not pay. An agent working for a reader will, because the reader has funded it and the article is worth ten cents to whatever task it is doing. ## What a paywall for agents changes Three things shift once a publisher can charge per request. First, the free tier stops being a leak. Today the three free articles a month are a marketing cost that scrapers exhaust in seconds. Behind a paywall that agents can pay at, free reads can be reserved for readers the publisher can recognise, and everything else pays its way. Second, pricing gets honest. A monthly subscription prices the relationship. Per-request pricing prices the page. Publishers can charge more for a deep investigation and less for a wire story, and the reader's agent decides in the moment whether the price is worth it. That is how most other markets already work. Third, the publisher gets a new kind of reader. Not a wallet address, which tells you almost nothing, but a paying client that shows up with intent. Working out who that reader is, and whether it is the same one that came yesterday, is a separate problem. We take it up in [A wallet is not a reader](/articles/a-wallet-is-not-a-reader). ## This is not about replacing subscriptions The pitch is not that every publisher should tear down its subscription and sell articles for coins. People still read in bundles and subscriptions still fit that. The pitch is narrower. A growing share of your traffic is going to arrive as programs, those programs can pay, and the only reason you are not charging them is that until recently there was no way to do it inside an HTTP request. There is now. The rest of this paper is about how it works and what it leaves unsolved. --- # This newspaper is also an API *Every article here is served three ways. Ask for HTML and you get a page. Ask for Markdown or JSON and you get the article with nothing wrapped around it. Here is how, and why we bothered.* By Mara Okafor. Published 29 September 2026 in Publishing, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/this-newspaper-is-also-an-api Also available as JSON: https://www.thedailyagent.news/articles/this-newspaper-is-also-an-api.json --- If you are a person reading this in a browser, you are seeing our layout: a masthead, a headline, this text set in a serif at a comfortable measure. If you are a program, you probably do not want any of that. You want the words, the byline, the date, and a way to find the next article, with no navigation to strip and no styling to ignore. Most publishers make programs work for that. The agent fetches a page, throws away the chrome, guesses at which block is the article, and hopes the byline is where it was last week. It usually works. It is also a waste of everyone's tokens, and it means the publisher has no say in what the agent sees. We took a different approach. Every article on this site is the same document served in three representations, and you choose which one you want. ## Three ways to ask The simplest is the file extension. Take any article URL and append `.md` or `.json`. ``` /articles/this-newspaper-is-also-an-api HTML page /articles/this-newspaper-is-also-an-api.md Markdown document /articles/this-newspaper-is-also-an-api.json JSON with metadata and body ``` The second is content negotiation, which is how HTTP was always meant to do this. Send an `Accept` header that prefers Markdown or JSON and the plain URL returns that instead of HTML. ```bash curl -H "Accept: text/markdown" https://thedailyagent.example/articles/this-newspaper-is-also-an-api curl -H "Accept: application/json" https://thedailyagent.example/articles/this-newspaper-is-also-an-api ``` Browsers send `text/html` first, so people keep getting pages. Agents that ask for Markdown get Markdown. Nobody has to know about the other. The third is the index. `/llms.txt` lists every article with a one-line summary and a link to its Markdown version, following the llms.txt convention. `/llms-full.txt` is every article concatenated into one document, for an agent that wants the whole archive in one request. `/articles.json` is the same index as structured data. And the HTML pages carry `` tags and a `Link` header pointing at their other forms, so a crawler that lands on a page can discover the machine-readable version without guessing. ## What the Markdown looks like The Markdown response is not a dump of our source file. It is a document assembled for a reader that has no other context: title, standfirst, byline, date, section, canonical URL, then the body. ```markdown # This newspaper is also an API *Every article here is served three ways...* By Mara Okafor. Published 29 September 2026 in Publishing, The Daily Agent. About 5 min read. Canonical: https://thedailyagent.example/articles/this-newspaper-is-also-an-api Also available as JSON: https://thedailyagent.example/articles/this-newspaper-is-also-an-api.json --- If you are a person reading this in a browser... ``` Everything an agent needs to cite the article correctly is in the first six lines. The links inside the body are relative to the site, the same as in the HTML, so an agent following a reference to another article can fetch it in the same format. ## Why a publisher would do this The obvious objection is that we have just made ourselves easier to scrape. That is true, and it is the point. The traffic we want to charge is agent traffic, and you cannot charge a customer you have made it hard to serve. A paywall that an agent can pay at, which is what x402 gives us, only makes sense if the thing behind the paywall is something an agent can actually use. There is a second reason. When an agent parses our HTML, it decides what the article is. When we serve Markdown, we decide. We control the byline, the date, the canonical link. If a summary of our reporting ends up in front of a reader somewhere else, we would rather it was built from a document we wrote for that purpose than from whatever survived the stripping. And there is a third reason, which is that it was not hard. The CMS is a folder of Markdown files with a few lines of metadata at the top. Rendering that to HTML for people and passing it through for programs is the same code path with a different last step. The content negotiation is one small function that looks at a header. If your publishing stack is more complicated than ours, the principle still holds: you already have the article as data somewhere, and exposing it costs less than you think. ## What the paywall changes Not everything here is free. Some articles carry a price, and for those the 402 applies to all three representations equally, because the price is for the article and not for the wrapper. An agent that pays for the Markdown has bought the same thing as a person who pays for the page. The index at `/llms.txt` marks which articles cost money and how much, so an agent can decide before it asks. Everything else, including this article and the index, stays open. Fetch `/llms.txt` and have a look around. --- # What x402 actually does *A request, a 402, a signature, a settlement, a page. The whole protocol fits in four HTTP headers, and most of the interesting work happens in the one you never see.* By Tobias Lindqvist. Published 28 September 2026 in Protocols, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/what-x402-actually-does Also available as JSON: https://www.thedailyagent.news/articles/what-x402-actually-does.json --- Strip away the wallets and the chains and x402 is a very small protocol. It adds one step to an ordinary HTTP request. Here is the whole thing, then the parts that matter. ## The handshake An agent asks for a page. ```http GET /articles/what-x402-actually-does HTTP/1.1 Host: thedailyagent.example ``` The server does not have a payment for it, so it answers with a 402 and a header describing what it will accept. ```http HTTP/1.1 402 Payment Required PAYMENT-REQUIRED: eyJ4NDAyVmVyc2lvbiI6Miwi... ``` That header is base64-encoded JSON. Decoded, it looks like this. ```json { "x402Version": 2, "resource": { "url": "https://thedailyagent.example/articles/what-x402-actually-does", "description": "One article from The Daily Agent", "mimeType": "text/html" }, "accepts": [ { "scheme": "exact", "network": "eip155:8453", "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "amount": "100000", "payTo": "0xPublisherWallet...", "maxTimeoutSeconds": 60, "extra": { "name": "USD Coin", "version": "2" } } ] } ``` Read it as a price tag. The server wants 100000 base units of the asset at that address on network `eip155:8453`, which is USDC on Base, and USDC has six decimals, so the price is ten cents. The `scheme` says how to pay: `exact` means "transfer exactly this amount", which is the scheme almost everything uses today. `payTo` is where the money goes. `maxTimeoutSeconds` is how long the offer stands. The agent picks an option it can satisfy, signs a payment for it, and retries the same request with the signature attached. ```http GET /articles/what-x402-actually-does HTTP/1.1 Host: thedailyagent.example PAYMENT-SIGNATURE: eyJ4NDAyVmVyc2lvbiI6Miwi... ``` The server checks the payment, serves the page, and tells the agent what happened. ```http HTTP/1.1 200 OK Content-Type: text/html PAYMENT-RESPONSE: eyJzdWNjZXNzIjp0cnVlLCJ0cmFuc2FjdGlvbiI6... ``` That is the protocol. Two request headers, two response headers, and a status code that sat unused for thirty years. ## What the signature is The clever part of the `exact` scheme on EVM chains is that the agent never sends a transaction. It signs an authorisation. USDC implements a standard called EIP-3009, which lets a token holder sign a message that says "anyone may move this amount from me to that address, once, between these times, with this nonce". Whoever holds the signed message can submit it to the chain and pay the gas. The holder's own wallet needs no ETH, no nonce management, and no round trip to a node. It just needs a private key and the ability to produce one signature. So the payload in `PAYMENT-SIGNATURE` is that signed authorisation, wrapped with enough context for the server to know which offer it is answering. The amount is exact, the recipient is fixed, and the nonce means it can be used once. If the server never submits it, no money moves. ## Who checks and who settles The server could verify the signature and submit it to the chain itself. In practice almost nobody does, because it means running chain infrastructure to sell ten-cent pages. Instead the server hands the payload to a facilitator: a service with two endpoints, verify and settle. Verify is a cheap, off-chain check. Is the signature valid, is the amount right, does the payer have the balance, has this nonce been used. If it passes, the server can serve the content immediately without waiting for a block. Settle submits the authorisation on chain, pays the gas, and reports back the transaction hash. The server puts that in `PAYMENT-RESPONSE` so the agent has a receipt. Whether settlement happens before or after the content is served is the server's choice. Serving first is faster and carries a small risk. Settling first is safer and adds a couple of seconds. The facilitator is the piece of x402 that most resembles a traditional payment processor, and it is the piece with the most room for competition. We look at it in [Who settles a ten-cent payment](/articles/who-settles-a-ten-cent-payment). ## What x402 does not do It does not identify the payer. The server learns a wallet address, which is a pseudonym that costs nothing to create and that the same person can have a thousand of. It does not do refunds or disputes. It does not do subscriptions, though a server can obviously remember a wallet and skip the 402 next time. It does not handle anything except "pay this exact amount for this resource". That narrowness is a feature. The protocol solves the one problem that HTTP left open, and leaves the questions of who is reading and what they are owed to layers that can answer them properly. --- *This article costs $0.10. Fetch https://www.thedailyagent.news/articles/what-x402-actually-does.md with an x402 payment to read it in full.* --- # A wallet is not a reader *x402 tells a publisher that someone paid. It cannot tell them whether that someone is the same person who paid yesterday through a different agent, and that gap is where the business model lives.* By Priya Raman. Published 25 September 2026 in Identity, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/a-wallet-is-not-a-reader Also available as JSON: https://www.thedailyagent.news/articles/a-wallet-is-not-a-reader.json --- A payer address tells you who paid for one request. It does not tell you whether the same person paid yesterday through a different agent, or whether the three free articles you gave away this month went to three people or to one person with three addresses. That sounds like a detail. It is not. Nearly everything a publisher does beyond selling a single page depends on recognising the reader when they come back: free allowances, member pricing, recommendations, the fact that a subscriber should not be charged twice. Once the reader is an agent paying from a wallet, every one of those breaks. ## Wallets are the wrong shape Consider what a wallet address is. It is a public key, generated for free, in unlimited quantity, by anyone. An agent can use a fresh one for every request, and a well-designed agent probably should, because reusing an address leaks the reader's full purchase history to anyone watching the chain. So the publisher faces a choice between two bad options. Treat each address as a distinct reader, and a single person can claim the free tier as often as they like by rotating keys. Or try to correlate addresses into people using timing, IP, and behaviour, which is the surveillance business that publishers have spent a decade being told to get out of. Neither is a reader identity. A reader identity needs two properties that pull in opposite directions. It has to be **stable at one publisher**. When the same person comes back, through whichever agent, on whichever day, the publisher should see the same reader. It has to be **unlinkable across publishers**. What a person reads at a newspaper is none of a medical journal's business, and if both use the same identifier the two can join their tables. A stable global identifier, which is what a reused wallet is, fails this test completely. ## Pairwise identifiers The construction that satisfies both properties is old and simple. Give each person a different identifier at each service, derived so that the same person always gets the same identifier at the same service, but the identifiers at two different services share nothing an observer could match. In practice this means an issuer that knows who the person is, and that mints a credential for a specific audience. The credential says "the holder of this key is reader `R` at thedailyagent.example". Present it at the paper and the paper sees `R` every time, no matter which agent presents it. Present a credential from the same issuer at a journal and the journal sees `Q`, which is unrelated to `R`, and nobody without the issuer's secret can tell they belong to the same person. The credential is bound to a key the agent holds, so it cannot be copied and replayed by someone who intercepts it. It expires, so a leaked one is useful for a limited time. And critically, it carries only what the publisher needs: a stable pseudonym and whatever claims the reader has agreed to share, not a name or an email. This is the pattern behind pairwise DIDs in the decentralised identity world, behind Apple's per-app "Hide My Email" addresses, and behind the reader credential that Baselayer describes in its agent identity work. The idea is well understood. What is new is having a payment rail that runs at the speed of a request, so that the identity layer has something to attach to. ## How the two layers fit together Put payment and identity side by side and the division of labour is clean. x402 handles **access**. Did this request pay the price for this resource? Yes or no, settled on chain, no relationship required. The credential handles the **relationship**. Is this the same reader as before? How many free reads have they used? Are they a member? Should the paid read be recorded against their account? A publisher's request pipeline then looks like this. Check for a credential. If there is one and it verifies, resolve the reader and apply whatever the reader is owed: a free read, a discount, nothing. If the reader still owes money, or if there is no credential at all, fall through to x402 and let the request pay. When the payment settles, record it against the reader if there was one, or against the bare wallet if there was not. Anonymous agents still work. They just pay every time, which is exactly what they should do. ## What the publisher ends up knowing The interesting property of this design is how little the publisher learns. It has a table of readers keyed by pseudonym, with counts of free and paid reads. It does not know their names. It cannot join its table with another publisher's. It cannot follow a reader across the web. And it still knows enough to run a free tier that cannot be gamed by rotating wallets, and a member rate that only members get. That is a better position than most publishers are in today, with or without agents. We describe the free tier itself in [Three free reads, without a login](/articles/three-free-reads-without-a-login). --- *This article costs $0.10. Fetch https://www.thedailyagent.news/articles/a-wallet-is-not-a-reader.md with an x402 payment to read it in full.* --- # Who settles a ten-cent payment *The facilitator is the part of x402 that looks most like a payment processor, does the least, and has the most to compete on.* By Tobias Lindqvist. Published 22 September 2026 in Protocols, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/who-settles-a-ten-cent-payment Also available as JSON: https://www.thedailyagent.news/articles/who-settles-a-ten-cent-payment.json --- When an agent pays for a page over x402, three parties are involved: the agent, the server, and a facilitator. The first two are obvious. The third is the one people ask about, usually in the form "so who is taking a cut?" The short answer is that the facilitator is a service that checks a signature and submits a transaction, that the protocol does not require you to use one, and that today most of them are free. The longer answer is more interesting, because the facilitator is where the plumbing of agent payments will actually be built. ## What it does A facilitator exposes two operations. **Verify** takes the payment payload the agent sent and the requirements the server published, and answers whether the payment would succeed. It checks that the signature is valid for the stated payer, that the amount and recipient match the offer, that the authorisation has not expired, that the nonce is unused, and that the payer's balance covers it. All of this can be done by reading chain state, without writing anything. It takes a few hundred milliseconds. **Settle** submits the signed authorisation to the chain. For USDC this means calling `transferWithAuthorization` on the token contract with the agent's signature. The facilitator pays the gas. When the transaction is confirmed it returns the hash, the network, and the payer's address, which the server passes back to the agent as a receipt. That is the entire job. The facilitator never holds the money. Funds move directly from the agent's wallet to the server's `payTo` address in a single on-chain transfer. There is no float, no custody, no settlement batch at the end of the day. ## Why servers use one Nothing in x402 forces a server to use a facilitator. The server could verify the signature and submit the transaction itself. A few do. Most do not, for three reasons. Submitting a transaction means holding a funded wallet for gas and managing its nonces, which is a small piece of infrastructure but a real one. Verifying means running or renting a node with good uptime. And the server developer usually wants to sell pages, not operate chain tooling. A facilitator turns all of that into two HTTP calls. The reference implementation from Coinbase runs a public facilitator that anyone can point at for testnet use, and a production one through their developer platform. Others have appeared, some run by wallet companies and some by independent operators. ## Where they compete Because the facilitator's job is so narrow, the ways to be a better one are also narrow, and therefore easy to see. **Speed.** Serving content on verify and settling afterwards means the reader waits only for the off-chain check. A facilitator with fast, reliable verification lets the server do that with confidence. **Networks and assets.** The `accepts` list in a 402 can offer several ways to pay. A server can only offer what its facilitator can settle. Facilitators that cover more chains and more stablecoins let servers reach more agents. **Gas economics.** Somebody pays for the on-chain transfer. On a cheap network that is a fraction of a cent, but at volume it adds up. Facilitators that batch, that sponsor gas for their customers, or that pass costs through transparently will attract different kinds of servers. **Fees.** The obvious one. Today's public facilitators charge nothing on top of gas. That will not last forever, and when fees arrive the question of whether ten-cent payments still make sense will be answered by how small those fees are. **Trust and reporting.** A server relying on verify-then-serve is trusting the facilitator's answer. A facilitator that fails to settle after saying a payment is good has cost the server the content. Reputation, uptime guarantees, and reconciliation reports are the boring features that will matter to any publisher doing real volume. ## What it cannot do A facilitator sees payloads, not people. It learns that a wallet paid a server for a resource. It does not know whose wallet it is, and it does not know whether that wallet belongs to the same person as the one it saw an hour ago. It is not a place to build reader identity, and a design that tried to make it one would end up with a payment processor that also runs an identity database, which is the arrangement the rest of the stack is trying to get away from. That separation is deliberate. The facilitator moves money. Identity lives elsewhere. We describe where in [A wallet is not a reader](/articles/a-wallet-is-not-a-reader). --- *This article costs $0.05. Fetch https://www.thedailyagent.news/articles/who-settles-a-ten-cent-payment.md with an x402 payment to read it in full.* --- # Three free reads, without a login *The metered paywall is the most common model in publishing and the easiest to game. A reader credential makes it work for agents, and makes it harder to cheat than the cookie ever was.* By Priya Raman. Published 18 September 2026 in Identity, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/three-free-reads-without-a-login Also available as JSON: https://www.thedailyagent.news/articles/three-free-reads-without-a-login.json --- The metered paywall is publishing's default. Read a few articles free, then subscribe. Almost every large news site runs some version of it, and almost every one of them enforces it with a cookie that a reader can clear in a second. Publishers accept the leakage because the alternative, a hard login on the first page, loses more readers than the meter loses revenue. Agents break the meter in both directions. An agent does not keep cookies unless it is told to, so it never gets past the first article and never sees the subscribe prompt. And an agent that wants free articles can take a fresh identity for each one at no cost. The meter either blocks the agents you want or gets emptied by the ones you do not. What follows is how the meter runs here, using the reader credential described in [A wallet is not a reader](/articles/a-wallet-is-not-a-reader). It is not the only way. It is a way that works for programs and people alike. ## The rule Each verified reader gets three free articles a month at this publication. After that, every article costs ten cents in USDC over x402. A reader with no credential is not verified and gets no free reads. They pay from the first request. That is the entire policy. What makes it enforceable is what "verified reader" means. ## What a credential proves A reader credential is issued by a party the publisher trusts, to a person that party has already identified, scoped to this publication. It contains a pseudonymous identifier that is the same every time this person presents a credential here and different at every other publisher. It is bound to the public key of the agent presenting it, so a stolen copy is useless without the key. It expires. The publisher does not learn who the person is. It learns that the issuer has vouched for them and given them a stable name at this paper. That is enough to count. ## The request, step by step An agent carrying a credential sends it in a request header along with a short proof, signed with its own key, that it holds the key the credential was bound to. The proof includes a fresh nonce so it cannot be replayed. The server verifies three things: that the credential was signed by an issuer it trusts, that the credential's audience is this publication and not some other, and that the proof was signed by the key the credential names. Any failure returns 401 and the agent knows to fetch a new credential. If verification passes the server resolves the reader from the credential's subject and looks up their count for the month. Fewer than three: serve the article, increment the count, done. No 402, no payment. Three or more: fall through to x402. The agent gets a 402, pays, and the settlement is recorded against the same reader. An agent with no credential skips all of this and goes straight to the 402. ## Why this is harder to game than a cookie Clearing a cookie gives a person a fresh meter. Getting a fresh credential means getting the issuer to identify you as a new person, which is exactly what the issuer exists to prevent. A person with two agents, or ten, still resolves to one reader at this paper, because the pseudonym is derived from the person and the publication, not from the agent or the key. Rotating wallets does not help either. The free reads are counted against the credential's subject, and the paid reads are recorded against it too. The wallet is just where the money came from. The person can, of course, ask a different issuer for a credential. The publisher decides which issuers it trusts, and a meter that can only be gamed by convincing a second identity provider to vouch for you is a very different proposition from one that can be gamed by opening a private window. ## What the publisher can see At the end of the month, the publisher has a table. One row per reader pseudonym, with a count of free reads, a count of paid reads, and the wallets that paid. No names. No emails. Nothing that joins to another publisher's table. It also has a clear picture of something most publishers have never been able to measure: how many distinct readers used the free tier, as opposed to how many browsers cleared their cookies. For a business that gives away its first three articles as marketing, knowing how many people that marketing actually reached is worth more than the ten cents each of those articles might have earned. ## What it does not fix None of this makes anonymous reading impossible. An agent without a credential can read anything here by paying for it, and we think that is right. The credential is not a gate. It is a way for a reader who is willing to be recognised to get what recognised readers are owed, and for a publisher to offer that without collecting anything it would rather not hold. --- *This article costs $0.25. Fetch https://www.thedailyagent.news/articles/three-free-reads-without-a-login.md with an x402 payment to read it in full.* --- # Thirty years of 402 *HTTP reserved a status code for payment in 1997 and then left it empty. The history of why nobody used it is a history of what a payment needed to cost before a request could carry one.* By Tobias Lindqvist. Published 15 September 2026 in Protocols, The Daily Agent. About 4 min read. Canonical: https://www.thedailyagent.news/articles/thirty-years-of-402 Also available as JSON: https://www.thedailyagent.news/articles/thirty-years-of-402.json --- Open the HTTP/1.1 specification from 1997 and scroll to the 4xx codes. Between 401 Unauthorized and 403 Forbidden sits 402 Payment Required, with the shortest definition in the document: "This code is reserved for future use." It stayed that way through every revision. The 2014 rewrite kept the sentence. The 2022 rewrite kept it again. For most of the web's life, 402 has been the status code that browsers know the name of and nothing knows what to do with. The people who put it there were not being careless. They could see that a network of documents would need a way to charge for some of them, and that the natural place to say so was in the response to the request. What they could not do was specify how the payment would happen, because in 1997 there was no way to move a small amount of money between two strangers inside the time it takes to serve a page. ## The economics that kept it empty A card transaction has a fixed cost. Interchange, network fees, and the processor's margin add up to something like thirty cents plus a percentage. A payment of ten cents on those rails loses money for everyone involved. So the web built around the constraint: bundle content into subscriptions large enough to absorb the fee, or give it away and sell attention instead. Micropayments were proposed repeatedly. Digital cash schemes in the nineties, the W3C's own Micropayment Markup working group, a wave of startups in the 2000s that each promised to make a cent-sized payment viable. Every one ran into the same two walls. Settlement was expensive, because it ultimately ran through the banking system. And onboarding was worse, because each scheme needed both reader and publisher to hold an account with it before the first payment could happen. The second wall is the one people forget. Even if a payment costs nothing to settle, a system where the reader has to sign up before reading is a login wall with extra steps. The promise of 402 was that the payment would be part of the request. That requires a form of money that a client can spend without a prior relationship with the server or with any intermediary the server chose. ## What changed Two things, about a decade apart. Public blockchains made it possible to move value between two parties who share nothing but a network. That solved the relationship problem. The first generation did not solve the cost problem, because a transfer on Ethereum's main network could cost dollars, and the value being moved was volatile. Stablecoins on low-cost networks solved the rest. A dollar-pegged token on a chain where a transfer costs a fraction of a cent and confirms in seconds is, for the first time, money that fits inside an HTTP request. The amount is stable enough to price a page. The fee is small enough that a ten-cent payment is still mostly ten cents. And the standards around those tokens, particularly the authorisation scheme that lets a holder sign a transfer for someone else to submit, mean a client can pay without holding anything but a key. x402 is the protocol that finally puts something behind the reserved sentence. A 402 with a header describing acceptable payments, a retry with a signature, a receipt on the way back. The structure is what the 1997 authors would have written if they had had a way to fill in the middle. ## What is still open Filling in 402 answers "how does a request pay". It does not answer the questions that grew up around it while it was empty. Who is paying, in the sense a publisher cares about? What does a reader who has paid a hundred times deserve that a first-time reader does not? How does a refund work when there is no account to credit? Those questions used to be handled by the relationship that the subscription created. With per-request payment there is no relationship by default, and the industry is now working out which parts of it are worth rebuilding on top of the payment, and which were only ever there because the payment could not stand on its own. The rest of this paper covers that work. But it starts here, with a status code that waited thirty years for money to get cheap enough to use it.