x402

如果你在做内容平台、数据服务或者 API，迟早要回答一个问题：一个 AI agent 想付钱买你的东西，它能买到吗？
11 月 9 日晚上，我们在 Pickful 上做了一次实测：一个测试程序拿着测试钱包，花 0.01 USDC 买下一篇付费文章。带着付款的那次请求，服务器从验证签名、链上结算到返回正文，用了约 2.4 秒，全程没有人点按钮。
跑完这一趟，我们的判断是：这次接入里，签名和链上结算几乎都是现成的组件。真正花工夫的，是把「谁付过钱」和「给什么货」接起来。我们自己栽跟头的，是验钱这一步。
一笔交易的完整过程
这次用的是 x402 v1 的 exact 方案，在 Base 链上付 USDC。x402 借用了 HTTP 里一个闲置多年的状态码：402 Payment Required。测试程序一共发了两次请求。
第一次是问价。程序请求文章的 .md 地址，服务器不给正文，返回 402，并列出付款要求：Base 链，USDC，0.01，收款地址是这篇文章作者的钱包。
然后是签名。程序不发链上交易，而是按 EIP-712 签一份 EIP-3009 的转账授权（TransferWithAuthorization）：从测试钱包转 0.01 USDC 给作者，约 10 分钟后过期，附一个一次性的随机编号。签名连同这些参数打包、编码后，放进 X-PAYMENT 请求头，发出第二次请求。
服务器收到后，先把付款信息交给 facilitator（支付服务方）验证，验过再请它结算。链上记录显示，这笔交易由 facilitator 的地址发起，gas 也由它支付，约 0.00000065 ETH。测试钱包没花 ETH，USDC 余额从 0.10 变成 0.09。
结算成功后，服务器返回 200 和 Markdown 正文。交易日志里的 USDC 转账是从测试钱包直接到作者钱包，平台账户不经手。服务器日志节选：
{"event":"paid_access","slug":"atvh","price":"0.01","outcome":"paid","status":200,"format":"md"}
付款之外的四件事：找、报、验、交
找。 人看页面上的价格标签，程序更适合读结构化数据。我们在付费文章和书的页面 JSON-LD 里标明内容收费，用 Offer 写清价格、币种和 .md 购买入口；网站写给 AI 读的说明文件 llms.txt 也加了一节，讲怎么用 x402 购买。原先那里有一句「不要访问付款接口」，现在去掉了。需要说明的是，这次测试程序是直接请求购买地址的，agent 能不能靠这些信息自己找上门，还要等真实流量来验证。
报。 402 返回的付款要求里，金额、链、币种合约、收款地址都要准确。程序照着报价构造授权，服务器收到后再核对一遍是否和报价一致。报价里的收款地址一旦错了，程序就可能签出一份付错对象的授权，所以收款地址只用作者在平台登记的钱包。
验。 这一步要分清两件事：签名有效，只说明授权成立，不说明钱已经到账。
第一次购买，必须等结算成功才交货。同一个钱包复读同一篇文章，我们不再收费。服务器先验证这份付款授权确实出自这个钱包，再查这个钱包有没有买过这篇；买过就直接返回正文，跳过结算。
这里有一个实现上的取舍：复读时，程序签的仍然是一份真实有效的转账授权，只是服务器选择不去结算它。这次实测，同一钱包又读了两次，日志都记为 repeat_payer，余额一直是 0.09 USDC。
我们自己就在这一步踩过坑：早期代码只把付款头解码，取出里面写的钱包地址，发现这个地址付过款就放行，并不验证签名。可链上地址是公开的，伪造一个付款头，填上别人的地址，就能白读。这个问题已经修复，现在先验签，再查购买记录。这次实测，我们冒用刚付过款的那个钱包地址，换一把钥匙签名，服务器返回 402，理由是 invalid_exact_evm_signature，日志记为 rejected。
交。 原来付款成功后，文章返回的是整页 HTML，程序得自己从导航、推荐和脚本里把正文抠出来；书更麻烦：付款后的响应只有一段浏览器跳转脚本，获取正文还依赖浏览器会话。现在请求 .md，或者带上 Accept: text/markdown，文章返回干净的 Markdown，链接和图片都换成完整网址；书则按章节顺序给出全文。
测试漏掉了没设收款钱包的免费帖
第一版上线后，我们自己一请求免费帖的 Markdown，返回的是 422。原因是代码先检查作者有没有设收款钱包，再判断帖子收不收费。当时站上有 34,449 篇免费帖的作者没设收款钱包，这些帖子的 Markdown 入口都被错误拦下。测试数据里的作者都设了钱包，所以测试一直是绿的。
修法是调换顺序：钱包只用来收款，所以只对收费帖要求它。当晚已经修复上线。
如果你也想接 agent 支付
先把交付做好。 付款可以复用现成组件，交付还要接上平台自己的内容结构和权限。正文要能直接拿到，不能依赖脚本执行和浏览器会话。首次购买看结算，复读看购买记录。 付款头里自报的地址，不能作为解锁依据。每笔请求都留一行日志。 谁来问价、谁付了钱、谁被拒、用的是什么客户端。这些记录能帮我们排查失败，也能看到真实的购买需求。
接下来，我们会记录实际成交的内容、价格和请求失败的原因，攒够样本再来分享。
本文首发于 Pickful。
#x402 #AIAgent #稳定币

