Qu'est-ce qu'une adresse TRC20 ?

Une adresse TRC20 est une adresse de compte TRON utilisée pour envoyer et recevoir des tokens TRC20, le plus souvent USDT. Elle commence par la lettre T et fait 34 caractères de long, par exemple TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. À proprement parler, il n’existe pas de « type d’adresse TRC20 » séparé : chaque adresse TRON peut détenir des TRX, des tokens TRC10 et des tokens TRC20 indifféremment. Quand un exchange demande votre « adresse USDT TRC20 », il s’agit de votre adresse TRON normale.

Le format ne ressemble en rien aux adresses 0x que vous connaissez d’Ethereum ou de BSC, et TRON ajoute une subtilité qui déroute les développeurs plus que tout le reste : la même adresse a une seconde écriture, hexadécimale, qui commence par 41. Ce guide passe en revue l’encodage, la question hex vs Base58, la différence entre adresses de wallet et de contrat, le code de validation, et comment créer des adresses TRON à grande échelle via une API.

Le format : T plus 33 caractères, Base58Check

Une adresse TRON dans sa forme lisible est encodée en Base58Check. Base58 est le même alphabet qu’utilise Bitcoin : tous les chiffres et lettres sauf 0, O, I et l, retirés car faciles à confondre à l’impression. Une adresse TRON valide donc :

• commence par T
• fait exactement 34 caractères de long
• ne contient que des caractères de l’alphabet Base58

La partie « Check » signifie que l’encodage porte une somme de contrôle intégrée. Sous la surface Base58, une adresse fait 25 octets : un octet de préfixe 0x41, un identifiant de compte de 20 octets, et 4 octets de somme de contrôle. Un seul caractère mal saisi casse la somme de contrôle, ce qui permet à un wallet de rejeter la faute de frappe avant qu’une transaction ne soit signée. C’est important car, contrairement à la casse EIP-55 optionnelle d’Ethereum, la somme de contrôle d’une adresse TRON n’est pas optionnelle. Chaque adresse valide en a une.

TRC-20 vs ERC-20 vs BEP-20, côte à côte

USDT à lui seul existe sur ces trois réseaux, donc les formats se croisent quotidiennement dans les formulaires de retrait et les tickets de support. Ce qui les distingue, avec des chiffres à mi-2026 :

Les lignes du milieu expliquent pourquoi cet article met sans cesse en garde contre les chaînes EVM plutôt que contre TRON lui-même. Une adresse ERC-20 et une adresse BEP-20 sont la même chaîne de caractères, donc rien dans l’adresse n’indique à l’expéditeur ou au validateur quelle chaîne est visée ; une adresse TRON, elle, ne peut jamais être confondue avec l’une ou l’autre. L’erreur que font réellement les utilisateurs de TRON se situe dans les lignes frais et réseau : choisir le mauvais réseau dans un menu déroulant d’exchange, ou sous-estimer le coût de la redistribution des dépôts.

Les lignes de timing méritent un horodatage. BSC a atteint son temps de bloc de 0,45 seconde avec le hard fork Fermi en janvier 2026, sa deuxième réduction de temps de bloc en un an, tandis que TRON produit un bloc toutes les 3 secondes depuis son lancement et qu’Ethereum maintient des slots de 12 secondes depuis son passage au Proof of Stake. La fenêtre de finalité de 19 blocs de TRON, environ 57 secondes, est ce que la plupart des exchanges attendent avant de créditer un dépôt TRC20, ce qui explique pourquoi « envoyé » et « crédité » sont séparés d’une minute même quand tout fonctionne.

Comment une adresse TRON est dérivée

La dérivation est plus proche d’Ethereum que l’apparence du résultat ne le laisse penser :

1. Générez une clé privée sur la courbe secp256k1, la même courbe utilisée par Bitcoin et Ethereum.
2. Calculez la clé publique et hachez-la avec Keccak-256.
3. Conservez les 20 derniers octets du hash. Jusqu’ici, c’est exactement la procédure d’Ethereum.
4. Ajoutez l’octet 0x41 (le préfixe mainnet de TRON) en tête, ce qui donne 21 octets.
5. Hachez ces 21 octets deux fois avec SHA-256 et prenez les 4 premiers octets comme somme de contrôle.
6. Ajoutez la somme de contrôle et encodez les 25 octets en Base58.

