Por Dentro da Delegação de Recursos no TRON: Como Funciona de Verdade

O Modelo de Recursos Antes de Entender a Delegação

O TRON não cobra gas no estilo Ethereum. Em vez disso, cada conta possui dois pools de recursos: Energy e bandwidth. O Energy é consumido pela execução de contratos inteligentes. O bandwidth é consumido por toda transação, independentemente de ela interagir com um contrato ou não. Quando sua conta fica sem qualquer um dos dois, a rede queima TRX do seu saldo para cobrir o déficit. É essa queima que torna as operações caras.

Os recursos são gerados de duas formas. A primeira é pelo staking de TRX: bloqueie TRX e a rede credita sua conta com uma parcela proporcional do pool global de Energy ou bandwidth, renovado a cada 24 horas. A segunda é por meio do recebimento de uma delegação: outra conta faz staking de TRX e atribui os recursos gerados ao seu endereço. Sua conta utiliza os recursos delegados exatamente como se você mesmo tivesse feito o staking. Do ponto de vista da máquina virtual, não há qualquer diferença.

Essa é a base sobre a qual todo o restante se sustenta. A delegação não é um canal de pagamento nem um invólucro. É uma atribuição direta de direitos sobre recursos na blockchain, de uma conta para outra.

O Que o Stake 2.0 Mudou na Delegação

O modelo original de staking (Stake 1.0) exigia que você escolhesse, no momento do stake, se seu TRX produziria Energy ou bandwidth, e só era possível desbloquear o valor total de uma vez após um período de bloqueio de 3 dias. A delegação existia, mas era bastante limitada. Você fazia staking de TRX, gerava um tipo de recurso e, opcionalmente, direcionava esse recurso para outro endereço.

O Stake 2.0, ativado na rede principal em meados de 2023, reestruturou esse processo de forma significativa. As principais mudanças relevantes para a delegação são:

• Divisão proporcional de recursos: Uma única posição de TRX em staking pode ter seus recursos gerados divididos e delegados a múltiplos endereços ao mesmo tempo. Você não está enviando TRX para lugar nenhum; está apenas direcionando a saída de recursos.
• Desbloqueio em parcelas: É possível fazer unstaking de valores parciais sem mexer no restante da posição. Isso permite que provedores de recursos gerenciem a liquidez sem interromper delegações ativas.
• Prazo de 14 dias para desbloqueio: Após chamar o comando unstake, o TRX entra em uma fila de retirada. Ele fica bloqueado por aproximadamente 14 dias até que você possa chamar withdrawExpireUnfreeze para recuperá-lo. Durante esse período, qualquer delegação que dependia daquele TRX é cancelada imediatamente, e não após os 14 dias. A delegação se encerra no momento em que o unstake é iniciado, não quando o TRX é recebido de volta.
• Fim do bloqueio para troca de tipo de recurso: No modelo 1.0, alternar de Energy para bandwidth exigia um ciclo completo de unstake e re-stake. No 2.0, é possível redirecionar a saída de recursos da mesma posição em staking para um tipo diferente sem fazer unstake, embora isso ainda exija uma transação separada na blockchain.

A implicação prática para quem recebe Energy delegado é clara: seu saldo de recursos pode cair a zero no meio do dia se o delegador iniciar um unstake. Não há período de carência para quem está recebendo a delegação.

A Mecânica de uma Transação de Delegação na Blockchain

Quando um delegador chama delegateResource, a transação registra três informações: o endereço do delegador, o endereço do destinatário e a quantidade de Energy (ou bandwidth) sendo delegada. A rede então ajusta os limites de recursos exibidos no estado da conta do destinatário.

Internamente, os nós TRON rastreiam os recursos delegados separadamente dos recursos próprios. Se você consultar uma conta via wallet/getaccount na API HTTP, verá campos como delegated_frozenV2_balance_for_energy e acquired_delegated_frozenV2_balance_for_energy. O primeiro representa o que você enviou. O segundo representa o que você recebeu. Nenhum deles movimenta TRX. O TRX em si permanece no saldo bloqueado do delegador.

O consumo de recursos durante uma transação funciona assim: a máquina virtual verifica o Energy disponível na conta em execução (staking próprio mais delegações recebidas). Se for suficiente, deduz desse pool na seguinte ordem: primeiro as delegações recebidas são consumidas, depois o staking próprio. Se o pool se esgotar, TRX é queimado do saldo livre da conta pela taxa atual da rede. Essa taxa não é fixa. Ela é calculada dinamicamente com base no Energy total da rede e no preço de queima definido pelos parâmetros da blockchain.

Como o Energy Se Recupera Após o Uso

O Energy não é um crédito de uso único. O Energy utilizado se recupera de forma linear ao longo de uma janela de 24 horas. Se sua conta tem um limite máximo de 100.000 de Energy e você usa 65.000 executando um contrato, voltará ao máximo após 24 horas. Na metade desse tempo (12 horas), você terá aproximadamente 32.500 disponíveis novamente.

