Cos'è un indirizzo TRC20?

Un indirizzo TRC20 è un indirizzo di account TRON usato per inviare e ricevere token TRC20, soprattutto USDT. Inizia con la lettera T ed è lungo 34 caratteri, per esempio TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. In senso stretto non esiste un «tipo di indirizzo TRC20» separato: ogni indirizzo TRON può contenere TRX, token TRC10 e token TRC20 allo stesso modo. Quando un exchange chiede il vostro «indirizzo USDT TRC20», intende il vostro normale indirizzo TRON.

Il formato non assomiglia per niente agli indirizzi 0x che conoscete da Ethereum o BSC, e TRON aggiunge una particolarità che confonde gli sviluppatori più di ogni altra cosa: lo stesso indirizzo ha una seconda forma, esadecimale, che inizia con 41. Questa guida passa in rassegna la codifica, la questione hex vs Base58, la differenza tra indirizzi wallet e contratto, il codice di validazione, e come creare indirizzi TRON su larga scala tramite API.

Il formato: T più 33 caratteri, Base58Check

Un indirizzo TRON nella sua forma leggibile è codificato in Base58Check. Base58 è lo stesso alfabeto usato da Bitcoin: tutte le cifre e lettere tranne 0, O, I e l, escluse perché facili da confondere in stampa. Quindi un indirizzo TRON valido:

• inizia con T
• è lungo esattamente 34 caratteri
• contiene solo caratteri dell’alfabeto Base58

La parte «Check» significa che la codifica porta un checksum integrato. Sotto la superficie Base58, un indirizzo è di 25 byte: un byte di prefisso 0x41, un identificatore di account di 20 byte e 4 byte di checksum. Un singolo carattere digitato male rompe il checksum, così un wallet può rifiutare l’errore di battitura prima che qualsiasi transazione venga firmata. Questo conta perché, a differenza della case EIP-55 opzionale di Ethereum, il checksum in un indirizzo TRON non è opzionale. Ogni indirizzo valido ne ha uno.

TRC-20 vs ERC-20 vs BEP-20 a confronto

USDT da solo vive su tutte e tre queste reti, quindi i formati si incontrano quotidianamente in moduli di prelievo e ticket di supporto. Cosa li distingue, con numeri aggiornati a metà 2026:

Le righe centrali spiegano perché questo articolo continua ad avvertire sulle chain EVM piuttosto che su TRON stesso. Un indirizzo ERC-20 e uno BEP-20 sono la stessa stringa, quindi nulla nell’indirizzo dice al mittente o al validatore quale chain sia intesa; un indirizzo TRON non può mai essere confuso con nessuno dei due. L’errore che gli utenti TRON commettono davvero sta nelle righe di fee e rete: scegliere la rete sbagliata in un menu a tendina di un exchange, o sottostimare quanto costa inoltrare i depositi.

Le righe sui tempi meritano una data. BSC ha raggiunto il suo block time di 0,45 secondi con l’hard fork Fermi nel gennaio 2026, il suo secondo taglio del block time in un anno, mentre TRON produce un block ogni 3 secondi dal lancio ed Ethereum mantiene slot di 12 secondi dal passaggio a Proof of Stake. La finestra di finalità di 19 block di TRON, circa 57 secondi, è ciò che la maggior parte degli exchange attende prima di accreditare un deposito TRC20, motivo per cui «inviato» e «accreditato» distano un minuto anche quando tutto funziona.

Come viene derivato un indirizzo TRON

La derivazione è più vicina a Ethereum di quanto suggerisca l’aspetto del risultato:

1. Generate una chiave privata sulla curva secp256k1, la stessa curva usata da Bitcoin ed Ethereum.
2. Calcolate la chiave pubblica e fatene l’hash con Keccak-256.
3. Conservate gli ultimi 20 byte dell’hash. Fin qui è esattamente la procedura di Ethereum.
4. Anteponete il byte 0x41 (il prefisso mainnet di TRON), ottenendo 21 byte.
5. Fate l’hash di questi 21 byte due volte con SHA-256 e prendete i primi 4 byte come checksum.
6. Aggiungete il checksum e codificate i 25 byte in Base58.

La T iniziale non è una convenzione scelta per il branding; deriva dalla matematica. Qualsiasi stringa di 25 byte che inizia con 0x41 si codifica in testo Base58 che inizia con T.

Base58Check con numeri reali

Le codifiche si ricordano meglio quando potete riprodurle voi stessi, ecco quindi l’indirizzo del contratto USDT assemblato dalle sue parti. Il payload di 21 byte è il prefisso 41 più l’identificatore di account di 20 byte:

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

