Machine payments, and what this deployment does instead

The handshake

1. The client requests something that is not provisioned.
2. The service answers 402 with a challenge: the amount, the accepted method, the recipient and a nonce.
3. The client signs a payment authorization with its wallet key.
4. A facilitator verifies the signature and settles the amount on mainnet.
5. The client retries with proof; the service provisions and answers normally.

Why the shape is what it is

Every step exists to remove a human. The challenge replaces a pricing page, the signature replaces a card form, the facilitator replaces a checkout session, and the retry replaces someone clicking continue after payment. What is left is a request that pays for itself.

The variations

What this deployment does

Nothing of the above. No 402 is ever returned, because no capability is priced. Anonymous publishing works without identity at all; keyed publishing works with a key a human minted; both are free.

curl -X POST https://read.botook.ai/v1/publish -F file=@index.html

The honest reason

Payment protocols exist so a service can charge. This is software you run in your own Cloudflare account — the infrastructure bills you directly, there is no operator in the middle, and a protocol that settles zero is worse than no protocol.

Identity without payment

The useful half of the design survives. link_wallet associates a wallet with the account that owns a page, so an autonomous client has a durable identity, and it moves no money:

link_wallet({ address: "0x…", label: "publisher-bot" })

How an agent authenticates instead

curl -s https://read.botook.ai/.well-known/oauth-authorization-server | jq .

If you wanted to add it

The pieces you would need: a challenge on the endpoint you decide to price, a facilitator to verify settlement, a record of what was provisioned, and a retry path. The account model already holds a wallet identity, so that part is done.

What would still be free

• Reading a published page — viewers never pay and never authenticate.
• Every gate: passwords, email domains, burn-after-read, expiry.
• Custom domains, which hosted products often price separately.

Stripe and the human rails

Equally absent. There is no billing code in the deployment: no checkout, no invoices, no subscription state to reconcile.

Is a payment rail a good idea in general?

For a service with real marginal cost and autonomous clients, plainly yes — it is the only way those clients can transact at all. The judgement here is narrow: this deployment has no marginal cost to recover, so the rail would be ceremony.

Discovery, without the payment half

An agent that has never seen this site can still learn the whole surface before its first call. That is the part of these designs worth having, and it needs no settlement layer at all:

curl -s https://read.botook.ai/.well-known/ai-catalog.json | jq '.entries[].capabilities'
curl -s https://read.botook.ai/.well-known/mcp/server-card.json | jq 'keys'
curl -s https://read.botook.ai/openapi.json | jq '.paths | keys'

Twelve capabilities, the transport, the authorization scheme, and every REST path — enough for a client to configure itself. What is missing from that list is a price, and only because there is not one.

The protocol as a discovery problem

Half of what these designs solve is machine-readable discovery: what does this service offer, what does it cost, how do I pay. The first of those is answered here without any payment layer — /.well-known/ai-catalog.json, /openapi.json and /llms.txt describe the whole surface to a client that has never seen this page.

Questions

Do you accept on-chain payments?

No. Nothing is priced.

Can an agent provision itself?

It can publish anonymously with no identity. Keys need a human once.

Where is the rest of this reasoning?

Agent payments.

Keep reading