Track 5: Super Representative candidate and operator

This track is a starting point for preparing to operate a Super Representative (SR) node. It is intended for teams planning to apply for SR candidacy or responsible for an SR node, keys, and operational assurance.

What you will learn

Starting from an SR's consensus and block-production responsibilities and on-chain governance responsibilities, this track covers node and signing-environment planning, a non-producing node check, permissions and key management, operational assurance, incident drills, and a launch-readiness assessment.

A non-producing Fullnode is used throughout. You can deploy it yourself or use an existing or team-managed test environment. Across the stages, you will create a node operations check, permission plan, monitoring and backup procedures, incident-drill record, and launch-readiness checklist for the same environment.

You can build these materials while working through the stages. This track does not require Mainnet candidacy registration, real block production, or an on-chain permission update, and it does not load a real Witness key. Those actions require separate organizational authorization, security review, and production change control.

You do not need to master every consensus and node parameter before starting. Use the overview to understand the focus of each stage, then inspect the current environment while following the documentation. Return to the recommended reading when a synchronization, permission, or operations issue arises.

Track overview

Before you begin

You should have experience operating Linux servers, JVM applications, networks, and storage, and understand TRON accounts, blocks, transactions, and DPoS basics. If these are new, start with Consensus and DPoS — At a glance and Nodes and clients — What are nodes and clients?.

The exercises require a running non-producing node you can safely inspect or an isolated test environment provided by your team. If deploying your own, plan against the current supported platforms and hardware requirements, allowing capacity for chain-data growth and recovery operations.

This track organizes the responsibilities, environment, and operating procedures that must be checked before an SR launch. Follow the linked documentation for concrete deployment, Witness permission, and API-hardening steps. During these exercises, do not enable --witness, put a real localwitness value in config.conf, register a Mainnet candidate, or submit an on-chain permission update.

Track stages

1. Understand SR operational responsibilities

TRON uses DPoS consensus, in which the active SRs produce blocks in a scheduled rotation. An SR must do more than keep a process online: during its assigned slot, it must construct and sign a block in time for other nodes to validate and extend the chain. Missed slots, a lagging node, or a signing failure directly affect consensus participation and operating performance.

SR operations also connect to voting, rewards and brokerage, and governance. The active set changes with votes and Maintenance Periods; rewards and brokerage affect the relationship with voters; and committee proposals can change resource prices, rewards, TVM features, and other network parameters. The operations team must follow node status, vote changes, proposals, and client upgrades together.

As a result, the operating objective cannot be only “the process is online.” It must cover synchronization freshness, signing availability, missed slots, recovery, key security, change control, and continuous staffing, with clear ownership for detection, decisions, and recovery.

Recommended reading

1. Super Representatives — Roles and Consensus and DPoS — Block production schedule

   Focus on the distinction between SRs, SR Partners, and candidates and on block scheduling. Then read Missed slots and Block solidification to understand how abnormal slots and solidification affect operations. Fork-handling examples are not required at this stage.

2. Voting — The 6-hour vote-counting cycle and Reward calculation — The two reward types

   Use these sections to understand how the active SR set, rewards, and brokerage relate to SR operations. Do not cast votes or claim rewards for this stage.

3. Committee — What the committee can change and Proposal lifecycle

   Understand how SRs participate in governance and why parameter changes belong in operations monitoring. Do not submit or approve a proposal for this stage.

Stage exercise

Create an SR responsibility table from the recommended reading. Convert block production, solidification, voting, rewards, governance, upgrades, and availability into observable operating objectives. For each objective, record its data source, check frequency, responsible role, and effect of failure.

Build an initial risk register that includes node downtime, synchronization lag, unavailable signing, an incorrect client version, configuration errors, insufficient storage, network partition, and permission misuse. Do not enable block production; the purpose is to define the operating scope and ownership boundaries.

Before planning the environment: Confirm that the SR's protocol duties have become concrete operating objectives and risks, and distinguish what a non-producing node can validate from what requires a later controlled block-production environment.

2. Plan the node and signing environments