Le T en tête n’est pas une convention choisie pour le branding ; il découle du calcul. Toute chaîne de 25 octets commençant par 0x41 s’encode en texte Base58 commençant par T.

Base58Check avec des chiffres réels

Les encodages se retiennent mieux quand on peut les reproduire soi-même, voici donc l’adresse du contrat USDT assemblée à partir de ses composants. Le payload de 21 octets est le préfixe 41 plus l’identifiant de compte de 20 octets :

payload:         41a614f803b6fd780986a42c78ec9c7f77e6ded13c
sha256(payload): 3a42512dd4f64e4d9dad3d5e6aa0ecf55adbd8a85979135cf211ba347278d029
sha256(again):   710277f5d80b170d90e2ec6c52caa368bc74b9226e3befe5c09825a0eedbfb68
checksum:        710277f5

La somme de contrôle correspond aux 4 premiers octets du second hash. Ajoutez-la au payload et vous obtenez 25 octets : 41a614f803b6fd780986a42c78ec9c7f77e6ded13c710277f5. Traitez ces octets comme un grand nombre, divisez-le à répétition par 58, et associez chaque reste à l’alphabet Base58. Le résultat est TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, l’adresse que tout wallet affiche.

Le décodage suit le même chemin à l’envers : Base58 vers 25 octets, on sépare les 4 derniers, on hache les 21 premiers deux fois avec SHA-256, et on compare. Si la comparaison échoue, un caractère a été altéré en transit et l’adresse ne doit pas être utilisée. Cette vérification explique pourquoi une adresse TRON mal saisie est rejetée par n’importe quel wallet correct : la probabilité qu’une faute de frappe aléatoire produise quand même une somme de contrôle correspondante de 4 octets est de 1 sur 2^32, environ une sur quatre milliards. L’EIP-55 d’Ethereum, en comparaison, détecte une faute de frappe avec environ 15 bits de contrôle, donc le schéma de TRON est nettement plus strict des deux.

Forme hex (41…) vs forme Base58 (T…) : une adresse, deux écritures

Voici la partie que presque aucun article explicatif ne couvre. Quand vous travaillez avec l’API node propre de TRON ou des bibliothèques bas niveau, les adresses reviennent en hexadécimal, commençant par 41. Le contrat du token USDT, par exemple :

Base58:  TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t
Hex:     41a614f803b6fd780986a42c78ec9c7f77e6ded13c

Les deux écritures identifient le même compte. La forme hex correspond aux 21 octets bruts (préfixe plus identifiant) sans la somme de contrôle ; la forme Base58 enveloppe ces octets avec la somme de contrôle pour un usage humain. Les wallets et explorateurs affichent T..., les réponses brutes des nodes et les payloads de transaction signés utilisent 41....

Deux conséquences pratiques. D’abord, ne comparez jamais des adresses comme de simples chaînes de caractères sans normaliser l’encodage, sinon TR7N... et 41a6... ressembleront à des comptes différents pour votre code. Ensuite, si vous retirez le préfixe 41 de la forme hex, les 20 octets restants ont la même forme qu’une adresse Ethereum, ce qui explique pourquoi certaines bibliothèques peuvent convertir entre représentations TRON et EVM. Même forme ne veut pas dire même compte : une clé utilisée sur les deux réseaux produit des adresses sans rapport, car la dérivation diverge à partir de l’étape 4.

Convertir entre les deux formes

La conversion est assez courte pour l’écrire soi-même plutôt que d’importer un SDK TRON. Passer de Base58 à hex signifie décoder et retirer la somme de contrôle ; l’autre sens la recalcule :

import bs58 from "bs58";
import { createHash } from "node:crypto";

const sha256 = (b) => createHash("sha256").update(b).digest();

function base58ToHex(address) {
  const raw = Buffer.from(bs58.decode(address));
  return raw.subarray(0, 21).toString("hex"); // retire les 4 octets de somme de contrôle
}

function hexToBase58(hex) {
  const payload = Buffer.from(hex, "hex"); // 21 octets, commence par 41
  const checksum = sha256(sha256(payload)).subarray(0, 4);
  return bs58.encode(Buffer.concat([payload, checksum]));
}

