XRP Ledger Standards

https://github.com/xrplf/xrpl-standards
Admin
XRP Ledger Standards (XLSs) define specifications for the XRP Ledger ecosystem to ensure...
Tokens:112,990
Snippets:381
Trust Score:9
License:MIT
Update:1 year ago
Show doc for...
Tokens:
Raw
### CTID Encoding Example - Hooks Testnet v3 (JavaScript)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0037-concise-transaction-identifier-ctid/QUICKSTART.md

This JavaScript example shows how to encode a CTID for a transaction on the XRPL Hooks Testnet v3. It highlights the different ledger sequence, transaction index, and network ID (21338) values specific to this testnet environment.

```javascript
encodeCTID(
  428986, // ledger sequence number the txn appeared in
  0, // `TransactionIndex` as per metadata
  21338,
); // Network ID of hooks v3 is 21338
("C0068BBA0000535A");
```

--------------------------------

### XRPL option_book_offers RPC Example Usage

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0062-options/README.md

A concrete example of an `option_book_offers` RPC request and its corresponding response, showcasing current ledger querying with a limit of 5 offers.

```json
{
  "method": "option_book_offers",
  "params": [
    {
      "ledger_index": "current",
      "option_id": "rOPTIONaccountAddress",
      "limit": 5
    }
  ]
}

{
  "result": {
    "ledger_hash": "ABCD1234...",
    "ledger_index": 6000000,
    "option": {
      "Account": "rOPTIONaccountAddress",
      "StrikePrice": {
        "currency": "USD",
        "issuer": "rUSDissuerAddress",
        "value": "20"
      },
      "Asset": { "currency": "GME", "issuer": "rGMEissuerAddress" },
      "Expiration": 743171558,
      "Type": "Call"
    },
    "offers": [
      {
        "OptionOffer": {
          "LedgerEntryType": "OptionOffer"
        },
        "quality": "500000000",
        "owner_funds": "1000000"
      }
    ]
  }
}
```

--------------------------------

### NFTokenMint Transaction Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0020-non-fungible-tokens/README.md

An example of the NFTokenMint transaction structure, detailing the required fields and optional Memo field.

```APIDOC
## POST /api/v1/transactions/NFTokenMint

### Description
Mints a new Non-Fungible Token (NFT).

### Method
POST

### Endpoint
/api/v1/transactions/NFTokenMint

### Parameters
#### Path Parameters
None

#### Query Parameters
None

#### Request Body
- **TransactionType** (string) - Required - Must be "NFTokenMint".
- **Account** (string) - Required - The XRP Ledger account submitting the transaction.
- **Issuer** (string) - Required - The account that is issuing the NFT.
- **TransferFee** (integer) - Optional - The fee for transferring the NFT, in drops.
- **Flags** (integer) - Optional - Flags related to the NFTokenMint transaction.
- **Fee** (integer) - Required - The transaction fee in XRP drops.
- **URI** (string) - Optional - A URI pointing to the NFT's metadata.
- **Memos** (array) - Optional - An array of memo objects to include with the transaction.
  - **Memo** (object) - Required if Memos is present.
    - **MemoType** (string) - Optional - The type of the memo.
    - **MemoData** (string) - Optional - The data of the memo.

### Request Example
```json
{
  "TransactionType": "NFTokenMint",
  "Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Issuer": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
  "TransferFee": 314,
  "Flags": 2147483659,
  "Fee": 10,
  "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi",
  "Memos": [
    {
      "Memo": {
        "MemoType": "687474703A2F2F6578616D706C652E636F6D2F6D656D6F2F67656E65726963",
        "MemoData": "72656E74"
      }
    }
  ]
}
```

### Response
#### Success Response (200)
- **status** (string) - Indicates the success of the operation.
- **tx_hash** (string) - The hash of the submitted transaction.

#### Response Example
```json
{
  "status": "success",
  "tx_hash": "some_transaction_hash"
}
```
```

--------------------------------

### Run rippled with specific flags for bootstrapping (Linux/macOS)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0018-bootstrapping/README.md

This command starts the rippled process with flags to enable validation, set a quorum of 1, and enable load balancing. This is typically used on the 'leader' node during a cold start.

```bash
./rippled --valid --quorum 1 --load

```

--------------------------------

### XRPL KYC Authorization Flow Example (JavaScript/JSON)

Source: https://context7.com/xrplf/xrpl-standards/llms.txt

A multi-step example demonstrating a complete KYC authorization flow using XRPL transactions. It covers enabling deposit authorization, authorizing credentials, creating and accepting a credential, and finally sending a payment.

