Blog · 30 octobre 2026

De combien de TRX un portefeuille a besoin pour envoyer des USDT

Un portefeuille qui envoie des USDT sur TRON a deux nombres à régler correctement, et on les prend facilement l'un pour l'autre. Le premier est les frais : ce qu'un transfert prélève sur le compte. Le second est les TRX que le compte doit détenir, et la limite que la transaction doit porter, pour que le transfert puisse passer. Avec de l'énergie sur le portefeuille, il n'a besoin de TRX que pour les octets : aucun pour le premier transfert de la journée, environ 0.345 TRX pour chacun des suivants. Sans énergie, il lui faut 6.5 TRX pour chaque transfert vers un destinataire qui détient des USDT et 13.1 TRX vers un qui n'en détient pas, plus les mêmes octets. Dans les deux cas, le fee_limit de la transaction doit atteindre la combustion entière. Un portefeuille approvisionné à hauteur des frais mais en dessous du second nombre échoue d'une façon qui coûte quand même des TRX.

Le nœud retient la plus petite de deux limites

Envoyer des USDT, c'est appeler un smart contract, et avant que l'appel ne s'exécute, le nœud décide de l'énergie qu'il peut dépenser. Il calcule deux chiffres et retient le plus petit. Le premier est ce que le compte peut payer : l'énergie qu'il détient déjà, plus autant d'unités que ses TRX en achèteraient au tarif du protocole de 100 sun l'unité. Le second est ce que la transaction permet : son fee_limit, divisé par ces mêmes 100 sun.

Deux règles en découlent. Les TRX du compte doivent couvrir toute l'énergie que le transfert va brûler, car un solde inférieur à la combustion plafonne l'appel en dessous de ce dont il a besoin. Et le fee_limit doit permettre cette combustion, car une limite basse plafonne l'appel tout aussi fermement, quels que soient les TRX qui se trouvent derrière. Manquez l'une ou l'autre et l'appel s'arrête en cours de route avec OUT_OF_ENERGY, et les TRX qu'il a brûlés en chemin restent brûlés (ce que ce résultat veut dire).

Le second chiffre piège les portefeuilles qui louent ou qui gèlent. Le nœud compte aussi l'énergie que le compte détient déjà dans le fee_limit, de la même façon qu'il compte les TRX qu'il brûlerait. Une transaction signée sans fee_limit porte une limite de zéro, et une limite de zéro ne laisse à l'appel dépenser aucune énergie, déléguée ou brûlée. Quoi que dise l'avertissement d'un portefeuille, le nœud fait ce calcul : l'énergie propre du compte ne couvrira pas l'appel, le nœud brûlera des TRX pour le reste, et le transfert passe seulement si le solde et la limite vont tous deux jusque-là.

Trois tentatives d'un même portefeuille sur le réseau principal

Le volet fee_limit de la règle s'observe sur le réseau principal. Le 6 octobre 2026, en parcourant le registre public du contrat USDT, nous sommes tombés sur un expéditeur qui a tenté trois fois le même transfert en moins de quarante minutes. Le transfert demandait 130,285 unités d'énergie, le chiffre pour un destinataire qui ne détient pas d'USDT, et le compte n'avait aucune énergie à lui : chaque unité devait donc être achetée en brûlant des TRX. Chaque ligne est l'enregistrement de cette transaction elle-même.

La première tentative s'est arrêtée à exactement 11,000 unités, soit son fee_limit divisé par 100 sun. Le compte aurait pu payer davantage : il a payé toute la combustion à la troisième tentative, et son historique ne montre aucun TRX arrivé entre-temps. La deuxième tentative ne portait aucun fee_limit, et son reçu rapporte une limite de zéro dès la première instruction du contrat. Elle n'a dépensé aucune énergie, n'a déplacé aucun USDT, et a tout de même payé ses octets. La troisième a été signée avec un fee_limit juste au-dessus de la combustion et est passée.

Cet expéditeur était l'exception. Sur 12,000 appels USDT consécutifs que nous avons comptés le même après-midi, chacun portait un fee_limit.

Quelle valeur donner au fee_limit

