Blog · 2. November 2026

Fünf Minuten oder eine Stunde: die Mietdauer für TRON-Energie wählen

Wir verkaufen TRON-Energie mit zwei Mietdauern, 300 Sekunden und 3,600 Sekunden. Beide liefern dieselbe Energie für denselben Transfer, und beide werden je Einheit Energie für die gesamte Mietdauer bepreist. Die Stunde lässt diese Energie länger auf der Adresse. Fünf Minuten passen zu Software, die auf das Signal hin sendet, und die zusätzliche Zeit ist es wert, bezahlt zu werden, wenn ein Mensch oder ein langer Stapel zwischen dem Eintreffen der Energie und dem Abgang des Transfers steht.

Gemietet wird eine Energiemenge für eine Laufzeit

Eine Bestellung nennt den Transfer und, wenn sie etwas anderes als die voreingestellten fünf Minuten will, eine duration_s. Die Energie ergibt sich aus dem Transfer: rund 65,000 Einheiten, wenn der Empfänger bereits USDT hält, rund 131,000, wenn er kein USDT hält. Die Mietdauer ändert diese Menge nicht. Der Preis ergibt sich aus der Mietdauer: current_price_sun ist das, was eine Einheit für die gesamte Mietdauer kostet, der Preis der Stunde ist also der Preis einer Einheit, die eine Stunde gehalten wird, ohne dass etwas mit zwölf zu multiplizieren wäre.

Bei der Stundenmiete kauft eine Bestellung für einen Transfer Energie für einen Transfer und eine Stunde, ihn zu senden. Ein Transfer verbraucht in Minute zwei dieselben Einheiten wie in Minute fünfzig, und verbrauchte Energie kommt, solange die Mietdauer läuft, kaum zurück: Die verbrauchte Energie eines Kontos fließt im Lauf des folgenden Tages zurück, und eine Stunde ist etwa ein Vierundzwanzigstel dieses Tages. Wie lange gemietete Energie hält geht diesen Tageszyklus und die beiden anderen Uhren einer Delegation durch.

Das Fenster ist die Mietdauer minus drei Sekunden

Sobald die Energie auf der sendenden Adresse bestätigt ist, trägt die Bestellung send_before. Bei der Fünf-Minuten-Miete sind das 297 Sekunden nach der Bestätigung, bei der Stunde 3,597. Die drei Sekunden sind bei jeder Mietdauer gleich, und sie sorgen nur dafür, dass das Fenster schließt, bevor die Mietdauer endet. Das Netz startet die Mietdauer mit dem Block, der die Delegation trug, wir starten das Fenster, wenn wir diese Delegation bestätigt sehen, und der Abstand zwischen beiden ist meist länger als drei Sekunden. Ein Transfer, der ganz am Ende eines der beiden Fenster gesendet wird, kann ankommen, nachdem die Energie schon nach Hause gegangen ist, und die volle Gebühr in TRX verbrennen.

Dieser Abstand ist bei beiden Mietdauern gleich groß. Bei fünf Minuten geht er von 297 Sekunden ab, bei der Stunde von 3,597, und die Regel bleibt dieselbe: Senden Sie auf den Webhook order.ready oder bei der ersten Abfrage, die send_before zeigt, und halten Sie reichlich Abstand zur Frist.

Ein Stapel teilt sich eine Frist. Sie läuft ab der letzten in der Bestellung bestätigten Delegation, und sie kann nicht später liegen, als der erste erfolgreiche Kauf es zulässt, denn Energie kann nicht vor ihrem Kauf beginnen. Wir kaufen etwa eine Position je Sekunde, und Positionen, die wir mit weniger als dreißig Sekunden Fenster erreichen, werden nicht gekauft: Sie schließen als failed mit purchase_failed, und ihre Reservierung kommt zurück. Bei der Fünf-Minuten-Miete schneidet das einen großen Stapel etwa bei seinem 269. Transfer ab. Bei der Stunde passt ein voller Stapel von 500 hinein, mit dem größten Teil des Fensters übrig.

Was eine Stunde bringt

Der schlichteste Einsatz ist eine Reihe von Transfers, die Sie innerhalb der Stunde senden werden, wenn auch nicht alle auf einmal. Ein Auszahlungslauf, der hinausgeht, wie Freigaben eintreffen, oder eine Warteschlange, die Ihr eigener Code in seinem eigenen Tempo leert, kann als ein Stapel auf der Stundenmiete bestellt werden. Die Energie für jeden Transfer landet gemeinsam auf der sendenden Wallet, und jeder Transfer geht hinaus, wenn er bereit ist. Bestellen Sie nur, was Sie senden werden. Eine Position, deren Fenster ungenutzt schließt, endet als expired und wird berechnet, weil die Energie geliefert und für das ganze Fenster gehalten wurde.

Die Stunde deckt auch ein Senden ab, das auf einen Menschen wartet. In mode A signieren und übertragen Sie den Transfer selbst, und die Bestellung sieht nie, wie er signiert wurde: Eine Hardware-Wallet und ein zweiter Freigeber passen beide. Fünf Minuten lassen wenig Platz für einen Freigeber, eine Stunde lässt reichlich. Mode B kann den zweiten Freigeber nicht tragen, weil er eine Owner-Signatur auf Permission_id 0 annimmt und Multisignatur ablehnt.

