¿Qué es una dirección TRC20?

Una dirección TRC20 es una dirección de cuenta TRON usada para enviar y recibir tokens TRC20, sobre todo USDT. Empieza con la letra T y tiene 34 caracteres de longitud, por ejemplo TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t. Estrictamente hablando no existe un «tipo de dirección TRC20» separado: cualquier dirección TRON puede contener TRX, tokens TRC10 y tokens TRC20 por igual. Cuando un exchange le pide su «dirección USDT TRC20», se refiere a su dirección TRON normal.

El formato no se parece en nada a las direcciones 0x que conoce de Ethereum o BSC, y TRON añade un giro que confunde a los desarrolladores más que cualquier otra cosa: la misma dirección tiene una segunda forma, hexadecimal, que empieza con 41. Esta guía recorre la codificación, la cuestión hex vs Base58, la diferencia entre direcciones de wallet y de contrato, código de validación, y cómo crear direcciones TRON a escala mediante una API.

El formato: T más 33 caracteres, Base58Check

Una dirección TRON en su forma legible está codificada en Base58Check. Base58 es el mismo alfabeto que usa Bitcoin: todos los dígitos y letras excepto 0, O, I y l, descartados porque son fáciles de confundir al imprimirse. Así, una dirección TRON válida:

• empieza con T
• tiene exactamente 34 caracteres de longitud
• contiene solo caracteres del alfabeto Base58

La parte «Check» significa que la codificación lleva un checksum incorporado. Bajo la superficie Base58, una dirección son 25 bytes: un byte de prefijo 0x41, un identificador de cuenta de 20 bytes y 4 bytes de checksum. Un solo carácter mal escrito rompe el checksum, así que una wallet puede rechazar el error tipográfico antes de firmar cualquier transacción. Esto importa porque, a diferencia de las mayúsculas opcionales EIP-55 de Ethereum, el checksum en una dirección TRON no es opcional. Toda dirección válida tiene uno.

TRC-20 vs ERC-20 vs BEP-20 lado a lado

USDT por sí solo vive en estas tres redes, así que los formatos se cruzan a diario en formularios de retiro y tickets de soporte. Lo que las distingue, con cifras a mediados de 2026:

Las filas centrales explican por qué este artículo advierte constantemente sobre las chains EVM en lugar de sobre TRON en sí. Una dirección ERC-20 y una BEP-20 son el mismo string, así que nada en la dirección le dice al remitente o al validador qué chain se pretende; una dirección TRON nunca puede confundirse con ninguna de las dos. El error que realmente cometen los usuarios de TRON está en las filas de fees y red: elegir la red equivocada en un desplegable de un exchange, o subestimar lo que cuesta reenviar depósitos.

Las filas de tiempos merecen una fecha. BSC alcanzó su tiempo de block de 0,45 segundos con el hard fork Fermi en enero de 2026, su segundo recorte de tiempo de block en un año, mientras que TRON ha producido un block cada 3 segundos desde su lanzamiento y Ethereum mantiene slots de 12 segundos desde su paso a Proof of Stake. La ventana de finalidad de 19 blocks de TRON, unos 57 segundos, es lo que la mayoría de exchanges espera antes de acreditar un depósito TRC20, por lo que «enviado» y «acreditado» quedan separados por un minuto incluso cuando todo funciona.

Cómo se deriva una dirección TRON

La derivación está más cerca de Ethereum de lo que sugiere el aspecto del resultado:

1. Genere una private key en la curva secp256k1, la misma curva que usan Bitcoin y Ethereum.
2. Calcule la public key y hágale hash con Keccak-256.
3. Conserve los últimos 20 bytes del hash. Hasta aquí es exactamente el procedimiento de Ethereum.
4. Anteponga el byte 0x41 (el prefijo mainnet de TRON), obteniendo 21 bytes.
5. Haga hash de esos 21 bytes dos veces con SHA-256 y tome los primeros 4 bytes como checksum.
6. Añada el checksum y codifique los 25 bytes en Base58.

La T inicial no es una convención elegida por branding; se desprende de las matemáticas. Cualquier string de 25 bytes que empiece con 0x41 se codifica en texto Base58 que empieza con T.

Base58Check con números reales

Las codificaciones se recuerdan mejor cuando puede reproducirlas usted mismo, así que aquí está la dirección del contrato USDT ensamblada a partir de sus partes. El payload de 21 bytes es el prefijo 41 más el identificador de cuenta de 20 bytes:

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

