Validador de direcciones cripto

Qué comprueba esta herramienta, y qué no puede comprobar

Detrás de «¿esta dirección es válida?» se esconden dos preguntas distintas. La primera es si la cadena está bien formada: longitud correcta, alfabeto correcto, checksum intacto. Esa pregunta tiene una respuesta definida, y esta página la responde en su navegador sin enviar la dirección a ningún sitio. La segunda es si la dirección existe, tiene saldo, o pertenece a la persona que se la dio. Ningún verificador sin conexión puede responder eso, y cualquier herramienta que diga hacerlo está leyendo una blockchain, no la cadena de caracteres.

La distinción importa porque los dos modos de fallo no se parecen en nada. Una dirección malformada se detecta aquí y en cualquier wallet, así que una errata en una dirección de TRON es una molestia, no una pérdida. Una dirección bien formada que pertenece a la persona equivocada es invisible para cualquier verificador jamás escrito.

TRON: Base58Check, verificado hasta el checksum

Una dirección de TRON tiene 34 caracteres y empieza por T. Detrás de esa cadena hay 25 bytes: un byte de versión, 20 bytes de dirección y un checksum de 4 bytes. El byte de versión es 0x41 en mainnet, y es la razón por la que toda dirección se renderiza con una T inicial una vez codificados los 25 bytes en Base58.

El checksum son los primeros cuatro bytes de SHA-256(SHA-256(payload)), donde el payload es el byte de versión más los 20 bytes de dirección. Esta página calcula ese hash de verdad, usando la propia Web Crypto API del navegador, y lo compara con los cuatro bytes que lleva la dirección. Un solo carácter alterado produce un payload distinto, un hash distinto y un desajuste. Ese es todo el mecanismo, y es la razón por la que una dirección de TRON mal escrita se rechaza en lugar de aceptarse en el vacío.

Base58 también deja fuera de su alfabeto cuatro caracteres a propósito: cero, O mayúscula, I mayúscula y l minúscula. Son los pares que la gente confunde al leer una dirección en voz alta o al copiarla a mano, y eliminarlos hace que esas confusiones no puedan producir otra dirección válida distinta. Si el verificador informa de un carácter fuera del alfabeto, uno de esos cuatro suele ser el culpable.

Una cosa que el formato no le dice: si la dirección es una wallet o un contrato de token. Ambos usan la misma forma con prefijo T en TRON. El contrato de USDT, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, es una dirección válida según cualquier comprobación de esta página, y enviarle un depósito sigue siendo un error. La página sobre direcciones TRC20 trata esa distinción y la notación hexadecimal con más detalle.

Ethereum y BSC: un formato, dos chains

Una dirección EVM es 0x seguido de 40 caracteres hexadecimales, 42 caracteres en total. Ethereum, BNB Smart Chain, Polygon y Arbitrum usan todos ese formato, porque comparten la misma capa de ejecución y la misma derivación de claves. Eso tiene una consecuencia que conviene decir con claridad: no existe forma de distinguir una dirección ERC-20 de una BEP-20 con solo mirarla. La cadena es la misma. Lo que difiere es la red a la que envía la transacción, y los saldos que existen en cada chain.

Aquí es de donde vienen la mayoría de las pérdidas entre chains. Una dirección perfectamente válida en Ethereum es igual de válida en BSC, así que una wallet enviará sin problema tokens BEP-20 a una dirección que el destinatario solo vigila en Ethereum. Los fondos no desaparecen, quedan en la otra chain, pero recuperarlos necesita la clave privada y una wallet configurada para esa red. La página sobre direcciones ERC20 y la página sobre direcciones BEP20 tratan el lado práctico de esto, incluyendo en qué se diferencia BEP-20 del formato BEP-2 anterior, que empieza por bnb1 y no es intercambiable con nada de lo tratado aquí.

EIP-55: el checksum escondido en las mayúsculas

El hexadecimal no distingue mayúsculas de minúsculas, así que 0xab… y 0xAB… apuntan a la misma cuenta. EIP-55 pone esa capacidad sobrante a trabajar: se aplica Keccak-256 a la dirección en minúsculas, y cada nibble del hash decide si la letra hexadecimal correspondiente se escribe en mayúscula o minúscula. El resultado parece una dirección normal en mayúsculas y minúsculas mezcladas y lleva aproximadamente cuatro bits de detección de errores por letra.

Así que una dirección EVM en mayúsculas y minúsculas mezcladas está haciendo una afirmación, y una toda en minúsculas o toda en mayúsculas no lo está. Ambas son una entrada válida para cualquier wallet y cualquier nodo. Solo la de mayúsculas y minúsculas mezcladas se puede verificar.

