Security
Understand the security model of CatFee Seamless Energy nodes, what the node can see, what it cannot do, and how to protect the node domain and AccessKey.
Your wallet itself remains secure. The most common question is: "Am I handing asset access to a third party?"
The answer is no.
This is not about whether you trust CatFee. It is determined by TRON's cryptographic signature mechanism: no matter who runs a custom node, they cannot directly obtain your private key or modify your transaction without invalidating the signature.
How TRON transactions actually work
This is worth understanding once, because it applies to every TRON node you use later:
Your wallet first constructs a transaction, including recipient, amount, contract call, and other information.
Your wallet signs the transaction locally with the private key stored on your device.
Only the signed transaction is sent to a node, and the node continues broadcasting it to the TRON network.
The TRON network verifies the signature. If the signature is tampered with, the transaction is rejected directly.
The key point is: signing happens before the transaction reaches any node.
When the Seamless Energy node sees your transaction, the transaction already carries a cryptographic signature that only your private key could generate. The node receives a "transaction that has already been signed", not your private key.
Think of it as a stamped instruction sheet
You write an instruction sheet locally first, meaning the transaction content. Then you use the private key that only you hold to sign it, like adding a digital stamp only you can create. Finally, you hand the stamped instruction sheet to the node for broadcasting.
The node is responsible for delivering the instruction sheet to the TRON network, but it cannot rewrite the content or stamp it again. If the node changes the recipient, amount, or contract parameters, the original signature becomes invalid immediately, and the network will not accept the transaction.
What the node can and cannot see
Your public address
Yes
The node needs to know which address initiated the transaction for resource preparation or bound address validation
Transaction details, such as recipient, amount, and contract call
Yes
They are part of the signed transaction data
Your private key
No
The private key is not transmitted, and signing happens locally
Your mnemonic phrase
No
The mnemonic phrase is not transmitted and remains in your wallet or device
Other accounts in your wallet
No
The node only sees addresses involved in the transaction you actually broadcast
What the node cannot do
Extract your private key
Your private key is not sent to the Seamless Energy node. As long as the normal broadcast flow is used, neither CatFee nor any other TRON node service can see your private key. This is a basic working principle shared by TRON and other blockchains.
Modify your transaction
The node cannot modify your original transaction without invalidating the signature. Even changing one key byte in the signed transaction invalidates the cryptographic signature, and the TRON network rejects the transaction.
Send transactions on your behalf
The node cannot create a valid transaction from your account on your behalf. To make a transaction come from your address, it must be signed again with your private key, which the node does not have.
Access your other tokens or balances
The Seamless Energy node only processes the signed transaction you explicitly broadcast. It has no mechanism to "also" access other tokens, TRX balances, or additional permissions in your account, and it cannot initiate other operations on your account without your signature.
How Seamless Energy nodes differ from default nodes
From a security model perspective, a Seamless Energy node is essentially the same as any public TRON node. The difference is: before forwarding the original transaction, CatFee prepares ENERGY for eligible transactions.
Can see your signed transaction
Yes
Yes
Can access your private key
No
No
Can modify your transaction
No
No
Can initiate a new transaction on your behalf
No
No
Can prepare ENERGY before broadcast
No
Yes
Communication method
HTTPS / TRON standard node protocol
HTTPS / gRPC / TRON standard broadcast API
The same security model and the same cryptographic boundary apply. Seamless Energy only adds one business step: before forwarding the original transaction, it prepares resources for your address.
Built-in protection measures
Keep the node domain and AccessKey confidential
The Seamless Energy node access domain and AccessKey are related to your member balance and node permissions, and should be managed as credentials.
Treat them like API keys:
Do not share them in public channels, public repositories, or screenshots.
Do not hardcode them in frontend source code or browser bundles.
Backend services should store them in environment variables or secret management systems.
If you suspect exposure, disable the node or reset the AccessKey immediately.
If you use API KEY mode, requests use:
Bound address can reduce abuse risk
If the range of addresses that send transactions is relatively fixed, it is recommended to enable bound address mode. This way, even if the node domain is exposed, not every address can continue triggering resource preparation.
This mode is especially suitable for:
Ordinary wallet users.
Wallets that do not support custom Headers.
Integrated applications that use fixed owner addresses.
No-authentication mode is only for temporary testing
No-authentication mode is the easiest to configure, but it also has the highest risk. As long as someone knows the node domain and the node is enabled, their request may be processed.
Therefore it is only suitable for:
Temporary integration testing.
Controlled test environments.
Internal scenarios where the open access risk is explicitly accepted.
What to do if the node domain or AccessKey is exposed
If you suspect the node domain or AccessKey has been exposed, handle it in this order:
Immediately disable the node in the CatFee User Center.
Confirm whether the exposed item is the node domain, AccessKey, or both.
If using bound address mode, immediately check and reduce the bound address range.
If using API KEY mode, reset the AccessKey immediately.
Update the node configuration in wallets, applications, or backends.
Before re-enabling, perform a small verification transaction.
Review logs and consumption records to confirm whether there were abnormal requests or abnormal charges.
Common security questions
Can CatFee steal my TRX or tokens?
No. The node does not hold your private key and cannot create, sign, or broadcast a new transaction on your behalf. Asset control always remains with you.
What happens if the Seamless Energy node is down?
Your assets remain on-chain and do not depend on any single node for storage. If the node is temporarily unavailable, you can still switch back to a regular TRON node and continue broadcasting transactions. The difference is that ENERGY will not be prepared automatically.
Is this a man-in-the-middle attack?
No. One prerequisite for a man-in-the-middle attack is that the middle party can secretly tamper with data. TRON transactions are already signed before they reach the node. Once changed, the signature becomes invalid and the network rejects the transaction.
Why still use HTTPS or TLS?
Seamless Energy nodes provide communication through HTTPS or TLS. This protects the transport link between the wallet or application and the node, preventing third parties on the network from eavesdropping on or tampering with request content. It does not replace transaction signatures, but it further protects transmission.
Compared with the default node, is it more secure, less secure, or the same?
From the cryptographic boundary perspective, it is the same. Default nodes and Seamless Energy nodes cannot obtain your private key or modify signed transactions. The Seamless Energy node only adds a business step: automatically preparing ENERGY before broadcast.
What happens when the balance is insufficient?
This depends on the policy configured in the CatFee User Center:
Continue broadcast: skip ENERGY purchase and continue forwarding the original transaction.
Stop broadcast: return
402 PAYMENT_REQUIREDand do not broadcast the original transaction.
This is not a private key security issue, but it affects business risk and cost control. Configure it clearly in production.
Security checklist before integration
Confirm that the wallet or backend only sends signed transactions to the Seamless Energy node.
Confirm that private keys, mnemonic phrases, or keystore files are not uploaded to CatFee.
Choose an appropriate authentication method instead of using no-authentication mode long term.
Confirm that the node domain and AccessKey will not appear in public repositories, public documents, or public screenshots.
Decide whether to enable bound address based on the business scenario.
Clearly decide whether to continue broadcasting or stop broadcasting when the balance is insufficient.
Complete at least one small real transaction verification.
Next steps
Integration flow: Quick Start.
Developer details: Application Integration.
AI-assisted refactoring: AI-Assisted Integration.
Wallet configuration: Wallet Settings.
Troubleshooting: FAQ.
Last updated