Blog · 8. November 2026

Eine TRON-Quittung lesen: verbrauchte Energie, Energiegebühr, Bandbreite und das Ergebnis

Die Transaktionsseite eines Block-Explorers zeigt einen USDT-Transfer als ein Wort, eine Gebühr und einige Ressourcenzahlen. Eine Node liefert die Quittung derselben Transaktion von gettransactioninfobyid, mit einem Namen an jeder Zahl: energy_usage, energy_usage_total, origin_energy_usage, energy_penalty_total, energy_fee, net_usage, net_fee und result. energy_fee ist das TRX, das für Energie verbrannt wird, die das Konto nicht hatte, zu 100 sun je Einheit, net_fee ist das für Bytes verbrannte TRX, und bei jeder Quittung in diesem Beitrag ist die fee der obersten Ebene die Summe der beiden. Wir bewahren Mainnet-Quittungen für jeden lesenswerten Fall auf: einen Transfer auf gemieteter Energie, einen in TRX bezahlten, Aufrufe, bei denen der Vertrag einen Teil der Energie bezahlte, und Transfers, die bei OUT_OF_ENERGY oder REVERT stoppten.

Ein fehlendes Feld bedeutet null

Eine Quittung lässt jedes Feld weg, dessen Wert null ist. Ein Transfer, der kein TRX für Energie verbrannt hat, hat kein energy_fee, und einer, dessen Bytes nichts kosteten, hat kein net_fee. Die Beträge, energy_fee, net_fee und die fee der obersten Ebene, stehen in sun, einem Millionstel TRX.

Ein Transfer auf gemieteter Energie, einer in TRX bezahlt

Beide Transfers unten verbrauchten 130,285 Einheiten, die Zahl für einen Empfänger ohne USDT-Guthaben. Der erste ist unserer: Am 2. September 2026 haben wir Energie von JustLend DAO an eine zweite Wallet gemietet und von ihr ein USDT gesendet (was diese Bestellung kostete). Der zweite stammt von einem anderen Absender, vom 6. Oktober 2026, ohne Energie auf dem Konto. Wir haben ihn aus der Transaktionsliste des Absenders gelesen, die dieselben Felder flach neben die Transaktion schreibt, Nullen eingeschlossen, und energy_penalty_total weglässt.

energy_usage_total ist das, was der Aufruf verbraucht hat. energy_usage ist der Teil, den der Absender aus Energie bezahlte, die er schon hatte, gestakt oder delegiert, und energy_fee ist der Rest, gekauft durch Verbrennen von TRX zu 100 sun je Einheit. Bei unserem Transfer sind die ersten beiden gleich und das dritte fehlt, die Delegation hat also jede Einheit bezahlt. Der andere Absender hatte keine Energie, und 13,028,500 sun gingen auf 130,285 Einheiten, genau 100 sun je Einheit.

Die Bandbreitenzeilen stimmen überein. Keines der Konten deckte die Bytes aus eigener Bandbreite, also zahlte jedes 345,000 sun: 345 Bytes zu 1,000 sun je Byte, dem Satz in den Kettenparametern, die wir am 2. September 2026 gelesen haben.

Wenn der Vertrag einen Teil der Energie bezahlt

Der Deployer eines Vertrags kann einen Teil der Energie jedes Aufrufs in ihn übernehmen. Die Quittung trägt dann origin_energy_usage, den Teil des Deployers. Der Aufrufer bezahlt den Rest so, wie ein Transfer bezahlt wird, zuerst aus eigener Energie und dann durch Verbrennen. Der Energiemarkt von JustLend DAO setzt den Anteil des Aufrufers auf ein Zehntel (consume_user_resource_percent ist 10), und bei allen 83 seiner Quittungen in unserer Stichprobe ist der Teil des Aufrufers gleich energy_usage plus ein Hundertstel von energy_fee.

Der zweite Aufrufer hatte 24 Einheiten eigene Energie und verbrannte 739,000 sun für die anderen 7,390. Unser Mietaufruf hat kein fee, obwohl er dem Vertrag eine Vorauszahlung schickte: Dieses Geld reist als Wert des Aufrufs, und fee zählt nur, was das Netz genommen hat (wohin die Vorauszahlung ging). Keine der USDT-Quittungen in diesem Beitrag trägt ein origin_energy_usage: Bei jeder ergeben die eigene Energie des Absenders und seine Verbrennung zusammen die gesamte Summe.

