> For the complete documentation index, see [llms.txt](https://docs.catfee.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catfee.io/en/getting-started/seamless-energy/security.md).

# Security

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:

1. Your wallet first constructs a transaction, including recipient, amount, contract call, and other information.
2. Your wallet signs the transaction locally with the private key stored on your device.
3. Only the signed transaction is sent to a node, and the node continues broadcasting it to the TRON network.
4. 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

| Content                                                           | Visible to the node | Reason                                                                                                              |
| ----------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------- |
| 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.**

| Capability or attribute                       | Default node                        | Seamless Energy node                       |
| --------------------------------------------- | ----------------------------------- | ------------------------------------------ |
| 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:

```http
CF-NODE-KEY: {AccessKey}
```

### 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:

1. Immediately disable the node in the CatFee User Center.
2. Confirm whether the exposed item is the node domain, AccessKey, or both.
3. If using bound address mode, immediately check and reduce the bound address range.
4. If using API KEY mode, reset the AccessKey immediately.
5. Update the node configuration in wallets, applications, or backends.
6. Before re-enabling, perform a small verification transaction.
7. 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_REQUIRED` and 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

1. Confirm that the wallet or backend only sends signed transactions to the Seamless Energy node.
2. Confirm that private keys, mnemonic phrases, or keystore files are not uploaded to CatFee.
3. Choose an appropriate authentication method instead of using no-authentication mode long term.
4. Confirm that the node domain and AccessKey will not appear in public repositories, public documents, or public screenshots.
5. Decide whether to enable bound address based on the business scenario.
6. Clearly decide whether to continue broadcasting or stop broadcasting when the balance is insufficient.
7. Complete at least one small real transaction verification.

## Next steps

* Integration flow: [Quick Start](/en/getting-started/seamless-energy/quick-start.md).
* Developer details: [Application Integration](/en/getting-started/seamless-energy/application-integration.md).
* AI-assisted refactoring: [AI-Assisted Integration](/en/getting-started/seamless-energy/ai-assisted-integration.md).
* Wallet configuration: [Wallet Settings](/en/getting-started/seamless-energy/wallet-settings.md).
* Troubleshooting: [FAQ](/en/getting-started/seamless-energy/faq.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.catfee.io/en/getting-started/seamless-energy/security.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.