The XRP Ledger (XRPL) activated its “Credentials” amendment on September 4, 2025 at 03:51:21 UTC, bringing a native, standards-aligned identity layer to the base protocol and enabling KYC/AML-aware flows directly on-chain. The upgrade follows the XRPL’s amendment governance model—an 80%+ validator supermajority maintained for two weeks—culminating in an EnableAmendment event that permanently switches the new rules on for all subsequent ledgers.
XRPL Adds Native KYC And AML Controls
At the heart of the change is XLS-0070 (“Credentials”), a specification designed to let issuers attest facts about an XRPL account—such as identity verification or sanctions status—in a way that other participants can rely on without exposing private documents to the chain. As the XRPL documentation puts it, “The Credentials feature is a set of tools for managing authorization and compliance requirements using the XRP Ledger blockchain, while respecting privacy and decentralization.” The design “draws from the W3C Verifiable Credentials standard,” adapting it so that the subject of a credential is an XRPL address rather than a URL.
Ripple’s open-source spec site captures the institutional rationale succinctly: “Credentials provide a set of tools for managing authorization and compliance requirements on the XRP Ledger, while respecting privacy and decentralization”—a framing that makes the feature legible to regulated actors who need attestations without building proprietary allow-lists.
Functionally, the amendment introduces new protocol-level objects and transactions so attestations can be issued, accepted, referenced and revoked on-chain. The XRPL’s Known Amendments registry enumerates the changes: three new transactions—CredentialCreate (issuer provisions a credential), CredentialAccept (subject validates it), and CredentialDelete (revocation/cleanup)—plus a new Credential ledger entry type. It also extends the existing DepositPreauth feature so deposit authorization can be expressed in terms of credential requirements, and adds a CredentialIDs field to several transactions (including Payment, EscrowFinish, PaymentChannelClaim, and AccountDelete) so a sender can present a set of credentials when interacting with a destination that enforces compliance gates.
Crucially, the concept docs emphasize that personal documents never touch the blockchain. In a canonical flow, a business that must restrict interactions to KYC’d accounts names trusted issuers off-chain; the issuer verifies the user privately and then writes only a signed credential to the ledger. “The documents that [the user] sends… are never published or stored on the blockchain,” yet multiple counterparties can rely on the same credential, avoiding redundant verification. That balance—on-chain attestations, off-chain evidence—mirrors the W3C Verifiable Credentials model while keeping attestations portable across the XRPL’s features.
The activation also slots into a broader roadmap aimed at institutional-grade rails. Credentials are a prerequisite and companion for other permissioned constructs under consideration, such as Permissioned Domains and a Permissioned DEX, which expect participants to present valid credentials to access controlled liquidity or domain-scoped markets. The documentation for those proposals explicitly ties enforcement back to Credentials, underscoring that the identity layer is designed to be reusable across product surfaces rather than a one-off toggle.
From an implementation standpoint, the feature has been visible to developers for months: Ripple’s reference server (rippled) releases highlighted Credentials among new amendments, the doc set shipped end-to-end guidance and code samples for testing on Devnet, and explorers tracked validator votes toward the 28/35 threshold. Today’s mainnet enablement flips the feature from “open for voting” to production reality, allowing issuers, exchanges, and fintechs to build credential-gated flows that settle atomically on XRPL.
Technically, the change is conservative but far-reaching. Because CredentialIDs can now ride alongside standard Payment semantics, an institution can—at the protocol layer—only accept deposits when the presented set of credential hashes matches a policy it has configured via DepositPreauth. That enforcement happens without bespoke middleware and is recorded in transaction metadata, improving auditability for regulated entities.
Combined with existing primitives (trust lines, AMM, DEX, escrow), the path is open to programmatic policies like “accept euro-stablecoin from counterparties with an up-to-date KYC credential from issuer X, and route cross-currency through a permissioned market if both sides meet domain requirements.”
At press time, XRP traded at $2.82.
Related Posts
