← All articles

Technology

DPoS and the 27: How TRON's Super Representatives Work

PUBLISHED │ READ~12 min │ BYTRONORIGIN

dpos consensus super-representatives governance

TRON’s history article covers Delegated Proof of Stake in a paragraph — the right level for an architectural overview. This article goes deeper: how DPoS actually works, who holds the 27 active block-producer seats, how the election machinery runs, and why it matters when reading on-chain data.

TRON’s security model concentrates block production in a small, elected group. That concentration is visible on-chain. Knowing who is in that group, how they got there, and what their addresses look like in the transaction graph helps analysts distinguish infrastructure activity from meaningful user behavior.

Delegated Proof of Stake, in plain language

Three consensus families dominate public blockchains, each making different trade-offs between throughput, decentralization, and governance.

Proof of Work (Bitcoin) requires computational expenditure to compete for each block. Security comes from the cost of attack, but throughput is low — a PoW chain typically confirms a block every 10 minutes, and finality takes multiple confirmations.

Proof of Stake (Ethereum post-Merge) requires validators to post staked collateral that can be destroyed (slashed) for dishonest behavior. Any participant with sufficient stake can validate. The validator set can be large and geographically distributed, which improves decentralization but introduces coordination overhead.

Delegated Proof of Stake takes a different path. Token holders do not produce blocks themselves. Instead, they elect a small committee of delegates who produce blocks on behalf of the entire network. The vote weight of each holder is proportional to their staked tokens. The committee is elected and rotates, and members who misbehave can be voted out.

DPoS was formalized by Dan Larimer (also used in BitShares and EOS) and is the consensus mechanism behind TRON. The core trade-offs:

  • Throughput and finality: A small, known committee can coordinate fast. TRON produces a block every three seconds — something impossible for PoW systems.
  • Decentralization: A 27-member committee is far more concentrated than Ethereum’s validator set of hundreds of thousands. Proponents call this an acceptable trade-off given the committee is elected; critics note that in practice the same entities tend to hold seats indefinitely due to self-reinforcing vote accumulation.
  • Governance: Because block producers are known addresses with declared identities, protocol changes can be voted on explicitly by the set — not just signaled through miner behavior.

For TRON specifically, DPoS means block production is not permissionless. You cannot become a block producer by running a node. You have to win an election.

The 27 active Super Representatives

At any given time, exactly 27 addresses hold the title of Super Representative (SR) and are responsible for producing all blocks on the TRON mainnet. This number is fixed in the protocol.

The mechanics work as follows. TRON runs a block every three seconds. Each three-second window is called a slot. The 27 active SRs are assigned slots in a rotating schedule. If the SR assigned to a given slot fails to produce a block — whether due to node downtime, network issues, or intentional skipping — that slot is simply missed. The next SR takes the next slot. The chain continues.

With 28,800 slots in a 24-hour day (86,400 seconds ÷ 3), each active SR is expected to produce approximately 1,067 blocks per day if slots are distributed evenly. In practice, exact counts vary slightly with missed blocks and schedule rounding.

Block production carries two types of reward. First, a block production reward: currently 16 TRX per block, paid to the SR address that produces the block. Second, a voting reward: currently 160 TRX per block, pooled across all SRs and SR Partners proportionally to their vote share. Daily totals work out to approximately 460,800 TRX in block rewards (split across the 27 active SRs) and approximately 4,608,000 TRX in voting rewards (split across all 127 eligible candidates — the 27 SRs plus the 100 SR Partners — weighted by vote count).

Each SR sets a brokerage rate (also called a commission rate) that determines how rewards are split between the SR address and its voters. The default rate when an SR is first elected is 20%, meaning the SR keeps 20% and distributes 80% pro rata to the addresses that voted for it. SRs can change this rate; in practice, SRs that compete for voter support tend to run lower rates, while SRs backed by entities that vote for themselves (large exchanges, for example) often run the default 20% or higher.

