Developers Forum for XinFin XDC Network: Abilash Senthilkumar

XDCAI : Agents can now invoice each other on XDC <> stateless x402 invoices + chain-truth payment verification

Abilash Senthilkumar — Tue, 07 Jul 2026 21:31:38 +0000

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

I tested XDC AI's x402 marketplace as both payer and provider. Here's everything I found

Abilash Senthilkumar — Mon, 06 Jul 2026 09:59:45 +0000

Yesterday I put XDC AI, the new x402 payments marketplace on XDC through a full test from both sides: as an agent paying for API calls, and as a provider building payable endpoints from scratch. This post is the complete log: what worked, what broke, and what we shipped because of it. Every claim links to a mainnet transaction.

TL;DR: the rails genuinely work — email → wallet → first paid API call in under 10 minutes, gasless. We shipped xforty Chain Tools as a live provider on those rails, found one serious settlement-reconciliation gap (with a double-charge repro), and are upstreaming XDC support to the official x402 SDKs.

The consumer side: paying for data as an agent

Onboarding is the smoothest I've seen in crypto: email OTP → a wallet exists → fund it with USDC → your agent can buy things. No seed phrase, no gas token (their relayer sponsors gas via EIP-3009).

My agent's first purchase is to fetch live DeFi rates from DeFi Watch, $0.005:
https://xdcscan.com/tx/0x54451b1ca87cd23c0692752e43351e4c8c0b4c427448798a96ea4ccfa6d1144d

Also genuinely good: payees are allowlisted, and approving a new recipient requires a browser login an automated agent cannot expand its own spending surface. That's real security design, not an afterthought.

The provider side: getting paid as an API

Here's where it got interesting. The official x402 npm packages (x402@1.2.0, @x402/core@2.17.0) don't include the xdc network in their registries yet, so there's no SDK path. I implemented the 402 flow from scratch against the live facilitator: challenge → X-PAYMENT (EIP-3009 authorization) → /verify → serve → /settle.

It interoperated with XDC AI's production CLI on the first try. The proof is my agent wallet paying my own endpoint, settled on-chain:
https://xdcscan.com/tx/0x381f791d13a2d094c506df20fca9d952b1f3aef8a46aa9fd319898cb14b42051

Two design choices I'd recommend to every provider:

Settle before responding the agent should never be in doubt about whether it paid.
Never charge for stale data. Public XDC RPCs load-balance across replicas, and I caught one serving blocks ~5 days old. Our endpoints validate the chain head's own timestamp per request and refuse to charge if freshness can't be proven.

The finding that matters: a three-way settlement disagreement

One $0.10 screening call produced the most instructive failure I've seen on agentic rails:

The service completed, but settlement timed out → the provider returned 502 with charged: "unknown".
My wallet history recorded the payment as "failed."
On-chain, it had actually settled: https://xdcscan.com/tx/0xf5413a271ec6626cd719a7d9d41cda20321e4c7fe53e90fdca9f7fb369e89232
Following the documented recovery ("retry — stored result, no recharge"), the retry carried a fresh authorization and charged again: https://xdcscan.com/tx/0xb272b13e641893985ed5874b420188fa1a6b9fbe6c115573be93ad7c97bae58d

One call. $0.20 paid. Three layers, three different answers — and the chain was the only honest one. To be clear: the provider's idempotent-retry instinct is right (dedupe just needs to key on the request, not the authorization), and the root cause looks like relayer/settle-window timing. Easy platform wins: history entries carrying the tx hash + chain-confirmed status.

But the general lesson is bigger than the bug: agentic payments need a reconciliation layer — something that answers "did money actually move?" from chain truth, not from whichever service timed out first. When agents spend autonomously at machine speed, "charged: unknown" is not an acceptable state.

Smaller notes

The @xdctaskman/x402-server package referenced on the providers page 404s on npm (hence the hand-rolling).
404s on paid routes return HTML error pages; agents would prefer JSON.
Catalog entries don't carry input schemas yet, so agents call-and-fail to learn parameters.

What we're building because of all this

xforty Chain Tools (live now): network stats + a contract inspector — pre-flight safety checks agents can buy for cents. Free taste: npx xdcai call https://api.xforty.xyz/api/x402/gas-price
The provider kit (npx xforty): everything I hand-rolled, packaged, so the next provider ships in minutes — plus an upstream PR adding xdc to the official x402 SDKs.
The trust layer: spend policies, human approvals, audit trails, and settlement reconciliation for agent wallets — the piece this testing convinced me the whole ecosystem needs before real money rides these rails.

The payment rails are XDC AI's, and they work — that's the headline. We're building what gets paid, and what keeps agent spending safe.

xforty · xforty.xyz · api.xforty.xyz · npx xforty