El checksum son los primeros 4 bytes del segundo hash. Añádalo al payload y tiene 25 bytes: 41a614f803b6fd780986a42c78ec9c7f77e6ded13c710277f5. Trate esos bytes como un número grande, divídalo repetidamente entre 58, y asigne cada resto al alfabeto Base58. El resultado es TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, la dirección que muestra cualquier wallet.

Decodificar recorre el mismo camino a la inversa: de Base58 a 25 bytes, separe los últimos 4, haga hash de los primeros 21 dos veces con SHA-256, y compare. Si la comparación falla, algún carácter se corrompió en tránsito y la dirección no debe usarse. Esa comprobación es la razón por la que una dirección TRON mal escrita es rechazada por cualquier wallet decente: la probabilidad de que un error tipográfico aleatorio produzca de todos modos un checksum coincidente de 4 bytes es 1 entre 2^32, aproximadamente uno entre cuatro mil millones. El EIP-55 de Ethereum, en comparación, detecta un error tipográfico con unos 15 bits de control, así que el esquema de TRON es, con amplio margen, el más estricto de los dos.

Forma hex (41…) vs forma Base58 (T…): una dirección, dos escrituras

Aquí viene la parte que casi ningún artículo explicativo cubre. Cuando trabaja con la API de node propia de TRON o con librerías de bajo nivel, las direcciones vuelven en hexadecimal, empezando con 41. El contrato del token USDT, por ejemplo:

Base58:  TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t
Hex:     41a614f803b6fd780986a42c78ec9c7f77e6ded13c

Ambas escrituras identifican la misma cuenta. La forma hex son los 21 bytes crudos (prefijo más identificador) sin el checksum; la forma Base58 envuelve esos bytes con el checksum para uso humano. Wallets y exploradores muestran T..., las respuestas crudas de nodes y los payloads de transacción firmados usan 41....

Dos consecuencias prácticas. Primero, nunca compare direcciones como strings sin normalizar la codificación, o TR7N... y 41a6... parecerán cuentas distintas para su código. Segundo, si quita el prefijo 41 de la forma hex, los 20 bytes restantes tienen la misma forma que una dirección de Ethereum, razón por la cual algunas librerías pueden convertir entre representaciones TRON y EVM. Misma forma no significa misma cuenta: una key usada en ambas redes produce direcciones sin relación, porque la derivación diverge a partir del paso 4.

Convertir entre ambas formas

La conversión es lo bastante corta para escribirla usted mismo en lugar de traer un SDK de TRON. Ir de Base58 a hex significa decodificar y descartar el checksum; el otro sentido lo recalcula:

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"); // descarta los 4 bytes de checksum
}

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

Elija una forma canónica única para el almacenamiento y convierta en los límites. Almacenar en Base58 mantiene su base de datos alineada con lo que muestran usuarios y exploradores; almacenar en hex coincide con lo que contienen los payloads crudos de los nodes. Ambas funcionan, pero mezclar las dos en la misma tabla es como nace el bug «misma dirección, sin coincidencia», normalmente descubierto al reconciliar depósitos a las 2 de la madrugada.

Dirección de contrato vs dirección de wallet

Tanto las wallets como los smart contracts viven en direcciones T..., y nada en el string las distingue. La distinción importa más para USDT:

• Su dirección de wallet es donde recibe USDT. Pertenece a su private key.
• La dirección del contrato TRC20 es donde reside el código del token. Para USDT en TRON eso es TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t.

Se encontrará con la dirección de contrato al añadir un token personalizado a una wallet, al verificar en Tronscan que un token es el USDT real y no una copia con el mismo nombre, y al llamar al token desde código. Lo que nunca debe hacer es enviar tokens a la dirección de contrato. Los contratos de token no tienen un owner que pudiera devolverlos, así que los transfers al contrato se pierden para siempre en casi todos los casos. Los exploradores etiquetan las cuentas de contrato como «Contract», la forma más rápida de comprobar con qué tipo de dirección está tratando.

Verificar una dirección en Tronscan, paso a paso

Tronscan es el explorador de blocks de TRON, y resuelve la mayoría de dudas en menos de un minuto.

Pegue la dirección en la barra de búsqueda. La página de la cuenta muestra el saldo de TRX, las tenencias TRC20 y cada transfer de entrada y salida. Una dirección de depósito recién creada muestra una página vacía, lo cual es normal; las cuentas TRON se activan con su primera transacción entrante, así que «sin datos aún» significa sin usar, no inválida.