```javascript
// Step 1: Verity enables Deposit Authorization
{
  "TransactionType": "AccountSet",
  "Account": "rVerityBusiness123OnlyKYCdUsers12",
  "SetFlag": 9,  // asfDepositAuth
  "Fee": "10"
}

// Step 2: Verity authorizes Isabel's KYC credentials
{
  "TransactionType": "DepositPreauth",
  "Account": "rVerityBusiness123OnlyKYCdUsers12",
  "AuthorizeCredentials": [{
    "Issuer": "rIsabelIssuer5KYC9Verification12345",
    "CredentialType": "4B59433A42617369630A"
  }],
  "Fee": "10"
}

// Step 3: Isabel creates credential for Alice (off-chain KYC completed)
{
  "TransactionType": "CredentialCreate",
  "Account": "rIsabelIssuer5KYC9Verification12345",
  "Subject": "rAliceUser789WantsToGetVerified12345",
  "CredentialType": "4B59433A42617369630A",
  "Fee": "10"
}

// Step 4: Alice accepts the credential
{
  "TransactionType": "CredentialAccept",
  "Account": "rAliceUser789WantsToGetVerified12345",
  "Issuer": "rIsabelIssuer5KYC9Verification12345",
  "CredentialType": "4B59433A42617369630A",
  "Fee": "10"
}

// Step 5: Alice can now send payments to Verity
{
  "TransactionType": "Payment",
  "Account": "rAliceUser789WantsToGetVerified12345",
  "Destination": "rVerityBusiness123OnlyKYCdUsers12",
  "Amount": "1000000",
  "Fee": "10"
}
```

--------------------------------

### Run rippled for follower nodes during bootstrapping (Linux/macOS)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0018-bootstrapping/README.md

This command starts the rippled process with flags to enable network participation and set a quorum of 1. It's used on 'follower' nodes during a cold start.

```bash
./rippled --net --quorum 1

```

--------------------------------

### XRPL Ledger Entry Documentation Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/xls-template.md

This is an example structure for documenting new ledger entries within an XRPL Standard. It includes sections for the entry name, high-level overview, fields table, flags, and error scenarios.

```markdown
#### **`<entry name>`** ledger entry

<High level overview, explaining the object>

##### Fields

<Any explanatory text about the fields overall>

---

| Field Name        | Required?        |  JSON Type      | Internal Type     |
|-------------------|:----------------:|:---------------:|:-----------------:|
| `<field name>` | :heavy_check_mark: | `<string, number, object, array, boolean>` | `<UINT128, UINT160, UINT256, ...>` |

<Any explanatory text about specific fields. For example, if an object must contain exactly one of three fields, note that here.>

###### Flags

> | Flag Name            | Flag Value  | Description |
>|:---------------------:|:-----------:|:------------|
>| `lsf<flag name>` | `0x0001`| <flag description> |

<Any explanatory text about specific flags>
```

--------------------------------

### CTID Encoding Example - Mainnet (JavaScript)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0037-concise-transaction-identifier-ctid/QUICKSTART.md

This JavaScript example demonstrates how to use the `encodeCTID` function to generate a CTID for a transaction on the XRPL Mainnet. It shows the specific values for ledger sequence, transaction index, and the Mainnet network ID (0).

```javascript
encodeCTID(
  77727448, // ledger sequence number the txn appeared in
  54, // `TransactionIndex` as per metadata
  0,
); // Network ID of mainnet is 0
("C4A206D800360000");
```

--------------------------------

### Clawback Transaction Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0033-multi-purpose-tokens/README.md

An example of the Clawback transaction structure for MPTs.

```APIDOC
## POST /transactions/submit (Clawback Transaction Example)

### Description
This is an example of the JSON payload for a Clawback transaction targeting an MPT.

### Method
POST

### Endpoint
/transactions/submit

### Request Body
- **TransactionType** (string) - Required - Must be 'Clawback'.
- **Account** (string) - Required - The account initiating the clawback.
- **Amount** (object) - Required - The amount to be clawed back.
  - **value** (number) - Required - The numeric value of the amount.
  - **mpt_issuance_id** (string) - Required - The ID of the MPT issuance.
- **MPTokenHolder** (string) - Required - The account holding the MPT to be clawed back.

### Request Example
```json
{
  "TransactionType": "Clawback",
  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
  "Amount": {
    "value": 10,
    "mpt_issuance_id": "0000012FFD9EE5DA93AC614B4DB94D7E0FCE415CA51BED47"
  },
  "MPTokenHolder": "rajgkBmMxmz161r8bWYH7CQAFZP5bA9oSG"
}
```

### Response
#### Success Response (200)
(Standard transaction submission success response)

#### Response Example
(Standard transaction submission success response example)
```

