Blog · 4. November 2026

TRON-Transaktion pending, abgelaufen oder nicht gefunden: was jedes für einen USDT-Transfer bedeutet

TRON erzeugt alle drei Sekunden einen Block, fünf Minuten auf der Kette sind also hundert Blöcke. Ein USDT-Transfer, der danach noch als „pending“ angezeigt wird, befindet sich an einer von vier Stellen: signiert, aber nie übertragen, von einer Node angenommen, aber noch nicht in einem Block, in einem Block, der noch nicht unumkehrbar ist, oder endgültig on-chain und wartet darauf, dass die empfangende Plattform ihn gutschreibt. Zwei weitere Wörter tauchen unterwegs gern auf: ein Explorer, der den Hash nicht finden kann, und eine Node, die die Transaktion als abgelaufen bezeichnet. Jedes hat seine eigene Abhilfe, und eine der Abhilfen bezahlt, zu früh angewandt, denselben Transfer zweimal.

Jede Transaktion trägt ihre eigene Frist

Das Blockintervall ist eine Konstante des Protokolls, 3,000 Millisekunden. Die andere Zahl steckt in der Transaktion. Wenn eine Wallet einen Transfer baut, schreibt sie eine expiration-Zeit in raw_data, den Teil, der signiert wird, und jede Node prüft sie. Eine Transaktion, deren Ablaufzeit verstrichen ist, wird abgelehnt, ebenso eine, deren Ablaufzeit mehr als einen Tag nach dem Kopfblock der Node liegt. Das Wort der Node für beides ist TRANSACTION_EXPIRATION_ERROR.

Ein zweites Paar von Feldern bindet die Transaktion an einen jüngeren Block. ref_block_bytes und ref_block_hash benennen einen Block, den das Netz noch vorhält, und eine Node erinnert sich an die letzten 65,536 Blöcke, etwa 54 Stunden Kette. Eine ältere Referenz oder eine, die aus einem Testnetz stammt, bringt stattdessen TAPOS_ERROR ein. Die Uhr für beide beginnt zu laufen, wenn die Transaktion gebaut wird.

Vier Dinge, die „pending“ bedeuten kann

Signiert, nie übertragen

Eine Wallet oder ein Auszahlungsskript kann einen Transfer signieren und ihn dann nie an eine Node übergeben, nach einem Timeout oder einem Absturz zwischen Signieren und Senden. Der Transfer hat trotzdem einen Hash, denn der Hash wird aus den eigenen Bytes der Transaktion berechnet. Er ist der SHA-256 von raw_data und existiert, bevor irgendeine Node etwas gesehen hat. Ein Hash in Ihren Logs beweist, dass der Transfer gebaut wurde. Ein Explorer, der dafür „nicht gefunden“ antwortet, hat recht: Keine Node, aus der er liest, hält diese Bytes.

Von einer Node angenommen, noch nicht in einem Block

Eine Node, die eine Transaktion annimmt, antwortet sofort und hält sie in ihrem Pool ausstehender Transaktionen, bis ein Block sie trägt. Annahme und Aufnahme sind getrennte Ereignisse, und unsere eigenen Bestellstatus halten sie auseinander: In mode B, wo wir einen vom Kunden signierten Transfer übertragen, bedeutet broadcasted, dass eine Node die Transaktion angenommen hat, und sagt noch nichts über einen Block. Auf einer Kette mit drei Sekunden Blockzeit ist dieser Zustand kurz. Eine Node kann auch eine Transaktion annehmen, die nie ein Block trägt, meist weil sie aus diesem Pool verworfen wurde. Ein solcher Transfer ist für immer verloren, wenn seine Ablaufzeit verstreicht.

In einem Block, noch nicht unumkehrbar

Die neuesten Blöcke an der Spitze der Kette können noch ersetzt werden. TRON führt einen zweiten Zeiger hinter der Spitze, den zuletzt solidifizierten Block, den neuesten, den das Netz als unumkehrbar behandelt, und eine Node liefert beide. Der Abstand zwischen ihnen ist, wie lange ein Transfer in einem Block liegt, ohne endgültig zu sein. Wir haben beide Zeiger einmal von einer öffentlichen Full Node gelesen, mit zwei Aufrufen im selben Moment.

