Blog · 30 de outubro de 2026

Quanto TRX uma carteira precisa para enviar USDT

Uma carteira que envia USDT na TRON tem dois números para acertar, e é fácil confundir um com o outro. Um é a taxa: o que uma transferência tira da conta. O outro é o TRX que a conta precisa ter, e o limite que a transação precisa carregar, para que a transferência se complete de fato. Com energia na carteira, ela precisa de TRX só para os bytes: nenhum na primeira transferência do dia, cerca de 0.345 TRX em cada uma depois dela. Sem energia, precisa de 6.5 TRX por transferência para um destinatário que tem USDT e de 13.1 TRX para um que não tem, mais os mesmos bytes. De qualquer jeito, o fee_limit da transação precisa alcançar a queima inteira. Uma carteira financiada até o valor da taxa e aquém do segundo número falha de um jeito que ainda custa TRX.

O nó fica com o menor de dois limites

Enviar USDT é uma chamada a um contrato inteligente, e antes de a chamada rodar o nó decide quanta energia ela pode gastar. Ele calcula dois valores e fica com o menor. O primeiro é o que a conta pode pagar: a energia que ela já tem, mais tantas unidades quantas o TRX dela compraria à taxa do protocolo de 100 sun cada. O segundo é o que a transação permite: o fee_limit dela, dividido pelos mesmos 100 sun.

Duas regras decorrem daí. O TRX da conta precisa cobrir toda a energia que a transferência vai queimar, porque um saldo aquém da queima deixa a chamada com um teto abaixo do que ela precisa. E o fee_limit precisa permitir essa queima, porque um limite baixo impõe o teto com a mesma força, por mais TRX que haja por trás. Fique aquém em qualquer um dos dois e a chamada para no meio com OUT_OF_ENERGY, e o TRX que ela queimou no caminho continua queimado (o que esse resultado quer dizer).

O segundo valor pega as carteiras que alugam ou fazem stake. O nó conta contra o fee_limit também a energia que a conta já tem, do mesmo jeito que conta o TRX que queimaria. Uma transação assinada sem fee_limit leva um limite de zero, e um limite de zero não deixa a chamada gastar energia nenhuma, delegada ou queimada. Diga o que disser o aviso da própria carteira, o nó faz esta aritmética: a energia da própria conta não cobre a chamada, o nó vai queimar TRX para o resto, e a transferência passa só se o saldo e o limite chegarem os dois até lá.

Três tentativas de uma carteira na mainnet

O lado do fee_limit da regra dá para ver na mainnet. Em 6 de outubro de 2026, percorrendo o registro público do contrato do USDT, topamos com um remetente que tentou a mesma transferência três vezes em menos de quarenta minutos. A transferência precisava de 130,285 unidades de energia, o valor para um destinatário sem USDT, e a conta não tinha energia própria, então cada unidade tinha de ser comprada queimando TRX. Cada linha é o registro da própria transação.

A primeira tentativa parou em exatamente 11,000 unidades, que é o seu fee_limit dividido por 100 sun. A conta poderia ter pago por mais: pagou a queima inteira na terceira tentativa, e o registro dela não mostra TRX chegando nesse intervalo. A segunda tentativa não levava fee_limit, e o recibo dela informa um limite de zero na primeira instrução do contrato. Não gastou energia, não moveu USDT e ainda assim pagou pelos seus bytes. A terceira foi assinada com um fee_limit logo acima da queima e passou.

Esse remetente foi a exceção. Das 12,000 chamadas consecutivas de USDT que contamos na mesma tarde, todas traziam um fee_limit.

Em quanto definir o fee_limit

O fee_limit limita a energia que a chamada pode usar, seja a que já está na carteira, seja a queimada, e não cobra nada por si só. Uma transferência cuja energia já está na carteira não queima nada dela, então um limite folgado não custa nada numa carteira que tem a sua energia. O valor que nunca interrompe uma transferência no meio é a queima maior, 13.1 TRX. Um limite de 6.5 TRX basta só enquanto o destinatário ainda tiver USDT quando a transferência chegar, e um destinatário com saldo vazio custa o valor maior tenha ele já tido USDT ou não (de onde vêm os dois valores). Um limite abaixo do que a transferência precisa interrompe a chamada mesmo numa carteira que tem toda a energia de que precisa, porque o nó conta essa energia contra o limite.

