Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

Firewall XLS-86

Ein Entwurf für ausgehende Ziel-Whitelist, Gegenparteifreigabe, Backup-Konto und ein kontoweites Gebührenlimit. 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-86
Spec-Status
Draft
Spec-Stand
19.09.2025

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

Ein gestohlener Haupt- oder Regular Key kann heute den spendierbaren Wert eines Kontos schnell übertragen. Multi-Signing kann helfen, ist aber nicht dasselbe wie eine dauerhaft erzwungene Empfänger-Whitelist mit Gebührenobergrenze.

Wie ist der Mechanismus im aktuellen Draft gedacht?

FirewallSet koppelt das geschützte Konto an Counterparty und Backup und kann MaxFee setzen. WithdrawPreauth legt gemeinsam signierte Empfängerfreigaben an, während die Vorprüfung ausgehende Werttransaktionen ohne passende Freigabe mit tefFIREWALL_BLOCK stoppt. Änderungen und Löschung der Firewall benötigen die Counterparty-Signatur; Clawback und notwendige Systemaktionen bleiben erlaubt.

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
Ein gültiger Kontoschlüssel konnte ausgehende Ziele und Transaktionsgebühren ohne zusätzliche Protokollfreigabe bestimmen.Ein geschütztes Konto könnte nur freigegebene Empfänger bezahlen und keine Transaktion oberhalb seines MaxFee einreichen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Ein Nutzer könnte Empfänger vorab freigeben und Gebührenmissbrauch begrenzen. Ohne Kooperation der Counterparty lassen sich Freigaben oder MaxFee später nicht erweitern.

Wallets und App-Entwickler

Wallets müssen Firewallstatus, erlaubte Ziele, Backup, Counterparty-Signaturen und eine mögliche Blockade durch MaxFee vor dem Signieren sichtbar machen.

Börsen und Emittenten

Treasury-Konten könnten Auszahlungen auf bekannte Ziele begrenzen. Clawback-Rechte eines Emittenten werden von der Firewall nicht blockiert.

Node-Betreiber

Nodes müssten vor der Anwendung jeder Kontotransaktion die Gebührenobergrenze und bei relevanten Typen zusätzlich das Ziel prüfen.

Welche Grenzen und Risiken bleiben?

  • XLS-86 ist ein Draft und noch keine aktive Schutzfunktion.
  • MaxFee gilt einheitlich für alle ausgehenden Transaktionen und kann nicht je Transaktionstyp abgestuft werden.
  • Steigen Netzwerkgebühren über MaxFee, sind sämtliche Transaktionen blockiert, bis die Grenze mit Counterparty-Zustimmung angehoben wird.
  • Eine kompromittierte oder nicht erreichbare Counterparty kann allein nichts ändern, aber legitime Änderungen dauerhaft verweigern.
  • Die Firewall verhindert nicht alle Kontoverwaltungsaktionen und lässt ausdrücklich Systemtransaktionen sowie Emittenten-Clawback zu.
  • MaxFee begrenzt Transaktionsgebühren, nicht die XRP-Reserve.
  • Jede Empfängerfreigabe kostet Reserve und die praktische Anzahl bleibt durch Reserve und Owner Directory begrenzt.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Die Firewall selbst und WithdrawPreauth-Einträge binden Owner-Reserven. Die Erstellung verlangt laut Draft Reserve für zwei Objekte.
  • Die MaxFee-Prüfung soll als erste, günstige Prüfung laufen, bevor aufwendigere Firewall-Regeln ausgewertet werden.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • FirewallSet
  • FirewallDelete
  • WithdrawPreauth
  • alle ausgehenden Transaktionen unter MaxFee-Prüfung

Ledger-Objekte

  • Firewall (LedgerEntryType 0x0085)
  • WithdrawPreauth (LedgerEntryType 0x0856)

Felder und Flags

  • FirewallID / Counterparty / Backup
  • CounterpartySignature
  • MaxFee
  • Authorize / Unauthorize
  • Firewall Key Space 0x0046 / WithdrawPreauth Key Space 0x0047

Ergebnis-Codes

  • tefFIREWALL_BLOCK
  • temDISABLED / temINVALID_FLAG / temMALFORMED
  • temBAD_SIGNATURE / temINVALID_ACCOUNT_ID / temCANNOT_PREAUTH_SELF
  • tecDUPLICATE / tecNO_DST / tecNO_TARGET / tecNO_ENTRY
  • tecNO_PERMISSION / tecINSUFFICIENT_RESERVE / tecDIR_FULL

Wie hängt dieses Amendment mit anderen zusammen?

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

Für dieses Amendment ist keine direkte, belastbar belegte Familienkante eingetragen. Die Seite zeigt deshalb bewusst keinen vermuteten Zusammenhang.

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