xrpldashboard

XRPL Credentials & Permissioned Domains, live

The Credentials amendment (XLS-70) lets one XRPL account attest something about another account on-ledger. The PermissionedDomains amendment (XLS-80) lets a domain owner declare which credentials it will accept as proof of access — the gating layer that turns attestations into entry rules. This page surfaces both: the credentials observable on mainnet through our seed-graph walker, and the active permissioned domains using them.

on ledger · enabled by validator majority
47
Credentials on mainnet
across the seed graph of 40 accounts · 2026-06-03T21:13:39Z
11issuers · 34subjects
distinct mainnet participants
37 accepted · 11 self-issued
0
Credential transactions in sample window
No CredentialCreate/Accept/Delete events in the last ~25 min. XLS-70 adoption is sparse — this stat will usually read zero.

How a Credential moves through the ledger

issuer
attesting account
a KYC provider, employer, exchange, or any account willing to put its name on an attestation
CredentialCreate →
subject
attested-about account
the account the issuer is making a claim about; must accept the credential for it to be effective
CredentialAccept →
verifier
gatekeeper
a PermissionedDomain, PermissionedDEX entry, or any account that checks for an accepted credential before granting access

What is on-ledger vs off-ledger

A Credential ledger object stores four things you can read directly from any rippled node: who the Issuer is, who the Subject is, a CredentialType code (a short label like "Passport" or "KYC-Tier-2"), and an optional URI pointing to a document that backs the claim. Optionally an expiration timestamp.

A Credential becomes "live" only after a two-step handshake. The Issuer submits CredentialCreate. The Subject then submits CredentialAccept against the same object. Only after acceptance does a verifier treat it as valid. Either side, or anyone with delete authority, can later remove it with CredentialDelete.

Credentials slot into the rest of the institutional stack via the same DepositPreauth machinery used for permissioned deposits. A PermissionedDomain can require "must hold an accepted Credential of type X issued by account Y" before allowing trades in a PermissionedDEX. That stack is designed to enable regulated markets to run on the XRP Ledger without each participant rebuilding compliance. Jump to the active PermissionedDomains on mainnet ↓

Scope of this page: we surface that a Credential exists, what type code it carries, and whether the Subject has accepted it. We do not (and will not) try to fetch the off-chain content of a Credential. The URI typically points to IPFS or an issuer-controlled document — whether the claim is honest, current, and meaningful is between the Issuer, the Subject, and whoever chooses to trust them. The dashboard reports what the ledger says, not what the underlying document means.

Examples observed on mainnet

Showing the first 10 of 47 Credentials reachable from the current seed graph of 40 known issuer/subject accounts.

Cards collapse when one issuer attests the same credential type and URI to multiple subjects.

NEXUS AUTH accepted attested to 3 subjects

issuer
rLGRav6ziCMTpQGeobWXz9gAs8kBstr2jU
subjects
r3Xo3TzqsYmytZHY6aZEh2akHe6Yt3PgA9
r4uXDHJFdGExnndRPeY4qPcTMH3GPwLetV
r4wka3TQLLkrt6trNy6ofGNocDmSxkNaFG
type code
4E455855532041555448 (NEXUS AUTH)
uri
ipfs://bafkreicgtkgptu4uf4omc3tth5zb6tjysznogfjkic4lm7uq2brzmmcbt4 (off-chain)
entry indices
F0EC4B3ADE0F30299D23CFB9967B1CBB520ADF57C080B7FCB307DA9C0BD25A4F
C9AC9E5A0D8141494B91F9730619F3621B9E80F31DA663FE35605DC60BED2D02
3DCA54920F2B56CAC46DFE9AE16A54A340F72F27959AFC18BFDFC6264FE86D50

LOOK HERE

issuer
raBopEaxzWRWsjqzXu2Ykur1YndYEFbgWG
subject
r4C88NG3qbu9z9eqRvCaXZXbGGoVFaLzTi
type code
4C4F4F4B2048455245 (LOOK HERE)
uri
This is a direct credential message test. (off-chain)
entry index
0CBD4D740278C1C74758EFEF349CABF21D23FFF8C6D9D81858BBDE05ADA849C6

OPEN ME

issuer
raBopEaxzWRWsjqzXu2Ykur1YndYEFbgWG
subject
r4C88NG3qbu9z9eqRvCaXZXbGGoVFaLzTi
type code
4F50454E204D45 (OPEN ME)
uri
Direct message test: this is a credential body for Xaman. (off-chain)
entry index
9824A2EA1E2479B63C3F52828763E9D3C81004C5FF8A3408CC87877DAE0687FC

XAPPMAG1

issuer
raBopEaxzWRWsjqzXu2Ykur1YndYEFbgWG
subject
r4C88NG3qbu9z9eqRvCaXZXbGGoVFaLzTi
type code
584150504D414731 (XAPPMAG1)
entry index
BBF1CCA1D84C228DC5D002F9493A16287E2E29F6A52EFD01AADEC8DCB1A9B6A9

EUROP_Approved accepted

