x402 on Stellar: How AI Agents Pay per Request

x402 on Stellar by the numbers (October 2026)

x402.org reported 75.41M transactions worth $24.24M across all supported chains over the 30 days to 8 October 2026, about $0.32 per payment on average. Stellar became a settlement network in March 2026. DefiLlama counts $392.5M of USDC on Stellar, the default x402 asset there.

• Whole-protocol activity: 75.41M transactions, $24.24M of volume, 94.06K buyers and 22K sellers in the past 30 days, per x402.org on 8 October 2026. The site does not break this down by chain.
• Stellar launch: the Stellar Development Foundation announced Stellar as an x402 settlement layer on 10 March 2026; the @x402/stellar npm package was first published the same day and is at version 2.28.0.
• Funding: SCF #45 (recap published 23 September 2026) gave $445,000 worth of XLM to four RFP-track projects, three of them for the "x402 Facilitator with Bazaar" request: Rail402 ($125,000), AgentSmith x402 ($122,000) and Rumble Fish ($78,000).
• Settlement asset: $392.5M of USDC circulates on Stellar, per DefiLlama on 8 October 2026. See stablecoins on Stellar.

How to choose

• You sell an API and want per-call payments: use the hosted OpenZeppelin facilitator on mainnet, or run the open-source one from Stellar's x402-stellar repo if you want no third party in the path.
• You build an agent that buys services: give it a dedicated account holding only what it may spend, and sign with a key the agent controls. Do not point an agent at your main wallet.
• You need usage-based pricing: x402's upto scheme is specified only for EVM chains so far; on Stellar, look at MPP's payment-channel "session" intent instead.
• You want to be discovered by agents: declare the Bazaar extension in your 402 response so facilitators can index your endpoint.

What x402 is — HTTP's unused status code, put to work

HTTP has reserved status code 402, "Payment Required", since the 1990s without a standard way to use it. x402 fills that gap: the server's 402 response carries machine-readable payment terms, the client attaches a signed payment to its retry, and the server delivers once payment is confirmed.

Coinbase launched x402 in May 2025 and released version 2 in December 2025, according to SDF's announcement. x402.org now presents it under the x402 Foundation, which SDF says was co-founded by Coinbase and Cloudflare and now includes Google and Visa. The standard is chain-neutral: the core specification defines the messages, and each chain gets its own "scheme" document describing how a payment is signed and settled there.

Three parties take part. The client (a script, an app or an AI agent) wants a resource. The resource server sells it. The facilitator is a service the server trusts to check payments and put them on-chain, exposing three endpoints: /supported, /verify and /settle. The facilitator spares the seller from running blockchain infrastructure; it does not hold the buyer's funds.

How a payment works on Stellar

On Stellar, the client builds a Soroban call to the token contract's transfer(from, to, amount), simulates it, and signs only the authorisation entry, not the whole transaction. The facilitator re-checks it, wraps it in a transaction from its own account, pays the fee and submits it.

The x402 specification's exact scheme for Stellar runs like this:

1. The client requests a resource; the server replies 402 with the price, the token contract address, the recipient and a timeout, plus a flag saying fees are sponsored (currently always true).
2. The client builds the transfer invocation, simulates it to find the authorisation it needs, and signs that entry with an expiry of roughly the timeout divided by the ledger time (about five seconds).
3. It retries the request with the transaction, encoded as XDR, in the payment payload.
4. The server forwards it to the facilitator's /verify, then /settle. Settlement must re-verify from scratch rather than trust the earlier check.
5. The facilitator rebuilds the transaction with its own account as source, simulates it, signs, submits through Stellar RPC and polls for the result. The server then returns the resource.

The checks are strict, and they are the interesting part. The transaction must contain exactly one operation, calling transfer on the stated token with the exact amount and recipient. The authorisation must not contain sub-invocations. The facilitator's own address must not appear as the sender, the transaction source or in any authorisation, and the simulation must show no balance changes other than the payer's decrease and the recipient's increase. Those rules exist because the facilitator signs and pays for a transaction a stranger built; without them, a crafted payload could make it spend its own funds.

Because only the authorisation is signed, the client spends no sequence number, so one account can pay in parallel. And because Soroban authorisation works for contract accounts as well as ordinary ones, a smart wallet can pay too; see passkey smart wallets on Stellar. The scheme covers SEP-41 tokens only, so a classic asset is paid through its Stellar Asset Contract.

Facilitators — who settles Stellar payments

Stellar's documentation lists three facilitators: OpenZeppelin's, built on its Relayer and hosted for testnet and mainnet; Coinbase's, for Stellar testnet; and a community one, Vellar, on testnet with Bazaar discovery. Anyone can also run their own from open-source code.

The OpenZeppelin service, which SDF calls the "Built on Stellar" facilitator, exposes the standard three endpoints at channels.openzeppelin.com/x402 and accepts any SEP-41 token with USDC as the default. Mainnet API keys need a GitHub sign-in; testnet keys need nothing. Its documentation mentions sponsored fees and roughly five-second finality, but publishes no pricing or rate limits. For higher throughput, the reference facilitator in Stellar's repo uses 19 channel accounts and one fee-bump signer, so it can submit transactions in parallel without sequence-number collisions.

