Blog · 2 novembre 2026

Cinq minutes ou une heure : choisir une location d'énergie TRON

Nous vendons l'énergie TRON sur deux locations, 300 secondes et 3,600 secondes. Les deux livrent la même énergie pour le même transfert, et les deux sont tarifées par unité d'énergie pour toute la location. L'heure laisse cette énergie plus longtemps sur l'adresse. Cinq minutes conviennent à un logiciel qui envoie dès le signal, et le temps supplémentaire vaut d'être payé quand une personne ou un long lot se tient entre l'arrivée de l'énergie et le départ du transfert.

Une location, c'est une quantité d'énergie et une durée

Une commande nomme le transfert et, si elle veut autre chose que les cinq minutes par défaut, un duration_s. L'énergie découle du transfert : environ 65,000 unités quand le destinataire détient déjà des USDT, environ 131,000 quand il n'en détient pas. La location ne change pas cette quantité. Le prix découle de la location : current_price_sun est ce que coûte une unité pour toute la durée, si bien que le prix de l'heure est le prix d'une unité tenue une heure, sans rien à multiplier par douze.

Sur la location d'une heure, une commande pour un transfert achète l'énergie d'un transfert et une heure pour l'envoyer. Un transfert dépense les mêmes unités à la deuxième minute qu'à la cinquantième, et l'énergie dépensée ne revient presque pas tant que la location court : l'énergie utilisée d'un compte se résorbe sur la journée suivante, et une heure vaut environ un vingt-quatrième de cette journée. Combien de temps dure l'énergie louée passe en revue ce cycle quotidien et les deux autres horloges d'une délégation.

La fenêtre, c'est la location moins trois secondes

Une fois l'énergie confirmée sur l'adresse émettrice, la commande porte send_before. Sur la location de cinq minutes, c'est 297 secondes après la confirmation, sur l'heure 3,597. Les trois secondes sont les mêmes sur chaque location, et tout ce qu'elles font est de faire fermer la fenêtre avant la location. Le réseau démarre la location au bloc qui a porté la délégation, nous démarrons la fenêtre quand nous voyons cette délégation confirmée, et l'écart entre les deux est d'ordinaire plus long que trois secondes. Un transfert envoyé tout à la fin de l'une ou l'autre fenêtre peut arriver après que l'énergie est repartie chez son propriétaire et brûler la totalité des frais en TRX.

Cet écart a la même taille sur les deux locations. Sur cinq minutes, il se prélève sur 297 secondes, sur l'heure sur 3,597, et la règle reste la même : envoyez sur le webhook order.ready ou à la première interrogation qui montre send_before, et gardez une bonne distance avec l'échéance.

Un lot partage une seule échéance. Elle court à partir de la dernière délégation confirmée de la commande, et elle ne peut pas tomber plus tard que ne le permet le premier achat réussi, puisque l'énergie ne peut pas démarrer avant d'avoir été achetée. Nous achetons à raison d'environ une seconde par position, et les positions que nous atteignons avec moins de trente secondes de fenêtre restantes ne sont pas achetées : elles se ferment en failed avec purchase_failed, et leur réservation est rendue. Sur la location de cinq minutes, cela coupe un gros lot à peu près à son 269e transfert. Sur l'heure, un lot complet de 500 tient avec l'essentiel de la fenêtre en réserve.

Ce qu'achète une heure

L'usage le plus simple est un ensemble de transferts que vous enverrez dans l'heure, mais pas tous d'un coup. Une série de paiements qui part au fil des validations, ou une file que votre propre code vide à son rythme, peut être commandée comme un seul lot sur la location d'une heure. L'énergie de tous les transferts arrive ensemble sur le portefeuille émetteur, et chaque transfert part quand il est prêt. Ne commandez que ce que vous enverrez. Une position dont la fenêtre se ferme inutilisée finit expired et est facturée, parce que l'énergie a été livrée et tenue pendant toute la fenêtre.

L'heure couvre aussi un envoi qui attend une personne. En mode A, vous signez et diffusez le transfert vous-même, et la commande ne voit jamais comment il a été signé : un portefeuille matériel et un second approbateur y trouvent tous deux leur place. Cinq minutes laissent peu de marge à un approbateur, une heure en laisse beaucoup. Le mode B ne peut pas porter le second approbateur, car il accepte une seule signature du propriétaire sur Permission_id 0 et refuse la multisignature.