The reward distribution from an SR to its voters is a batch on-chain operation that appears as mass outbound transfers from the SR address. These transfers can look like unusual transaction patterns to an automated system unfamiliar with TRON’s reward mechanics. Understanding that an address with dozens or hundreds of small outbound TRX transfers every epoch is likely a Super Representative distributing block rewards — not a suspicious fund dispersion — is practically useful.

SR Partners — the next 100

Super Representatives are not a binary status. TRON maintains a ranked list of SR candidates, and the full eligible set includes positions 1 through 127:

  • Positions 1–27: Active Super Representatives. Produce blocks, earn both block rewards and voting rewards.
  • Positions 28–127: SR Partners. Do not produce blocks. Earn voting rewards only, at their brokerage rate, distributed pro rata to their voters.
  • Positions 128+: SR Candidates. Registered but not earning rewards. Eligible to receive votes but currently outside the top 127.

SR Partners are the bench: as vote weight shifts, Partners get promoted to active SR status and active SRs can be displaced. The boundary between rank 27 and rank 28 can move every election. SR Partner addresses also participate in the reward distribution chain — if you encounter an address running mass outbound TRX distributions every six hours, it may be a Partner, not just an active SR.

Becoming an SR candidate requires a registration fee of 9,999 TRX, paid on-chain as a WitnessCreateContract transaction. Encountering this transaction type in a wallet’s history is a meaningful identity marker: the address registered as TRON infrastructure, or at least paid to appear as one.

Voting via TRON Power

SR elections run on a continuous cycle. Every six hours, TRON runs what the protocol calls a maintenance period, during which the vote tallies are calculated, the SR rankings are updated, and the new active set takes over block production. The six-hour window is sometimes called an “epoch” in informal documentation.

Votes are denominated in TRON Power (TP). TP is acquired by staking TRX under Stake 2.0: one TRX staked for votes yields one TP, which in turn grants one vote. TP is non-transferable and non-tradeable — it lives on the staking address. When TRX is unstaked, the TP and the votes it backs are simultaneously removed.

There is no lock-in for the voting act itself. A voter can reallocate their votes at any time between maintenance periods, and the new allocation takes effect at the next election. The staked TRX itself faces the 14-day unstaking waiting period introduced by Stake 2.0 (TIP-467, activated 2023), but the voting direction can be changed freely. This means an SR’s vote count can shift substantially within a single six-hour window if a large holder moves votes.

A voter can split their TP across multiple SR candidates. Large holders — exchanges, staking services — commonly spread votes across several SR slots to maintain multiple seats simultaneously or to support SR Partners near the threshold boundary.

The voting reward flow — from the SR/Partner address to voter addresses — runs automatically each maintenance period. These distributions create the mass-outbound transfer patterns visible on SR addresses every six hours.

Who actually holds the seats

The composition of the active SR set is dominated by three categories of entity:

Major cryptocurrency exchanges. Exchanges hold large quantities of user-deposited TRX in custody. By running an SR node and voting their custodied TRX for themselves, exchanges earn block rewards and voting rewards on assets they hold on behalf of customers. This is economically rational — the rewards partially offset custodial costs — and it is explicitly permitted by the protocol. In practice, Binance Staking has historically been among the top vote-getters, with estimates of having commanded over 59% of total votes at certain points; OKX, HTX (formerly Huobi), and Poloniex have also held active SR positions. The exact rankings shift with market conditions and exchange TRX custody volumes.

Dedicated staking services. Entities like P2P.org (which was elected as an SR in April 2025) exist specifically to provide professional node operation and staking infrastructure. These operators typically offer users a revenue share in exchange for delegating votes and sometimes earn lower brokerage rates to attract vote delegation.

Entities affiliated with the TRON Foundation or Justin Sun. TRON’s early SR set included addresses closely associated with the Foundation. The degree of Foundation-affiliated control has decreased as the network grew, but investors and analysts with reason to examine network control should review the current SR list and associated address annotations rather than relying on any static description.

