A step-by-step guide for any team that issues a token or MPT on the XRP Ledger to publish a cryptographic two-way attestation between an issuer wallet and a public domain. Once both sides match, your project becomes verifiable by anyone — including this dashboard.
Who this page is for. Anyone who controls an XRPL issuer wallet and a web domain — a token issuer, an MPT issuer, a tokenized-RWA project, an institutional treasury. Setup takes roughly 15 minutes once you have access to both the wallet and the domain.
Anyone can put a string in their wallet's Domain field, and anyone can put a wallet address in a file on their website. Either by itself proves nothing — both are unilateral claims.
A two-way attestation is different. The wallet on-ledger says "I belong to this domain," and the domain says "this wallet belongs to me." When both sides match, an observer can verify the claim cryptographically without trusting either side individually — because controlling both sides requires controlling both the issuer's private key and the issuer's web infrastructure. That's the bar this dashboard, and most institutional indexers, use to call an issuer "verified."
Without it, we have no way to distinguish a legitimate issuer from a vanity wallet that happens to share a recognizable name. So we don't try — we list the project as pending attestation until the chain is in place. The same logic applies on the consumer side: wallet apps like Xaman, explorers like Bithomp and XPRSCAN, and most institutional indexers use this two-way handshake to decide what name to attach to a wallet.
Want to see a real one?
Ripple publishes a production TOML at ripple.com/.well-known/xrp-ledger.toml. It uses every canonical section ([METADATA], [[VALIDATORS]], [[SERVERS]], [[ACCOUNTS]], [[PRINCIPALS]]) and also includes two non-canonical custom blocks of Ripple's own ([[ISSUERS]] and [[TOKENS]]) for richer asset metadata. Those custom blocks are tolerated by the spec but not parsed by general-purpose XRPL tooling — for portability, stick to the canonical schema in your own TOML.
The mechanism is defined in XLS-26, an XRPL community standard. It uses two pieces:
AccountSet transaction. It points to a domain you control — e.g., example.com.
https://example.com/.well-known/xrp-ledger.toml. Inside, an [[ACCOUNTS]] entry lists the same wallet address.
A verifier (this dashboard, a wallet app, an indexer) reads the Domain field from the wallet, fetches the TOML at that domain, and checks that the file claims the same wallet back. Match → verified. Mismatch or missing → not verified.
Sign and submit an AccountSet transaction from your issuer wallet that sets the Domain field to your domain, hex-encoded (uppercase).
For domain example.com, the hex-encoded value is 6578616D706C652E636F6D. Most signing tools (Xaman/Xumm, GemWallet, xrpl-py, xrpl.js) accept the domain as a plain string and hex-encode it for you. The protocol stores it as hex; the human-readable form is just a presentation detail.
Example transaction body:
{
"TransactionType": "AccountSet",
"Account": "rYourIssuerWalletAddressHere...",
"Domain": "6578616D706C652E636F6D"
}
Once the transaction is included in a validated ledger, anyone can read the Domain field back via account_info against any public XRPL node and decode the hex to confirm the domain.
Create a plain-text TOML file and serve it from your domain at the exact path /.well-known/xrp-ledger.toml over HTTPS. The minimum required content is an [[ACCOUNTS]] entry that names the same issuer wallet you set the Domain field on.
Minimal example for an issuer of one token, using only canonical XLS-26 sections:
[METADATA] modified = 2026-05-17T00:00:00.000Z [[ACCOUNTS]] address = "rYourIssuerWalletAddressHere..." desc = "Primary issuer wallet for the Example Token (EXM)." [[CURRENCIES]] code = "EXM" issuer = "rYourIssuerWalletAddressHere..." display_decimals = 2 [[PRINCIPALS]] name = "Example Inc. — Compliance Desk" email = "compliance@example.com"
Every section above is defined in the canonical XLS-26 spec. The role of each block:
[METADATA] —
a single timestamp recording when the file was last updated. Optional but encouraged; helps indexers know if their cached copy is stale.
[[ACCOUNTS]] —
the wallets you are claiming. This is the half of the chain that closes the loop with the on-chain Domain field. List multiple entries here if you have hot/cold, treasury, or operational wallets to disclose.
[[CURRENCIES]] —
the tokens you issue. The issuer field MUST point to a wallet listed above in [[ACCOUNTS]]. The code field is the on-ledger currency ticker. Optional fields include display_decimals, symbol, and network (use "main" for the production XRP Ledger; omit to default to main).
[[PRINCIPALS]] —
the people or business contacts associated with the issuer. Useful for wallets, indexers, or regulators that need a verified point of contact.
The full schema (including [[VALIDATORS]], [[SERVERS]], and every optional field on each section) is documented in the xrpl.org reference. The spec also permits custom non-standard fields — tools tolerate them but will silently ignore typos and any sections not defined here, so stick to canonical names unless you know exactly what you're doing.
CORS matters.
Many wallet apps and indexers fetch the TOML from the browser. The response must include Access-Control-Allow-Origin: *, or those clients won't be able to read it. Most CDNs let you set this with one line of config.
Before announcing anything, prove both sides match. You can do this from a terminal with no special tooling.
Check the file is reachable:
curl -sS https://example.com/.well-known/xrp-ledger.toml
You should see the TOML you published. Anything else (404, HTML, redirect to a landing page) means it is not yet correctly served.
Check the wallet Domain field:
curl -sS -X POST -H 'Content-Type: application/json' \
--data '{"method":"account_info","params":[{"account":"rYourIssuerWalletAddressHere..."}]}' \
https://s2.ripple.com:51234/
In the JSON response, look for account_data.Domain. Decode the hex (any hex decoder, or python3 -c "print(bytes.fromhex('...').decode())") and confirm it matches the domain serving your TOML.
If both sides agree, the two-way chain is closed. Anyone in the world can now verify your issuer the same way.
Official checker (browser). The XRP Ledger Foundation runs a hosted verification tool at xrpl.org/resources/dev-tools/xrp-ledger-toml-checker. Paste your domain into the "Look Up By Domain" form, or your wallet address into "Look Up By Account," and it walks the two-way chain and reports any mismatch. Use this as the canonical green-light before announcing.
This dashboard runs a periodic sweep that rechecks the Domain field and TOML file for every issuer wallet we know about. Once the chain matches, your project will move from pending to verified on the next sweep — typically within a day. Other XRPL surfaces (wallet apps, block explorers, third-party indexers) operate on their own schedules.
To accelerate the check on this dashboard specifically, send us a note (link at the bottom of this page) with the wallet address and the domain. We will re-run the check on demand.
Wrong path.
The file must live at /.well-known/xrp-ledger.toml exactly. Not /xrp-ledger.toml. Not /well-known/.... The leading dot in .well-known is a real, standardized directory name (RFC 8615).
Wrong domain in the wallet.
The Domain field must be the bare domain — e.g., example.com, not https://example.com or example.com/about. Verifiers prepend https:// and append /.well-known/xrp-ledger.toml themselves.
Soft 404 from a single-page app.
If your domain serves a React/Vue/etc. SPA, the server may return HTML for every path — including /.well-known/xrp-ledger.toml — instead of a real 404 or the actual file. Configure your web server or CDN to serve the TOML as a static file before the SPA fallback rule.
Content-Type mismatch.
The TOML should be served as text/plain or application/toml. If your server sends text/html or application/json, some clients will reject the response. curl -I against the URL shows the headers being returned.
Apex vs. www mismatch.
If your wallet Domain field is example.com, verifiers fetch from https://example.com/.well-known/xrp-ledger.toml — not www.example.com. Either serve the file from both, or make sure the apex resolves and serves the file directly.
If you have completed all four steps and the chain checks out, send us a short note at contact@xrpldashboard.com with your wallet address and your domain. We will re-run the verification, and on a match your issuer moves to the verified list on /rwa.
We do not charge for verification, do not run a paid placement program, and do not promote one issuer over another. The list is curated solely on whether the on-chain Domain field and the off-chain TOML claim each other.