TRON proposals are on-chain requests to change network parameters. A successful creation transaction does not mean the requested change has taken effect. Read the governance result separately, then check the corresponding current parameter. A historical approval can also be superseded by a later change.
This read-only beginner guide follows one real Mainnet record across three surfaces: the creation transaction, proposal 104 and the current Energy-price field. Success means identifying which record supports each statement, with its date, units and limits. No wallet connection, submission, approval or vote is required.
Table of Contents
1. Start with the right proposal record
The official committee and proposal lifecycle describes submission, an approval window and settlement during maintenance processing at expiry. An approval tally seen during the window is not an early execution signal. Eligible committee membership matters when the result is determined.
The tested public route was TRONSCAN → Governance → Parameters & Proposals. The Network Parameters view linked its Energy-price row to proposal 104. We opened that historical record and followed its Hash link to the creation transaction. These pages were readable without selecting Connect Wallet.
- Check that the explorer’s network indicator says Mainnet.
- Open Network Parameters and find the parameter by its description and ID.
- Follow Updated by Proposal to the specific detail.
- Record the state and dates, then follow the creation hash separately.
- Return to the current parameter and preserve the observation time.
Our TRONSCAN beginner guide explains the explorer’s broader record types. This article addresses a narrower decision: whether a governance record supports a claim about an active setting.
2. Match the proposal to the actual parameter
On 31 October 2026, proposal 104’s public detail displayed EXECUTED. Its content described the Energy unit price as 0.0001 TRX, with a previous value of 0.00021 TRX. Its creation date was 26 August 2025 and its expiration date 29 August 2025. This is a historical example, not a 31 October fee-change announcement.
We also sent one public, read-only POST to the Mainnet provider route https://api.trongrid.io/wallet/getproposalbyid, with JSON {"id":104,"visible":true}. The GetProposalById reference documents the query; its sample host is Shasta testnet, so retain the intended network when choosing a host. A normal HTTP status alone is insufficient if the body contains Error.
| Question | Checked observation | Interpretation |
|---|---|---|
| Which proposal? | proposal_id 104 | One governance record, not parameter 104 |
| Which setting? | parameters key 11, value 100 | Energy unit price, raw SUN units |
| Which result vocabulary? | Provider APPROVED; explorer EXECUTED | Preserve the source’s exact label |
| Creation time? | 1756202439000 ms = 2025-08-26 10:00:39 UTC | Proposal record’s own timestamp |
| Expiration time? | 1756468800000ms = 2025-08-29 12:00:00 UTC | Not this article’s publication date |
| What value was observed now? | getEnergyFee 100 | A separate latest-view response on 31 October 2026 |
Governance-record numbers and parameter numbers live in different namespaces. The number 104 identifies this proposal; 11 identifies the setting inside its parameter list. The current chain-parameter response uses the named key getEnergyFee. Searching a response for the record number will not reliably find the changed setting.
3. Separate governance results from transaction success
The Hash link opened a successful, confirmed transaction at block 75,181,031. Its full hash was 40d5bdd965d26a56509cc54af552e379f17304118c5ffa3dc68e903ecde5a585. The page said the account created a proposal; its content requested the Energy price change. It did not describe a USDT transfer.
That transaction’s block time was 2025-08-26 10:00:42 UTC, three seconds after the governance record’s creation timestamp. Keep those as two named fields. Replacing one with the other would hide which source a later reader should reproduce. We did not independently identify the exact block that applied the parameter change.
The transaction’s successful result answers whether its creation operation succeeded. It cannot establish the later outcome by itself. Similarly, an expiration field is not proof that its requested value is the value returned by a current query.
4. Verify the proposal against a current-value read
We separately requested https://api.trongrid.io/wallet/getchainparameters and saved the complete response. The entry getEnergyFee carried 100. Dividing 100 SUN by 1,000,000 SUN per TRX gives 0.0001 TRX per Energy unit, matching the explorer parameter display in this observation.
This match supports a dated comparison of the selected fields. It does not prove that the parameter remained unchanged throughout every intervening block. The reads were sequential and not pinned to one block. We did not run an independent node or reconstruct the complete governance history.
For a software-draft comparison, see the TIP-945 vote-input and stake-weight review, checked November 3, 2026. An issue, an unmerged implementation and a local rule model do not establish Mainnet activation. Keep each evidence state separate before attributing a changed transaction result to a proposed network setting.
When counts or labels differ
Our saved provider response contained 27 approval addresses, all distinct. The explorer detail displayed Upvotes 25 and Not voted 2. We retain both observations. We did not reconstruct the active committee at expiry, inspect each approval transaction or establish why the two counts differ.
Do not silently edit 27 to 25, infer fraudulent voting, or call today’s candidate list the historical eligible committee. The witness-list data audit shows why candidate records, active flags and vote counts require separate denominators. It is an October 29 snapshot, not a reconstruction of August 2025.
State labels need the same care: our raw response used APPROVED while the visible detail used EXECUTED. Quote the label with its source rather than claiming that every API and interface uses one vocabulary. A missing result, an Error object and an explicit pending state are also different observations.
A reusable proposal decision worksheet
| If you have | You can say | Still required |
|---|---|---|
| Successful creation receipt only | The request was created | Read its governance result |
| An open proposal and a large tally | The displayed tally at that time | Wait for settlement; preserve source and eligibility scope |
| A historical completed result | That recorded outcome | Query the current matching parameter |
| A current value matching the proposal | The two values matched in this dated observation | Historical evidence for a continuous-value or exact-activation claim |
| Two different counts or labels | Both observed source values | A separate investigation before attributing a cause |
For your own note, preserve network, proposal URL, numeric record ID, parameter ID and unit, requested value, exact state string, creation timestamp, expiration timestamp, current-query key and collection time. Add the creation hash in its own field. Write unresolved differences as unresolved instead of forcing them to agree.
If a page asks for a wallet before an action, stop at the public reading task. No submission, signature or vote is necessary for this worksheet. If a provider refuses access or returns no usable record, retain that limitation and use the available official public view; do not bypass an API-key requirement or invent a result.
Practice a claim with the evidence you actually have
Hypothetical exercise: someone sends a screenshot of a successful creation receipt and says a lower fee is already active. First identify the operation and its date. Next open the linked governance record, check the requested parameter and read the governance result. Finally obtain a separate current-value observation. If any stage is unavailable, narrow your statement to the stage actually checked.
For our real example, a reproducible note can say: Mainnet proposal 104 was returned as APPROVED by the provider; the explorer displayed EXECUTED; its parameter 11 value was 100 SUN. The separate current getEnergyFee read also returned 100. The governance response completed at 03:06:26.461853 UTC and the current-parameter response at 03:06:26.602291 UTC on 31 October 2026. Both requests returned HTTP 200 and usable expected fields.
Those are collection times, not activation times. They belong beside the saved files rather than replacing the 2025 creation and expiration dates. Our note also preserves the unresolved approval-count difference. It does not say that a new reduction happened during our review.
If a later current read differs, retain both dated observations. Check subsequent governance history and provider freshness before attributing a cause. A changed present value would not, by itself, prove that this historical request failed. A match would not establish the entire intervening history either.
Five frequently asked questions
1. Are TRON proposals the same as transfers?
No. This governance operation requests a network-parameter change. Its creation transaction is a different operation from a token transfer.
2. Does a successful creation transaction mean a proposal passed?
No. Read the separate proposal outcome and its dates. Transaction success alone does not settle governance.
3. Is proposal 104 the same as parameter 104?
No. Our example is proposal 104 changing parameter 11, represented as getEnergyFee in the current-value response.
4. Did the Energy price change on 31 October 2026?
This article does not establish such a change. It checks a historical 2025 proposal against a 31 October 2026 observation.
5. Can I read TRON proposals without connecting a wallet?
Yes. We read the public parameter, proposal and creation-transaction pages without a connection and performed no governance action.
Sources, testing scope and corrections
The independent Tronscan News editorial team checked the cited official documentation, public Mainnet pages and two provider responses on 31 October 2026. Original work includes the field correspondence, exact millisecond conversions, unique-address count, decision worksheet and two diagrams. AI assisted drafting and diagram preparation. The saved observations are not block-pinned, an independent consensus audit, a historical committee reconstruction or a future-fee guarantee. Editorial standards and corrections are available through the Tronscan News homepage.
Leave a Reply