Quando transmitimos por você uma transferência assinada, no mode B, aplicamos essa regra antes de qualquer energia ser comprada. Um fee_limit que não consegue pagar a energia da transferência ao preço atual da rede é recusado com 400 invalid_request e details.reason em fee_limit_too_low. Uma estimativa dessa transferência devolve a queima dela como burn_cost_trx, e um limite pelo menos igual a ela sempre passa.

O limite pesa mais numa transferência cujo custo muda depois de precificada. Um destinatário que tinha USDT quando você o conferiu e esvaziou o saldo até a transferência chegar custa o valor maior. Se a carteira tem energia para o menor, o nó queima a diferença do TRX. O saldo precisa cobrir essa diferença, e o fee_limit precisa cobrir o valor maior inteiro, porque a energia que a carteira tinha também conta contra ele. Aquém em qualquer um dos dois, a transferência é interrompida com OUT_OF_ENERGY, e o que ela queimou no caminho continua queimado.

Com energia na carteira, o que sobra é o bandwidth

A energia paga a chamada de contrato e nada além disso. Os bytes da transação são medidos à parte, como bandwidth (os dois medidores lado a lado). Toda conta ganha 600 bytes de bandwidth de graça por dia, o que cobre cerca de uma transferência de USDT. Passado isso, a rede queima TRX por todo o bandwidth cobrado de cada transação, a dez vezes a taxa da energia: um byte custa o que dez unidades de energia custam.

Uma transferência de USDT é cobrada em algumas centenas de bytes de bandwidth. A que enviamos e medimos em 2 de setembro de 2026 foi cobrada em 345, e as três tentativas acima entre 339 e 345. Então, depois que a cota de graça foi gasta na primeira transferência do dia, toda transferência seguinte paga os seus bytes em TRX, quer a energia dela tenha sido alugada, de stake ou queimada. Uma carteira sem TRX nenhum ainda pode enviar a primeira transferência do dia com energia delegada, com a cota de graça pagando os bytes; a segunda precisa de TRX na conta (enviar sem ter TRX).

Cobranças fora da transferência

Uma carteira que envia precisa existir na cadeia antes de se poder delegar energia a ela (o que é a ativação), e enviar TRX a um endereço que a rede nunca viu é o que cria a conta dele. Dois parâmetros da cadeia precificam a criação de conta. Não ativamos um endereço para ver se uma transferência dessas paga só o primeiro deles ou os dois, então a tabela lista os dois, e a soma deles é o valor a manter para isso. Mais dois parâmetros precificam um memo numa transação e uma transação assinada sob uma permissão de multiassinatura. Diferente da ativação, os dois são cobrados em toda transação que leva um memo ou uma permissão de multiassinatura, então uma carteira quente assinada assim soma o parâmetro a cada transferência contada na tabela abaixo. Não enviamos nenhuma delas, e essas linhas trazem o parâmetro e nada medido.

O colchão para um dia de transferências

Juntando tudo, o TRX que uma carteira que envia consome num dia depende de onde vem a energia dela e, quando ela queima, do tipo de destinatário a quem ela paga. A tabela abaixo supõe 345 bytes de bandwidth cobrados por transferência, a cota de graça gasta na primeira transferência do dia e os parâmetros acima. Uma carteira que queima paga 6.5 TRX ou 13.1 TRX de energia em cada transferência, e os bytes dela a partir da segunda. Uma carteira com energia paga só os bytes.

A energia alugada é paga com o seu saldo conosco, e o preço dela por transferência está na página de preços. A energia de stake custa o TRX travado para produzi-la, o que fica fora desta tabela (stake contra aluguel). O valor diário é o que um abastecimento de uma vez por dia precisa deixar na carteira. Antes de qualquer transferência avulsa, o piso é menor: a queima dessa transferência, se ela queima, e os bytes dela.

A última linha é a margem para a energia comprada no valor menor. O Auto-refill leva a carteira de volta a cerca de 131,000 unidades depois das transferências dela, o bastante para os dois tipos de destinatário, então numa carteira assim um destinatário que acaba precisando do valor maior está coberto em energia e a margem cai a zero (como o Auto-refill funciona). Seja qual for a fonte da energia, o fee_limit ainda precisa cobrir a energia inteira da transferência, que é 13.1 TRX para um destinatário que pode não ter USDT quando a transferência chegar.

Não medimos a rapidez com que a cota de graça volta ao longo de um dia; a tabela supõe que só a primeira transferência do dia se apoia nela, então para uma carteira que espalha as transferências os valores de bandwidth são um limite superior.

Dimensione o limite de cada transferência pela queima que o nó vai exigir dela: POST /v1/estimate e o burn_cost_trx dele, na referência da API →