“Is it safe?” is the right question to ask of any crypto service, and it deserves a better answer than “yes, we’re non-custodial.” TronSave is non-custodial and does not ask for KYC — but buyers, providers and API users each expose something different, and one of those exposures is real enough to be worth managing. Here is the honest version.
The baseline: what non-custodial actually means here
TronSave is an energy marketplace, not a wallet. When you rent energy, providers delegate a resource to your address — nothing of yours moves anywhere. When you use the transfer or swap tools, the transaction is built for you and then signed in your own wallet; your USDT goes straight from you to the recipient, and TronSave is never in the path of the funds.
There is no account to open and no identity check. That is a genuine property of the design rather than a policy that could change quietly: there is nothing to verify because there is nothing being held.
The rule that follows from this is absolute and worth stating on its own: you never send a private key to TronSave. The API documentation says so explicitly, and the SDKs’ own server-side signing helper carries a comment telling developers to prefer local signing instead. If anything ever asks you for a private key or seed phrase in TronSave’s name, it is not TronSave.
What a buyer exposes
Very little, with one exception worth naming.
If you pay for orders on-chain from your connected wallet, the exposure is the transaction you signed and nothing more. If you pay from your prepaid internal balance, that balance is TRX you have deposited with the platform in advance — and that is the one genuinely custodial piece of the product.
It is not a reason to avoid it; the internal balance is what makes gas-free, instant order settlement possible, and it doubles as a spending cap for automation. But treat it the way you would treat a float on any exchange: size it to your usage rather than parking your treasury there. A week or two of expected spend is a sensible ceiling for most people.
What a provider exposes
Selling is where the security surface is genuinely larger, because automation needs on-chain permissions to delegate on your behalf.
- Your staked TRX stays yours. What you grant is the ability to delegate resources from it, not the ability to move it.
- Permission changes are an on-chain action with a 100 TRX review cost, so batch them rather than granting one at a time.
- Automatic Reclaim has a sharp edge. Set to All, it reclaims every unlocked delegation from your account — including ones you made privately, outside TronSave. If the address also delegates to your own wallets or a partner, use Only TronSave. Our Sell Settings guide covers the rest of the fields.
- Early Unstake is irreversible. It works through a permission change on your account, and it is not something to click through casually — see how early unstake works before using it.
None of this is unusual for a delegation marketplace, but it is a real grant. Read what you are signing, and use a dedicated address if the alternative is mixing platform automation with wallets you manage by hand.
Two things make this checkable rather than a matter of trust. The permission granted covers resource delegation only — not a balance permission — so it cannot move, send or withdraw your principal, and your owner key stays yours. And you can verify both facts yourself: open your account permissions on TronScan, confirm the active permission lists only the delegate operation, and revoke it there at any time by signing the update with your owner key. Access ends immediately. As a general rule, never grant an owner or balance permission to any third party.
What an API or agent user exposes
Credentials, and they are worth treating as secrets in the ordinary sense.
An API key reaches your internal-account operations — which is precisely why it is the right credential for autonomous work: the funded balance behind it is a hard ceiling on what anything can spend. A wallet-signature session is bound to your wallet and reaches platform operations, which is more power and more care.
If you connect an AI agent through the MCP server, the session identifier it returns is itself a credential: anyone holding it can act with that session’s rights until it expires. Keys can be revoked through the API when you need to rotate them, and revocation takes effect for every subsequent request.
Protections you get without asking
Several checks run whether or not you know about them:
- Receiver screening. The Transfer USDT tool checks the destination against TronScan’s security flags — blacklisted accounts, known fraud activity, memo-spam senders. A flagged address blocks the transfer. And when the check cannot be completed, it does not show a false green: you get an explicit “couldn’t verify” warning instead.
- Simulation before broadcast. Swaps are run against the chain first; a trade that would fail is blocked rather than sent, and a failed simulation costs nothing.
- No double-broadcasts. Once a transaction has an ID it is never re-sent, which rules out the classic “clicked twice, paid twice” accident.
- Obvious mistakes refused. Sending to your own address, or naming a contract as an energy receiver, are rejected at the form rather than on-chain.
The risks that are yours, not the platform’s
Most losses in this corner of crypto have nothing to do with the marketplace you used.
- A wrong address is final. No screening catches a valid address that simply is not the one you meant. Verify destinations independently for anything significant.
- Address poisoning. Dust transfers from lookalike addresses exist to get copied out of your history. Never copy a destination from a transaction list.
- Fake sites and pasted addresses. This is the one to be most careful about. Deposit and payment addresses should be read from the application or the SDK, never from a message, a search result, or a screenshot. The SDKs expose the fund address as a value you can read in code precisely so it is never a string somebody typed.
- A clean badge is not a guarantee. Screening reflects what has already been reported; an address created this morning has no history to flag.
A short hardening checklist
- Keep the internal balance sized to your spending, not your holdings.
- Use API keys — not signature sessions — for anything autonomous.
- Rotate and revoke keys you no longer use.
- As a provider, prefer a dedicated address, and set Automatic Reclaim to match how you use it.
- Read fund and deposit addresses from the app or SDK, never from a message.
- Verify large destinations independently, screening or no screening.
FAQ
Does TronSave hold my USDT or TRX?
Not unless you deposit into the internal balance. Rented energy is delegated to your address, and transfers and swaps are signed in your own wallet, so funds move directly from you to their destination.
Does TronSave require KYC?
No. There is no identity verification, because there is no custodial account to verify.
Will I ever be asked for my private key?
No. Signing happens in your wallet, and the documentation states that private keys are never sent. Any request for one is a scam, regardless of whose name is on it.
What is the riskiest thing on the platform?
For a buyer, an oversized internal balance. For a provider, the permissions that automation requires — particularly Automatic Reclaim set to All on an address you also use privately.
Is my staked TRX at risk if I provide energy?
The stake stays yours; what you grant is delegation on your behalf. The considerations are the permission scope and the fact that staking commits your TRX for a lock-up period.
What happens if my API key leaks?
Someone could place orders against your internal balance — which is capped by whatever you funded. Revoke the key immediately; revocation applies to every request after it.
Bottom line
The custody answer is straightforward: your tokens stay in your wallet, you sign everything yourself, and nobody asks who you are. The parts that need judgement are the ones people skip — how much you leave in a prepaid balance, which permissions a provider account grants, and where you copied that address from. Get those three right and the remaining risk is the ordinary risk of transacting on a public blockchain, which no marketplace can remove.
Start small: rent a single order’s worth of energy on the TronSave market, paid on-chain from your own wallet, before you fund an internal balance or grant any provider permissions.
TronSave publishes this blog and operates the marketplace described here, so treat this as a documented explanation of how the product works rather than an independent audit. Behaviour and fees reflect the product at the time of writing and can change. On-chain transactions are irreversible. This is not financial advice.
