Como funciona a delegação de energia TRON
A delegação de energia TRON é uma transação e dois campos de conta. Um endereço que tem TRX em stake para energia chama delegateResource nomeando um receptor, e daquele bloco em diante esse receptor pode gastar energia pela qual nunca fez stake, enquanto quem fez o stake continua com cada TRX que congelou. Nada é transferido, nada é aprovado do lado que recebe, chave nenhuma troca de mãos. É o mecanismo sobre o qual o mercado de aluguel de energia inteiro se apoia, e o que vem abaixo está lido dos próprios atuadores do java-tron, de leituras ao vivo da mainnet e de duas execuções com transações na rede de testes Nile em 3 e 4 de setembro de 2026.
O que atravessa, e o que fica
O TRX em stake nunca sai da conta do dono: delegar move esse TRX entre dois compartimentos dentro dessa mesma conta, saindo do saldo congelado para energia e entrando num de delegado-para-energia. O TRON Power — o peso de voto — é a soma dos dois compartimentos, então emprestar não custa a quem fez stake nenhum voto e nenhuma recompensa de voto. Uma conta com stake na mainnet, lida em 3 de setembro de 2026, mostra isso melhor do que a fonte: ela lançava 3,080,000 votos tendo sem delegar menos da metade disso, o resto emprestado, e o número de TRON Power que o próprio nó dava para ela eram os dois compartimentos somados.
Quem recebe fica com a outra metade do acordo: energia, e nada mais. O campo que uma delegação escreve na conta que recebe não é uma parcela do TRON Power, então energia emprestada não leva voto junto — o receptor daquela mesma leitura não tinha número de TRON Power nenhum, e o nosso na Nile também não.
O que a conta que recebe mostra
Dois números se mexem. O acquired_delegated_frozenV2_balance_for_energy sobe pelo valor delegado, e o limite de energia da conta sobe junto — o TRX delegado vezes o TotalEnergyLimit da rede dividido pelo TotalEnergyWeight dela, truncado. Em 3 de setembro de 2026 um receptor da mainnet com 31246 TRX em delegações de dois delegadores mostrava um limite de energia de 299,638, que é exatamente essa aritmética na razão que a rede carregava naquela noite: 180,000,000,000 sobre 18,770,236,993.
E é aí que quem compra energia se surpreende: uma delegação é denominada em TRX, não em energia. O denominador é o peso total em stake da rede, ele se move a cada bloco, e um número medido em outro lugar não viaja — naquela semana o mesmo stake valia cerca de 7.7 vezes mais energia na Nile do que na mainnet.
A trava, e as quatro recusas
Por padrão uma delegação pode ser retomada a qualquer momento. O lock=true na chamada de delegação é o que impede isso, e é a única coisa que impede. Ele leva um parâmetro, o lock_period, contado em blocos de três segundos — um campo que se lê como duração e é uma contagem, então pedir 300 deles porque você queria 300 segundos compra quinze minutos, em silêncio. Deixado em zero ou omitido, ele quer dizer 86,400 blocos: três dias. O teto é um parâmetro da cadeia, e na mainnet em 3 de setembro de 2026 ele estava em 864,000 blocos, ou trinta dias.
Uma trava pode ser esticada e nunca encurtada. Uma segunda delegação para o mesmo receptor só é aceita se o período dela for pelo menos o tempo que ainda falta correr, e aí ela reinicia o vencimento do saldo acumulado inteiro em vez de só da parte nova — ou seja, recarregar uma delegação travada trava de novo tudo o que está embaixo dela. Todo o resto a rede recusa. Estas quatro recusas voltaram de um nó da mainnet em 3 de setembro de 2026, apontadas a um par com uma trava viva de vinte e quatro horas; o nó roda a validação do próprio atuador enquanto monta qualquer uma das duas chamadas, então as quatro são respostas do próprio atuador e nada foi assinado nem enviado:
- uma trava de um bloco em cima da que estava viva —
The lock period for ENERGY this time cannot be less than the remaining time[86241000ms] of the last lock period for ENERGY!, que diz o que ainda falta correr, em milissegundos; - uma trava de quatro horas em cima da mesma — a recusa idêntica. O teste não é ser mais longo que uma trava nova; é ser mais longo que o que ainda falta;
- uma trava um bloco acima do teto —
The lock period of delegate resource cannot be less than 0 and cannot exceed 864000!; - a própria retomada —
insufficient delegateFrozenBalance(Energy), request=1000000, unlock_balance=0. Não é "menos do que você pediu": enquanto a trava estiver em vigor, saldo travado não conta absolutamente nada.
Uma montagem validada não é um bloco, então a mesma coisa foi feita com uma trava nossa. Duas execuções na Nile em 4 de setembro de 2026 puseram uma trava, pediram a retomada na hora, esperaram a trava vencer e pediram de novo: recusadas as duas vezes com aquela última frase caractere por caractere, aceitas as duas vezes assim que o vencimento passou — em cinco minutos e em quatro horas. A execução longa resolveu também o que a unidade conta: entre as duas transações o relógio dos cabeçalhos avançou 4,801 intervalos de três segundos enquanto a altura de bloco avançou 4,785, ou seja, dezesseis intervalos não produziram bloco nenhum e a trava correu as quatro horas dela assim mesmo. O lock_period conta intervalos do relógio de blocos, não blocos que chegam a ser produzidos.
Encerrar uma, e ver que ela encerrou
Quem delegou chama o undelegateResource, e sem uma trava no caminho isso está feito em um bloco. Nenhuma das duas chamadas carrega taxa além de bandwidth — os dois atuadores se precificam em zero — e é por isso que dá para vender energia em unidades de minutos. Contra uma trava viva não há cancelamento e não há taxa que compre uma saída; delegar de novo com lock=false também não é uma, já que isso escreve uma linha separada e deixa a travada de pé.
A trava fica visível em exatamente um lugar: a linha de delegação daquele par, onde o expire_time_for_energy é um carimbo de tempo em milissegundos. Chave ausente quer dizer que não há trava — que é a cara da delegação de um vendedor de aluguel comum, e as linhas de um pool da mainnet, lidas em 3 de setembro de 2026, não traziam chave de vencimento nenhuma. Leia esse número em vez de calculá-lo: o atuador o carimba a partir do cabeçalho do bloco anterior, então uma conta feita a partir do bloco da própria delegação erra por um bloco, e uma feita a partir do carimbo de tempo da transação erra por um valor diferente a cada vez. As duas execuções na Nile bateram com o valor guardado no milissegundo pela primeira regra e por nenhuma das outras.
Quando uma delegação acaba, os dois campos de quem recebeu não vão a zero — eles somem da resposta, e a linha de delegação volta vazia. Qualquer coisa que fique consultando uma conta precisa tratar ausente como zero, ou vai continuar mostrando energia que voltou para o dono dela minutos atrás.
Por que a carteira que recebe não assina nada
Tudo isso acontece do lado de quem delega: o receptor é nomeado na transação, um campo é escrito na conta dele, e não há nada a aceitar, aprovar ou conectar — que é também por que uma delegação não consegue alcançar o que aquela carteira guarda. Duas exigências apontam para o outro lado: o endereço precisa já existir como conta, e não pode ser um contrato, o que o atuador recusa de saída. É isso que torna energia alugável por API afinal (o que é energia, e de onde ela vem).
O que o aluguel constrói em cima
Um vendedor de energia é uma conta com stake e com hábito de delegar: ele delega para a carteira de onde você envia por um prazo, você gasta a energia numa transferência de USDT, e ele retoma a delegação. Os prazos mudam de vendedor para vendedor; o nosso é de 300 segundos, porque uma transferência leva segundos. Um pedido responde com send_before — o instante em que a janela de entrega fecha, três segundos antes de esse prazo acabar — e é esse campo, não o relógio da parede, que se planeja em volta.
Tudo isso fica visível enquanto o prazo corre, que é a parte útil de alugar numa cadeia pública: a transação de delegação na carteira que envia, o limite de energia que subiu nela, e a linha entre os dois endereços em qualquer explorador que leia o estado de delegação. A energia está no endereço ou não está, e a cobrança é pela primeira dessas coisas (quanto isso custa agora). Uma carteira que envia o dia inteiro é o mesmo mecanismo com horário: uma regra de Auto-refill a recarrega depois de cada transferência em vez de pedir que você faça um pedido.
Duas coisas que não medimos, e as duas merecem ficar às claras. Uma é o que a atividade de stake da própria conta que recebe faz com uma delegação apoiada nela: se quem recebe desfaz o stake ou delega adiante no meio do prazo, o código do atuador sugere que há algo a encontrar, e não rodamos isso. A outra é uma recarga: a fonte e a TIP-542 dizem as duas que uma segunda delegação aceita trava de novo o saldo inteiro embaixo dela, e não passamos nenhuma.