fix: fix email and Github username formatting (XRPLF#342)

Author: mvadari

XLS-0006-visual-account-icons/README.md

@@ -2,7 +2,7 @@
   xls: 6
   title: Standard for Visual Account Icons
   description: A standard for visually distinguishing XRPL accounts by generating unique icons for each account, regardless of address format.
-  author: Richard Holland (RichardAH)
+  author: Richard Holland (@RichardAH)
   discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/24
   status: Final
   category: Community

XLS-0022-api-versioning/README.md

@@ -2,7 +2,7 @@
   xls: 22
   title: rippled API Versioning
   description: The API version number allows for evolving the `rippled` API while maintaining backward compatibility
-  author: Elliot Lee (intelliot), Peng Wang (pwang200)
+  author: Elliot Lee (@intelliot), Peng Wang (@pwang200)
   status: Final
   category: Protocol
   created: 2021-08-11

XLS-0025-enhanced-secret-numbers/README.md

@@ -2,7 +2,7 @@
   xls: 25
   title: Enhanced Secret Numbers
   description: Enhances XLS-12 secret number format by introducing an additional block for encoding ancillary information, and supporingt for longer secrets.
-  author: Nik Bougalis (nikb@bougalis.net)
+  author: Nik Bougalis <nikb@bougalis.net>
   status: Final
   category: Community
   created: 2021-12-10

XLS-0041-xpop/README.md

@@ -1,7 +1,7 @@
 <pre>
     xls: 41
     title: XRPL Proof of Payment Standard (XPOP)
-    author: Richard Holland (RichardAH)
+    author: Richard Holland (@RichardAH)
 	description: An offline non-interactive cryptographic proof that a transaction was successfully submitted to the XRP Ledger and what its impact (metadata) was
     created: 2023-05-04
     status: Final

XLS-0064-pseudo-account/README.md

@@ -11,11 +11,11 @@ updated: 2025-08-29
 
 ### Abstract
 
-This document proposes a standard for a *pseudo-account*, an `AccountRoot` ledger entry that can be associated with one or more other ledger entries. A pseudo-account is designed to hold and/or issue assets on behalf of its associated entries, enabling protocol-level functionality that requires an on-ledger entity to manage funds.
+This document proposes a standard for a _pseudo-account_, an `AccountRoot` ledger entry that can be associated with one or more other ledger entries. A pseudo-account is designed to hold and/or issue assets on behalf of its associated entries, enabling protocol-level functionality that requires an on-ledger entity to manage funds.
 
 ### Motivation
 
-The XRP Ledger is an account-based system where assets (XRP, IOUs, etc.) can only be held by an `AccountRoot` entry. However, several advanced protocols, such as Automated Market Makers (AMMs), lending pools, and vaults, require a ledger *object* itself to hold and manage assets.
+The XRP Ledger is an account-based system where assets (XRP, IOUs, etc.) can only be held by an `AccountRoot` entry. However, several advanced protocols, such as Automated Market Makers (AMMs), lending pools, and vaults, require a ledger _object_ itself to hold and manage assets.
 
 The [XLS-30 (AMM)](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0030-automated-market-maker#readme) specification pioneered this concept by introducing a pseudo-account linked to each `AMM` instance. This allows the AMM to track its token balances and issue Liquidity Provider Tokens (`LPTokens`).
 
@@ -43,30 +43,30 @@ A nonce-based approach is used to generate the unique `AccountRoot` ID:
 
 ###### **Fields**
 
-| Field Name | Constant | Required | Internal Type | Default Value | Description |
-| :--- | :---: | :---: | :---: | :---: | :--- |
-| `<Object>ID` | Yes | Yes | `HASH256` | N/A | The unique identifier of the ledger object this pseudo-account is associated with. |
-| `Flags` | Yes | Yes | `UINT32` | N/A | A set of flags that must be set for a pseudo-account. |
-| `Sequence` | Yes | Yes | `UINT32` | `0` | The sequence number, which must be `0`. |
-| `RegularKey` | Yes | No | `ACCOUNT` | N/A | A regular key, which must not be set for a pseudo-account. |
+| Field Name   | Constant | Required | Internal Type | Default Value | Description                                                                        |
+| :----------- | :------: | :------: | :-----------: | :-----------: | :--------------------------------------------------------------------------------- |
+| `<Object>ID` |   Yes    |   Yes    |   `HASH256`   |      N/A      | The unique identifier of the ledger object this pseudo-account is associated with. |
+| `Flags`      |   Yes    |   Yes    |   `UINT32`    |      N/A      | A set of flags that must be set for a pseudo-account.                              |
+| `Sequence`   |   Yes    |   Yes    |   `UINT32`    |      `0`      | The sequence number, which must be `0`.                                            |
+| `RegularKey` |   Yes    |    No    |   `ACCOUNT`   |      N/A      | A regular key, which must not be set for a pseudo-account.                         |
 
 A detailed description of these fields follows:
 
 **`<Object>ID`**
 
 This field links the pseudo-account to its parent ledger object. Any protocol introducing a pseudo-account must define a new, optional field on the `AccountRoot` object to store this ID. The field name must follow this convention:
 
-* `<Object>` is the name of the associated ledger object (e.g., `AMM`, `Vault`). Names that are acronyms should be fully capitalized (`AMMID`). Otherwise, use PascalCase (`VaultID`).
-* The suffix `ID` must always be appended.
+- `<Object>` is the name of the associated ledger object (e.g., `AMM`, `Vault`). Names that are acronyms should be fully capitalized (`AMMID`). Otherwise, use PascalCase (`VaultID`).
+- The suffix `ID` must always be appended.
 
 **`Flags`**
 
 The following flags must be set on a pseudo-account's `AccountRoot` and must be immutable:
 
-| Flag Name | Hex Value | Description |
-| :--- | :---: | :--- |
-| `lsfDisableMaster` | `0x00040000` | Disables the master key pair, ensuring no entity can sign transactions directly for this account. Control is ceded entirely to protocol rules. |
-| `lsfDepositAuth` | `0x01000000` | Requires authorization for deposits, typically meaning that funds can only be sent to this account via specific protocol transactions rather than standard `Payment` transactions. |
+| Flag Name          |  Hex Value   | Description                                                                                                                                                                        |
+| :----------------- | :----------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `lsfDisableMaster` | `0x00040000` | Disables the master key pair, ensuring no entity can sign transactions directly for this account. Control is ceded entirely to protocol rules.                                     |
+| `lsfDepositAuth`   | `0x01000000` | Requires authorization for deposits, typically meaning that funds can only be sent to this account via specific protocol transactions rather than standard `Payment` transactions. |
 
 **`Sequence`**
 
@@ -80,9 +80,9 @@ A `RegularKey` must not be set on a pseudo-account.
 
 The cost of creating a pseudo-account depends on whether it is owned and controlled by another account.
 
-* **Owned Pseudo-Accounts:** For objects like a `Vault` where a single account owns and controls the associated pseudo-account, the transaction must increase the owner's XRP reserve by one increment. This is in addition to any other reserve requirements of the transaction (e.g., for the `Vault` object itself). The transaction fee is the standard network fee.
+- **Owned Pseudo-Accounts:** For objects like a `Vault` where a single account owns and controls the associated pseudo-account, the transaction must increase the owner's XRP reserve by one increment. This is in addition to any other reserve requirements of the transaction (e.g., for the `Vault` object itself). The transaction fee is the standard network fee.
 
-* **Unowned Pseudo-Accounts:** For objects like an `AMM` that are not owned by any account, the creation transaction must charge a special, higher-than-normal transaction fee. This fee must be at least the value of one incremental owner reserve (currently **2 XRP**, subject to change via Fee Voting). This amount is burned, compensating for the permanent ledger space without tying the reserve to a specific owner.
+- **Unowned Pseudo-Accounts:** For objects like an `AMM` that are not owned by any account, the creation transaction must charge a special, higher-than-normal transaction fee. This fee must be at least the value of one incremental owner reserve (currently **2 XRP**, subject to change via Fee Voting). This amount is burned, compensating for the permanent ledger space without tying the reserve to a specific owner.
 
 ###### **Deletion**
 
@@ -92,18 +92,18 @@ A pseudo-account must be deleted together with the associated object.
 
 The following invariants must hold true for any `AccountRoot` entry functioning as a pseudo-account:
 
-* The ledger object identified by the `<Object>ID` field must exist.
-* Exactly one `<Object>ID` field must be present on the `AccountRoot` (e.g., an account cannot be linked to both an `AMMID` and a `VaultID`).
-* The `lsfDisableMaster` and `lsfDepositAuth` flags must always be set.
-* The `Sequence` number must always be `0`, and must never change.
-  * AMM pseudo-accounts created under old rules will have a sequence number set to the index of the ledger they were created in. They still must never change.
-* A `RegularKey` must not be set.
+- The ledger object identified by the `<Object>ID` field must exist.
+- Exactly one `<Object>ID` field must be present on the `AccountRoot` (e.g., an account cannot be linked to both an `AMMID` and a `VaultID`).
+- The `lsfDisableMaster` and `lsfDepositAuth` flags must always be set.
+- The `Sequence` number must always be `0`, and must never change.
+  - AMM pseudo-accounts created under old rules will have a sequence number set to the index of the ledger they were created in. They still must never change.
+- A `RegularKey` must not be set.
 
 ### Security Considerations
 
 The design of pseudo-accounts includes several critical security features:
 
-* **No Direct Control:** The mandatory `lsfDisableMaster` flag and the absence of a `RegularKey` ensure that no user can directly control the pseudo-account or its assets. All fund movements are governed exclusively by the rules of the associated protocol.
-* **Transaction Prevention:** A `Sequence` of `0` makes it impossible for the account to submit transactions, preventing any misuse of the account itself.
-* **Address Front-running Prevention:** The deterministic but unpredictable method for generating the account address prevents attackers from guessing the address and sending funds to it before it is officially created by the protocol.
-* **Controlled Deposits:** The `lsfDepositAuth` flag prevents arbitrary `Payment` transactions from being sent to the account, ensuring that its balances can only be modified through legitimate protocol transactions.
+- **No Direct Control:** The mandatory `lsfDisableMaster` flag and the absence of a `RegularKey` ensure that no user can directly control the pseudo-account or its assets. All fund movements are governed exclusively by the rules of the associated protocol.
+- **Transaction Prevention:** A `Sequence` of `0` makes it impossible for the account to submit transactions, preventing any misuse of the account itself.
+- **Address Front-running Prevention:** The deterministic but unpredictable method for generating the account address prevents attackers from guessing the address and sending funds to it before it is officially created by the protocol.
+- **Controlled Deposits:** The `lsfDepositAuth` flag prevents arbitrary `Payment` transactions from being sent to the account, ensuring that its balances can only be modified through legitimate protocol transactions.

XLS-0069-simulate/README.md

@@ -2,7 +2,7 @@
   xls: 69
   title: Simulating Transaction Execution
   description: A new API method for executing dry runs of transactions without submitting them to the network
-  author: Mayukha Vadari <mvadari@ripple.com>, Elliot Lee (intelliot)
+  author: Mayukha Vadari <mvadari@ripple.com>, Elliot Lee (@intelliot)
   discussion-from: https://github.com/XRPLF/XRPL-Standards/discussions/199
   status: Final
   category: Protocol

site/xls_parser.py

@@ -193,10 +193,20 @@ def validate_xls_documents(root_dir: Path) -> bool:
                 validation_errors.append(
                     f"Error: {doc.folder} is missing required authors metadata"
                 )
+            elif any(not name for name, _ in doc.authors):
+                validation_errors.append(
+                    f"Error: {doc.folder} has an author with missing name"
+                )
+            elif any(link == "" for _, link in doc.authors):
+                validation_errors.append(
+                    f"Error: {doc.folder} has an author with missing link"
+                )
+
             if not doc.status or doc.status == "Unknown":
                 validation_errors.append(
                     f"Error: {doc.folder} is missing required status metadata"
                 )
+
             if not doc.category or doc.category == "Unknown":
                 validation_errors.append(
                     f"Error: {doc.folder} is missing required category metadata"
@@ -205,20 +215,22 @@ def validate_xls_documents(root_dir: Path) -> bool:
                 validation_errors.append(
                     f"Error: {doc.folder} has an invalid category: {doc.category}"
                 )
+
             if not doc.created or doc.created == "Unknown":
                 validation_errors.append(
                     f"Error: {doc.folder} is missing required created metadata"
                 )
 
         if validation_errors:
+            print("\n")
             for error in validation_errors:
                 print(error)
             print(
                 f"Validation failed: {len(validation_errors)} document(s) missing required metadata"
             )
             return False
 
-        print(f"Successfully validated {len(docs)} XLS documents")
+        print(f"\nSuccessfully validated {len(docs)} XLS documents")
         return True
 
     except Exception as e: