Blog · 4 de novembro de 2026

Transação TRON pendente, expirada ou não encontrada: o que cada uma significa para uma transferência de USDT

A TRON faz um bloco a cada três segundos, então cinco minutos na cadeia são cem blocos. Uma transferência de USDT que ainda aparece como pendente depois disso está em um de quatro lugares: assinada mas nunca transmitida, aceita por um nó mas ainda não num bloco, num bloco que ainda não é irreversível, ou final na cadeia e esperando a plataforma que recebe creditá-la. Duas outras palavras costumam aparecer pelo caminho: um explorador que não acha o hash, e um nó que chama a transação de expirada. Cada uma tem a sua correção, e uma das correções, aplicada cedo demais, paga a mesma transferência duas vezes.

Toda transação carrega o seu próprio prazo

O intervalo entre blocos é uma constante do protocolo, 3,000 milissegundos. O outro número está dentro da transação. Quando uma carteira monta uma transferência, ela escreve um tempo de expiration em raw_data, a parte que é assinada, e todo nó o confere. Uma transação cuja expiração já passou é recusada, e também é recusada uma cuja expiração fica mais de um dia depois do bloco de ponta do nó. A palavra do nó para as duas é TRANSACTION_EXPIRATION_ERROR.

Um segundo par de campos amarra a transação a um bloco recente. ref_block_bytes e ref_block_hash nomeiam um bloco que a rede ainda guarda, e um nó se lembra dos últimos 65,536 blocos, cerca de 54 horas de cadeia. Uma referência mais antiga que isso, ou tirada de uma rede de testes, recebe TAPOS_ERROR. O relógio dos dois começa quando a transação é montada.

Quatro coisas que “pendente” pode significar

Assinada, nunca transmitida

Uma carteira ou um script de pagamentos pode assinar uma transferência e nunca entregá-la a um nó, depois de um timeout ou de uma queda entre assinar e enviar. A transferência tem um hash do mesmo jeito, porque o hash é calculado dos próprios bytes da transação. É o SHA-256 de raw_data, e existe antes de qualquer nó ter visto qualquer coisa. Um hash nos seus logs prova que a transferência foi montada. Um explorador que responde “não encontrada” para ele está certo: nenhum nó de que ele lê tem esses bytes.

Aceita por um nó, ainda não num bloco

Um nó que recebe uma transação responde na hora e a guarda no seu pool de transações pendentes até um bloco levá-la. Aceitação e inclusão são eventos separados, e os status dos nossos próprios pedidos os mantêm separados: no mode B, em que transmitimos uma transferência que o cliente assinou, broadcasted quer dizer que um nó aceitou a transação e ainda não diz nada sobre um bloco. Numa cadeia de três segundos esse estado é curto. Um nó também pode aceitar uma transação que nenhum bloco chega a levar, em geral porque ela saiu desse pool. Uma transferência assim está perdida de vez quando a expiração dela passa.

Num bloco, ainda não irreversível

Os blocos mais novos na ponta da cadeia ainda podem ser substituídos. A TRON mantém um segundo ponteiro atrás da ponta, o último bloco solidificado, que é o mais novo que a rede trata como irreversível, e um nó serve os dois. A distância entre eles é quanto tempo uma transferência fica num bloco sem ser final. Lemos os dois ponteiros uma vez de um nó completo público, com duas chamadas feitas no mesmo instante.

A diferença em números de bloco e a diferença em carimbos de tempo concordam a três segundos por bloco. Os itens do nosso mode B só chegam a confirmed depois da solidificação, que a nossa referência da API põe em cerca de um minuto, e a leitura está de acordo com isso. Isso dá a resposta de costume para quanto tempo uma transferência de USDT leva na TRON: um bloco a cada três segundos, e a finalidade cerca de um minuto depois. É uma leitura única de um só nó. Não medimos como a diferença se move ao longo de um dia, nem os tempos dos nossos próprios pedidos da entrega à transmissão ao bloco.

Final na cadeia, ainda não creditada

Uma exchange ou um processador de pagamentos credita um depósito depois de uma contagem de blocos que ele mesmo define. Não conhecemos a contagem de nenhuma plataforma e não citamos nenhuma. Antes de perguntar à plataforma, leia o resultado escrito ao lado da transferência. Uma transferência pode estar num bloco e ainda assim ter falhado, com a taxa gasta e nenhum token movido, e qualquer coisa diferente de SUCCESS nesse lugar é uma falha (o que OUT_OF_ENERGY quer dizer, e as outras maneiras de uma transferência de USDT falhar). Uma transferência bem-sucedida num bloco solidificado chegou ao endereço do destinatário. O que resta é a contabilidade da plataforma, e o suporte dela consegue rastreá-la pelo hash.

O que expirada quer dizer, e como enviar de novo

