Dedicated TRON Broadcast Node / Signed Transaction Enhancement

Seamless Energy Build Energy Preparation into Broadcasting

Submit a signed transaction to your dedicated CatFee Seamless Energy node. The node detects the required resources, prepares them, and then forwards the original transaction unchanged to CatFee's TRON node.

Apply for a Dedicated Node
CatFee Seamless Energy service logoCATFEE

Replace Only theBroadcast API

Before forwarding a signed TRON transaction, CatFee automatically prepares ENERGY and Bandwidth.

Signed Transaction

CatFee Seamless Energy broadcast layer

CatFee

Broadcast Layer

Seamless Energy

Automatically purchases ENERGY and Bandwidth

Helps reduce transfer costs

TRON network logo

TRON Node

  • HTTP / gRPC Support
  • No Private Key Required
  • Original Transaction Unchanged
Dedicated Broadcast NodeCF-NODE-KEYApplication-side SigningMultiple StrategiesForward After DelegationTraceable Results

Why Developers Need It

Why Seamless Energy

This is not another one-off energy purchase. It brings broadcasting, resource preparation, and security boundaries into one reliable path.

ENERGY Should Not Interrupt Your Flow

TRC20 transfers, approvals, and contract calls should not require a separate energy order and an extra wait before broadcasting.

Signing Authority Stays with You

Your application constructs and signs transactions in its own secure environment. Broadcast enhancement never accesses private keys or modifies transactions.

Resources Must Be Ready Before Broadcast

TRON has no nonce queue or bundle mechanism, so the resource transaction should arrive before the original transaction whenever possible.

A Node Domain Is Not a Credential

The domain identifies the node. Production requests also use CF-NODE-KEY authentication to prevent access-key abuse.

Product Capabilities

Core Capabilities

CatFee packages node infrastructure, resource handling, and upstream forwarding into a broadcast node developers can integrate directly.

Dedicated Domain, Drop-in Broadcast Endpoint

Apply for a dedicated Seamless Energy node such as https://{NodeSlug}.catfee.vip, then replace your existing broadcast domain.

Compatible with Native TRON Broadcast APIs

Keep native paths and request formats such as /wallet/broadcasttransaction and /wallet/broadcasthex.

Signed Transactions Only, No Private Keys

Your system constructs and signs each transaction. CatFee neither signs for you nor changes the original transaction.

Node-level Keys for Environment Isolation

Authenticate with CF-NODE-KEY and manage dedicated nodes and access keys separately for testing and production.

Estimate and Prepare ENERGY Before Broadcast

For supported contract calls, the node detects required ENERGY and forwards the transaction after resource delegation succeeds.

Configurable Failure Handling and Traceable Results

Choose what happens when preparation fails, and use node records to investigate authentication, rate limiting, preparation, and forwarding issues.

Integration Flow

Transaction Broadcast Flow

Your system retains transaction construction and signing authority. CatFee only enhances the signed-transaction broadcast path.

1. Sign in Your Environment

Your application or service constructs and signs the TRON transaction in its own secure environment, keeping private keys and signing authority under your control.

2. Submit for Broadcast

Your backend sends the signed transaction to the dedicated Seamless Energy node using the native TRON path and request format.

3. Identify the Node

CatFee uses {NodeSlug}.catfee.vip to locate the member's Seamless Energy node and its current status.

4. Authenticate

The node validates CF-NODE-KEY and confirms that the service is authorized to use this dedicated node.

5. Prepare Resources

The node currently detects the ENERGY required by the first TriggerSmartContract call and initiates resource delegation.

6. Forward After Delegation

After delegation succeeds, CatFee forwards the original transaction unchanged to its TRON node.

7. Confirm On-chain

CatFee preserves the TRON broadcast response. Resource arrival and on-chain confirmation can still be affected by TRON network conditions.

8. Complete

After confirmation, the Seamless Energy broadcast flow is complete and your system can continue with notifications, records, and downstream tasks.

Use Cases

Built for Developer Workflows

For developers and service providers that control the transaction broadcast endpoint and want ENERGY preparation handled automatically.

Wallet Providers

