XRP Deposit Authorization erklärt: DepositAuth, DepositPreauth und sichere Zahlungseingänge
Im XRP Ledger können Zahlungen grundsätzlich ohne vorherige Zustimmung des Empfängers eintreffen. Für Privatpersonen ist das bequem. Für eine Börse, eine regulierte Zahlungsdienstleisterin oder eine Firma mit internen Kontrollpflichten kann derselbe Mechanismus jedoch unerwünscht sein. Deposit Authorization, oft DepositAuth genannt, verändert deshalb nicht die Übertragungstechnik von XRP, sondern die Annahmeregeln eines Kontos. Dieser Fachartikel erklärt, wie die Sperre funktioniert, welche Ausnahmen gelten und weshalb sie weder Identitätsprüfung noch vollständigen Betrugsschutz ersetzt.
Was ist Deposit Authorization?
DepositAuth ist eine optionale Kontoeinstellung des XRP Ledger. Solange sie ausgeschaltet ist, kann ein gewöhnliches Konto XRP von beliebigen anderen Adressen empfangen. Nach Aktivierung werden direkte Zahlungen unbekannter Absender grundsätzlich zurückgewiesen. Zulässig bleiben ausdrücklich vorautorisierte Absender und bestimmte Verfahren, bei denen der Empfänger die Annahme selbst auslöst. Das Protokoll setzt damit eine technische Empfangsbeschränkung um; ob der Absender wirtschaftlich vertrauenswürdig ist, beurteilt es nicht. Eine Adresse kann einer echten Person, einem Unternehmen oder einem automatisierten Dienst gehören.
Wozu brauchen Unternehmen kontrollierte Zahlungseingänge?
Bei Geschäftskonten müssen Zahlungseingänge häufig mit Rechnungen, Kundenakten, Sanktionsprüfungen und internen Freigaben zusammenpassen. Ungefragte Überweisungen können Buchhaltung und Herkunftsabklärung erschweren. DepositAuth bietet eine Möglichkeit, spontane direkte Zahlungen einzuschränken. Daraus folgt aber keine automatische Erfüllung von Geldwäschereivorschriften. Wer eine Adresse freischaltet, muss Identität, wirtschaftlich Berechtigte und zulässige Transaktionen weiterhin nach den jeweils anwendbaren Regeln prüfen. Die Blockchain kennt lediglich technische Kontoberechtigungen, nicht die juristische Qualität einer Geschäftsbeziehung.
Wie funktioniert die Aktivierung?
Das Konto aktiviert DepositAuth durch eine AccountSet-Transaktion mit SetFlag asfDepositAuth und dem Wert 9. Zum Abschalten wird eine AccountSet-Transaktion mit ClearFlag und demselben Wert gesendet. Beide Aktionen benötigen eine gültige Signatur und unterliegen den üblichen Transaktionsanforderungen. Eine Wallet-Oberfläche kann diese Einstellung unterschiedlich darstellen oder gar nicht anbieten. Vor einer Änderung sollte der Kontoinhaber prüfen, welche Einzahlungswege sein Geschäftsprozess tatsächlich benötigt und ob eine sichere Rücknahme der Einstellung möglich ist.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Relai verkauft nicht die hier besprochenen Altcoins. Gutscheincode: AUSWANDERNSCHWEIZ
Technische Kontrolle des Kontostatus
Die öffentliche Methode account_info liefert unter anderem das Flags-Feld des AccountRoot-Objekts. Das Bit lsfDepositAuth entspricht 0x01000000. Ist dieses Bit gesetzt, gilt die Einstellung als aktiviert. Die reine Existenz einer Wallet-Adresse reicht nicht, um den Status zu beurteilen. Wer Zahlungen automatisiert verarbeitet, sollte den Zustand aus einem validierten Ledger lesen und Änderungen überwachen. Eine veraltete lokale Anzeige kann sonst zu falschen Annahmen über die Erreichbarkeit des Kontos führen.
DepositPreauth: einzelne Absender freigeben
DepositPreauth ist ein eigener Transaktionstyp. Mit dem Feld Authorize erlaubt der Empfänger einer konkreten Adresse direkte Einzahlungen; mit Unauthorize entzieht er diese Berechtigung wieder. Die Erlaubnis ist gerichtet: Wenn A Zahlungen von B akzeptiert, bedeutet das nicht, dass B automatisch Zahlungen von A akzeptieren muss. Sie ist zudem nicht auf eine einzelne Währung beschränkt. Eine Freigabe für einen Absender darf daher nicht als Erlaubnis nur für XRP oder nur für einen bestimmten ausgegebenen Token verstanden werden.
Warum die Reihenfolge wichtig ist
Ein Unternehmen kann zuerst seine vertrauenswürdigen Gegenparteien freischalten und danach DepositAuth aktivieren. So reduziert es das Risiko, dass laufende Geschäftsprozesse unmittelbar unterbrochen werden. Wer dagegen zuerst die Sperre einschaltet, kann erwartete Direktzahlungen blockieren. Die Vorautorisierung ist zwar bereits vor Aktivierung möglich, entfaltet aber erst mit aktivem DepositAuth die entsprechende Wirkung. Auch nach einer Freigabe sollte der tatsächliche Zahlungseingang getestet werden: Netzwerkgebühren, Kontoreserven, Token-Vertrauenslinien und sonstige Voraussetzungen bleiben bestehen.
Kontoreserve und Ledger-Objekte
Jede adressbezogene DepositPreauth-Freigabe legt einen Eintrag im Ledger an. Dieser Eintrag beansprucht eine Owner-Reserve des freigebenden Kontos. Das bedeutet, dass nicht beliebig viele Gegenparteien ohne zusätzlichen Reservebedarf gespeichert werden können. Die Höhe der Reserven ist eine veränderliche Netzwerkgrösse und sollte vor einer Implementierung direkt anhand der aktuellen XRPL-Dokumentation und Netzwerkparameter geprüft werden. Beim Entfernen einer Freigabe wird der entsprechende Eintrag entfernt und die dafür gebundene Reserve wieder freigegeben. Eine Reserve ist keine Gebühr, die automatisch endgültig verloren ist.
Welche Zahlungen werden blockiert?
Bei aktivem DepositAuth scheitert eine gewöhnliche Payment-Transaktion eines nicht freigegebenen Absenders grundsätzlich. Das betrifft XRP ebenso wie andere auf dem XRPL übertragene Vermögenswerte. Allerdings existieren protokollbedingte Ausnahmen und Sonderfälle. Ein Konto mit zu wenig frei verfügbarem XRP kann unter engen Bedingungen eine kleine XRP-Zahlung zum Wiederherstellen seiner Handlungsfähigkeit empfangen. Ausserdem hängen bestimmte Token-Zuflüsse von Trust Lines, Rippling und Handelsangeboten ab. Die Einstellung sollte deshalb nicht als mathematische Garantie verstanden werden, dass niemals irgendein Wert zufliessen kann.
Checks, Escrow und Payment Channels
Nicht jeder Zahlungsvorgang ist eine direkte Payment-Transaktion. Bei einem Check kann der Empfänger den Abruf selbst auslösen. Bei Escrow werden XRP zunächst gesperrt und später unter den geltenden Bedingungen freigegeben. Payment Channels erlauben signierte Zahlungsansprüche und eine spätere Abrechnung. Diese Mechanismen können mit DepositAuth zusammenspielen, weil der Empfänger bei bestimmten Abläufen aktiv handelt. Die konkreten Bedingungen unterscheiden sich erheblich. Ein Check garantiert insbesondere nicht, dass bei Einlösung noch ausreichend Mittel vorhanden sind; Escrow reserviert Mittel dagegen bereits bei der Einrichtung.
Beispiel: Ein Händler akzeptiert nur geprüfte Kunden
Angenommen, ein Händler nutzt eine XRPL-Adresse für B2B-Zahlungen. Er kennt drei Vertragspartner, die zuvor geprüft wurden. Der Händler erstellt für deren Adressen DepositPreauth-Freigaben und aktiviert danach DepositAuth. Eine gewöhnliche direkte Zahlung einer vierten, nicht freigegebenen Adresse wird grundsätzlich nicht akzeptiert. Das ist eine technische Filterregel und keine Aussage darüber, ob die vierte Partei seriös ist. Für einen neuen Kunden muss der Händler zuerst seinen Prüfprozess durchführen und dann die entsprechende Adresse freigeben oder einen geeigneten zweistufigen Zahlungsweg nutzen.
Beispielrechnung: Reserve statt Gebühren verwechseln
Nehmen wir rein illustrativ an, eine Freigabe binde eine zusätzliche Reserve von R XRP und ein Betrieb benötige 40 adressbezogene Freigaben. Dann beträgt die dadurch gebundene Zusatzreserve 40 × R XRP. Bei R = 0,2 XRP wären es 8 XRP. Diese Werte sind ausdrücklich Rechenannahmen und keine Aussage über die aktuelle Netzwerkreserve. Daneben fallen Transaktionskosten für die Erstellung und spätere Änderung der Einträge an. Bei einer operativen Kalkulation sind beide Positionen getrennt zu betrachten: temporär gebundene Liquidität und tatsächlich verbrauchte Gebühren.
DepositAuth ist nicht RequireDest
RequireDest beziehungsweise das RequireDestTag-Flag verlangt bei bestimmten Zahlungen einen Destination Tag. Solch ein Tag dient oft der internen Zuordnung, beispielsweise wenn eine Börse eine Sammeladresse für viele Kunden nutzt. Ein Absender kann jedoch selbst irgendeinen Tag angeben. Der Tag überprüft nicht seine Identität. DepositAuth hingegen beschränkt grundsätzlich, wer direkt einzahlen darf. Beide Funktionen lösen somit verschiedene Probleme und können je nach Architektur nebeneinander sinnvoll sein. Wer sie verwechselt, könnte eine blosse Buchungsreferenz fälschlich als Zugangskontrolle interpretieren.
DepositAuth ist nicht RequireAuth
RequireAuth betrifft die Autorisierung von Trust Lines für ausgegebene Token und die Frage, wer solche Vermögenswerte halten darf. DepositAuth betrifft dagegen die Annahme von Wert durch ein bestimmtes Empfängerkonto. Ein Token-Emittent kann andere Anforderungen haben als ein Händler, der XRP empfängt. Auch DisallowXRP ist nicht dasselbe: Die XRPL-Dokumentation beschreibt dieses Flag als weichere Schutzmassnahme, deren Beachtung nicht in gleicher Weise vom Ledger erzwungen wird. Für eine verlässliche Architektur muss jede Funktion anhand ihrer genauen Protokollsemantik gewählt werden.
Vorautorisierung über Credentials
Die aktuelle XRPL-Dokumentation beschreibt zusätzlich eine Berechtigung anhand von Credentials. Hier kann eine Kombination von auf dem Ledger nachgewiesenen Berechtigungsnachweisen statt einer einzigen fest hinterlegten Absenderadresse relevant sein. Solche Funktionen hängen von den jeweils aktivierten Amendments ab und sollten nicht ohne Netzwerkprüfung vorausgesetzt werden. Auch ein technischer Credential-Nachweis ersetzt nicht automatisch die rechtliche Identitätsprüfung oder die Bewertung des Ausstellers. Insbesondere Gültigkeit, Ablauf, Akzeptanz und Zuordnung des Nachweises müssen bei der Integration berücksichtigt werden.
Prüfung mit deposit_authorized
Die XRPL-API bietet die Methode deposit_authorized, um zu prüfen, ob eine Quelle an ein bestimmtes Ziel einzahlen darf. Dabei wird berücksichtigt, ob das Ziel überhaupt DepositAuth verlangt und ob die Quelle entsprechend freigegeben ist. Für eine Zahlungsvorbereitung ist dies nützlich, aber kein Ersatz für eine endgültige Prüfung des tatsächlichen Transaktionsergebnisses. Zwischen Vorabprüfung und Einreichung können Berechtigungen geändert werden. Erst das Ergebnis im validierten Ledger bestätigt, ob ein konkreter Zahlungsvorgang erfolgreich abgeschlossen wurde.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Relai verkauft nicht die hier besprochenen Altcoins. Gutscheincode: AUSWANDERNSCHWEIZ
Sicherheitsrisiken und Fehlkonfigurationen
Eine zu breite Freigabeliste vergrössert die Zahl möglicher unerwünschter Eingänge. Eine zu enge Liste blockiert legitime Kunden. Fehler bei der Zuordnung von Adressen können ebenfalls schwerwiegende Folgen haben. Besonders kritisch sind kompromittierte Schlüssel: Wer eine freigegebene Adresse kontrolliert, kann deren technische Berechtigung missbrauchen. Deshalb gehören Schlüsselverwaltung, Vier-Augen-Freigaben, regelmässige Überprüfung der Berechtigungsliste und Notfallverfahren zu einer professionellen Umsetzung. DepositAuth verhindert weder Phishing noch Kursverluste, manipulierte Wallet-Oberflächen oder fehlerhafte Smart-Contract-Integrationen.
Datenschutz und Compliance
Eine XRPL-Adresse ist pseudonym, nicht automatisch anonym. Zahlungsströme und Freigabeeinträge können öffentlich analysiert werden. Unternehmen sollten deshalb personenbezogene Prüfunterlagen nicht unbedacht auf einer öffentlichen Blockchain speichern. Die technische Erlaubnis kann auf eine Adresse zeigen, während die Dokumentation zur Geschäftsbeziehung in einem geschützten internen System liegt. Je nach Tätigkeit und Rechtsraum können zusätzliche Pflichten zur Herkunft der Mittel, Sanktionskontrolle und Aufbewahrung bestehen. Welche Vorgaben in der Schweiz oder EU tatsächlich greifen, hängt vom konkreten Geschäftsmodell ab; eine allgemeine Protokollfunktion schafft keine regulatorische Lizenz.
Operative Umsetzung in fünf Phasen
Zunächst wird festgelegt, welche Zahlungstypen angenommen werden sollen und wer Gegenparteien freigibt. Danach folgen eine Testumgebung mit absichtlich erlaubten und gesperrten Zahlungen, eine kontrollierte Migration bestehender Partneradressen und die Aktivierung von DepositAuth. Anschliessend müssen Monitoring und Fehlerbehandlung eingerichtet werden. Wichtig sind insbesondere Rückmeldungen bei abgewiesenen Zahlungen, Reserveüberwachung und eine dokumentierte Möglichkeit, Freigaben zu widerrufen. Vor dem produktiven Einsatz sollte der gesamte Prozess einschliesslich eines Schlüsselverlusts und einer versehentlichen Sperre durchgespielt werden.
Kosten, Leistungsfähigkeit und Grenzen
DepositAuth ist keine eigenständige Blockchain und benötigt keinen zusätzlichen Konsensmechanismus. Die Regeln werden innerhalb des XRPL-Protokolls durchgesetzt. Transaktionen zur Kontokonfiguration und Vorautorisierung verbrauchen Netzwerkgebühren; Einträge können Reserven binden. Die Zahl von Freigaben, die ein Unternehmen verwalten muss, kann jedoch operative Kosten verursachen, selbst wenn einzelne Ledger-Transaktionen günstig sind. Bei sehr vielen Kunden können alternative Einzahlungsprozesse sinnvoller sein. Ob eine Architektur skalierbar ist, hängt nicht allein von Transaktionen pro Sekunde, sondern auch von Onboarding, Identitätsprüfung und Support ab.
Vergleich: Direktzahlung oder kontrollierter Empfang?
Ohne DepositAuth ist der direkte Empfang für den Absender unkompliziert, aber das Konto kann grundsätzlich ungefragte Zahlungen erhalten. Mit DepositAuth und einzelnen Freigaben wird die Kontrolle strenger, dafür entsteht Verwaltungsaufwand. Mit Checks oder Escrow kann der Empfänger einen Zahlungseingang in einem zweiten Schritt auslösen, allerdings unterscheiden sich Liquiditätsbindung und Ausfallrisiko. Keine Variante ist für alle Nutzer besser. Für private Transfers kann die Standardeinstellung genügen, während ein institutioneller Empfänger eine gezielte Kontrolle bevorzugt.
Häufige Fragen
Kann ich DepositAuth nachträglich abschalten? Ja, mit einer entsprechend signierten AccountSet-Transaktion. Kann ich nur XRP erlauben, aber andere Token blockieren? Eine adressbezogene DepositPreauth-Freigabe ist grundsätzlich nicht währungsspezifisch. Muss jeder Absender freigeschaltet werden? Nicht für alle zweistufigen Empfangswege; direkte Payments benötigen grundsätzlich die entsprechende Erlaubnis. Ist die Funktion ein Schutz gegen Betrug? Nur begrenzt: Sie beschränkt bestimmte Eingänge, prüft aber weder Personen noch Transaktionsabsichten.
Fazit
Deposit Authorization ist ein spezialisiertes Werkzeug für kontrollierte Zahlungseingänge im XRP Ledger. Der wesentliche Unterschied zur gewöhnlichen Wallet liegt nicht im XRP-Kurs, sondern in der Frage, wer Werte unmittelbar annehmen lassen darf. Die Kombination aus AccountSet, DepositPreauth, geeigneten zweistufigen Zahlungswegen und laufender Überwachung kann für Unternehmen nützlich sein. Sie verlangt jedoch sorgfältige Implementierung und ersetzt keine rechtlichen oder organisatorischen Kontrollen. XRP und andere Kryptowährungen bleiben hochriskante Vermögenswerte; Totalverlust, Betrug und technische Fehler sind möglich. Dieser Artikel ist keine individuelle Anlage- oder Rechtsberatung.
Kommentare