Blog · 5 novembre 2026

Balayer les USDT des adresses de dépôt sur TRON : activation, énergie et bande passante par balayage

Une passerelle de paiement ou une plateforme d'échange qui donne à chaque client une adresse de dépôt à lui doit rassembler les USDT TRC-20 de ces adresses dans un portefeuille principal, le portefeuille chaud, avant de pouvoir en payer quoi que ce soit. Sur TRON, chacun de ces mouvements est un transfert USDT ordinaire, signé par l'adresse de dépôt. Il lui faut un compte sur la chaîne, de l'énergie pour l'appel de contrat et de la bande passante pour les octets, et une adresse de dépôt qui n'a jamais été payée qu'en USDT n'a rien de tout cela.

Recevoir des USDT ne crée pas de compte

Un solde USDT est une entrée dans le stockage propre du contrat du jeton. Un transfert entrant écrit cette entrée et ne crée aucun compte : une adresse peut donc détenir des USDT alors que le réseau n'a aucun compte pour elle. Notre mesure du 7 septembre 2026 a trouvé deux adresses de ce genre sur le réseau principal : chacune détenait des USDT, et le nœud sur lequel nous lisions a renvoyé un objet vide quand nous lui avons demandé le compte derrière elle, avant notre appel de test comme après. Le 27 octobre, les deux détenaient encore exactement les soldes qu'elles détenaient le 7 septembre.

L'énergie se délègue à un compte, et nous n'en livrons pas à une adresse qui n'en a pas : une commande en mode A ou en mode C qui nomme une telle adresse comme from revient en 422 invalid_address avec details.reason à inactive_wallet. Nous n'avons pas testé si la chaîne elle-même accepterait une délégation vers une telle adresse, car notre refus passe en premier. Nos notes d'exploitation consignent aussi la réponse du nœud à un envoi depuis un portefeuille qui n'a jamais rien reçu, no OwnerAccount. Cette note concerne des TRX envoyés depuis notre propre portefeuille chaud ; nous n'avons pas essayé un transfert USDT sortant d'une adresse dans cet état. L'histoire plus large de cet état se trouve dans l'article sur les comptes non activés.

Activer une adresse demande un transfert de TRX, payé par l'expéditeur

Tout transfert de TRX entrant crée le compte, si petit soit-il, et dès lors l'adresse est un compte comme un autre. La première tentative de cette mesure a déraillé précisément là-dessus, et nous l'avons écartée : une adresse lue comme n'ayant aucun compte, et 22 secondes plus tard quelqu'un lui a envoyé un seul sun, ce qui en a créé un. Son propre horodatage de création le disait.

Les frais de création retombent sur celui qui envoie les TRX : dans un dispositif de balayage, le portefeuille qui finance les activations. Deux paramètres de la chaîne les fixent. Nous les avons lus le 3 septembre 2026, et le réseau peut les modifier : relisez-les donc avant de budgétiser avec eux.

Comment les deux se combinent sur un simple transfert de TRX, nous ne l'avons pas mesuré avec un envoi à nous : cela demande un transfert réel vers une adresse neuve, et nous n'en avons fait aucun. Dans tous les cas, les frais se paient une fois par adresse. Une équipe qui active chaque adresse à sa génération les paie sur des adresses qui ne verront peut-être jamais de dépôt, et celle qui active au premier dépôt ne les paie que là où il y a quelque chose à balayer.

Chaque balayage prend le chiffre d'énergie le plus bas

L'énergie que dépense un transfert USDT dépend du destinataire. Quand le destinataire détient déjà des USDT, le transfert prend environ 65,000 unités ; quand son solde USDT est nul, il en prend environ 131,000. Que le destinataire ait un compte n'y entre pas. La mesure qui a trouvé ces deux adresses a mis les quatre combinaisons côte à côte, et le solde a décidé à chaque fois (pourquoi il y a deux chiffres).

Un balayage paie toujours le même destinataire, le portefeuille chaud, et le portefeuille chaud détient des USDT. Chaque balayage est donc du type le moins cher, single, quel que soit l'état de l'adresse de dépôt. Les appels du 7 septembre déplaçaient une unité hors d'un portefeuille qui gardait le reste, alors qu'un balayage déplace tout et laisse l'adresse de dépôt à zéro. Le 27 octobre, nous avons demandé au nœud de simuler les deux sur les deux mêmes adresses, avec un portefeuille détenant des USDT comme destinataire.

Vider l'adresse de dépôt n'a rien changé, et le chiffre est celui que cette mesure a donné pour tout transfert vers un détenteur. Ce sont des simulations du nœud, et aucune n'est le reçu d'un balayage diffusé ; les chiffres du 7 septembre portent la même réserve. Si les deux adresses ont aujourd'hui un compte, nous ne l'avons pas relu.