Mode B braucht die Stunde am wenigsten, selbst bei einer Transaktion, die lange im Voraus signiert wurde. Dort übergeben Sie uns einen signierten Transfer, und wir übertragen ihn im selben Durchgang, der die Energie als bereit markiert, ein einzelner Transfer gewinnt also nichts von einem längeren Fenster. Das Fenster wird außerdem von der eigenen Ablaufzeit der Transaktion begrenzt, abzüglich dreißig Sekunden. Die Stunde hilft einer Bestellung in mode B daher nur, wenn der Stapel länger als fünf Minuten zum Kaufen braucht und seine Transaktionen so signiert wurden, dass sie länger leben. Das können sie: Wir akzeptieren eine Ablaufzeit bis zu 23 Stunden 59 Minuten, nachdem die Transaktion bei uns eintrifft. Was eine TRON-Energie-API tatsächlich tut geht mode B von der Anfrage an durch.

Eine Bestellung über eine Menge (energy_units) von mehr als 131,000 Einheiten muss die Stunde nehmen. Eine solche Position wird in Teilen bei mehreren Verkäufern gekauft, und die Mietdauer jedes Teils läuft ab seiner eigenen Delegation, bei fünf Minuten würde der erste Teil also anfangen abzulaufen, während der letzte noch eintrifft. Eine kürzere Mietdauer wird mit 400 invalid_request, details.reason bulk_needs_longer_lease abgelehnt.

Was die Stunde gegenüber fünf Minuten kostete

Der größte Teil des Marktes verkauft die Stunde. Von den siebzehn Preislisten, die unsere Beobachtung am 7. September 2026 las, nannten sechzehn eine Stunde. Jede unserer beiden Mietdauern hat ihren eigenen Preis, gegen den Markt neu berechnet, keine ist also von der anderen abgeleitet. GET /v1/tariff/history zeichnet eine Mietdauer je Anfrage, und mit range=30d liefert es 720 Stundenwerte der Preise, zu denen wir verkauft haben. Wir haben beide Reihen am 27. Oktober 2026 gelesen und Stunde für Stunde verglichen.

Die Stundenmiete kostete in den meisten Stunden mehr und in einigen weniger, und über den Monat lagen die beiden dicht beieinander. Der Aufpreis wanderte von Woche zu Woche, und in einer der vier Wochen kam die Stunde günstiger heraus. Der größte Teil jenes Monats wurde nach dem früheren Tagesplan der Preise verkauft, und am 26. Oktober löste ihn ein Preis je Mietdauer ab. Die letzte Zeile beginnt an diesem Tag um 00:00 UTC, ihre ersten Stunden können also noch den Plan tragen, und zwei Tage sind zu wenig, um zu sagen, ob der Abstand hält.

Die Historie hält fest, wozu wir verkauft haben, und verspricht nichts über die nächste Stunde. Die heutigen Preise für beide Mietdauern stehen auf der Preisseite, und products[] von GET /v1/tariff liefert dieselben Zahlen. Wann TRON-Energie am günstigsten ist liest dieselbe Historie über die Stunden des Tages.

Die Mietdauer wählen

Wählen Sie nach dem Längsten, was Ihr Senden nach dem Eintreffen der Energie dauern kann. Sind es Sekunden, nehmen Sie fünf Minuten. Ist es länger, nehmen Sie die Stunde und bestellen Sie nur die Transfers, die Sie darin ausführen werden.

Lassen Sie Ihren Code die Mietdauern jedes Mal aus products[] lesen. Produkte gehen ohne Release in den Verkauf und aus ihm: Die Tagesmiete wurde am 25. Oktober 2026 aus dem Verkauf genommen, und eine Bestellung oder Schätzung, die eine nicht angebotene Mietdauer nennt, bekommt 400 invalid_request, mit den Mietdauern im Angebot in details.allowed. Die Mietdauer ist Teil des Bodys der Bestellung, ein Wiederholungsversuch unter demselben Idempotency-Key mit einer anderen duration_s wird also mit 409 idempotency_conflict abgelehnt und legt nichts an.

Eine Wallet, die den ganzen Tag sendet, passt zu keiner der beiden Mietdauern, und nichts, was länger als eine Stunde dauert, ist im Verkauf. Eine Auto-refill-Regel ist dafür gebaut: Sie nennen eine Adresse und ein Tagesbudget, und die Wallet wird nach jedem Transfer, den sie macht, wieder aufgefüllt.

Was wir nicht gemessen haben

Wir haben nicht gemessen, wie lange die Bestellungen unserer eigenen Kunden auf der Stundenmiete zwischen Lieferung und Senden warten, nichts hier sagt also, wie viel von der Stunde eine typische Bestellung nutzt. Der Abstand zwischen dem Beginn einer Mietdauer im Netz und unserem ist aus der Berechnung des Fensters abgeleitet, und wir haben ihn nicht für sich gemessen. Der Preisvergleich umfasst einen Monat, fast ganz unter dem früheren Tagesplan.

Bepreisen Sie denselben Stapel auf beiden Mietdauern, bevor Sie sich entscheiden, ohne dass etwas reserviert wird: POST /v1/estimate nimmt duration_s →