Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

VaultMetadata XLS-98

Eine optionale JSON-Konvention für Name und Website eines Single Asset Vault im vorhandenen Data-Feld. Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Netzwerkstatus
Kein Netzwerk-Amendment
XLS
XLS-98
Spec-Status
Draft
Spec-Stand
28.01.2026

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

Das freie Data-Feld verrät ohne gemeinsame Struktur nicht, welchen Zweck ein Vault hat oder wo verlässlicher Betreiberkontext zu finden ist. Anwendungen müssten diese Zuordnung sonst separat pflegen.

Wie ist der Mechanismus im aktuellen Draft gedacht?

Ein teilnehmender Vault speichert ein kompaktes JSON-Objekt in Data. Der Schlüssel n bezeichnet den Anzeigenamen, w eine Betreiber- oder Fondswebsite; beide Werte sind nach der Konvention empfohlen. VaultSet kann die Angaben später ändern, ohne andere freie Data-Nutzungen zu verbieten.

Wie verbindlich ist das?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Was ändert sich gegenüber dem Vorgänger?

VorherNachher
Vault.Data war ein freies Bytefeld ohne gemeinsame maschinenlesbare Bedeutung.Teilnehmende Vaults könnten Name und Website in einem kleinen, einheitlich lesbaren JSON-Objekt veröffentlichen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Nutzer könnten Vaults leichter zuordnen. Ein angezeigter Name oder Link beweist weder Betreiberidentität noch Seriosität.

Wallets und App-Entwickler

Explorer sollten JSON defensiv parsen, Ausgaben bereinigen und unbekannte Schlüssel tolerieren. Historische Änderungen können für Audits relevant sein.

Börsen und Emittenten

Vaultbetreiber können einen verständlichen Namen und einen Kontextlink veröffentlichen, dürfen dort aber keine sensiblen Daten ablegen.

Node-Betreiber

Für Nodes entsteht keine neue Ausführungslogik. Sie erzwingen weiter nur die vorhandene 256-Byte-Grenze des Vault.Data-Felds.

Welche Grenzen und Risiken bleiben?

  • XLS-98 ist ein freiwilliger Ecosystem-Draft und kein Netzwerk-Amendment.
  • Der Ledger prüft nicht, ob das JSON der Konvention entspricht.
  • Die Website ist nicht kryptografisch verifiziert und kein Eigentumsnachweis.
  • Alle Angaben sind öffentlich und können über VaultSet verändert werden.
  • Das gesamte Data-Feld bleibt auf 256 Byte begrenzt.
  • Anwendungen müssen Inhalte bereinigen, bevor sie Namen oder URLs rendern.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • VaultCreate
  • VaultSet

Ledger-Objekte

  • Vault aus XLS-65

Felder und Flags

  • Data (max. 256 Byte)
  • n für name
  • w für website
  • gültiges JSON-Objekt

Invarianten

  • Die Konvention ist optional und ändert keine Protokollvalidierung des Data-Felds.

Wie sieht ein konkreter Ablauf aus?

Ein Vault speichert {"n":"EUR Credit Vault","w":"example.org"}. Ein Explorer zeigt den Namen an und kennzeichnet die Website weiterhin als unbestätigte Betreiberangabe.

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

Wie geht es mit diesem Vorschlag weiter?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Der Entwurf muss fachlich reifen und kann sich noch grundlegend ändern oder verworfen werden. Erst ein passendes rippled-Amendment würde eine getrennte Netzwerkabstimmung auslösen.

Wo steht es in seiner Amendment-Familie?

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen