Como comprar Energy da TRON de forma programática, sem confirmação manual

Resposta curta: a Energy da TRON é comprada de forma programática pelo mesmo fluxo montar → assinar → transmitir de uma transferência comum. Seu serviço monta uma transação não assinada com um método HTTP (wallet/freezebalancev2 — staking para energy, DelegateResource — atribuição do recurso a um endereço específico), a assina localmente com a chave privada do pool e a envia para wallet/broadcasttransaction. A confirmação manual só aparece onde a chave está na carteira do usuário (TronLink, servidores MCP do ecossistema). Se o seu código detém a chave, não há nada a confirmar, e a aquisição automatizada se torna apenas mais uma etapa do pipeline de pagamentos.

De onde vem a Energy

Ao contrário do Bandwidth, a Energy não tem cota diária gratuita (o Bandwidth tem — 600 unidades por dia para uma conta externa). Para executar uma transferência TRC-20, uma conta precisa ter Energy em staking ou delegada, ou complementá-la queimando TRX ao preço atual de getEnergyFee — a documentação indica 100 sun (0.0001 TRX) por unidade. É um parâmetro da cadeia alterado por votação dos SRs, então em produção deve ser lido da rede em vez de fixado no código.

Há duas formas padrão de obter Energy:

• fazer staking de TRX (Stake 2.0) — você congela TRX e recebe uma parcela do limite total da rede segundo a fórmula staked TRX / total network TRX staked for Energy × 180,000,000,000;
• alugar no Energy Rental Market da JustLend DAO — acesso à energy sem congelar seus próprios ativos.

O primitivo sobre o qual pools e serviços de aluguel são construídos é o DelegateResourceContract: o detentor do stake delega Energy a outra conta, e o destinatário a gasta diretamente, sem fazer staking de nada. É exatamente assim que exchanges e operadores de DApps cobrem os custos dos usuários a partir de um único pool de staking.

A arquitetura "pool + delegação"

1. Uma conta de pool dedicada, com TRX em staking para ENERGY (o mínimo para uma única operação FreezeBalanceV2 é 1 TRX, ou seja, 1,000,000 sun; qualquer valor menor é rejeitado com ContractValidateException).
2. Antes de cada pagamento — consultar wallet/getaccountresource para o hot address: quanta energy está disponível agora.
3. Se não houver o suficiente — DelegateResource do pool na quantidade necessária, assinar, transmitir.
4. Após um lote de pagamentos — UnDelegateResource, devolvendo o recurso ao pool.

O campo resource aceita as strings ENERGY ou BANDWIDTH. A delegação é reversível, mas admite um bloqueio opcional: até o bloqueio expirar, o recurso não pode ser recuperado — no backend isso deve ser tratado como "o pool está temporariamente menor", caso contrário o agendador ficará esbarrando em saldos que não consegue sacar.

Se a sua lógica de alocação de recursos já está on-chain, a mesma coisa pode ser feita sem servidor: o Stake 2.0 está disponível a partir do Solidity — freezebalancev2(1000000, 1), receiver.delegateResource(1000000, 0), receiver.unDelegateResource(...), além do método de visualização target.delegatableResource(1) para monitorar o valor disponível para delegação. Os detalhes estão na seção Bandwidth and Energy.

Se você pretende conduzir a aquisição por meio de um agente de IA, tenha em mente uma limitação: as ferramentas MCP da TronScan são atualmente somente leitura, a TronGrid pode montar transações não assinadas e transmitir transações já assinadas, mas não assina nem armazena chaves privadas, e os demais servidores do ecossistema exigem autorização explícita do usuário. Um cenário totalmente "sem intervenção" via MCP não é suportado de fábrica — a assinatura precisa permanecer dentro do seu próprio código.

Quanto comprar: calculando em tempo de execução

Não fixe no código a quantidade de energy por transferência.

A conta é simples: fee_limit (sun) = energy_required × getEnergyFee. A estimativa reflete o estado do nó no momento da requisição e não garante que a transação on-chain subsequente será bem-sucedida.

O principal risco de custo é o modelo de energy dinâmica (DEM). O parâmetro #75 getDynamicEnergyMaxFactor retorna 34,000 na mainnet, ou seja, max_factor = 3.4, enquanto o multiplicador combinado de energy pode chegar a 4.4. O fator muda após a virada do ciclo de manutenção, então qualquer cache de estimativas que sobreviva ao ciclo precisa ser invalidado. A estratégia de "sempre calcular com max_factor" é segura para fazer as transações passarem, mas gera orçamento excessivo. Uma explicação detalhada está em FeeLimit & Energy.

Uma transferência de USDT não ativa o destinatário nem custa Energy extra por isso: os 25,000 de Energy adicionais só se aplicam quando um contrato inteligente envia TRX ou TRC-10 para um endereço não ativado. O que muda o gasto é o saldo de USDT do destinatário: cerca de 65,000 de Energy se ele tem USDT e cerca de 131,000 se o saldo é zero.

O que quebra sob carga

• O TTL da transação é de 60 segundos após a montagem. Pode acontecer de um broadcast ser "bem-sucedido" e a transação nunca chegar a um nó SR; tentar de novo só faz sentido depois que o período de validade expirar.
• OUT_OF_TIME: o limite global de execução de uma transação de contrato é de 80 ms (alterável por votação dos SRs). Se for excedido, todo o fee_limit é cobrado.
• A Energy não é reembolsada — nem do stake, nem da queima — mesmo que a transação seja revertida ou falhe em outra verificação.
• A recuperação leva 24 horas, de forma linear. Se você gastar novamente ou revogar uma delegação nesse período, o sistema mescla proporcionalmente o progresso da recuperação com o novo ciclo: "revogado" não significa "disponível imediatamente".
• O unstaking leva 14 dias: UnfreezeBalanceV2Contract, esperar e depois WithdrawExpireUnfreezeContract. Não é uma ferramenta de rebalanceamento rápido.
• Stake 1.0 em código copiado e colado: exemplos mais antigos contêm frozen_duration: 3 e FreezeBalanceContract — se você os copiar, montará uma transação para o mecanismo antigo.
• Chave de API: o cabeçalho TRON-PRO-API-KEY só é necessário na mainnet; Shasta e Nile funcionam sem ele, e o Stake 2.0 se comporta ali exatamente como na mainnet — o que os torna o lugar certo para depurar a aquisição automatizada.

A conclusão: a confirmação manual desaparece não por causa de alguma "API de aluguel" especial, mas porque a assinatura permanece do seu lado. Todo o resto é disciplina: estimar a energy em tempo de execução, ler os parâmetros da cadeia diretamente da rede (wallet/getchainparameters) e lembrar que o staking, a delegação e a recuperação de recursos rodam cada um em seus próprios temporizadores.

Este material tem apenas caráter informativo e não constitui aconselhamento de investimento.