Blog · 5 de novembro de 2026

Varrer o USDT dos endereços de depósito na TRON: ativação, energia e bandwidth por varredura

Um gateway de pagamentos ou uma exchange que dá a cada cliente um endereço de depósito próprio precisa juntar o USDT TRC-20 desses endereços numa carteira principal, a carteira quente, antes de poder pagar qualquer parte dele. Na TRON, cada um desses movimentos é uma transferência de USDT comum, assinada pelo endereço de depósito. Ela exige uma conta na cadeia, energia para a chamada de contrato e bandwidth para os bytes, e um endereço de depósito que só foi pago em USDT até hoje não tem nenhum dos três.

Receber USDT não cria uma conta

Um saldo de USDT é uma entrada no armazenamento do próprio contrato do token. Uma transferência de entrada escreve essa entrada e não cria conta nenhuma, então um endereço pode ter USDT sem que a rede tenha conta alguma para ele. A nossa medição de 7 de setembro de 2026 achou dois endereços assim na mainnet: cada um tinha USDT, e o nó de que lemos devolveu um objeto vazio quando perguntamos pela conta por trás dele, tanto antes da nossa chamada de teste quanto depois. Em 27 de outubro os dois ainda tinham exatamente os saldos que tinham em 7 de setembro.

A energia é delegada a uma conta, e não a entregamos a um endereço que não tem nenhuma: um pedido no mode A ou no mode C que nomeie um endereço assim como from volta com 422 invalid_address e details.reason em inactive_wallet. Se a própria cadeia aceitaria uma delegação a um endereço assim, não testamos, porque a nossa recusa vem primeiro. As nossas notas de operação também registram a resposta do nó a um envio de uma carteira que nunca recebeu nada, no OwnerAccount. Essa nota é sobre TRX enviado da nossa própria carteira quente; não tentamos uma transferência de USDT saindo de um endereço nesse estado. A história mais ampla desse estado está no texto sobre contas não ativadas.

Ativar um endereço leva uma transferência de TRX, paga por quem envia

Qualquer transferência de TRX recebida cria a conta, por menor que seja, e a partir daí o endereço é uma conta como qualquer outra. A primeira tentativa daquela medição deu errado justamente nisso, e a descartamos: um endereço foi lido como sem conta, e 22 segundos depois alguém lhe enviou um único sun, o que criou uma. O próprio horário de criação dela dizia isso.

A taxa de criação cai sobre quem envia o TRX: numa estrutura de varredura, a carteira que financia as ativações. Dois parâmetros da cadeia a definem. Nós os lemos em 3 de setembro de 2026, e a rede pode alterá-los, então leia-os de novo antes de orçar com eles.

Como os dois se combinam numa transferência simples de TRX, não medimos com um envio nosso: isso exige uma transferência real a um endereço novo, e não fizemos nenhuma. De um jeito ou de outro, a taxa é paga uma vez por endereço. Uma mesa que ativa todo endereço quando ele é gerado a paga em endereços que talvez nunca recebam um depósito, e uma que ativa no primeiro depósito só a paga onde há algo para varrer.

Toda varredura leva o valor menor de energia

O que uma transferência de USDT gasta em energia depende do destinatário. Quando o destinatário já tem USDT, a transferência leva cerca de 65,000 unidades; quando o saldo de USDT dele é zero, leva cerca de 131,000. Se o destinatário tem conta ou não, isso não entra. A medição que achou aqueles dois endereços pôs as quatro combinações lado a lado, e o saldo decidiu todas as vezes (por que há dois valores).

Uma varredura paga sempre o mesmo destinatário, a carteira quente, e a carteira quente tem USDT. Então toda varredura é do tipo mais barato, single, seja qual for o estado do endereço de depósito. As chamadas de 7 de setembro moveram uma unidade de uma carteira que ficou com o resto, enquanto uma varredura move tudo e deixa o endereço de depósito em zero. Em 27 de outubro pedimos ao nó que simulasse as duas coisas nos mesmos dois endereços, com uma carteira que tem USDT como destinatário.

Esvaziar o endereço de depósito não mudou nada, e o valor é o que aquela medição deu para toda transferência a um destinatário que tem USDT. São simulações do nó, e nenhuma delas é o recibo de uma varredura transmitida; os valores de 7 de setembro têm a mesma ressalva. Se os dois endereços têm conta hoje, não voltamos a ler.

