Blog · 5. November 2026

USDT von Einzahlungsadressen auf TRON sweepen: Aktivierung, Energie und Bandbreite je Sweep

Ein Zahlungs-Gateway oder eine Börse, die jedem Kunden eine eigene Einzahlungsadresse gibt, muss das TRC-20-USDT auf diesen Adressen in einer Hauptwallet, der Hot Wallet, einsammeln, bevor sie etwas davon auszahlen kann. Auf TRON ist jeder dieser Züge ein gewöhnlicher USDT-Transfer, signiert von der Einzahlungsadresse. Er braucht ein Konto on-chain, Energie für den Vertragsaufruf und Bandbreite für die Bytes, und eine Einzahlungsadresse, auf die nur je USDT eingezahlt wurde, hat nichts davon.

Das Empfangen von USDT legt kein Konto an

Ein USDT-Guthaben ist ein Eintrag im eigenen Speicher des Token-Vertrags. Ein eingehender Transfer schreibt diesen Eintrag und legt kein Konto an, eine Adresse kann also USDT halten, während das Netz überhaupt kein Konto für sie hat. Unsere Messung vom 7. September 2026 fand zwei solche Adressen im Mainnet: Jede hielt USDT, und die Node, von der wir lasen, gab ein leeres Objekt zurück, als sie nach dem Konto dahinter gefragt wurde, sowohl vor unserem Testaufruf als auch danach. Am 27. Oktober hielten beide noch genau die Guthaben, die sie am 7. September gehalten hatten.

Energie wird an ein Konto delegiert, und an eine Adresse, die keines hat, liefern wir sie nicht: Eine Bestellung in mode A oder mode C, die eine solche Adresse als from nennt, kommt mit 422 invalid_address zurück, wobei details.reason auf inactive_wallet steht. Ob die Kette selbst eine Delegation an eine solche Adresse annehmen würde, haben wir nicht getestet, weil unsere Ablehnung zuerst kommt. Unsere Betriebsnotizen halten auch die Antwort der Node auf ein Senden von einer Wallet fest, die nie etwas empfangen hat, no OwnerAccount. Diese Notiz betrifft TRX, das von unserer eigenen Hot Wallet gesendet wurde; einen USDT-Transfer aus einer Adresse in diesem Zustand haben wir nicht versucht. Die ganze Geschichte dieses Zustands steht in dem Beitrag über nicht aktivierte Konten.

Eine Adresse zu aktivieren braucht einen TRX-Transfer, bezahlt vom Absender

Jeder eingehende TRX-Transfer legt das Konto an, wie klein er auch ist, und von da an ist die Adresse ein Konto wie jedes andere. Der erste Versuch dieser Messung ging genau daran schief, und wir haben ihn verworfen: Eine Adresse las sich als ohne Konto, und 22 Sekunden später schickte ihr jemand ein einziges sun, das eines anlegte. Ihre eigene Erstellungszeit verriet es.

Die Gebühr für das Anlegen trifft den, der das TRX sendet: in einem Sweep-Aufbau die Wallet, die die Aktivierungen finanziert. Zwei Kettenparameter legen sie fest. Wir haben sie am 3. September 2026 gelesen, und das Netz kann sie ändern, lesen Sie sie also erneut, bevor Sie damit budgetieren.

Wie die beiden bei einem einfachen TRX-Transfer zusammenwirken, haben wir nicht mit einem eigenen Senden gemessen: Das braucht einen echten Transfer an eine frische Adresse, und den haben wir nicht gemacht. So oder so wird die Gebühr einmal je Adresse bezahlt. Ein Desk, das jede Adresse bei ihrer Erzeugung aktiviert, zahlt sie auf Adressen, die womöglich nie eine Einzahlung sehen, und eines, das bei der ersten Einzahlung aktiviert, zahlt sie nur dort, wo es etwas einzusammeln gibt.

Jeder Sweep nimmt die niedrigere Energiezahl

Was ein USDT-Transfer an Energie verbraucht, hängt vom Empfänger ab. Hält der Empfänger bereits USDT, braucht der Transfer rund 65,000 Einheiten; ist sein USDT-Guthaben null, braucht er rund 131,000. Ob der Empfänger ein Konto hat, spielt keine Rolle. Die Messung, die jene beiden Adressen fand, stellte alle vier Kombinationen nebeneinander, und das Guthaben entschied jedes Mal (warum es zwei Zahlen gibt).

Ein Sweep zahlt immer an denselben Empfänger, die Hot Wallet, und die Hot Wallet hält USDT. Jeder Sweep ist also die günstigere Art, single, in welchem Zustand sich die Einzahlungsadresse auch befindet. Die Aufrufe vom 7. September bewegten eine Einheit aus einer Wallet, die den Rest behielt, während ein Sweep alles bewegt und die Einzahlungsadresse auf null lässt. Am 27. Oktober haben wir die Node beide auf denselben zwei Adressen simulieren lassen, mit einer Wallet, die USDT hält, als Empfänger.

Das Leeren der Einzahlungsadresse änderte nichts, und die Zahl ist die, die jene Messung für jeden Transfer an einen Halter ergab. Das sind Simulationen der Node, und keine davon ist eine Quittung eines übertragenen Sweeps; die Zahlen vom 7. September tragen denselben Vorbehalt. Ob die beiden Adressen heute ein Konto haben, haben wir nicht erneut gelesen.

Der einzige Weg, die günstigere Art zu verlieren, ist, die Hot Wallet zu leeren. Eine einzige Einheit USDT beim Empfänger genügt für die niedrigere Zahl, aber bei null braucht der nächste Sweep in sie rund 131,000 Einheiten, das sind 13.1 TRX, wenn verbrannt. Verbrannt kostet ein normaler Sweep 6.5 TRX zum Protokollsatz von 100 sun je Einheit, und was es kostet, dieselbe Energie zu mieten, bewegt sich mit dem Markt.

