Committee & proposals
How TRON's 27 active Super Representatives form the on-chain committee, how proposals are submitted, voted on, and applied, and how rotating SR membership affects pending proposals.
Prerequisites
The TRON committee is the on-chain governance body formed by the 27 currently active Super Representatives. It is the only body whose votes can change the network's dynamic parameters — block production rewards, resource pricing, TVM features, governance thresholds, and dozens of other values that govern how the network operates. This page explains who is in the committee, how proposals move from submission to effect, and how committee rotation interacts with pending proposals.
Committee composition
The committee is not a fixed roster. It mirrors the live SR election and is recalculated at every Maintenance Period boundary (every 6 hours by default) based on the latest vote tallies:
| Role | Vote rank | In committee | Can submit proposals | Can vote on proposals |
|---|---|---|---|---|
| Active SR | Top 27 | Yes | Yes | Yes (counted at expiry) |
| SR Partner (SRP) | 28 – 127 | No | Yes | Approvals recorded but not counted |
| SR Candidate (SRC) | 128 + | No | Yes | Approvals recorded but not counted |
Any address registered in witnessStore is eligible to submit proposals or approval transactions. Registration happens by submitting a WitnessCreateContract, which burns a one-time 9,999 TRX fee. Proposal submission itself charges no extra fee.
What the committee can change
Committee proposals can modify on-chain dynamic parameters. These cover:
- Economic parameters — block production reward, voter reward pool, brokerage limits.
- Resource parameters — Bandwidth and Energy unit prices, free daily quotas, total Energy limits.
- Protocol parameters — Maintenance Period interval, proposal expiration time, maximum transaction execution time.
- TVM parameters — activate new opcodes, enable Ethereum-compatible upgrades (Constantinople, Istanbul, London, Shanghai).
- Consensus parameters — account creation fees, multi-sign enablement, staking-mechanism options.
For the full list with current values, see Network parameters.
Proposal lifecycle
A proposal moves through a fixed sequence: submitted → voting open → tallied at expiry → applied (or marked failed) at the same boundary.
Submission
Any SR, SR Partner, or SR Candidate can submit a ProposalCreateContract carrying a map of {parameter_id: new_value}. Multiple parameters can ride in one proposal — they are voted on together as a bundle, all-or-nothing.
For a complete TronWeb walkthrough (build → sign → broadcast → track approval), see the Create a Governance Proposal recipe.
Validity window
A proposal's expirationTime is set to the first Maintenance Period boundary at least 3 days after creation, so the effective voting window is 3 days to 3 days + 6 hours depending on submission timing. The 3-day base is chain parameter #92 (PROPOSAL_EXPIRE_TIME, default 259,200,000 ms; range 0 to ~365 days), itself adjustable by proposal.
Voting rules
- Approval-only. A vote can only add an approval or withdraw a previously cast approval. There is no NO vote — anything that is not an active YES at expiry simply does not count toward the threshold.
- Who is heard. SRs, SR Partners, and SR Candidates can all submit
ProposalApproveContract; submissions are recorded on-chain. Only approvals from the 27 active SRs are counted at expiry — non-active approvals are filtered out and have no effect on the outcome. - Threshold. A proposal passes if at least 18 of the 27 active SRs have approvals on record at expiry.
Tally and apply
Approvals are tallied only at expiry, never as soon as the threshold is first reached. Crossing 18 mid-window does not trigger an early apply, and falling back below 18 before expiry causes the proposal to fail. At the expiration Maintenance Period boundary:
- If at least 18 active-SR approvals are recorded → state becomes
APPROVED, and the parameter change is written to chain state in the same boundary block, taking effect for all subsequent blocks. - Otherwise → state becomes
DISAPPROVED. No parameter changes; the final state remains permanently queryable on-chain. A new proposal must be submitted to retry.
Canceling a proposal
The proposer can cancel a pending proposal before expiry with wallet/proposaldelete. Once a proposal has passed and applied, it cannot be canceled — the only way to revert a change is to pass a new proposal that restores the old value.
Committee rotation interaction
Because committee membership is recomputed at every 6-hour Maintenance Period boundary based on live vote tallies, an SR can move into or out of the committee during a proposal's 3-day voting window:
- An SR who drops below the top 27 mid-window keeps any approvals already recorded, but those approvals are filtered out at expiry because the SR is no longer active.
- An SR who enters the top 27 mid-window can submit fresh approvals; those are counted at expiry like any other active-SR approval.
A proposal's chance of passing therefore depends not only on its merits but on which 27 accounts happen to be in the committee at the moment of expiry. In practice this matters most for proposals submitted near a vote-share boundary or during periods of active campaigning.
Related resources
- Network parameters — Full parameter reference and current values.
- Create a Governance Proposal — TronWeb walkthrough: build, sign, broadcast, and track approval.
- Vote for Super Representatives — TronWeb recipe for voters who shape the active set.
- Super Representatives — Roles, election, and operation of the 27-SR committee.
- Consensus and DPoS — How the active 27 are elected and how blocks become irreversible.
Updated 7 days ago