Blog · 30. Oktober 2026

Wie viel TRX eine Wallet braucht, um USDT zu senden

Eine Wallet, die USDT auf TRON sendet, muss zwei Zahlen richtig treffen, und sie werden leicht miteinander verwechselt. Die eine ist die Gebühr: was ein Transfer dem Konto abnimmt. Die andere ist das TRX, das das Konto halten muss, und das Limit, das die Transaktion tragen muss, damit der Transfer überhaupt durchgeht. Mit Energie auf der Wallet braucht sie TRX nur für Bytes: keines für den ersten Transfer des Tages, etwa 0.345 TRX für jeden weiteren. Ohne Energie braucht sie 6.5 TRX für jeden Transfer an einen Empfänger, der USDT hält, und 13.1 TRX an einen, der kein USDT hält, dazu dieselben Bytes. So oder so muss das fee_limit der Transaktion bis zur vollen Verbrennung reichen. Eine Wallet, die bis zur Gebühr gefüllt ist und bei der zweiten Zahl zu kurz kommt, scheitert auf eine Weise, die trotzdem TRX kostet.

Die Node nimmt das kleinere von zwei Limits

USDT zu senden ist ein Aufruf in einen Smart Contract, und bevor der Aufruf läuft, entscheidet die Node, wie viel Energie er ausgeben darf. Sie berechnet zwei Zahlen und nimmt die kleinere. Die erste ist das, was das Konto bezahlen kann: die Energie, die es bereits hält, plus so viele Einheiten, wie sein TRX zum Protokollsatz von je 100 sun kaufen würde. Die zweite ist das, was die Transaktion erlaubt: ihr fee_limit, geteilt durch dieselben 100 sun.

Daraus folgen zwei Regeln. Das TRX auf dem Konto muss die Energie decken, die der Transfer verbrennen wird, denn ein Guthaben unterhalb der Verbrennung deckelt den Aufruf unter dem, was er braucht. Und das fee_limit muss diese Verbrennung erlauben, denn ein niedriges Limit deckelt den Aufruf ebenso hart, wie viel TRX auch dahintersteht. Reicht eines von beiden nicht, bleibt der Aufruf auf halbem Weg mit OUT_OF_ENERGY stehen, und das TRX, das er unterwegs verbrannt hat, bleibt verbrannt (was dieses Ergebnis bedeutet).

Die zweite Zahl erwischt Wallets, die mieten oder staken. Die Node zählt auch die Energie, die das Konto bereits hält, gegen das fee_limit, genauso wie das TRX, das sie verbrennen würde. Eine Transaktion, die ohne fee_limit signiert wird, trägt ein Limit von null, und ein Limit von null lässt den Aufruf überhaupt keine Energie ausgeben, weder delegierte noch verbrannte. Was auch die eigene Warnung einer Wallet sagt, die Node rechnet so: Die eigene Energie des Kontos deckt den Aufruf nicht, die Node verbrennt TRX für den Rest, und der Transfer geht nur durch, wenn Guthaben und Limit beide so weit reichen.

Drei Versuche einer Wallet im Mainnet

Die fee_limit-Seite der Regel lässt sich im Mainnet beobachten. Am 6. Oktober 2026 stießen wir beim Durchgehen der öffentlichen Aufzeichnung des USDT-Vertrags auf einen Absender, der denselben Transfer dreimal in weniger als vierzig Minuten versuchte. Der Transfer brauchte 130,285 Einheiten Energie, die Zahl für einen Empfänger ohne USDT, und das Konto hatte keine eigene Energie, jede Einheit musste also durch Verbrennen von TRX gekauft werden. Jede Zeile ist der eigene Datensatz dieser Transaktion.

