Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

PseudoAccount XLS-64

Ein gemeinsamer Sicherheits- und Reserve-Standard für protokollgesteuerte AccountRoot-Objekte ohne privaten Schlüssel. 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-64
Spec-Status
Draft
Spec-Stand
29.08.2025

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

Auf dem kontobasierten XRPL können normale Ledger-Objekte nicht selbst XRP oder Token halten. Einzelne Protokolle benötigen deshalb ein AccountRoot, das ausschließlich ihren Regeln gehorcht und nach einheitlichen Sicherheitsregeln erzeugt wird.

Wie ist der Mechanismus im aktuellen Draft gedacht?

Das anlegende Protokoll leitet eine schwer vorhersagbare AccountID deterministisch aus Objektkennung und Nonce ab. Das AccountRoot erhält genau ein <Object>ID-Verknüpfungsfeld, lsfDisableMaster und lsfDepositAuth, während Sequence null bleibt und kein RegularKey gesetzt werden darf. Pseudo-Konto und Elternobjekt werden gemeinsam erzeugt und gemeinsam gelöscht.

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
Jedes Protokoll musste eigene Regeln für ein Asset haltendes, nicht signierbares Hilfskonto definieren.AMM, Vault oder ein künftiges Protokoll könnten dieselben unveränderlichen Sicherheits-, Verknüpfungs- und Reserveregeln verwenden.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Nutzer interagieren nicht mit einem normalen Schlüsselinhaber, sondern mit Protokollregeln. Direkte Payments an das Pseudo-Konto sind durch DepositAuth blockiert.

Wallets und App-Entwickler

Explorer und Wallets müssen Pseudo-Konten erkennen, das Elternobjekt auflösen und dürfen sie nicht wie frei kontrollierbare Nutzerkonten darstellen.

Börsen und Emittenten

Token können in Protokollkonten liegen, deren Bewegungen ausschließlich das Elternprotokoll erlaubt. Das verändert nicht automatisch Freeze-, Clawback- oder Autorisierungsrechte.

Node-Betreiber

Nodes prüfen AccountID-Kollision, feste Flags, Sequence, Verknüpfung und gemeinsame Lebensdauer von AccountRoot und Elternobjekt.

Welche Grenzen und Risiken bleiben?

  • XLS-64 ist ein Draft. Jedes nutzende Protokoll benötigt weiterhin seine eigene konkrete Amendment-Logik.
  • Ein Pseudo-Konto besitzt keinen privaten Schlüssel und kann keine normale Transaktion signieren.
  • Es darf nur mit genau einem Elternobjekt verknüpft sein.
  • Normale Payments werden durch DepositAuth abgewehrt; Assetbewegungen brauchen ausdrücklich erlaubte Protokollpfade.
  • Das Konto muss zusammen mit seinem Elternobjekt gelöscht werden.
  • Vor dem Standard erzeugte AMM-Pseudo-Konten können statt null ihre damalige LedgerSequence tragen. Auch dieser Wert darf sich nie ändern.
  • Ein Implementierungsfehler im Elternprotokoll kann nicht durch einen Kontoinhaber korrigiert werden, weil es keinen solchen Schlüsselinhaber gibt.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Ein besessenes Pseudo-Konto erhöht die Reserve des Eigentümers um eine zusätzliche Objektreserve.
  • Ein unbesessenes Pseudo-Konto wie beim AMM verlangt stattdessen eine verbrannte Sondergebühr von mindestens einer inkrementellen Owner-Reserve; der im Draft genannte damalige Wert von 2 XRP ist per Fee Voting veränderbar.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • keine allgemeinen Transaktionen; Erzeugung und Löschung durch das jeweilige Elternprotokoll

Ledger-Objekte

  • AccountRoot des Pseudo-Kontos
  • verknüpftes Elternobjekt

Felder und Flags

  • <Object>ID als genau ein Verknüpfungsfeld
  • Flags / Sequence = 0 / RegularKey nicht gesetzt
  • lsfDisableMaster 0x00040000
  • lsfDepositAuth 0x01000000

Invarianten

  • Das durch <Object>ID bezeichnete Elternobjekt muss existieren.
  • Genau ein <Object>ID-Feld darf vorhanden sein.
  • lsfDisableMaster und lsfDepositAuth müssen dauerhaft gesetzt bleiben.
  • Neu erzeugte Pseudo-Konten behalten Sequence null und dürfen keinen RegularKey besitzen. Alte AMM-Pseudo-Konten dürfen ihren abweichenden Startwert behalten, ihn aber nie ändern.

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