Comment louer de l'énergie TRON en toute sécurité
Une location ne vous demande qu'une chose : l'adresse où l'énergie doit se poser. Cherchez comment louer de l'énergie TRON en toute sécurité et vous tombez sur deux sortes de pages — des vendeurs, et des mises en garde contre les vendeurs — dont aucune ne tranche, parce que le test utile n'est pas de savoir si un vendeur a l'air digne de confiance, mais ce que la transaction exige réellement. Tout le reste de ce qu'un vendeur demande est une demande pour autre chose que de l'énergie.
Ce qu'une vraie location demande : une adresse
L'énergie se déplace par délégation, et une délégation est signée par le compte qui détient les TRX gelés, pas par le compte qui reçoit l'énergie. Le côté qui reçoit est passif : le réseau relève sa limite d'énergie, et l'événement s'arrête là (comment fonctionne l'énergie). La liste complète de ce dont un vendeur légitime a besoin de votre part, c'est donc l'adresse où l'énergie doit se poser.
Rien à signer. Aucune connexion de portefeuille. Aucune approbation de jeton. Aucune phrase de récupération. Aucun paiement d'« activation » pour débloquer la livraison. La seule exigence portant sur l'adresse elle-même est qu'elle existe sur la chaîne : on ne peut pas déléguer d'énergie à un compte qui n'a jamais été activé, ce qui donne dans notre API un refus — 422 invalid_address avec details.reason à inactive_wallet — plutôt qu'un débit pour une livraison qui n'aurait pas pu avoir lieu.
À quoi ressemble la délégation, vue de votre côté
La livraison n'a pas à être prise sur parole. TRON enregistre une délégation sur le compte qui reçoit autant que sur celui du délégant — les noms de champs portent encore le V2 du modèle de gel qui l'a introduite — de sorte que l'acheteur peut lire le résultat sans rien demander au vendeur.
Deux champs le disent, et chacun vient de son propre appel. acquired_delegated_frozenV2_balance_for_energy, que renvoie getaccount, est le sun gelé délégué à votre compte ; et sur un portefeuille qui n'a rien gelé en propre, l'EnergyLimit de getaccountresource est ce que cela fait en énergie — le montant acquis multiplié par le rapport propre au réseau entre la limite d'énergie totale et le poids gelé total. Là où le portefeuille gèle aussi, la part déléguée est la hausse de l'EnergyLimit et non sa totalité. Ce qu'une délégation fixe, c'est le sun ; l'énergie, non, parce que ce rapport bouge avec le gel du réseau entier, bloc après bloc.
Lue sur un compte receveur du réseau principal le 3 septembre 2026, l'arithmétique est tombée juste à l'unité : de l'énergie acquise auprès de deux délégants, et un EnergyLimit de 299,638. Le même enregistrement ne portait aucun tronPowerLimit — un receveur ne gagne aucun poids de vote par une délégation, ce qui est une façon de plus de dire que ce qui traverse, c'est l'énergie et rien d'autre.
La durée se lit au même endroit. getdelegatedresourcev2 montre une délégation verrouillée avec un expire_time_for_energy sur sa ligne ; sans verrou, cette clé n'existe pas, et le délégant peut reprendre l'énergie en un appel. Le pool d'un vendeur d'énergie lu le 4 septembre 2026 montrait exactement cela — une délégation vivante sans expiration sur la ligne, et le nœud construisant sur demande une transaction de retrait de délégation contre elle. Pas de la malhonnêteté : un bien différent, et l'enregistrement est le seul endroit qui dise lequel des deux vous avez acheté.
Les signaux d'alerte, et ce que chacun vise
- « Connectez votre portefeuille. » Une délégation n'a besoin d'aucune connexion et d'aucune session : le délégant la signe seul, et votre compte y figure comme une simple chaîne de caractères. Ce qu'un parcours de connexion achète réellement à l'autre partie, c'est la possibilité de vous mettre une transaction sous les yeux pour signature, et les deux qui valent la peine d'y être mises sont un transfert et une approbation.
- « Approuvez l'USDT pour que l'énergie puisse être livrée. » Une approbation est un appel sur le contrat du jeton qui accorde à un tiers — le spender du contrat — le droit de déplacer vos USDT, jusqu'au plafond que vous fixez et aussi longtemps qu'il tient. Elle n'a strictement aucune place dans une délégation — l'énergie arrive sur un compte qui n'a jamais rien signé. Ce n'est pas un signe avant-coureur à côté de l'arnaque ; c'est l'arnaque.
- « Envoyez des TRX à cette adresse et recevez de l'énergie gratuite. » Un paiement sans commande derrière : aucun identifiant à citer, aucune trace de ce qui a été acheté, personne qui porte une obligation. Une location a une commande qui a livré ou qui n'a pas livré, et celle qui n'a pas livré rend l'argent sans qu'on le demande.
- Un bot qui veut une clé privée ou une phrase de récupération — pour « vérifier », « activer » ou « relier » le portefeuille. Aucune étape d'aucune location n'a de place pour cela. Qui détient la clé détient les fonds, et la conversation s'arrête là.
- Un vendeur qui veut faire passer le transfert par lui. « Envoyez-nous les USDT et nous les faisons suivre dès que l'énergie arrive » relève de la garde de fonds, pas de l'énergie. Confier un transfert est un arrangement réel — c'est le mode B ici — mais ce qui est confié est une transaction que vous avez signée vous-même, nommant le destinataire et le montant, et qu'on ne peut pas modifier d'un octet sans casser la signature.
Ce qu'il faut vérifier après avoir payé
Deux faits, tous deux lisibles sur la chaîne plutôt que chez le vendeur. D'abord l'énergie : la limite d'énergie du compte qui reçoit a monté ou n'a pas monté, et cette livraison est la totalité de ce qui se vend. Ensuite la durée, c'est-à-dire combien de temps elle reste. Une délégation sans verrou est révocable à tout instant ; une délégation verrouillée ne peut même pas être écourtée par le délégant, et le réseau refuse la tentative en nommant les millisecondes qui restent à courir.
Le nôtre est un bail court à dessein : la commande porte send_before, à 297 secondes de la dernière délégation confirmée, et une estimation renvoie en écho le bail qu'elle a tarifé, dans duration_s. C'est une fenêtre courte qui rend l'énergie assez bon marché pour être louée au transfert.
Ce qu'un vendeur peut promettre, et ce qu'il ne peut pas
Un vendeur honnête promet la livraison de l'énergie. Il ne peut pas promettre que votre transfert réussira, parce que les raisons pour lesquelles un transfert USDT échoue sont des propriétés des adresses et non de l'énergie : un destinataire gelé dans le contrat du jeton, un expéditeur qui ne détient pas ce qu'il essaie de déplacer, un contrat qui annule tout (ce qu'un service de paiements rencontre vraiment).
Nos statuts sont écrits pour tenir les deux choses séparées. completed veut dire que l'énergie a été livrée, et en mode A cela peut arriver avant que vous ayez envoyé quoi que ce soit. expired veut dire qu'elle a été livrée, tenue toute la fenêtre et non utilisée — débitée, parce qu'elle a été livrée. failed veut dire qu'elle n'a pas été livrée de notre fait, et alors rien n'est débité. Lequel de ces statuts libère de l'argent, c'est toute la politique de remboursement, et un vendeur qui refuse d'énoncer le même partage à l'avance mérite une question de plus avant que l'argent bouge.
Les crédits prépayés, et ce que fait une livraison échouée
L'argent ici, ce sont des crédits de service prépayés, libellés en TRX. Créer une commande réserve le prix ; le débit tombe quand l'énergie est visible sur la chaîne, pas quand un fournisseur dit l'avoir envoyée. Une livraison qui échoue libère la réservation en entier, automatiquement, sans aucun ticket à ouvrir, et un lot mixte se solde ligne par ligne en partially_completed — débité pour les positions arrivées, libéré pour le reste (comment cela se lit sur une facture).
Les questions qu'on nous pose vraiment
Une délégation peut-elle vider le portefeuille où elle se pose ?
Non — et vous n'avez pas à le croire sur parole : le compte qui reçoit gagne acquired_delegated_frozenV2_balance_for_energy et n'accorde rien en retour, et c'est tout ce que montre l'enregistrement.
Faut-il des TRX sur le portefeuille pour recevoir de l'énergie ?
Non, et une délégation ne touche au solde dans aucun sens. Le portefeuille doit en revanche exister sur la chaîne : une adresse qui n'a jamais été activée n'est pas encore un compte, et il n'y a donc aucun compte à qui déléguer.
Comment savoir si un prix annoncé est réel ?
Lisez-le sur un endpoint plutôt que sur une page écrite il y a des mois. Le nôtre est sur la page des tarifs, en direct à chaque chargement ; la page du marché montre ce que les vendeurs que nous surveillons publient sur eux-mêmes, chaque relevé horodaté de l'instant où il a été pris. Un prix que personne ne peut aller chercher est une affirmation et non une offre (d'autres questions d'intégrateurs).