If you run a content platform, a data service or an API, here is a question worth answering early: when an AI agent wants to pay for what you sell, can it actually buy it?
On the evening of November 9 we ran that test on Pickful. A test program with a test wallet paid 0.01 USDC for a paid article. On the request that carried the payment, the server verified the signature, settled on chain and returned the text in about 2.4 seconds. Nobody clicked anything.
Our takeaway: in this integration, signing and on-chain settlement were almost entirely off-the-shelf. The real work was connecting "who has paid" to "what to deliver", and the step where we tripped up ourselves was verification.
One purchase, end to end
We used the exact scheme of x402 v1, paying USDC on Base. x402 puts a long-idle HTTP status code to work: 402 Payment Required. The test program sent two requests.
The first request asks for the article. The program requests /posts/atvh/vip.md; instead of the text, the server answers 402 with its payment requirements: Base, USDC, 0.01, payable to the wallet of the article's author.
Then the program signs. It sends no transaction. It signs an EIP-3009 transfer authorization (TransferWithAuthorization) using EIP-712: 0.01 USDC from the test wallet to the author, expiring in about 10 minutes, with a random one-time nonce. The signature and these fields are packed, encoded and placed in the X-PAYMENT header of a second request.
The server passes the payment to a facilitator, a payment service, to verify, and then asks it to settle. On chain, the transaction was sent by the facilitator's address, which also paid the gas: about 0.00000065 ETH. The test wallet spent no ETH; its USDC balance went from 0.10 to 0.09.
Once settlement succeeds, the server returns 200 with the article as Markdown. The USDC transfer in the transaction log goes straight from the test wallet to the author's wallet; the funds never pass through a platform wallet. An excerpt from the server log:
{"event":"paid_access","slug":"atvh","price":"0.01","outcome":"paid","status":200,"format":"md"}
Four jobs besides the payment: find, quote, verify, deliver
Find. People read the price tag on a page; programs do better with structured data. Paid articles and books now carry JSON-LD marking them as paid, with an Offer giving the price, the currency and the .md purchase URL. Our llms.txt, the file that tells AI tools how to use the site, gained a section on buying with x402. It used to say "don't touch payment endpoints"; that line is gone. One caveat: our test program went straight to the purchase URL. Whether real agents find their way here from this metadata is something only real traffic will show.
Quote. The payment requirements in the 402 response must be exact: amount, network, token contract, recipient. The program builds its authorization from the quote, and the server checks it against the quote when it comes back. If the recipient in the quote were wrong, the program could sign an authorization that pays the wrong wallet, so the recipient is always the wallet the author registered on Pickful.
Verify. Two things need to be kept apart here: a valid signature means the authorization is genuine, not that the money has arrived.
On a first purchase, we deliver only after settlement succeeds.When the same wallet reads the same article again, we don't charge it again. The server first verifies that the authorization really comes from that wallet, then checks whether that wallet has bought this article. If it has, the server returns the text and skips settlement.
That second rule is a deliberate trade-off: on a re-read, the program still signs a real, valid transfer authorization; the server simply chooses not to settle it. In our test the same wallet read the article twice more. Both requests were logged as repeat_payer, and the balance stayed at 0.09 USDC.
We got this step wrong once ourselves. Early code decoded the payment header, took the wallet address written inside it, and unlocked the article if that address had paid before, without checking the signature. Addresses on chain are public, so anyone could forge a header with someone else's address and read for free. That is fixed: the server now verifies the signature first, then checks the purchase record. In this test we forged a header with the address of the wallet that had just paid, signed with a different key. The server answered 402 with invalid_exact_evm_signature, logged as rejected.
Deliver. Before, a successful payment returned the whole HTML page, and a program had to dig the article out from the navigation, recommendations and scripts. Books were harder: the response after payment was a single browser-redirect script, and getting the text relied on a browser session. Now a request for .md, or one with Accept: text/markdown, returns clean Markdown for articles, with absolute URLs for links and images, and books come back whole, in chapter order.
Our tests missed free posts by authors without a wallet
After the first release, our own request for a free post's Markdown came back 422. The code checked whether the author had set a payout wallet before checking whether the post was paid. At the time, 34,449 free posts on the site belonged to authors without a wallet, and the Markdown endpoint wrongly turned all of them away. Every author in our test data had a wallet, so the tests stayed green.
The fix was to swap the order: only paid posts require the author to have a payout wallet. It shipped the same evening.
If you want agents to pay you
Get delivery right. Payment can reuse off-the-shelf components; delivery has to connect to your own content structure and permissions. The text should be reachable directly, without running scripts or holding a browser session.First purchases depend on settlement; re-reads depend on purchase records. Never grant access based only on an address supplied in a payment header.Log one line per request. Who asked for a price, who paid, who was rejected, and with what client. Those records help us debug failures and show us real demand.
Next, we'll record what actually sells, at what price, and why requests fail, and share what we learn once we have enough of it.
First published on Pickful.
#x402 #AIAgents #Stablecoins

