Conformance
What OpenWallet implements, against which pinned sources, and how it is tested against other implementations.
Pinned sources
| Source | Pinned at |
|---|---|
x402 specification (v2), x402-foundation/x402 | 6b6ee91fee027b540faabcb25774e73851006c3b (29 Sep 2026) |
XRPL exact scheme, specs/schemes/exact/scheme_exact_xrpl.md | same commit; file SHA-256 c8defedd55c76aada590283605f985fb7c237e68c6eec2db7b96552bf1f28bf9; introduced 3 Jul 2026, revised 14 Jul 2026 |
x402 over MCP, specs/transports-v2/mcp.md | same commit |
| Reference packages | npm @x402/xrpl 2.28.0 and @x402/mcp 2.28.0 |
| MCP | Specification 2026-07-28; clients on 2025-11-25 are also served |
| XRPL network ids | CAIP-2 xrpl:{NetworkID} |
What is implemented
| Item | Status in the spec | OpenWallet |
|---|---|---|
| x402 v2 HTTP transport | Normative | Client and merchant |
| x402 v1 | Normative, but the XRPL scheme is v2 only | Refused with x402_v1_unsupported; X-PAYMENT-RESPONSE read as a fallback |
exact on XRPL: XRP and issued tokens | Merged | All of it: both asset kinds, invoiceId, destinationTag, issuer, both transfer methods (tickets behind a grant switch), authorization and upfront |
Facilitator API /verify, /settle, /supported | Normative | The merchant library calls them, or verifies and submits by itself |
| x402 over MCP | Normative | As a client (paying a paid tool) and in the merchant library (building one) |
payment-identifier extension | Normative | Client and merchant |
bazaar extension | Normative | Echoed unchanged |
sign-in-with-x and EVM-only extensions | No XRPL definition | Echoed unchanged, never acted on |
upto, batch settlement on XRPL | Not standardised | Not shipped; refused with unsupported_scheme |
| A2A transport | Normative | Not supported |
What OpenWallet signs is strict: it always adds payload.invoiceId beside signedTxBlob, adds SourceTag only when a 402 asks with extra.sourceTag, never adds Memos, accepts an entry where areFeesSponsored is absent (XRPL cannot sponsor fees) and refuses one where it is true. This exact shape passed /verify and settled on both x402.org and t54 on Testnet on 30 September 2026.
Interop matrix
The interop tests run this matrix on Testnet. "Expected to fail" cells assert the documented failure, so a change in either facilitator shows up.
| Payer ↓ · Merchant → | x402-xrpl, self | x402-xrpl + x402.org | x402-xrpl + t54 | @x402 reference + x402.org | t54 SDK merchant |
|---|---|---|---|---|---|
openwallet-agent | passes: XRP, RLUSD, sequence, tickets | passes | passes (sourceTag) | passes | passes |
@x402/xrpl client | passes | passes | expected to fail | passes | expected to fail |
t54 x402-xrpl payer | expected to fail (Memos) | expected to fail | passes | expected to fail | passes |
Known facilitator differences
- t54 needs
payload.invoiceIdand aSourceTag, omitsareFeesSponsoredin its 402s, and acceptsMemos. - x402.org is Testnet only for XRPL and ignores
payload.invoiceId. - Duplicate settlement: both returned
success: truetwice for one blob in a single Testnet test. Merchants should keep their own atomic gate on the hash and the invoice, as the library does. - xrpl.org's "Agentic Payments with x402" page describes the client as submitting the transaction and using
X-PAYMENT. In v2 the client signs without submitting and sendsPAYMENT-SIGNATURE. Build from the spec.
Where the evidence is thin
- t54's Mainnet behaviour (fee cap, expiry bound, how long it deduplicates). Only its Testnet facilitator was probed.
- Whether the facilitators' duplicate-settlement behaviour is consistent: it rests on one sample each.