Choisissez une forme canonique unique pour le stockage et convertissez aux frontières. Stocker en Base58 garde votre base de données alignée sur ce que montrent les utilisateurs et les explorateurs ; stocker en hex correspond à ce que contiennent les payloads bruts des nodes. Les deux fonctionnent, mais mélanger les deux dans la même table est ainsi que naît le bug « même adresse, aucune correspondance », généralement découvert en réconciliant des dépôts à 2 heures du matin.

Adresse de contrat vs adresse de wallet

Wallets et smart contracts vivent tous deux à des adresses T..., et rien dans la chaîne de caractères ne les distingue. La distinction compte surtout pour USDT :

• Votre adresse de wallet est celle où vous recevez USDT. Elle appartient à votre clé privée.
• L’adresse du contrat TRC20 est celle où réside le code du token. Pour USDT sur TRON, c’est TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.

Vous rencontrerez l’adresse de contrat en ajoutant un token personnalisé à un wallet, en vérifiant sur Tronscan qu’un token est le véritable USDT et non une imitation portant le même nom, et en appelant le token depuis du code. Ce qu’il ne faut jamais faire, c’est envoyer des tokens vers l’adresse de contrat. Les contrats de token n’ont pas de propriétaire qui pourrait les renvoyer, donc les transferts vers le contrat sont perdus définitivement dans presque tous les cas. Les explorateurs étiquettent les comptes de contrat comme « Contract », le moyen le plus rapide de vérifier à quel type d’adresse vous avez affaire.

Vérifier une adresse sur Tronscan, étape par étape

Tronscan est l’explorateur de blocs de TRON, et il règle la plupart des doutes en moins d’une minute.

Collez l’adresse dans la barre de recherche. La page du compte affiche le solde TRX, les avoirs TRC20 et chaque transfert entrant et sortant. Une toute nouvelle adresse de dépôt affiche une page vide, ce qui est normal ; les comptes TRON sont activés par leur première transaction entrante, donc « pas encore de données » signifie inutilisée, pas invalide.

Vérifiez ensuite le type de compte. Les comptes de contrat portent une étiquette « Contract » visible en haut de la page. L’argent va vers des comptes ordinaires ; si la destination que quelqu’un vous a donnée s’avère étiquetée comme contrat, n’envoyez pas.

Pour les tokens, recherchez par adresse de contrat plutôt que par nom. Taper « USDT » dans Tronscan renvoie le vrai token entouré d’imitations utilisant le même ticker, et sur TRON, n’importe qui peut déployer un token appelé USDT. Le vrai réside à TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, a six décimales, et sa page Tronscan affiche une étiquette d’émetteur et un nombre de détenteurs dans les dizaines de millions. Un token inconnu dont la page affiche quelques centaines de détenteurs et aucun émetteur vérifié n’est pas l’actif que vous croyez.

Dernière étape après tout transfert : recherchez l’ID de transaction. La page de détail liste expéditeur, destinataire, contrat de token, montant et statut de confirmation. Une fois que la transaction s’affiche comme confirmée au-delà de la fenêtre de 19 blocs, elle est finale.

Ne confondez pas les réseaux

USDT existe simultanément sur plusieurs chaînes : comme token TRC20 sur TRON, comme token ERC-20 sur Ethereum, comme token BEP-20 sur BSC. Même ticker, contrats séparés, réseaux incompatibles.

TRON est en fait le cas le plus indulgent ici, car les formats diffèrent visiblement : une adresse T... ne peut pas être collée dans un formulaire de retrait Ethereum sans échouer à la validation, et une adresse 0x... échoue sur TRON. Le risque se situe dans les menus de retrait des exchanges, où vous choisissez le réseau dans un menu déroulant à côté du champ d’adresse. Choisissez « ERC20 » et collez une adresse TRON, et un bon exchange la bloquera. Mais si vous possédez des adresses sur plusieurs réseaux et collez par erreur celle qui correspond au réseau sélectionné, aucun validateur ne peut vous sauver. Indiquez explicitement le réseau partout où vous affichez ou acceptez une adresse. Pour le côté EVM de ce problème, où une adresse existe simultanément sur de nombreuses chaînes, voir Qu’est-ce qu’une adresse BEP20 ?.

Address poisoning : l’attaque que les sommes de contrôle ne détectent pas

