The origin tracer is paused. The library is open and still growing.What’s paused, and when it returns

← All articles

Technology

Chain Parameters and Governance Proposals

PUBLISHED │ READ ~10 min │ BY TRONORIGIN │ UPDATED 2026-07-09

governancechain-parametersproposalsfee-model

Key takeaways

  • TRON's economic constants — fees, resource prices, rewards — are dynamic on-chain parameters; the committee of the 27 active Super Representatives changes them by proposal, and the full set is queryable via GetChainParameters.
  • Any SR, SR Partner, or SR Candidate can create a proposal, but only the 27 active SRs vote. Eighteen approvals within the 3-day window pass it, and the change lands at the next 6-hour maintenance period.
  • Every parameter is a timestamped series: the Energy price has been reset eight times since genesis, and the 1 TRX account-activation fee did not exist before mid-2021.
  • Reconstructing a past transaction's cost means using the value in force at that block — today's Energy price applied to a December 2022 transaction understates the burn by 4.2×.

TRON hard-codes almost none of its economics. The price of a unit of Bandwidth or Energy, the fee for activating an account, the reward an SR collects per block — each lives on-chain as a “dynamic parameter,” and each can be rewritten by a vote of the network’s block producers. The companion piece on transaction cost, What a Transaction Actually Costs, describes the rates as governance parameters rather than a live auction. This is the machinery behind that phrase: who can propose a change, who votes, and when a new value takes hold.

The forensic payoff is a habit. Because every one of these values has an effective date, the current setting answers questions about the present only. Any reconstruction of a past transaction’s cost, or a past account’s activation, has to use the value that governed the chain at that block’s timestamp.

Who sets the numbers

The java-tron documentation calls the Committee “the highest governing body of the TRON network, responsible for modifying the network parameters (eg. transaction fees, block rewards).” The Developer Hub identifies its membership: the current 27 Super Representatives — the same block producers covered in DPoS and the 27. Whoever holds the production seats also holds the pen on the fee schedule.

The modifiable set is public. GetChainParameters returns “all parameters that the blockchain committee can set” as a list of keys and values: getEnergyFee at 0.0001 TRX, getTransactionFee — the Bandwidth unit price — at 0.001 TRX, getCreateNewAccountFeeInSystemContract at 1 TRX, getMaintenanceTimeInterval at 6 hours. Those are the settings as of July 2026. None of them is a constant; each is the latest value in a series the committee can extend.

The proposal lifecycle

Any SR, SR Partner, or SR Candidate can create a proposal — that end of the process is open. It goes on-chain as a ProposalCreateContract whose payload is a map of chain-parameter IDs to new values, so a single proposal can change several parameters at once.