Because large TRX holders can self-vote, and because exchanges hold the largest TRX concentrations, the SR set has tended toward institutional incumbency. Community nodes appear in the SR Partner tier, but holding an active seat (positions 1–27) requires vote weight that community operators rarely sustain against institutional competition. This concentration dynamic appears in every DPoS system; it is a known structural feature, not an anomaly specific to TRON. For the live SR roster with current vote counts, the authoritative source is TronScan’s SR page.

On-chain governance

The process for changing the TRON protocol runs through two parallel tracks.

TIPs (TRON Improvement Proposals) are the community-facing specification layer. Anyone can author a TIP, starting with a GitHub issue in the tronprotocol/tips repository followed by a formal pull request. TIPs move through Draft, Last Call (at least two weeks of public review), and Accepted statuses. Accepted TIPs requiring a protocol change then move to an on-chain network proposal.

Network proposals are the on-chain activation layer. Only SRs, SR Partners, and SR Candidates can submit a proposal. If at least 18 of the 27 active SRs vote in support, the proposal passes and takes effect automatically. This 18-of-27 threshold — two-thirds plus one — means 10 SRs can block any change. That is the governance corollary of vote concentration: entities dominating the SR set by vote weight also hold veto power.

Three TIPs illustrate the process:

  • TIP-467 (Stake 2.0): Separated resource delegation from vote delegation and introduced the 14-day unstaking window. Now the live staking model on mainnet.
  • TIP-541: Added the ability to cancel an in-progress unstake within the 14-day window, requiring a new API endpoint.
  • TIP-542: Made the resource-delegation lock period customizable at delegation time, replacing Stake 1.0’s fixed three-day lock.

Governance activity is visible on-chain. Proposal creation and SR vote transactions cluster on SR addresses around protocol upgrades — normal artifacts of SR status, not evidence of unusual coordination.

Why this matters on-chain

The SR system generates predictable on-chain activity patterns that any analyst working in TRON transaction data will encounter. Understanding them prevents false positives.

WitnessCreateContract transactions. This contract type registers an SR candidate. If a wallet in your investigation contains a WitnessCreateContract transaction, the address self-registered as an SR candidate. This is a meaningful identity signal: either the address belongs to an entity running TRON infrastructure, or someone paid 9,999 TRX to appear as one. Cross-reference with TronScan’s SR history to determine whether the address was ever elected.

Periodic mass-outbound TRX transfers. SR and SR Partner addresses distribute voting rewards to their delegators every maintenance period (every six hours). This produces a rhythmic pattern: dozens to hundreds of small TRX outbound transfers, clustered in time, with amounts proportional to each recipient’s vote share. An automated system that flags “mass outbound transfers” as suspicious may fire on legitimate SR reward distributions. The distinguishing characteristics are the six-hour periodicity, the proportional amounts, and the fact that the sending address is a registered SR or Partner.

Resource delegation from SR addresses. SRs often delegate Energy or Bandwidth to their own operational addresses or to partner wallets. Finding an SR address at the origin of a delegation chain does not imply the SR controls the recipient — it likely reflects a service relationship (subsidizing energy for a staking product’s users, for example).

SR vote and block producer patterns. VoteWitnessContract transactions come from addresses casting votes; high volumes of these from a single address indicate an exchange, staking service, or large holder managing vote allocations — not protocol manipulation. The block-producing SR address is recorded in every block header and visible in block explorers. If you need to identify which SR was active during a particular window, the block producer address provides the answer directly.

The cross-reference point: TRONORIGIN’s how-it-works methodology describes how SR-affiliated addresses are handled in Phase 2 funding-history analysis. SR addresses are noted as infrastructure — not scored as meaningful funding candidates — because their outbound transfers are protocol reward distributions, not deliberate funding relationships.

Sources

Primary documentation and data sources used for facts in this article: