For twenty-five years, HTTP has reserved status code 402: Payment Required — defined in the spec, waiting for a future where an implementation of digital cash was feasible and practical.

This site now uses real simple licensing (RSL).

As of this month, ryanwold.net does three new things:

1. States its terms in a machine-readable way. Every page, the RSS feed, and robots.txt now point to /license.xml, an RSL 1.0 license describing exactly what's free, what's licensed, and how to pay.
2. Accepts payment from software. The machine-readable API answers unpaid requests with HTTP 402 and instructions. An agent pays a few thousand satoshis in BSV, presents the transaction id, and gets access — no account, no API-key email, no human in the loop.
3. Shows its credits to humans. Every entry now carries a visible credit block: byline, copyright, CC BY-NC 4.0, and a tip jar.

This is an experiment in precedent, not a business model. Let me explain the reasoning.

robots.txt is an ask. This is an offer.

Like many sites, my robots.txt disallows AI training crawlers — GPTBot, CCBot, and their cousins. But a Disallow line is a request with no terms attached. It gives a well-behaved crawler exactly two options: go away, or ignore me. There's no third door marked "here's what access costs."

Really Simple Licensing — from the folks who brought you RSS — adds that door. It's an XML vocabulary for saying, in a way software can parse: search indexing and AI retrieval are free with attribution; AI training and inference input are licensed per-crawl; here's the price; here's how to pay; here's the human-readable license if you're a person. Yahoo, Reddit, Medium, and O'Reilly are adopting it. My robots.txt still says Disallow — the blocks remain the default answer for crawlers that don't engage with the terms. But now the terms exist, in a place and format built for machines.

Why BSV, and why 402

When an agent requests my content API without paying, it gets:

HTTP/1.1 402 Payment Required X-Payment-Network: bsv-mainnet X-Payment-Address: <address> X-Payment-Amount-Sats: 10000 Link: <https://ryanwold.net/license.xml>; rel="license"; type="application/rsl+xml"

plus a JSON body spelling out the deal: 10,000 satoshis buys 100 requests over 30 days. Pay the address from any BSV wallet, then redeem the transaction id:

curl -X POST https://ryanwold.net/api/v1/payments \ -H 'Content-Type: application/json' \ -d '{"txid":"<your-txid>"}'

You get back a bearer token. Or skip the round trip entirely — send X-BSV-Payment: <txid> on the content request itself and the server verifies, grants, and serves in one shot.

Why BSV? Because per-request payments need fees that round to zero, and settlement fast enough that a 0-confirmation transaction is acceptable risk when the stakes are a third of a cent. BSV was built for exactly this shape of transaction, and I've been writing about it here for years. The larger agentic-payments world is converging on x402 — USDC micropayments over this same 402 pattern, now a Linux Foundation project with tens of thousands of active agents. My license file declares x402 as planned; the terms are interoperable even where my rails aren't yet. The pattern is the point, not the coin.

Design choices worth stealing

Watch-only. The server holds a receive address and nothing else. No private keys, no wallet software, no custody. Verification is a lookup against WhatsOnChain's public API: does this transaction pay at least this many sats to this address? The blast radius of a total server compromise, payments-wise, is zero.

Zero-conf, on purpose. I accept unconfirmed transactions. Someone could theoretically double-spend me out of a hundred API requests, at the cost of more effort than the content is worth. Pricing the fraud below the cost of committing it is an old and honorable security model.

Replay-proof by database constraint. A transaction id redeems exactly once — a unique index, not a protocol. Try to redeem it twice and you get a 409.

Tipping stays peer-to-peer. The credit block on each entry links my HandCash handle and paymail. Human generosity shouldn't need to route through my server at all.

What this doesn't do

Honesty clause: the full text of every entry remains free in the places humans read it — the HTML and the RSS feed. A scraper that ignores my terms can still scrape. This is not DRM, and building DRM would ruin the thing worth protecting: a site that's pleasant to read and easy to cite.

What it does instead is remove an excuse. There is now no crawler operator who can say the terms weren't machine-readable, the price wasn't posted, or payment wasn't possible without a phone call to a licensing department. The terms are in the header of every response this server sends. Norms precede enforcement; publishing terms is how norms start. One personal site doing this is a curiosity. A million of them is an economy.

Try it

curl -sI https://ryanwold.net/license.xml

curl -si https://ryanwold.net/api/v1/entries.json # the 402 in the wild

If you run an agent, point it at the flow above and tell me what breaks. If you run a website, the pattern is small — an XML file, a Link header, a 402 handler, and a watch-only address. And if you just like the writing: the tip jar is at the bottom of every entry.