Frais de transfert TRC-20 décortiqués : énergie, bandwidth et ce qui est réellement facturé

Deux ressources, une transaction

Chaque transfert TRC-20 sur TRON consomme deux ressources distinctes : bandwidth et energy. Elles sont facturées séparément, puisées dans des pools séparés et possèdent des mécaniques de réapprovisionnement complètement différentes. La plupart des développeurs comprennent l'une ou l'autre, mais c'est l'interaction entre les deux qui détermine si les coûts restent maîtrisés ou explosent.

Le bandwidth couvre le coût en octets bruts de la diffusion d'une transaction sur le réseau. L'énergie couvre le coût d'exécution VM de la logique du smart contract. Un simple transfert TRX n'a besoin que de bandwidth. Un transfert TRC-20, qui déclenche la fonction transfer(address,uint256) du contrat du token, a besoin des deux.

Bandwidth : la moitié la plus simple

Chaque compte TRON reçoit 600 bandwidth gratuit par jour grâce à une allocation de base. Une transaction de transfert TRC-20 standard fait typiquement environ 345 octets, ce qui correspond à environ 345 unités de bandwidth (le réseau facture 1 bandwidth par octet de données de transaction, signatures et champs de mémo compris).

Si votre compte dispose d'assez de bandwidth gratuit quotidien ou de TRX staké pour le bandwidth, la transaction ne coûte rien sur cette dimension. Si le pool de bandwidth est vide, le réseau consomme du TRX directement au taux de 0.001 TRX par unité de bandwidth (1000 SUN par octet). Pour une transaction de 345 unités, cela représente 0.345 TRX consommé depuis l'adresse expéditrice, sans staking requis.

Les 600 unités gratuites quotidiennes se réinitialisent à 00h00 UTC. Si vous effectuez des transferts à faible volume, vous atteindrez rarement les coûts en bandwidth. Les expéditeurs à fort volume stakent typiquement du TRX pour le bandwidth plutôt que de consommer, puisque le rendement de staking couvre plus de transactions par TRX que le taux de consommation.

Energy : là où réside le vrai coût

Un transfert USDT TRC-20 consomme environ 65,000 energy. Ce chiffre provient de l'exécution du bytecode compatible EVM à l'intérieur de la TRON Virtual Machine : lectures et écritures de stockage sur le mapping de soldes du contrat, émission de l'évènement pour le log Transfer, et vérifications de sécurité internes. La valeur exacte peut varier légèrement selon que les emplacements de stockage sont écrits pour la première fois (cold) ou mis à jour (warm), mais 65,000 est la valeur standard pour un transfert USDT typique entre deux adresses actives. Un transfert vers un destinataire dont le solde USDT est actuellement à zéro double approximativement à environ 130,000 energy parce qu'un nouvel emplacement de stockage est alloué.

L'énergie a deux sources : votre propre TRX staké, ou de l'énergie louée (déléguée) par un tiers. Staker du TRX vous donne une part proportionnelle du pool total d'énergie du réseau, et le pool se régénère linéairement jusqu'à 100% sur 24 heures. Le ratio exact d'énergie par TRX staké dépend du montant total staké à l'échelle du réseau et évolue dans le temps. Récupérer 65,000 energy depuis votre propre staking seul nécessite un montant important de TRX immobilisé, c'est pourquoi la location d'énergie existe.

Ce qui se passe quand l'énergie est épuisée

Si une transaction a besoin de 65,000 energy et que votre compte n'en dispose pas assez, le réseau ne traite pas silencieusement une exécution partielle. Il vérifie le fee_limit de la transaction et consomme du TRX prélevé sur votre compte, dans la limite de ce plafond, pour couvrir le déficit énergétique, puis exécute la transaction complète. Si le déficit dépasse votre fee_limit, la transaction échoue avant qu'aucun changement d'état ne soit validé.

C'est le scénario que vous voulez éviter : payer à la fois pour votre énergie stakée et pour du TRX consommé par-dessus, ou pire, voir la transaction échouer purement et simplement parce que fee_limit était trop bas. Vous pouvez consulter le coût actuel en TRX pour couvrir 65,000 energy sur la page des tarifs avant d'arrêter une stratégie.

Stake 2.0 a changé le fonctionnement de la délégation

Avant Stake 2.0 (activé sur le mainnet en avril 2023), staking et délégation étaient imbriqués : le propriétaire de ressource appelait freezeBalance et spécifiait directement une adresse destinataire, le freeze était lié à ce destinataire, et le modèle n'avait pas la flexibilité requise pour des marchés de ressources.

Stake 2.0 a introduit freezeBalanceV2 et séparé l'action de staking de l'action de délégation. Vous stakez désormais du TRX dans un pool personnel d'énergie ou de bandwidth, puis vous déléguez cette ressource séparément via delegateResource. Cela signifie :