La seule façon de perdre le type le moins cher est de vider le portefeuille chaud. Une seule unité d'USDT chez le destinataire suffit pour le chiffre le plus bas, mais à zéro le balayage suivant vers lui prend environ 131,000 unités, soit 13.1 TRX si elles sont brûlées. Brûlé, un balayage normal coûte 6.5 TRX au tarif du protocole de 100 sun l'unité, et ce que coûte la location de la même énergie bouge avec le marché.

La bande passante gratuite couvre environ un balayage par adresse et par jour

La bande passante mesure les octets d'une transaction, là où l'énergie mesure son calcul (les deux compteurs côte à côte). Chaque compte en reçoit une allocation quotidienne gratuite. Le transfert USDT que nous avons envoyé et mesuré sur le réseau principal le 2 septembre 2026 a payé sa bande passante en TRX, ce qui donne exactement la bande passante qui lui a été facturée.

Face à 600 par jour, un balayage facturé à ce niveau tient et deux d'affilée non. Au-delà de l'allocation, le réseau brûle les TRX de l'expéditeur pour les octets. Le premier balayage d'une adresse dans la journée ne coûte donc rien en bande passante, et une adresse de dépôt qui reçoit aussi son énergie par délégation n'a besoin d'aucun TRX à elle pour l'envoyer. Un second balayage peu après le premier paie ses octets avec les TRX de l'adresse de dépôt. À quelle vitesse l'allocation se reconstitue entre les deux, nous ne l'avons pas mesuré ; notre propre balayage compte sur environ un transfert par jour et par adresse sur l'allocation gratuite. Si une adresse doit être balayée plus souvent que cela, le transfert d'activation peut lui laisser en même temps les TRX de ces octets.

Commander l'énergie pour une série de balayages

Le mode A nomme les deux bouts de chaque transfert, l'adresse de dépôt en from et le portefeuille chaud en to, et nous lisons nous-mêmes le type sur le portefeuille chaud. Le mode C ne nomme que le portefeuille à alimenter et prend le type que vous lui indiquez, ce qui convient à un système de garde qui signe ses balayages à son propre rythme et veut l'énergie déjà en place (le mode C en détail). Pour un balayage, ce type est toujours single, tant que le portefeuille chaud détient des USDT. L'un et l'autre mode acceptent jusqu'à 500 transferts dans une commande, le même plafond qu'une série de paiements. La location dure cinq minutes ou une heure, et send_before tombe trois secondes avant sa fin.

Une seule adresse de dépôt sans compte fait refuser toute la commande. Le 422 la nomme dans details.index et details.address, et rien n'est acheté. Passez donc la série au crible d'abord. POST /v1/estimate prend les mêmes 500 transferts et ne réserve rien, et il avertit là où la commande refuserait : donnez-lui from sur chaque élément, et toute adresse de dépôt sans compte revient marquée inactive_sender. Activez-les, laissez les activations se confirmer, puis envoyez la commande. Le refus ne consomme pas l'Idempotency-Key, et nous relisons l'activation sans passer par notre cache avant de refuser une commande pour cela : la même clé et le même corps fonctionnent donc dès que le transfert d'activation est confirmé.

Règles à retenir de notre propre balayage

Nous faisons tourner un balayage à nous. Des clients paient vers des adresses de dépôt que nous tenons pour eux, et un passage en arrière-plan déplace ces fonds vers l'unique portefeuille chaud qui paie les achats. Il déplace des TRX : il dépense donc de la bande passante et aucune énergie, et ses enregistrements ne disent rien du côté énergie d'un balayage d'USDT.

Notre balayage lit le montant sur la chaîne au moment où il décide. Nos propres enregistrements ne savent rien des frais qui ont été brûlés, ni d'un balayage dont la ligne en base n'a pas survécu à un processus planté, et la chaîne, si. La même règle rend un nouvel essai sûr : si les fonds sont déjà partis, il n'y a rien à envoyer.

Nous gardons un balayage diffusé ouvert jusqu'à ce que sa transaction apparaisse dans un bloc, et ne le passons en échec qu'après une fenêtre au moins aussi longue que la plus longue expiration que notre service de signature met à une transaction. Si on le ferme plus tôt, un transfert qui peut encore arriver est compté comme perdu, et le passage suivant peut signer un second transfert du même solde. Tant qu'un balayage n'est pas confirmé, son adresse reste hors du passage suivant.

Notre balayage de TRX envoie au plus le solde moins une réserve de frais, et ne garde cette réserve que lorsque la bande passante gratuite de l'adresse est déjà dépensée. Un balayage d'USDT paie ses frais dans une autre monnaie que celle qu'il déplace : tout le solde en USDT part donc à chaque fois, et la réserve devient les TRX dont une adresse de dépôt a besoin pour les octets d'un second balayage dans la journée.

Trouvez toute adresse de dépôt qui doit encore être activée avant de chiffrer le balayage, cinq cents par requête : POST /v1/estimate avec from sur chaque élément →