Der erste Versuch hielt bei genau 11,000 Einheiten an, das ist sein fee_limit geteilt durch 100 sun. Das Konto hätte mehr bezahlen können: Beim dritten Versuch bezahlte es die ganze Verbrennung, und in seiner Aufzeichnung kommt dazwischen kein TRX an. Der zweite Versuch trug kein fee_limit, und seine Quittung meldet ein Limit von null bei der ersten Anweisung des Vertrags. Er verbrauchte keine Energie, bewegte kein USDT und bezahlte trotzdem seine Bytes. Der dritte wurde mit einem fee_limit knapp über der Verbrennung signiert und ging durch.

Dieser Absender war die Ausnahme. Von 12,000 aufeinanderfolgenden USDT-Aufrufen, die wir am selben Nachmittag gezählt haben, trug jeder ein fee_limit.

Worauf das fee_limit zu setzen ist

Das fee_limit deckelt die Energie, die der Aufruf nutzen darf, gehalten oder verbrannt, und kostet von sich aus nichts. Ein Transfer, dessen Energie schon auf der Wallet liegt, verbrennt nichts davon, ein großzügiges Limit ist auf einer Wallet mit ihrer Energie also kostenlos. Der Wert, der einen Transfer nie vorzeitig stoppt, ist die größere Verbrennung, 13.1 TRX. Ein Limit von 6.5 TRX genügt nur, solange der Empfänger beim Eintreffen des Transfers noch USDT hält, und ein Empfänger mit leerem Guthaben kostet die größere Zahl, gleichgültig, ob er je USDT gehalten hat (woher die beiden Zahlen kommen). Ein Limit unter dem, was der Transfer braucht, stoppt den Aufruf selbst auf einer Wallet, die alle benötigte Energie hält, weil die Node diese Energie gegen das Limit zählt.

Wenn wir in mode B einen signierten Transfer für Sie übertragen, messen wir ihn an dieser Regel, bevor irgendeine Energie gekauft wird. Ein fee_limit, das die Energie des Transfers zum aktuellen Preis des Netzes nicht bezahlen kann, wird mit 400 invalid_request abgelehnt, wobei details.reason auf fee_limit_too_low steht. Eine Schätzung genau dieses Transfers liefert seine Verbrennung als burn_cost_trx, und ein Limit, das mindestens so hoch ist, geht immer durch.

Das Limit zählt am meisten bei einem Transfer, dessen Kosten sich ändern, nachdem er bepreist wurde. Ein Empfänger, der USDT hielt, als Sie ihn geprüft haben, und sein Guthaben bis zum Eintreffen des Transfers geleert hat, kostet die größere Zahl. Hält die Wallet Energie für die kleinere, verbrennt die Node die Differenz aus TRX. Das Guthaben muss diese Differenz decken, und das fee_limit muss die ganze größere Zahl decken, weil auch die Energie, die die Wallet hielt, dagegen zählt. Reicht eines von beiden nicht, bleibt der Transfer mit OUT_OF_ENERGY stehen, und was er unterwegs verbrannt hat, bleibt verbrannt.

Mit Energie auf der Wallet bleibt die Bandbreite übrig

Energie bezahlt den Vertragsaufruf und sonst nichts. Die Bytes der Transaktion werden getrennt gemessen, als Bandbreite (die beiden Zähler nebeneinander). Jedes Konto bekommt täglich 600 Bytes Bandbreite gratis, das deckt etwa einen USDT-Transfer. Darüber hinaus verbrennt das Netz TRX für die gesamte Bandbreite, die jeder Transaktion berechnet wird, zum Zehnfachen des Energiesatzes: Ein Byte kostet, was zehn Einheiten Energie kosten.

Einem USDT-Transfer werden einige hundert Bytes Bandbreite berechnet. Der, den wir am 2. September 2026 gesendet und gemessen haben, wurde mit 345 berechnet, die drei Versuche oben mit 339 bis 345. Sobald das freie Tageskontingent also für den ersten Transfer des Tages aufgebraucht ist, bezahlt jeder weitere Transfer seine Bytes in TRX, gleichgültig, ob seine Energie gemietet, gestakt oder verbrannt wurde. Eine Wallet, die überhaupt kein TRX hält, kann ihren ersten Transfer des Tages trotzdem auf delegierter Energie senden, wobei das freie Tageskontingent die Bytes bezahlt; der zweite braucht TRX auf dem Konto (senden, ohne TRX zu halten).

