Blog · 2 de novembro de 2026

Cinco minutos ou uma hora: como escolher um aluguel de energia TRON

Vendemos energia TRON em dois aluguéis, de 300 segundos e de 3,600 segundos. Os dois entregam a mesma energia para a mesma transferência, e os dois têm o preço por unidade de energia para o aluguel inteiro. A hora deixa essa energia no endereço por mais tempo. Cinco minutos servem a um software que envia no sinal, e o tempo a mais vale ser pago quando uma pessoa ou um lote longo fica entre a chegada da energia e a saída da transferência.

Um aluguel é uma quantidade de energia e um prazo

Um pedido nomeia a transferência e, se quiser algo diferente dos cinco minutos padrão, um duration_s. A energia decorre da transferência: cerca de 65,000 unidades quando o destinatário já tem USDT, cerca de 131,000 quando não tem. O aluguel não muda essa quantidade. O preço decorre do aluguel: current_price_sun é o que uma unidade custa pelo prazo inteiro, então o preço da hora é o preço de uma unidade mantida por uma hora, sem nada a multiplicar por doze.

No aluguel de uma hora, um pedido de uma transferência compra energia para uma transferência e uma hora para enviá-la. Uma transferência gasta as mesmas unidades no minuto dois e no minuto cinquenta, e a energia gasta quase não volta enquanto o aluguel corre: a energia usada de uma conta escoa de volta ao longo do dia seguinte, e uma hora é cerca de um vinte e quatro avos desse dia. Quanto tempo a energia alugada dura percorre esse ciclo diário e os outros dois relógios de uma delegação.

A janela é o aluguel menos três segundos

Quando a energia é confirmada no endereço que envia, o pedido passa a trazer send_before. No aluguel de cinco minutos isso é 297 segundos depois da confirmação, no de uma hora, 3,597. Os três segundos são os mesmos em todo aluguel, e tudo o que fazem é fazer a janela fechar antes do aluguel. A rede começa o aluguel no bloco que levou a delegação, nós começamos a janela quando vemos essa delegação confirmada, e a distância entre os dois costuma ser maior que três segundos. Uma transferência enviada no limite de qualquer das duas janelas pode chegar depois de a energia ter voltado para casa e queimar a taxa inteira em TRX.

Essa distância tem o mesmo tamanho nos dois aluguéis. Em cinco minutos ela sai de 297 segundos, na hora de 3,597, e a regra continua a mesma: envie no webhook order.ready ou na primeira consulta que mostrar send_before, e fique bem longe do fim do prazo.

Um lote compartilha um só prazo. Ele conta a partir da última delegação confirmada no pedido, e não pode ser posterior ao que a primeira compra bem-sucedida permite, já que a energia não pode começar antes de ter sido comprada. Compramos a cerca de um segundo por posição, e as posições que alcançamos com menos de trinta segundos de janela sobrando não são compradas: fecham como failed com purchase_failed, e a reserva delas volta. No aluguel de cinco minutos isso corta um lote grande em mais ou menos a sua 269ª transferência. Na hora, um lote cheio de 500 cabe com a maior parte da janela de sobra.

O que uma hora compra

O uso mais simples é um conjunto de transferências que você vai enviar dentro da hora, mas não todas de uma vez. Uma rodada de pagamentos que sai conforme as aprovações chegam, ou uma fila que o seu próprio código esvazia no ritmo dele, pode ser pedida como um lote só no aluguel de uma hora. A energia de todas as transferências chega junta à carteira que envia, e cada transferência sai quando está pronta. Peça só o que você vai enviar. Uma posição cuja janela fecha sem uso termina como expired e é cobrada, porque a energia foi entregue e mantida durante a janela inteira.

A hora também cobre um envio que espera por uma pessoa. No mode A você assina e transmite a transferência você mesmo, e o pedido nunca vê como ela foi assinada: uma carteira de hardware e um segundo aprovador cabem os dois. Cinco minutos deixam pouco espaço para um aprovador, e uma hora deixa bastante. O mode B não comporta o segundo aprovador, porque aceita uma assinatura do dono em Permission_id 0 e recusa multiassinatura.

