The Credentials amendment lets one account prove something about itself to another account without either of them handling the evidence. An issuer checks your documents off the ledger, then writes a signed attestation onto it. That attestation says you passed. It does not say who you are, what you submitted, or what your passport number is.
That distinction is the entire design, and it is the reason this amendment matters more than its low profile suggests.
| Amendment | Credentials |
| Specification | XLS-70 |
| Activated | 2025-09-04 |
| Activation ledger | 98,615,297 |
| First shipped in | rippled 2.3.0 |
| Amendment ID | 1CB67D082CF7D9102412D34258CEDB400E659352D3B207348889297A6D90F5EF |
The problem this was built for
A public ledger has an awkward property for regulated finance: it settles between parties who were never introduced. That is the source of its usefulness and also the source of its legal difficulty. A regulated business cannot accept funds from an account it knows nothing about, and until recently the XRP Ledger gave it two bad options.
The first was to approve counterparties one at a time. Deposit Authorization has existed since 2018, and an account using it can name specific senders it will accept. That works until the list has four thousand names on it and every new client requires a ledger transaction from the business before they can do anything. It is one of the ledger’s oldest access-control amendments, and its limits are why the newer ones exist.
The second was to keep the check off the ledger entirely, in a normal compliance database. That works too, and it is what most regulated crypto businesses actually do. The cost is that the ledger no longer enforces anything. The rule lives in an application, and the ledger will happily settle a transaction the application would have rejected.
Neither option scales, and neither makes the ledger itself aware of who is allowed to do what.
What the amendment does
Credentials adds a new ledger object and three transactions that manage it. The structure is deliberately small.
A Credential entry on the ledger holds a Subject (the account the credential is about), an Issuer (the account that vouched for it), and a CredentialType, which is an arbitrary hex blob the issuer defines. Optional fields include an Expiration and a URI for additional data.
What that list leaves out is the point. There is no name field, no document field, and no personal data field of any kind. A credential is a pointer to a judgment somebody made off the ledger.
The flow runs across three parties:
- A business decides which issuers it trusts.
- A user sends documents privately to one of those issuers, off the ledger.
- The issuer reviews them and calls
CredentialCreate, writing the attestation on-chain. - The user calls
CredentialAccept, which sets thelsfAcceptedflag. - The user can now transact with any business that trusts that issuer.
Step four is easy to skim past and worth pausing on. A credential is not valid until its subject accepts it. Nobody can attach a label to your account without your participation, which closes an obvious abuse: an adversary issuing defamatory or jurisdiction-triggering credentials against accounts they dislike.
Revocation is symmetrical. The issuer can delete a credential when circumstances change, and the holder can delete their own.
The reuse property is what makes this more than a permission list. Once an issuer has verified a user, every business trusting that issuer can rely on the same credential. The user verifies once. The verification travels.
Why this is good for the XRP Ledger
The ledger gains a way to express authorization without gaining a gatekeeper.
Credentials do not create a central registry, and no party can decide globally who may use the network. What the amendment provides is a vocabulary: any account can state a requirement, any account can attest, and any account can decide which attestors it believes. A business that trusts nobody is unaffected. Base settlement stays open.
That matters because the alternative designs are worse for the ledger. Putting compliance logic into the settlement layer itself would make the ledger the arbiter of who is legitimate. Leaving it entirely to applications means the ledger cannot support regulated activity natively at all. Credentials takes the third path, where the ledger carries the claims and the participants choose their own trust graph.
It is also the substrate the later access-control work is built on. Permissioned Domains and Permissioned DEXes both define membership in terms of credentials, so this amendment is the dependency underneath the ledger’s institutional access-control stack rather than a standalone feature. It is also what makes compliant on-chain liquidity pools expressible at all.
Why this matters for institutional adoption
Institutions do not have the option of skipping identity checks. The constraint they actually face is subtler than “we need KYC,” and Credentials addresses the subtle version.
Privacy and compliance are simultaneous requirements, not competing ones. The BIS makes this explicit in Project Agorá, its tokenization work with seven central banks and a group of commercial banks, which examines how tokenized central bank reserves and commercial bank deposits can satisfy existing rules on settlement finality, anti-money laundering, and data privacy at the same time. A design that achieves compliance by publishing customer identity to a public ledger fails the third requirement while satisfying the second. The Credentials split, where attestations are public and evidence is private, is a direct answer to that shape of problem.
Verify once, use many times, is a stated policy goal. The European Union built exactly this into law with Regulation (EU) 2024/1183, which establishes the European Digital Identity Framework and its wallet: a reusable credential a citizen obtains once and presents to many relying parties. The XRPL implementation is narrower and lives on a settlement ledger, but the economic logic is identical. Repeated re-verification of the same customer by every counterparty is pure cost.
The model follows an existing standard rather than inventing one. The design draws on the W3C Verifiable Credentials Data Model v2.0, the same issuer, holder, verifier structure used across the wider digital identity field, with the deliberate difference that a subject is identified by an XRP Ledger address instead of a URL. For an institution, an implementation tracking a published standards-body model is easier to assess than a bespoke scheme.
Tokenized markets need this to function. The Monetary Authority of Singapore’s Project Guardian runs industry trials across tokenized funds, bonds, and bank liabilities, working toward standardized protocols across asset classes. Instruments like those carry eligibility rules. Accredited investor status, jurisdiction limits, and transfer restrictions are properties of the instrument, and enforcing them requires the venue to know something verifiable about the counterparty. This is the practical bottleneck sitting between tokenization as a concept and regulated instruments actually trading on a public ledger.
Where this is limited
Several things this amendment does not do.
It does not make anyone trustworthy. A credential is only as good as its issuer. The ledger enforces that an attestation exists and was accepted. It has no opinion on whether the issuer did competent work, and there is no built-in reputation system for issuers. That judgment stays with whoever relies on the credential.
Credential relationships are public. The documents stay off-chain, but the existence of a credential, its issuer, its subject account, and its type are all readable by anyone. That leaks information. An observer can see which accounts hold credentials from a particular issuer, and where a credential type is narrow enough, that may be more revealing than institutions expect. This is a real disclosure consideration rather than a solved problem.
It creates dependency on issuers. If a widely trusted issuer stops operating or has its keys compromised, every business relying on it has a problem at once. Concentration risk moves rather than disappearing.
Expiration is coarse. A credential can carry an expiration time, but there is no mechanism for continuous revalidation. A credential issued today and valid for a year says nothing about whether the subject’s status changed in month three, unless the issuer actively deletes it.
Enabled is not adopted. The amendment activated in September 2025. The existence of the capability tells you nothing about how many issuers operate today or how much value moves under credential gating, and the honest answer is that this is early.
Common questions
What is the XRPL Credentials amendment? It is a protocol change, activated 2025-09-04, that adds on-ledger credentials to the XRP Ledger. An issuer can attest that an account meets some criterion, and other accounts can require that attestation before interacting.
Does using Credentials put my personal information on the blockchain? No. Identity documents go to the issuer privately and off-chain. What appears on the ledger is the fact that an issuer vouched for an account, plus a type code the issuer defines.
Can someone issue a credential about my account without permission? They can create one, but it has no effect until you accept it with a CredentialAccept transaction. Unaccepted credentials do not authorize anything.
How is this different from DID on the XRP Ledger? A DID is an identifier an account controls for itself. A credential is a statement one account makes about another. They are complementary: the DID says who is speaking, the credential is what somebody else said about you. Both sit inside the ledger’s wider decentralized identity and KYC design.
Who decides which credential issuers are legitimate? Each business does, independently. There is no global list and no authority that designates approved issuers.
Educational only, not tax, legal, or investment advice. Nothing here is a recommendation to buy, sell, or hold any digital asset. Check primary sources and speak with a qualified professional before making financial decisions.
