Blog · 7 novembre 2026

Garder un portefeuille de paiements en énergie : geler, louer par transfert ou recharger après chacun

Un portefeuille de paiements sur TRON dépense de l'énergie à chaque transfert USDT qu'il envoie : environ 65,000 unités quand le destinataire détient déjà des USDT, environ 131,000 quand il n'en détient aucun. Quand l'énergie manque, le réseau prend des TRX à la place, à 100 sun l'unité, ce qui fait 6.5 TRX ou 13.1 TRX par transfert, et le paiement se confirme quand même tant que le portefeuille détient ces TRX et que le fee_limit de la transaction permet la combustion (tout le calcul). Le travail d'un portefeuille chaud est donc d'avoir de l'énergie en place avant chaque envoi sans que personne la commande à la main. Trois schémas font ce travail, et chacun échoue à sa façon.

Un gel est dimensionné pour la journée la plus chargée et payé tous les jours

Geler des TRX pour de l'énergie achète une part d'un pool quotidien fixe. L'allocation quotidienne d'un portefeuille est son gel multiplié par TotalEnergyLimit du réseau sur TotalEnergyWeight, et le 3 septembre 2026 ce rapport valait 180,000,000,000 sur 18,770,236,993 : un peu moins de dix unités d'énergie par jour pour chaque TRX gelé. Le diviseur est tout le gel du réseau pour l'énergie, le vôtre compris, si bien que le chiffre dérive d'un bloc à l'autre (la formule déroulée).

L'énergie dépensée revient progressivement sur les 24 heures suivantes. Un portefeuille qui paie l'essentiel de sa journée en une seule série à midi a besoin d'un gel qui couvre cette série, et le gel reste immobilisé pendant les heures calmes et les jours calmes. En sortir est lent aussi. Sur le réseau principal, des TRX dégelés aujourd'hui peuvent être retirés quatorze jours plus tard.

Quand les paiements dépassent le gel, les transferts qui trouvent l'allocation dépensée brûlent des TRX pour le manque et, avec des TRX sur le portefeuille et de la marge dans le fee_limit, se confirment quand même. Rien ne renvoie d'erreur, et le premier signe est une ligne de combustion dans l'historique du portefeuille (ce qui se passe quand la limite est trop basse).

Louer par transfert met une attente devant chaque envoi

Le deuxième schéma achète l'énergie pour chaque transfert au fil de l'eau. Une commande nomme le portefeuille émetteur et le destinataire. L'API répond 202, avec l'adresse propre de la commande dans Location et l'intervalle d'interrogation dans Retry-After, et nous achetons l'énergie et la guettons sur le portefeuille. Une fois la délégation confirmée, la commande porte send_before, et c'est le signal d'envoi pour votre code. La fenêtre est la location moins trois secondes : 297 secondes sur la location de cinq minutes et 3,597 sur celle d'une heure.

Chaque paiement attend donc un achat et un bloc. Nous avons mesuré cette attente sur nos propres commandes où c'est le code du client qui envoie, du moment où la commande a été créée à la dernière délégation confirmée sur la chaîne, sur les soixante jours jusqu'au 8 septembre 2026.

Treize commandes, c'est un petit échantillon, et la plus grande partie est précoce. Sept viennent de la première semaine de commandes réelles, la plus lente parmi elles, et les semaines suivantes ont tourné à trois ou quatre secondes. Nous n'avons pas répété la mesure sur un échantillon plus grand.

