The first live x402 facilitator on Sui — agents pay USDC per API call, verified humans read free

General
, ,
1

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:

  1. 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.
  2. 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.

1 Like