Super Representative best practices

📘

Prerequisites

• Super Representatives
• Committee & proposals

A Super Representative (SR) missing its block production slot costs real TRX — both in missed block rewards and in lost voter confidence that translates to fewer votes next cycle. These practices come from operational lessons across the TRON SR community. Most are principles you can apply with whatever tooling you already have; two of them — separating block-production keys and tuning the API surface — have enough configuration depth to warrant dedicated walkthroughs, linked from their sections below.

Availability

• Run redundant nodes. Operate at least two block-producing candidates in distinct data centers or clouds. Only one produces at a time; the other stays on standby with synchronized state and can be switched over in minutes.
• Monitor block production directly. Alert on missed slots, not just node uptime. A node can be "up" but lagging behind the network — alert on block height drift.
• Keep a runbook. Apply the switchover procedure and test it quarterly. Do not wait until a production incident to discover your standby has drifted.

Security

• Separate block-production keys from owner keys. Delegate witness_permission to a dedicated hot signing key so the owner key can stay offline — see Witness permission separation below.
• Tune the API surface for the SR's role. Reduce the API surface and rate-limit incoming traffic so API serving doesn't compete with consensus — see API configuration below.
• Protect keystore files. If you use localwitnesskeystore, encrypt the file at rest and never commit it to source control. Prefer hardware-backed key storage where available.

Witness permission separation

By default, an SR account's witness_permission, active_permission, and owner_permission all authorize the same key — the SR's own address. A single private key therefore signs both blocks (validated against witness_permission) and balance-moving transactions (validated against owner / active). Leaking that key compromises block production and reward funds at once.

Delegating witness_permission to a separate hot-signing key reduces this exposure:

• The owner key stays offline. It is only needed when changing permissions, transferring rewards, or creating proposals — operations that can be batched and signed on a cold machine.
• The hot signing key has limited blast radius. A leaked hot key can disrupt block production but cannot move TRX, vote, or update permissions. Recovery is reverting the permission update.
• Production SRs typically use this pattern.

For the on-chain AccountPermissionUpdateContract flow, the matching localwitness configuration on the node, and verification steps, see SR node configuration.

API configuration

TRON full nodes expose HTTP and gRPC APIs by default — useful for monitoring, integration, and read-heavy clients. For an SR, those APIs are not required for block production; every byte of CPU spent serving them is CPU not spent on consensus. TRON gives three configuration levers to tune the API surface:

• Network reach — bind API ports to localhost or place the node inside a private network. If external access is required, enforce it at a firewall or reverse proxy with an IP allowlist.
• Endpoint selection — disable methods the SR doesn't need to serve (commonly listnodes, getnodeinfo) via disabledApi in config.conf.
• Traffic caps — rate-limit gRPC per-method and JSON-RPC globally with rate.limiter so legitimate but noisy clients don't compete with the consensus thread.

None of these are required to run an SR — they are tuning options for operators who want to give the consensus path more headroom. For configuration syntax, capability differences between gRPC and JSON-RPC, and QPS rules of thumb, see SR API configuration.

Monitoring

• Track block production, vote share, and voter count separately. A miss in block production signals an operational problem; a vote share drop signals a reputation problem; a voter count drop signals a communication gap. Each needs a different response.
• Set up Prometheus scraping. The java-tron JMX MBeans expose the full metric catalog; scrape them into Prometheus and alert on production miss rate > 1% per Maintenance Period.
• Watch the committee proposal feed. Parameter changes can affect your reward rate overnight.

Community

• Publish and maintain your TronScan SR profile. See Becoming a Super Representative.
• Communicate changes. Brokerage ratio changes, incidents, and node upgrades all affect voter decisions. Telegram and Twitter/X updates are standard practice.

Upgrades

• Upgrade on time. When Mainnet releases a new version, complete the update before the specified deadline to avoid block-sync interruptions from protocol incompatibilities or hard forks.
• Drain before upgrading. Switch block production to the standby node before upgrading the primary. Never upgrade the active producer in place.
• No version rollback after a mandatory upgrade. Once a mandatory upgrade completes and the hard-forking proposal passes, do not downgrade or roll back — running old java-tron will fail to recognize and process transactions that use new features.

Related resources

• SR node configuration — Witness permission delegation, full walkthrough.
• SR API configuration — Network reach, endpoint selection, and traffic caps in detail.
• Becoming a Super Representative — Application, brokerage, and the registration flow.
• Committee & proposals — How committee proposals can affect your reward rates.
• Consensus and DPoS — How block production, solidification, and rewards work.