XR-Trust

For developers & AI agents

Pay $0.10 per query, no API key

XR-Trust implements x402 v2 with the exact scheme on XRPL mainnet. Verification and settlement are delegated to the t54 XRPL facilitator.

1. POST /scan returns 402 Payment Required with the XRP option (RLUSD coming in a follow-up).
2. Sign an XRPL Payment matching the requirement, base64-JSON-encode it, send as PAYMENT-SIGNATURE.
3. Server verifies, looks up the domain or owner, then settles. Returns 200 with the JSON and a PAYMENT-RESPONSE header.

Swagger UI OpenAPI spec agents.json /schema

Or skip the integration: call xrpl_trust_list_domains, xrpl_trust_get_domain, xrpl_trust_credential_issuers, or xrpl_trust_recent_events from any MCP client (Claude Desktop etc.) via @xrpl-utilities/mcp or the hosted endpoint at mcp.xrpl-utilities.io/mcp. Same x402 model, just wrapped as MCP tools.

# pip install x402-xrpl

from x402_xrpl import X402RequestsSession
from xrpl.wallet import Wallet

session = X402RequestsSession(
    wallet=Wallet.from_seed(seed),
    rpc_url="https://xrplcluster.com",
    payment_requirements_selector="XRP",
)

# look up a single domain by its 64-hex LedgerIndex
record = session.post(
    "https://trust.xrpl-utilities.io/scan",
    json={"domain_id": "AB12…"},
).json()

for match in record["matches"]:
    print(match["owner_address"],
          match["accepted_credentials"])

Output shape

What you get back

domains[]: one normalized record per PermissionedDomain ledger object
domain_id, owner_address, sequence, flags, previous_txn_id, previous_txn_lgr_seq: full XLS-80 ledger-object metadata
owner_label: XRPScan label when available ({name, desc, domain, verified, twitter}), else null
accepted_credentials[]: each entry carries {issuer, credential_type, credential_type_decoded, issuer_label}. Hex types are decoded to ASCII when printable (e.g. 4B5943 → KYC).
institutional_issuer_count + institutional_issuers[]: count and display names of distinct XRPScan-labeled, non-self credential issuers accepted by the domain
Drill-down only (single-domain lookup): lifecycle (creation + last-modified meta walked from PreviousTxnID), permissioned_market (XLS-81 owner-side offers + AMMs), and identity (XLS-40 DID + parsed .well-known/xrp-ledger.toml when published)
walk_status: one of complete, warming, truncated_total, or error_<status>
total, limit, offset, next_offset, schema_version, generated_at: pagination + envelope
/credentials/issuers returns issuers[] with {issuer_address, issuer_label, domains_referencing, credential_types_issued}

Reserved fields surfaced as null in v1, populated later: member_count_estimate, verified_attestation, health_score. Full field-level details at /schema.

How it works

Reads the validated XRPL ledger directly

Source. XR-Trust reads PermissionedDomain ledger objects directly from the validated XRPL ledger via a Clio data-layer node (ledger_data type=permissioned_domain). No third-party indexer, no editorial filter, no curated list. If it's on-ledger and validated, it's in the directory.

Materialization. A background warmer task walks the full PermissionedDomain set every six hours and atomically swaps the in-memory snapshot. The previous snapshot keeps serving while the next walk runs, so reads stay instant. Every response carries a walk_status field so you can tell whether the snapshot is complete, warming on first boot, or partial.

Drill-down vs enumeration. Looking up a single domain by its domain_id is O(1) regardless of warmer state. The service goes straight to ledger_entry. Whole-network enumeration relies on the materialized snapshot.

Owner labels. Where XRPScan recognizes a domain owner (banks, asset managers, infrastructure providers), the label appears on the directory row and the drill-down panel. Unlabeled owners surface their raw classic address.

Cross-product link. Every drill-down includes a one-click jump to XR-Sentinel to inspect the owner's on-chain behavioral pattern. Eventually the same panel will surface XR-Telemetry macro context and the XR-Pulse permissioned_domain_lifecycle event feed; both are queued for v2.

What XR-Trust is not

Descriptive directory, not a verdict

Inclusion in this directory does not imply legitimacy. Absence does not imply illegitimacy. We surface what the validated XRPL ledger says exists; we do not certify it.

· Not a compliance, AML, sanctions, or KYC determination of any domain, owner, credential issuer, or member
· Not a certification of any credential issuer's authority to attest the credentials they issue
· Not an endorsement of any domain owner's identity, jurisdiction, or business practice
· Not legal, regulatory, or investment advice
· Not a member-eligibility check. Membership in a permissioned domain is implicit (any address holding an accepted credential), and v1 does not estimate member counts

XR-Trust describes what's on-chain. Compliance, verification, and trust judgments remain the responsibility of the consumer.