--------------------------------

### Start New Standard Proposal (Bash)

Source: https://context7.com/xrplf/xrpl-standards/llms.txt

This bash script outlines the initial steps for starting a new XRPL Standard proposal on GitHub. It involves navigating to GitHub Discussions, creating a new discussion with a specific title format, gathering feedback, and then creating a new directory for the specification using a template.

```bash
# 1. Navigate to GitHub Discussions
# https://github.com/XRPLF/XRPL-Standards/discussions

# 2. Create new discussion with title format:
# "XLS-{next-number}d {Descriptive Title}"
# Example: "XLS-0099d Cross-Chain Token Bridge"

# 3. Use discussion to gather feedback and refine concept

# 4. When ready, close discussion and create PR with:
mkdir XLS-0099d-cross-chain-token-bridge
cd XLS-0099d-cross-chain-token-bridge

# 5. Copy template and fill in specification
cp ../xls-template.md README.md

# 6. Submit PR referencing discussion
git add XLS-0099d-cross-chain-token-bridge/
git commit -m "Add XLS-99 Cross-Chain Token Bridge draft"
git push origin xls-99-draft
```

--------------------------------

### Example OptionPairCreate Transaction

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0062-options/README.md

An example JSON object representing an OptionPairCreate transaction. This transaction is used to create a new option listing on the XRPL, defining the assets involved in the option pair.

```json
{
  "TransactionType": "OptionPairCreate",
  "Account": "rAccountCreatingTheListing",
  "Asset": {
    "currency": "GME",
    "issuer": "rGMEissuerAddress"
  },
  "Asset2": {
    "currency": "USD",
    "issuer": "rUSDissuerAddress"
  }
}
```

--------------------------------

### Example URIToken JSON Document (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0035-uritoken/README.md

A sample JSON document adhering to the defined URIToken schema. This example includes basic details such as the content URL, token title, categories, and publisher name. It demonstrates how to structure metadata for a URIToken.

```json
{
  "content": {
    "url": "https://someuri"
  },
  "details": {
    "title": "Some URIToken",
    "categories": ["0000"],
    "publisher": {
      "name": "XRPL-Labs"
    }
  }
}
```

--------------------------------

### Example OptionCreate Transaction (Buy Call)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0062-options/README.md

An example JSON object for an OptionCreate transaction. This transaction is used to create a new option offer, specifically a 'Buy Call' in this instance, specifying the option details, premium, and quantity.

```json
{
  "TransactionType": "OptionCreate",
  "Account": "rBuyerAccount",
  "OptionID": "rOPTIONaccountAddress",
  "Premium": {
    "currency": "USD",
    "issuer": "rUSDissuer",
    "value": "0.5"
  },
  "Quantity": 100,
  "Flags": 0 // Buy (tfSell unset), Limit (tfMarket unset)
}
```

--------------------------------

### Example: Minimal art.v0 NFT Metadata (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0024-nft-metadata/README.md

This example demonstrates a valid 'art.v0' NFT metadata object that includes only the strictly required properties: schema, nftType, name, description, and image. This serves as a basic structure for art NFTs.

```json
{
    "schema":"ipfs://QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU",
    "nftType":"art.v0",
    "name":"ART NFT #0",
    "description":"An ART NFT with minimum properties!",
    "image":"ipfs://QmcCST9U9qwJwuBxZyTJ6ePvdJHrub7yPkAcNeCKZQ3trn"
}
```

--------------------------------

### XRPL FirewallSet Transaction - Creation Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0086-firewall/README.md

Example JSON payload for creating a new FirewallSet transaction on the XRPL. This includes transaction type, account, counterparty, backup, optional max fee and destination tag, fee, and sequence number.

```json
{
  "TransactionType": "FirewallSet",
  "Account": "rU9XRmcZiJXp5J1LDJq8iZFujU6Wwn9cV9",
  "Counterparty": "raKG2uCwu71ohFGo1BJr7xqeGfWfYWZeh3",
  "Backup": "rBackupAccount123456789",
  "MaxFee": "100000",
  "DestinationTag": 12345,
  "Fee": "36",
  "Sequence": 10
}
```

--------------------------------

### Example: Complete art.v0 NFT Metadata (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0024-nft-metadata/README.md

This example showcases a comprehensive 'art.v0' NFT metadata object, including all supported properties. It features optional fields like animation, video, audio, file, collection details (name and family), and custom attributes with trait types, values, and descriptions.