Der Abstand in Blocknummern und der Abstand in Zeitstempeln stimmen bei drei Sekunden je Block überein. Unsere Positionen in mode B erreichen confirmed erst nach der Solidifizierung, die unsere API-Referenz auf etwa eine Minute ansetzt, und die Ablesung liegt auf dieser Linie. Das ergibt die übliche Antwort darauf, wie lange ein USDT-Transfer auf TRON dauert: ein Block alle drei Sekunden und die Endgültigkeit etwa eine Minute später. Es ist eine einzelne Ablesung von einer Node. Wir haben weder gemessen, wie sich der Abstand im Lauf eines Tages bewegt, noch die Zeiten unserer eigenen Bestellungen von der Lieferung über die Übertragung bis zum Block.

Endgültig on-chain, noch nicht gutgeschrieben

Eine Börse oder ein Zahlungsdienstleister schreibt eine Einzahlung nach einer Anzahl von Blöcken gut, die er selbst festlegt. Wir kennen die Anzahl keiner Plattform und nennen keine. Lesen Sie, bevor Sie die Plattform fragen, das Ergebnis, das neben dem Transfer steht. Ein Transfer kann in einem Block stehen und trotzdem gescheitert sein, mit ausgegebener Gebühr und ohne dass Tokens bewegt wurden, und alles außer SUCCESS an dieser Stelle ist ein Fehlschlag (was OUT_OF_ENERGY bedeutet und die anderen Arten, auf die ein USDT-Transfer scheitert). Ein erfolgreicher Transfer in einem solidifizierten Block hat die Adresse des Empfängers erreicht. Was bleibt, ist die Buchführung der Plattform, und ihr Support kann sie anhand des Hashs nachverfolgen.

Was abgelaufen bedeutet und wie man erneut sendet

Nach ihrer Ablaufzeit kann eine Transaktion in keinen Block mehr gelangen. Jede Node lehnt sie ab, und dieselben signierten Bytes erneut zu übertragen, bringt nur eine weitere Ablehnung ein. Die Abhilfe ist eine neue Transaktion: den Transfer neu bauen, mit einer frischen Ablaufzeit und einem Verweis auf einen jüngeren Block, und signieren.

Der Neubau bezahlt nicht doppelt. Eine Transaktion, die kein Block getragen hat, wurde nie ausgeführt: Sie hat keine Tokens bewegt und nichts verbrannt, denn ein Transfer gibt seine Energie und sein TRX aus, während er in einem Block läuft. Sobald eine Transaktion in einem Block steht, führt keine Node sie ein zweites Mal aus. Der einzige Weg, das Geld zweimal zu senden, ist, einen Ersatz zu signieren, solange das Original noch ankommen kann. Eine Node beurteilt die Ablaufzeit nach der Zeit ihres Kopfblocks, die hinter Ihrer Uhr herhinken kann, ein in den letzten Sekunden vor der Frist erzeugter Block kann das Original also noch tragen, und eine hinterherhinkende Node oder ein Explorer zeigt das Original womöglich noch nicht an. Die Software, die das Original gebaut hat, hält es und kann raw_data.expiration lesen, in Millisekunden seit der Epoche. Warten Sie, bis der zuletzt solidifizierte Block diesen Moment überschritten hat, was in unserer Ablesung etwa eine Minute länger dauert, und fragen Sie dann eine Node per Hash. Kennt die Node die Transaktion dann immer noch nicht, kann das Original nicht mehr ankommen, und der neue Transfer ist der einzige.

Pending und abgelaufen bei einer Energiebestellung