Essa recuperação se aplica tanto ao Energy do staking próprio quanto ao delegado. A taxa de recuperação está vinculada ao máximo da conta, e não a um relógio global fixo. Portanto, duas contas com limites de Energy diferentes se recuperam em taxas absolutas distintas, ainda que ambas se reponham completamente em 24 horas.

Para operações de alta frequência, esse ciclo de 24 horas é o principal fator limitante. Uma delegação dimensionada para uma transferência por dia não vai cobrir dez transferências por dia, mesmo que o Energy total pareça suficiente no papel. É preciso levar em conta o ritmo de recuperação, não apenas a capacidade total.

Revogar e Redirecionar Delegações

A delegação não é permanente. Um delegador pode chamar unDelegateResource a qualquer momento para recuperar os recursos. O efeito é imediato: o Energy disponível do destinatário cai pelo valor revogado já no próximo bloco. Não há período de carência para quem recebe, nem qualquer mecanismo de compensação no nível do protocolo.

Redirecionar uma delegação, ou seja, enviar a mesma saída de recursos para um destinatário diferente, exige duas transações: revogar do destinatário atual e depois delegar para o novo. São operações separadas na blockchain e elas mesmas consomem bandwidth. No Stake 2.0 é possível fazer isso de forma mais eficiente do que antes, mas ainda não são operações atômicas em uma única transação.

Um caso específico que vale conhecer: se o TRX em staking de um delegador gera, digamos, 200.000 de Energy, e ele delegou 150.000 para o endereço A, ainda é possível delegar os 50.000 restantes para o endereço B sem alterar a delegação de A. A restrição é que o total de Energy delegado não pode ultrapassar o total de Energy gerado. Tentar delegar além desse limite resultará em falha no nível da transação.

O Que Isso Significa para o Aluguel de Energy

Serviços de aluguel de Energy como o tronenergyrent.com operam inteiramente dentro desse modelo de delegação. Quando você aluga Energy, o provedor faz staking de TRX, gera Energy e chama delegateResource apontando para o seu endereço. Do ponto de vista da sua conta, você recebe acquired_delegated_frozenV2_balance_for_energy exatamente como descrito acima. Você não detém TRX. Você detém uma alocação temporária de recursos.

A duração do aluguel corresponde ao tempo em que o provedor mantém essa delegação ativa. Um aluguel de 1 dia pelo preço atual custa 8,19 TRX por 65.000 de Energy (suficiente para cobrir uma transferência padrão de USDT TRC-20, que exige aproximadamente 65.000 de Energy e 345 de bandwidth). Um aluguel de 30 dias sai por 175,50 TRX para o mesmo bloco de Energy. Você pode verificar os custos exatos para o seu volume de transferências na calculadora.

O motivo pelo qual aluguéis de curta duração custam mais por dia é puramente mecânico: o provedor precisa gerenciar a fila de unstaking e o custo operacional de redelegação para ciclos frequentes. O prazo de retirada de 14 dias significa que o capital fica imobilizado independentemente de quanto tempo dura o aluguel.

A Delegação de Bandwidth Segue o Mesmo Modelo

Tudo o que foi descrito acima se aplica igualmente ao bandwidth, com uma diferença no comportamento padrão. Toda conta recebe 600 de bandwidth gratuito por dia da rede, independentemente de staking. Essa alocação gratuita cobre transferências básicas de TRX, mas não é suficiente para a parte de bandwidth de transferências TRC-20 em alta frequência. Fazer staking ou receber bandwidth delegado aumenta seu limite acima dessa base de 600.

Quando você delega bandwidth para uma conta, está somando à capacidade dela além de qualquer alocação gratuita que ela já possua. A ordem de consumo é: primeiro o bandwidth gratuito, depois o bandwidth delegado, depois o bandwidth do staking próprio e por último a queima de TRX. Essa ordem importa se você estiver tentando calcular exatamente quando a queima vai começar para uma determinada conta.

Lendo o Estado da Delegação pela API

Se você está desenvolvendo ferramentas ou monitorando uma delegação, as chamadas de API relevantes são:

• wallet/getaccount: retorna o estado completo da conta, incluindo os campos de recursos delegados e recebidos
• wallet/getdelegatedresourcev2: retorna o registro de delegação específico entre dois endereços, incluindo o valor exato de Energy e a data de expiração do bloqueio, se houver algum definido
• wallet/getcanwithdrawunfreezeamount: permite que um delegador verifique quanto do seu unstake em fila já está disponível para retirada

O endpoint getdelegatedresourcev2 é especialmente útil para confirmar que uma delegação está ativa e com o tamanho correto antes de executar transações que dependam dela. Não presuma que uma delegação está em vigor só porque foi configurada no dia anterior. Sempre confirme o estado na blockchain antes de depender dela.