“É seguro?” é a pergunta certa a se fazer sobre qualquer serviço cripto, e ela merece uma resposta melhor do que “sim, somos não custodiais”. A TronSave é não custodial e não exige KYC — mas compradores, provedores e usuários de API expõem coisas diferentes, e uma dessas exposições é real o suficiente para merecer atenção. Aqui está a versão honesta.
O ponto de partida: o que não custodial significa aqui
A TronSave é um marketplace de energia, não uma carteira. Quando você aluga energia, os provedores delegam um recurso ao seu endereço — nada seu sai do lugar. Quando você usa as ferramentas de transferência ou swap, a transação é montada para você e então assinada na sua própria carteira; seus USDT vão direto de você para o destinatário, e a TronSave nunca fica no caminho dos fundos.
Não há conta para abrir nem verificação de identidade. Essa é uma propriedade real do design, e não uma política que possa mudar em silêncio: não há o que verificar porque nada está sendo guardado.
A regra que decorre disso é absoluta e merece ser dita à parte: você nunca envia uma chave privada para a TronSave. A documentação da API diz isso explicitamente, e o próprio auxiliar de assinatura no servidor dos SDKs traz um comentário recomendando que os desenvolvedores prefiram a assinatura local. Se algo pedir sua chave privada ou frase-semente em nome da TronSave, não é a TronSave.
O que um comprador expõe
Muito pouco, com uma exceção que vale citar.
Se você paga as ordens on-chain pela sua carteira conectada, a exposição é a transação que você assinou e nada mais. Se você paga pelo seu saldo interno pré-pago, esse saldo é TRX que você depositou antecipadamente na plataforma — e essa é a única parte realmente custodial do produto.
Isso não é motivo para evitá-lo; o saldo interno é o que torna possível a liquidação instantânea e sem gas das ordens, e ele também funciona como limite de gastos para automações. Mas trate-o como trataria um saldo em qualquer exchange: dimensione-o ao seu uso em vez de estacionar sua tesouraria ali. Uma ou duas semanas de gasto previsto é um teto sensato para a maioria das pessoas. Nosso guia sobre o saldo interno explica o mínimo de 10 TRX, as duas formas de recarga e por que ele também serve como limite de gastos.
O que um provedor expõe
Vender é onde a superfície de segurança é realmente maior, porque a automação precisa de permissões on-chain para delegar em seu nome.
- Seu TRX em staking continua sendo seu. O que você concede é a capacidade de delegar recursos a partir dele, não a capacidade de movê-lo.
- Mudanças de permissão são uma ação on-chain com custo de revisão de 100 TRX, então agrupe-as em vez de conceder uma de cada vez.
- O Automatic Reclaim tem um ponto delicado. Configurado como All, ele recupera toda delegação desbloqueada da sua conta — inclusive as que você fez por conta própria, fora da TronSave. Se o endereço também delega para suas próprias carteiras ou para um parceiro, use Only TronSave. Nosso guia do Sell Settings cobre os demais campos.
- O unstake antecipado é irreversível. Ele funciona por meio de uma mudança de permissão na sua conta e não é algo para clicar sem pensar — veja como funciona o unstake antecipado antes de usá-lo.
Nada disso é incomum para um marketplace de delegação, mas é uma concessão real. Leia o que você está assinando e use um endereço dedicado se a alternativa for misturar a automação da plataforma com carteiras que você gerencia manualmente.
Duas coisas tornam isso verificável, em vez de uma questão de confiança. A permissão concedida cobre apenas a delegação de recursos — não é uma permissão de saldo —, então ela não pode mover, enviar nem sacar seu principal, e sua chave Owner continua sendo sua. E você pode verificar os dois fatos por conta própria: abra as permissões da sua conta no TronScan, confirme que a permissão Active lista apenas a operação de delegação e revogue-a ali quando quiser, assinando a atualização com sua chave Owner. O acesso termina imediatamente. Como regra geral, nunca conceda uma permissão Owner ou de saldo a terceiros.
O que um usuário de API ou agente expõe
Credenciais, e vale tratá-las como segredos no sentido comum.
Uma chave de API alcança as operações da sua conta interna — e é exatamente por isso que ela é a credencial certa para trabalho autônomo: o saldo depositado por trás dela é um teto rígido para o que qualquer coisa pode gastar. Uma sessão por assinatura de carteira fica vinculada à sua carteira e alcança operações da plataforma, o que significa mais poder e exige mais cuidado.
Se você conectar um agente de IA pelo servidor MCP, o identificador de sessão que ele retorna é, ele próprio, uma credencial: quem o tiver pode agir com os direitos dessa sessão até ela expirar. As chaves podem ser revogadas pela API quando você precisar trocá-las, e a revogação vale para todas as requisições seguintes.
Proteções que você tem sem pedir
Várias verificações rodam, você saiba delas ou não:
- Triagem do destinatário. A ferramenta Transfer USDT confere o destino com os alertas de segurança do TronScan — contas em lista negra, atividade de fraude conhecida, remetentes de spam por memo. Um endereço sinalizado bloqueia a transferência. E, quando a verificação não pode ser concluída, ela não mostra um falso verde: você recebe um aviso explícito de “não foi possível verificar”.
- Simulação antes da transmissão. Os swaps são testados na blockchain antes; uma operação que falharia é bloqueada em vez de enviada, e uma simulação que falha não custa nada.
- Sem transmissões duplicadas. Depois que uma transação tem um ID, ela nunca é reenviada, o que elimina o clássico acidente “cliquei duas vezes, paguei duas vezes”.
- Erros óbvios recusados. Enviar para o seu próprio endereço ou indicar um contrato como receptor de energia é rejeitado no formulário, e não on-chain.
Os riscos que são seus, não da plataforma
A maioria das perdas neste canto do mundo cripto não tem nada a ver com o marketplace que você usou.
- Um endereço errado é definitivo. Nenhuma triagem detecta um endereço válido que simplesmente não é o que você queria. Verifique os destinos de forma independente em qualquer valor significativo.
- Envenenamento de endereço (address poisoning). Transferências de poeira a partir de endereços parecidos existem para serem copiadas do seu histórico. Nunca copie um destino de uma lista de transações.
- Sites falsos e endereços colados. Este é o ponto que exige mais cuidado. Endereços de depósito e pagamento devem ser lidos no aplicativo ou no SDK, nunca em uma mensagem, um resultado de busca ou uma captura de tela. Os SDKs expõem o endereço de fundos como um valor que você pode ler no código justamente para que ele nunca seja um texto digitado por alguém.
- Um selo limpo não é garantia. A triagem reflete o que já foi denunciado; um endereço criado hoje de manhã não tem histórico a sinalizar.
Um checklist rápido de proteção
- Mantenha o saldo interno dimensionado aos seus gastos, não aos seus fundos.
- Use chaves de API — não sessões por assinatura — para qualquer coisa autônoma.
- Troque e revogue as chaves que você não usa mais.
- Como provedor, prefira um endereço dedicado e configure o Automatic Reclaim de acordo com o uso que você faz dele.
- Leia os endereços de fundos e de depósito no app ou no SDK, nunca em uma mensagem.
- Verifique destinos de valores altos de forma independente, com ou sem triagem.
Perguntas frequentes
A TronSave guarda meus USDT ou TRX?
Não, a menos que você deposite no saldo interno. A energia alugada é delegada ao seu endereço, e transferências e swaps são assinados na sua própria carteira, então os fundos vão direto de você para o destino.
A TronSave exige KYC?
Não. Não há verificação de identidade, porque não existe conta custodial a verificar.
Algum dia vão pedir minha chave privada?
Não. A assinatura acontece na sua carteira, e a documentação afirma que chaves privadas nunca são enviadas. Qualquer pedido de chave é golpe, não importa em nome de quem.
Qual é a coisa mais arriscada na plataforma?
Para um comprador, um saldo interno grande demais. Para um provedor, as permissões que a automação exige — especialmente o Automatic Reclaim configurado como All em um endereço que você também usa por conta própria.
Meu TRX em staking corre risco se eu fornecer energia?
O stake continua sendo seu; o que você concede é a delegação em seu nome. Os pontos de atenção são o escopo da permissão e o fato de que o staking compromete seu TRX por um período de bloqueio.
O que acontece se minha chave de API vazar?
Alguém poderia fazer ordens usando seu saldo interno — que é limitado ao que você depositou. Revogue a chave imediatamente; a revogação vale para todas as requisições a partir dali.
Conclusão
A resposta sobre custódia é direta: seus tokens ficam na sua carteira, você mesmo assina tudo e ninguém pergunta quem você é. As partes que exigem bom senso são as que as pessoas pulam — quanto você deixa em um saldo pré-pago, quais permissões uma conta de provedor concede e de onde você copiou aquele endereço. Acerte essas três e o risco restante é o risco comum de transacionar em uma blockchain pública, que nenhum marketplace consegue eliminar.
Comece pequeno: alugue a energia de uma única ordem no mercado da TronSave, paga on-chain pela sua própria carteira, antes de recarregar um saldo interno ou conceder qualquer permissão de provedor.
A TronSave publica este blog e opera o marketplace descrito aqui, então considere este texto uma explicação documentada de como o produto funciona, e não uma auditoria independente. O comportamento e as taxas refletem o produto no momento da redação e podem mudar. Transações on-chain são irreversíveis. Isto não é aconselhamento financeiro.