```json
{
    "schema":"ipfs://QmNpi8rcXEkohca8iXu7zysKKSJYqCvBJn3xJwga8jXqWU",
    "nftType":"art.v0",
    "name":"ART NFT #0",
    "description":"An Art NFT with all properties supported by the art.v0 schema.",
    "image":"ipfs://QmcCST9U9qwJwuBxZyTJ6ePvdJHrub7yPkAcNeCKZQ3trn",
    "animation":"ipfs://QmfQGVwoxpqnAvDxFxW7bPsesivFas7FFjBcW9tVU5ymZQ",
    "video":"ipfs://QmWrLXyMFCB5XajAg9xRDkM9YtCvgMN7NqjmsgkoaV4k5k",
    "audio":"ipfs://QmQxMmXRrFZ8oMNtQjhaSnqosNTQFFzacT8F6kCoA4iSUd",
    "file":"ipfs://QmXVgDaHkXbyhnim8P9KmKG2khqLwnfT3fbZJRPBeVJDWY",
    "collection":
        {
            "name":"XLS-24D Examples",
            "family":"X-Tokenize Example NFTS"
        },
        "attributes":[
        {
            "trait_type":"Background",
            "description":"A dark background.",
            "value":"Black"
        },
        {
            "trait_type":"Text",
            "description":"A comforting message.",
            "value":"Hello XLS-24D"
        }
    ]
}
```

--------------------------------

### URITokenBuy Transaction Example (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0035-uritoken/README.md

An example of a URITokenBuy transaction in JSON format. This transaction is used to purchase a URIToken that has an active sell offer. It requires the URITokenID and the purchase Amount, which must match the currency and be at least the offered amount. No pathing is allowed, and the buyer must have sufficient funds.

```json
{
  "Account": "rpiLN1C94hGKGpLUbhsadVHzdSXtB2Ldra",
  "Amount": "100001",
  "TransactionType": "URITokenBuy",
  "URITokenID": "0FAC3CD45FCB800BB9CCCF907775E7D4FB167847D8999FF05CE7456D6C3A70FA"
}
```

--------------------------------

### TaggedAddresses Metadata Example (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0005-tagged-addresses/README.md

This JSON snippet represents metadata that an XRPL server could add to a transaction's response. It helps map packed addresses to their expanded forms, including the resolved address and tag, aiding third-party tools in understanding user deposits.

```json
{
    "TaggedAddresses": [
        {
            "XVLhHMPHU98es4dbozjVtdWzVrDjtV8zpDURx7DzBCkrQE7": {
                "Address": "rGWrZyQqhTp9Xu7G5Pkayo7bXjH4k4QYpf",
                "Tag": 2
            }
        }
    ]
}
```

--------------------------------

### Running the Witness Server

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0038-cross-chain-bridge/README.md

Instructions on how to build and run the XRPL Witness Server.

```APIDOC
## Running a Witness Server

### Description
Instructions on how to build and run the XRPL Witness Server.

### Command
```bash
./xbridge_witnessd --conf witness.json
```

### Additional Information
Further details are available in the README of the [repo](https://github.com/seelabs/xbridge_witness).
```

--------------------------------

### XRPL SubscriptionSet Creation Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0078-subscriptions/README.md

This JSON object represents a SubscriptionSet transaction used to create a new recurring payment subscription. It includes details such as the account, destination, amount, currency, issuer, frequency, start time, and expiration time.

```json
{
  "TransactionType": "SubscriptionSet",
  "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
  "Destination": "rLdCa1mLK5R5Am25ArfXFmqgNwjZgnfy91",
  "Data": "DEADBEEF",
  "Amount": {
    "currency": "USD",
    "value": "100",
    "issuer": "rUSDIssuerAddress"
  },
  "Frequency": 2592000,
  "StartTime": 711232800,
  "Expiration": 721600800,
  "Fee": "12",
  "Sequence": 42
}
```

--------------------------------

### List and View XRP Ledger Standards

Source: https://context7.com/xrplf/xrpl-standards/llms.txt

Commands to list all available standards directories, view the contents of a specific standard's README file, and search for standards by keywords. These bash commands are essential for navigating and understanding the structure of the XRPL-Standards repository.

```bash
# List all available standards
ls -d XLS-*/

# View a specific standard
cat XLS-0020-non-fungible-tokens/README.md

# Search for standards by topic
ls -d XLS-*credentials* XLS-*token*
```

--------------------------------

### XRPL Payment Failure (No Deposit Authorization Setup) in TypeScript

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0070-credentials/README.md