O único jeito de perder o tipo mais barato é esvaziar a carteira quente. Uma única unidade de USDT no destinatário basta para o valor menor, mas em zero a próxima varredura para dentro dela leva cerca de 131,000 unidades, que são 13.1 TRX se queimadas. Queimada, uma varredura normal custa 6.5 TRX à taxa do protocolo de 100 sun por unidade, e quanto custa alugar a mesma energia se move com o mercado.

O bandwidth de graça cobre cerca de uma varredura por endereço por dia

O bandwidth mede os bytes de uma transação, onde a energia mede a computação dela (os dois medidores lado a lado). Toda conta recebe uma cota diária de graça dele. A transferência de USDT que enviamos e medimos na mainnet em 2 de setembro de 2026 pagou o bandwidth em TRX, e isso dá exatamente quanto de bandwidth foi cobrado dela.

Contra 600 por dia, uma varredura cobrada nesse valor cabe e duas seguidas não. Passada a cota, a rede queima o TRX do remetente pelos bytes. Então a primeira varredura de um endereço no dia não custa nada em bandwidth, e um endereço de depósito que também recebe a energia por delegação não precisa de TRX próprio para enviá-la. Uma segunda varredura logo depois da primeira paga os bytes dela com o TRX do endereço de depósito. A rapidez com que a cota se recupera entre as duas, não medimos; a nossa própria varredura conta com cerca de uma transferência por dia por endereço da cota de graça. Se um endereço for varrido com mais frequência que isso, a transferência de ativação pode deixar nele ao mesmo tempo o TRX para esses bytes.

Pedindo a energia para uma rodada de varredura

O mode A nomeia as duas pontas de cada transferência, o endereço de depósito como from e a carteira quente como to, e nós mesmos lemos o tipo a partir da carteira quente. O mode C nomeia só a carteira que vai receber a energia e pega o tipo de você, o que serve a um sistema de custódia que assina as suas varreduras no seu próprio ritmo e quer a energia já à espera (o mode C em detalhe). Para uma varredura esse tipo é sempre single, desde que a carteira quente tenha USDT. Qualquer dos modos aceita até 500 transferências num pedido, o mesmo teto de uma rodada de pagamentos. O aluguel é de cinco minutos ou de uma hora, e send_before cai três segundos antes do fim dele.

Um único endereço de depósito sem conta faz o pedido inteiro ser recusado. O 422 o nomeia em details.index e details.address, e nada é comprado. Então examine a rodada antes. POST /v1/estimate aceita as mesmas 500 transferências e não reserva nada, e avisa onde o pedido seria recusado: informe from em cada item, e todo endereço de depósito sem conta volta marcado como inactive_sender. Ative esses, espere as ativações confirmarem e envie o pedido. A recusa não gasta a Idempotency-Key, e relemos a ativação por fora do nosso cache antes de recusar um pedido por ela, então a mesma chave e o mesmo corpo funcionam assim que a transferência de ativação é confirmada.

Regras que valem a pena tirar da nossa própria varredura

Rodamos uma varredura própria. Os clientes pagam em endereços de depósito que guardamos para eles, e uma passagem em segundo plano move essas moedas para a única carteira quente que paga as compras. Ela move TRX, então gasta bandwidth e nenhuma energia, e os registros dela não dizem nada sobre o lado da energia de uma varredura de USDT.

A nossa varredura lê o valor da cadeia no momento em que decide. Os nossos próprios registros não sabem de uma taxa que foi queimada, nem de uma varredura cuja linha no banco de dados não sobreviveu a um processo que caiu, e a cadeia sabe. A mesma regra torna segura uma repetição: se as moedas já saíram, não há nada a enviar.

Mantemos aberta uma varredura transmitida até a transação dela aparecer num bloco, e só a damos como falha depois de uma janela não menor que a maior expiração que o nosso serviço de assinatura põe numa transação. Fechá-la antes faz com que uma transferência que ainda pode chegar seja contada como perdida, e a passagem seguinte pode assinar uma segunda transferência do mesmo saldo. Enquanto uma varredura não está confirmada, o endereço dela fica fora da passagem seguinte.

A nossa varredura de TRX envia no máximo o saldo menos uma reserva de taxa, e só mantém essa reserva quando o bandwidth de graça do endereço já foi gasto. Uma varredura de USDT paga a taxa numa moeda diferente da que move, então o saldo inteiro de USDT vai todas as vezes, e a reserva passa a ser o TRX de que um endereço de depósito precisa para os bytes de uma segunda varredura no dia.

Ache todo endereço de depósito que ainda precisa ser ativado antes de a varredura ser precificada, quinhentos por requisição: POST /v1/estimate com from em cada item →