Governance

Explore the mechanics of TRON On-Chain Governance and the protocol’s evolution through Super Representative voting. This technical guide explains how network parameters are modified, the lifecycle of TRON Improvement Proposals (TIPs), and the decentralized recovery mechanisms that ensure network liveness.

How Governance Works

SR submits proposal → 27 active SRs vote →
threshold reached → change activates at next available maintenance period

TRON governance is SR-exclusive at the proposal and vote level. Regular TRX holders participate indirectly by choosing which SRs hold voting power. This is the intended design of DPoS: stake holders elect representatives, representatives govern.

Proposal Lifecycle

Stage	Duration	Details
Active	3 days	SRs can cast approval votes
Approved	Immediate	If ≥19 of 27 SRs approve within 3 days
Expired	After 3 days	If threshold not reached, proposal fails silently
Executed	Next maintenance period	6-second governance event at end of Epoch

What Can Be Changed

Governance proposals can modify any protocol-level parameter. Examples of parameters that have been changed through governance:

Parameter	Description
Energy cost per byte	Adjusts the base cost of smart contract execution
Bandwidth cost per byte	Adjusts the cost of simple transfers
Block reward	TRX minted per block for SRs
Vote reward	TRX distributed to voters per block
SR candidate deposit	Required TRX deposit to register as an SR candidate
Maximum CPU time per transaction	Execution time limit per transaction
Adaptive Energy upper bound	Cap on the total Energy available network-wide

Viewing Active Proposals

All current and historical proposals are visible on TRONSCAN:

Navigate to tronscan.org
Select Blockchain → Governance from the top menu
The Governance page lists active, approved, and expired proposals with vote counts and the specific parameter change proposed

TRX Holder Participation

As a TRX holder, you participate in governance by choosing which SRs to vote for. SRs with a published governance stance — how they intend to vote on protocol changes — allow you to align your votes with your preferences.

TRON Improvement Proposals (TIPs)

Before a formal on-chain proposal, changes are typically discussed through TRON Improvement Proposals (TIPs) — public documents submitted to the TRON GitHub repository (github.com/tronprotocol/tips).

Anyone can submit a TIP or comment on one. The TIP process provides:

Technical discussion before committing to an on-chain proposal
Community feedback from developers and users
A public record of the rationale behind each change

Reviewing active TIPs is the best way to stay ahead of upcoming protocol changes that may affect staking yields, transaction costs, or smart contract behavior.

Nakamoto Coefficient

The Nakamoto Coefficient (NC) is the minimum number of independent entities that would need to collude to compromise a blockchain network — halt it, reverse transactions, or force through a malicious protocol change. A higher number means the network is harder to capture.

TRON’s Nakamoto Coefficient is 14. Here is how that number is derived and what it actually means.

How the Number Is Derived

TRON uses Delegated Proof-of-Stake with 27 active Super Representatives producing blocks in rotation. To control the actual content of the blockchain — deciding which transactions are included and in what order — a colluding group needs to control a simple majority of SR slots:

Total SRs	Majority threshold	Minimum colluding SRs
27	>50% (>13.5)	14 (= 51.85% of SRs)

14 is the smallest integer greater than 27 ÷ 2. With 14 SRs under coordinated control, a coalition can:

Determine which transactions are included in blocks
Censor specific addresses or contracts
Control network liveness (block production and therefore chain progress)

Note: 14 SRs alone cannot unilaterally pass governance proposals — that requires 19 of 27 approvals. But 14 controls the ledger itself.

Understanding the “9” Threshold

There is a second, separate threshold that is often confused with the Nakamoto Coefficient: the finality disruption threshold.

TRON’s consensus is BFT-augmented DPoS. A produced block is not final until it is solidified — acknowledged by at least 19 of 27 SRs via PBFT-style attestations. The 19-SR requirement follows directly from the “two-thirds majority” rule: ⌈2/3 × 27⌉ = 19.

If 9 or more SRs refuse to broadcast attestations, only 18 honest signatures can accumulate. Since 18 falls one short of the required 19, no block becomes irreversible:

Threshold	SRs required	What it means
Block solidification	19 of 27	Minimum attestations for a block to become irreversible
Finality disruption	9 of 27	Fewest non-participating SRs that prevent solidification
Block production control	14 of 27	Majority of block slots — the Nakamoto Coefficient

These are two completely separate threat vectors:

9 SRs going offline disrupts finality. Blocks are still produced on schedule — the chain keeps moving — but no block becomes irreversible. Transactions enter the chain but remain un-finalized until the faulty SRs are replaced.
14 SRs colluding compromises content. The attacker controls which transactions are valid, can censor addresses, and can create forks. This is the DPoS equivalent of a 51% attack.

Halting finality is a less costly attack to mount than controlling block content. The NC of 14 specifically measures the more impactful threat.

The DPoS Resilience Advantage

A common misconception is that TRON fails the same way as “pure” PBFT systems such as Tendermint (Cosmos).

Pure PBFT: If >1/3 of nodes (9) fail, the chain stops completely. No new blocks are produced. Recovery requires a coordinated view-change protocol or a hard fork.
TRON DPoS: If 9 SRs fail, the chain keeps moving. It falls back to “Longest Chain” consensus (similar to Bitcoin) until the 19-SR finality threshold is restored.

The recovery mechanism: TRON’s 6-hour Epoch acts as a decentralized circuit breaker. If 9 SRs are blocking finality, TRX holders can vote them out. A new SR set is then elected during the next maintenance period (the 6-second event at the end of each Epoch). Once a 19th responsive SR is elected, block solidification resumes automatically — starting from the oldest unconfirmed block and catching up to the tip of the chain — without any protocol change or hard fork.

Voter Concentration

The SR set is elected by TRX holders staking for TRON Power. A secondary dimension of decentralization is how concentrated voting power is: if a small number of large TRX holders collectively control enough votes to elect 14 or more SRs, they can influence the SR set itself. This is distinct from the SR Nakamoto Coefficient but related to the overall security model.

On-chain vote distributions are publicly visible on TRONSCAN’s SR voting page.

Comparison in Context

Metric	TRON	Bitcoin	Ethereum
Nakamoto Coefficient	14	~4 (Mining Pools)	~3–5 (LSTs)
Consensus Type	DPoS (High Liveness)	PoW (Probabilistic)	PoS (BFT-Safety)
Failure Mode	Finality lag at 9; Control at 14	Control at 51% Hashrate	Halt at 1/3 Stake

TRON’s raw NC of 14 is higher than most leading PoW or PoS networks. The important caveat: DPoS validators are a known, named set — coordination among a small group is logistically simpler than among anonymous miners. This is a structural trade-off of DPoS: high throughput and a measurable NC, at the cost of a smaller, identifiable validator set.

Summary

A Nakamoto Coefficient of 14 means that no single entity controls the network. 14 independent SR operators would have to coordinate — without detection or defection — to compromise TRON. While 9 entities can slow the time-to-finality, the integrity and liveness of the blockchain remain secure until 14 entities are fully captured.

Follow TIPs

Active proposals and technical discussions are public on github.com/tronprotocol/tips. Subscribe to stay informed about upcoming changes.

Choose SRs carefully

Research each SR’s governance voting history on TRONSCAN before allocating your TP. SRs that vote against community interests can be replaced by shifting votes.