Ein fehlendes origin_energy_usage heißt, dass der Deployer nichts bezahlt hat und der Aufrufer den ganzen Aufruf bezahlt hat. Das ist der teuerste Fall, und er sieht genau aus wie ein Feld, das niemand gefüllt hat. Der Anteil des Deployers kommt aus der eigenen Energie des Deployers, und nur solange welche übrig ist. Am selben Nachmittag, weniger als drei Stunden vor unserer Miete, trug der Mietaufruf eines anderen Mieters auf demselben Markt kein origin_energy_usage und bezahlte alle 52,672 Einheiten selbst, 51,492 davon verbrannt.

Bandbreite: net_usage gegen net_fee

Bandbreite wird in Bytes der signierten Transaktion gemessen (Energie und Bandbreite nebeneinander). net_usage zählt die Bytes, die ein Konto aus eigener Bandbreite deckte, dem freien Tageskontingent oder einem Bandbreiten-Stake. net_fee ist das, was es in TRX für Bytes bezahlte, die es nicht decken konnte. In jeder Quittung, die wir haben, ist es das eine oder das andere.

Unsere JustLend-Bestellung zeigt beides. Der Mietaufruf oben hat net_usage 383 und kein net_fee: Die freie Bandbreite der Wallet deckte ihn. Unser eigener Rückgabeaufruf, von derselben Wallet 144 Sekunden später und nicht in der Tabelle oben, hat kein net_usage und ein net_fee von 378,000 sun. Das freie Kontingent beträgt 600 am Tag nach getFreeNetLimit der Kette, und was die Miete davon übrig ließ, deckte die Rückgabe nicht. Von den 83 JustLend-Quittungen in unserer Stichprobe zahlten 29 für ihre Bytes, jede zu 1,000 sun je Byte.

Was das Ergebniswort entscheidet

Das Wort steht zweimal in einer Quittung. Eine gescheiterte Quittung trägt ein result der obersten Ebene von FAILED, was auch immer schiefging, mit einer resMessage in Hex. Die Ursache steht eine Ebene tiefer, in receipt.result: SUCCESS, OUT_OF_ENERGY oder REVERT. Eine erfolgreiche Quittung hat überhaupt kein result der obersten Ebene, ein Skript, das nur das äußere Feld liest, legt also jeden Fehlschlag unter einem Namen ab.

Drei Datensätze von einer Wallet am 6. Oktober 2026 zeigen, wie OUT_OF_ENERGY zustande kommt. Es ist ein Transfer, dreimal signiert, aus der Transaktionsliste gelesen, weil fee_limit zur signierten Transaktion gehört. Der dritte ist der in TRX bezahlte Transfer aus der ersten Tabelle.

Der erste Versuch hielt bei genau 11,000 Einheiten an, seinem fee_limit geteilt durch 100 sun: Eine Node deckelt die Energie eines Aufrufs bei fee_limit über dem Energiepreis, was auch immer das Konto hält. Der zweite trug kein fee_limit, das als null zählt, er konnte also überhaupt keine Energie ausgeben. Seine Quittung hat keine Energiefelder, und seine resMessage dekodiert zu „Not enough energy for 'PUSH1' operation executing: curInvokeEnergyLimit[0], …“. Drei Minuten später bezahlte dasselbe Konto den dritten Versuch, es war also nicht leer. Delegierte Energie fällt unter denselben Deckel, weshalb unsere API einen Transfer in mode B, der ohne genug fee_limit signiert wurde, mit fee_limit_too_low ablehnt, bevor wir Energie kaufen.

Zwei weitere USDT-Transfers aus denselben wenigen Minuten zeigen beide Fehlerwörter, jeder FAILED auf der obersten Ebene.

Der erste Absender hatte 44,165 Einheiten eigene Energie, verbrannte TRX für 13,834 weitere und war bei 57,999 am Ende, bei allem, was seine Energie und sein TRX zusammen kaufen konnten. Sein signiertes fee_limit erlaubte 350,000 Einheiten, diesmal war also das Konto die Grenze. Beim zweiten lehnte der Vertrag den Transfer ab: Die resMessage lautet „REVERT opcode executed“, und USDT nennt keinen Grund, wenn es zurückrollt. Unsere API-Referenz nennt zwei Ursachen: einen Absender, der den Betrag nicht mehr hält, und einen, der vom Herausgeber des Tokens eingefroren wurde (die Fehlschläge, die Auszahlungs-Desks treffen).

