Blog · 7. November 2026

Eine Auszahlungs-Wallet in Energie halten: staken, je Transfer mieten oder nach jedem auffüllen

Eine Auszahlungs-Wallet auf TRON gibt bei jedem USDT-Transfer, den sie sendet, Energie aus: rund 65,000 Einheiten, wenn der Empfänger bereits USDT hält, rund 131,000, wenn er kein USDT hält. Fehlt die Energie, nimmt das Netz stattdessen TRX, zu 100 sun je Einheit, das sind 6.5 TRX oder 13.1 TRX je Transfer, und die Auszahlung wird trotzdem bestätigt, solange die Wallet dieses TRX hält und das fee_limit der Transaktion die Verbrennung erlaubt (die ganze Rechnung). Die Aufgabe einer Hot Wallet ist also, vor jedem Senden Energie bereitzuhaben, ohne dass sie jemand von Hand bestellt. Drei Muster erledigen diese Aufgabe, und jedes scheitert auf seine eigene Weise.

Ein Stake wird für den geschäftigsten Tag bemessen und jeden Tag bezahlt

TRX für Energie zu staken kauft einen Anteil an einem festen Tagespool. Das Tageskontingent einer Wallet ist ihr Stake mal TotalEnergyLimit des Netzes über TotalEnergyWeight, und am 3. September 2026 stand dieses Verhältnis bei 180,000,000,000 über 18,770,236,993: etwas unter zehn Einheiten Energie am Tag für jedes gestakte TRX. Der Divisor ist der gesamte Stake des Netzes für Energie, Ihrer eingeschlossen, die Zahl driftet also von Block zu Block (die Formel durchgerechnet).

Verbrauchte Energie kommt im Lauf der folgenden 24 Stunden allmählich zurück. Eine Wallet, die den größten Teil ihres Tages in einem Lauf am Mittag auszahlt, braucht einen Stake, der diesen Lauf deckt, und der Stake bleibt auch durch die ruhigen Stunden und die ruhigen Tage eingefroren. Auch der Ausstieg ist langsam. Im Mainnet kann heute unstaktes TRX vierzehn Tage später abgehoben werden.

Wachsen die Auszahlungen über den Stake hinaus, verbrennen die Transfers, die das Kontingent verbraucht vorfinden, TRX für den Fehlbetrag und werden, mit TRX auf der Wallet und Spielraum im fee_limit, trotzdem bestätigt. Nichts liefert einen Fehler, und das erste Zeichen ist ein Verbrennungsposten im Verlauf der Wallet (was geschieht, wenn das Limit zu niedrig ist).

Mieten je Transfer stellt vor jedes Senden eine Wartezeit

Das zweite Muster kauft Energie für jeden Transfer, wie er kommt. Eine Bestellung nennt die sendende Wallet und den Empfänger. Die API antwortet mit 202, mit der eigenen Adresse der Bestellung in Location und dem Abfrageintervall in Retry-After, und wir kaufen die Energie und beobachten sie auf der Wallet. Sobald die Delegation bestätigt ist, trägt die Bestellung send_before, und das ist das Signal für Ihren Code zu senden. Das Fenster ist die Mietdauer minus drei Sekunden: 297 Sekunden bei der Fünf-Minuten-Miete und 3,597 bei der Ein-Stunden-Miete.

Jede Auszahlung wartet daher auf einen Kauf und einen Block. Wir haben diese Wartezeit an unseren eigenen Bestellungen gemessen, bei denen der Code des Kunden sendet, vom Moment der Anlage der Bestellung bis zur letzten on-chain bestätigten Delegation, über die sechzig Tage bis zum 8. September 2026.

Dreizehn Bestellungen sind eine kleine Stichprobe, und der größte Teil davon stammt aus der Anfangszeit. Sieben kamen aus der ersten Woche echter Bestellungen, die langsamsten darunter, und die Wochen danach lagen bei drei bis vier Sekunden. Wir haben die Messung nicht an einer größeren Stichprobe wiederholt.

Ein Transfer, der gesendet wird, bevor die Energie eintrifft, verbrennt zum vollen Satz, und einer, der nach send_before gesendet wird, kann die Energie verschwunden vorfinden und genauso verbrennen. Das TRX, das er verbrennt, kommt nicht zurück. Energie, die geliefert und innerhalb des Fensters nicht genutzt wurde, schließt als expired und wird berechnet, weil sie geliefert wurde (die drei Uhren einer Miete). Eine Auszahlungswarteschlange, die nach eigenem Zeitplan sendet, muss um dieses Signal herum neu gebaut werden. Für einen im Voraus bekannten Auszahlungslauf bringt eine Sammelbestellung von bis zu 500 Transfers das Warten an einer Stelle zusammen: Die Energie für den ganzen Lauf wird zuerst gekauft, und jeder Transfer darin teilt sich ein send_before (wie ein Stapel von innen aussieht).

Eine Regel, die die Wallet nach jedem Transfer auffüllt

Das dritte Muster ist eine Regel auf der Wallet, die wir als Auto-refill verkaufen, der Fall der Hot Wallet von USDT senden, ohne TRX zu halten. Sie nimmt zwei Felder, address und daily_budget_trx, in einem Aufruf von POST /v1/auto-refill-rules. Von da an wird die Wallet nach jedem Transfer, den sie macht, wieder auf rund 131,000 Einheiten Energie gebracht. Das deckt jeden nächsten einzelnen Transfer, auch einen an eine Adresse, die kein USDT hält. Die Regel legt keine Bestellungen an: GET /v1/orders listet nur die, die Sie aufgegeben haben.