This TypeScript example shows a 'Payment' transaction that will fail. Alice attempts to send funds to Bob, including a 'CredentialIDs' field. However, Bob has not configured his account with 'DepositPreauth' settings to accept payments authorized by this specific credential. Consequently, the transaction is rejected because Bob's account is not set up to receive payments from Alice under these conditions.

```typescript
{
    TransactionType: "Payment",
    Account: "rALICE......",
    Destination: "rBOB......",
    Amount: "10000000",
    CredentialIDs: ["DD40031C6C21164E7673...17D467CEEE9"]
}
```

--------------------------------

### channel_verify Method

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0034-paychan-escrow-for-tokens/README.md

Documentation for the channel_verify method, detailing its request parameters and expected formats.

```APIDOC
## channel_verify Method

### Description
This method is used to verify a channel, including details about the authorized amount.

### Method
POST

### Endpoint
/xrplf/xrpl-standards

### Parameters
#### Request Body
- **Amount** (object or string) - Required - The amount the provided signature authorizes.

### Request Example
```json
{
  "method": "channel_verify",
  "params": [
    {
      "Amount": "1000 XRP"
    }
  ]
}
```

### Response
#### Success Response (200)
- **result** (object) - The result of the channel verification.
  - **status** (string) - The status of the verification (e.g., "success").

#### Response Example
```json
{
  "result": {
    "status": "success"
  }
}
```
```

--------------------------------

### XRPL NFTokenBurn Transaction Example (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0020-non-fungible-tokens/README.md

This JSON object demonstrates an example of an NFTokenBurn transaction. It specifies the TransactionType, the Account burning the token, the Fee, and the NFTokenID of the token to be removed. This transaction effectively removes an NFToken from the ledger.

```json
{
      "TransactionType": "NFTokenBurn",
      "Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
      "Fee": 10,
      "NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65"
}
```

--------------------------------

### Book Offers API Documentation

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0081-permissioned-dex/README.md

Documentation for the book_offers endpoint, including its request parameters and response fields.

```APIDOC
## GET /book_offers

### Description
Retrieves a list of offers for a given currency pair. This endpoint supports filtering by specific domains and includes parameters for pagination and ledger selection.

### Method
GET

### Endpoint
/book_offers

### Parameters
#### Query Parameters
- **taker_gets** (object) - Required - The asset the account taking the Offer would receive, as a currency without an amount.
- **taker_pays** (object) - Required - The asset the account taking the Offer would pay, as a currency without an amount.
- **ledger_hash** (string) - Optional - A 20-byte hex string for the ledger version to use.
- **ledger_index** (number or string) - Optional - The ledger index of the ledger to use, or a shortcut string to choose a ledger automatically.
- **limit** (number) - Optional - The maximum number of Offers to return. The response may include fewer results.
- **taker** (string) - Optional - The address of an account to use as a perspective. The response includes this account's offers even if they are unfunded.
- **domain** (string) - Optional - The object ID of a `PermissionedDomain` object. If this field is provided, the response will include only valid domain offers associated with that specific domain. If omitted, the response will include only hybrid and open offers for the trading pair, excluding all domain-specific offers.

### Response
#### Success Response (200)
- **ledger_current_index** (number or string) - The ledger index of the current in-progress ledger version, which was used to retrieve this information.
- **ledger_index** (number or string) - The ledger index of the ledger version that was used when retrieving this data, as requested.
- **ledger_hash** (string) - The identifying hash of the ledger version that was used when retrieving this data, as requested.
- **offers** (array) - Array of offer objects, each of which has the fields of an Offer object.

#### Response Example
{
  "ledger_current_index": 37753034,
  "ledger_index": 37753033,
  "ledger_hash": "ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890",
  "offers": [
    {
      "account": "rf1BiGBuGK9Pmm9AW4kztK8d2G6P8W3Qc",
      "buy_pays": {"currency": "USD", "value": "10"},
      "buy_gets": {"currency": "XRP", "value": "100"},
      "sell_pays": {"currency": "XRP", "value": "100"},
      "sell_gets": {"currency": "USD", "value": "10"},
      "ledger_index": 37753033,
      "hash": "OFFERHASH1",
      "flags": 0
    }
  ]
}
```

--------------------------------

### NFTokenPage JSON Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0020-non-fungible-tokens/README.md

An example JSON object illustrating the structure of an NFTokenPage, including its ledger entry type, references to previous pages and transactions, and a collection of NFToken objects with their IDs and URIs. This structure is fundamental for organizing and retrieving NFTs.