Il checksum sono i primi 4 byte del secondo hash. Aggiungetelo al payload e avrete 25 byte: 41a614f803b6fd780986a42c78ec9c7f77e6ded13c710277f5. Trattate questi byte come un unico numero grande, dividetelo ripetutamente per 58, e mappate ogni resto sull’alfabeto Base58. Il risultato è TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, l’indirizzo che ogni wallet mostra.

La decodifica percorre lo stesso cammino al contrario: da Base58 a 25 byte, separate gli ultimi 4, fate l’hash dei primi 21 due volte con SHA-256, e confrontate. Se il confronto fallisce, qualche carattere è stato alterato durante il transito e l’indirizzo non deve essere usato. Questo controllo è il motivo per cui un indirizzo TRON digitato male viene rifiutato da qualsiasi wallet decente: la probabilità che un errore di battitura casuale produca comunque un checksum corrispondente di 4 byte è 1 su 2^32, circa una su quattro miliardi. L’EIP-55 di Ethereum, in confronto, cattura un errore di battitura con circa 15 bit di controllo, quindi lo schema di TRON è, con ampio margine, il più rigoroso dei due.

Forma hex (41…) vs forma Base58 (T…): un indirizzo, due scritture

Ecco la parte che quasi nessun articolo esplicativo copre. Quando lavorate con l’API node propria di TRON o con librerie di basso livello, gli indirizzi tornano in esadecimale, iniziando con 41. Il contratto del token USDT, per esempio:

Base58:  TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t
Hex:     41a614f803b6fd780986a42c78ec9c7f77e6ded13c

Entrambe le scritture identificano lo stesso account. La forma hex sono i 21 byte grezzi (prefisso più identificatore) senza il checksum; la forma Base58 avvolge questi byte con il checksum per l’uso umano. Wallet ed explorer mostrano T..., le risposte grezze dei node e i payload di transazione firmati usano 41....

Due conseguenze pratiche. Primo, non confrontate mai gli indirizzi come stringhe senza normalizzare la codifica, altrimenti TR7N... e 41a6... sembreranno account diversi al vostro codice. Secondo, se togliete il prefisso 41 dalla forma hex, i restanti 20 byte hanno la stessa forma di un indirizzo Ethereum, motivo per cui alcune librerie possono convertire tra rappresentazioni TRON ed EVM. Stessa forma non significa stesso account: una key usata su entrambe le reti produce indirizzi non correlati, perché la derivazione diverge a partire dal passo 4.

Convertire tra le due forme

La conversione è abbastanza breve da scriverla da soli invece di importare un SDK TRON. Passare da Base58 a hex significa decodificare e scartare il checksum; l’altra direzione lo ricalcola:

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"); // scarta i 4 byte di checksum
}

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

Scegliete una forma canonica unica per lo storage e convertite ai confini. Salvare in Base58 mantiene il vostro database allineato a ciò che mostrano utenti ed explorer; salvare in hex corrisponde a ciò che contengono i payload grezzi dei node. Entrambe funzionano, ma mescolarle nella stessa tabella è il modo in cui nasce il bug «stesso indirizzo, nessuna corrispondenza», di solito scoperto riconciliando i depositi alle 2 di notte.

Indirizzo contratto vs indirizzo wallet

Sia i wallet che gli smart contract vivono a indirizzi T..., e nulla nella stringa li distingue. La distinzione conta soprattutto per USDT:

• Il vostro indirizzo wallet è dove ricevete USDT. Appartiene alla vostra chiave privata.
• L’indirizzo del contratto TRC20 è dove risiede il codice del token. Per USDT su TRON è TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.

Incontrerete l’indirizzo del contratto quando aggiungete un token personalizzato a un wallet, quando verificate su Tronscan che un token sia il vero USDT e non un’imitazione con lo stesso nome, e quando chiamate il token dal codice. Ciò che non dovete mai fare è inviare token *all’*indirizzo del contratto. I contratti token non hanno un owner che potrebbe rispedirli, quindi i transfer al contratto sono persi per sempre in quasi tutti i casi. Gli explorer etichettano gli account contratto come «Contract», il modo più rapido per verificare con che tipo di indirizzo avete a che fare.

Verificare un indirizzo su Tronscan, passo dopo passo

Tronscan è il block explorer di TRON, e risolve la maggior parte dei dubbi in meno di un minuto.

Incollate l’indirizzo nella barra di ricerca. La pagina dell’account mostra il saldo TRX, le partecipazioni TRC20 e ogni transfer in entrata e in uscita. Un indirizzo di deposito appena creato mostra una pagina vuota, il che va bene; gli account TRON vengono attivati dalla loro prima transazione in entrata, quindi «nessun dato ancora» significa non usato, non non valido.

Controllate poi il tipo di account. Gli account contratto portano un tag «Contract» visibile vicino alla parte superiore della pagina. Il denaro va ad account normali; se la destinazione che qualcuno vi ha dato risulta etichettata come contratto, non inviate.

