TIP-945 proposes a more explicit order for TRON vote input checks and a per-account method for Stake 2.0 weight updates. It does not raise the 30-entry vote limit. As checked November 3, 2026, the primary discussion still identifies the proposal as a draft and its associated implementation pull request is open and unmerged.
This review explains the October 27 draft and October 29 clarification through a small original rule model and synthetic arithmetic examples. It is for readers interpreting proposed contract behavior and internal records. We did not vote, stake, sign, deploy a contract or execute the java-tron virtual machine. Our success standard is an evidence table that distinguishes an early rejection, later processing and an unproved network rollout.
Table of Contents
1. Establish the scope before reading a TRON vote input
A vote input in this review is the paired witness-address and vote-amount arrays supplied to the contract voting instruction, together with their declared lengths. It is not a transaction hash, a wallet approval or an explorer account label. Reading a TRON vote input means identifying those paired fields before deciding which proposed validation rule applies.
The TIP-945 draft concerns TVM resource processing. Its vote-input section describes the contract execution path, not a new rule telling every ordinary wallet user to vote for 30 representatives. A maximum is a boundary for supplied entries, not a recommended portfolio or a promise that every input below it will succeed.
The associated implementation PR7069 is a separate software-review record. A branch name, milestone or test report does not establish Mainnet activation. Keep the draft status, implementation state and runtime parameter state in separate columns. This article checked the first two and did not establish the third.
The source issue was created October 27 and last updated October 29 in the saved API metadata. November 3 is our review date, not a claimed protocol launch date. We retained the PR head revision returned by the public API with the source snapshot, because an open pull request can change after a reader’s visit.
2. Preserve the first failing vote input check
The proposed sequence first compares each array’s in-memory header with that array’s supplied length: witness first, amounts second. Only after both match does it compare the two supplied lengths with each other. Only after those lengths agree does it compare their common count with the existing limit of 30.
This ordering matters when a synthetic vote input violates several conditions. A header mismatch is not interchangeable with an oversized count. Under the draft’s stated sequence, the earlier mismatch determines the route before a later count check is reached. Retaining the first failed condition is more informative than labelling every unsuccessful vote input “over limit.”
For the supplied-length and oversized-count failures, the draft specifies a failure return and no vote-state update, with additional details about the recorded internal transaction. It also preserves earlier VM and resource checks. Therefore a simplified count comparison cannot reconstruct every exception, Energy charge or enclosing-call outcome.
Our original six-case rule-model worksheet
We wrote a small local Python function with four integer inputs: witness header, supplied witness length, amount header and supplied amount length. The function checks the three gates in the stated order and returns a descriptive label. The following six fixtures all produced the expected label in our local run on November 3.
| Synthetic fixture | Witness header / supplied | Amount header / supplied | Local model output |
|---|---|---|---|
| empty | 0 / 0 | 0 / 0 | continue existing rules |
| limit | 30 / 30 | 30 / 30 | continue existing rules |
| over limit | 31 / 31 | 31 / 31 | count limit return0 |
| unequal supplied | 31 / 31 | 30 / 30 | length mismatch return0 |
| first header conflict | 30 / 31 | 30 / 30 | witness-header exception |
| second header conflict | 31 / 31 | 29 / 30 | amount-header exception |
“Continue existing rules” means only that our three-gate model did not reject the input. It does not mean that a real vote input was accepted. The model has no witness accounts, vote amounts, memory engine, Energy accounting, transaction nonce, storage state or actual internal-transaction recorder.
The two conflicting-header fixtures deliberately use otherwise problematic counts. They demonstrate why a reader should preserve the priority rule. The unequal-length fixture has a supplied witness length above 30, yet our model reports the earlier length mismatch because both individual headers agree with their own supplied values.
The empty-array fixture keeps the proposal’s stated existing behavior outside the model’s conclusion. Our vote input model permits it to proceed to later rules; it does not assign a new empty-vote meaning. This distinction prevents a compact teaching model from silently inventing protocol behavior that its inputs cannot represent.
3. Count entries before simplifying the list
The source describes the limit in terms of supplied entries before merging duplicate witnesses or removing zero-vote entries. A list containing repeated destinations is therefore not automatically reduced to the number of unique destinations for this boundary check. Keeping the raw count beside any normalized list avoids comparing different quantities.
As a hypothetical illustration, a supplied list with 31 entries cannot be called a 30-entry list merely because two rows name the same destination. That example explains the count definition; we did not construct or submit an actual encoded vote input payload. Whether any individual row is otherwise valid remains a separate question.
The oversized-count branch is specified to reject before per-entry payload copying and decoding. This is an execution-order requirement, not a claim that rejection has zero cost. The draft preserves ordinary instruction and memory-related charges assessed before this branch, as well as existing exceptions and constraints.
For an explorer reader, a rejected internal action and the status of its enclosing transaction are separate fields. Do not turn a model’s return-zero label into a claim that the whole call reverted, every resource was refunded or no fee existed. Those conclusions require actual execution evidence that we did not collect here.
4. Round stake weights account by account
The second part of the draft describes eligible Stake 2.0 balances and integer weight accounting. Its rule divides each account’s relevant balance by one million sun and takes the whole-number part before summing. Combining different accounts’ balances before division can produce another result.
Our clearly synthetic example starts with 1,600,000 sun of eligible source stake and 600,000 sun of existing eligible beneficiary stake. Before a full eligible transfer, their separate weights are 1 and 0. After consolidation at the beneficiary, 2,200,000 sun produces weight 2. The operation-local difference is therefore plus1.
A second example uses exactly 1,000,000 sun at each account. The separate weights total 2 and the combined weight is also 2, giving a delta of zero. Thus a positive transfer amount alone does not determine whether the rounding boundary adds a weight unit; the before and after states matter.
We checked the same integer identity over 441 pairs sampled at 100,000-sun intervals, from 0 through 2,000,000 sun for each account. Each sampled combined-floor minus separate-floors result was 0 or 1. This is an original local arithmetic check on that grid, not exhaustive coverage of VM states, all balances or production transfer behavior.
Keep eligible stake and spendable balance separate
The source’s eligible categories distinguish stake owned by an account from acquired delegated resources and from liquid, pending-unfreeze or withdrawn balances. Our arithmetic examples assume eligible balances; they do not provide a method to turn a wallet’s total displayed TRX into a resource weight.
The draft also describes the state boundary around an individual transfer. A subsequent operation uses the state left by the previous operation, rather than repeatedly starting from the transaction’s initial snapshot. A source deletion marker does not authorize applying the same delta a second time after the operation has already accounted for it.
Its October29 clarification explicitly separates prevention of future discrepancies from reconciliation of older offsets. We did not quantify any historical network discrepancy, and the source does not supply a measured cumulative Mainnet amount in that clarification. Our plus1 example must not be multiplied by an invented transfer count to claim a real total.
A read-only review checklist
- Confirm the official issue and software PR URLs. Save their current status, update dates and revision. Keep the observation date separate from the proposal creation date.
- Write the raw vote input counts and array-header counts in distinct fields. Apply the proposed checks in order, recording the first failed gate.
- Label every simplified result as a model output. A continued model path needs later protocol validation; an early rejection does not reconstruct the whole receipt.
- For a rounding example, record eligible balances for each distinct account before and after the operation, then compute individual whole-number weights before summing.
- Stop at the supported conclusion. A draft, unmerged implementation, synthetic calculation and active Mainnet rule are different evidence states.
For context, see our TRON proposal lifecycle guide, staked versus available TRX balance explanation, and guide to internal transaction records. Each handles a separate part of interpreting a future implementation or a current public record.
The Tronscan News home page links our independent English guides. AI assisted preparation; the editorial check used the linked primary sources, saved public API metadata and local model results on November 3, 2026. We are not the protocol authors and do not claim their reported full regression suite as our own test.
Frequently asked questions
Does TIP-945 raise the TRON vote input limit?
No. The draft retains the existing 30-entry limit and makes the order and scope of its check explicit.
Does a local model result prove Mainnet behavior?
No. Our model checks a short rule sequence and integer arithmetic. It does not run java-tron or establish activation.
Can duplicate witnesses be removed before the proposed count check?
The draft defines the boundary using supplied entries before duplicate merging or removal of zero-vote entries.
Does a return-zero branch mean a free or fully reverted transaction?
No. A simplified rejection label does not reconstruct earlier resource charges or the outcome of the enclosing call.
Does the rounding example measure old network discrepancies?
No. The examples are synthetic and the sampled grid is local arithmetic. We did not measure a historical Mainnet offset.
Leave a Reply