formatting - remove separators

Author: achowdhry-ripple

XLS-0103-vault-metadata/README.md

@@ -22,8 +22,6 @@ This document proposes a minimal, optional convention for using the Vault arbitr
 
 This proposal does not restrict how the arbitrary data field may otherwise be used. Vaults that follow this recommendation will simply be easier to identify and integrate into downstream applications.
 
----
-
 ## 1. Background and Motivation
 
 The Vault object includes a `Data` field defined as:
@@ -38,8 +36,6 @@ Because this field is unstructured, there is currently no consistent way to:
 
 As Vaults become more widely used for institutional and ecosystem-facing use cases, the absence of standardized metadata limits transparency and usability.
 
----
-
 ## 2. Proposed Data Convention
 
 This proposal defines a minimal JSON-based convention for the Vault `Data` field. The convention focuses on compact key names to accommodate the 256-byte size limit, while still providing sufficient context for discovery and attribution.
@@ -53,17 +49,13 @@ All fields defined below are optional but recommended.
 | `name`     | `n` | Human-readable name of the Vault or fund           | LATAM Private Credit Fund II | string | ✔️        |
 | `website`  | `w` | Website associated with the Vault operator or fund | examplefund.com              | string | ✔️        |
 
----
-
 ## 3. Usage Guidelines
 
 - The `Data` field should contain a valid JSON object when following this convention.
 - Short key names are recommended to minimize on-ledger storage usage.
 - The `website` field may point to a fund page, dashboard, or general operator website.
 - This convention is intended to complement, not replace, other attribution mechanisms such as account domain fields.
 
----
-
 ## 4. Example
 
 The following example demonstrates a Vault `Data` payload that follows this recommendation: