Por qué el exchange aún no detecta los BTC, ETH o USDT enviados

Que una cartera marque una operación como «enviada» no significa necesariamente que el exchange ya pueda reconocerla o acreditarla. La transferencia puede no haberse difundido correctamente, seguir pendiente, estar confirmada en una red distinta, haber fallado al ejecutar un token o encontrarse a la espera de las comprobaciones internas del servicio. El diagnóstico exige revisar el hash, la red, el activo, la dirección de depósito y el estado real en la cadena; sin esos datos no es posible atribuir una causa concreta. ^[1]

Cómo se comprobaron los puntos decisivos

El análisis utiliza documentación primaria de Bitcoin, Ethereum, TRON y Tether disponible al 26 de septiembre de 2026. Se priorizaron las descripciones oficiales del ciclo de una transacción, la mempool, la inclusión en bloques, la finalización y los protocolos en los que existe USDT. Las condiciones particulares de acreditación de un exchange —número de confirmaciones, redes aceptadas, mantenimiento, límites o controles de cumplimiento— son datos dinámicos y deben verificarse en la solicitud concreta.

No se emplean cálculos de tiempo, comisiones ni probabilidades. Tampoco se presupone que una red o un par determinado estén disponibles: incluso si el servicio admite BTC, ETH o USDT como activos, la aceptación de una blockchain específica debe comprobarse antes de enviar fondos.

Qué significa realmente «el exchange no ve la transferencia»

Conviene separar dos situaciones que suelen describirse con la misma frase:

• La operación no aparece como detectada: el sistema todavía no ha asociado una transacción de la red con la dirección y la solicitud de intercambio.
• La operación aparece, pero no está acreditada: el depósito fue localizado, aunque aún no cumple las confirmaciones, validaciones operativas o controles aplicables.

En Bitcoin, una transacción sin confirmar puede estar en la mempool de uno o varios nodos sin haber entrado en un bloque. Además, la información de una mempool representa la vista de un nodo y no necesariamente una lista completa y universal de todas las operaciones pendientes. Una transacción incluida en un bloque empieza a acumular confirmaciones a medida que se añaden bloques posteriores. ^[2]

En Ethereum, la operación se difunde primero y entra en un conjunto de transacciones pendientes. Después, un validador debe seleccionarla e incluirla en un bloque; con el avance de la cadena, ese bloque pasa por estados de mayor seguridad hasta llegar a la finalización. Por tanto, disponer de un hash no demuestra por sí solo que la transferencia ya se haya ejecutado con éxito. ^[3]

TRON también distingue entre difusión, validación, inclusión en un bloque y solidificación. Esto importa especialmente cuando USDT se envía como token TRC-20: la existencia de una operación en la cartera remitente no sustituye la comprobación de su estado en la red. ^[4]

Las causas más frecuentes, ordenadas por el estado del hash

El hash no aparece en el explorador de la red elegida

Este resultado puede indicar que la cartera todavía no difundió la transacción, que el proveedor de retirada solo creó un registro interno, que se copió un identificador incorrecto o que el hash se está buscando en un explorador perteneciente a otra blockchain. En Bitcoin también pueden existir diferencias temporales entre la información observada por distintos nodos. ^[2]

No conviene repetir el envío de inmediato: si la primera operación termina propagándose, podrían producirse dos pagos. Primero hay que confirmar con la plataforma emisora si el identificador corresponde a una transacción realmente transmitida a la red.

La transacción figura como pendiente

Una operación pendiente todavía no ha alcanzado el estado necesario para considerarla asentada. En Ethereum debe ser incluida por un validador; en Bitcoin permanece sin confirmar mientras no entre en un bloque. La prioridad también puede depender de las reglas de selección y retransmisión de cada red y de la relación de la transacción con otras operaciones pendientes. La documentación de Bitcoin Core 31.0, por ejemplo, describe la ordenación de transacciones en la mempool según su tasa de comisión y sus relaciones de dependencia. ^[3]

No puede deducirse un plazo exacto únicamente a partir de la palabra «pendiente». La cartera o plataforma remitente puede ofrecer mecanismos específicos para gestionar la operación, pero deben seguirse sus instrucciones: intentar reemplazarla o acelerarla sin comprender el procedimiento puede complicar la identificación del depósito.

Está confirmada, pero la dirección no coincide

El explorador debe mostrar como destinataria la misma dirección que figuraba en la solicitud. Hay que comparar la cadena completa de caracteres, no solo el principio y el final. Si la dirección es diferente, la transacción puede ser válida en la blockchain y, al mismo tiempo, no pertenecer al depósito esperado.

