x402 is the Linux Foundation’s open standard for HTTP-native payments (founding members include Google, Visa, Stripe, Circle). A client gets HTTP 402 Payment Required, signs a payment, retries, and gets the resource. It’s how autonomous agents buy API calls.
The x402 spec has included a Sui exact scheme for a while, but no live facilitator implemented it — every production facilitator today is EVM/Solana/Stellar. As of today that’s no longer true:
https://sui-facilitator.onrender.com — a spec-conformant x402 v2 facilitator settling on sui:testnet (GET /supported, POST /verify, POST /settle). Non-custodial by construction: the payment payload is the payer’s own signed transaction, so the facilitator holds no keys and physically cannot redirect funds — source is open (Apache-2.0) if you want to verify that claim or run your own. Zero fees.
Proof it works (testnet, verifiable on any explorer — full list in PROOF.md):
- An autonomous agent bought an API response for $0.01 Circle USDC, settled on Sui through the live service: digest
22NXwKmciPXT4aKX3bhqPAkJuqXPQjT5z5CK4ZTovbfi
- Try the demo endpoint yourself —
curl -i https://sui-facilitator.onrender.com/signal/whales returns the 402 + payment terms (it sells recent large SUI transfers on mainnet, $0.01/call).
The part I think is genuinely new for any chain: the same endpoint has a second door. A wallet holding a Proof of Real personhood credential signs a personal message and reads free — humans verify once and read free; agents pay per call. Differential pricing for the agentic internet, using Sui object ownership as the discriminator.
Two technical notes for anyone implementing the scheme:
dryRunTransactionBlock simulates against latest object versions, so an already-executed payment still simulates cleanly — replay protection needs a local digest computation (TransactionDataBuilder.getDigestFromBytes) plus a getTransactionBlock lookup, not just a dry-run.- The spec defines
sui:mainnet but no testnet network id — I shipped sui:testnet (CAIP-2 style) and would love a canonical answer. Curious whether anyone from Mysten or the Foundation has a view, since the scheme spec came out of this ecosystem.
Testnet first, deliberately — mainnet comes after a hardening pass. Feedback very welcome, especially from anyone building agent-side x402 tooling who wants a Sui rail to test against.
2 Likes
Nice work getting this running on Sui Testnet.
Good catch on the network identifier as well. The current x402 Sui exact spec defines sui:mainnet, but I don’t see a canonical Testnet identifier specified yet. sui:testnet looks like a reasonable implementation choice for now, but I wouldn’t treat it as standardized until that’s confirmed in the spec.
I’ll flag the testnet identifier question to the relevant team/spec owners. Also really useful notes on replay protection here.
Can vouch for this from the outside. I just spent a few days building a client SDK and seller middleware on top of your facilitator, used as is, and it held up well. Ten $0.01 USDC payments settled through it on testnet, a few via my own instance running from a Dockerfile around your pinned repo. I posted about it here as “An x402 client SDK + middleware for Sui” if you want to poke at the API.
On the testnet network id, I hit the same gap and also landed on sui:testnet. Happy to help draft the upstream proposal, I have wording ready.
Also filed issue 2 on your repo: the /signal/whales demo 500s on valid payments because it still calls JSON-RPC. Verify and settle are fine, it’s just the demo route.
Thanks for digging in on this, and for offering to flag it upstream — that’s the right instinct.
You’ve got it exactly: the exact spec pins sui:mainnet but never defined a testnet id, so sui:testnet is my own reasonable-but-unofficial guess. The good news is the canonical answer is already in motion — the Sui exact-scheme spec is under active review on x402-foundation/x402 (#3081/#3082), and I’m in that thread, so I’ll make sure testnet gets a proper id there rather than everyone hand-rolling one. yannickrocks (above) hit the same gap building on this, so there’s real demand to point at.
Appreciate the note on the replay protection, too.
1 Like
This is great to see — a client SDK, seller middleware, ten testnet settlements, and your own facilitator instance is about the most thorough kick of the tires I could ask for. Genuinely appreciate it.
And you’re dead right on the bug. The /signal/whales reader was still calling the public mainnet JSON-RPC, which got retired out from under it (it just returns -32601 migrate to gRPC or GraphQL now), so the data fetch threw after settlement and the whole call 500’d. Fixed — moved it to the Sui GraphQL transactions query and deployed. While I was in there I found the same underlying problem in the PoR free door: it read the credential over testnet JSON-RPC and the error was getting swallowed, so verified humans were quietly bounced to the paywall instead of reading free. That’s on GraphQL now too. Both live if you want to re-run your suite.
On the testnet identifier — yes, let’s get it written down properly, and I think I can save us a step. I’ve been reviewing the Sui exact scheme spec upstream (x402-foundation/x402 #3081/#3082), which is exactly where the network id belongs: sui:mainnet is specified there, testnet just hasn’t been yet. sui:testnet is the obvious form; happy to carry it into that thread so it lands canonically instead of us each picking one. If you want to co-sign or bring your implementer’s view, even better — two independent facilitators asking for the same id is a strong signal.
1 Like
Just re-ran my suite against the fixed demo and it settled first try, digest F1YSaQdcFiMgV364osSCDAVNuD4tPPPAQtZVXMACh39k if you want to see it on chain. That was a fast turnaround, nice work. I’ll close the issue with the confirmation.
And yes, count me in on the testnet id. Bring sui:testnet into the spec review thread and I’ll add the implementer’s view there: my payer and middleware both treat it as the default network and ten plus settlements have used it, so there’s running code behind the ask. Happy to co-sign however is most useful.
Perfect — thanks for re-running it, and for the on-chain digest. Glad it settled first try, and appreciate you closing the issue.
On the testnet id: it’s already in the review thread, and your running-code angle is exactly what it needs. I raised it on the Sui exact-scheme spec PR (x402-foundation/x402 #3081). One wrinkle worth knowing before you weigh in — the spec itself already defines sui:testnet (it’s in the Network Format section). The actual gap is that the core network-and-token-support registry doc doesn’t list Sui at all yet, so anyone validating against that registry comes up empty. That’s almost certainly what we both kept hitting.
So the ask upstream is really “document Sui in the registry to match the scheme spec.” Ten-plus settlements defaulting to sui:testnet, with a payer and middleware that treat it as the default, is the strongest possible “there’s running code behind this” evidence — dropping that on the PR thread would land well. Co-signing there is perfect.