Eine Auffüllung wird danach bepreist, was der Transfer davor verbraucht hat. Hat dieser Transfer rund 65,000 Einheiten ausgegeben, wird die Auffüllung zum Satz single berechnet; hat er rund 131,000 ausgegeben, zu double. Beide Sätze stehen in GET /v1/tariff unter maintenance_price_trx. Sie sind ein eigener Preis und bewegen sich getrennt von den Mietpreisen, und berechnet wird der Satz, der gilt, wenn die Auffüllung bestätigt wird. Die erste Auffüllung einer neuen Regel ist immer double: Es gibt keinen früheren Transfer, nach dem sie sich bepreisen ließe, und die Wallet bekommt die vollen 131,000 auf einmal.

Die Berechnung wartet, bis die Energie on-chain auf der Wallet sichtbar ist; dass ein Lieferant sagt, er habe geliefert, genügt nicht. Jede Belastung kommt als Ereignis maintenance.topup mit rule_id, address, units und charged_trx und als charge-Zeile in GET /v1/ledger. Eine Wallet, die nichts sendet, bekommt keine Auffüllungen und bezahlt keine.

Wie die Auffüllung stoppt und was die Wallet dann tut

Das Tagesbudget, daily_budget_trx, wird von Ihrem verfügbaren Guthaben reserviert, wenn die Regel startet, und noch einmal zu Beginn jedes UTC-Tages, und es ist das Höchste, was die Regel an diesem Tag ausgeben kann. Auffüllungen werden aus dieser Reservierung bezogen, und was davon übrig ist, kehrt um Mitternacht UTC auf das Guthaben zurück. Das spent_today_trx der Regel zeigt, wie viel vom Tag verbraucht ist. Das Budget am Mittag zu erhöhen, fügt die Differenz der Reservierung hinzu und eröffnet keinen zweiten Tag.

Ist das Budget aufgebraucht, stoppen die Auffüllungen bis zum nächsten UTC-Tag. Sie bekommen ein Ereignis maintenance.budget_exhausted, mit spent_today_trx und daily_budget_trx darin, und die Regel bleibt active. Von da an bis Mitternacht verbrennt jeder Transfer, den die Wallet nicht in Energie bezahlen kann, TRX für den Fehlbetrag zu 100 sun je Einheit. Ein auf einen durchschnittlichen Tag bemessenes Budget reicht an einem geschäftigen nicht.

Kann Ihr Guthaben die Reservierung des nächsten Tages nicht decken, stoppt die Regel. Ihr status wird paused mit paused_reason auf insufficient_balance, und ein Ereignis maintenance.paused geht hinaus. Eine pausierte Regel nimmt nie von selbst wieder auf, und eine Einzahlung startet sie nicht neu: Sie wartet auf PATCH /v1/auto-refill-rules/{rule_id} mit {"status": "active"}, und eine Wiederaufnahme, die das Guthaben noch immer nicht decken kann, antwortet mit 402. Eine Pause, die Sie selbst setzen, trägt keinen Grund, paused_reason unterscheidet also eine Regel, die auf Geld wartet, von einer, die auf Ihre Entscheidung wartet.

Ein Budget unter dem Satz double wird mit 422 abgelehnt, mit details.reason auf budget_below_topup_price und dem Minimum in details.min_daily_budget_trx: Die erste Auffüllung ist double, und eine Regel mit kleinerem Budget ginge live und bezahlte sie nie.

Rund 131,000 Einheiten auf der Wallet decken zwei Transfers an Adressen, die USDT halten, oder einen an eine Adresse, die kein USDT hält. Ein Transfer, der gesendet wird, bevor die Auffüllung für den vorigen eingetroffen ist, kann weniger vorfinden, als er braucht, und einen Teil seines Weges, oder fast den ganzen, in TRX bezahlen. Wir haben nicht gemessen, wie bald nach einem Transfer die Auffüllung eintrifft. Eine Regel zu löschen, bevor ihre Auffüllungen gedeckt haben, was wir für diese Wallet vorausbezahlt haben, kostet den ungedeckten Teil, wobei Vorauszahlungen und Belastungen ab dem 6. November 2026 gezählt werden; eine Pause berechnet dafür nie etwas.

Ein Beispieltag, auf drei Arten

Um die drei nebeneinanderzustellen, nehmen wir eine Wallet und einen Tag: dreißig Auszahlungen an Adressen, die bereits USDT halten, und zehn an Adressen, die kein USDT halten. Die Verbrennung und der Stake sind Arithmetik des Netzes. Der Bestellpreis und die Auffüllraten sind unsere, gelesen aus GET /v1/tariff um 21:46 UTC am 27. Oktober 2026; die heutigen stehen auf der Preisseite.

Zu dieser Stunde kamen die Bestellungen auf weniger als die Auffüllungen, und das war der Normalfall. Über die dreißig Tage Stundenhistorie bis zum selben Abend änderten sich die Auffüllraten kein einziges Mal, und eine Fünf-Minuten-Bestellung für denselben Transfer kostete in den meisten Stunden weniger als ihre Auffüllung.

Was eine Auffüllung über der Bestellung kostet, kauft eine Wallet, die ihre Energie schon hat, wenn jeder Transfer hinausgeht, und eine harte Obergrenze für das, was sie an einem Tag ausgeben kann. Das Budget muss wie ein Stake den geschäftigen Tag decken, aber was ein ruhiger Tag davon übrig lässt, kehrt um Mitternacht UTC auf das Guthaben zurück. Eine Zahl aus dem Produktivbetrieb dafür, wie viele Auffüllungen eine Regel an einem Tag macht, haben wir nicht.

Stellen Sie eine Auszahlungs-Wallet mit einer Anfrage und einem Tagesbudget Ihrer Wahl so ein, dass sie sich selbst auffüllt: POST /v1/auto-refill-rules in der API-Referenz →