Facilitator rejects cross-currency Payments (SendMax asset ≠ Amount asset) with verify_failed:unsupported_payment_features — feature request with full repro and on-ledger counter-proof

[vkostich]

Summary

The testnet facilitator rejects otherwise-valid cross-currency XRPL
Payments under the exact scheme. The blob parses (no longer
invalid_tx_blob); the rejection is explicit:
verify_failed:unsupported_payment_features. Supporting this would let
merchants quote in RLUSD while agents pay from XRP balances in a single
transaction, with conversion handled by the protocol-native DEX/AMM —
a capability unique to XRPL among x402 settlement chains.

Environment

• x402-xrpl==0.1.4 (PyPI), Python 3.12, Windows
• network xrpl:1 (testnet), facilitator https://xrpl-facilitator-testnet.t54.ai
• Date of runs: 2026-06-12 (US Pacific, early AM)
• Payer: rUoQ8iuNNaSM8Vo394ZcWi6NjGE4QGLkXh
• payTo: rp6L9vgThTwPoCvBMAZ3o7t3qtVHpqCwAx
• invoiceId of rejected run (for your logs): 77052C46486246828FB5B89F0499DF48

Reproduction

1. Merchant middleware quotes: amount 0.01, asset
   524C555344000000000000000000000000000000 (RLUSD), issuer
   rQhWct2fv4Vc4KRjRgMrxa8xPN9Zx9iLKV, sourceTag 21000001.

2. Payer holds XRP only. ripple_path_find returns
   source_amount: "16184" (drops) for 0.01 RLUSD with
   paths_computed: [] — i.e., direct conversion via the default path.

3. Construct Payment: Amount = {0.01 RLUSD, issuer above},
   SendMax = 100000 drops, Paths omitted (empty path set is invalid
   in xrpl-py's binarycodec), InvoiceID memo bound to the quote,
   SourceTag 21000001, tfPartialPayment NOT set. Sign locally.

4. Retry resource with PAYMENT-SIGNATURE. Facilitator response
   (verbatim body):

   {"x402Version":2,"resource":{"url":"http://127.0.0.1:8402/hello",
   "description":"RailGate demo endpoint","mimeType":"application/json"},
   "accepts":[{"scheme":"exact","network":"xrpl:1","amount":"0.01",
   "asset":"524C555344000000000000000000000000000000",
   "payTo":"rp6L9vgThTwPoCvBMAZ3o7t3qtVHpqCwAx","maxTimeoutSeconds":600,
   "extra":{"sourceTag":21000001,
   "issuer":"rQhWct2fv4Vc4KRjRgMrxa8xPN9Zx9iLKV",
   "invoiceId":"77052C46486246828FB5B89F0499DF48"}}],
   "error":"verify_failed:unsupported_payment_features","extensions":{}}

   Pre-submit hash of the rejected (never-settled) blob:
   509540BDE9273F6AC25835DDEF9F88032B770C2417DD7B271196D7CB74D7326C

Evidence the ledger supports this exact shape

The identical transaction shape (XRP SendMax → RLUSD Amount, default
path, no explicit Paths) settles when submitted directly:

• tesSUCCESS, validated ledger 18177250, ~1.618 XRP consumed at the AMM
  mid + 0.5% fee:
  https://testnet.xrpl.org/transactions/4E2ADADD66B3257D8FA8BF8F7A3023D3EA162387B7F9C38C25D37A8565E8DD2C
• Liquidity is not a constraint: testnet RLUSD/XRP AMM at
  rPn7kHwycXzS5XNj167CnKwC2t82yAAdNW (~525k XRP / ~326k RLUSD, 0.5% fee).

Same-asset IOU exact payments already verify and settle correctly —
confirmed funded run:
https://testnet.xrpl.org/transactions/9B3D9C9B37730D87D212219F983F36DC9EF8261E9CE3A340134CEC09F44CEDBE
So the gap is specifically: SendMax asset ≠ Amount asset.

Proposed verifier semantics (for discussion)

Accept a Payment under exact when:

• Amount/DeliverMax exactly equals the quoted {value, currency, issuer}
• Destination == payTo; InvoiceID matches the challenge
• tfPartialPayment is NOT set (ledger then guarantees delivery of
  the full Amount or the tx fails — closes the classic partial-payment
  exploit)
• SendMax may be any asset; Paths may be absent (default path) or present
• Settlement criterion unchanged: tesSUCCESS

Related minor findings (client-side, can file separately if preferred)

• to_currency_hex (client/presigned_payment_payer.py) accepts only
  3-char or 40-hex codes; the literal "RLUSD" raises ValueError.
  Quoting the 160-bit hex works; auto-encoding 4–20 char codes would
  improve DX.
• Passing paths=[] to xrpl-py's Payment raises IndexError in
  binarycodec path_set.py; a guard that omits empty paths in any future
  cross-currency payer avoids it.

Happy to share the full repro scripts, run additional funded testnet
cases, or draft a spec PR. Building an XRPL x402 merchant gateway and
would love to see this land — it's a genuine differentiator for XRPL
in the x402 ecosystem.

[tsubasakong]

Hi @vkostich — thank you for this. The repro, the on-ledger counter-proof, and the proposed verifier semantics were about as complete as a feature request gets, and they map almost exactly onto what we just shipped. Cross-currency exact payments are now supported.

What's live

• Facilitator: cross-currency verification is deployed on all environments — testnet (xrpl-facilitator-testnet.t54.ai), staging, and mainnet. Testnet was rolled to the new build today, so your exact environment is ready.
• SDK: x402-xrpl@0.3.0 on npm and PyPI, which adds the payer-side payWith / pay_with source-funding parameter.

How to run your RLUSD-quote / XRP-pay flow

One addition to your repro: it's opt-in per requirement. The merchant advertises the flag; the payer funds with a cross-asset SendMax.

1. Merchant — add crossCurrency: true to the 402 requirement's extra (alongside your existing issuer/sourceTag). In the SDK that's require_payment(..., extra={"crossCurrency": True}).
2. Payer — pass the XRP source as pay_with (drops). The client sets it as SendMax, keeps Amount as the exact RLUSD quote, and omits Paths:

   # asset encoding helper (see your finding #1 below)
   from x402_xrpl.xrpl_currency import resolve_currency_code
   # ...
   payer.prepare_payment(req, pay_with="100000")  # XRP drops = your SendMax ceiling

   TypeScript: preparePayment(req, { payWith: "100000" }).

That yields exactly the shape your direct-submit counter-proof settled with: Amount = {0.01 RLUSD}, SendMax = <XRP drops>, no explicit Paths, tfPartialPayment unset.

On your proposed verifier semantics — we implemented essentially your list:

• ✅ Amount/DeliverMax must equal the quote exactly; Destination == payTo; InvoiceID matches.
• ✅ tfPartialPayment must NOT be set — rejected unconditionally. Exactly your framing: full delivery or the tx fails.
• ✅ SendMax may be any asset (the whole relaxation), gated on the crossCurrency opt-in.
• ⚠️ One deliberate narrowing: explicit Paths are still rejected; the supported shape is default path (Paths omitted) — which is precisely your repro. If you have a concrete need for explicit Paths, open a follow-up and we'll look at it.

Your two client-side findings — both addressed in 0.3.0:

• resolve_currency_code("RLUSD", allow_utf8_symbol=True) now returns the 160-bit hex, so no more hand-encoding 524C5553440000….
• The client never emits Paths, so the paths=[] IndexError can't occur — for cross-currency, omit Paths and let the default path route through the AMM/DEX, as in your settled example.

A re-run with extra.crossCurrency: true on the quote and x402-xrpl==0.3.0 should clear the unsupported_payment_features rejection and settle. Would love to hear how it goes — and if you're still up for a spec PR documenting the cross-currency exact shape, that'd be very welcome.

[vkostich]

Verified end-to-end on x402-xrpl==0.3.0, testnet — it settles. 🎉

With extra.crossCurrency: true on the quote and Paths omitted
(default path), the XRP-funded / RLUSD-quoted payment that returned
unsupported_payment_features three days ago now returns 200:

• Rejected (explicit Paths set): verify_failed:unsupported_payment_features
• Settled (Paths omitted, default path):
  https://testnet.xrpl.org/transactions/8D252A09B570B41827EF0621FBFBFB74009CB3DA50E148F39D33CE464418CDF0

Confirms the deliberate narrowing too — explicit Paths rejected,
default-path shape accepted, exactly as you described. The
resolve_currency_code("RLUSD") helper and the no-emit-Paths client
change both work as documented; no hand-encoding needed.

Happy to land the spec PR. Here's the doc for review — point me at the
right path in the repo and I'll open it (or feel free to lift this
directly):