On the buyer side, Stellar lists wallets that can sign authorisation entries: the Freighter browser extension, Albedo, Hana, HOT, Klever, OneKey and Scopuly. Freighter Mobile is explicitly not supported yet. In practice, autonomous agents usually sign with a key held in their own runtime.

Bazaar — how agents find paid services

Bazaar is an x402 extension for discovery. A seller adds a bazaar block to its 402 response describing the endpoint (HTTP method or MCP tool name, inputs, an example output), and facilitators that support it catalogue those endpoints so agents can search them.

The point is that an agent cannot pay for a service it cannot find. Bazaar makes the 402 response double as a listing, and covers MCP tools as well as plain HTTP endpoints, which matters because MCP is how many AI agents call external tools. Rail402's implementation shows what this looks like: listings appear automatically from settled payments, tied to the recipient address, with full-text and semantic search across them. Its hosted instance runs on testnet and settles in testnet USDC.

The SCF #45 winners

The Stellar Community Fund's #45 round funded three teams under its "x402 Facilitator with Bazaar (discovery) support" request: Rail402, AgentSmith x402 and Rumble Fish. All three are open source and pair a facilitator with Bazaar discovery; they differ in scope and maturity.

• Rail402 ($125,000 in XLM): an Apache-2.0 suite for discovering, buying, settling and inspecting x402 services, built on @x402/stellar with the standard endpoints and several settlement schemes. Its repo describes non-custodial settlement in which buyers sign transfers directly to sellers while Rail402 sponsors the fee.
• AgentSmith x402 ($122,000): a facilitator and Bazaar layer for testnet and pubnet, with non-custodial verify and settle and sponsored fees, per the recap.
• Rumble Fish ($78,000): a facilitator and Bazaar layer for API endpoints and MCP tools, paying in USDC or any SEP-41 asset, with a metered upto scheme and an MCP server for agents. When we checked its public repo on 8 October it described itself as a skeleton, so treat it as early.

The same round also funded Fermah Pay ($65,000), seller-side billing infrastructure with recurring USDC charges and an x402-compatible settlement interface. For how SCF rounds work, see the Stellar Community Fund.

Use cases

x402 fits payments that are small, frequent and initiated by software: an agent buying one weather reading, one search, one model call or one tool invocation. It removes sign-ups and API-key management, at the cost of putting every purchase on-chain.

• Pay-per-call APIs: the specification's own example is a weather endpoint priced per request. A seller can price a call at a cent without a billing system.
• Agent tool use: through Bazaar, an agent can discover an MCP tool, see its price and pay for one use.
• Usage-based compute: the upto scheme, which authorises a maximum and charges actual use, names LLM token generation and bandwidth as examples. Its specification currently has only an EVM implementation.

Limits and risks

x402 settles payments; it does not handle what happens after. There are no built-in refunds or disputes, the facilitator is a trusted operator in the delivery path, and Stellar's metered-pricing support is still in development.

• Pay first, then hope. The server returns the resource after settlement. If it then fails or returns rubbish, the protocol offers no recourse; refunds are up to the seller.
• Facilitator trust. A facilitator cannot redirect funds, because the client signs an exact amount and recipient. But it can refuse, delay or log payments, and a seller who relies on a hosted facilitator depends on its uptime and terms.
• Every payment is a transaction. At a minimum of 100 stroops per operation plus resource fees, Stellar's costs are tiny (see Stellar fees explained), but someone pays them, and the hosted facilitator publishes no pricing. MPP's Stellar "session" intent avoids per-payment transactions with one-way payment channels.
• Agent key risk. An agent that holds a key can be prompted or tricked into paying. Cap its balance, or use a smart account with a spending-limit policy.
• Classic accounts still need XLM. Fee sponsorship covers the transfer, not the account's own minimum balance and trustline reserve.
• Young code. Coinbase's, Vellar's and Rail402's hosted facilitators run on testnet only, and the volume figures above are for all chains.

How these fit together

The pieces form a short stack. The x402 specification fixes the messages. The Stellar exact scheme turns a payment into one signed transfer authorisation. Facilitators verify and settle it, and Bazaar lets agents find what to pay for. SCF #45 funded three competing implementations of the last two layers, which is a sign the foundation wants more than one operator rather than a single gateway. MPP sits alongside as a different design, with direct settlement and payment channels instead of facilitators.

Stellar's case for hosting this is the one SDF makes: five-second settlement fits inside an HTTP request, fees are far below the price of a single call, and USDC is native. How much agents actually buy this way on Stellar is unknown: no public figure isolates its share.

The takeaway

x402 on Stellar is a narrow, well-specified tool: it moves an exact amount of a token from a buyer to a seller, per request, with the fee paid by someone else. Use it where a payment is small and the buyer is software. Keep agent balances small, prefer facilitators whose code you can read, and do not expect the protocol to settle disputes it was never designed to handle.

Sources: x402 specification (coinbase/x402: scheme_exact_stellar.md, scheme_upto.md, extensions/bazaar.md); x402.org (8 Oct 2026); SDF, "x402 on Stellar" (10 Mar 2026); Stellar docs, "x402 on Stellar", "Built on Stellar x402 Facilitator" and "MPP on Stellar"; stellar/x402-stellar README; npm registry, @x402/stellar; SCF #45 Round Recap (23 Sep 2026); tolgayayci/rail402 and rumblefishdev/stellar-x402 READMEs; DefiLlama stablecoins API (8 Oct 2026).