Blog · 9. September 2026

OUT_OF_ENERGY: der TRON-Fehler, der die Gebühr ausgibt und nichts sendet

Ein USDT-Transfer geht raus, die Wallet zeigt eine abgezogene Gebühr, und beim Empfänger kommt nichts an. Die Transaktion steht in einem Block — sie wurde nicht abgewiesen, und keine Node war ausgefallen —, und wo ein abgeschlossener Transfer SUCCESS liest, liest dieser OUT_OF_ENERGY. Auf TRON bedeutet dieser Fehler genau das, was er sagt: Dem Aufruf ging mittendrin die Energie aus, und er stoppte. Hier ist der Mechanismus, hier sind die drei Wege, auf denen ein Auszahlungslauf hineinläuft, und die Auswege, vom schnellsten bis zu dem, der tatsächlich am wenigsten kostet.

Was das Ergebnis wirklich sagt

USDT zu senden ist ein Aufruf in einen Smart Contract, und die Ausführung eines Vertrags wird auf TRON in Energie gemessen und nicht als Pauschalgebühr berechnet (was Energie ist). Zuerst wird die eigene Energie des Absenders verbraucht. Reicht sie für den Aufruf nicht, hört das Netz dort nicht auf — es kauft den Rest, indem es das TRX des Absenders zum Protokollsatz von 100 sun für jede Einheit verbrennt, aber nur so weit, wie das fee_limit der Transaktion es zulässt. Dieses Feld ist keine Gebühr, die jemand erhebt. Es ist eine Obergrenze dafür, wie viel TRX des Absenders dieser eine Aufruf verbrennen darf.

Wird die Obergrenze erreicht und der Aufruf ist nicht fertig, hält die Ausführung an. Jede Zustandsänderung, die sie vorgenommen hatte, wird zurückgerollt, es bewegen sich also keine Token, und das Netz schreibt sein Urteil an die Stelle der Transaktion, an der ein abgeschlossener Aufruf SUCCESS trägt. Dieses Urteil ist das Wort, das ein Explorer neben einer gescheiterten Transaktion zeigt, und das Feld, das eine Node als contractRet zurückgibt. An der Transaktion hat nichts das Netz verfehlt. Sie erreichte das Netz und wurde ausgeführt, bis das Geld dafür alle war.

Das TRX ist so oder so ausgegeben

Der Rollback macht den Transfer rückgängig. Die Verbrennung macht er nicht rückgängig: Verbrauchte Energie ist bezahlte Energie, und dem Absender fehlt am Ende, was der Versuch auf dem Weg zur Obergrenze verbrannt hat, es wurden keine Token bewegt, und es bleibt ein Transaktions-Hash, den ein Abgleichsskript bereitwillig als Zahlung ablegt.

Womit die reflexhafte Wiederholung der teure Zug ist. Derselbe Transfer mit derselben Grenze gibt dasselbe TRX für dasselbe Ergebnis aus, und eine Auszahlungsschleife, die ihre Fehlschläge automatisch wiederholt, schafft das mehrfach, bevor ein Mensch die Ergebniszeichenkette liest. Die meisten Fehlschläge, die ein Auszahlungsteam trifft, kosten still Geld. Dieser kostet laut Geld und wird trotzdem übersehen, weil die Wallet eine Gebühr meldet und das Geld nirgends ist.

Warum eine Grenze, die gestern reichte, plötzlich nicht mehr reicht

Der Empfänger hat sich geändert, die Grenze nicht. Das ist der Fall, dem ein Auszahlungslauf zuerst begegnet. Ein Transfer an eine Adresse, die bereits USDT hält, braucht rund 65,000 Einheiten Energie; an eine Adresse, die nie welche gehalten hat, muss der Transfer zusätzlich das Token-Konto des Empfängers anlegen, und das sind rund 131,000 — der doppelte Appetit für denselben bewegten Betrag. Verbrennen kostet für den ersten Fall 6.5 TRX zum Protokollsatz und für den zweiten 13.1 TRX. Eine Obergrenze, die auf den gewöhnlichen Fall zugeschnitten ist, fehlt um die Hälfte, sobald zum ersten Mal ein neuer Kunde bezahlt wird, und nichts im Stapel sieht anders aus: Es ist eine Eigenschaft des Empfängers, nicht des Transfers.

Die Energie war da und ist es nicht mehr. Eine Delegation ist eine Menge auf Zeit und kein Abonnement. Was der erste Transfer verbraucht, ist für den zweiten nicht mehr da, und wenn die Frist endet, geht der Rest an seinen Eigentümer zurück. Eine Wallet, die im selben Fenster schon einmal gesendet hat, hat weniger, als die genannte Gesamtzahl der Delegation vermuten lässt, und es ist der spätere Transfer, der stoppt — was von außen aussieht wie derselbe Transfer, der zufällig scheitert.