```json
{
    "LedgerEntryType": "NFTokenPage",
    "PreviousTokenPage": "598EDFD7CF73460FB8C695d6a9397E907378C8A841F7204C793DCBEF5406",
    "PreviousTokenNext": "598EDFD7CF73460FB8C695d6a9397E9073781BA3B78198904F659AAA252A",
    "PreviousTxnID": "95C8761B22894E328646F7A70035E9DFBECC90EDD83E43B7B973F626D21A0822",
    "PreviousTxnLgrSeq": 42891441,
    "Tokens":
        {
            {
                "NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65",
                "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"
            },
            /* potentially more objects */
       }
}
```

--------------------------------

### Best Practices

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0038-cross-chain-bridge/README.md

Recommended security practices for running a witness server in a production environment.

```APIDOC
## Best Practices

### Description
In a production environment, it is recommended to use different cryptographic keys for:
1. Signing attestations.
2. Signing locking chain transactions.
3. Signing issuing chain transactions.

This practice enhances security and helps mitigate risks associated with transaction replay attacks.
```

--------------------------------

### PriceOracle Object JSON Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0047-PriceOracles/README.md

Provides an example JSON structure for a PriceOracle ledger entry.

```APIDOC
## PriceOracle Object JSON Example

```json
{
    "LedgerEntryType": "PriceOracle",
    "Owner": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
    "Provider": "70726F7669646572",
    "AssetClass": "63757272656E6379",
    "PriceDataSeries": [
      {
        "PriceData": {
          "BaseAsset": "XRP",
          "QuoteAsset": "USD",
          "AssetPrice": 74,
          "Scale": 2
        }
      }
    ],
    "LastUpdateTime": 743609414,
    "PreviousTxnID": "C53ECF838647FA5A4C780377025FEC7999AB4182590510CA461444B207AB74A9",
    "PreviousTxnLgrSeq": 56865244
}
```
```

--------------------------------

### XRPL NFTokenMint Transaction Example (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0020-non-fungible-tokens/README.md

This JSON object represents an example of an NFTokenMint transaction. It includes essential fields such as TransactionType, Account, Issuer, TransferFee, Flags, Fee, URI, and Memos. The transaction is used to mint a new Non-Fungible Token on the XRP Ledger.

```json
{
  "TransactionType": "NFTokenMint",
  "Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
  "Issuer": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
  "TransferFee": 314,
  "Flags": 2147483659,
  "Fee": 10,
  "URI": "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi",
  "Memos": [
        {
            "Memo": {
                "MemoType": "687474703A2F2F6578616D706C652E636F6D2F6D656D6F2F67656E65726963",
                "MemoData": "72656E74"
            }
        }
    ]
}
```

--------------------------------

### MPTokenIssuanceCreate Transaction Example (JavaScript)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0033-multi-purpose-tokens/README.md

This is an example of an MPTokenIssuanceCreate transaction in JavaScript format. It demonstrates the required and optional fields, including TransactionType, Account, AssetScale, MaximumAmount, Flags, MPTokenMetadata, and Fee. The example illustrates how to set specific flags and metadata for token issuance.

```javascript
{
  "TransactionType": "MPTokenIssuanceCreate",
  "Account": "rajgkBmMxmz161r8bWYH7CQAFZP5bA9oSG",
  "AssetScale": "2", // <-- Divisible into 100 units / 10^2
  "MaximumAmount": "100000000", //  <-- 100,000,000
  "Flags": 66, // <-- tfMPTCanLock and tfMPTCanClawback
  "MPTokenMetadata": "464F4F", // <-- "FOO" (HEX)
  "Fee": 10
}
```

--------------------------------

### XRPL NFToken URI Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0032-tx-request-uri/README.md

An example of an 'nftoken' type URI for XRPL, which includes the NFT's unique identifier.

```uri
xrpl:nftoken?id=000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65
```

--------------------------------

### JSON-RPC API Versioning Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0022-api-versioning/README.md

Example of a JSON-RPC request payload demonstrating the 'api_version' field. Note that 'api_version' is not a top-level field in this interface.

```json
{
  "method": "...",
  "params": [
    {
      "api_version": 1,
      "...": "..."
    }
  ]
}
```

--------------------------------

### Server Specs

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0038-cross-chain-bridge/README.md

Information regarding the recommended server specifications for running a witness server.

```APIDOC
## Server Specs

### Description
The witness server is generally lightweight. While specific high-end requirements haven't been tested, standard server resources should suffice.
```

--------------------------------

### WebSocket API Versioning Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0022-api-versioning/README.md

Example of a WebSocket request payload showing the 'api_version' field at the top level, adhering to the WebSocket request format.

```json
{
  "api_version": 1,
  "id": 4,
  "command": "...",
  "...": "..."
}
```

--------------------------------

### W3C Verifiable Credential Compliance

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0070-credentials/README.md