An SR node needs stable resources for consensus execution, block validation, database I/O, and network communication. Plan CPU architecture and core count, JDK compatibility, JVM memory, SSD capacity and IOPS, network bandwidth and latency, and continuing chain-data growth together. Base specifications on the current hardware requirements and actual load testing, not a one-time static estimate.

The topology should separate the production candidate, synchronized standby, public API, monitoring, and management access. Only one controlled production node should produce blocks at a time; a standby remains synchronized and ready for a managed failover. Public query traffic must not contend with the consensus path, and management access must not be directly exposed to the public internet.

Treat the signing environment as a separate security domain. Owner, Active, and Witness permissions have different responsibilities and must not share storage and access paths merely for deployment convenience. At this stage, design key loading, custody, and access boundaries without installing a real key on the non-producing node.

Recommended reading

1. Nodes and clients — Node types and Deploy a node — Supported platforms

   Choose the node type and confirm currently supported platforms. Continue into the hardware, JAR, configuration, and startup sections as needed. Skip block-producing startup and do not enable Witness mode.

2. Mainnet database snapshots — Choosing a snapshot

   Plan initial synchronization, disk space, the database engine, and the source of recovery data. A public database snapshot is bootstrap data, not the team's own backup plan.

3. SR best practices — Availability and Security

   Plan active and standby nodes, signing-key separation, and API boundaries. Leave monitoring, community operations, and upgrades until stage 5.

Stage exercise

Create a capacity and compatibility checklist that records the operating system, CPU architecture, JDK, JVM flags, memory, disk capacity and growth margin, database engine, network entry points, and expected load. Record the basis and validation method for every choice.

Draw the node topology and mark network and trust boundaries among the production candidate, synchronized standby, API, monitoring, management, and signing environments. Add failure domains, failover direction, and single points of failure. Confirm that no public API directly exposes the signing environment or consumes the consensus node's primary resources.

Before inspecting a non-producing node: Confirm that capacity, JDK, storage, network, topology, and signing environment all have an explicit plan and that the node under inspection will neither load a real Witness key nor start in block-producing mode.

3. Prepare and inspect a non-producing node

A non-producing node can validate deployment, synchronization, and routine operational foundations; it cannot prove real block-production readiness. First confirm that FullNode.jar, the configuration file, the database snapshot, and the target network match. Preserve the software version, file verification result, and configuration source.

A live process is not necessarily a healthy node. Compare its local height with an independent source, observe continued height growth, and check peer count, network connectivity, log errors, JVM, CPU, memory, disk space, and I/O. A node stuck at one height, repeatedly losing peers, or logging consensus-execution errors should follow the slow or stopped block sync diagnostic path.

Include startup, shutdown, and restart behavior in the check. A process manager should start the node, and the clean shutdown flow should stop it without risking database corruption. After restart, confirm the database opens, the node reconnects to peers, and it catches up to the network height.

Recommended reading

1. Deploy a node — Obtain FullNode.jar, Pick a configuration file, Start the node, and Shutting down cleanly

   Confirm the client, configuration, startup, and clean-shutdown procedure. Skip block-producing steps; no startup command in this stage uses --witness.

2. Mainnet database snapshots — Using the snapshot and Node maintenance toolkit — Data copy

   Focus on download, extraction, directory, and database-engine requirements. Never overwrite a running node's directory or a directory that already contains data. Use the toolkit only when there is a real copy, migration, or recovery requirement.

3. Node operations troubleshooting — Slow or stopped block sync and Network stability and resource usage control

   Check synchronization, JVM, network, and disk issues. Read the result-code section only if consensus execution actually diverges. Private-chain debugging settings are not fixes for a public-network node.

4. Check node synchronization and data freshness

   Compare the local latest height, solidified height, and independent reference height, turning a one-time check into a repeatable acceptance record. This recipe does not validate real block production or Witness signing.

Stage exercise

Run an operations check on the non-producing node or shared test environment. Record the client and configuration versions, target network, database engine, start time, local height, independent reference height, peers, important logs, process state, and host resources. Observe long enough to cover ordinary synchronization changes and confirm that height continues to advance.

