Blog · 4 de noviembre de 2026

Transacción TRON pendiente, caducada o no encontrada: qué significa cada una para una transferencia USDT

TRON hace un bloque cada tres segundos, así que cinco minutos en la cadena son cien bloques. Una transferencia USDT que sigue apareciendo como pendiente pasado ese tiempo está en uno de cuatro sitios: firmada pero nunca emitida, aceptada por un nodo pero todavía no en un bloque, en un bloque que aún no es irreversible, o definitiva en la cadena y a la espera de que la plataforma receptora la acredite. Otras dos palabras suelen aparecer por el camino: un explorador que no encuentra el hash, y un nodo que llama caducada a la transacción. Cada una tiene su solución, y una de las soluciones, aplicada demasiado pronto, paga dos veces la misma transferencia.

Cada transacción lleva su propia fecha límite

El intervalo entre bloques es una constante del protocolo, 3,000 milisegundos. El otro número está dentro de la transacción. Cuando una cartera construye una transferencia escribe un tiempo de expiration en raw_data, la parte que se firma, y todos los nodos lo comprueban. Una transacción cuya expiración ya pasó se rechaza, y también una cuya expiración queda a más de un día por delante del bloque más reciente del nodo. La palabra del nodo para ambos casos es TRANSACTION_EXPIRATION_ERROR.

Un segundo par de campos ata la transacción a un bloque reciente. ref_block_bytes y ref_block_hash nombran un bloque que la red todavía conserva, y un nodo recuerda los últimos 65,536 bloques, unas 54 horas de cadena. Una referencia más antigua que eso, o una tomada de una red de pruebas, recibe en cambio TAPOS_ERROR. El reloj de ambas empieza cuando se construye la transacción.

Cuatro cosas que puede significar «pendiente»

Firmada, nunca emitida

Una cartera o un script de pagos puede firmar una transferencia y no entregársela nunca a un nodo, por un tiempo de espera agotado o una caída entre la firma y el envío. La transferencia tiene hash de todos modos, porque el hash se calcula a partir de los propios bytes de la transacción. Es el SHA-256 de raw_data, y existe antes de que ningún nodo haya visto nada. Un hash en sus registros demuestra que la transferencia se construyó. Un explorador que responde «no encontrada» para él tiene razón: ningún nodo del que lee tiene esos bytes.

Aceptada por un nodo, aún no en un bloque

Un nodo que recibe una transacción responde al instante y la mantiene en su grupo de transacciones pendientes hasta que un bloque la incluye. Aceptación e inclusión son sucesos distintos, y los estados de nuestros propios pedidos los mantienen separados: en el mode B, donde emitimos una transferencia que firmó el cliente, broadcasted significa que un nodo aceptó la transacción y todavía no dice nada de un bloque. En una cadena de tres segundos este estado es corto. Un nodo también puede aceptar una transacción que ningún bloque llega a incluir, normalmente porque se descartó de ese grupo. Una transferencia así se pierde para siempre cuando pasa su expiración.

En un bloque, aún no irreversible

Los bloques más nuevos en la punta de la cadena aún pueden ser sustituidos. TRON mantiene un segundo puntero detrás de la punta, el último bloque solidificado, que es el más reciente que la red trata como irreversible, y un nodo sirve los dos. La distancia entre ambos es el tiempo que una transferencia pasa en un bloque sin ser definitiva. Leímos los dos punteros una vez de un nodo completo público, con dos llamadas hechas en el mismo momento.

La distancia en números de bloque y la distancia en marcas de tiempo concuerdan a tres segundos por bloque. Nuestros ítems del mode B llegan a confirmed solo tras la solidificación, que nuestra referencia de la API sitúa en torno a un minuto, y la lectura va en línea con eso. Eso da la respuesta habitual a cuánto tarda una transferencia USDT en TRON: un bloque cada tres segundos y la finalidad como un minuto después. Es una sola lectura de un nodo. No hemos medido cómo se mueve la distancia a lo largo de un día, ni los tiempos de nuestros propios pedidos desde la entrega hasta la emisión y el bloque.

Definitiva en la cadena, aún no acreditada

Un exchange o un procesador de pagos acredita un depósito tras un número de bloques que fija por su cuenta. No conocemos el número de ninguna plataforma y no citamos ninguno. Antes de preguntar a la plataforma, lea el resultado escrito junto a la transferencia. Una transferencia puede estar en un bloque y haber fallado, con la comisión gastada y sin tokens movidos, y cualquier cosa distinta de SUCCESS en ese lugar es un fallo (qué significa OUT_OF_ENERGY, y las otras formas en que falla una transferencia USDT). Una transferencia exitosa en un bloque solidificado ha llegado a la dirección del destinatario. Lo que queda es la contabilidad de la plataforma, y su soporte puede rastrearla a partir del hash.

Qué significa caducada, y cómo enviar de nuevo

