Other Wallets and Apps

For other wallets, DApps, backend services, and self-built middleware, learn how to connect to the CatFee Seamless Energy node and when to choose different authentication modes.

Besides TronLink, any wallet, DApp, backend service, or middleware that can control the TRON transaction broadcast target can integrate CatFee Seamless Energy.

Applicable scenarios

• Desktop or mobile wallets that support custom TRON nodes.

• Self-built backend services responsible for centrally broadcasting signed transactions.

• Wallet aggregators, custody panels, or multi-tenant business systems.

• Server-side applications that connect directly to TRON nodes through gRPC.

Which authentication method to choose

Bound address

Suitable when:

• The wallet does not support custom Headers.

• The number of addresses is limited.

• You want to keep configuration complexity low.

Validation rule:

• The owner address of the first transaction in the request must be bound to the node.

API KEY

Suitable when:

• Transactions are broadcast centrally by a backend.

• There are many addresses and binding them one by one is inconvenient.

• The client supports HTTP Header or gRPC metadata.

API KEY is passed through this field:

CF-NODE-KEY: {AccessKey}

Validation rule:

• The passed value must match the 41-character random AccessKey stored for the node.

No authentication

Only suitable for temporary testing or scenarios where you explicitly accept the risk of open access. It is not recommended for long-term use.

HTTP application integration

If the application currently calls a TRON node through HTTP, only replace the broadcast domain and keep the original path:

POST https://{NodeSlug}.catfee.vip/wallet/broadcasthex
POST https://{NodeSlug}.catfee.vip/wallet/broadcasttransaction

The request body remains in the original TRON format.

gRPC application integration

If the application currently calls a TRON node through gRPC, usually you only need to replace the target server and keep the broadcast method unchanged:

Server: {NodeSlug}.catfee.vip
Port: 443
SSL/TLS: enabled
Broadcast path: /protocol.Wallet/BroadcastTransaction

If API KEY is used, pass CF-NODE-KEY through gRPC metadata.

Recommended integration methods

• Pure wallet-side integration: prefer bound address.

• Wallet plus self-owned backend: prefer backend API KEY.

• Enterprise multi-address business: use centralized backend broadcasting and manage the AccessKey centrally.

Common notes

• Only send signed transactions. Do not upload private keys, mnemonic phrases, or keystore files to CatFee.

• The node domain is used for routing and should not be distributed publicly as the only credential.

• If the UI layer cannot customize authentication headers, prefer bound address mode.

• Before changing nodes, verify the full flow with a small contract transaction.

Next steps

• Developer details: Application Integration.

• Risk boundaries: Security.

• Common errors: FAQ.