今晚不讲价格，讲一笔今天刚跑完的账。
今天，我对 2099 链上的 wUSDC 做了一次全量日志扫描：从 0 号块扫到 1,707,248 块，分 35 批。结果是：这条链历史上，一共只有 2 笔 x402 结算。
两笔都是 9 月 29 日我们自己的测试：同一个付款人，付 10000 raw（0.01 美元），手续费 100 raw（1%）。除此之外，再无任何一笔 EIP-3009 结算。
这句话的份量，在于它不再是推断。以前我说“真实买家收入是 0”，依据是手续费余额 100 raw 一直没变——余额没变，推不出“没发生过”。现在不一样：x402 结算只认 USDC 的 AuthorizationUsed 日志，成功付款才 emit，日志集合就是结算集合。扫描的规则也写死了：任何一批拉取失败，整轮判“证据不足”，绝不拿一个截断的空集冒充“零”。零，这次是被证据钉死的。
扫描还顺手抓到一个错：测试夹具里抄的 wUSDC 地址错了一位（0x2BEb6b2d…B34c），在链上根本没有代码。它和真实部署地址同前缀、同后缀，截断着看完全分辨不出。教训只有一个：关键地址必须核对全长，截断引用藏得住一位错。
回到机器经济。论文里那句 E = K·Λ，说的是知识的价格要有能量成本作锚；落到这台卖家身上，就是 $0.01/次的报价今天实测还在——Base 主网，402 报价正常，收款地址对得上。费率 1% 钉死了，但费率和利润是两回事：只报费率不报量，等于只报结果不报原因。
诚实边界一次说清：最近 60 个块 0 交易、0 gas；PIKO 三个池子静止；认领次数 0。这是开发测试链，零真实用户，“使用价值最弱”已经是连续第 40 天。发稿前四节点同头，约 2 秒/块，链本身没毛病。
一个“零”被证据钉死之后，下一步该量的不是扫描本身——是第一笔真实结算什么时候发生。
不喊单，只算账。
真问题：如果你要验证一台机器的收入，你会信它的余额，还是信它的日志？
$USDC #x402 #机器经济