This week the XDC AI beta group debugged two payment mysteries by hand. In one, an agent paid for a call and got a 404 back. In another (from my last post), a payment settled on-chain while the provider reported "charged: unknown" and the wallet history said "failed." Both times, resolving it took humans, screenshots, and someone manually checking the explorer — and in one memorable moment, the source of truth was literally "the payment went through, as per Claude."
Three layers, three answers. Only one layer never lies: the chain.
So we shipped two tools that make the chain the first place agents ask — both live now on xforty Chain Tools via the XDC AI marketplace.
1. payment/verify — the answer to "charged: unknown"
npx xdcai call "https://api.xforty.xyz/api/x402/payment/verify?tx=0x…"
Give it any transaction hash, get back the chain-truth verdict: did USDC actually move, how much, from whom, to whom, in which block, at what time. $0.002 per call. This is the one-liner that would have resolved both of this week's debugging threads instantly — no screenshots, no "try calling it again," no trusting anyone's dashboard, including ours.
Verified against a live settlement:
{ "settled": true, "block": 104652620, "timestamp": "2026-07-07T21:04:42Z",
"usdcTransfers": [{ "amountUSDC": "0.020246",
"from": "0x0094ce…254d", "to": "0xb0f9…033b" }] }
2. Stateless invoices — agents billing each other
The bigger piece: any agent can now mint an invoice that any other agent can pay.
npx xdcai call "https://api.xforty.xyz/api/x402/invoice/create" \
--method POST \
--data '{"amountUSDC":"0.02","payTo":"0xYourAddress","memo":"design work"}'
Back comes a one-time x402-payable URL. The payer's agent calls it, gets a standard 402 challenge with the invoice's exact terms, pays through the normal flow — settlement goes directly to the invoice's payTo (any address you choose, not ours), gasless as always on these rails. A free status endpoint answers "has it been paid?" at any time.
Two design decisions worth explaining:
There is no database. The invoice is a signed token — amount, recipient, memo, and validity are HMAC-signed into the invoice ID itself. We can't lose your invoice, corrupt it, or edit it, because we don't store it.
The chain is the ledger. How do you match an on-chain USDC transfer to a specific invoice when EIP-3009 has no memo field? The invoice's amount carries a per-invoice fingerprint in its lowest digits — a $0.02 invoice becomes, say, 0.020246 USDC. The status endpoint scans USDC transfer logs for that exact amount to that recipient within the validity window. Payment attribution from pure chain data — no bookkeeping to trust, ours included.
We ran the full loop with real money before writing this: mint → agent pays the invoice → settlement on-chain → status flips to paid from the chain scan alone.
The pattern underneath
Both tools follow the same principles from our first writeup, which this week's incidents keep validating: validate before settling (bad input must be rejected before money moves — good to see LendWatch adopt the same fix), settle before responding (the agent should never wonder whether it paid), and never charge for your own failures. Agentic payments don't need more trust — they need less of it, replaced by verification.
What's next
These endpoints are the retail edge of a bigger piece we're building: guard — spend policies, human approvals, audit trails, and automatic settlement reconciliation for agent wallets, running on this same chain-truth engine. If your agent moves real money and you'd sleep better with limits and a kill switch, come talk.
xforty · xforty.xyz · api.xforty.xyz · npx xforty · built on XDC AI's rails
Discussion (0)