In a test environment where you are authorized to operate the node, stop it through the clean-shutdown path and restart it. Record the time to stop, start, reconnect, and catch up. If you cannot restart a shared environment, review its latest maintenance record instead of exceeding your operations authority.

Before planning permissions and keys: Confirm that the non-producing node synchronizes reliably, its important logs and resource metrics have no unresolved anomaly, and a reviewable operations record is preserved. This proves ordinary node foundations, not block-production readiness.

4. Plan permissions and keys

An SR account's Owner, Active, and Witness permissions serve different purposes. Owner controls the account and permission changes and must receive the strongest protection. Active permissions authorize explicitly allowed routine transactions. Witness permission is only for signing blocks and cannot authorize ordinary transfers or contract calls.

A production design usually delegates Witness permission to a separate block-signing key, allowing the Owner key to remain offline. The Witness key must be available online, but access should be restricted to the controlled signing environment. Design separate Active permissions for reward management, voting, proposals, or other operations instead of concentrating everything in the Owner key.

The plan must cover more than normal custody. Include key generation, handoff, loading, backup, rotation, revocation, compromise, and personnel departure. Witness rotation must coordinate the on-chain permission and node configuration so an incorrect new-key/old-key sequence does not stop block production. At this stage, produce the plan and drill steps without submitting a real permission update.

Recommended reading

1. Multi-signature and permission management — Permission types and Active permissions and contract restrictions

   Distinguish Owner, Active, and Witness permissions and their operation scopes. If designing a future permission update, also study Updating permissions: an update replaces the complete permission structure and must not be submitted as part of this exercise.

2. Witness permission separation — Why separate block production and Point the node at the delegated key

   Understand Witness permission delegation, node-side key configuration, and the switch sequence. Include Verify the witness_permission entry in the plan, but do not load a real key or update Mainnet permissions at this stage.

3. SR best practices — Security

   Establish cold Owner-key storage, online Witness signing, and least privilege. Leave the other operational-assurance topics until stage 5.

Stage exercise

Build a permission matrix listing each Owner, Active, and Witness operation, key location, authorized personnel, approval method, and audit record. For every secret, state whether it may be online or exportable and how it is backed up and recovered.

Write procedures for Witness key rotation and compromise. Define the sequence for stopping block production, generating a new key, updating permissions, changing node configuration, verifying the new permission, and restoring service. Run a tabletop exercise with fictional addresses or isolated test data; do not submit a real on-chain permission change.

Before establishing operational assurance: Confirm that the matrix separates fund control, routine operations, and block signing and that the rotation and compromise procedures include approval, rollback, and verification.

5. Establish operational assurance

SR assurance covers the node, consensus, host, and external dependencies together. Node-height difference, peers, process state, logs, CPU, JVM, memory, disk, and I/O are basic metrics. A real block-producing environment must also monitor scheduled slots, produced and missed blocks, signing errors, vote changes, and governance proposals.

Every alert needs an action, not just a notification. Define a threshold, duration, severity, owner, diagnostic entry point, and escalation path for each one. The on-call procedure must state who can fail over the node, who can access the Witness signing environment, and when an issue escalates to security or governance owners.

Backups and recovery should cover configuration, versions, monitoring rules, runbooks, and necessary database recovery material without putting plaintext keys in an ordinary backup. Validate an upgrade on a standby or non-producing node before a controlled rollout. Restrict the API access surface by network, exposed methods, and traffic so external requests cannot consume consensus resources.

Recommended reading

1. SR best practices — Availability, Monitoring, and Upgrades

   Establish active/standby, monitoring, upgrade, and continuing-operations objectives. Validate the collection method, metric names, and thresholds against the node version, deployment architecture, and team response process.

2. SR API configuration — Network reach, Endpoint selection, and API request and response limits

   Narrow HTTP, gRPC, and JSON-RPC access, methods, and traffic separately. Set thresholds from actual load rather than copying an example QPS value.

3. Deploy a node — Shutting down cleanly and Updating the client

   Plan shutdown and version upgrades. If database copying, migration, or recovery is required, continue to Node maintenance toolkit — When to use each utility. Neither public snapshots nor the toolkit replace the team's own backup and recovery procedure.