Gebühren außerhalb des Transfers

Eine sendende Wallet muss on-chain existieren, bevor Energie an sie delegiert werden kann (was Aktivierung ist), und TRX an eine Adresse zu senden, die das Netz noch nie gesehen hat, legt ihr Konto an. Zwei Kettenparameter bepreisen die Kontoanlage. Wir haben keine Adresse aktiviert, um zu sehen, ob ein solcher Transfer nur den ersten von ihnen zahlt oder beide, deshalb führt die Tabelle beide auf, und ihre Summe ist der Betrag, den man dafür vorhalten muss. Zwei weitere Parameter bepreisen ein Memo an einer Transaktion und eine Transaktion, die unter einer Multisignatur-Berechtigung signiert wird. Anders als die Aktivierung werden beide bei jeder Transaktion berechnet, die ein Memo oder eine Multisignatur-Berechtigung trägt, eine Hot Wallet, die so signiert, addiert den Parameter also zu jedem Transfer, der in der folgenden Tabelle gezählt ist. Beides haben wir nicht gesendet, und diese Zeilen geben den Parameter an und nichts Gemessenes.

Der Puffer für einen Tag Transfers

Zusammengenommen hängt das TRX, das eine sendende Wallet an einem Tag durchbringt, davon ab, woher ihre Energie kommt und, wenn sie verbrennt, an welche Art von Empfänger sie zahlt. Die Tabelle unten nimmt 345 Bytes berechnete Bandbreite je Transfer an, das auf den ersten Transfer des Tages verbrauchte freie Tageskontingent und die Parameter oben. Eine Wallet, die verbrennt, zahlt bei jedem Transfer 6.5 TRX oder 13.1 TRX für Energie und ab dem zweiten Transfer ihre Bytes. Eine Wallet mit Energie zahlt nur die Bytes.

Gemietete Energie wird von Ihrem Guthaben bei uns bezahlt, und ihr Preis je Transfer steht auf der Preisseite. Gestakte Energie kostet das TRX, das gesperrt wird, um sie zu erzeugen, und das liegt außerhalb dieser Tabelle (Staken gegen Mieten). Die Tageszahl ist das, was eine Aufladung einmal am Tag auf der Wallet lassen muss. Vor jedem einzelnen Transfer ist die Untergrenze kleiner: die Verbrennung dieses Transfers, falls er verbrennt, und seine Bytes.

Die letzte Zeile ist die Reserve für Energie, die zur kleineren Zahl gekauft wurde. Auto-refill füllt eine Wallet nach ihren Transfers wieder auf rund 131,000 Einheiten auf, genug für beide Arten von Empfängern, sodass auf einer solchen Wallet ein Empfänger, der die größere Zahl braucht, mit Energie gedeckt ist und die Reserve auf null fällt (wie Auto-refill funktioniert). Woher die Energie auch kommt, das fee_limit muss trotzdem die gesamte Energie des Transfers decken, und das sind 13.1 TRX für einen Empfänger, der beim Eintreffen des Transfers möglicherweise kein USDT hält.

Wir haben nicht gemessen, wie schnell das freie Tageskontingent im Lauf eines Tages zurückkommt; die Tabelle nimmt an, dass nur der erste Transfer des Tages darauf läuft, für eine Wallet, die ihre Transfers verteilt, sind die Bandbreitenzahlen also eine Obergrenze.

Bemessen Sie das Limit jedes Transfers nach der Verbrennung, an der die Node ihn misst: POST /v1/estimate und sein burn_cost_trx in der API-Referenz →