Voting is the narrow gate. Only the 27 active SRs may vote, each casting a ProposalApproveContract carrying the proposal ID and an approval flag. The system supports approval votes only: per the java-tron docs, “not voting is equivalent to disapproving,” so an SR that stays silent has in effect voted no. The window is 3 days by default — and even that window is a governable parameter (getProposalExpireTime, #92). Until a proposal takes effect, its creator can withdraw it with a ProposalDeleteContract.

A proposal passes at 18 or more approval votes — 18 of 27, which also means 10 SRs can block any change. It then takes effect at the next maintenance period, the 6-hour cycle on which the network tallies votes.

[ PROPOSAL LIFECYCLE · CREATE → EFFECT ] OPEN CREATION · CLOSED VOTE · 18-VOTE THRESHOLD · TIMED ACTIVATION CREATE ANY SR / PARTNER / CANDIDATE ProposalCreateContract MAP OF PARAM IDs → NEW VALUES · SEVERAL PARAMS AT ONCE WITHDRAWABLE BY CREATOR UNTIL EFFECT — ProposalDeleteContract ON-CHAIN VOTE ONLY THE 27 ACTIVE SRs ProposalApproveContract · APPROVAL VOTES ONLY NOT VOTING IS EQUIVALENT TO DISAPPROVING 3-DAY WINDOW — ITSELF GOVERNABLE (PARAM #92) TALLY PASS ≥ 18 OF 27 APPROVALS 18 OF 27 — 10 SRs CAN BLOCK ANY CHANGE KEY ACTIVATE TAKES EFFECT AUTOMATIC AT THE NEXT 6-HOUR MAINTENANCE PERIOD THE CYCLE ON WHICH THE NETWORK TALLIES VOTES PROPOSAL VOTES USE ProposalApproveContract — DISTINCT FROM SR ELECTIONS (VoteWitnessContract)
From creation to effect: open proposal creation, approval-only voting by the active 27, an 18-vote threshold, activation at the next maintenance period.

This is a different vote from the one most TRON users cast. Electing SRs runs through VoteWitnessContract and is open to anyone with staked TRX — that mechanism is Voting on TRON. Voting on proposals runs through ProposalApproveContract and is closed to everyone but the active 27.

The parameters that matter for investigation

Each governable value carries a discrete proposal-parameter number, and the Developer Hub documents the list with its current settings. The ones an investigator meets most often, as of July 2026:

IDParameterDocumented value
#0Maintenance interval6 hours
#1SR application fee9,999 TRX
#2Account-creation fee (getCreateAccountFee)0.1 TRX
#3Bandwidth unit price0.001 TRX
#5SR block-production reward8 TRX
#7Account creation via system contract (getCreateNewAccountFeeInSystemContract)1 TRX
#11Energy unit price0.0001 TRX
#22Account-permission-update fee100 TRX
#31Voting reward per block, shared by vote weight128 TRX
#61Free Bandwidth per account600 units
#92Proposal expiration window3 days

Two of these get conflated constantly, and keeping them apart matters. Parameter #2, at 0.1 TRX, is the Bandwidth burn charged on an account-creation transaction when the creator lacks staked Bandwidth. Parameter #7, at 1 TRX, is the activation fee proper — the cost of standing up a new account through the system contract. They stack: together they make the roughly 1.1 TRX total the resource-lifecycle article references. An analyst who treats “the account fee” as one number will misread both halves.

The reward parameters (#5 and #31) appear here as examples of the same principle — even the block and voting rewards are committee-settable values with effective dates. How those rewards actually reach SRs and voters is covered in the voting article.

Every value has a history

The Energy unit price shows how far a “constant” can travel, and the chain publishes the record itself. GetEnergyPrices returns every price the parameter has ever held, each stamped with its effective date. Queried 3 July 2026, the series reads: 100 sun per unit at genesis, 20 from 19 November 2018, 10 from 13 December 2018, 40 from 24 November 2020, 140 from 11 February 2021, 280 from 28 October 2021, 420 from 4 December 2022, 210 from 19 September 2024, and 100 from 29 August 2025. The current 100 sun (0.0001 TRX) is a return to the genesis price — after eight governance changes and a 42-fold spread between the lowest and highest settings.

[ ENERGY UNIT PRICE · getEnergyFee · PARAM #11 ] NINE VALUES · EIGHT GOVERNANCE RESETS · GetEnergyPrices, QUERIED 3 JUL 2026 100 SUN GENESIS STARTING PRICE — 0.0001 TRX PER UNIT 20 SUN EFF. 19 NOV 2018 FIRST RESET — CUT TO A FIFTH 10 SUN EFF. 13 DEC 2018 SERIES LOW 40 SUN EFF. 24 NOV 2020 THE CLIMB BEGINS 140 SUN EFF. 11 FEB 2021 3.5× IN ONE STEP 280 SUN EFF. 28 OCT 2021 DOUBLED 420 SUN EFF. 4 DEC 2022 TIP-483 · SERIES PEAK · 42× THE LOW KEY 210 SUN EFF. 19 SEP 2024 THE CLIMB REVERSES — HALVED 100 SUN EFF. 29 AUG 2025 RETURN TO THE GENESIS PRICE TODAY'S 100 SUN APPLIED TO A DEC 2022 TX UNDERSTATES THE BURN BY 4.2× MATCH THE VALUE TO THE BLOCK'S TIMESTAMP
The Energy price as governance set it: nine values across the chain's life, ending where it began.

Bandwidth keeps the same kind of ledger. GetBandwidthPrices returns 10 sun per unit at genesis, 40 from 24 November 2020, 140 from 11 February 2021, and 1,000 sun — today’s 0.001 TRX — from 26 July 2021.

Two steps in those series trace directly to published proposals. TIP-286 raised the Bandwidth unit price from 0.00014 TRX to 0.001 TRX and, in the same stroke, raised the system-contract account-creation fee from 0 to 1 TRX. That second change is the one that bites hardest in forensics: the 1 TRX activation fee — the anchor of account-activation analysis — did not exist before roughly July 2021. An account activated in 2020 paid no such fee, because the parameter was zero. TIP-483, created 1 December 2022 and effective 4 December 2022, moved the Energy price from 280 to 420 sun — and the on-chain series shows exactly that step on exactly that date. Two records, the same step on the same day.

A chain parameter is a value with an effective date, and the date does the forensic work.

Using the value in force

Because the prices are governance-set and timestamped rather than auctioned per block, a past transaction’s burned cost is deterministically reconstructable — the property the resource-lifecycle article states as “historical cost is deterministic.” The determinism has one condition: the reconstruction must use the parameter value in force at that block’s timestamp. Applying today’s 100-sun Energy price to a December 2022 transaction, when the price was 420 sun, understates the burn by a factor of 4.2. Applying the current 1 TRX creation fee to a 2020 activation invents a fee that was zero at the time.

The same discipline extends past fees. The 8 TRX block reward and the 128 TRX voting reward are proposal-modifiable values too, so any model of SR income at a historical date needs the values of that date.

When a reconstruction hinges on a fee, a price, or a reward, pull the series — GetChainParameters for the present, GetEnergyPrices and its Bandwidth counterpart for the past, the TIP record for why a step happened — and match the value to the block’s timestamp. The chain keeps a complete ledger of its own rules; the only way to misread it is to hold today’s page against yesterday’s transaction.

Sources