Die Grenze ist null. Null ist der richtige Wert, wenn die Energie sicher ist, und in mode B, wo wir die Energie liefern und die Transaktion selbst senden, ist fee_limit genau das, was wir Sie bitten, nicht zu setzen: Eine Grenze wäre dort nichts als eine stehende Erlaubnis, das TRX des Absenders zu verbrennen, falls etwas schiefgeht. Sie ist zugleich ein harter Stopp. Null Erlaubnis heißt, dass ein Aufruf, dem eine einzige Einheit fehlt, anhält, statt dafür zu zahlen — eine bei null belassene Grenze ist also eine Entscheidung, die nur so lange trägt, wie die Energie trägt.

Es sehen, bevor die Transaktion signiert ist

Die Frage hinter dem ersten Auslöser — wie viel Energie kostet dieser Empfänger — ist beantwortbar, bevor irgendetwas signiert ist, mit zwei Aufrufen, die nichts reservieren und nichts belasten.

GET /v1/address-check antwortet für eine Adresse: activated, holds_usdt, blacklisted, is_contract und das expected_kind, das daraus folgt. holds_usdt ist das Feld, das die Größe des Aufrufs bestimmt.

curl -s -H "Authorization: Bearer $KEY" \
  "https://api.nrg.market/v1/address-check?address=TN3W4H6rK2ce4vX9YnFQHwKENnHjoxb3m9"
# expected_kind ist "single", "double" oder "custom"

POST /v1/estimate antwortet für einen Stapel — bis zu 500 Empfänger in einem Aufruf, jeder mit einem kind, den energy_units dahinter und etwaigen warnings. single ist der gewöhnliche Transfer und double der, der ein Token-Konto eröffnet. custom ist die Position, die keine Faustregel abdeckt: Der Empfänger entpuppt sich als Vertrag mit eigener transfer-Logik, also passt keine der beiden Standardzahlen, und energy_units kommt aus einem Dry-Run des tatsächlichen Aufrufs. Das sind die Positionen, nach denen eine Grenze einzeln bemessen wird, und die Warnung contract_recipient daneben ist oft das erste Zeichen dafür, dass eine Auszahlungsadresse gar keine Wallet ist.

Die Auswege, der einfachste zuerst

Die Grenze anheben. Ein Feld, keine Infrastruktur, und der Stopp verschwindet: Der Aufruf läuft durch, und das Netz nimmt sich, was es braucht. Die Kosten verschwinden nicht mit. Eine Grenze ist eine Erlaubnis zu verbrennen, eine großzügige Grenze ist also eine großzügige Verbrennung — der Transfer, der bisher anhielt, geht jetzt für 13.1 TRX durch. Richtig als Untergrenze unter einem Auszahlungslauf, falsch als Plan.

Energie auf den Absender bringen. Dann gibt es nichts, was die Grenze erlauben müsste. Energie kommt aus gestaktem TRX, was heißt, ein Arbeitsguthaben festzusetzen und ein Ressourcenbudget zu überwachen, oder aus einer gemieteten Delegation für die paar Minuten, die ein Transfer braucht (was das gerade kostet). So oder so ist der Aufruf in Energie bezahlt, und es wird überhaupt nichts verbrannt.

Innerhalb des Fensters senden. Gemietete Energie liegt auf Zeit auf der Wallet, und die Antwort auf eine Bestellung trägt send_before — den Moment, in dem das Lieferfenster schließt, drei Sekunden vor Ablauf der gekauften Frist. Achten Sie darauf, dass dieses Feld erscheint, und nicht auf das Wort ready: Die Bestellung ist mit der Lieferung der Energie erfüllt, completed folgt also sofort darauf. Nach send_before zu senden, setzt den Transfer in ein Netz, in dem die Energie womöglich schon nach Hause gegangen ist — genau der Fehlbetrag, um den es in diesem Beitrag geht.

Die signierte Transaktion übergeben. Mode B nimmt Ihnen das Fenster ganz ab: Sie schicken einen bereits signierten Transfer, wir halten ihn, und wir senden ihn, sobald die Energie on-chain bestätigt ist. Erreicht eine von uns gesendete Transaktion trotzdem einen Block, ohne ausgeführt zu werden, schließt die Position als failed mit transaction_reverted, und die ganze Reservierung wird freigegeben — diese Ursache wird, wie jede andere auf der Liste, nie berechnet. Lesen Sie den Namen als das, was er ist: transaction_reverted ist unser Wort für „sie erreichte einen Block und wurde nicht ausgeführt“, wie auch immer das Netz seine Ablehnung selbst benannt hat, ein OUT_OF_ENERGY und ein REVERT des Vertrags kommen also unter demselben Status an. Das TRX, das eine solche Transaktion auf dem Weg zu diesem Urteil verbrannt hat, gehört dem Absender und nicht uns — was für die Schätzung am Anfang dieses Abschnitts spricht und gegen eine Wiederholungsschleife an seinem Ende.