Chapters 1 and 2 demonstrated USDC transfers on Solana — a buyer sends stablecoins to a seller's wallet. The transfer worked, the recipient was flexible, and the on-chain verification was solid. But those chapters were fundamentally about moving money. They didn't answer the harder question: what happens after the money moves?
This is where x402 becomes a protocol, not just a transfer mechanism. The "402" in x402 refers to HTTP status code 402 — "Payment Required" — a response code that has been reserved in the HTTP specification since 1997 but was never given a standard implementation. Until now.
Chapter 3 builds the simplest possible paywall: a server that locks content behind a payment, accepts USDC as the key, and remembers that you paid.
The paywall introduces one endpoint that behaves differently depending on what the buyer sends. The buyer's browser calls it up to three times. The USDC transfer itself is identical to Chapters 1 and 2 — the new part is the HTTP layer that wraps around it.
| Request | Purpose | Response |
|---|---|---|
GET /content/:id — no cookie, no signature |
First visit. No valid access cookie, so the server quotes a price instead of serving content. | 402 + PAYMENT-REQUIRED |
GET /content/:id — PAYMENT-SIGNATURE header |
Buyer retries with a signed payment. Server checks the transaction, then has the facilitator verify and settle it on-chain. | 200 + PAYMENT-RESPONSE + Set-Cookie (settled) or 402 (invalid) |
GET /content/:id — access cookie |
Return visit. Cookie is present and valid. Server serves the full content without requiring payment. | 200 (content) |
After the server verifies the on-chain payment, it sets a signed cookie — x402_access — with a 24-hour expiration. On subsequent visits, the browser sends this cookie automatically. The server validates the signature, checks the expiration, and serves the content without re-checking the blockchain.
This means:
Traditional paywalls force a binary choice on readers: subscribe for $10/month (and get access to everything, whether you read 1 article or 100) or get nothing. This creates two problems:
| Problem | Subscription Model | x402 Micropayment Model |
|---|---|---|
| Casual reader | Bounces — $10/month for one article is absurd | Pays $0.25, reads the article, moves on |
| Heavy reader | Great deal at $10/month for 100 articles | Pays $25/month — more expensive, but fair |
| Publisher revenue from casual readers | $0 — they never subscribed | $0.25 per article — actual revenue from every reader |
The x402 paywall captures the 95% of readers who would never subscribe but would happily pay a quarter to read one article. That's the addressable market that subscription paywalls leave on the table.
When the server receives a signed payment, it doesn't trust the buyer's claim. It checks the transaction itself, then has the facilitator verify and settle it against the Solana blockchain, confirming three things:
If all three checks pass, the payment is confirmed. The server doesn't need to trust the buyer, the wallet, or any intermediary. The blockchain is the receipt.
| Layer | Chapter 2 | Chapter 3 |
|---|---|---|
| Payment (USDC transfer) | Buyer selects recipient, signs tx | Identical |
| Verification | Client-side confirmation | Server-side on-chain check |
| Access control | None — open page | HTTP 402 + cookie-based unlock |
| Return visits | Not applicable | Cookie valid for 24 hours |
Chapters 1 through 3 all run on Solana. But real buyers hold USDC on different networks — Base, Polygon, Arbitrum, Ethereum. A publisher can't ask every reader to bridge their funds to Solana first. The payment protocol needs to work across chains.
In Chapter 4: Multi-Chain, we extract the payment logic into a reusable framework with chain adapters — one adapter per network, one unified verification algorithm. Adding a new blockchain becomes a configuration change, not a rewrite.