issuer
rUhvWdQZKAyzVJPa3TiX9fULQswc5iinMn
subject
r4eVo8fqigp2WwkpmMCCFCVnqVssLXQJvv
type code
4555524F505F417070726F766564 (EUROP_Approved)
uri
https://schuman.io/terms-and-conditions/ (off-chain)
entry index
7EC2CA1DA04E80AB02F747C71605D3094E4AED6A0141901EB05C96A0606D5A55

member_v1 accepted self-issued

issuer
r97MGUDC6v7szXXu1JurAWQarueCi4isEv
subject
r97MGUDC6v7szXXu1JurAWQarueCi4isEv
type code
6D656D6265725F7631 (member_v1)
entry index
10C3892FAF15D206808858C034D62F627CF76A8C8B800B7EB193B2E7E4DB24FC

winner accepted self-issued

issuer
r97MGUDC6v7szXXu1JurAWQarueCi4isEv
subject
r97MGUDC6v7szXXu1JurAWQarueCi4isEv
type code
77696E6E6572 (winner)
entry index
17A15A70B00D856F9BDA956FC311A668581491C7D687B4A657466C6005FFC17F

hackaton_participation

issuer
r97MGUDC6v7szXXu1JurAWQarueCi4isEv
subject
rJ2nF4MZueH3rh5qsbFDvZk7ppJg7bssNm
type code
6861636B61746F6E5F70617274696369706174696F6E (hackaton_participation)
uri
{"event":"Ripple Hackaton IXH25","placement":"WINNER"} (off-chain)
entry index
E450A0CED9474EC3BA998FEC776F6345E537128FF98A5D8E958F81F0A34BD964

This is exhaustive for credentials whose issuer or subject is in our current seed graph. Issuers we don't yet know about are still picked up over time by a supplemental full-state walk, then folded into the seed set for the next cycle.

Permissioned Domains using these credentials

A PermissionedDomain (XLS-80) is an on-ledger object that declares an accept-list of credentials. To enter the domain — and the PermissionedDEX order books restricted to it — a wallet must hold at least one accepted credential, attested by an issuer the domain trusts. The two amendments compose: Credentials are the attestations, PermissionedDomains are the gates.

2 active permissioned domains on mainnet
Discovered by walking account_objects type=permissioned_domain across a 14-account institutional seed set. First dashboard to surface PermissionedDomain adoption.
walker pass: 2026-06-03T19:49:54Z · 14/14 accounts scanned · walk complete
multi-party + self-issued

Multi-party consortium: accepts attestations from 7 external issuers, plus self-issued credentials from the domain owner. (8 total accept-list entries.)

owner
rGKMDUdmquUCvoXxhcJSttnVnr2NYc9fYi
credential types
KYC
accept-list
  • rUujgL52fMEp5zf9bbYH1t5u52RPT1jtWa external · KYC (4B5943)
  • rDk1xiArDMjDqnrR2yWypwQAKg4mKnQYvs external · KYC (4B5943)
  • rNEJCPyv6D4BNcqtnWFcNWAai1qJLnDMEj external · KYC (4B5943)
  • rGKMDUdmquUCvoXxhcJSttnVnr2NYc9fYi self · KYC (4B5943)
  • rGm7WCVp9gb4jZHWTEtGUr4dd74z2XuWhE external · KYC (4B5943)
  • rJi1NFyZia2KfY472aQAUiDCr5Ssz5pXqk external · KYC (4B5943)
  • rMThU2t78UKig5vNzDLid7LKMEnCss3anG external · KYC (4B5943)
  • rMxCKbEDwqr76QuheSUMdEGf4B9xJ8m5De external · KYC (4B5943)
sequence
102095529
last on-chain touch
2026-06-03T19:50:00Z
previous tx
90A374B9C53E0BC74853AD1B35EAA948EA04112B07C592D5C153E20848C4B0F4
domain id
3125689BD765DA18AF4A9250F8BC96D1D5355C73044FD13A5D7682597D3722A8
single-party · self-issued only

Single-party domain: the owner accepts only credentials it has issued itself. Structurally a private access list, not a coalition.

owner
r9JoiCWSrNcebGfRoc8PP95SUQxXDAo4hZ
credential types
KYC
accept-list
  • r9JoiCWSrNcebGfRoc8PP95SUQxXDAo4hZ self · KYC (4B5943)
sequence
103472706
last on-chain touch
2026-06-03T19:50:00Z
previous tx
BB9D16250EA11DB0DC327B119A59D2C5110C84EB9349F07F3485CD0BF0B64D97
domain id
872D41243820C8FDE8EEB5F342224C0A02056FE873F6EDA4ABFA7C8C55633F82

Adoption is early — we surface every PermissionedDomain the walker finds rather than ranking or filtering. If the dataset grows or new credential types beyond KYC appear, this section spins out to a dedicated /permissioned-domains page.

Sources and references

Amendment hash: 1CB67D082CF7D9102412D34258CEDB400E659352D3B207348889297A6D90F5EF