Stage exercise

Create a monitoring and alert table that covers at least the process, synchronization-height difference, peers, log errors, JVM, CPU, memory, disk, and I/O. For metrics available only after real block production, define the data source, threshold, and acceptance method without inventing a passing result in the non-producing environment.

Write backup and recovery, version upgrade, API isolation, and routine on-call procedures. For each, record the operator, approver, inputs, sequence, validation, rollback condition, and expected completion time, and schedule periodic review.

Before incident drills: Confirm that every important risk has a monitoring or manual-check entry point, alerts have owners, backup and upgrade procedures include validation and rollback, and the API and signing environments remain isolated.

6. Complete incident drills and the launch check

An incident drill tests whether monitoring and runbooks work; it does not merely prove that the documents exist. Run drills on a non-producing node or isolated environment, using recoverable methods that cannot corrupt the database or affect real consensus.

The minimum set covers process exit, node lag, and a configuration error. For each scenario, record fault injection, detection, alert time, diagnosis, response, recovery condition, and actual recovery time. Treat any reliance on undocumented personal knowledge or permissions as a readiness gap.

The launch check brings evidence from the first five stages into one table. Node operations, capacity, permissions, keys, monitoring, backup, upgrades, API controls, on-call coverage, and drills must each have an owner and result. Explicitly mark real block-production metrics that cannot be validated on a non-producing node as later controlled acceptance items instead of marking them as passed.

Recommended reading

1. Node operations troubleshooting — Slow or stopped block sync and Network stability and resource usage control

   Design diagnostic paths for node lag, insufficient resources, and network problems. Private-chain debugging parameters are not fixes for public-network nodes.

2. SR best practices — Availability and Upgrades

   Check that failover, monitoring, and upgrades appear in the launch review. Passing a high-level review does not validate a production failover or real block production.

3. Deploy a node — Shutting down cleanly, Start the node, and Updating the client

   Confirm safe shutdown, startup, version, and configuration operations. Do not enable Witness mode or load a real signing key in this stage.

Stage exercise

In an authorized non-producing environment, run three drills: simulate process exit through normal process management; simulate node lag through controlled network or synchronization conditions; and simulate startup failure with a reversible test configuration. Restore the original state after each drill and confirm the node database, synchronization, and monitoring return to normal.

Update the alerts and runbooks based on the results, then assemble the SR launch-readiness checklist. Include node-operations evidence, permission and key plans, monitoring rules, backup and upgrade procedures, API isolation, on-call arrangements, drill records, unresolved risks, and later real block-production acceptance items.

Validate launch readiness: Every in-scope check has evidence and an owner, and every issue exposed by a drill is either fixed or explicitly blocks launch. State the result as “ready,” “conditionally ready,” or “not ready.” Never represent a non-producing node check as completed Mainnet registration or real block-production acceptance.

Next steps and extensions

After this track, you should have a node-operations record, permission and key plan, monitoring rules, backup and upgrade procedures, incident-drill record, and SR launch-readiness checklist. These materials support a decision to enter the next security-review and controlled block-production phase; they do not mean Mainnet candidacy registration is complete.

Before applying, separately read Becoming a Super Representative — Apply for SR candidacy. Confirm the current on-chain fee, account information, and registration process, and obtain explicit financial, security, and organizational authorization. Treat registration, permission updates, and real Witness enablement as separate production changes.

The controlled block-production phase must separately validate scheduled slots, block signing, missed-slot alerts, Witness-permission rotation, and active/standby failover. These checks affect real consensus and key environments, so the team should execute and retain evidence under a dedicated change plan rather than treat them as ordinary exercises in this track.

Repeat the readiness review periodically. When the client version, chain-data size, network parameters, team, or operating environment changes, reassess the affected capacity, permissions, monitoring, recovery, and drill results.

If you are still blocked at any stage, share track feedback and include “Track 5,” the current stage, node version, target network, completed steps, and redacted error information. Do not submit private keys, keystores, passwords, internal addresses, or production topology.