• Les délégations sont révocables par défaut et peuvent être réassignées sans déstaker. Il existe un drapeau optionnel lock : le passer à true maintient la délégation pendant au moins la période de verrouillage minimale du réseau (actuellement 3d). Sans ce drapeau, vous pouvez récupérer la délégation à tout moment.
• La période d'attente de déblocage de 14 jours s'applique au TRX staké sous-jacent lorsque vous le retirez, pas à la délégation elle-même.
• Les plateformes de location d'énergie peuvent faire tourner les délégations sur de nombreuses adresses destinataires à partir d'une position stakée unique.

On-chain, lorsqu'une plateforme de location comme tronenergyrent.com délègue de l'énergie à votre adresse, le montant délégué est reflété dans l'état de votre compte, visible via wallet/getaccount sous acquired_delegated_frozenV2_balance_for_energy. L'énergie utilisable correspondante apparaît sur la limite d'énergie de votre compte et est immédiatement dépensable sans action de votre part.

Coûts de location vs coûts de consommation

La location est tarifée par palier de durée : 1h, 1d, 3d, 30d. Le palier 1h est le moins cher en valeur absolue de TRX, le palier 30d est le plus cher, avec 1d et 3d entre les deux. La tarification reflète la durée pendant laquelle le staking TRX sous-jacent de la plateforme est verrouillé sur votre adresse : fenêtres plus longues = plus de capital immobilisé = plus de TRX facturé. Pour les chiffres actuels par palier en TRX, consultez la page des tarifs.

Comparée à la consommation, la location est presque toujours gagnante pour les expéditeurs qui planifient. Consommer les 65,000 energy au taux dynamique du réseau est simple mais exposé au coût de consommation du moment, qui peut bouger fortement lorsque la demande énergétique totale du réseau évolue. La location vous donne un coût fixe en TRX au moment de la commande.

L'ordre de priorité des ressources pendant l'exécution

Lorsqu'une transaction s'exécute, la VM puise l'énergie dans un ordre précis :

1. Énergie adossée à des ressources déléguées à votre adresse par d'autres comptes
2. Énergie issue de votre propre TRX staké
3. TRX consommé depuis votre compte pour couvrir tout déficit restant (plafonné par fee_limit)

Cet ordonnancement compte pour les stratégies de location. L'énergie déléguée est consommée avant votre propre staking. Donc si vous disposez à la fois de votre propre énergie stakée et d'énergie louée, c'est la portion louée qui est puisée en premier. Une fois la fenêtre de location expirée et la délégation récupérée, votre compte se rabat sur son propre solde staké ou, si cela ne suffit pas, sur la consommation de TRX.

Le bandwidth suit la même priorité : allocation gratuite quotidienne d'abord, puis bandwidth staké, puis consommation de TRX. Il n'y a pas de substitution entre ressources : vous ne pouvez pas utiliser de l'énergie excédentaire pour couvrir un déficit de bandwidth.

Lire l'état des ressources de votre compte on-chain

L'endpoint API TRON wallet/getaccountresource retourne un objet JSON avec les champs que vous devriez connaître :

• EnergyLimit : énergie totale actuellement disponible sur votre compte depuis votre propre staking
• EnergyUsed : énergie consommée dans la fenêtre de 24 heures en cours
• TotalEnergyLimit : énergie totale à l'échelle du réseau (utile pour calculer le ratio staking/énergie)
• TotalEnergyWeight : poids total staké à l'échelle du réseau pour l'énergie
• freeNetLimit : votre allocation gratuite quotidienne de bandwidth (typiquement 600)
• NetLimit : bandwidth issu de votre propre TRX staké
• NetUsed : bandwidth consommé aujourd'hui
• TotalNetLimit, TotalNetWeight : totaux à l'échelle du réseau pour le bandwidth

Pour voir combien d'énergie a été déléguée à votre adresse par d'autres, interrogez wallet/getaccount et lisez le champ acquired_delegated_frozenV2_balance_for_energy. Pour le détail par délégateur, y compris toute expiration de verrouillage, utilisez wallet/getdelegatedresourcev2.

Si vous construisez un système qui envoie des transferts TRC-20 de façon programmatique, interroger ces endpoints avant la diffusion vous permet de détecter les conditions de faible énergie avant qu'elles ne provoquent des consommations inattendues de TRX. La documentation API couvre comment intégrer les vérifications de ressources et la commande d'énergie dans des workflows automatisés.

Pourquoi la consommation d'énergie varie selon les contrats de tokens

Le chiffre de 65,000 energy d'USDT est spécifique au contrat Tether à TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. D'autres contrats TRC-20 différeront. Un contrat de token avec une logique additionnelle (mécaniques de frais sur transfert, vérifications d'allowance pour des routers, ou émissions d'évènements pour plusieurs topics) consommera plus d'énergie par appel. Un contrat ERC-20 minimaliste pourrait passer sous les 30 000.

La seule façon fiable de connaître le coût réel en énergie d'un contrat est de simuler la transaction ou de consulter l'historique des exécutions de ce contrat précis sur un explorateur de blocs. N'appliquez pas universellement le chiffre USDT à tous les tokens TRC-20.