Le mode B a le moins besoin de l'heure, même pour une transaction signée bien à l'avance. Là, vous nous remettez un transfert signé, et nous le diffusons dans le même passage qui marque l'énergie prête : un transfert isolé ne gagne donc rien à une fenêtre plus longue. La fenêtre est aussi plafonnée par l'expiration propre de la transaction, moins trente secondes. L'heure n'aide donc une commande en mode B que lorsque le lot met plus de cinq minutes à s'acheter et que ses transactions ont été signées pour vivre plus longtemps que cela. Elles peuvent l'être : nous acceptons une expiration allant jusqu'à 23 heures 59 minutes après que la transaction nous parvient. Ce que fait vraiment une API d'énergie TRON parcourt le mode B à partir de la requête.

Une commande pour un volume (energy_units) au-delà de 131,000 unités doit prendre l'heure. Une telle position est achetée en morceaux auprès de plusieurs vendeurs, et la location de chaque morceau court à partir de sa propre délégation : sur cinq minutes, le premier morceau commencerait à expirer alors que le dernier arriverait encore. Une location plus courte est refusée avec 400 invalid_request, details.reason bulk_needs_longer_lease.

Ce que l'heure a coûté face aux cinq minutes

La plupart du marché vend l'heure. Sur les dix-sept listes de prix que notre veille a relevées le 7 septembre 2026, seize cotaient une heure. Chacune de nos deux locations a son propre prix, recalculé face au marché, si bien qu'aucune n'est dérivée de l'autre. GET /v1/tariff/history trace une location par requête, et avec range=30d il renvoie 720 points horaires de ce à quoi nous avons vendu. Nous avons lu les deux séries le 27 octobre 2026 et les avons comparées heure par heure.

La location d'une heure a coûté plus cher la plupart des heures et moins cher à certaines, et sur le mois les deux sont ressorties proches. Le surcoût a varié d'une semaine à l'autre, et sur l'une des quatre semaines l'heure est ressortie moins chère. L'essentiel de ce mois a été vendu sous l'ancienne grille de prix quotidienne, et un seul prix par location l'a remplacée le 26 octobre. La dernière ligne commence à 00:00 UTC ce jour-là, si bien que ses premières heures peuvent encore porter la grille, et deux jours sont trop peu pour dire si l'écart tiendra.

L'historique enregistre ce à quoi nous avons vendu et ne promet rien pour l'heure suivante. Les prix du jour des deux locations sont sur la page des tarifs, et products[] de GET /v1/tariff renvoie les mêmes chiffres. Quand l'énergie TRON est la moins chère lit ce même historique à travers les heures de la journée.

Choisir une location

Choisissez d'après le plus long délai que votre envoi peut prendre après l'arrivée de l'énergie. Si ce sont des secondes, prenez cinq minutes. Si c'est plus long, prenez l'heure, et ne commandez que les transferts que vous ferez dedans.

Faites lire les locations à votre code depuis products[] à chaque fois. Les produits entrent et sortent de la vente sans nouvelle version : la location d'un jour est sortie de la vente le 25 octobre 2026, et une commande ou une estimation qui nomme une location qui n'est pas en vente reçoit 400 invalid_request, avec les locations en vente dans details.allowed. La location fait partie du corps de la commande : un nouvel essai sous la même clé d'idempotence avec un duration_s différent est donc refusé avec 409 idempotency_conflict et ne crée rien.

Un portefeuille qui envoie toute la journée ne s'accorde à aucune des deux locations, et rien de plus long qu'une heure n'est en vente. Une règle Auto-refill est faite pour lui : vous donnez une adresse et un budget quotidien, et le portefeuille est rechargé après chaque transfert qu'il fait.

Ce que nous n'avons pas mesuré

Nous n'avons pas mesuré combien de temps les commandes sur la location d'une heure de nos propres clients attendent entre la livraison et l'envoi : rien ici ne dit donc quelle part de l'heure utilise une commande type. L'écart entre le début d'une location pour le réseau et le nôtre est déduit de la façon dont la fenêtre est calculée, et nous ne l'avons pas chronométré isolément. La comparaison des prix couvre un mois, presque entièrement sous l'ancienne grille quotidienne.

Chiffrez le même lot sur les deux locations avant de choisir, sans rien réserver : POST /v1/estimate accepte duration_s →