Welche Kontrolle steht zwischen einem Auftrag und dem Schlüssel?

Ein verwahrender Anbieter hält einen Schlüssel, der Ihr Guthaben bewegen kann. Daran ändert nichts, was hier steht.

Was die Kontrollen ändern, ist die Zahl der Wege, auf denen ein Auftrag entstehen kann, den dieser Schlüssel unterschreibt. Jede schließt einen davon und lässt andere offen. Eine Kontrolle ohne ihre Grenze ist weniger wert als eine mit, denn die Grenze ist die Stelle, an die ein Mensch gehört.

Heiß ist der Schlüssel aus einem unspektakulären Grund. Jemand löst um zwei Uhr nachts eine Auszahlung aus, in einer Zeitzone, in der beim Anbieter niemand wach ist, und der Transfer muss trotzdem gebaut, signiert und ins Netzwerk gegeben werden. Kalte Verwahrung ist die Abwesenheit davon: Ein Schlüssel, der einen anwesenden Menschen braucht, kann keinen Auftrag beantworten. Wer auf Zuruf auszahlt, betreibt ein Hot Wallet, unter welchem Namen auch immer.

Die interessante Frage war also nie, ob der Schlüssel online ist. Sie lautet, was ein Auftrag überstehen muss, bevor der Schlüssel ihn überhaupt sieht.

Wo mehrere Unterschriften nicht geholfen haben

Unterschrieben wurde die Transaktion von genau den Leuten, die sie unterschreiben sollten.

Am oder um den 21. Februar 2025 verließen rund 1,5 Mrd. $ an virtuellen Werten Bybit; fünf Tage später schrieb das FBI die Tat Nordkorea zu.

Eine Woche nach der Tat beschrieb die Safe Ecosystem Foundation den Weg in einer eigenen Erklärung: Der Angriff auf den Bybit-Safe sei über einen kompromittierten Entwicklerrechner von Safe{Wallet} gelaufen, und auf diesem Weg sei eine getarnte bösartige Transaktion vorgeschlagen worden.

Mehrere Personen haben zugestimmt. Die Mehrfachunterschrift hat auf der falschen Transaktion genau das getan, wofür sie gebaut war, und die Zahl der Unterschriften war nie die Stellschraube. Das ist der Prüfsatz für alles Weitere: Was tut diese Kontrolle, wenn der Auftrag schon legitim aussieht?

Welcher Zugang kann überhaupt Geld bewegen?

Genau einer der beiden, und die Trennung ist erzwungen statt dokumentiert. Ein Händler hält je Umgebung einen Payment- und einen Payout-Zugang.

Der Payment-Zugang reicht an Rechnungen und Zahlungskanäle, der Payout-Zugang an Auszahlungen und an die Lesezugriffe, die eine Auszahlung zur Prüfung braucht. Keiner der beiden greift in den Bereich des anderen. Ein Payment-Schlüssel, der aus einem Plugin, einem Logfile oder von einem Laptop abhandenkommt, kann deshalb keine Auszahlung erstellen — er hat dafür nichts zu missbrauchen.

Geprüft wird an einer Stelle. Jede Anfrage passiert denselben einen Autorisierungsschritt, und der hält den Umfang des Aufrufers gegen das, was die Operation verlangt; ein Zugang, der nicht reicht, wird dort abgewiesen und erreicht den Handler nie.

Eine Prüfung, die jede Route für sich mitbringt, fehlt irgendwann auf der Route, die nächstes Quartal dazukommt.

Zwei Bedingungen stehen daneben. Ein Payout-Zugang muss eine IP-Liste tragen, und eine leere Liste wird bei der Anmeldung abgewiesen statt als „unbeschränkt“ gelesen; ein Payment-Zugang kann gar keine tragen, weil Zahlungsaufrufe von dort kommen müssen, wo Ihre Kunden sind.

Einen Schlüssel je Dienst oder je Shop gibt es nicht: je Umgebung ein aktiver Zugang pro Typ, vier insgesamt, und ein Widerruf ist endgültig.

Das gehört in einen Notfallplan und nicht in einen Prospekt: Ein Leck lässt sich nicht dadurch eingrenzen, dass man die undichte Anbindung abschaltet, denn jede Anbindung dieser Umgebung hält denselben Schlüssel.

Was trennt das isolierte Signieren?

Den Signierweg von den Oberflächen, die ein Händler oder ein Zahler erreichen kann.

Ausgehende Transaktionen werden abseits des öffentlichen Webpfads signiert, und eine Auszahlung darf nur ein Ziel nennen, das der Händler vorher freigegeben hat.

Isolation ist eine Aussage über Erreichbarkeit. Sie verkürzt die Liste dessen, was einen Auftrag vor den Schlüssel bringen kann, und das ist echte Arbeit. Es ist zugleich weniger, als das Wort verspricht, denn gegen einen Auftrag, der durch die Vordertür mit gültiger Signatur hereinkommt, richtet sie nichts aus.

