XRPL Commerce Verification: Trust Lines,
RLUSD, and NFTs in a Single API Call

The XRP Ledger now has RLUSD, native USDC from Circle, and a growing NFT ecosystem. But there has been no API for verifying XRPL holdings in a commerce context. InsumerAPI now supports the XRP Ledger across all 26 production endpoints. Verify native XRP, trust line tokens, issued currencies, and NFT ownership with the same API call structure used for 31 other chains.

Why XRPL needs commerce verification

XRPL has unique properties that make it well-suited for commerce. Transactions settle in 3-5 seconds. Trust lines let issuers create tokens without deploying smart contracts. RLUSD and Circle's native USDC bring institutional stablecoins directly onto the ledger. The recent surge in XRPL payment volume underscores the growing demand. But building on XRPL for commerce has meant writing custom verification code against XRPL's JSON-RPC interface.

A merchant who wants to offer 10% off to customers holding RLUSD cannot just call a standard ERC-20 balance check. XRPL uses trust lines, not token contracts. Balances live in a different data structure. Currency codes work differently. The tooling gap between "XRPL has stablecoins" and "a merchant can verify stablecoin holdings" is where InsumerAPI fits.

What is supported

XRPL is now a first-class chain in InsumerAPI, alongside 30 EVM chains and Solana. It is the third ledger architecture in the API: trust-line-based, alongside EVM contract-based and Solana account-based, all normalized to the same boolean output. The integration covers four asset types:

• Native XRP. Verify that a wallet holds XRP above a threshold. Use contractAddress: "native" and chainId: "xrpl".
• Trust line tokens (RLUSD, USDC, any issued currency). Verify holdings of any token issued on XRPL. Specify the issuer's r-address and a currency field. Standard 3-character codes like "USD" and longer token names like "RLUSD" both work.
• NFTs. Verify ownership of XRP Ledger NFTokens by issuer address. Optionally filter by taxon to target a specific collection.
• Wallet trust profiles. The XRPL dimension in POST /v1/trust includes two curated checks: RLUSD and USDC presence. An XRPL wallet passed alongside an EVM wallet produces a profile spanning up to 39 on-chain checks.

How a verification call works

The request format matches every other chain in the API. The only differences are the chain ID (the string "xrpl" instead of an integer), the wallet parameter (xrplWallet instead of wallet), and the optional currency field for trust line tokens.

To verify that a wallet holds at least 50 RLUSD:

• POST /v1/attest with xrplWallet set to the r-address
• One condition: type: "token_balance", contractAddress set to the RLUSD issuer (rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De), chainId: "xrpl", currency: "RLUSD", threshold: 50
• The response includes a ledgerIndex and ledgerHash (XRPL's equivalent of a block number and block hash) for independent snapshot verification, plus an ECDSA signature over the entire result

The response is a signed boolean. The wallet either meets the threshold or it does not. No raw amounts are exposed. The same verification flow used for EVM tokens applies here.

Try it live. Paste your own r-address and run a real RLUSD attestation in the browser. Open the interactive demo →

Multi-chain in a single call

XRPL does not exist in isolation. A customer might hold USDC on both Ethereum and the XRP Ledger. A trust profile might span EVM governance tokens, Solana stablecoins, and XRPL issued currencies.

InsumerAPI handles this natively. A single POST /v1/attest request can include conditions across EVM chains, Solana, and XRPL simultaneously. Pass wallet for EVM, solanaWallet for Solana, and xrplWallet for XRPL. All conditions are evaluated in one call, one response, one signature.

This is what makes the API useful for real commerce scenarios. A merchant running a promotion for RLUSD holders who also hold a governance token on Ethereum does not need two API calls and custom orchestration. One call handles it.

Commerce protocol support

XRPL wallets work with every commerce endpoint in the API, not just attestation:

• POST /v1/acp/discount and POST /v1/ucp/discount for AI agent commerce protocols. An autonomous agent can verify XRPL holdings before applying a discount, using the same ACP/UCP flow that works for EVM and Solana.
• POST /v1/verify for in-store verification. A merchant's scanner app verifies an XRPL wallet at the point of sale.
• GET /v1/discount/check for pre-checking eligibility before a customer arrives.
• POST /v1/trust and POST /v1/trust/batch for wallet assessment. The XRPL dimension adds 2 checks (RLUSD and USDC) to the standard 26-check EVM profile.

Available across all four SDKs

XRPL support is not limited to the REST API. It ships in all four agent integration SDKs:

• MCP Server (mcp-server-insumer v1.6.2): All 26 tools accept xrplWallet. AI agents using Claude, GPT, or any MCP-compatible model can verify XRPL holdings through their standard tool-calling interface.
• LangChain (langchain-insumer v0.9.13): All 26 tools accept xrpl_wallet. Python agents using LangChain or LangGraph get XRPL verification as a native tool.
• ElizaOS (@insumermodel/plugin-eliza): VERIFY_WALLET and CHECK_TRUST actions accept xrplWallet.
• OpenAI GPT: The updated GPT spec includes XRPL parameters across all 26 actions.

For AI agents operating in multi-chain environments, this means XRPL is not a special case. The agent calls the same tool it uses for Ethereum or Solana, just with a different wallet parameter.

Known XRPL tokens

Two tokens are pre-configured in the trust profile's XRPL dimension:

• RLUSD (Ripple USD): issuer rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De
• USDC (Circle): issuer rGm7WCVp9gb4jZHWTEtGUr4dd74z2XuWhE

Any issued token on XRPL can be verified through the attestation endpoint. You just need the issuer's r-address and the currency code. The trust profile curates the two most commercially relevant stablecoins, but the attestation endpoint is open to any trust line token on the ledger.

What the response includes

XRPL responses follow the same envelope as every other chain, with a few XRPL-specific fields:

• ledgerIndex and ledgerHash instead of blockNumber. These are the validated ledger sequence and hash at the time of verification, enabling independent snapshot reproduction.
• trustLineState for trust line token conditions, showing whether the line is frozen. A frozen trust line returns met: false even if the balance exceeds the threshold.
• currency in the evaluated condition, normalized to the 40-character hex format for non-standard currency codes.
• met: true/false per condition, with an overall pass boolean.
• The full response is ECDSA P-256 signed and verifiable against the public key at /.well-known/jwks.json or via the insumer-verify npm package.

One note: Merkle storage proofs are not available for XRPL. The XRP Ledger uses a different state tree structure than EVM chains. Standard attestation signing covers all XRPL verifications.

33 chains, one API

XRPL is the 32nd chain supported by InsumerAPI, with native Bitcoin bringing the total to 33. The full set now covers 30 EVM chains (Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain, Avalanche, Chiliz, Soneium, Plume, World Chain, and 19 more via indexed data), Solana (SPL tokens), and the XRP Ledger (native XRP, trust lines, NFTs).

Every chain works with every endpoint. Every response is ECDSA-signed. Every verification returns a boolean, not a raw amount. The same API key, the same authentication, the same response format. Whether a merchant wants to verify SHIB on Ethereum, USDC on Solana, or RLUSD on XRPL, the integration work is identical.