Blog · 7 de novembro de 2026

Manter uma carteira de pagamentos com energia: stake, aluguel por transferência ou recarga depois de cada uma

Uma carteira de pagamentos na TRON gasta energia em cada transferência de USDT que envia: cerca de 65,000 unidades quando o destinatário já tem USDT, cerca de 131,000 quando não tem. Quando falta energia, a rede cobra TRX no lugar, a 100 sun por unidade, o que dá 6.5 TRX ou 13.1 TRX por transferência, e o pagamento ainda confirma desde que a carteira tenha esse TRX e o fee_limit da transação permita a queima (o cálculo inteiro). Então o trabalho de uma carteira quente é ter energia a postos antes de cada envio sem que ninguém a peça à mão. Três padrões fazem esse trabalho, e cada um falha do seu jeito.

Um stake é dimensionado para o dia mais cheio e pago todos os dias

Fazer stake de TRX por energia compra uma parte de um pool diário fixo. A cota diária de uma carteira é o stake dela vezes o TotalEnergyLimit da rede sobre o TotalEnergyWeight, e em 3 de setembro de 2026 essa razão estava em 180,000,000,000 sobre 18,770,236,993: um pouco menos de dez unidades de energia por dia para cada TRX em stake. O divisor é o stake inteiro da rede para energia, o seu incluído, então o valor se mexe de bloco em bloco (a fórmula trabalhada).

A energia gasta volta aos poucos ao longo das 24 horas seguintes. Uma carteira que paga a maior parte do seu dia numa rodada só, ao meio-dia, precisa de um stake que cubra essa rodada, e o stake fica congelado também nas horas e nos dias parados. Sair também é lento. Na mainnet, o TRX cujo stake é desfeito hoje pode ser retirado catorze dias depois.

Quando os pagamentos passam do stake, as transferências que encontram a cota gasta queimam TRX pela diferença e, com TRX na carteira e folga no fee_limit, confirmam do mesmo jeito. Nada devolve um erro, e o primeiro sinal é uma linha de queima no histórico da carteira (o que acontece quando o limite é baixo demais).

Alugar por transferência põe uma espera na frente de todo envio

O segundo padrão compra energia para cada transferência à medida que ela surge. Um pedido nomeia a carteira que envia e o destinatário. A API responde 202, com a URL do próprio pedido em Location e o intervalo de consulta em Retry-After, e nós compramos a energia e a esperamos aparecer na carteira. Quando a delegação é confirmada, o pedido passa a trazer send_before, e esse é o sinal para o seu código enviar. A janela é o aluguel menos três segundos: 297 segundos no aluguel de cinco minutos e 3,597 no de uma hora.

Todo pagamento, portanto, espera por uma compra e por um bloco. Medimos essa espera nos nossos próprios pedidos em que o código do cliente faz o envio, do momento em que o pedido foi criado até a última delegação confirmada na cadeia, ao longo dos sessenta dias até 8 de setembro de 2026.

Treze pedidos são uma amostra pequena, e a maior parte dela é do início. Sete vieram da primeira semana de pedidos ao vivo, os mais lentos entre eles, e as semanas seguintes ficaram em três a quatro segundos. Não repetimos a medição numa amostra maior.

Uma transferência enviada antes de a energia chegar queima à taxa cheia, e uma enviada depois de send_before pode chegar quando a energia já foi embora e queimar do mesmo jeito. O TRX que ela queima não volta. A energia que foi entregue e não usada dentro da janela fecha como expired e é cobrada, porque foi entregue (os três relógios de um aluguel). Uma fila de pagamentos que envia no seu próprio ritmo precisa ser reconstruída em torno desse sinal. Para uma rodada de pagamentos conhecida de antemão, um pedido em lote de até 500 transferências reúne a espera num lugar só: a energia da rodada inteira é comprada primeiro, e toda transferência dela compartilha um único send_before (como um lote é visto por dentro).

Uma regra que recarrega a carteira depois de cada transferência

O terceiro padrão é uma regra na carteira, que vendemos como Auto-refill, o caso da carteira quente de enviar USDT sem ter TRX. Ela leva dois campos, address e daily_budget_trx, numa chamada a POST /v1/auto-refill-rules. A partir daí a carteira é levada de volta a cerca de 131,000 unidades de energia depois de cada transferência que faz. Isso cobre qualquer próxima transferência, inclusive uma para um endereço sem USDT. A regra não cria pedidos: GET /v1/orders lista só os que você fez.