Un transfert envoyé avant l'arrivée de l'énergie brûle au tarif plein, et un transfert envoyé après send_before peut trouver l'énergie partie et brûler de la même façon. Les TRX qu'il brûle ne reviennent pas. L'énergie livrée et non utilisée dans la fenêtre se ferme en expired et est facturée, parce qu'elle a été livrée (les trois horloges d'une location). Une file de paiements qui envoie à son propre rythme doit être reconstruite autour de ce signal. Pour une série de paiements connue d'avance, une seule commande groupée, jusqu'à 500 transferts, rassemble l'attente en un seul endroit : l'énergie de toute la série est achetée d'abord, et chaque transfert en partage un seul send_before (ce qu'est un lot vu de l'intérieur).

Une règle qui recharge le portefeuille après chaque transfert

Le troisième schéma est une règle sur le portefeuille, que nous vendons sous le nom d'Auto-refill, le cas du portefeuille chaud de l'envoi d'USDT sans détenir de TRX. Elle prend deux champs, address et daily_budget_trx, en un seul appel à POST /v1/auto-refill-rules. Dès lors, le portefeuille est ramené à environ 131,000 unités d'énergie après chaque transfert qu'il fait. Cela couvre n'importe quel transfert suivant, y compris vers une adresse qui ne détient aucun USDT. La règle ne crée aucune commande : GET /v1/orders ne liste que celles que vous avez passées.

Une recharge est tarifée d'après ce qu'a utilisé le transfert qui la précède. Si ce transfert a dépensé environ 65,000 unités, la recharge est facturée au tarif single ; s'il en a dépensé environ 131,000, au tarif double. Les deux tarifs sont dans GET /v1/tariff sous maintenance_price_trx. Ils sont un prix à part et bougent séparément des prix de location, et le tarif facturé est celui en vigueur quand la recharge est confirmée. La première recharge d'une nouvelle règle est toujours double : il n'y a pas de transfert antérieur d'après lequel la tarifer, et le portefeuille reçoit d'un coup les 131,000 complets.

La facturation attend que l'énergie soit visible sur le portefeuille, sur la chaîne ; qu'un fournisseur dise avoir livré ne suffit pas. Chaque débit arrive sous la forme d'un événement maintenance.topup portant rule_id, address, units et charged_trx, et d'une ligne charge dans GET /v1/ledger. Un portefeuille qui n'envoie rien ne reçoit aucune recharge et n'en paie aucune.

Comment la recharge s'arrête, et ce que fait alors le portefeuille

Le budget quotidien, daily_budget_trx, est réservé sur votre solde disponible au démarrage de la règle puis au début de chaque journée UTC, et c'est le maximum que la règle peut dépenser ce jour-là. Les recharges sont prélevées sur cette réservation, et ce qu'il en reste retourne au solde à minuit UTC. Le spent_today_trx de la règle montre quelle part du budget du jour est déjà dépensée. Relever le budget à midi ajoute la différence à la réservation et n'ouvre pas une seconde journée.

Quand le budget est dépensé, les recharges s'arrêtent jusqu'à la journée UTC suivante. Vous recevez un seul événement maintenance.budget_exhausted, avec spent_today_trx et daily_budget_trx dedans, et la règle reste active. À partir de là et jusqu'à minuit, chaque transfert que le portefeuille ne peut pas payer en énergie brûle des TRX pour le manque à 100 sun l'unité. Un budget dimensionné pour une journée moyenne s'épuise sur une journée chargée.

Quand votre solde ne peut pas couvrir la réservation du jour suivant, la règle s'arrête. Son status passe à paused avec paused_reason à insufficient_balance, et un événement maintenance.paused part. Une règle en pause ne reprend jamais d'elle-même, et un dépôt ne la relance pas : elle attend PATCH /v1/auto-refill-rules/{rule_id} avec {"status": "active"}, et une reprise que le solde ne peut toujours pas couvrir répond 402. Une pause que vous posez vous-même ne porte aucune raison : paused_reason distingue donc une règle qui attend de l'argent d'une règle qui attend votre décision.

Un budget inférieur au tarif double est refusé avec 422, details.reason à budget_below_topup_price et le minimum dans details.min_daily_budget_trx : la première recharge est double, et une règle au budget plus petit démarrerait sans jamais pouvoir la payer.

Environ 131,000 unités sur le portefeuille couvrent deux transferts vers des adresses qui détiennent des USDT, ou un seul vers une adresse qui n'en détient aucun. Un transfert envoyé avant que la recharge du précédent soit arrivée peut trouver moins que ce qu'il lui faut et payer une partie de son énergie, voire presque toute, en TRX. Nous n'avons pas mesuré en combien de temps après un transfert la recharge arrive. Supprimer une règle avant que ses recharges aient couvert ce que nous avons prépayé pour ce portefeuille coûte la part non couverte, en comptant les prépaiements et les débits à partir du 6 novembre 2026 ; une pause n'en facture jamais.

Une journée d'exemple, de trois façons

Pour mettre les trois côte à côte, prenons un portefeuille et une journée : trente paiements vers des adresses qui détiennent déjà des USDT et dix vers des adresses qui n'en détiennent aucun. La combustion et le gel relèvent de l'arithmétique du réseau. Le prix de commande et les tarifs de recharge sont les nôtres, lus dans GET /v1/tariff à 21:46 UTC le 27 octobre 2026 ; ceux d'aujourd'hui sont sur la page des tarifs.

À cette heure, les commandes revenaient moins cher que les recharges, et c'était le cas habituel. Sur les trente jours d'historique horaire jusqu'au même soir, les tarifs de recharge n'ont pas changé une seule fois, et une commande de cinq minutes pour le même transfert a coûté moins que sa recharge la plupart des heures.

Ce que coûte une recharge au-dessus de la commande achète un portefeuille qui a déjà son énergie quand chaque transfert part, et un plafond ferme sur ce qu'il peut dépenser en une journée. Le budget, comme un gel, doit couvrir la journée chargée, mais ce qu'une journée calme en laisse retourne au solde à minuit UTC. Nous n'avons aucun chiffre de production sur le nombre de recharges qu'une règle fait en une journée.

Réglez un portefeuille de paiements pour qu'il se recharge tout seul, avec une requête et un budget quotidien de votre choix : POST /v1/auto-refill-rules dans la référence de l'API →