Una operación confirmada no puede ser cancelada por el exchange receptor. La posibilidad de recuperación depende de quién controle las claves de la dirección, de la arquitectura de custodia y de las políticas del servicio; no debe darse por garantizada. Ante una discrepancia, es importante conservar el hash, la dirección copiada originalmente y cualquier comprobante de la solicitud.

USDT se envió por una red distinta

USDT no identifica por sí solo una única blockchain. Tether publica protocolos distintos, entre ellos ERC-20 en Ethereum y TRC-20 en TRON, además de otras redes. Su documentación pide comprobar cuidadosamente el protocolo correspondiente a la dirección de destino. Que dos variantes utilicen el mismo nombre de activo no permite tratarlas como un único canal de depósito. ^[5]

Por ejemplo, una solicitud preparada para recibir USDT mediante una red no queda satisfecha automáticamente por una transferencia realizada en otra. Incluso cuando el formato de las direcciones parece compatible, el sistema del exchange debe admitir expresamente la red utilizada y controlar la dirección dentro de ella. La recuperación de un envío por una red no aceptada puede ser imposible o requerir una revisión técnica; depende del control efectivo de las claves y no constituye una función garantizada.

La transacción de ETH o de un token está incluida, pero falló

En Ethereum, una transferencia de ETH y una transferencia de un token ERC-20 no se verifican exactamente igual. El envío de un token consiste en ejecutar una función de su contrato. El estándar ERC-20 define funciones de transferencia y un evento Transfer, que permite comprobar el movimiento del token entre direcciones. Por eso no basta con que el hash aparezca en un bloque: hay que revisar que la ejecución sea satisfactoria, que el contrato corresponda al token esperado y que el evento muestre la dirección y el importe correctos. ^[6]

Una operación fallida puede haber consumido la comisión de red sin trasladar los tokens al destinatario. En ese caso, el exchange no tiene un depósito que acreditar, aunque la transacción exista en el historial.

Todo coincide en la cadena, pero el saldo aún no cambia

Si el hash es válido, la ejecución fue satisfactoria, la red es la correcta y la dirección coincide, la causa deja de ser puramente blockchain. Puede faltar el umbral de confirmaciones exigido por ese servicio, la asociación con la solicitud, una actualización del sistema de depósitos o una comprobación de cumplimiento aplicable a la operación. No es posible determinar cuál de estas causas interviene solo con datos públicos del explorador.

Los requisitos de verificación dependen del sentido de la operación y del resultado de los controles de cumplimiento. También pueden variar las redes admitidas y las condiciones de depósito. Deben consultarse los requisitos vigentes de la solicitud antes de transferir, sin asumir que una configuración utilizada anteriormente continúa disponible.

Registro de afirmaciones

Tesis que determinan el diagnóstico y sus límites de verificación

Estado	Afirmación decisiva	Tipo y fuente primaria	Fecha de publicación o actualización	Limitación	Qué podría cambiar la conclusión
Confirmada	Una transacción difundida pero no incluida en un bloque aún no está confirmada.	Documentación técnica de Bitcoin sobre red P2P y procesamiento de pagos; documentación de Ethereum sobre el ciclo de las transacciones. [1]	Bitcoin: la página técnica no muestra una fecha visible; Ethereum: actualizada el 25 de julio de 2026.	La documentación explica el protocolo, no los criterios particulares de acreditación de cada exchange.	La inclusión de la operación en un bloque y las confirmaciones posteriores.
Confirmada	La mempool observada por un nodo de Bitcoin no representa necesariamente una vista completa de todas las transacciones pendientes.	Referencia oficial para desarrolladores de Bitcoin sobre el mensaje de mempool. [2]	No se indica una fecha de actualización visible.	La ausencia en una fuente de datos aislada no prueba por sí sola que nunca se difundiera la operación.	La aparición del hash en otros nodos, su inclusión en un bloque o la confirmación del emisor de que no fue transmitido.
Confirmada	USDT existe en más de una blockchain y debe coincidir el protocolo de envío con el aceptado por el destinatario.	Página oficial de Tether sobre protocolos e instrucciones de integración; preguntas frecuentes oficiales. [5]	No se muestra una fecha de actualización; contenido consultado el 26 de septiembre de 2026.	Que Tether reconozca un protocolo no significa que un exchange concreto acepte depósitos mediante él.	Los cambios de Tether en sus protocolos y, sobre todo, la lista vigente de redes admitidas por el exchange.
Dependiente de condiciones	Una transferencia ERC-20 debe mostrar una ejecución satisfactoria y el movimiento del token esperado, no solo un hash incluido.	Documentación oficial de Ethereum sobre ERC-20, recibos y eventos Transfer. [6]	La página del estándar no ofrece una fecha visible; el tutorial fue publicado originalmente en 2020.	La interpretación concreta depende del contrato del token y de los datos contenidos en el recibo de la transacción.	El estado de ejecución, el contrato identificado y los registros de transferencia del recibo.
Dependiente de condiciones	El número de confirmaciones y el momento de acreditación son reglas del exchange, no una constante común para BTC, ETH y USDT.	La fuente primaria necesaria sería la solicitud activa, las reglas de depósito vigentes y los registros internos del servicio.	No verificable públicamente para una operación individual.	Sin los datos de la solicitud no puede fijarse un umbral ni un plazo.	La red, el activo, la dirección operativa, el estado del sistema y el resultado de las comprobaciones de cumplimiento.
Desconocida sin datos de la operación	La causa exacta por la que un depósito específico no aparece.	Se necesitan el hash, la red declarada, la dirección, el activo, la solicitud y la respuesta del servicio.	No aplicable.	Un explorador solo muestra la parte registrada en la blockchain; no muestra necesariamente el procesamiento interno del exchange.	La comprobación conjunta de los datos de la cadena y del registro de la solicitud.