Per i token, cercate per indirizzo del contratto piuttosto che per nome. Digitare «USDT» su Tronscan restituisce il token genuino circondato da imitazioni che usano lo stesso ticker, e su TRON chiunque può deployare un token chiamato USDT. Quello vero risiede a TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, ha sei decimali, e la sua pagina Tronscan mostra un’etichetta emittente e un numero di holder nelle decine di milioni. Un token sconosciuto la cui pagina mostra poche centinaia di holder e nessun emittente verificato non è l’asset che pensate.

Ultimo passo dopo qualsiasi transfer: cercate l’ID transazione. La pagina di dettaglio elenca mittente, destinatario, contratto del token, importo e stato di conferma. Una volta che la transazione appare confermata oltre la finestra di 19 block, è finale.

Non confondete le reti

USDT esiste contemporaneamente su più chain: come token TRC20 su TRON, come token ERC-20 su Ethereum, come token BEP-20 su BSC. Stesso ticker, contratti separati, reti incompatibili.

TRON è in realtà il caso più clemente qui, perché i formati differiscono visibilmente: un indirizzo T... non può essere incollato in un modulo di prelievo Ethereum senza fallire la validazione, e un indirizzo 0x... fallisce su TRON. Il rischio sta nei menu di prelievo degli exchange, dove scegliete la rete da un menu a tendina accanto al campo indirizzo. Scegliete «ERC20» e incollate un indirizzo TRON, e un buon exchange lo blocca. Ma se possedete indirizzi su più reti e incollate per errore quello che corrisponde alla rete selezionata, nessun validatore può salvarvi. Dichiarate la rete esplicitamente ovunque mostriate o accettiate un indirizzo. Per il lato EVM di questo problema, dove un indirizzo esiste contemporaneamente su molte chain, vedete Cos’è un indirizzo BEP20?.

Address poisoning: l’attacco che i checksum non riescono a rilevare

Ogni controllo descritto finora cattura gli incidenti. L’address poisoning è deliberato, e funziona proprio perché l’indirizzo avvelenato è perfettamente valido.

Il meccanismo: un aggressore osserva la vostra attività on-chain, poi genera un indirizzo vanity i cui primi e ultimi caratteri corrispondono a un indirizzo con cui transate regolarmente. Generare un indirizzo TRON che corrisponda, diciamo, a quattro caratteri iniziali e quattro finali di un bersaglio è una questione di tempo di calcolo, non di rompere alcuna crittografia. L’aggressore poi pianta questo sosia nella vostra cronologia delle transazioni, sia inviando un importo minimo di TRX, sia, più elegantemente, sfruttando il fatto che i contratti TRC20 permettono transfer a valore zero: un transferFrom di 0 USDT costa poco all’aggressore e appare nella vostra cronologia come se aveste interagito con l’indirizzo.

Il guadagno arriva settimane dopo, quando copiate «l’indirizzo abituale» dalla vostra cronologia dei transfer invece che dai vostri registri. Wallet ed explorer abbreviano gli indirizzi ai loro primi e ultimi caratteri, esattamente i caratteri che l’aggressore ha fatto corrispondere, quindi il falso sembra corretto a prima vista. Le perdite dovute a questo schema non sono teoriche; in un caso ampiamente riportato nel 2024, un utente Ethereum ha inviato circa 68 milioni di dollari in WBTC a un indirizzo avvelenato. Le transazioni economiche di TRON rendono il passo di seeding ancora più economico lì.

Le difese non sono affascinanti ma funzionano. Non copiate mai gli indirizzi dalla vostra cronologia delle transazioni; copiateli dalla vostra rubrica, dal vostro database, o dalla schermata di ricezione del destinatario. Quando verificate, confrontate più di otto caratteri, o meglio, confrontate l’intera stringa una volta e poi affidatevi a un’allowlist. Per le piattaforme, la regola è strutturale: le destinazioni di pagamento provengono dal vostro database, inserite e verificate una volta, e non sono mai derivate dalla cronologia on-chain. E l’abitudine della transazione di prova si applica anche qui: un piccolo transfer, confermato su Tronscan come ricevuto dalla parte prevista, costa pochi TRX e batte qualsiasi ispezione visiva.

Validare un indirizzo TRC20 nel codice

Un primo controllo è un’espressione regolare contro l’alfabeto Base58:

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

La regex cattura lunghezza sbagliata e caratteri vietati, ma non errori di battitura interni all’alfabeto. Per quello verificate il checksum:

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);
}

Un controllo superato dimostra che la stringa è un indirizzo TRON ben formato. Non dimostra che l’account esista on-chain né che qualcuno ne possieda la key, e non può distinguere un wallet da un contratto. Per la questione del contratto, interrogate la chain o controllate l’explorer.

