Credentials and Permissioned Domains

Native XRP Ledger features for representing verified attributes on-chain and restricting participation to verified accounts.

The compliance problem these features address

Regulated financial activity often needs to verify something about a participant — that they've passed identity verification (KYC), that they're an accredited investor, that they're not on a sanctions list — before allowing them to transact. Historically, XRPL applications needing this kind of gating had to build it entirely off-chain or through custom application logic. Credentials and Permissioned Domains bring a native, standardized way to express this on-ledger.

Credentials

A Credential is a native ledger object representing a claim about an account, issued by another account acting as the credential issuer — for example, a licensed KYC provider issuing a credential to an account confirming it has completed identity verification. The credential is cryptographically tied to both the issuer and the holder, and can be checked by other parts of the protocol (or by applications) without needing to re-verify the underlying claim from scratch each time.

This is conceptually similar to a digital, on-chain analog of a verifiable credential or attestation — the ledger records that a specific trusted issuer vouched for a specific claim about a specific account, without necessarily exposing the underlying personal data itself on a public ledger.

Permissioned Domains

A Permissioned Domain uses Credentials to restrict participation in a specific context — for example, an issuer could define a domain requiring a specific KYC credential, and then restrict a trading venue, an AMM pool, or another feature to only accept participants holding that credential.

Why this matters for institutional adoption

Regulated institutions considering the XRPL for tokenized real-world assets or other compliance-sensitive activity have historically needed to build custom, off-chain gating logic, or avoid public, permissionless venues entirely. Native credentials and permissioned domains let compliance requirements be expressed and enforced directly at the protocol level, potentially making it practical to run a compliant, KYC-gated trading venue or asset offering using the same public ledger and native DEX/AMM infrastructure everyone else uses — rather than requiring an entirely separate, walled-off private deployment.

Relationship to other issuer controls

Credentials and Permissioned Domains complement, rather than replace, the Deposit Authorization and freeze/clawback features covered elsewhere in this section — together, they give issuers and application builders a fuller native toolkit for building compliant financial products directly on public XRPL infrastructure.

A relatively new addition

Like Multi-Purpose Tokens, Credentials and Permissioned Domains are a comparatively recent addition to the protocol, reached through the standard amendment process — reflecting the XRPL's ongoing evolution toward supporting more sophisticated, compliance-aware institutional use cases without compromising the base ledger's open, permissionless character for ordinary users.