Pasada su expiración, una transacción no puede entrar en ningún bloque. Todos los nodos la rechazan, así que emitir otra vez los mismos bytes firmados solo cosecha otro rechazo. La recuperación es una transacción nueva: construya de nuevo la transferencia, con una expiración nueva y una referencia a un bloque reciente, y fírmela.

Reconstruir no paga dos veces. Una transacción que ningún bloque incluyó nunca se ejecutó: no movió tokens y no quemó nada, porque una transferencia gasta su energía y su TRX mientras se ejecuta en un bloque. Una vez que una transacción está en un bloque, ningún nodo la ejecutará una segunda vez. La única manera de enviar el dinero dos veces es firmar un reemplazo mientras el original aún pueda incluirse en un bloque. Un nodo juzga la expiración frente a la hora de su bloque más reciente, que puede ir por detrás de su reloj, así que un bloque hecho en los últimos segundos antes de la fecha límite todavía puede incluir el original, y un nodo o explorador retrasado puede no mostrarlo aún. El software que construyó el original lo conserva y puede leer raw_data.expiration, en milisegundos desde el epoch. Espere hasta que el último bloque solidificado esté más allá de ese momento, lo que en nuestra lectura lleva alrededor de un minuto más, y luego pregunte a un nodo por el hash. Si el nodo sigue sin conocer la transacción, el original ya no puede incluirse, y la transferencia nueva es la única.

Pendiente y caducada en un pedido de energía

La energía alquilada añade un segundo reloj. Cuando se entrega la energía de un pedido, el pedido lleva send_before, el alquiler menos tres segundos: 297 segundos en el alquiler de cinco minutos y 3,597 en el de una hora. La ventana se cuenta desde la delegación que vimos confirmada, y el alquiler en la cadena empezó un bloque y un ciclo de consulta antes, así que dé por perdidos los últimos segundos de la ventana (cuánto dura la energía alquilada). Una transferencia que llega a un bloque cuando la energía ya se ha ido de la cartera quema el TRX del remitente a la tarifa del protocolo de 100 sun por unidad, unos 6.5 TRX para una transferencia a una dirección que tiene USDT.

Lo que pasa cuando se cierra la ventana depende de quién envía. En el mode A usted emite la transferencia. Nosotros vigilamos la red, marcamos el ítem como sent cuando aparece su transferencia, y enviamos el webhook order.item.sent con su hash en data.txid. Si no ha aparecido ninguna transferencia para send_before, el ítem pasa a expired y se cobra, porque la energía se entregó.

En el mode B usted nos entrega una transacción firmada y la emitimos en cuanto llega la energía (cómo funciona el mode B). El ítem pasa por broadcasting y broadcasted hasta confirmed, este último solo tras la solidificación. Nunca emitimos después de send_before: un ítem que no enviamos a tiempo se cierra como failed con error: broadcast_window_missed, y la reserva vuelve entera. Allí la ventana también está limitada por la propia expiración de la transacción, menos un margen para la emisión, así que una transacción que nos llega con poca vida restante recibe una ventana corta.

El mode B también comprueba la expiración a la entrada. Cuando recibimos la transacción necesita al menos 180 segundos de vida restante y no más de 23 horas y 59 minutos. Una fecha límite demasiado lejana vuelve como 400 invalid_request con details.reason en expiration_too_far, y muy poca vida como el mismo 400 solo con details.index. Las dos respuestas llegan antes de que se compre ninguna energía.

Qué comprobar, por orden

1. Si algún nodo llegó a aceptar la transacción. El software que la envió conserva la respuesta del nodo, o no conserva nada porque la emisión nunca ocurrió. Un hash por sí solo no resuelve nada, porque existe antes de cualquier emisión.
2. Si el hash se encuentra, en un explorador o preguntando por el hash a un nodo. Si no se encuentra y la expiración aún no ha llegado, emita otra vez los mismos bytes firmados. Si el último bloque solidificado ya pasó la expiración y el hash sigue sin encontrarse, construya una transacción nueva y fírmela.
3. El resultado junto a un hash que se encuentra. SUCCESS significa que la transferencia se completó. Cualquier otra cosa significa que se ejecutó y falló, y la comisión ya está gastada.
4. Si su bloque está solidificado. En nuestra lectura el bloque irreversible más reciente iba por detrás de la punta en cerca de un minuto, así que una transferencia exitosa más reciente que eso aún se está asentando.
5. El propio número de bloques de la plataforma receptora y, después, su soporte, con el hash.
6. En un pedido nuestro, el ítem: sent con su txid en el mode A, confirmed en el mode B. Cuando la ventana se cerró antes, el mode A muestra expired y el mode B muestra failed con error: broadcast_window_missed. Un expired en el mode B significa que un nodo rechazó la transacción por lo que es, o que la transacción se revirtió en un bloque, y se cobra.

Vea cómo un ítem se queda en ready y luego pasa a expired sin nada real en juego: el entorno de pruebas tiene un destinatario cuya transferencia nunca llega →