Da dove vengono gli indirizzi wallet: derivazione HD su TRON

Quando un’app wallet vi consegna un indirizzo TRON pochi secondi dopo aver annotato dodici parole, questa è la meccanica dietro. Le parole sono un mnemonic BIP-39 che si espande in un seed. Dal seed, BIP-32 deriva un albero di coppie di key, sempre lo stesso albero per le stesse parole. BIP-44 assegna poi a ogni blockchain il proprio ramo tramite un coin type registrato, e quello di TRON è 195, quindi il percorso standard per il vostro primo indirizzo TRON è m/44'/195'/0'/0/0.

Il coin type è il dettaglio da ricordare. Ethereum sta al coin type 60, TRON al 195, ed entrambi i numeri compaiono a un livello hardened del percorso. Stesse parole seed, alberi di key completamente diversi. Ecco perché la stessa recovery phrase dà un indirizzo 0x in un wallet EVM e un indirizzo T non correlato in un wallet TRON, e perché nessuno dei due wallet può vedere i fondi dell’altro. Se ripristinate una frase in un wallet esclusivamente Ethereum e il vostro saldo TRON sembra sparito, non è andato perso nulla; il wallet semplicemente non ha mai derivato il ramo 195. Ripristinate le stesse parole in un wallet con supporto TRON e l’indirizzo, e il saldo, riappaiono.

L’indice alla fine del percorso si incrementa: .../0/1 è il vostro secondo indirizzo TRON dalle stesse parole, .../0/2 il terzo. I wallet personali raramente vanno oltre una manciata. Le piattaforme sono il caso opposto, e per loro key generate indipendentemente per cliente e registrate tramite API sono la costruzione più sicura, perché nessuna singola frase controlla allora ogni indirizzo di deposito nel sistema.

Come ottenere un indirizzo wallet TRC20

Ci sono due strade, e quale vi serve dipende dal fatto che vogliate un indirizzo per voi stessi o molti indirizzi per un’applicazione.

La strada del wallet (un indirizzo, uso personale)

Installate un wallet che supporti TRON: TronLink è il wallet browser standard della rete, Trust Wallet copre il mobile, Ledger copre l’hardware. Create un account, annotate la recovery phrase offline, e aprite la schermata di ricezione. L’indirizzo T... mostrato lì è il vostro indirizzo wallet TRC20 per USDT e ogni altro token TRON. Non c’è alcuna fee per crearlo né alcun passaggio di registrazione; l’indirizzo funziona nel momento in cui il wallet lo genera.

La strada API (molti indirizzi, per applicazioni)

Una piattaforma che accredita depositi per cliente ha bisogno di un indirizzo per cliente, e cliccare mille volte in una UI wallet non è un’opzione. Con la REST API di Chaingateway generate key nel vostro stesso ambiente e le registrate per la rete TRON. L’autenticazione è un token 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>"
  }'

Con l’header X-Network: testnet la stessa chiamata punta alla testnet TRON, quindi l’intero flusso può essere testato prima con TRX di test gratuito. L’invio successivo di token passa per POST /api/v2/tron/transactions/trc20. Il quickstart illustra entrambe le chiamate; una prova di 7 giorni senza onboarding KYC copre la fase di test, e i piani sono sulla pagina prezzi.

Accettare depositi TRC20: il flusso webhook

Una volta che ogni cliente ha un indirizzo, il problema restante è accorgersi dei depositi senza fare polling di Tronscan. Lo schema:

1. Assegnate un indirizzo TRON dedicato per cliente e salvate la corrispondenza nel vostro database.
2. Registrate un webhook. Quando un transfer TRC20 raggiunge l’indirizzo, il vostro endpoint viene chiamato con i dati della transazione.
3. Verificate la firma HMAC del webhook, poi accreditate il cliente.

Le consegne sono firmate, e una consegna che il vostro endpoint ha mancato non è persa: GET /api/v2/tron/webhooks/notifications/failed elenca ciò che non è mai arrivato, e POST /api/v2/tron/webhooks/notifications/{id}/retry la reinvia. Dopo un’interruzione, GET /api/v2/tron/webhooks/notifications elenca le notifiche passate per la riconciliazione. Dettagli e codice di firma sono nella guida ai webhook.

Un punto specifico di TRON: ricevere è gratuito, ma inoltrare i depositi costa energy e bandwidth. Da quando la proposal #104 ha abbassato il prezzo dell’energy da 210 a 100 Sun, un transfer di USDT costa circa 6,4 TRX verso un indirizzo attivo e circa 13,4 TRX verso uno vuoto, se pagate senza energy in stake. Pianificate i costi di consolidamento con il calcolatore di fee TRON; i mittenti abituali riducono il consumo continuo mettendo in stake TRX per energy, cosa che l’API copre con POST /api/v2/tron/freeze.