Passada a expiração, uma transação não pode entrar em nenhum bloco. Todo nó a recusa, então transmitir de novo os mesmos bytes assinados só colhe outra recusa. A recuperação é uma transação nova: monte a transferência outra vez, com uma expiração nova e uma referência a um bloco recente, e assine.

Remontar não paga duas vezes. Uma transação que nenhum bloco levou nunca foi executada: não moveu token nenhum e não queimou nada, porque uma transferência gasta a sua energia e o seu TRX enquanto roda num bloco. Uma vez que uma transação está num bloco, nenhum nó a executará uma segunda vez. O único jeito de enviar o dinheiro duas vezes é assinar uma substituta enquanto a original ainda pode chegar. Um nó julga a expiração contra o horário do seu bloco de ponta, que pode ficar atrás do seu relógio, então um bloco feito nos últimos segundos antes do prazo ainda pode levar a original, e um nó ou explorador atrasado pode não mostrá-la ainda. O software que montou a original a tem e pode ler raw_data.expiration, em milissegundos desde o epoch. Espere até o último bloco solidificado passar desse instante, o que na nossa leitura leva cerca de um minuto a mais, e então pergunte a um nó pelo hash. Se o nó ainda não conhece a transação, a original não pode mais chegar, e a nova transferência é a única.

Pendente e expirada num pedido de energia

A energia alugada acrescenta um segundo relógio. Quando a energia de um pedido é entregue, o pedido passa a trazer send_before, o aluguel menos três segundos: 297 segundos no aluguel de cinco minutos e 3,597 no de uma hora. A janela é contada a partir da delegação que vimos confirmada, e o aluguel na cadeia começou um bloco e um ciclo de sondagem antes disso, então trate os últimos segundos da janela como já perdidos (quanto tempo a energia alugada dura). Uma transferência que chega a um bloco depois de a energia ter saído da carteira queima o TRX do remetente à taxa do protocolo de 100 sun por unidade, cerca de 6.5 TRX para uma transferência a um endereço que tem USDT.

O que acontece quando a janela fecha depende de quem envia. No mode A você mesmo transmite a transferência. Nós vigiamos a rede, marcamos o item como sent quando a sua transferência aparece, e enviamos o webhook order.item.sent com o hash dela em data.txid. Se nenhuma transferência tiver aparecido até send_before, o item passa a expired e é cobrado, porque a energia foi entregue.

No mode B você nos entrega uma transação assinada e nós a transmitimos assim que a energia chega (como o mode B funciona). O item passa por broadcasting e broadcasted até confirmed, este último só depois da solidificação. Nunca transmitimos depois de send_before: um item que não enviamos a tempo fecha como failed com error: broadcast_window_missed, e a reserva volta inteira. A janela ali também é limitada pela própria expiração da transação, menos uma margem para a transmissão, então uma transação que chega a nós com pouca vida restante recebe uma janela curta.

O mode B confere a expiração também na entrada. Quando recebemos a transação, ela precisa ter pelo menos 180 segundos de vida restante e no máximo 23 horas e 59 minutos. Um prazo longe demais volta como 400 invalid_request com details.reason em expiration_too_far, e vida de menos como o mesmo 400 só com details.index. As duas respostas vêm antes de qualquer energia ser comprada.

O que conferir, em ordem

1. Se algum nó chegou a aceitar a transação. O software que a enviou guarda a resposta do nó, ou não guarda nada porque a transmissão nunca aconteceu. Um hash não resolve nada sozinho, já que existe antes de qualquer transmissão.
2. Se o hash é encontrado, num explorador ou por um nó consultado pelo hash. Se não é encontrado e a expiração ainda está adiante, transmita de novo os mesmos bytes assinados. Se o último bloco solidificado já passou da expiração e o hash continua não encontrado, monte uma transação nova e assine.
3. O resultado ao lado de um hash encontrado. SUCCESS quer dizer que a transferência passou. Qualquer outra coisa quer dizer que ela rodou e falhou, e a taxa já foi gasta.
4. Se o bloco dela está solidificado. Na nossa leitura o bloco irreversível mais novo ficou cerca de um minuto atrás da ponta, então uma transferência bem-sucedida mais nova que isso ainda está se assentando.
5. A contagem de blocos da própria plataforma que recebe, e depois disso o suporte dela, com o hash.
6. Num pedido nosso, o item: sent com o txid dele no mode A, confirmed no mode B. Quando a janela fechou antes, o mode A mostra expired e o mode B mostra failed com error: broadcast_window_missed. Um expired no mode B quer dizer que um nó recusou a transação pelo que ela é, ou que a transação foi revertida num bloco, e ele é cobrado.

Veja um item ficar em ready e depois virar expired sem nada real em jogo: a sandbox tem um destinatário cuja transferência nunca chega →