Comment fonctionne la délégation d'énergie TRON
La délégation d'énergie TRON, c'est une transaction et deux champs de compte. Une adresse qui a gelé des TRX pour l'énergie appelle delegateResource en nommant un receveur, et à partir de ce bloc, ce receveur peut dépenser une énergie qu'il n'a jamais gelée, pendant que le compte qui a gelé conserve tous les TRX qu'il a gelés. Rien n'est transféré, rien n'est approuvé du côté qui reçoit, aucune clé ne change de mains. C'est le mécanisme sur lequel repose tout le marché de la location d'énergie, et ce qui suit est lu dans les Actuator de java-tron eux-mêmes, dans des relevés en direct du réseau principal et dans deux passages transactionnels sur le testnet Nile les 3 et 4 septembre 2026.
Ce qui traverse, et ce qui reste
Les TRX gelés ne quittent jamais le compte de leur propriétaire : déléguer les déplace entre deux poches à l'intérieur de ce compte, hors du solde gelé pour l'énergie et vers un solde délégué pour l'énergie. Le TRON Power — le poids de vote — est la somme des deux poches, si bien que prêter ne coûte à celui qui a gelé ni voix ni récompenses de vote. Un compte du réseau principal ayant gelé des TRX, lu le 3 septembre 2026, le montre mieux que la source : il exprimait 3,080,000 voix tout en détenant moins de la moitié de cela en non délégué, le reste étant prêté, et le chiffre de TRON Power que le nœud donnait pour lui était les deux poches additionnées.
Le receveur obtient l'autre moitié du marché : de l'énergie, et rien d'autre. Le champ qu'une délégation écrit sur le compte qui reçoit n'entre pas dans le calcul du TRON Power, si bien qu'une énergie empruntée n'emporte aucun bulletin de vote avec elle — le receveur, dans ce même relevé, n'avait aucun chiffre de TRON Power, et le nôtre sur Nile non plus.
Ce que montre le compte qui reçoit
Deux nombres bougent. acquired_delegated_frozenV2_balance_for_energy monte du montant délégué, et la limite d'énergie du compte monte avec lui — des TRX délégués multipliés par le TotalEnergyLimit du réseau divisé par son TotalEnergyWeight, tronqué. Le 3 septembre 2026, un receveur du réseau principal détenant 31246 TRX de délégations venues de deux délégants affichait une limite d'énergie de 299,638, ce qui est exactement cette arithmétique au rapport que le réseau portait ce soir-là : 180,000,000,000 sur 18,770,236,993.
C'est là que les acheteurs d'énergie sont surpris : une délégation est libellée en TRX, pas en énergie. Le dénominateur est le poids gelé total du réseau, il bouge à chaque bloc, et un chiffre mesuré ailleurs ne voyage pas — le même gel valait environ 7.7 fois plus d'énergie sur Nile cette semaine-là que sur le réseau principal.
Le verrou, et les quatre refus
Par défaut, une délégation peut être reprise à tout instant. lock=true sur l'appel de délégation est ce qui l'empêche, et c'est la seule chose qui l'empêche. Il prend un paramètre, lock_period, compté en blocs de trois secondes — un champ qui se lit comme une durée et qui est un compte, si bien qu'en demander 300 parce qu'on voulait 300 secondes achète quinze minutes, sans un mot. Laissé à zéro ou omis, il vaut 86,400 blocs : trois jours. La borne haute est un paramètre de chaîne, et sur le réseau principal le 3 septembre 2026 elle se tenait à 864,000 blocs, soit trente jours.
Un verrou peut être prolongé et jamais écourté. Une seconde délégation vers le même receveur n'est acceptée que si sa période vaut au moins le temps qui reste à courir, et elle réinitialise alors l'échéance de tout le solde accumulé et non de la seule part nouvelle — recharger une délégation verrouillée reverrouille donc tout ce qui se trouve dessous. Tout le reste, le réseau le refuse. Ces quatre réponses sont revenues d'un nœud du réseau principal le 3 septembre 2026, contre un couple d'adresses sous un verrou de vingt-quatre heures en cours ; le nœud exécute la validation de l'Actuator pendant qu'il construit l'un ou l'autre appel, si bien que les quatre sont les réponses de l'Actuator lui-même et que rien n'a été signé ni envoyé :
- un verrou d'un bloc par-dessus celui en cours —
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!, qui nomme ce qui reste à courir, en millisecondes ; - un verrou de quatre heures par-dessus le même — le refus identique. Être plus long qu'un verrou neuf n'est pas le critère ; être plus long que ce qui reste, si ;
- un verrou d'un bloc au-delà du plafond —
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - le retrait de délégation lui-même —
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0. Pas « moins que ce que vous avez demandé » : tant que le verrou tient, un solde verrouillé ne compte pour rien du tout.
Une construction validée n'est pas un bloc, alors la même chose a été faite avec un verrou à nous. Deux passages sur Nile le 4 septembre 2026 ont posé un verrou, demandé le retrait de délégation aussitôt, attendu la fin du verrou et redemandé : refusés les deux fois par cette dernière phrase caractère pour caractère, acceptés les deux fois une fois l'échéance passée — à cinq minutes et à quatre heures. Le passage long a aussi tranché ce que compte l'unité : entre les deux transactions, l'horloge des en-têtes a avancé de 4,801 créneaux de trois secondes tandis que la hauteur de bloc avançait de 4,785, donc seize créneaux n'ont produit aucun bloc et le verrou a tout de même couru ses quatre heures. lock_period compte des créneaux de l'horloge des blocs, et non des blocs effectivement produits.
Y mettre fin, et voir qu'elle a pris fin
Le délégant appelle undelegateResource, et sans verrou en travers c'est réglé en un bloc. Ni l'un ni l'autre appel ne porte de frais au-delà de la bande passante — les deux Actuator se tarifent à zéro — et c'est pour cela que l'énergie peut se vendre à la minute. Face à un verrou en cours, il n'y a ni annulation ni frais qui achètent une sortie ; déléguer à nouveau avec lock=false n'en est pas une non plus, puisque cela écrit une ligne séparée et laisse la ligne verrouillée debout.
Le verrou est visible à un seul endroit : la ligne de délégation du couple d'adresses, où expire_time_for_energy est un horodatage en millisecondes. Une clé absente veut dire pas de verrou — c'est à cela que ressemble la délégation d'un loueur ordinaire, et les lignes d'un pool du réseau principal, lues le 3 septembre 2026, ne portaient aucune clé d'expiration. Lisez ce nombre plutôt que de le calculer : l'Actuator l'estampille depuis l'en-tête du bloc précédent, si bien qu'un calcul fait depuis le bloc de la délégation elle-même est décalé d'un bloc, et qu'un calcul fait depuis l'horodatage de la transaction est décalé d'une valeur différente à chaque fois. Les deux passages sur Nile ont retrouvé la valeur stockée à la milliseconde près sous la première règle, et sous aucune des deux autres.
Quand une délégation prend fin, les deux champs du receveur ne tombent pas à zéro — ils disparaissent de la réponse, et la ligne de délégation revient vide. Tout ce qui interroge un compte doit traiter l'absence comme un zéro, sans quoi il continuera d'afficher une énergie repartie chez son propriétaire depuis plusieurs minutes.
Pourquoi le portefeuille qui reçoit ne signe rien
Tout cela se passe du côté du délégant : le receveur est nommé dans la transaction, un champ est écrit sur son compte, et il n'y a rien à accepter, à approuver ni à connecter — ce qui est aussi la raison pour laquelle une délégation ne peut pas atteindre ce que ce portefeuille détient. Deux exigences vont dans l'autre sens : l'adresse doit déjà exister en tant que compte, et elle ne doit pas être un contrat, ce que l'Actuator refuse net. C'est ce qui rend l'énergie louable par API tout court (ce qu'est l'énergie, et d'où elle vient).
Ce que la location construit par-dessus
Un vendeur d'énergie est un compte qui a un gel et l'habitude de déléguer : il délègue à votre portefeuille émetteur pour une durée, vous dépensez l'énergie dans un transfert USDT, et il reprend la délégation. Les durées diffèrent d'un vendeur à l'autre ; la nôtre est de 300 secondes, parce qu'un transfert prend des secondes. Une commande répond avec send_before — l'instant où la fenêtre de livraison se ferme, trois secondes avant la fin de cette durée — et c'est ce champ, et non l'horloge murale, qu'il faut prendre pour repère.
Tout est visible pendant que la durée court, et c'est la partie utile d'une location sur une chaîne publique : la transaction de délégation sur le portefeuille émetteur, la limite d'énergie qui y a monté, et la ligne entre les deux adresses sur n'importe quel explorateur qui lit l'état des délégations. L'énergie est sur l'adresse ou elle n'y est pas, et ce qui est facturé, c'est le premier cas (ce que cela coûte en ce moment). Un portefeuille qui envoie toute la journée, c'est le même mécanisme mis à l'heure : une règle Auto-refill le recharge après chaque transfert au lieu de vous demander une commande.
Deux choses que nous n'avons pas mesurées, et toutes deux méritent d'être dites. La première est ce que l'activité de gel du compte qui reçoit fait à une délégation posée sur lui : si un receveur dégèle ou délègue à son tour en cours de durée, le code de l'Actuator laisse penser qu'il y a quelque chose à trouver, et nous ne l'avons pas exécuté. La seconde est la recharge : la source et TIP-542 disent l'une comme l'autre qu'une seconde délégation acceptée reverrouille tout le solde qui se trouve dessous, et nous n'en avons pas fait passer une.