Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 42 additions & 1 deletion docs/build/agentic-payments/x402/README.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -59,7 +59,7 @@ x402 on Stellar supports any [SEP-41](https://stellar.org/protocol/sep-41) compl

## x402 Facilitators

You can use a facilitator to verify and settle x402 payments. Two options are available for Stellar:
You can use a facilitator to verify and settle x402 payments. Two production implementations are available for Stellar, plus one community-run pre-production option listed at the end of this section:

### Coinbase x402 Facilitator

Expand Down Expand Up @@ -95,6 +95,47 @@ This version supports x402 v2 specification. For x402 v1 support, please use a p

:::

### Community facilitators
Comment thread
davedumto marked this conversation as resolved.

The following facilitators are built and operated by the community. They are not
maintained by SDF and are at varying stages of readiness, so check each project's
current status before depending on it.

#### Vellar Facilitator

[Vellar](https://github.com/Vellar-Wallet/vellar-facilitator) is an Apache-2.0
x402 facilitator that pairs the standard `/verify`, `/settle`, and `/supported`
endpoints with a **Bazaar discovery layer**: when a payment settles and its
payload carries the Bazaar discovery extension, the facilitator may add the
resource to a searchable catalog, so sellers that use the extension are listed
without a separate registration step. Cataloging is conditional and can be
refused for invalid discovery data, or when the resource URL is already bound
to a different recipient; settlement succeeds either way, and payments without
the extension settle normally but are never cataloged. The catalog is also
reachable by AI agents through an
[MCP](https://modelcontextprotocol.io) discovery server (`src/mcp.ts` in the
repository), which is a separate stdio process you run locally and point at the
facilitator URL; the hosted instance does not expose an MCP endpoint itself. The
facilitator sponsors the settlement transaction fee, so buyers do not need XLM
to pay for the transaction itself. Classic Stellar accounts still maintain their
own base and trustline reserves.

- **Facilitator**: `https://vellar-facilitator.onrender.com`
- **Source**: https://github.com/Vellar-Wallet/vellar-facilitator
- **Docs**: https://docs.vellar.xyz

:::note

Vellar runs on **Testnet only** and is pre-production; there is no mainnet
instance. The facilitator has completed an internal pre-mainnet security review,
with most findings closed and the remainder documented as open or deferred. A
mainnet release is separately gated on an external audit covering the
facilitator and its three provenance contracts, which has not yet been
commissioned. The hosted instance runs on a free tier, so the first request
after an idle period can take up to a minute.
Comment on lines +130 to +135

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Respectfully, I think this reverses the earlier finding rather than restoring it. The 09:13:36Z review on the previous revision flagged the spending-limit-only wording as understating the scope, and asked for the full gate to be described; 9d30a1d is that change.

The current text matches the project's own documents:

  • technical-doc.md, pre-mainnet checklist item 1: "External security audit | Not started".
  • technical-doc.md, milestone 3: the audit covers "Facilitator + its three provenance contracts (attestation registry, verified-recipient policy, spending-limit policy)", described as "a second, independent review on top of the already-completed pre-mainnet review".
  • docs/mainnet-deployment-checklist.md: "Item 1 (external security audit) remains open and is a hard blocker".

So the completed review is the internal pre-mainnet one, and the outstanding external audit covers the facilitator plus all three contracts, not the spending-limit contract alone. The "separate audit of the spending-limit policy contract" wording in fe2112e was my error, which is why it was corrected.

Happy to reword for clarity if any part reads ambiguously, but I do not think reverting to the narrower scope would be accurate.


:::

## Examples

- **x402 on Stellar (Stellar repo)** — Tools, examples, and references for the x402 protocol on Stellar. Use this as the canonical source for Stellar-specific x402 demos and tooling. [View on GitHub](https://github.com/stellar/x402-stellar)
Expand Down
Loading