Blog · 29. Oktober 2026

Warum ein USDT-Transfer 65,000 Energie braucht und 131,000 für eine leere Adresse

Fragt man, wie viel Energie ein USDT-Transfer auf TRON braucht, geben alle Quellen dieselben zwei Antworten: rund 65,000 Einheiten, oder rund 131,000, wenn der Empfänger kein USDT hält. Beim Verbrennungssatz des Netzes von 100 sun je Einheit sind das die 6.5 TRX und 13.1 TRX, die Wallets als Gebühr anzeigen. Kaum jemand sagt, woher die beiden Zahlen kommen. Wir haben eine Node gefragt, und ihre eigene Buchführung teilt jede von ihnen in zwei Teile. Mehr als drei Viertel der Energie sind ein Aufschlag nach dem dynamischen Energiemodell des Netzes, und USDT zahlt ihn mit dem höchsten Faktor, den das Netz zulässt. Die zusätzlichen 66,000 für eine Adresse ohne USDT sind 15,000 Einheiten zusätzliche Arbeit, die denselben Aufschlag tragen.

Was die Node für einen Transfer meldet

Eine Node kann einen Vertragsaufruf ausführen, ohne ihn zu senden. Sie führt den Aufruf gegen ihre eigene Kopie der Kette aus und verwirft das Ergebnis nach der Antwort, sodass nichts signiert oder bezahlt wird. Am 7. September 2026 haben wir vier solche Aufrufe ausgeführt, jeder ein Transfer des kleinsten Betrags, einer Einheit oder eines Millionstels USDT, von einer Wallet, die Tausende hält, an vier Arten von Empfängern: mit oder ohne USDT, mit oder ohne Konto on-chain. Minuten später haben wir den Satz noch einmal auf anderen Adressen ausgeführt, insgesamt acht Aufrufe.

Jede Antwort trägt die Zahl, die alle zitieren, energy_used, und daneben eine zweite, energy_penalty. Beide Läufe gaben für jede Art von Empfänger dasselbe Paar:

Ob der Empfänger ein Konto hat, macht keinen Unterschied: Eine Adresse, von der das Netz noch nie gehört hat, kostet dasselbe wie eine alte mit demselben Guthaben. Das Guthaben entscheidet, und seine Grenze liegt bei null. Im zweiten Lauf bekam ein Empfänger mit einer einzigen Einheit USDT, einem Millionstel eines Tokens, die günstigere Zahl. Was das für eine Bestellung bedeutet, steht in dem Beitrag über nicht aktivierte Konten.

Am 27. Oktober 2026 haben wir zwei dieser Aufrufe wiederholt, von derselben Wallet an dieselben zwei Adressen, eine mit USDT und eine leer. Beide kamen mit demselben energy_used und demselben energy_penalty zurück wie im September, auf die Einheit genau.

Der Aufschlag und seine Parameter

Die Kette hat einen Schalter für das, was sie dynamische Energie nennt, und jeder Vertrag trägt seinen eigenen energy_factor. Drei weitere Netzparameter gehören dazu, und nach ihren Namen sind es eine Nutzungsschwelle, eine Stufe, um die der Faktor steigt, und eine Obergrenze: Ein Vertrag, der stark genutzt wird, zahlt für jeden Aufruf mehr Energie. Wir haben die Parameter am 3. September 2026 gelesen und noch einmal am 27. Oktober, als wir auch den eigenen Faktor von USDT gelesen haben. Die Parameter hatten sich zwischen den beiden Ablesungen nicht bewegt.

USDT liegt an der Obergrenze. An dem Abend, an dem wir diesen Faktor gelesen haben, meldete der Transfer an einen Halter dasselbe energy_penalty wie im September, die Septemberzahlen passen also ebenfalls zu einem Faktor von 34,000.

65,000 und 131,000 aufteilen

Lesen Sie energy_penalty als den Aufschlag und den Rest als die eigene Arbeit des Aufrufs, seine Grundkosten. Die beiden Arten von Transfer unterscheiden sich dann um 15,000 Einheiten Arbeit und 51,000 Einheiten Aufschlag:

Die Rechnung in der Differenzspalte geht genau auf: Die zusätzlichen 15,000 Einheiten Arbeit tragen 51,000 Einheiten Aufschlag, siebzehn auf je fünf, und das ist der Faktor von 34,000, in Zehntausendsteln gezählt. Die 66,000, die die beiden zitierten Zahlen trennen, sind also ein Block zusätzlicher Arbeit, mit dem Faktor von USDT aufgeschlagen.

