XRPL Credentials (XLS-70) Explained for Token Holders

You Tried to Buy a Token and Got Blocked

It happens more than people expect. You connect your XRPL wallet, find a token you want to hold, and the transaction fails. The issuer has set a requirement you can't see and don't know how to meet. In many cases, that requirement is a credential, and without one, the ledger simply won't let the transfer go through.

XLS-70 is the XRPL standard that makes credentials possible at the protocol level. If you hold XRPL tokens, or plan to, understanding how this works will save you confusion and missed opportunities.

What XLS-70 Actually Is

XLS-70 is a proposed and now active XRPL standard that adds a native credential object to the ledger. Think of it like a verifiable badge attached to your wallet address. It says something specific about you, and it's issued by a trusted party rather than self-reported.

Before XLS-70, issuers who wanted to restrict token access had no clean way to do it on-chain. They could use trust line flags or off-ledger checks, but nothing was standardized. XLS-70 gives issuers a consistent mechanism to say: only wallets holding credential X can interact with this token.

Credentials live on the ledger as first-class objects. They're tied to a specific account, issued by a specific issuer, and can have an expiration date. They're not stored in your wallet app. They're on-chain.

The Three Parties Involved

Every credential transaction involves three roles.

The issuer. This is the entity that creates and signs the credential. It could be a compliance provider, a KYC service, a DAO, or a project team. The issuer's address is part of the credential object itself, so anyone can verify who issued it.

The subject. That's you. The subject is the wallet address the credential is assigned to. You don't create the credential, but you do need to accept it before it becomes active.

The token issuer. This is often a separate party from the credential issuer. They've set a deposit preauthorization or permission requirement that checks for specific credentials before allowing a transfer or trust line.

These roles can overlap. A project might issue its own credentials and its own tokens. But in regulated contexts, they're usually separate.

How a Credential Gets Created and Accepted

The flow is straightforward once you've seen it.

1. You complete some off-ledger process. This could be a KYC check, an accreditation verification, a membership confirmation, or anything else the issuer defines.
2. The issuer submits a CredentialCreate transaction on the XRPL, naming your wallet address as the subject.
3. The credential object appears on the ledger in a pending state.
4. You submit a CredentialAccept transaction from your wallet to activate it.
5. The credential is now live and readable by any smart contract, AMM, or token issuer that checks for it.

Step four matters. You have to explicitly accept the credential. This prevents issuers from assigning attributes to wallets without the holder's consent.

What Token Issuers Can Do With Credentials

Once credentials exist on the ledger, token issuers can build rules around them.

The most direct use is deposit preauthorization with credential requirements. An issuer can configure their token so that incoming transfers are only accepted from addresses holding a valid credential from a trusted issuer. If your wallet doesn't have that credential, the payment fails at the protocol level.

This is not a front-end restriction. It's enforced by the ledger itself. No amount of wallet switching or API workarounds gets around it.

For you as a token holder, this means two things. First, if you hold a token that later adds a credential requirement, your existing balance isn't affected. You already hold it. Second, if you want to receive more of that token, you'll need the credential before the next transfer can succeed.

Credentials can also expire. An issuer can set an expiration date on the credential object. Once it expires, you'd need to go through the verification process again and get a new one issued. This matters for things like annual accreditation renewals or time-limited compliance checks.

Why This Matters More Than You Might Think

The push toward credential-gated tokens isn't arbitrary. Regulated asset issuance on public blockchains has always faced the same problem: how do you enforce real-world rules without compromising the open nature of the ledger?

XLS-70 gives issuers a way to do that without moving to a permissioned chain or relying on custodians to gate access. The ledger stays public. The rules stay enforced.

For token holders, this is a shift in what it means to manage your XRPL portfolio. Holding tokens will sometimes require holding credentials. Managing those credentials, knowing when they expire, understanding who issued them, becomes part of managing your assets.

Privacy is also part of the design. A credential can attest to a property, like being a verified accredited investor, without revealing the underlying personal data. The verifier sees the credential. They don't see your documents.

How Rhyzlo Fits Into This

Rhyzlo is built specifically for XRPL trust infrastructure, and credential management is a core part of that. The platform gives token holders a clear view of which credentials are attached to their wallet, who issued them, and when they expire. For projects and issuers, Rhyzlo provides the tooling to issue, manage, and revoke credentials at scale without building custom on-chain infrastructure from scratch.

If you're trying to figure out why a token transfer is failing, or you're a project planning to gate a token issuance, having a credential layer you can actually see and manage makes a practical difference.

Common Questions Token Holders Ask

Can I transfer my credential to another wallet? No. Credentials are bound to the subject address. They don't transfer.

What happens if my credential expires mid-hold? Your existing balance is unaffected. You just can't receive new transfers until you renew.

Can an issuer revoke a credential? Yes. The issuer can submit a CredentialDelete transaction to remove it. This is important for compliance scenarios where someone's status changes.

Do I need a credential to hold every XRPL token? No. Credential requirements are optional and set by the token issuer. Most tokens on XRPL don't use them yet. But adoption is growing as regulated asset issuance on the ledger increases.

What to Do Next

If you're a token holder on XRPL, check whether any tokens you hold or plan to hold have credential requirements. This information should come from the token issuer directly, or you can inspect the ledger objects associated with the issuing address.

If you're a project building on XRPL and considering credential-gated access, the time to think about your credential infrastructure is before you launch, not after.

Rhyzlo gives you the tools to issue and manage XRPL credentials without building everything from scratch. See how it works at rhyzlo.com.