A continuación compruebe el tipo de cuenta. Las cuentas de contrato llevan una etiqueta «Contract» visible cerca de la parte superior de la página. El dinero va a cuentas normales; si el destino que alguien le dio resulta estar etiquetado como contrato, no envíe.

Para tokens, busque por dirección de contrato en lugar de por nombre. Escribir «USDT» en Tronscan devuelve el token genuino rodeado de imitaciones que usan el mismo ticker, y en TRON cualquiera puede desplegar un token llamado USDT. El real reside en TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, tiene seis decimales, y su página en Tronscan muestra una etiqueta de emisor y un número de holders en las decenas de millones. Un token desconocido cuya página muestra unos pocos cientos de holders y ningún emisor verificado no es el activo que usted cree.

Último paso tras cualquier transfer: busque el ID de transacción. La página de detalle lista remitente, destinatario, contrato del token, importe y estado de confirmación. Una vez que la transacción se muestra confirmada tras la ventana de 19 blocks, es final.

No confunda las redes

USDT existe simultáneamente en varias chains: como token TRC20 en TRON, como token ERC-20 en Ethereum, como token BEP-20 en BSC. Mismo ticker, contratos separados, redes incompatibles.

TRON es en realidad el caso más amable aquí, porque los formatos difieren visiblemente: una dirección T... no se puede pegar en un formulario de retiro de Ethereum sin fallar la validación, y una dirección 0x... falla en TRON. El riesgo está en los menús de retiro de los exchanges, donde elige la red en un desplegable junto al campo de dirección. Elija «ERC20» y pegue una dirección TRON, y un buen exchange la bloqueará. Pero si posee direcciones en varias redes y pega por error la que coincide con la red seleccionada, ningún validador puede salvarle. Indique la red explícitamente en todo lugar donde muestre o acepte una dirección. Para el lado EVM de este problema, donde una dirección existe simultáneamente en muchas chains, vea ¿Qué es una dirección BEP20?.

Address poisoning: el ataque que los checksums no detectan

Toda comprobación descrita hasta ahora atrapa accidentes. El address poisoning es deliberado, y funciona precisamente porque la dirección envenenada es perfectamente válida.

El montaje: un atacante observa su actividad on-chain, y luego genera una dirección vanity cuyos primeros y últimos caracteres coinciden con una dirección con la que usted transacciona habitualmente. Generar una dirección TRON que coincida, digamos, en cuatro caracteres iniciales y cuatro finales de un objetivo es cuestión de tiempo de cómputo, no de romper ninguna criptografía. El atacante planta entonces ese sosias en su historial de transacciones, ya sea enviando una cantidad ínfima de TRX o, más elegantemente, abusando de que los contratos TRC20 permiten transfers de valor cero: un transferFrom de 0 USDT cuesta poco al atacante y aparece en su historial como si hubiera interactuado con la dirección.

La recompensa llega semanas después, cuando copia «la dirección de siempre» de su historial de transfers en lugar de sus propios registros. Wallets y exploradores abrevian las direcciones a sus primeros y últimos caracteres, exactamente los caracteres que el atacante hizo coincidir, así que la falsa parece correcta a simple vista. Las pérdidas por este patrón no son teóricas; en un caso ampliamente reportado de 2024, un usuario de Ethereum envió unos 68 millones de dólares en WBTC a una dirección envenenada. Las transacciones baratas de TRON hacen que el paso de siembra sea aún más barato allí.

Las defensas son poco vistosas y funcionan. Nunca copie direcciones de su historial de transacciones; cópielas de su propia libreta de direcciones, de su base de datos, o de la pantalla de recepción del destinatario. Al verificar, compare más de ocho caracteres, o mejor, compare el string completo una vez y luego confíe en una allowlist. Para plataformas, la regla es estructural: los destinos de pago provienen de su base de datos, introducidos y verificados una vez, y nunca se derivan del historial on-chain. Y el hábito de la transacción de prueba también aplica aquí: un pequeño transfer, confirmado en Tronscan como recibido por la parte prevista, cuesta unos pocos TRX y supera cualquier inspección visual.

Validar una dirección TRC20 en código

Una primera comprobación es una expresión regular contra el alfabeto Base58:

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

La regex atrapa longitud incorrecta y caracteres prohibidos, pero no errores tipográficos dentro del alfabeto. Para eso verifica el 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);
}

Una comprobación exitosa demuestra que el string es una dirección TRON bien formada. No demuestra que la cuenta exista on-chain ni que alguien posea su key, y no puede distinguir una wallet de un contrato. Para la cuestión del contrato, consulte la chain o revise el explorador.