Der Rest des Aufrufs verfehlt diesen Satz um ein wenig. Siebzehn Fünftel von 14,650 wären 49,810, und die Node meldete 49,635, das sind 175 Einheiten weniger. Der Fall mit leerem Guthaben liegt ebenfalls um 175 Einheiten niedriger, die Lücke sitzt also in der Arbeit, die beide Arten teilen. Weil 49,635 nicht siebzehn Fünftel irgendeiner ganzen Zahl ist, kann der Fehlbetrag kein Teil des Aufrufs sein, der dem Aufschlag entgeht, und der Faktor las 34,000 an dem Abend, an dem derselbe Aufruf denselben Penalty-Wert meldete. Das Muster sieht nach Rundung aus, wobei der Aufschlag auf vielen kleinen Schritten des Aufrufs einzeln berechnet wird. Das haben wir nicht am Code der Node geprüft; die Tabelle gibt also wieder, was die Node gemeldet hat, und lässt die 175 ungeklärt.

Was die zusätzlichen 15,000 Einheiten Arbeit sind

Ein USDT-Guthaben ist ein Eintrag im eigenen Speicher des Token-Vertrags, getrennt vom TRON-Konto, weshalb eine Adresse ohne Konto USDT halten kann. Ein Transfer an eine Adresse mit Guthaben überschreibt einen Eintrag, der bereits eine Zahl enthält. Ein Transfer an ein Guthaben von null schreibt in einen leeren. Die übliche Erklärung für die Lücke ist, dass ein Schreibvorgang in einen leeren Eintrag mehr kostet als ein Überschreiben, und 15,000 passen dazu. Unsere Messungen haben die Kosten erfasst, ohne diesen Grund zu prüfen; nehmen Sie ihn also als eine Erklärung, mit der die Zahlen übereinstimmen.

Wenn sie stimmt, müsste eine Adresse, die einmal USDT gehalten und alles davon weggeschickt hat, die höhere Zahl kosten, weil ihr Eintrag wieder bei null steht. Mindestens eine Seite in den Suchergebnissen sagt, dass eine solche Adresse womöglich trotzdem noch die niedrigere bekommt. Für diesen Fall haben wir keine Messung geplant, und eine der aufgezeichneten deckt ihn trotzdem ab. Ein Empfänger mit Guthaben null im ersten Lauf war als Absender aus dem Feed der USDT-Transfers herausgegriffen worden: Genau eine Woche vor der Messung hatte er etwas über vierundvierzig USDT gesendet. Er hatte also USDT gehalten und war geleert worden, und der Transfer an ihn kam auf 130,285, genau wie bei der für den Lauf erzeugten Adresse. Das ist eine Adresse, einmal gelesen.

Von 64,285 auf 65,000

Die runden Zahlen liegen knapp über den gemessenen. Unser Dienst rundet ebenso auf: Eine Bestellung wird hier für die beiden Arten von Transfer mit 65,000 oder 131,000 Einheiten bemessen, bei gemessenem Bedarf von 64,285 und 130,285. Das lässt in beiden Fällen 715 Einheiten Spielraum. Aufrunden ist die sichere Seite, denn ein Transfer, dem die Energie ausgeht, verbrennt entweder das TRX des Absenders für den Rest oder scheitert, wenn nichts verbrannt werden darf, mit bereits verbrauchter Energie (wie dieser Fehlschlag aussieht). Verbrannt statt gemietet, kommen die gemessenen Zahlen auf etwas weniger als die runden:

Beide Zahlen sind Energie allein. Ein Transfer verbraucht auch Bandbreite, einen eigenen Zähler mit einer viel kleineren Rechnung (Energie und Bandbreite nebeneinander).

Was die Zahlen bewegen würde

Der erste Hebel ist der Faktor. Er gehört zum Vertrag, und nach den Namen der Parameter steigt er mit der Nutzung des Vertrags stufenweise bis zur Obergrenze. USDT liegt jetzt an der Obergrenze, der Faktor kann von hier aus also nur halten oder sinken, es sei denn, die Obergrenze selbst wird geändert. Die Schwelle, die Stufe und die Obergrenze sind Netzparameter, die die Governance des Netzes ändern kann. An der Obergrenze macht der Aufschlag mehr als drei Viertel dessen aus, was ein USDT-Transfer verbraucht. Nach diesen Zahlen käme derselbe Transfer an einen Halter ohne ihn auf seine Grundkosten von 14,650 Einheiten.

Der zweite ist der Verbrennungssatz, getEnergyFee, 100 sun je Einheit an beiden Tagen, an denen wir ihn gelesen haben. Er bestimmt, was das Verbrennen der Energie in TRX kostet, und die Energiemenge bleibt dieselbe, wie hoch er auch ist. Das Netz hat ihn schon früher geändert, und der Leitfaden zur Gebühr zeigt die Rechnung zum heutigen Satz. Die Energieseite hat sich in den sieben Wochen zwischen unseren beiden Messreihen nicht bewegt: 64,285 und 130,285, beide Male.

Prüfen Sie, welche Zahl ein Empfänger kostet, bevor etwas signiert wird: GET /v1/address-check in der API-Referenz →