Nur eine SUCCESS-Quittung hält fest, dass Tokens bewegt wurden: Ihr log enthält das Transfer-Ereignis des Tokens, wie das unseres gemieteten Transfers. Die Quittungen OUT_OF_ENERGY und REVERT tragen kein Log, weil keine Tokens bewegt wurden. Ihre Gebühr ist trotzdem ausgegeben, da das, was der Aufruf vor dem Stopp verbraucht hat, bezahlt bleibt (warum das TRX nach OUT_OF_ENERGY weg ist).

Wenn wir in mode B den signierten Transfer eines Kunden übertragen, entscheidet die Quittung auch, wer die Energie bezahlt. Eine OUT_OF_ENERGY-Quittung, die weniger ausgab als der Bedarf des Transfers, 64,285 Einheiten an eine Adresse mit USDT oder 130,285 an eine ohne, heißt, dass unsere Energie beim Lauf des Aufrufs nicht auf der Adresse war. Die Position schließt als expired, und wir berechnen sie, außer unsere Aufzeichnungen zeigen, dass der Verkäufer die Delegation vor dem Block des Transfers zurückgenommen hat oder dass ein anderer Ihrer Transfers von derselben Adresse die Energie verbraucht hat. Dann geht der Fehlbetrag zu unseren Lasten, ebenso wie wenn eine Quittung mindestens den Bedarf ausgab und trotzdem ausging, weil unsere Schätzung zu knapp war: Die Position schließt als failed, und wir geben die Reservierung zurück. Eine Quittung, die wir haben, verbrauchte 108,047 Einheiten und stoppte trotzdem: Bei einem Transfer, den wir für einen Empfänger mit USDT bemessen hatten, ginge dieser Fehlbetrag zu unseren Lasten. Auch einen REVERT berechnen wir.

Die Penalty ist Teil der Summe

Bei unserem gemieteten Transfer beträgt die Summe 130,285 Einheiten, die Wallet zog genau 130,285 aus ihrer Delegation, und 100,635 dieser Einheiten tragen das Penalty-Label. Die gescheiterten Transfers stimmen überein: Energie vom Konto plus verbrannte Energie ergibt die Summe, Penalty eingeschlossen.

Die Werte, die wir haben, sind 100,635 bei einem abgeschlossenen Transfer an eine Adresse ohne USDT, 25,905 bei zwei Transfers, denen die Energie ausging, und 6,640 bei dem, den der Vertrag abgelehnt hat. Der Dry-Run eines Transfers auf einer Node meldet ein passendes energy_penalty: 100,635 neben 130,285 für einen Empfänger ohne USDT und 49,635 neben 64,285 für einen, der USDT hält. Die Kettenparameter, die wir am 2. September 2026 gelesen haben, haben dynamische Energie eingeschaltet (getAllowDynamicEnergy ist 1), und der Name passt zu einer Penalty, die mit dem kostspieligeren Empfänger wächst. Die Arithmetik der Node haben wir nicht gegen diese Parameter geprüft, was die Penalty berechnet, ist hier also weiter ungemessen.

Eine Miete an ihrer Quittung prüfen

Nach dem Mieten von Energie sagen zwei Felder der Quittung des Transfers, ob die Miete ihre Aufgabe erfüllt hat: energy_fee fehlt, und energy_usage, plus ein etwaiges origin_energy_usage, ist gleich energy_usage_total. Ein energy_fee bei einem Transfer, für den Sie gemietet haben, heißt, dass ein Teil seiner Energie doch mit TRX gekauft wurde. Die Delegation war kleiner als der Aufruf, war beim Lauf des Aufrufs nicht eingetroffen, war schon zurückgenommen oder wurde zuerst von einem anderen Transfer derselben Wallet verbraucht (wie eine Delegation beginnt und endet). Das Konto selbst lässt sich vor dem Senden lesen (So mieten Sie TRON-Energie sicher).

Übergeben Sie uns den signierten Transfer in mode B, und die Quittung zu lesen wird unsere Aufgabe, Position für Position: jeder Grund, mit dem eine Position schließen kann, in der API-Referenz →