Explains how XRPL integrates with the W3C Verifiable Credential (VC) specification, detailing the verification flow and recommended practices for DID object usage.

```APIDOC
## Compliance with W3C Spec

### Description
This section outlines XRPL's compliance with the W3C Verifiable Credential (VC) specification, emphasizing interoperability and detailing the primary verification flow involving DID resolution and VC access. It also mentions an optional enhancement for pointing to VCs within the `Credential` object's `URI` field.

### Verification Flow

1.  **DID Resolution:** Verifiers access the DID document from the DID ID (e.g., `did:xrpl:r....`). This document is stored in the account's DID object.
2.  **VC Access:** The DID document provides a link to the relevant Verifiable Credentials.
3.  **VC Verification:** Based on access permissions, verifiers can view and verify the retrieved VCs.

### Optional Enhancement

- Within the `Credential` object, the `URI` field can optionally point to the VC. This is not mandatory, as the core verification process using DID resolution remains the primary method.

### Recommendation

It is recommended that credential holders also possess a DID object to enhance compliance with the W3C VC spec.

### Issuer Note

The issuer of the on-chain `Credential` does not need to match the issuer of the VC. The on-chain object can serve as an on-chain attestation from the issuer for the VC.
```

--------------------------------

### TOML Validator Configuration Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0050-validator-toml-infra-details/README.md

Demonstrates the recommended TOML format for validator configuration, including essential properties like 'server_country', 'network_asn', 'server_location', and 'server_cloud'. This helps in understanding the necessary metadata for validator distribution.

```toml
[[VALIDATORS]]
...
server_country = "??"
network_asn = 12345
server_location = "US-West-1"
server_cloud = true
```

--------------------------------

### XRPL Transaction URI Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0032-tx-request-uri/README.md

Illustrates an XRPL URI for a transaction, identified by its unique hash. This example shows how to directly link to or reference a specific transaction.

```uri
xrpl:tx?hash=73734B611DDA23D3F5F62E20A173B78AB8406AC5015094DA53F53D39B9EDB06C
```

--------------------------------

### MPTokenIssuanceSet Transaction JSON Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0033-multi-purpose-tokens/README.md

An example JSON structure for the MPTokenIssuanceSet transaction. This transaction can be used to lock or unlock MPT balances for a specific issuance.

```json
{
  "TransactionType": "MPTokenIssuanceSet",
  "Fee": 10,
  "MPTokenIssuanceID": "000004C463C52827307480341125DA0577DEFC38405B0E3E",
  "Flags": 1
}
```

--------------------------------

### SubscriptionClaim Transaction JSON Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0078-subscriptions/README.md

An example of a SubscriptionClaim transaction in JSON format. This transaction type is used to claim an amount from a subscription. Key fields include TransactionType, Account, SubscriptionID, and Amount.

```json
{
  "TransactionType": "SubscriptionClaim",
  "Account": "rLdCa1mLK5R5Am25ArfXFmqgNwjZgnfy91",
  "SubscriptionID": "E8A6F9B99B041DF5C932DF8DA29B2A84B42D4D4F0F4A08931D76D62F42E1F1B9",
  "Amount": "50000000",
  "Fee": "12",
  "Sequence": 100
}
```

--------------------------------

### Example OptionOffer Object Structure

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0062-options/README.md

This JSON object represents a sample OptionOffer ledger entry. It includes fields for the offer details, owner, assets, quantity, and optionally sealed options with counterparties. The structure defines the parameters for an option contract on the XRPL.

```json
{
  "LedgerEntryType": "OptionOffer",
  "Owner": "rU9XRmcZiJXp5J1LDJq8iZFujU6Wwn9cV9",
  "OwnerNode": "0000000000000000",
  "OptionID": "D79DE793C6934943D5389CB4E5392A05A8E00881202F05FE41ADC2AE83B24E91",
  "Premium": {
    "currency": "USD",
    "issuer": "rUSDissuer",
    "value": "0.5"
  },
  "Quantity": 100,
  "OpenInterest": 50,
  "Amount": {
    "currency": "GME",
    "issuer": "rGMEissuerAddress",
    "value": "100"
  },
  "BookDirectory": "00B15D0B5E...",
  "BookNode": "0000000000000000",
  "SealedOptions": [
    {
      "Owner": "rBuyerAccountID",
      "OptionOfferID": "E5F6AEBCC10B8C2A9C3B2A1C4A6EEBDBF5D48D6749F3A5B07B9FCDABB3F70279",
      "Quantity": 50
    }
  ],
  "PreviousTxnID": "D79DE793C6934943D5389CB4E5392A05A8E00881202F05FE41ADC2AE83B24E91",
  "PreviousTxnLgrSeq": 54322
}
```