Chaque vérification décrite jusqu’ici attrape les accidents. L’address poisoning est délibéré, et il fonctionne précisément parce que l’adresse empoisonnée est parfaitement valide.

Le montage : un attaquant observe votre activité on-chain, puis génère une adresse vanity dont les premiers et derniers caractères correspondent à une adresse avec laquelle vous transigez régulièrement. Générer une adresse TRON correspondant, disons, aux quatre premiers et quatre derniers caractères d’une cible est une question de temps de calcul, pas de rupture d’une quelconque cryptographie. L’attaquant plante ensuite ce sosie dans votre historique de transactions, soit en envoyant un montant infime de TRX, soit, plus élégamment, en exploitant le fait que les contrats TRC20 autorisent les transferts de valeur nulle : un transferFrom de 0 USDT coûte peu à l’attaquant et apparaît dans votre historique comme si vous aviez interagi avec l’adresse.

Le gain arrive des semaines plus tard, quand vous copiez « l’adresse habituelle » depuis votre historique de transferts au lieu de vos propres enregistrements. Wallets et explorateurs abrègent les adresses à leurs premiers et derniers caractères, exactement les caractères que l’attaquant a fait correspondre, donc le faux paraît correct au premier coup d’œil. Les pertes dues à ce schéma ne sont pas théoriques ; dans un cas largement rapporté en 2024, un utilisateur Ethereum a envoyé environ 68 millions de dollars en WBTC à une adresse empoisonnée. Les transactions bon marché de TRON rendent l’étape d’amorçage encore moins chère sur ce réseau.

Les défenses sont sans éclat mais efficaces. Ne copiez jamais d’adresses depuis votre historique de transactions ; copiez-les depuis votre propre carnet d’adresses, votre base de données, ou l’écran de réception du destinataire. Lors de la vérification, comparez plus de huit caractères, ou mieux, comparez la chaîne entière une fois puis reposez-vous sur une allowlist. Pour les plateformes, la règle est structurelle : les destinations de paiement proviennent de votre base de données, saisies et vérifiées une fois, et ne sont jamais dérivées de l’historique on-chain. Et l’habitude de la transaction test s’applique aussi ici : un petit transfert, confirmé sur Tronscan comme reçu par la partie visée, coûte quelques TRX et bat toute inspection visuelle.

Valider une adresse TRC20 en code

Une première vérification est une expression régulière contre l’alphabet Base58 :

const TRON_FORMAT = /^T[1-9A-HJ-NP-Za-km-z]{33}$/;

La regex attrape la mauvaise longueur et les caractères interdits, mais pas les fautes de frappe internes à l’alphabet. Pour cela, vérifiez la somme de contrôle :

import bs58 from "bs58";
import { createHash } from "node:crypto";

const sha256 = (buf) => createHash("sha256").update(buf).digest();

function isValidTronAddress(address) {
  if (!/^T[1-9A-HJ-NP-Za-km-z]{33}$/.test(address)) return false;

  const decoded = Buffer.from(bs58.decode(address));
  if (decoded.length !== 25 || decoded[0] !== 0x41) return false;

  const payload = decoded.subarray(0, 21);
  const checksum = decoded.subarray(21);
  const expected = sha256(sha256(payload)).subarray(0, 4);
  return expected.equals(checksum);
}

Une vérification réussie prouve que la chaîne est une adresse TRON bien formée. Elle ne prouve pas que le compte existe on-chain ni que quelqu’un détient sa clé, et elle ne peut pas distinguer un wallet d’un contrat. Pour la question du contrat, interrogez la chaîne ou consultez l’explorateur.

D’où viennent les adresses de wallet : dérivation HD sur TRON

Quand une application wallet vous remet une adresse TRON quelques secondes après avoir noté douze mots, voici la mécanique derrière. Les mots forment un mnémonique BIP-39 qui s’étend en une seed. À partir de la seed, BIP-32 dérive un arbre de paires de clés, toujours le même arbre pour les mêmes mots. BIP-44 assigne ensuite à chaque blockchain sa propre branche via un coin type enregistré, et celui de TRON est 195, donc le chemin standard pour votre première adresse TRON s’écrit m/44'/195'/0'/0/0.

