XLS-d: Open NFT Issuer Registry — verified mapping from organisations to XRPL NFT-issuing accounts

[eamwhite1]

Hi all,

I'd like to open a discussion on a small but missing piece of NFT infrastructure on XRPL: a public, verifiable mapping from organisation identities to the wallets they use to mint NFTs.

The gap

XRPL NFTs (XLS-20) are increasingly used as proofs of real-world events — a shipped container, a sold ticket, a completed certification, an issued credential. The cryptography proves that an NFT was minted by a specific wallet. But there is no public infrastructure that proves who controls that wallet.

A buyer (human or AI agent) receiving an NFT today must either trust the seller's word about the issuer, or manually search for an off-chain attestation. The pieces to close this exist on XRPL already: xrp-ledger.toml binds wallets to domains, and on-chain Domain fields work in the opposite direction. What's missing is the lookup layer that ties them together at internet scale.

What I'm proposing

An open, chain-agnostic-in-design, XRPL-reference-implemented standard for an NFT Issuer Registry:

Organisations register their issuing accounts; the registry verifies bidirectionally via xrp-ledger.toml and on-chain Domain fields.
The registry publishes a versioned JSON feed (GET /nft/issuers/feed) with a stable schema, pagination, and incremental sync support — any wallet, DEX, explorer, or agent can consume it. Discovery via GET /.well-known/xrpl-issuer-registry lets tools auto-resolve a registry from a domain.
The spec supports multiple registries — no single operator is a chokepoint.
An MCP server exposes list_trusted_issuers, company_xrpl_lookup, verify_nft_proof, and verify_domain_ownership so AI agents can check issuer identity inline.
Full draft spec, schema, and rationale: https://www.cryptovault.co.uk/docs/issuer-registry-spec.md

Why this is worth standardising rather than just shipping

If different wallets, marketplaces, and agent frameworks each invent their own issuer-trust mechanism, end users will face inconsistent and conflicting signals about the same wallet. Standardising the schema and the discovery path lets Xaman, XPMarket, Bithomp, XRPScan and others surface the same verified identity in the same way — without anyone having to trust a single registry operator.

The closest adjacent work is XLS-26 (native DIDs). This proposal is complementary rather than overlapping: when XLS-26 ships, the registry becomes a natural resolver between a DID and its XRPL accounts.

Reference implementation

There's a working registry live today operated by AgentTrust, with seeded entries for several XRPL projects. The API is at https://xrpl-referee.onrender.com/nft/issuers and the MCP server at https://xrpl-referee.onrender.com/mcp. I'd rather get the spec right with community input than expand it unilaterally, which is why I'm posting here before pushing wider adoption.

What I'd value feedback on

Verification model — TOML bidirectional check is the minimum viable. Should the spec also require a signed registry entry (issuer signs their listing), or is that overkill given DNS already gates TOML?
Re-verification cadence — should this be normative (MUST re-verify every N days) or advisory?
Categorisation — should the schema include a structured category field (ticketing, logistics, certification, etc.) or leave that to clients?
Relationship to XLS-26 — if XLS-26 contributors are reading this, I'd love to align early so the registry can serve as the canonical DID→account resolver once DIDs ship.
Happy to iterate on the draft, open a PR for an assigned XLS number once there's directional consensus, and donate the reference implementation to the Foundation if that's the preferred ownership model.

Thanks,
Ed White
AgentTrust — cryptovault.co.uk