Esta página informa de cuál de las dos ha pegado, y se detiene ahí. Verificar el checksum EIP-55 necesita una implementación de Keccak-256, y la Web Crypto API del navegador no ofrece Keccak, sino SHA-256, que es lo que usa la comprobación de TRON de arriba. En lugar de incluir una función hash escrita a mano para una comprobación relevante para la seguridad, la herramienta le dice qué no verificó. Si su dirección viene de la interfaz de una wallet, casi con toda seguridad ya lleva un checksum correcto; si viene de una base de datos o un archivo de log, vale la pena ejecutar una verificación EIP-55 completa en su propio código, donde una librería probada está a un import de distancia.

De dónde vienen las direcciones en una integración

Validar una dirección pegada es la última línea de defensa. La anterior es no pegar direcciones en absoluto. En un flujo de pagos o pagos salientes, las direcciones de depósito se generan por cliente y se vigilan de forma programática, así que ningún humano vuelve a teclear ninguna y la cuestión del formato nunca se plantea.

Ese es el trabajo que hacen la API de TRON y los endpoints equivalentes de Ethereum y BSC: crear una dirección, registrar un webhook para ella, acreditar el depósito cuando llega la notificación. Las direcciones siguen siendo non-custodial, y la prueba dura siete días sin tarjeta de crédito ni KYC. Vale la pena conocer dos detalles operativos antes de construir sobre esto: los webhooks no tienen reintento automático, así que una entrega fallida se recupera con POST /<chain>/webhooks/notifications/failed en lugar de esperar un reenvío, y Solana no tiene ningún soporte de webhooks.

Las demás calculadoras de este sitio están listadas en el resumen de herramientas.

Preguntas frecuentes

¿La dirección sale de mi navegador?

No. Tanto la decodificación Base58 como el hashing SHA-256 se ejecutan localmente, a través de la Web Crypto API del navegador. No hay ninguna solicitud a un servidor, lo que también significa que la herramienta funciona sin conexión de red.

¿Qué se verifica exactamente en una dirección TRON?

Cuatro cosas: que la cadena tenga 34 caracteres, que todos los caracteres estén en el alfabeto Base58, que decodifique a 25 bytes con el byte de versión 0x41, y que los últimos cuatro bytes coincidan con los primeros cuatro bytes de SHA-256(SHA-256(payload)). El checksum se calcula, no se da por supuesto.

¿Puede distinguir una dirección ERC-20 de una BEP-20?

No, y nada puede hacerlo. Ambos estándares usan el mismo formato de 0x seguido de 40 caracteres hexadecimales. Una herramienta que afirme distinguirlas o bien está adivinando, o bien está consultando saldos en una blockchain, que es una pregunta distinta de la validez de la dirección.

¿Por qué no se verifica el checksum EIP-55?

Porque necesita Keccak-256, que la criptografía integrada del navegador no ofrece, y esta página no incluye una implementación propia de hash para una comprobación de la que la gente dependería. Lo que la página sí indica es si la dirección está escrita en mayúsculas y minúsculas mezcladas, lo que significa que lleva un checksum EIP-55, o en un solo caso, lo que significa que no lleva ninguno.

¿Una dirección válida significa que los fondos llegarán?

No. La validez es una propiedad de la cadena de texto. Si la dirección está monitorizada, si pertenece a la cadena desde la que envía, y si es del destinatario previsto, son preguntas distintas que ninguna comprobación sin conexión puede resolver.

¿Por qué Base58 se salta algunos caracteres?

El cero, la O mayúscula, la I mayúscula y la l minúscula se excluyen porque se confunden fácilmente entre sí. Dejarlos fuera evita que una lectura ambigua produzca en silencio una dirección distinta pero también válida.

¿Cuál es la forma hexadecimal de una dirección TRON?

Los mismos 21 bytes de payload escritos en hexadecimal: 41 seguido de 40 caracteres hexadecimales. La TVM usa esa forma internamente, las wallets muestran la forma Base58Check. La forma hexadecimal no lleva checksum, así que no hay nada que verificar en ella.

¿Una dirección de contrato es una dirección válida?

Sí, según cualquier comprobación de formato. En TRON y en las cadenas EVM, las direcciones de contrato y las direcciones de wallet son indistinguibles por su forma. Enviar un depósito a un contrato de token supera la validación y aun así pierde los fondos, por eso la validación de direcciones es una comprobación de formato y no una comprobación de seguridad.