De dónde vienen las direcciones de wallet: derivación HD en TRON

Cuando una app de wallet le entrega una dirección TRON segundos después de anotar doce palabras, esta es la maquinaria detrás. Las palabras son un mnemónico BIP-39 que se expande en una seed. A partir de la seed, BIP-32 deriva un árbol de pares de keys, siempre el mismo árbol para las mismas palabras. BIP-44 asigna entonces a cada blockchain su propia rama mediante un coin type registrado, y el de TRON es 195, así que la ruta estándar para su primera dirección TRON es m/44'/195'/0'/0/0.

El coin type es el detalle que vale la pena recordar. Ethereum está en el coin type 60, TRON en 195, y ambos números aparecen en un nivel hardened de la ruta. Mismas palabras seed, árboles de keys completamente distintos. Por eso la misma frase de recuperación da una dirección 0x en una wallet EVM y una dirección T sin relación en una wallet TRON, y por eso ninguna de las dos wallets puede ver los fondos de la otra. Si restaura una frase en una wallet exclusiva de Ethereum y su saldo TRON parece haber desaparecido, no se ha perdido nada; la wallet simplemente nunca derivó la rama 195. Restaure las mismas palabras en una wallet con soporte TRON y la dirección, y el saldo, reaparecen.

El índice al final de la ruta se incrementa: .../0/1 es su segunda dirección TRON a partir de las mismas palabras, .../0/2 la tercera. Las wallets personales rara vez van más allá de un puñado. Las plataformas son el caso opuesto, y para ellas, keys generadas independientemente por cliente y registradas mediante una API son la construcción más segura, porque entonces ninguna frase única controla todas las direcciones de depósito del sistema.

Cómo obtener una dirección de wallet TRC20

Hay dos caminos, y cuál necesita depende de si quiere una dirección para usted mismo o muchas direcciones para una aplicación.

El camino de la wallet (una dirección, uso personal)

Instale una wallet compatible con TRON: TronLink es la wallet de navegador estándar de la red, Trust Wallet cubre móvil, Ledger cubre hardware. Cree una cuenta, anote la frase de recuperación fuera de línea, y abra la pantalla de recepción. La dirección T... mostrada ahí es su dirección de wallet TRC20 para USDT y cualquier otro token TRON. No hay fee por crearla ni paso de registro; la dirección funciona en el momento en que la wallet la genera.

El camino de la API (muchas direcciones, para aplicaciones)

Una plataforma que acredita depósitos por cliente necesita una dirección por cliente, y hacer clic mil veces en una UI de wallet no es una opción. Con la API REST de Chaingateway genera keys en su propio entorno y las registra para la red TRON. La autenticación es 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 el header X-Network: testnet la misma llamada apunta al testnet de TRON, así que todo el flujo puede probarse primero con TRX de prueba gratuito. El envío posterior de tokens se hace mediante POST /api/v2/tron/transactions/trc20. El quickstart recorre ambas llamadas; una prueba de 7 días sin onboarding KYC cubre la fase de pruebas, y los planes están en la página de precios.

Aceptar depósitos TRC20: el flujo de webhook

Una vez que cada cliente tiene una dirección, el problema restante es detectar depósitos sin hacer polling a Tronscan. El patrón:

1. Asigne una dirección TRON dedicada por cliente y guarde la correspondencia en su base de datos.
2. Registre un webhook. Cuando un transfer TRC20 llega a la dirección, su endpoint es llamado con los datos de la transacción.
3. Verifique la firma HMAC del webhook, luego acredite al cliente.

Las entregas están firmadas, y una entrega que su endpoint no recibió no se pierde: GET /api/v2/tron/webhooks/notifications/failed lista lo que nunca llegó, y POST /api/v2/tron/webhooks/notifications/{id}/retry la reenvía. Tras una caída, GET /api/v2/tron/webhooks/notifications lista las notificaciones pasadas para reconciliación. Los detalles y el código de firma están en la guía de webhooks.

Un punto específico de TRON: recibir es gratis, pero reenviar depósitos cuesta energy y bandwidth. Desde que la proposal #104 bajó el precio de energy de 210 a 100 Sun, un transfer de USDT cuesta unos 6,4 TRX a una dirección activa y unos 13,4 TRX a una vacía, si paga sin energy stakeado. Planifique los costes de consolidación con la calculadora de fees de TRON; los remitentes habituales reducen el consumo continuo stakeando TRX para energy, lo que la API cubre con POST /api/v2/tron/freeze.