Le coin type est le détail à retenir. Ethereum se situe au coin type 60, TRON à 195, et les deux nombres apparaissent à un niveau durci du chemin. Mêmes mots de seed, arbres de clés entièrement différents. C’est pourquoi la même phrase de récupération donne une adresse 0x dans un wallet EVM et une adresse T sans rapport dans un wallet TRON, et pourquoi ni l’un ni l’autre ne peut voir les fonds de l’autre. Si vous restaurez une phrase dans un wallet exclusivement Ethereum et que votre solde TRON semble disparu, rien n’est perdu ; le wallet n’a simplement jamais dérivé la branche 195. Restaurez les mêmes mots dans un wallet compatible TRON, et l’adresse, et le solde, réapparaissent.

L’index à la fin du chemin s’incrémente : .../0/1 est votre deuxième adresse TRON issue des mêmes mots, .../0/2 la troisième. Les wallets personnels dépassent rarement une poignée. Les plateformes sont le cas inverse, et pour elles, des clés générées indépendamment par client et enregistrées via une API constituent la construction la plus sûre, car aucune phrase unique ne contrôle alors toutes les adresses de dépôt du système.

Comment obtenir une adresse de wallet TRC20

Il existe deux voies, et celle dont vous avez besoin dépend du fait que vous voulez une adresse pour vous-même ou de nombreuses adresses pour une application.

La voie wallet (une adresse, usage personnel)

Installez un wallet compatible TRON : TronLink est le wallet navigateur standard du réseau, Trust Wallet couvre le mobile, Ledger couvre le matériel. Créez un compte, notez la phrase de récupération hors ligne, et ouvrez l’écran de réception. L’adresse T... affichée là est votre adresse de wallet TRC20 pour USDT et tout autre token TRON. Il n’y a aucun frais pour sa création et aucune étape d’enregistrement ; l’adresse fonctionne dès que le wallet la génère.

La voie API (nombreuses adresses, pour les applications)

Une plateforme qui crédite les dépôts par client a besoin d’une adresse par client, et cliquer mille fois dans l’interface d’un wallet n’est pas une option. Avec l’API REST Chaingateway, vous générez des clés dans votre propre environnement et les enregistrez pour le réseau TRON. L’authentification se fait par jeton Bearer :

curl -X POST https://app.chaingateway.io/api/v2/tron/addresses/import \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "address": "TYourGeneratedTronAddress",
    "privatekey": "<generated secp256k1 private key, hex>",
    "password": "<encryption password for this key>"
  }'

Avec l’en-tête X-Network: testnet, le même appel cible le testnet TRON, ce qui permet de tester tout le flux d’abord avec du TRX de test gratuit. L’envoi ultérieur de tokens passe par POST /api/v2/tron/transactions/trc20. Le quickstart présente les deux appels ; un essai de 7 jours sans onboarding KYC couvre la phase de test, et les plans sont sur la page tarifs.

Accepter des dépôts TRC20 : le flux webhook

Une fois que chaque client a une adresse, il reste à détecter les dépôts sans interroger Tronscan en continu. Le schéma :

1. Attribuez une adresse TRON dédiée par client et stockez la correspondance dans votre base de données.
2. Enregistrez un webhook. Quand un transfert TRC20 atteint l’adresse, votre endpoint est appelé avec les données de transaction.
3. Vérifiez la signature HMAC du webhook, puis créditez le client.

Les livraisons sont signées, et une livraison manquée par votre endpoint n’est pas perdue : GET /api/v2/tron/webhooks/notifications/failed liste ce qui n’est jamais passé, et POST /api/v2/tron/webhooks/notifications/{id}/retry le renvoie. Après une panne, GET /api/v2/tron/webhooks/notifications liste les notifications passées pour réconciliation. Les détails et le code de signature figurent dans le guide webhooks.

Un point spécifique à TRON : recevoir est gratuit, mais redistribuer les dépôts coûte de l’energy et de la bandwidth. Depuis que la proposition #104 a fait baisser le prix de l’energy de 210 à 100 Sun, un transfert d’USDT coûte environ 6,4 TRX vers une adresse active et environ 13,4 TRX vers une adresse vide, si vous payez sans energy staké. Planifiez les coûts de consolidation avec le calculateur de frais TRON ; les expéditeurs réguliers réduisent la consommation continue en stakant des TRX pour de l’energy, ce que l’API couvre avec POST /api/v2/tron/freeze.