AI-Assisted Integration

Developer guide for using AI coding assistants to locate the TRON broadcast entry point, generate an integration plan, check security boundaries, and complete CatFee Seamless Energy integration testin

If your project already has TRON transaction signing and broadcasting logic, an AI coding assistant can help you locate the integration point faster. Treat it as a code review and refactoring assistant, not as a tool that decides private key handling, security strategy, or production configuration for you.

The most important rule is: do not send private keys, mnemonic phrases, keystore files, real AccessKeys, or production node domains to AI.

What AI is best at helping with

• Locating the TRON broadcast entry point in the codebase.

• Distinguishing signing logic, transaction construction logic, and broadcast logic.

• Generating a minimal change plan that only replaces the broadcast domain.

• Checking whether CF-NODE-KEY only appears on the server side and in environment variables.

• Generating an integration checklist for small contract transaction testing.

• Checking whether normal query requests were incorrectly switched to the Seamless Energy node.

AI should not make these decisions for you:

• Whether to expose the node domain publicly.

• How to handle real private keys, mnemonic phrases, or keystore files.

• Whether production should continue broadcasting or stop broadcasting when the balance is insufficient.

• Inventing fields, prices, status codes, or SLA commitments that CatFee has not published.

Prepare context for AI

Replace real credentials with placeholders before giving context to AI. Recommended information:

Project type: Node.js / Java / Python / Go / PHP / other
Current TRON SDK or node call method: for example TronWeb, HTTP API, gRPC, self-built gateway
Where signing happens: frontend wallet, local service, backend service, third-party wallet
Broadcast entry point: if known, provide the function name, file name, or API path
Current broadcast path: /wallet/broadcasttransaction or /wallet/broadcasthex
Target Seamless Energy node: https://{NodeSlug}.catfee.vip
Authentication method: API KEY / bound address / temporary no authentication
AccessKey: do not provide the real value; write {AccessKey}
Insufficient balance policy: continue broadcast / stop broadcast / to be confirmed
Test transaction type: small TRC20 transfer, approval, or low-risk contract call

If you do not know where the broadcast entry point is, ask AI to search for these keywords first:

broadcasttransaction
broadcasthex
BroadcastTransaction
sendRawTransaction
tronWeb.trx.sendRawTransaction
fullNode
TronWeb
/wallet/

Recommended prompt: locate the broadcast entry point

You are a developer familiar with TRON and backend transaction broadcast flows.

Please read the code snippets I provide and help me locate where the signed transaction is finally broadcast to the TRON node.

Requirements:
1. Distinguish the three stages: transaction construction, transaction signing, and transaction broadcasting.
2. Only locate the broadcast entry point. Do not modify signing logic.
3. Mark code that may call /wallet/broadcasttransaction, /wallet/broadcasthex, BroadcastTransaction, or sendRawTransaction.
4. If the current code uses the same node configuration for query, construction, and broadcasting, explain the risk and optional approaches for only replacing the broadcast entry point.
5. Do not ask me to provide private keys, mnemonic phrases, keystore files, or real AccessKeys.

Recommended prompt: generate the minimal integration plan

You are a senior TRON developer. I want to integrate my existing signed transaction broadcast entry point with CatFee Seamless Energy.

Known information:
- Seamless Energy only handles the signed transaction broadcast stage.
- The original transaction is still signed locally by my wallet or backend.
- The broadcast domain should be replaced with https://{NodeSlug}.catfee.vip.
- The HTTP path keeps the original TRON format, such as /wallet/broadcasttransaction or /wallet/broadcasthex.
- If API KEY is used, pass CF-NODE-KEY: {AccessKey} through the HTTP header or gRPC metadata.
- Private keys, mnemonic phrases, keystore files, and AccessKeys must not be written into frontend source code.

Based on the code I provide:
1. Give the minimal change plan.
2. Clearly state which files should be changed and which files should not be changed.
3. Keep the signature, transaction body, owner address, and contract parameters unchanged.
4. Add an example of reading the node domain and AccessKey from environment variables.
5. Provide an integration verification checklist.

Recommended prompt: pre-launch review

Please review this CatFee Seamless Energy integration change as a code reviewer.

Focus on:
1. Whether only the signed transaction broadcast entry point was changed.
2. Whether signing logic, transaction construction logic, owner address, or contract parameters were changed by mistake.
3. Whether CF-NODE-KEY, AccessKey, node domain, or other credentials are exposed in the frontend bundle, logs, public repository, or screenshots.
4. Whether the expected behavior is distinguished between contract transactions and regular TRX transfers.
5. Whether insufficient balance, disabled node, authentication failure, rate limiting, and broadcast failure are handled.
6. Whether end-to-end verification has been completed with a small TRC20 transfer or approval transaction.

Output in this format: Must fix / Suggested improvements / Confirm before launch.

Security constraints for AI-generated code

No matter what code AI generates, manually confirm these constraints:

1. Private keys, mnemonic phrases, and keystore files do not enter CatFee requests.

2. CF-NODE-KEY is only used in server-side services, backend gateways, or controlled runtime environments.

3. Frontend browser code does not hardcode the AccessKey.

4. The original transaction is signed before being sent to the Seamless Energy node.

5. The request path is still the original TRON broadcast API.

6. Normal query requests do not trigger resource preparation because of the integration change.

7. After small contract transaction verification succeeds, expand to production traffic gradually.

Example: ask AI to refactor an HTTP broadcast function

The following is an abstract example to help you check whether AI-generated code is moving in the right direction. Use the actual TRON transaction object format from your project.

const nodeUrl = process.env.CATFEE_NODE_URL;
const nodeKey = process.env.CATFEE_NODE_KEY;

async function broadcastSignedTransaction(signedTransaction) {
  const response = await fetch(`${nodeUrl}/wallet/broadcasttransaction`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "CF-NODE-KEY": nodeKey,
    },
    body: JSON.stringify(signedTransaction),
  });

  return response.json();
}

This example only shows the integration direction:

• signedTransaction should already be signed.

• nodeUrl uses the Seamless Energy node domain, for example https://{NodeSlug}.catfee.vip.

• nodeKey is read from an environment variable and is not hardcoded.

• This function does not generate, read, or upload private keys.

What AI can help check during integration testing

After the code change is complete, you can give AI sanitized request logs, error codes, and configuration notes to help troubleshoot. Ask AI to check in this order:

1. Whether the request is sent to the Seamless Energy node domain.

2. Whether the path is still the original TRON broadcast path.

3. Whether API KEY mode carries CF-NODE-KEY.

4. Whether the transaction is already signed.

5. Whether the test transaction is a TriggerSmartContract contract transaction.

6. Whether the insufficient balance policy matches expectations.

7. Whether the response is still handled as a TRON broadcast API response.

Do not use a regular TRX transfer as the only verification, because regular TRX transfers do not trigger ENERGY preparation.

Next steps

• Understand the broadcast flow first: Application Integration.

• Complete the first verification: Quick Start.

• Check credentials and private key boundaries: Security.

• Troubleshoot common statuses: FAQ.