fix without other formatting changes

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
@@ -99,6 +99,7 @@ The `proof` key inside `transaction` section has one of two possible forms:
 1. Tree form:
 
    In this form the merkle proof is an object of objects containing the entire transaction map for the ledger. This form is useful if many XPOPs must be generated for the same ledger and the size of each individual XPOP is less relevant than the amount of work to make and store the XPOPs. Each object contains three keys: `children`, `hash`, `key`.
+
    - The `children` key is always either an empty object or is keyed with only the branches which actually exist there, each as a single hex nibble `0` - `F`.
    - The `hash` key is always a 64 nibble hex string: either the hash over the children (with appropriate namespace) or, if a leaf node, the hash over the node (with appropriate namespace).
    - The `key` key is always a 64 nibble hex string: the keylet (index) of the object at this location.

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