A new TRON vote allocation replaces the account’s complete previous allocation; it does not add the submitted rows to the old list. A candidate omitted from the new list is not retained merely because the account voted for it earlier. This is a guide to reading public records, not a request to change anyone’s votes.
A vote allocation is the list of SR candidates and vote counts associated with an account. To interpret a change, keep the old list, the complete submitted list and the current account state separate. Our original worksheet uses fictional Candidate A, B and C with a hypothetical 100 TP budget. No wallet, signature, stake or vote transaction was used.
Table of Contents
1. Read the vote allocation as a complete list
The official TRONSCAN voting guide, updated October 15, 2026, states that each submission replaces the entire earlier allocation. Include every candidate meant to remain in the new list. It also distinguishes successful confirmation from the later maintenance update of official candidate rankings.
For a reader checking an existing record, the important word is complete. An interface may let a user edit one visible row, but the recorded transaction must be interpreted through the list it actually submitted. A note that says only “added C” is insufficient to establish what happened to A and B.
Do not reconstruct a vote allocation from memory of the previous screen. Preserve the full candidate identifiers and integer counts from the record being reviewed. Short names such as A and B are appropriate for our fictional worksheet; a real investigation needs the original unabridged addresses and the network.
Our original replacement worksheet
Start with the synthetic old list A60 and B40. Now suppose a new complete list contains A20 and C80. The replacement model gives A20, C80 and no retained allocation to B. It does not give A80, B40 and C80. That additive interpretation would produce200 votes from a hypothetical 100 TP example.
| Synthetic new complete list | Resulting list in our model | Old candidate omitted | Unallocated from example 100 TP |
|---|---|---|---|
| A20, C80 | A20, C80 | B | 0 |
| A20 only | A20 only | B | 80 |
| A60, B40 | A60, B40 | None | 0 |
| C100 only | C100 only | A and B | 0 |
| A30, B30, C40 | A30, B30, C40 | None | 0 |
We tested all five rows with a small local dictionary-replacement function. Each result equalled the supplied new list, and each example total stayed within the stated 100 TP budget. A separate negative check confirmed that carrying old rows forward produces a different object. Another arithmetic check identified an illustrative A80+B40 list as exceeding that hypothetical budget.
These checks verify our worksheet’s consistency. They do not run the TRON voting contract, validate an encoded transaction or certify a wallet’s implementation. Candidate labels, amounts and budget are deliberately synthetic. No entry is a suggested candidate, real allocation or recommended investment.
2. Separate transaction history from current vote allocation
A successful historical transaction answers what was recorded at that point. The account’s current vote allocation answers a later state question. If another change happened after the transaction, comparing the old receipt with today’s list without preserving their times can make a correct record look inconsistent.
The official GetAccount reference includes account vote information among the data it can return. It also warns that many fields are conditional and that an HTTP 200 response can contain an Error object. Preserve the actual body and timestamp rather than treating every missing field as a proven empty allocation.
For example, “the response did not contain a votes field” and “the service returned a verified complete list with no retained candidates” are different observations. Our new read-only account checks below did not obtain a nonempty votes array. We therefore did not establish a specific account’s complete allocation or observe a real before-and-after replacement. The local replacement worksheet remains explicitly synthetic.
When two records disagree, first ask whether they describe the same account, network and moment. Then inspect whether a later successful vote or another documented state change explains the difference. Avoid resubmitting a financial or governance action merely because an old screenshot and a current page show different rows.
Our actual public-account retrieval check
At about 04:29:31 UTC on November 3, 2026, we read the public Mainnet provider at api.trongrid.io. One wallet/listwitnesses request supplied candidate addresses. We selected only the first three provider-list entries, converted their address representation to Base58 and sent wallet/getaccount reads with visible=true. Source-list order was not treated as a ranking.
| Actual account queried | HTTP and returned identity | Votes field supplied? |
|---|---|---|
| TN2W4cc7a4dsYyTLiLMWa9m7jVpdLjGvYs | 200; matching address | Not present |
| TVFKwzE8qeETLaZEHMx2tjEsdnujAgAWaA | 200; matching address | Not present |
| TC6qGw3d6h25gjcM64KLuZn1cznNi5NR6t | 200; matching address | Not present |
All three requests returned the matching address, and none supplied a votes field. This is the recorded response shape, not a three-account proof of zero voting or an estimate of network-wide participation. We stopped after the preset three-account sample rather than search until a preferred result appeared.
- Read the documented Mainnet witness-list endpoint without wallet credentials and retain the response time.
- Take a bounded sample of source addresses and convert their representation, keeping each original address in the saved request.
- Read each account with visible=true; compare the returned address and inspect whether the votes field is present.
- Record omitted fields as omitted. Our check reached that branch and did not supply a real allocation to feed into the synthetic replacement model.
This tested path establishes that we could retrieve account objects for those three public identifiers. It does not establish who controls them, how they voted earlier, a historical committee or any reward eligibility. A real change investigation still needs its own successful transaction and sufficiently complete state evidence.
3. Keep personal allocation and candidate ranking on separate clocks
The TRONSCAN governance questions explain that account confirmation and official ranking recalculation occur at different stages. A candidate’s network-wide total is not the same quantity as one account’s vote allocation. Changing one does not require an immediate visually identical change in the other.
A ranking page aggregates allocations from many accounts. Its displayed ordering may follow a maintenance snapshot. A personal list can therefore be updated while a reader still sees an older candidate rank. The correct response is to preserve the two observation times and the relevant maintenance information, not assume the vote allocation was added twice or ignored.
Rewards introduce another scope. A visible allocation is not a receipt of a fixed return, and a successful vote transaction is not a reward withdrawal. This article does not estimate APR, recommend representatives or predict future earnings. Check the actual reward record separately when that is the question being investigated.
4. Distinguish allocated votes, TP and liquid TRX
Our 100 TP budget is a teaching input. A wallet’s liquid TRX balance is not a direct substitute for it. The cited guide describes voting power obtained through staking; this review neither stakes funds nor calculates a reader’s available TP from an address’s total asset value.
A partial vote allocation need not consume the whole illustrative budget. In the A20-only row, 80 TP remains unallocated in the model. The worksheet does not automatically distribute that remainder, preserve an omitted candidate or convert it into spendable TRX. Those would be additional rules that the model never implemented.
A permission to manage an account is also a separate record. Being listed as a signer does not establish how the account’s votes are allocated, while a candidate receiving votes does not become an authorized signer. Keep authorization, resource ownership and the vote allocation in distinct fields of your evidence note.
How to build a read-only comparison note
- Record the network, full voting-account address and transaction identifier from a trusted original source. Open the official explorer through a verified entry.
- Read the transaction type and result. For the documented voting workflow, the official guide names VoteWitnessContract. Do not infer success from a candidate name alone.
- Transcribe the complete candidate list and counts from that transaction. Keep its timestamp. Mark abbreviated or unavailable rows as incomplete evidence.
- Read the account’s current vote allocation separately and record the new observation time. Look for later relevant records before treating a difference as an error.
- Compare personal allocation with candidate rankings only after identifying their maintenance timing. Keep any reward calculation outside this allocation comparison.
The success criterion is a note another reader can audit without signing anything. Include four columns: old allocation with date, submitted complete allocation with transaction, current account list with observation time, and unresolved questions. If one column is unavailable, leave it unknown instead of filling it with the output of the fictional model.
Common misreadings and the next evidence to collect
An omitted candidate still appears in an older screenshot: establish which screenshot is earlier and whether it is a historical transaction view or current account state. The older appearance does not override a later complete vote allocation.
The personal list changed but the candidate rank did not: preserve the maintenance countdown and the rank observation time. One account’s updated allocation and a network snapshot need not refresh together.
A page is empty or a request failed: save the failure or incomplete response. An unavailable list is not a numeric zero allocation, and this guide provides no basis to recreate the missing list from candidate popularity.
The record involves unstaking or cancellation: investigate that action’s documented effect separately. Do not assume that every change to staked principal is a new vote submission or that restored resources necessarily reconstruct an old allocation. The official governance questions describe those distinctions.
For broader navigation, use our TRONSCAN beginner guide. To interpret aggregate candidate fields, continue to the witness-list snapshot audit; for a different account action, see voting rewards versus unstaking records. These are separate reading tasks.
The Tronscan News home page organizes independent English education. Sources and the local worksheet were checked November 3, 2026. AI assisted drafting and original diagrams. We retrieved three public account objects without obtaining a votes array. We did not operate a wallet, cast votes, validate a user’s governance transaction or test a live signing interface. Corrections can use the site’s About & Standards route.
Frequently asked questions
Does a new TRON vote allocation add to the old list?
No. The official guide describes complete replacement. Read the whole submitted list rather than combining it with an older allocation.
What happens to a candidate omitted from the new list?
The earlier allocation to that candidate is not retained by that new submission. Preserve the transaction and any later account changes when checking a real case.
Does an unchanged ranking prove the vote allocation failed?
No. Personal confirmation and official maintenance rankings are separate observations. Check the transaction result and the relevant times.
Is unallocated TP the same as liquid TRX?
No. The hypothetical remainder in our worksheet is unused voting power, not a calculated spendable balance or an automatic transfer.
Did the original worksheet send a vote transaction?
No. It tested fictional list replacement and arithmetic locally. It did not connect a wallet, sign, broadcast or measure rewards.
Leave a Reply