Credentials: Building a Compliant Identity Layer for the XRP Ledger

Credentials is a new feature that provides a secure, lightweight framework for issuing, managing, and verifying user credentials directly on the XRP Ledger, enabling robust compliance while preserving user privacy.

Last year, the RippleX team introduced the XLS-70 spec for the XRPL, and it is currently undergoing the amendment voting process as part of the rippled 2.3.0 release. This article will cover how the feature is built, what it enables, and how it fits into a bigger picture of enabling compliant, institutional-grade DeFi on XRPL.

Robust Build

Credentials are designed to be a lightweight feature and are additive to the recent Decentralized Identity (DID) standard. The Credentials standard introduces a new Credential ledger object along with new transaction types for creating, accepting, and deleting credentials.

• Credential ledger object
  • Stores basic details about a credential such as issuer, subject, credential type, optional expiration, and URI.
  • A flag (lsfAccepted) indicates whether the subject has accepted it. Before acceptance, the issuer maintains the reserve; after acceptance, the subject does.
  • A credential is considered “valid” if it has been accepted by the subject and is not expired.
• Extended Deposit Authorization flow
  • Deposit Authorization is an optional feature that blocks direct incoming payments from unknown senders, requiring explicit preauthorization or self-initiated transactions to receive funds. Entities may comply with regulations that require knowledge and control over inbound transactions.
  • DepositPreauth is an existing object type that allows an account requiring deposit authorization to explicitly preauthorize specific sending addresses to send direct payments. Essentially, it acts as a whitelisting capability for deposit authorization.
  • With Credentials, DepositPreauth is extended to allow specifying credentials rather than only individual accounts, meaning an account may require incoming transactions to provide valid credentials (e.g. KYC status) issued by one or more trusted issuers.
  • Internally, DepositPreauth objects can now hold an array of (Issuer, CredentialType) pairs in place of an account. A transaction must include the specified credentials to be authorized.
  • Transactions that require showing credentials include a CredentialIDs field listing the valid credential object IDs. The ledger checks those objects to confirm validity, issuer, subject, and expiration before allowing the transaction.
• New Transaction Types
  • CredentialCreate: An issuer creates a credential ledger object on the XRPL, specifying the subject, credential type, optional expiration, and related data.
  • CredentialAccept: The subject uses this transaction to “accept” the credential, flipping the lsfAccepted flag and transferring its reserve burden from the issuer to the subject.
  • CredentialDelete: Either the issuer or the subject can delete a credential at any time. Anyone can delete it if the credential has expired.

Immediate Use Cases

Upon activation, developers may utilize the Credentials feature to streamline user onboarding processes. It will first work with Deposit Authorization, where senders can be automatically approved, instead of a manual process. Credentials can also be used to authorize off-ledger activities in association with a decentralized identifier.

Because the robust design of Credentials combines on-ledger credential objects, enhanced DepositPreauth checks, and specialized transaction types, it allows for issuing, accepting, revoking, and using credentials directly on XRPL without exposing personal data. Essentially, privacy is an embedded use case within the design of this feature.

Broader Implications

Credentials can be thought of as a modular building block to DID. It can be applied to attest to some criteria (e.g. KYC) for a user and issued to their DID. This may create an important foundation for enabling a smooth onboarding process when accessing products like tokenized RWAs.

Two additional features on the RippleX team’s roadmap, Permissioned Domains and a Permissioned DEX, may build on top of Credentials and DID to facilitate a flexible, institutional grade identity system on XRPL:

• Permissioned Domains is a protocol that enables an entity such as a financial institution to create a controlled environment on XRPL that requires specified credentials for access. Here are a few ways this can work with the Credentials feature:

  • Credential-Gated Membership: A domain object can list accepted credentials, such that any account holding any one of those credentials is automatically considered a member.
  • Streamlined Control: Organizations can define requirements (like KYC credentials from a trusted issuer) and manage who joins or transacts within a domain.
  • Privacy Preservation: Rather than upload personal information, users only prove they hold a required credential. The ledger itself only tracks whether the user’s credential is valid and accepted by the domain.
  • Additionally, Permissioned Domains will enable a Permissioned DEX and could be used with the upcoming lending protocol.

• Permissioned DEX is a protocol that extends the XRPL’s built-in decentralized exchange (DEX) to operate in a controlled environment, where creating or filling orders requires specified credentials.

  • Restricted Orderbooks: An offer tagged with a domain ID can only be matched by other offers from accounts within the same domain who also hold valid credentials.
  • Regulatory Compliance: Institutions can trade on the XRP Ledger’s DEX while enforcing AML/KYC rules. Only properly credentialed accounts in the same domain can interact with one another on that orderbook.
  • Controlled but Still Decentralized: Instead of splitting into separate private blockchains or specialized tokens, the Permissioned DEX reuses XRPL’s core DEX capabilities—just with added checks to ensure participants belong to the same, credential-gated domain.

Taken together, DIDs serve as a foundational “fingerprint” for each user, while Credentials provide the identity and compliance layer required for different scenarios. Building on these foundations, Permissioned Domains and Permissioned DEX protocols enforce membership and compliance rules by requiring the appropriate DID-based Credentials, all while preserving the decentralized nature of the XRPL.

How to Vote for the Credentials Amendment

To support the adoption of Credentials on the XRPL, you can participate in the amendment voting process!

Refer to the Amendments Guide for a step-by-step overview of how to vote.

New to XRPL? This guide also explains how the amendment process works and how you can contribute to the network’s evolution.

For more information and updates, visit the XRPL Credentials Overview.