Como alugar energia TRON com segurança
Um aluguel precisa de uma coisa sua: o endereço em que a energia deve cair. Procure como alugar energia TRON com segurança e você recebe dois tipos de página — vendedores, e avisos sobre vendedores — e nenhum resolve, porque o teste útil não é se um vendedor parece confiável, e sim o que a transação de fato exige. Qualquer outra coisa que um vendedor peça está atrás de outra coisa que não energia.
O que um aluguel de verdade pede: um endereço
Energia se move por delegação, e uma delegação é assinada pela conta que tem o TRX em stake, não pela conta que recebe a energia. O lado que recebe é passivo: a rede eleva o limite de energia dele e o evento é isso e mais nada (como funciona a energia). Então a lista completa do que um vendedor legítimo precisa de você é o endereço em que a energia deve cair.
Nada a assinar. Nenhuma conexão de carteira. Nenhuma aprovação de token. Nenhuma frase-semente. Nenhum pagamento de "ativação" para liberar a entrega. A única exigência sobre o endereço em si é que ele exista na cadeia: energia não pode ser delegada a uma conta que nunca foi ativada, o que na nossa API é uma recusa — 422 invalid_address com details.reason em inactive_wallet — e não uma cobrança por uma entrega que não teria como acontecer.
Como a delegação aparece do seu lado
A entrega não precisa ser aceita na confiança. A TRON registra uma delegação tanto na conta que recebe quanto na de quem delega — os nomes dos campos ainda carregam o V2 do modelo de stake que a introduziu — então o comprador consegue ler o resultado sem perguntar nada ao vendedor.
Dois campos dizem isso, e cada um vem de uma chamada própria. acquired_delegated_frozenV2_balance_for_energy, que o getaccount devolve, é o sun em stake delegado à sua conta; e numa carteira que não tem stake próprio nenhum, o EnergyLimit do getaccountresource é o que isso dá em energia — o valor adquirido vezes a própria razão da rede entre limite total de energia e peso total em stake. Quando a carteira também tem stake, a parte delegada é a subida do EnergyLimit e não o valor todo. O sun é o que uma delegação fixa; a energia não, porque essa razão se move com o stake da rede inteira, bloco a bloco.
Lida contra uma conta receptora da mainnet em 3 de setembro de 2026, a aritmética fechou na unidade: energia adquirida de dois delegadores, e um EnergyLimit de 299,638. O mesmo registro não trazia tronPowerLimit nenhum — quem recebe não ganha peso de voto por uma delegação, que é mais um jeito de dizer que o que atravessa é energia e nada mais.
O prazo está no mesmo lugar. O getdelegatedresourcev2 mostra uma delegação travada com um expire_time_for_energy na linha dela; sem trava não existe essa chave, e quem delegou pode retomar a energia com uma chamada. O pool de um fornecedor de energia lido em 4 de setembro de 2026 mostrou exatamente isso — uma delegação ativa, sem expiração na linha, e o nó montando uma transação de retomada contra ela quando pedimos. Não é desonestidade: é outro produto, e o registro é o único lugar que diz qual dos dois você comprou.
Os sinais de alerta, e o que cada um quer
- "Conecte a sua carteira." Uma delegação não precisa de conexão nem de sessão: quem delega assina sozinho, e a sua conta aparece ali como uma string. O que um fluxo de conexão de fato compra para o outro lado é a possibilidade de pôr uma transação na sua frente para assinatura, e as duas que valem pôr ali são uma transferência e uma aprovação.
- "Aprove o USDT para a energia poder ser entregue." Uma aprovação é uma chamada no contrato do token dando a alguém o direito de mover o seu USDT, até o limite que você definir e enquanto ela continuar valendo. Ela não tem parte nenhuma numa delegação — energia chega numa conta que nunca assinou nada. Isto não é um sinal de alerta perto do golpe; é o golpe.
- "Mande TRX para este endereço e ganhe energia grátis." Um pagamento sem pedido por trás: nenhum identificador para citar, nenhum registro do que foi comprado, ninguém com obrigação nenhuma. Um aluguel tem um pedido que entregou ou não entregou, e um que não entregou devolve o dinheiro sem que seja preciso pedir.
- Um bot que quer uma chave privada ou uma frase-semente — para "verificar", "ativar" ou "vincular" a carteira. Nenhuma etapa de um aluguel tem lugar para isso. Quem tem a chave tem os fundos, e a conversa acaba aí.
- Um vendedor que quer a transferência passando por ele. "Mande o USDT para nós e a gente repassa quando a energia chegar" é custódia, não energia. Entregar uma transferência é um arranjo real — é o mode B aqui — mas o que é entregue é uma transação que você mesmo assinou, nomeando o destinatário e o valor, e que não pode ser alterada em um byte sem quebrar a assinatura.
O que conferir depois de pagar
Dois fatos, os dois legíveis na cadeia, e não com o vendedor. Primeiro a energia: o limite de energia da conta receptora subiu ou não subiu, e essa entrega é a coisa inteira que está sendo vendida. Segundo o prazo, que é quanto tempo ela fica. Uma delegação sem trava é revogável a qualquer momento; uma travada não pode nem ser encurtada por quem delegou, e a rede recusa a tentativa dizendo os milissegundos que ainda faltam.
O nosso é um arrendamento curto de propósito: o pedido traz send_before, 297 segundos a partir da última delegação confirmada, e uma estimativa devolve o prazo que precificou como duration_s. Uma janela curta é o que torna a energia barata o bastante para ser alugada por transferência.
O que um vendedor pode prometer, e o que não pode
Um vendedor honesto promete a entrega de energia. Ele não pode prometer que a sua transferência vai dar certo, porque os motivos de uma transferência de USDT falhar são propriedades dos endereços e não da energia: um destinatário congelado no contrato do token, um remetente que não tem o que está tentando mover, um contrato que reverte (o que uma mesa de pagamentos encontra de verdade).
Os nossos status são escritos para manter os dois separados. completed quer dizer que a energia foi entregue, e no mode A pode chegar antes de você ter enviado qualquer coisa. expired quer dizer que ela foi entregue, ficou pela janela inteira e não foi usada — e é cobrada, porque foi entregue. failed quer dizer que ela não foi entregue por culpa nossa, e aí nada é cobrado. Qual desses libera dinheiro é a política de reembolso por inteiro, e um vendedor que não queira declarar a mesma divisão de antemão vale uma pergunta a mais antes de o dinheiro se mover.
Créditos pré-pagos, e o que uma entrega falha faz
Dinheiro aqui são créditos de serviço pré-pagos, denominados em TRX. Criar um pedido reserva o preço; a cobrança acontece quando a energia está visível na cadeia, não quando um fornecedor diz que ela foi mandada. Uma entrega que falha libera a reserva inteira, automaticamente, sem chamado nenhum para abrir, e um lote misto acerta linha por linha como partially_completed — cobrado pelas posições que chegaram, liberado no resto (como isso aparece numa fatura).
Perguntas que recebemos de verdade
Uma delegação pode esvaziar a carteira em que cai?
Não — e você não precisa aceitar isso na confiança: a conta que recebe ganha acquired_delegated_frozenV2_balance_for_energy e não concede nada em troca, que é tudo o que o registro mostra.
Preciso de TRX na carteira para receber energia?
Não, e uma delegação não toca o saldo em direção nenhuma. A carteira precisa, sim, existir na cadeia: um endereço que nunca foi ativado ainda não é uma conta, e não há a que delegar.
Como sei se um preço cotado é real?
Leia de um endpoint e não de uma página escrita meses atrás. O nosso está na página de preços, ao vivo a cada carregamento; a página do mercado mostra o que os fornecedores que acompanhamos publicam sobre si mesmos, cada leitura carimbada com o instante em que foi tirada. Um preço que ninguém consegue buscar é uma alegação e não uma cotação (mais do que os integradores perguntam).