Le fee_limit plafonne l'énergie que l'appel peut utiliser, détenue ou brûlée, et ne facture rien par lui-même. Un transfert dont l'énergie est déjà sur le portefeuille n'en brûle aucune : une limite généreuse ne coûte donc rien sur un portefeuille qui a son énergie. La valeur qui n'arrête jamais un transfert en cours de route est la plus grosse combustion, 13.1 TRX. Une limite de 6.5 TRX ne suffit que tant que le destinataire détient encore des USDT quand le transfert arrive, et un destinataire au solde vide coûte le chiffre le plus élevé, qu'il en ait déjà détenu ou non (d'où viennent les deux chiffres). Une limite inférieure à ce dont le transfert a besoin arrête l'appel même sur un portefeuille qui détient toute l'énergie nécessaire, parce que le nœud compte cette énergie contre la limite.

Quand nous diffusons un transfert signé pour vous, en mode B, nous le soumettons à cette règle avant l'achat de toute énergie. Un fee_limit qui ne peut pas payer l'énergie du transfert au prix actuel du réseau est refusé avec 400 invalid_request et details.reason à fee_limit_too_low. Une estimation de ce seul transfert renvoie sa combustion sous la forme burn_cost_trx, et une limite au moins aussi haute passe toujours.

La limite compte le plus pour un transfert dont le coût change après qu'il a été tarifé. Un destinataire qui détenait des USDT quand vous l'avez vérifié et qui a vidé son solde au moment où le transfert arrive coûte le chiffre le plus élevé. Si le portefeuille détient de l'énergie pour le plus petit, le nœud brûle la différence sur les TRX. Le solde doit couvrir cette différence, et le fee_limit doit couvrir tout le plus grand chiffre, parce que l'énergie que le portefeuille détenait compte elle aussi contre lui. S'il manque l'un ou l'autre, le transfert s'arrête avec OUT_OF_ENERGY, et ce qu'il a brûlé en route reste brûlé.

Avec de l'énergie sur le portefeuille, il reste la bande passante

L'énergie paie l'appel de contrat et rien d'autre. Les octets de la transaction sont comptés à part, comme bande passante (les deux compteurs côte à côte). Chaque compte reçoit chaque jour 600 octets de bande passante gratuits, ce qui couvre environ un transfert USDT. Au-delà, le réseau brûle des TRX pour toute la bande passante facturée à chaque transaction, à dix fois le tarif de l'énergie : un octet coûte ce que coûtent dix unités d'énergie.

Un transfert USDT est facturé quelques centaines d'octets de bande passante. Celui que nous avons envoyé et mesuré le 2 septembre 2026 a été facturé 345, et les trois tentatives ci-dessus entre 339 et 345. Une fois l'allocation gratuite consommée par le premier transfert de la journée, chaque transfert suivant paie donc ses octets en TRX, que son énergie ait été louée, gelée ou brûlée. Un portefeuille qui ne détient aucun TRX peut encore envoyer son premier transfert de la journée sur de l'énergie déléguée, l'allocation gratuite payant les octets ; le deuxième exige des TRX sur le compte (envoyer sans détenir de TRX).

Frais en dehors du transfert

Un portefeuille émetteur doit exister sur la chaîne avant qu'on puisse lui déléguer de l'énergie (ce qu'est l'activation), et envoyer des TRX à une adresse que le réseau n'a jamais vue est ce qui crée son compte. Deux paramètres de la chaîne tarifent la création d'un compte. Nous n'avons pas activé d'adresse pour voir si un tel transfert paie le premier seul ou les deux, aussi le tableau les liste-t-il tous deux, et leur somme est le montant à garder pour cela. Deux autres paramètres tarifent un mémo sur une transaction et une transaction signée sous une permission multisignature. À la différence de l'activation, tous deux sont facturés à chaque transaction qui porte un mémo ou une permission multisignature : un portefeuille chaud signé ainsi ajoute donc le paramètre à chaque transfert compté dans le tableau ci-dessous. Nous n'avons envoyé ni l'un ni l'autre, et ces lignes donnent le paramètre et rien de mesuré.

La réserve pour une journée de transferts

Mis bout à bout, les TRX qu'un portefeuille émetteur consomme en une journée dépendent de la provenance de son énergie et, quand il brûle, du type de destinataire qu'il paie. Le tableau ci-dessous suppose 345 octets de bande passante facturés par transfert, l'allocation gratuite dépensée sur le premier transfert de la journée et les paramètres ci-dessus. Un portefeuille qui brûle paie 6.5 TRX ou 13.1 TRX d'énergie à chaque transfert, et ses octets à partir du deuxième transfert. Un portefeuille qui a de l'énergie ne paie que les octets.

L'énergie louée se paie sur votre solde chez nous, et son prix par transfert se trouve sur la page des tarifs. L'énergie gelée coûte les TRX immobilisés pour la produire, ce qui reste hors de ce tableau (geler ou louer). Le chiffre quotidien est ce qu'une recharge une fois par jour doit laisser sur le portefeuille. Avant un transfert isolé, le plancher est plus bas : la combustion de ce transfert, s'il brûle, et ses octets.

La dernière ligne est la marge pour de l'énergie achetée au plus petit chiffre. Auto-refill recharge un portefeuille jusqu'à environ 131,000 unités après ses transferts, de quoi couvrir les deux sortes de destinataires : sur un tel portefeuille, un destinataire qui se révèle exiger le plus grand chiffre est couvert en énergie et la marge tombe à zéro (comment fonctionne Auto-refill). Quelle que soit la source de l'énergie, le fee_limit doit tout de même couvrir toute l'énergie du transfert, soit 13.1 TRX pour un destinataire qui peut ne détenir aucun USDT quand le transfert arrive.

Nous n'avons pas mesuré à quelle vitesse l'allocation gratuite se reconstitue au fil d'une journée ; le tableau suppose que seul le premier transfert de la journée en profite : pour un portefeuille qui étale ses transferts, les chiffres de bande passante sont donc une borne supérieure.

Dimensionnez la limite de chaque transfert d'après la combustion que le nœud exigera : POST /v1/estimate et son burn_cost_trx, dans la référence de l'API →