Uma recarga é precificada pelo que a transferência anterior usou. Se essa transferência gastou cerca de 65,000 unidades, a recarga é cobrada na taxa single; se gastou cerca de 131,000, na double. As duas taxas estão em GET /v1/tariff sob maintenance_price_trx. São um preço próprio e se movem separadamente dos preços de aluguel, e a taxa cobrada é a que estava em vigor quando a recarga é confirmada. A primeira recarga de uma regra nova é sempre double: não há transferência anterior para precificá-la, e a carteira recebe os 131,000 inteiros de uma vez.

A cobrança espera até a energia estar visível na carteira na cadeia; um fornecedor dizer que entregou não basta. Cada cobrança chega como um evento maintenance.topup com rule_id, address, units e charged_trx, e como uma linha charge em GET /v1/ledger. Uma carteira que não envia nada não recebe recargas e não paga por nenhuma.

Como a recarga para, e o que a carteira faz então

O limite diário, daily_budget_trx, é reservado do seu saldo disponível quando a regra começa e de novo no início de cada dia UTC, e é o máximo que a regra pode gastar naquele dia. As recargas saem dessa reserva, e o que sobra dela volta ao saldo à meia-noite UTC. O spent_today_trx da regra mostra quanto do dia já foi. Aumentar o limite ao meio-dia soma a diferença à reserva e não abre um segundo dia.

Quando o limite se esgota, as recargas param até o próximo dia UTC. Você recebe um evento maintenance.budget_exhausted, com spent_today_trx e daily_budget_trx dentro dele, e a regra continua active. Desse ponto até a meia-noite, toda transferência que a carteira não consegue pagar em energia queima TRX pela diferença a 100 sun por unidade. Um limite dimensionado para um dia médio acaba num dia cheio.

Quando o seu saldo não consegue cobrir a reserva do dia seguinte, a regra para. O status dela passa a paused com paused_reason em insufficient_balance, e um evento maintenance.paused é emitido. Uma regra pausada nunca volta sozinha, e um depósito não a reinicia: ela espera por PATCH /v1/auto-refill-rules/{rule_id} com {"status": "active"}, e uma retomada que o saldo ainda não consegue cobrir responde 402. Uma pausa que você mesmo põe não traz motivo, então paused_reason distingue uma regra que espera por dinheiro de uma que espera pela sua decisão.

Um limite abaixo da taxa double é recusado com 422, details.reason em budget_below_topup_price e o mínimo em details.min_daily_budget_trx: a primeira recarga é double, e uma regra com um limite menor entraria no ar e nunca a pagaria.

Cerca de 131,000 unidades na carteira cobrem duas transferências a endereços que têm USDT, ou uma a um endereço que não tem. Uma transferência enviada antes de a recarga da anterior chegar pode encontrar menos do que precisa e pagar parte do caminho, ou quase todo, em TRX. Não medimos quanto tempo depois de uma transferência a recarga chega. Excluir uma regra antes de as recargas dela terem coberto o que pagamos antecipadamente por aquela carteira custa a parte descoberta, contando pré-pagamentos e cobranças a partir de 6 de novembro de 2026; uma pausa nunca cobra por isso.

Um dia de exemplo, de três jeitos

Para pôr os três lado a lado, tome uma carteira e um dia: trinta pagamentos a endereços que já têm USDT e dez a endereços que não têm. A queima e o stake são aritmética da rede. O preço do pedido e as taxas de recarga são nossos, lidos de GET /v1/tariff às 21:46 UTC de 27 de outubro de 2026; os de hoje estão na página de preços.

Naquela hora os pedidos saíram mais baratos que as recargas, e esse era o caso habitual. Ao longo dos trinta dias de histórico horário até a mesma noite, as taxas de recarga não mudaram uma vez sequer, e um pedido de cinco minutos para a mesma transferência custou menos que a recarga dela na maioria das horas.

O que uma recarga custa acima do pedido compra uma carteira que já tem a sua energia quando cada transferência sai, e um teto rígido para o que ela pode gastar num dia. O limite, como um stake, precisa cobrir o dia cheio, mas o que um dia parado deixa dele volta ao saldo à meia-noite UTC. Não temos um número de produção de quantas recargas uma regra faz num dia.

Configure uma carteira de pagamentos para se recarregar sozinha com uma requisição e um limite diário que você escolhe: POST /v1/auto-refill-rules na referência da API →