Freie Bandbreite deckt etwa einen Sweep je Adresse und Tag

Bandbreite misst die Bytes einer Transaktion, wo Energie ihre Berechnung misst (die beiden Zähler nebeneinander). Jedes Konto bekommt davon ein freies Tageskontingent. Der USDT-Transfer, den wir am 2. September 2026 im Mainnet gesendet und gemessen haben, bezahlte seine Bandbreite in TRX, und daraus ergibt sich genau, wie viel Bandbreite ihm berechnet wurde.

Gegen 600 am Tag passt ein Sweep mit dieser Berechnung hinein, zwei direkt hintereinander nicht. Über das Kontingent hinaus verbrennt das Netz das TRX des Absenders für die Bytes. Der erste Sweep einer Adresse an einem Tag kostet also keine Bandbreite, und eine Einzahlungsadresse, die auch ihre Energie per Delegation erhält, braucht kein eigenes TRX, um ihn zu senden. Ein zweiter Sweep kurz nach dem ersten bezahlt seine Bytes aus dem TRX der Einzahlungsadresse. Wie schnell sich das Kontingent zwischen beiden erholt, haben wir nicht gemessen; unser eigener Sweep rechnet mit etwa einem Transfer am Tag je Adresse aus dem freien Kontingent. Soll eine Adresse öfter als das eingesammelt werden, kann der aktivierende Transfer ihr zugleich das TRX für diese Bytes hinterlassen.

Die Energie für einen Sweep-Lauf bestellen

Mode A nennt beide Enden jedes Transfers, die Einzahlungsadresse als from und die Hot Wallet als to, und die Art lesen wir selbst von der Hot Wallet ab. Mode C nennt nur die Wallet, die mit Energie versorgt werden soll, und nimmt die Art von Ihnen, was zu einem Verwahrsystem passt, das seine Sweeps nach eigenem Zeitplan signiert und die Energie zuerst bereitstehen haben will (mode C im Detail). Bei einem Sweep ist diese Art immer single, solange die Hot Wallet USDT hält. Beide Modi nehmen bis zu 500 Transfers in einer Bestellung, dieselbe Obergrenze wie ein Auszahlungslauf. Die Mietdauer beträgt fünf Minuten oder eine Stunde, und send_before liegt drei Sekunden vor ihrem Ende.

Eine Einzahlungsadresse ohne Konto lässt die ganze Bestellung scheitern. Das 422 nennt sie in details.index und details.address, und es wird nichts gekauft. Prüfen Sie den Lauf also zuerst. POST /v1/estimate nimmt dieselben 500 Transfers und reserviert nichts, und es warnt dort, wo die Bestellung ablehnen würde: Geben Sie bei jeder Position from an, und jede Einzahlungsadresse ohne Konto kommt mit der Markierung inactive_sender zurück. Aktivieren Sie diese, lassen Sie die Aktivierungen bestätigen und senden Sie die Bestellung. Die Ablehnung verbraucht den Idempotency-Key nicht, und wir lesen die Aktivierung an unserem Cache vorbei neu, bevor wir eine Bestellung deswegen ablehnen, derselbe Schlüssel und derselbe Body funktionieren also, sobald der aktivierende Transfer bestätigt ist.

Regeln, die man aus unserem eigenen Sweep mitnehmen kann

Wir betreiben einen eigenen Sweep. Kunden zahlen an Einzahlungsadressen, die wir für sie halten, und ein Hintergrunddurchlauf bewegt diese Coins zu der einen Hot Wallet, die Einkäufe bezahlt. Er bewegt TRX, verbraucht also Bandbreite und keine Energie, und seine Aufzeichnungen sagen nichts über die Energieseite eines USDT-Sweeps.

Unser Sweep liest den Betrag in dem Moment aus der Kette, in dem er entscheidet. Unsere eigenen Aufzeichnungen wissen nichts von einer Gebühr, die verbrannt wurde, oder von einem Sweep, dessen Datenbankzeile einen abgestürzten Prozess nicht überlebt hat, und die Kette weiß es. Dieselbe Regel macht eine Wiederholung sicher: Sind die Coins schon weg, gibt es nichts zu senden.

Wir halten einen übertragenen Sweep offen, bis seine Transaktion in einem Block auftaucht, und schreiben ihn erst nach einem Fenster als gescheitert ab, das nicht kürzer ist als die längste Ablaufzeit, die unser Signer einer Transaktion gibt. Schließt man ihn früher, wird ein Transfer, der noch ankommen kann, als verloren gezählt, und der nächste Durchlauf signiert womöglich einen zweiten Transfer desselben Guthabens. Solange ein Sweep unbestätigt ist, bleibt seine Adresse aus dem nächsten Durchlauf heraus.

Unser TRX-Sweep sendet höchstens das Guthaben abzüglich einer Gebührenreserve und behält diese Reserve nur, wenn die freie Bandbreite der Adresse bereits verbraucht ist. Ein USDT-Sweep bezahlt seine Gebühr in einer anderen Münze als der, die er bewegt, also geht jedes Mal das ganze USDT-Guthaben, und die Reserve wird zu dem TRX, das eine Einzahlungsadresse für die Bytes eines zweiten Sweeps an einem Tag braucht.

Finden Sie jede Einzahlungsadresse, die noch aktiviert werden muss, bevor der Sweep bepreist wird, fünfhundert je Anfrage: POST /v1/estimate mit from bei jeder Position →