--------------------------------

### XRPL Simulate Method Request Example (JSON)

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0069-simulate/README.md

This JSON object demonstrates a typical request to the XRPL 'simulate' method. It includes a transaction of type 'Payment' with specified sender, receiver, and amount details. The request is intended for simulating transaction effects without actual submission.

```json
{
  "id": 2,
  "command": "simulate",
  "tx_json" : {
      "TransactionType" : "Payment",
      "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
      "Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
      "Amount" : {
         "currency" : "USD",
         "value" : "1",
         "issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
      }
   }
}
```

--------------------------------

### MPTokenIssuanceDestroy Transaction JSON Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0033-multi-purpose-tokens/README.md

An example JSON structure for the MPTokenIssuanceDestroy transaction. This transaction is used to remove an MPTokenIssuance object from the ledger, effectively destroying the token issuance.

```json
{
  "TransactionType": "MPTokenIssuanceDestroy",
  "Fee": 10,
  "MPTokenIssuanceID": "000004C463C52827307480341125DA0577DEFC38405B0E3E"
}
```

--------------------------------

### Example OracleSet Transaction JSON

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0047-PriceOracles/README.md

Provides an example of the OracleSet transaction JSON, used for creating or updating a PriceOracle instance on the XRPL. It includes account details, oracle identifiers, and price data.

```json
{
    "TransactionType": "OracleSet",
    "Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
    "OracleDocumentID": 34,
    "Provider": "70726f7669646572",
    "LastUpdateTime": 743609014,
    "AssetClass": "63757272656e6379",
    "PriceDataSeries": [
      {
        "PriceData": {
          "BaseAsset": "XRP",
          "QuoteAsset": "USD",
          "AssetPrice": 740,
          "Scale": 3
        }
      }
    ]
}
```

--------------------------------

### XRPL Ledger URI Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0032-tx-request-uri/README.md

Provides an example of an XRPL URI for a ledger, using the ledger sequence number as an identifier. This shows how to reference specific ledger states using a URI.

```uri
xrpl:ledger?seq=7295400
```

--------------------------------

### Path Find Create Request Fields

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0081-permissioned-dex/README.md

Details the request fields accepted by the `path_find create` subcommand, including standard and proposed additions.

```APIDOC
## Path Find Create Request Fields

This section details the fields accepted by the `path_find create` subcommand.

### Method
POST

### Endpoint
/path_find/create

### Parameters
#### Request Body
- **subcommand** (string) - Required - Use `"create"` to send the create sub-command.
- **source_account** (string) - Required - The address of the account to find a path from.
- **destination_account** (string) - Required - The address of the account to find a path to.
- **destination_amount** (string or object) - Required - The currency amount that the destination account would receive.
- **send_max** (string or object) - Optional - The currency amount that would be spent in the transaction.
- **paths** (array) - Optional - Array of arrays of objects, representing payment paths to check.
- **domain** (string) - Optional - The object ID of a `PermissionedDomain` object. If included, only valid paths for this domain will be returned.

### Request Example
```json
{
  "command": "path_find",
  "subcommand": "create",
  "source_account": "some_source_account_address",
  "destination_account": "some_destination_account_address",
  "destination_amount": "1000/USD",
  "send_max": "1100/USD"
}
```

### Response
#### Success Response (200)
- **alternatives** (array) - An array of alternative paths found.
- **destination_account** (string) - The destination account address.
- **destination_amount** (object) - The amount the destination account will receive.
- **full_reply** (boolean) - Indicates if a full reply was provided.
- **id** (string) - The ID of the request.
- **optimized_path** (array) - The optimized path found.
- **source_account** (string) - The source account address.
- **validation_public_key** (string) - The public key used for validation.
```

--------------------------------

### XRPL Account URI Example

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0032-tx-request-uri/README.md

Demonstrates the format for an XRPL URI representing an account, including the account address and an optional tag. This example illustrates how to specify account-related information in a URI.

```uri
xrpl:account?address=rpfBYsmNBB7Y6z7qHS8g26KE3y3hHaTxkq&tag=000001
```

--------------------------------

### Install xls-32d Library using npm or yarn

Source: https://github.com/xrplf/xrpl-standards/blob/master/XLS-0032-tx-request-uri/README.md

Instructions for installing the 'xls-32d' library, which facilitates XRPL URI encoding and decoding, using either npm or yarn package managers.

```bash
npm install xls-32d@latest
```

```bash
yarn add xls-32d@latest
```
Tokens:
Raw