Handling TRON ENERGY at the broadcast layer — no private keys, no transaction modification
Hey TRON developers,
We recently launched CatFee Senseless Energy, a broadcast-layer enhancement service for TRON transactions.
The idea is simple:
Instead of asking users to manually rent ENERGY before sending TRC20 transfers or contract interactions, wallets and backend services can broadcast already-signed transactions to a dedicated CatFee node. Before forwarding the original transaction to the TRON network, CatFee automatically estimates the required ENERGY, prepares resources for the transaction owner address, and then broadcasts the original transaction unchanged.
From the developer side, integration is designed to be lightweight.
In most cases, you only need to replace your current TRON broadcast node domain with your dedicated CatFee Senseless Energy node:
https://{NodeSlug}.catfee.vip
Supported broadcast interfaces include:
POST /wallet/broadcasttransaction
POST /wallet/broadcasthex
For gRPC clients:
Server: {NodeSlug}.catfee.vip
Port: 443
TLS: Enabled
Method: /protocol.Wallet/BroadcastTransaction
A simple HTTP example:
curl -X POST "https://bright-blue-river.catfee.vip/wallet/broadcasttransaction" \
-H "Content-Type: application/json" \
-H "CF-NODE-KEY: {AccessKey}" \
-d '{
"raw_data_hex": "...",
"signature": ["..."]
}'
A few important points:
- CatFee only receives already-signed transactions
- CatFee does not require private keys, seed phrases, keystores, or wallet custody
- CatFee cannot sign transactions on behalf of users
- CatFee does not modify the original transaction
- The original transaction is forwarded in the standard TRON broadcast format
- Non-contract transactions are forwarded directly without ENERGY purchase
- Current ENERGY handling focuses on the first
TriggerSmartContractcall in the transaction
For authentication, nodes can be configured in three modes:
- No auth — useful for testing
- Bound addresses — suitable for wallet users
- API Key — suitable for developers, wallets, and backend services managing many addresses
API Key mode uses a simple request header or gRPC metadata:
CF-NODE-KEY: {AccessKey}
This service is mainly designed for:
- TRON wallet developers
- Telegram bot developers
- TRC20 payment tools
- exchanges or payment gateways
- backend services that broadcast many signed TRON transactions
- apps that want users to send USDT/TRC20 transactions without manually handling ENERGY
One limitation to be transparent about: TRON does not provide Ethereum-style nonce queuing or bundle execution. After the ENERGY transaction is broadcast successfully, CatFee waits briefly before forwarding the original transaction, but final execution still depends on TRON network state and contract conditions.
If you are building on TRON and want a simpler way to handle ENERGY for signed transactions, this may be useful.