O mode B é o que menos precisa da hora, mesmo para uma transação assinada com bastante antecedência. Ali você nos entrega uma transferência assinada, e nós a transmitimos na mesma passagem que marca a energia como pronta, então uma transferência isolada não ganha nada com uma janela mais longa. A janela também é limitada pela própria expiração da transação, menos trinta segundos. A hora, portanto, só ajuda um pedido do mode B quando o lote leva mais de cinco minutos para ser comprado e as transações dele foram assinadas para viver mais que isso. Podem ter sido: aceitamos uma expiração de até 23 horas e 59 minutos depois de a transação chegar a nós. O que uma API de energia TRON realmente faz percorre o mode B a partir da requisição.

Um pedido de um volume (energy_units) acima de 131,000 unidades tem de pegar a hora. Uma posição assim é comprada em pedaços de vários vendedores, e o aluguel de cada pedaço corre a partir da sua própria delegação, então em cinco minutos o primeiro pedaço começaria a expirar enquanto o último ainda estava chegando. Um aluguel mais curto é recusado com 400 invalid_request, details.reason bulk_needs_longer_lease.

O que a hora custou contra os cinco minutos

A maior parte do mercado vende a hora. Das dezessete tabelas de preços que o nosso monitoramento de mercado leu em 7 de setembro de 2026, dezesseis cotavam uma hora. Cada um dos nossos dois aluguéis tem o seu preço, recalculado contra o mercado, então nenhum deriva do outro. GET /v1/tariff/history traça um aluguel por requisição, e com range=30d devolve 720 pontos horários do preço a que vendemos. Lemos as duas séries em 27 de outubro de 2026 e as comparamos hora a hora.

O aluguel de uma hora custou mais na maior parte das horas e menos em algumas, e ao longo do mês os dois ficaram próximos. O ágio variou de semana para semana, e em uma das quatro semanas a hora saiu mais barata. A maior parte daquele mês foi vendida sob a grade diária de preços anterior, e um preço por aluguel a substituiu em 26 de outubro. A última linha começa às 00:00 UTC desse dia, então as primeiras horas dela ainda podem trazer a grade, e dois dias são pouco para dizer se a diferença vai se manter.

O histórico registra o preço a que vendemos e não promete nada sobre a próxima hora. Os preços de hoje dos dois aluguéis estão na página de preços, e products[] de GET /v1/tariff devolve os mesmos valores. Quando a energia TRON é mais barata lê o mesmo histórico ao longo das horas do dia.

Escolhendo um aluguel

Escolha pelo mais longo que o seu envio pode levar depois de a energia chegar. Se forem segundos, fique com cinco minutos. Se for mais, fique com a hora, e peça só as transferências que você vai fazer dentro dela.

Faça o seu código ler os aluguéis de products[] a cada vez. Produtos entram e saem de venda sem uma versão nova: o aluguel de um dia saiu de venda em 25 de outubro de 2026, e um pedido ou uma estimativa que nomeia um aluguel que não está à venda recebe 400 invalid_request, com os aluguéis que estão à venda em details.allowed. O aluguel faz parte do corpo do pedido, então uma repetição sob a mesma chave de idempotência com um duration_s diferente é recusada com 409 idempotency_conflict e não cria nada.

Uma carteira que envia o dia todo não cabe em nenhum dos dois aluguéis, e nada mais longo que uma hora está à venda. Uma regra de Auto-refill é feita para ela: você informa um endereço e um limite diário, e a carteira é reabastecida depois de cada transferência que faz.

O que não medimos

Não medimos quanto tempo os pedidos de aluguel de uma hora dos nossos próprios clientes esperam entre a entrega e o envio, então nada aqui diz quanto da hora um pedido típico usa. A distância entre o início do aluguel pela rede e o nosso é deduzida de como a janela é calculada, e não a cronometramos isoladamente. A comparação de preços cobre um mês, quase todo sob a grade diária anterior.

Precifique o mesmo lote nos dois aluguéis antes de escolher um, sem reservar nada: POST /v1/estimate aceita duration_s →