Voting for Super Representatives

📘

Prerequisites

• Stake 2.0 overview
• Reward calculation

TRON's network is governed by 27 elected Super Representatives (SRs) who produce blocks and vote on proposals. Token holders elect them by voting with TRON Power (TP) — the voting weight you receive when you stake TRX. This page covers how voting works, what TP is, and how the network counts votes.

Voting rights and TRON Power

Before you can vote for an SR, your account must hold TRON Power. TP is obtained by staking TRX. Mainnet currently has getAllowNewResourceModel=0, so:

• Stake 1 TRX → receive 1 TP, together with Bandwidth or Energy. If the new resource model is enabled, new TP must instead be staked separately with the TRON_POWER resource type. See Stake 2.0 overview.

TP is not delegatable — voting rights stay with the account that staked. This differs from Bandwidth and Energy, which can be delegated to other accounts (see Delegating resources).

When you unstake TRX, the same amount of TP is reclaimed. If you have voted, the votes are revoked proportionally — see Unstaking — TRON Power reclamation.

How to vote

Use wallet/votewitnessaccount to cast votes. You can split your TP across multiple SRs in a single transaction:

BASE_URL=https://nile.trongrid.io   # Nile testnet; the example account exists on this network
curl -X POST ${BASE_URL}/wallet/votewitnessaccount \
  -d '{
    "owner_address": "TTGhREx2pDSxFX555NWz1YwGpiBVPvQA7e",
    "votes": [
      {"vote_address": "<SR1_address>", "vote_count": 600},
      {"vote_address": "<SR2_address>", "vote_count": 400}
    ],
    "visible": true
  }'

This transaction casts 600 votes for SR 1 and 400 votes for SR 2. The total vote_count across all entries cannot exceed your account's TP.

Vote overwrite behavior

🚧

The latest vote replaces all earlier votes

Each vote transaction completely replaces your previous votes. If you have voted (600, 400) for two SRs, then submit a new vote of (1,000) for a third SR, your earlier votes are erased — the third SR receives 1,000 votes and the first two receive 0 from your account.

To preserve some of your earlier votes, include them in the new transaction.

This means your "current vote" is always the contents of your most recent vote transaction, not the cumulative sum of all your past vote transactions.

SR vs SR Partner

The voting system produces two tiers based on vote ranking:

The top 27 vote-getters become SRs and produce blocks; the next 100 become SR Partners. Both tiers earn voting rewards proportional to the votes they received, but only SRs earn block production rewards.

Your votes count for either tier — voting for a candidate ranked 50th still earns you rewards if they remain ranked 28–127. See Reward calculation for the details.

The 6-hour vote-counting cycle

Votes are not applied continuously to the SR ranking. Mainnet currently uses a 6-hour Maintenance Period (chain parameter #0). The first block whose timestamp reaches or exceeds the next scheduled maintenance time triggers vote tallying and updates the SR/SR Partner rankings. Until that update, new votes have no effect on rankings.

Practically:

• If you vote 1 hour before the next scheduled maintenance time, your votes affect the rankings at the next update.
• If you vote multiple times within the same 6-hour Maintenance Period, only the latest vote is counted at the next scheduled maintenance update (the vote-overwrite rule above means earlier votes were already erased anyway).
• Vote rewards are distributed continuously block-by-block based on the current rankings, so the longer you remain in the ranking, the more rewards you and your SR earn.

You can query the next scheduled maintenance time via wallet/getnextmaintenancetime. The maintenance update is triggered by the first block whose timestamp reaches or exceeds that value.

Vote snapshots and reward timing

A subtle but important behavior: submitting a vote transaction does not immediately update the active-SR ranking; the network recalculates the ranking at the next scheduled maintenance update.

The first vote transaction (or first reward withdrawal) after a new cycle begins fixes the previous cycle's ending vote distribution as this cycle's reward snapshot; any further vote changes within the cycle no longer alter that snapshot. Reward computations use this snapshot throughout the current Maintenance Period, until it is replaced after the next scheduled maintenance update.

Practical consequences:

• If you cancel votes for SR X mid-cycle, you still earn your share of SR X's voting reward for the rest of the current cycle (the snapshot has SR X). You stop earning from the next cycle onward.
• If you add new votes for SR Y mid-cycle, you do not earn any share of SR Y's reward for the current cycle (the snapshot has no SR Y). Earnings start the next cycle.
• If you change votes multiple times within the same cycle, this cycle's reward snapshot was already fixed at the start of the cycle (to the previous cycle's ending distribution), so none of this cycle's changes affect this cycle's rewards. Because votes are full-overwrite, only the last vote in the cycle takes effect as the next cycle's distribution.

This means: "I voted for SR Y a few hours ago, why are my rewards still going to SR X?" is expected behavior, not a bug. Wait until the next scheduled maintenance update.

Effect of unstaking

When you unstake TRX, the same amount of TP is reclaimed. The reclamation order is:

1. Idle (unused) TP is reclaimed first.
2. If idle TP is insufficient, voted TP is reclaimed proportionally from each SR you voted for.

For the formula and a worked example, see Unstaking — TRON Power reclamation.

This is a key difference from legacy Stake 1.0, where unstaking any amount revokes all votes at once. Stake 2.0 is more graceful — partial unstakes only reduce votes proportionally.

Querying votes and SRs

Related resources

• Stake 2.0 overview — stake TRX to obtain TP before voting
• Reward calculation — how voting rewards are calculated
• Unstaking & cancellation — how unstaking affects your votes
• Consensus & DPoS — how SRs are elected and reach consensus
• Staking & reward APIs — full API reference table