Use CatFee as an enhanced broadcast endpoint to reduce transaction failures caused by insufficient ENERGY.

Developers and Backend Services

Send CF-NODE-KEY through an HTTP header or gRPC metadata when managing large address sets.

Payment and Trading Systems

Add a stable ENERGY preparation and broadcast path for payments, merchant settlement, and frequent on-chain operations.

DApps, Bots, and Automation

Support TRC20 transfers, approvals, swaps, and other contract interactions that depend on ENERGY.

Security and Boundaries

Security and Integration Summary

Seamless Energy separates security into three layers: your system retains signing authority, the dedicated node authenticates access, and the broadcast path returns clear processing results.

Integration Note

Signing Boundary

Transactions are constructed and signed by your application or backend. CatFee never accesses private keys, seed phrases, or keystores, and never modifies the original transaction.

Application-side signingNo private-key custodyNo transaction changes

Integration Note

Node Authentication

Send CF-NODE-KEY through an HTTP header or gRPC metadata. The AccessKey belongs to the dedicated node and can be viewed or reset in the dashboard.

CF-NODE-KEYNode-level AccessKeyResettable key

Integration Note

Supported Scope

The node is compatible with native TRON broadcast paths and currently focuses on signed transactions containing TriggerSmartContract. Other transactions follow the configured node strategy.

Native broadcast pathsSigned transactionsDefined processing scope

Integration Note

Failure Strategy

If resource preparation fails or the balance is insufficient, choose whether to stop or continue broadcasting and use the result for retries, alerts, and troubleshooting.

Stop or continueTraceable resultsApplication-side retry

Start Integrating

Application and Integration

Developers and service providers integrate over HTTP or gRPC using a dedicated node domain and CF-NODE-KEY.

Developers and Service Providers

For HTTP, gRPC, and automated business systems

  • Send CF-NODE-KEY through an HTTP header or gRPC metadata.
  • AccessKey is a 41-character node-level random key that can be viewed or reset in the dashboard.
  • Keep the native TRON broadcast path and only replace the domain and add authentication information.
CF-NODE-KEY: {AccessKey}
POST /wallet/broadcasttransaction

Before You Integrate

Frequently Asked Questions

Understand product differences, security boundaries, supported scope, node authentication, and failure handling.

How is Seamless Energy different from buying energy?

A standard energy purchase requires creating an order and specifying a receiving address first. Seamless Energy puts resource preparation directly into the broadcast path, so your system only submits the signed transaction to its dedicated node.

Broadcast enhancementAutomatic preparationNo advance order
Can CatFee access private keys or modify transactions?

No. Your system constructs and signs each transaction. CatFee only reads the signed transaction to determine resource requirements and forwards it unchanged after preparation succeeds.

No private-key custodyApplication-side signingUnchanged forwarding
Which broadcast APIs and transaction types are supported?

The service currently supports /wallet/broadcasttransaction and /wallet/broadcasthex, focusing on signed transactions that contain TriggerSmartContract. Validate your exact contract call with a test transaction before production integration.

broadcasttransactionbroadcasthexTriggerSmartContract
How is a dedicated node protected from unauthorized use?

Each node has an independent AccessKey. Send CF-NODE-KEY through an HTTP header or gRPC metadata. The key can be viewed or reset in the dashboard.

CF-NODE-KEYAccessKeyNode authentication
What happens if resource preparation fails?

Configure the node to either continue or stop broadcasting when the balance is insufficient or resource preparation fails. In production, choose the strategy that matches your fault-tolerance requirements and record the result for retries and alerts.

Failure strategyStop broadcastContinue broadcast
How do I apply and complete the first integration?

Apply for a dedicated node in the dashboard, obtain the node domain and AccessKey, replace the broadcast domain, add CF-NODE-KEY, and complete an end-to-end test with a small or testnet transaction.

Apply for a nodeConfigure the keyTest transaction

Ready to Start

Add Seamless Energy with One Dedicated Broadcast Node

Apply for a node, obtain an AccessKey, replace the broadcast domain, add CF-NODE-KEY, and validate the integration with a small or testnet transaction.

Apply for a Dedicated Node
View Integration Guide