Die Befugnis zu signieren teilt sie auch nicht auf, und nichts hier soll so gelesen werden. Das ist betreute Verwahrung: Der Händler beauftragt, der Anbieter betreibt Signieren und Versand. Ob dieser Tausch zu einem Unternehmen passt, ist eine Entscheidung über das Verwahrmodell und fällt, bevor irgendeine Kontrolle weiter unten überhaupt interessant wird.

Die nächste Frage einer Finanzabteilung hat eine kurze Antwort: Ein Paymos-Guthaben wird nicht beliehen und erwirtschaftet für Paymos nichts, solange es liegt.

Was begrenzt die Freigabeliste, und was nicht?

Die Richtung. Nicht die Höhe, nicht den Auftraggeber, und nicht, wem die Adresse inzwischen gehört.

Die Mechanik ist kurz genug, um sie an einer Stelle zu lesen:

• Steht nichts darauf, geht nichts hinaus. Eine leere Liste gilt nicht als „keine Einschränkung“, sie schaltet Auszahlungen ab.
• Ein Eintrag ist nach Adresse und Netzwerkgruppe geschlüsselt. Eine freigegebene EVM-Adresse deckt Ethereum, BSC, Polygon, Arbitrum, Optimism, Base, Avalanche und Plasma in einem Zug; Tron, TON und Solana sind eigene Gruppen.
• Freigeben lassen sich vier Gruppen und nur vier. Deshalb nehmen NEAR und Sui Zahlungen an und können kein Auszahlungsziel sein.
• Entfernen widerruft den Eintrag, statt ihn zu löschen. Die Spur, wer wann Ziel sein durfte, bleibt damit erhalten.
• Eine Freigabe trägt bis zu 1.000 Adressen, ein CSV-Import bis zu 1.000 Zeilen je Datei, und ein Konto hält höchstens 5.000 aktive Einträge.
• Einen API-Weg dafür gibt es nicht. Die Liste lebt im Dashboard, und ein Payout-Zugang liest sie, um ein Ziel zu prüfen, ohne eines eintragen zu können.

Bei der letzten Zeile lohnt ein Moment. Der Zugang, der Geld bewegt, kann die Menge der Orte, wohin es darf, nicht erweitern, und diese Trennung übersteht eine Fehlkonfiguration, weil der Weg dafür nie gebaut wurde.

Jetzt die Grenzen. Eine Freigabeliste ist eine Aussage über die Richtung und keine über Eigentum: Ein Händler darf die Adresse eines Kunden oder eines Spielers mit Absicht freigeben und dorthin auszahlen — so funktionieren Auszahlungen an Endnutzer hier.

Eine im März für das Wallet eines Dienstleisters freigegebene Adresse ist im September eine freigegebene Adresse, auch wenn dieser Dienstleister längst gegangen ist.

Über die Höhe sagt sie ebenso wenig. Zwei Kontolimits gelten für eine Auszahlung — eine Obergrenze je Auszahlung und eine Grenze dafür, wie viele gleichzeitig unterwegs sein dürfen — und die verbleibende Zahl steht im Auszahlungsformular, bevor überhaupt etwas eingetippt ist, statt hinterher als Ablehnung zu erscheinen.

Beide begrenzen eine Bewegung; die Liste begrenzt eine Richtung. Eine Auszahlung kann bequem innerhalb beider liegen und trotzdem irgendwohin gehen, wohin Sie sie heute Morgen nicht geschickt hätten.

Wer darf ein Ziel freigeben, und wer darf dorthin zahlen?

Absichtlich nicht dieselben Leute.

In der Grundeinstellung führt nur der Kontoinhaber die Freigabeliste. Wer die Rolle Finanzen trägt, zahlt an Ziele aus, die der Inhaber freigegeben hat, und darf selbst keines freigeben; ein Administrator darf zunächst gar nicht auszahlen.

Das NIST-Glossar fasst das Prinzip in einem Satz über die Lohnbuchhaltung: Niemand soll genug Rechte haben, um das System allein zu missbrauchen, und wer eine Gehaltszahlung genehmigt, sollte sie nicht auch vorbereiten können.

Grundeinstellungen sind allerdings eine Ausgangslage, und einzelnen Mitgliedern lassen sich zusätzliche Rechte einräumen.

Die Funktionstrennung hält, solange niemand diese Rechte vergibt und es danach vergisst. Damit gehört die Rechteseite zu dieser Kontrolle dazu.

Die zweite Schicht in diesem Moment ist eine erneute Authentifizierung, und sie ist nicht bedingungslos. Wer weder TOTP noch einen Passkey eingerichtet hat, wird nie gefragt, denn eine solche Abfrage verstärkt einen vorhandenen Faktor und kann keinen verlangen, den es nicht gibt.

Als Schutz, den das Konto schon hat, ist sie damit keiner. Was in beiden Fällen hält, ist die Liste: Eine Auszahlung darf nur eine Adresse darauf nennen, jedes Hinzufügen ist eine protokollierte Aktion für sich, und eine leere Liste heißt keine Auszahlungen.

