DOCSEARCHbyAlgolia
Submit Docs

XRP Ledger Standards (XLS)

repository·master·Indexed 42 days ago

https://github.com/xrplf/xrpl-standards

Specifications and protocols designed to ensure interoperability and compatibility across the XRP Ledger ecosystem. This includes Amendment, System, Ecosystem, and Meta XLS categories, covering core protocol changes, RPCs, metadata formats, and the XLS lifecycle process.

Tokens
268.6K
Snippets
406
Records
940
Agent score
53%

What's inside XLS

  1. Overview of XLS-62: Options on XRPL Protocol Chains

    master
    XLS-62 introduces a framework for options trading on the XRP Ledger. It uses a 'pseudo account' approach where each option listing is represented by a pseudo account without an owner (similar to AMM implementations). This allows for the creation, trading, and exercising of options in a lightweight and decentralized manner.

  2. Overview of Permissioned DEXes (XLS-81)

    master

    XLS-81 introduces a permissioned Decentralized Exchange (DEX) system to the XRP Ledger. This allows regulated financial institutions to participate in the DEX while adhering to compliance requirements (like AML/KYC) by operating within specific 'domains'.

    Key components of this standard include:

    • Permissioned DEX: A subset of the DEX that operates under the rules of a specific domain.
    • Open DEX: The standard, un-permissioned DEX with no restrictions.
    • Permissioned Orderbook: An orderbook governed by domain rules.
    • Permissioned Offer/Payment: Also called 'Closed' offers/payments; these can only be filled by other offers/payments that are part of the same specific domain.
    • Open Offer/Payment: Also called 'Unpermissioned' offers/payments; these can trade on the open DEX or potentially in permissioned DEXes, but do not impose restrictions themselves.
    • Valid Domain Offer/Payment: A permissioned offer/payment that satisfies a domain's rules (e.g., the account holds the required KYC credentials).

    This standard builds upon XLS-80 (Permissioned Domains) and requires the featurePermissionedDEX amendment.

  3. Overview of XLS-20 Non-Fungible Token Support

    master

    XLS-20 is a finalized amendment to the XRP Ledger that introduces native support for Non-Fungible Tokens (NFTokens). Unlike standard fungible IOUs used for payments, XLS-20 NFTs are designed to be indivisible, unique, and not used for payments.

    This standard provides primitives for token issuers to manage ownership of digital or physical goods, including operations to enumerate, purchase, sell, and hold tokens. It includes NFT-specific configurations such as transfer fees and burnable/non-burnable properties, utilizing an efficient storage mechanism for large-scale NFT management.

  4. Overview of Confidential Transfers for Multi-Purpose Tokens (XLS-0096)

    master

    XLS-0096 introduces Confidential Transfers for Multi-Purpose Tokens (Confidential MPTs) as an extension to the XLS-33 (Multi-Purpose Token) standard. It enables encrypted balances and transfers using EC-ElGamal encryption and Zero-Knowledge Proofs (ZKPs) while maintaining the core accounting semantics of the XRP Ledger.

    Key Properties

    • Confidentiality: Individual balances and transfer amounts are encrypted and hidden from validators and observers.
    • Public Auditability: The global supply remains auditable via the existing OutstandingAmount ≤ MaximumAmount invariant.
    • Selective Disclosure: Supports a trust-minimized on-chain auditor model via encrypted balance mirroring.
    • Compatibility: Public and confidential balances can coexist. Note that the issuer account itself cannot hold confidential balances; issuers wishing to participate in confidential circulation must use a separate Dedicated Account (or "Confidential Vault").
    • Issuer Control: Preserves existing controls and adds ConfidentialMPTClawback to burn confidential balances.

  5. Overview of XRPL Smart Contracts

    master

    XRPL Smart Contracts provide an L1 native implementation of smart contracts on the XRP Ledger. The design combines the familiar address/function paradigm of the EVM with the human-readable transaction structure of the XRPL.

    Core Concepts:

    • Pseudo-Accounts: Smart contracts live on pseudo-accounts (defined in XLS-0064), which are XRPL accounts that cannot be controlled by any human keyholder. This allows the contract to act as its own entity.
    • Triggering Contracts: Contracts are triggered via a ContractCall transaction, which specifies a function name and parameters.
    • State & Interaction: Contracts can modify their own state via ContractData and interact with the XRPL (including other contracts) by submitting transactions from their pseudo-account.
    • Capabilities: Includes contract-level data storage, per-user data storage, on-chain verified ABIs, and read-only access to the ledger state.

  6. Overview of XLS-0013: Tickets & Ticket Batching

    master

    XLS-0013 introduces Tickets, a protocol amendment for the XRP Ledger designed to solve transaction ordering issues caused by strict sequence number requirements.

    In the standard XRP Ledger model, every account has an incrementing sequence number, and transactions must be applied in strict order. This creates bottlenecks in multisigning scenarios:

    1. Multiple Independent Signers: If two signers create transactions simultaneously using the same current sequence number, one will fail with tefPAST_SEQ when the other is processed.
    2. Multiple Required Signers: A signer cannot prepare a transaction with a future sequence number without waiting for all preceding transactions to be validated, as any intervening transaction would invalidate the sequence.

    Tickets allow an account to create specific identifiers that can be used in place of a sequence number. Transactions using Tickets are not constrained by the standard sequence number ordering, allowing for out-of-order processing.

  7. Overview of On-Chain Credentials (XLS-0070)

    master

    XLS-0070 introduces a system for issuing, storing, and verifying credentials directly on the XRP Ledger. It builds upon the XRPL DID (Digital Identifier) amendment (XLS-40) to allow for secure, privacy-preserving identity management.

    Key capabilities include:

    • Issuance: Trusted entities (Issuers) can create credentials for users (Subjects).
    • Storage: Credentials are stored as ledger objects in both the Subject's and Issuer's owner directories.
    • Verification: Accounts can use credentials to gate interactions, extending the existing Deposit Authorization feature to allowlist accounts based on specific credentials rather than just account IDs.
    • Privacy: Sensitive data (like KYC documents) can be handled off-chain, with only the cryptographic attestation stored on-chain.

  8. Overview of XLS-0099: ElGamal Key Rotation for Confidential MPTs

    master

    XLS-0099 is an amendment to XLS-0096 (Confidential Transfers for Multi-Purpose Tokens) that introduces ElGamal key rotation for the three participant roles: issuer, auditor, and holder.

    It addresses three primary operational risks:

    1. Compromised Keys: Provides a remediation path if an ElGamal key is compromised.
    2. Operational Changes: Allows roles to rotate keys as personnel or systems change.
    3. Key Loss Recovery: Provides a mechanism for holders to recover access to balances if they lose their ElGamal private key, and for auditors to recover regulatory visibility if their keys are lost.

    Key rotation is supported for both voluntary updates and loss-recovery scenarios.

  9. Overview of XLS-0009 Blinded Tags

    master

    XLS-0009 introduces tag blinding, a privacy feature for XRP Ledger source and destination tags. Standard tags (32-bit integers) can allow observers to correlate transactions by treating the { address, tag } pair as a unique identifier for a user.

    Blinded tags mutate the tag so it is meaningful only to the sender and the recipient, appearing random to external observers. This allows hosted wallets (like exchanges) to provide privacy while still allowing the recipient to identify the intended user.

  10. Overview of Single Asset Vault (XLS-0065)

    master

    A Single Asset Vault is an on-chain primitive designed to aggregate assets from multiple depositors and make them available to other on-chain protocols (such as lending markets or yield aggregators).

    Key characteristics:

    • Ownership via Shares: Ownership of the vault's assets is represented by Multi-Purpose Tokens (MPT) issued by the vault's pseudo-account.
    • Decoupling: It separates liquidity provision from specific protocol logic, allowing different protocols to use the same aggregated liquidity.
    • Asset Types: The vault can hold XRP, Fungible Tokens, or Multi-Purpose Tokens.
    • Vault Entry: The specification introduces a new Vault ledger entry containing available assets, shares, total value, and other metadata.

  11. Overview of XLS-0040 Decentralized Identity

    master

    XLS-0040 implements native support for W3C Decentralized Identifiers (DIDs) on the XRP Ledger. It provides a way for users to create, manage, and resolve self-sovereign digital identities that are persistent, globally resolvable, cryptographically verifiable, and decentralized.

    Key components include:

    • A new ledger object: DID
    • New transaction types: DIDSet (for Create/Update) and DIDDelete (for Delete)
    • A specific DID method: did:xrpl

  12. Overview of XLS-78: Subscriptions

    master

    XLS-78 introduces a subscription mechanism to the XRP Ledger (XRPL) that enables automated recurring payments, similar to direct debits. This amendment allows account owners to pre-authorize payments with specific parameters, removing the need for the sender to manually sign every individual transaction in a series.

    Supported assets for subscriptions include:

    • XRP
    • Trustline-based tokens (IOUs)
    • Multi-Purpose Tokens (MPTs)