---

Cross-Currency Payments (exact scheme)

The exact scheme supports cross-currency payments: a merchant quotes
the price in one asset (e.g. RLUSD) while the payer funds from a
different asset (e.g. XRP). The XRPL default path routes the conversion
through the native DEX/AMM. The merchant always receives the exact
quoted asset and amount; conversion risk and slippage sit with the
payer, bounded by SendMax. Opt-in per requirement via
crossCurrency: true.

Merchant: advertising cross-currency

Add crossCurrency: true to the requirement's extra:

require_payment(
    path="/your-endpoint",
    price="0.01",
    pay_to_address=PAY_TO,
    facilitator_url=FACILITATOR_URL,
    network="xrpl:1",
    asset="RLUSD",
    extra={"issuer": RLUSD_ISSUER, "sourceTag": 21000001,
           "crossCurrency": True},
)

Payer: funding from a different asset

Pass the XRP source via pay_with (Python) / payWith (TS), in drops.
The client sets it as SendMax, keeps Amount as the exact quote, and
omits Paths:

from x402_xrpl.xrpl_currency import resolve_currency_code
payer.prepare_payment(req, pay_with="100000")  # drops = SendMax ceiling

Supported transaction shape

Payment
  Account     : <payer>
  Destination : <payTo>                          # == quote
  Amount      : { value, currency, issuer }       # exact quoted asset
  SendMax     : <drops>                            # source asset (e.g. XRP)
  InvoiceID   : <hash bound to the quote>
  SourceTag   : <advertised tag>
  Flags       : 0                                 # tfPartialPayment MUST be unset
  (Paths omitted — default path routes via DEX/AMM)

Verifier rules

• Requirement advertised crossCurrency: true.
• Amount/DeliverMax equals the quote exactly; Destination == payTo;
  InvoiceID matches.
• tfPartialPayment MUST NOT be set — rejected unconditionally (full
  delivery or the tx fails).
• SendMax may be any asset (the relaxation), gated on the opt-in.
• Paths omitted; explicit Paths rejected (default path only).
• Settlement unchanged: must reach tesSUCCESS.

Limitations

• Explicit Paths not supported — default path only.
• Liquidity, not protocol, bounds delivery: thin DEX/AMM depth surfaces
  as a failed payment, not a verifier rejection.
• Trust lines required: payer must reach the quoted asset via the route;
  merchant needs a trust line for an IOU quote asset.