Wo die Abfrage kommt, ist sie an die Aktion gebunden, die sie freigibt, und beim Einlösen verbraucht; offen auf dem Konto liegt sie nie.

Achten Sie darauf, wo sie sitzt. Die Auszahlung selbst fragt nichts; die Änderung an der Liste fragt. Bewacht wird die Tür, nicht jeder einzelne Weg hinaus.

Was hält eine Auszahlung auf, die schon läuft?

Von Station zu Station weniger, und diese Reihenfolge kennt man besser vorher. Stornieren ist ein Fenster am Anfang, kein Rückruf. Eine Auszahlung lässt sich stornieren, solange sie noch im Zustand created steht und die Ausführung nicht begonnen hat; ein zweiter Aufruf auf eine bereits stornierte Auszahlung bekommt eine 200 zurück und bewegt nichts mehr.

Danach gehört der Transfer der Kette, und die Freigabeliste erweist sich als das Einzige, was zwischen dem Auftrag und einer unumkehrbaren Transaktion stand.

Sperren arbeiten oberhalb der einzelnen Auszahlung. Es gibt eine globale Sperre für ausgehende Transfers und eine für ein einzelnes Paar aus Asset und Netzwerk, die sich selbst setzen kann: Laufen Hauptbuch und Wallet um mehr als eine eingestellte Toleranz auseinander, hält dieses Paar an, ohne dass es jemand bemerken muss.

Ein Sicherheitsmechanismus bei der Arbeit: Er hält genau das an, worüber die Bücher uneins sind, bevor jemand weiß, welche Seite irrt.

Davon getrennt kann ein Auszahlungsweg für ein Asset auf einem Netzwerk zeitweise nicht verfügbar sein. Abgewiesen wird er an der Tür, statt in einer Warteschlange zu landen: Das Paar fehlt in der Auswahl, ein Auftrag darauf wird beim Erstellen abgelehnt, und das Guthaben bleibt unberührt.

Eine Ablehnung kostet dabei nichts, und das ist so gebaut. Eine erstellte Auszahlung legt Betrag und Netzwerkgebühr in eine Reservierung; bleibt die Transaktion aus, wird die Reservierung ganz aufgelöst — die Gebühr ebenso wie der Betrag.

Für einen zweiten Anlauf gilt dasselbe: external_order_id ist je Händler eindeutig, und eine wiederholte Anlage gibt die bestehende Auszahlung zurück, statt eine zweite zu senden. Das rettet einen abgebrochenen Abrechnungslauf und nichts darüber hinaus.

Warum sagt eine gescheiterte Auszahlung so wenig?

Weil die Alternative eine interne Rohmeldung auf dem Bildschirm eines Händlers wäre. Warum eine Auszahlung gescheitert ist, erfährt der Händler nicht. Was er sieht, kommt aus dem Status — einer geschlossenen Menge von Ausgängen — und sagt, dass die Auszahlung nicht rausgegangen ist, dass die Reservierung aufgelöst wurde und wohin er sich wenden kann.

Das Feld dahinter trägt Ausnahmetexte aus Signierer und RPC, interne Zahlen und Notizen von Betreibern. Ein geschlossener Status an der Oberfläche statt einer Zeichenkette von weiter unten — das ist das Muster.

Der Preis dafür landet beim Händler, und beim fehlenden Grund bleibt es nicht. Eine Auszahlung, die nicht rausgeht, schickt keine E-Mail und legt nichts an die Glocke — davon erfahren Sie über den Webhook oder gar nicht.

Wie lange der Rest einer Auszahlung dauert, steht auf einer eigenen Seite.

Welche Fragen stellen Sie einem verwahrenden Anbieter?

Fangen Sie bei dem Guthaben an, das gerade nichts tut, und gehen Sie dann zu den Menschen.

Wird es verliehen, im Staking gebunden oder erwirtschaftet es dem Anbieter etwas, während es liegt? Danach: Welche Rolle gibt ein Ziel frei, darf dieselbe Rolle auch dorthin zahlen, und was tut die Abfrage bei einer Änderung der Liste auf einem Konto, auf dem niemand einen zweiten Faktor eingerichtet hat? Eine gute Antwort nennt eine Rolle und eine Abfrage, kein Team. Zuletzt: Was erfahren Sie, wenn eine Auszahlung nicht rausgeht, und über welchen Kanal? Wer „wir informieren Sie bei jedem Schritt per E-Mail“ antwortet, hat entweder etwas gebaut, das wir nicht haben, oder seinen eigenen Benachrichtigungscode nicht gelesen.

Eine Kontrolle trägt mehr als die übrigen, und es ist die Liste der freigegebenen Adressen. Sie wirkt genau so gut, wie sie kurz ist, und der Moment, den es zu bewachen lohnt, ist der, in dem sie sich ändert. Genau deshalb liegt diese Änderung bei Paymos standardmäßig beim Kontoinhaber, steht im Prüfprotokoll, hat keinen API-Weg und ist die eine Aktion, die nach einem zweiten Faktor fragt — während die Auszahlung, die sie später erlaubt, nach gar nichts fragt.