Decentralized Identifiers (DIDs) represent digital identities controlled by their owners instead of being issued and controlled by centralized entities like governments or social media platforms.

They are particularly important for institutional adoption of the XRP Ledger, as they allow for various types of verification. For example, DIDs will be the underlying identifier upon which Know Your Customer (KYC) authentication is issued, but can also be applied to supply chain verification, healthcare data management, and countless more areas.

Recently, three new XRP Ledger specs have been proposed.

They are important for developers to understand as they impact the scope of projects that can be built on the XRPL and help compliantly onboard more institutions.

The new specs include:

1. XLS-70d (On-Chain Credentials): Enabling the issuance, storage, and verification of credentials directly on the XRPL. Before this, credentials were managed off-chain.
2. XLS-80d (Permissioned Domains): Allowing certain areas (“domains”) within the XRPL to have specific access rules or regulatory requirements. For instance, permissioned domains can restrict participation to KYC-verified accounts.
3. XLS-81d (Permissioned DEX): Extends the Permissioned Domains concept to a permissioned decentralized exchange (DEX) on the XRPL, allowing for KYC and Anti-Money Laundering (AML)-compliant trading that helps to onboard more institutions.

Below I’ll provide a brief overview of DIDs before covering each of the three specs in greater depth.

Decentralized Identifiers (DID)

The World Wide Web Consortium (W3C), established in 1994, is a global organization of over 450 members responsible for developing key internet standards and guidelines, including HTML, web security, and web payments.

In July 2022, recognizing the importance of DIDs, the W3C released an official Web standard for DIDs aimed at increasing ownership over one’s data and relationships and increasing privacy and security.

In this, they outlined 4 features for DIDs:

1. Decentralized: Self-sovereign, and the user has complete control over them (unlike credentials issued by governmental agencies or social media platforms).
2. Persistent and Portable: they continue to exist without maintenance and can be used across various platforms and applications.
3. Verifiable: provable through cryptography.
4. Resolvable/Interoperable: metadata can be discovered by any platform that has incorporated W3C’s standards, making the DIDs interoperable.

Developers for the XRPL have since built an identifier format for DIDs that aligns with the W3C standards described above. These identifiers could be owned by any XRPL account holder who can create, manage, and own their DIDs.

These DIDs can represent any subject in a globally recognized manner, such as:

• People
• Organizations
• Devices (iPhone, computer, any smart-device, etc)
• Products
• Locations (any location can be globally recognized)

On the XRPL, DIDs would be beneficial for nearly anything that requires authorization.

This could include verified payments, Automated Market Makers (AMMs) / DEXs, regulated liquidity pools, supply chain distribution, and just about anything else.

However, the infrastructure is still being built out to make it as easy as possible for any institution to easily integrate decentralized identity solutions and interact securely with regulated environments on the XRPL.

This is why the new specs are so important.

1. XLS-70d (On-Chain Credentials)

Right now, it’s extremely challenging for an institution to interact with decentralized finance (DeFi) as it’s entirely pseudonymous with minimal regulations.

If we wish to onboard massive institutional volume on-chain, compliance must be built-in. For example, no institution will operate on-chain if there is the risk of inadvertently dealing with laundered funds or malicious parties.

The XLS-70d specification enables the issuance, storage, and verification of credentials directly on the XRPL.

Previously, credentials were managed off-chain, but XLS-70d bridges this gap by enabling on-chain credential handling while maintaining privacy. This means that KYC verification, accreditations, licenses, and more can be stored and verified directly on-chain. At the same time, once a credential is issued, it can be used across multiple platforms and websites.

For example, I could control a DID that represents my on-chain identity. Once I am KYC’d, I can connect my DID to financial institutions or other on-chain entities that can serve me in a compliant manner. This is also important for decentralized applications (dApps), which must otherwise restrict access to certain jurisdictions (like the U.S.) and may be otherwise worried about what products and services they can offer.

Full details on XLS-70d can be found here: https://github.com/XRPLF/XRPL-Standards/discussions/202

2. XLS-80d: Permissioned Domains

This specification introduces “permissioned domains,” or controlled environments within the XRPL, where specific rules and credential requirements regulate access.

Building on XLS-70d, it provides a framework to create custom domains that restrict access based on verified credentials, enabling more secure and compliant interactions.

A few examples include:

• Government-Issued ID Domain: A domain restricted to users who can present government-issued credentials (e.g., a digital passport or ID). This could be used for government-related applications, such as tax filings or voting.
• KYC-Verified Trading Domain: A domain where users must hold a verified KYC credential to participate, allowing only identity-verified accounts to engage in trading or investment activities. This setup would align with Anti-Money Laundering (AML) and Know Your Customer (KYC) standards for institutional DeFi.
• Accredited Investor Domain: This domain could limit participation to accredited investors for high-risk or private investment opportunities. Users would need to prove accredited investor status with an appropriate credential to interact with offerings like private equity or certain high-value assets.

That being said, virtually any type of permissioned domain can be created, including exclusive membership clubs with customized, on-chain rules that only allow access to users whose DID has verified their membership.

Full details on XLS-80d can be found here: https://github.com/XRPLF/XRPL-Standards/discussions/228

3. XLS-81d: Permissioned DEX

The main aim of XLS-81d is to enable regulated financial institutions to participate in decentralized finance while adhering to AML and KYC requirements.

As DEXs host substantial on-chain volume, providing permissioned environments allows institutions to engage in compliant trading while meeting regulatory requirements.

XLS-81d proposes changes to various on-ledger objects, such as the Offer, DirectoryNode, and Payment transactions. Each permissioned offer will contain a DomainID field that associates it with a regulatory domain, and the offer validity will depend on this domain status and relevant compliance credentials.

The permissioned DEX system can utilize additional compliance tools already present on XRPL, such as:

• Authorized Trustlines: Allows issuers to restrict asset ownership to pre-approved, KYC-verified accounts.
• Freezing: Issuers can halt asset transfers in cases of fraud or regulatory concerns, either individually or globally.
• Clawbacks: Enables issuers to reclaim assets under certain conditions, such as recovering funds from compromised accounts or malicious actors.

I covered these in-depth here.

Some have expressed concern over the extent of censorship these could entail, but ultimately it’s important to remember that regulated companies require these to to be in place to satisfy legal concerns they have, which ultimately allows them to operate on-chain.

To learn more about XLS-81d, visit https://github.com/XRPLF/XRPL-Standards/discussions/229

What’s Next?

The technical specifications have been released and are undergoing review. They are expected to be proposed as amendments to the XRPL in the coming months.

Each amendment must pass a two-week activation period with at least 80% validator support to be fully accepted and active on the ledger. This governance process means that if support dips below 80% during the two-week period, the amendment is temporarily halted until it regains the required consensus level for two consecutive weeks​.

To stay up-to-date, follow RippleX: https://x.com/RippleXDev

To see more of my content, follow me on Twitter: https://x.com/lachlanalextodd