Para iniciar una operación nueva o contrastar la información mostrada en una solicitud, puede comprobar los activos, redes y direcciones de intercambio disponibles actualmente. Esta consulta práctica no sustituye la verificación independiente del hash en la blockchain ni constituye una fuente para las afirmaciones técnicas anteriores.

Procedimiento de diagnóstico para el usuario

1. Obtén el hash real. No confundas el identificador interno de una retirada con el TXID o hash de la blockchain.
2. Identifica la red exacta. Para USDT, anota el protocolo seleccionado; para ETH, confirma si se usó Ethereum u otra red compatible; para BTC, comprueba que se trate de la red indicada en la solicitud.
3. Busca el hash en el explorador correspondiente. Un explorador de Ethereum no mostrará una operación de TRON, y viceversa.
4. Revisa el estado. Distingue entre no encontrada, pendiente, confirmada con éxito y fallida.
5. Compara el destinatario. La dirección del explorador debe coincidir exactamente con la proporcionada para el depósito.
6. Comprueba el activo transferido. En tokens, verifica también el contrato y el evento de transferencia; no te guíes únicamente por el símbolo visible en una cartera.
7. Revisa las confirmaciones y la solicitud. El hecho de estar incluida en un bloque no obliga al exchange a acreditarla antes de alcanzar sus condiciones vigentes.
8. Escala el caso con datos completos. Si todo coincide, facilita a soporte el identificador de la solicitud, hash, red, activo, importe, dirección receptora y estado mostrado por el explorador.

Riesgos que requieren especial atención

• Red equivocada: es posible que el envío sea válido en la blockchain seleccionada, pero incompatible con el depósito solicitado.
• Dirección sustituida: programas maliciosos pueden alterar el contenido del portapapeles. La comparación debe realizarse antes de firmar.
• Phishing: no introduzcas frases semilla ni claves privadas en páginas de seguimiento o formularios de supuesto soporte. El hash es público y basta para consultar una transacción.
• Irreversibilidad: una transferencia confirmada a una dirección incorrecta no puede deshacerse como un pago bancario convencional.
• Volatilidad: mientras un depósito está pendiente, el valor de mercado de BTC, ETH o USDT frente a otras monedas puede variar; la comprobación técnica no elimina ese riesgo.
• Reglas nacionales: las obligaciones de identificación, origen de fondos, fiscalidad y disponibilidad del servicio pueden diferir según el país. Este análisis no sustituye asesoramiento jurídico o tributario.

Cómo repetir la verificación sin depender de datos obsoletos

Antes de cada envío, conviene repetir una secuencia breve porque las redes aceptadas, las direcciones de depósito y los requisitos operativos pueden cambiar:

• crea o abre la solicitud vigente y no reutilices automáticamente una dirección antigua;
• lee el nombre completo de la red, no solo el ticker del activo;
• confirma que las retiradas estén habilitadas en la plataforma emisora y los depósitos en la receptora;
• realiza, cuando resulte apropiado y esté permitido, una transferencia inicial limitada para comprobar la ruta, teniendo en cuenta las comisiones y mínimos mostrados en ese momento;
• guarda el hash y una copia de los datos de la solicitud;
• si el estado cambia, vuelve a revisar el mismo hash en el explorador correcto en lugar de crear conclusiones a partir de capturas antiguas.

Conclusión: el primer dato decisivo es el hash en la red correcta. Si no existe o está pendiente, el problema se encuentra antes de la acreditación. Si aparece como exitoso, hay que verificar dirección, activo, contrato y protocolo. Solo cuando todos esos elementos coinciden tiene sentido investigar confirmaciones pendientes, asociación con la solicitud, mantenimiento o controles internos del exchange. Sin el hash y los datos de la orden, cualquier explicación más precisa sería una suposición.