Gemietete Energie fügt eine zweite Uhr hinzu. Wenn die Energie für eine Bestellung geliefert ist, trägt die Bestellung send_before, die Mietdauer minus drei Sekunden: 297 Sekunden bei der Fünf-Minuten-Miete und 3,597 bei der Stunde. Das Fenster wird ab der Delegation gezählt, die wir bestätigt gesehen haben, und die Mietdauer auf der Kette begann einen Block und einen Abfragezyklus davor, behandeln Sie die letzten Sekunden des Fensters also als bereits vergangen (wie lange gemietete Energie hält). Ein Transfer, der einen Block erreicht, nachdem die Energie die Wallet verlassen hat, verbrennt das TRX des Absenders zum Protokollsatz von 100 sun je Einheit, rund 6.5 TRX für einen Transfer an eine Adresse, die USDT hält.

Was beim Schließen des Fensters geschieht, hängt davon ab, wer sendet. In mode A übertragen Sie den Transfer selbst. Wir beobachten das Netz, markieren die Position als sent, wenn Ihr Transfer erscheint, und senden den Webhook order.item.sent mit seinem Hash in data.txid. Ist bis send_before kein Transfer erschienen, wird die Position expired und berechnet, weil die Energie geliefert wurde.

In mode B übergeben Sie uns eine signierte Transaktion, und wir übertragen sie, sobald die Energie eintrifft (wie mode B funktioniert). Die Position durchläuft broadcasting und broadcasted bis confirmed, Letzteres erst nach der Solidifizierung. Nach send_before übertragen wir nie: Eine Position, die wir nicht rechtzeitig gesendet haben, schließt als failed mit error: broadcast_window_missed, und die Reservierung kommt vollständig zurück. Das Fenster ist dort außerdem durch die eigene Ablaufzeit der Transaktion begrenzt, abzüglich einer Marge für die Übertragung, eine Transaktion, die mit wenig verbleibender Lebensdauer bei uns eintrifft, bekommt also ein kurzes Fenster.

Mode B prüft die Ablaufzeit auch beim Eingang. Wenn wir die Transaktion erhalten, braucht sie mindestens 180 Sekunden Restlebensdauer und höchstens 23 Stunden 59 Minuten. Eine zu weit entfernte Frist kommt als 400 invalid_request zurück, mit details.reason auf expiration_too_far, und zu wenig Lebensdauer als dasselbe 400 nur mit details.index. Beide Antworten kommen, bevor irgendeine Energie gekauft wird.

Was zu prüfen ist, der Reihe nach

1. Ob eine Node die Transaktion je angenommen hat. Die Software, die sie gesendet hat, hält die Antwort der Node, oder sie hält nichts, weil die Übertragung nie stattfand. Ein Hash entscheidet für sich allein nichts, denn er existiert vor jeder Übertragung.
2. Ob der Hash gefunden wird, in einem Explorer oder von einer Node, die per Hash gefragt wird. Wird er nicht gefunden und liegt die Ablaufzeit noch voraus, übertragen Sie dieselben signierten Bytes erneut. Hat der zuletzt solidifizierte Block die Ablaufzeit überschritten und wird der Hash immer noch nicht gefunden, bauen Sie eine neue Transaktion und signieren Sie sie.
3. Das Ergebnis neben einem gefundenen Hash. SUCCESS heißt, der Transfer ist durchgegangen. Alles andere heißt, er lief und scheiterte, und die Gebühr ist bereits ausgegeben.
4. Ob sein Block solidifiziert ist. In unserer Ablesung lag der neueste unumkehrbare Block etwa eine Minute hinter der Spitze, ein erfolgreicher Transfer, der jünger ist, wird also noch abgewickelt.
5. Die eigene Blockanzahl der empfangenden Plattform und danach ihr Support, mit dem Hash.
6. Bei einer Bestellung von uns die Position: sent mit ihrem txid in mode A, confirmed in mode B. Schloss das Fenster zuerst, zeigt mode A expired und mode B failed mit error: broadcast_window_missed. Ein expired in mode B heißt, dass eine Node die Transaktion wegen ihrer Beschaffenheit abgelehnt hat oder die Transaktion in einem Block revertiert wurde, und sie wird berechnet.

Sehen Sie zu, wie eine Position auf ready steht und dann expired wird, ohne dass etwas Reales auf dem Spiel steht: die Sandbox hat einen Empfänger, dessen Transfer nie kommt →