> 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/ai-assisted-integration.md). # AI-Assisted Integration 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. ```js 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](/en/getting-started/seamless-energy/application-integration.md). * Complete the first verification: [Quick Start](/en/getting-started/seamless-energy/quick-start.md). * Check credentials and private key boundaries: [Security](/en/getting-started/seamless-energy/security.md). * Troubleshoot common statuses: [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/ai-assisted-integration.md?ask=&goal= ``` `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.