TRON Proposal 108: Approved State and a Critical Flag Check

TRON proposal 108 returned APPROVED in our post-expiry Mainnet read at 12:00:16 UTC on November 2, 2026, with 26 unique recorded approval addresses. A separate current-parameter read returned getAllowOptimizeTvmStorageKey with an explicit integer value of 1. This is new provider evidence after the stated deadline, not a reconstruction of the final eligible-voter count or a test of every node deployment.

This is a dated news and data review of an actual October 30 governance request. It is not a November 2 launch announcement or a generic promise of lower USDT fees. We retained three pairs of anonymous node responses: 02:06:34 UTC (10:06 Beijing), 04:47:49 UTC (12:47 Beijing) and a post-expiry pair beginning 12:00:16 UTC (20:00 Beijing). Each pair contained sequential latest-state reads, not historical results pinned to the same block. The original diagrams preserve the earlier observation and its timestamp; the update table below supplies the later evidence.

Post-expiry update: an approved state and explicit parameter value

The later proposal response retained ID 108, the requested pair 102 = 1 and the same 12:00 UTC expiry. Its address set added one entry relative to 04:47 UTC, with none removed. Unlike the two earlier responses, it supplied an explicit APPROVED state. The separate parameter response also changed the evidence from an omitted default value to an explicit integer 1.

Our local reader returned value=1 with origin=”explicit integer” for this new actual parameter response. We preserved all earlier raw files and their absence-versus-default interpretation. These latest reads establish what this provider returned after expiry. We did not independently reconstruct the active-SR eligibility tally, identify the exact execution block, audit all deployed nodes or measure a fee or throughput effect. We performed no vote, signature or node upgrade.

Pre-expiry proposal fields retained for comparison

The primary discussion in the TRON TIPs repository, opened October 30, describes enabling ALLOW_OPTIMIZE_TVM_STORAGE_KEY, parameter 102, to improve contract-storage reliability. Its estimated effective date is November 2 and remains conditional on approval and effect. The discussion asks node operators to use a supporting version before activation; we did not test an upgrade.

The proposal 108 evidence uses three different identifiers. Proposal 108 identifies the on-chain voting request. Parameter 102 identifies the setting it asks to change. GitHub issue 946 identifies the discussion. They are not interchangeable numbers, and a link to a discussion is not an on-chain execution receipt.

This table is our original extraction from the saved provider responses. We checked the proposal ID and complete parameter pair before counting approvals. It does not show a final eligible-voter tally, a measured performance improvement or a completed node deployment. No synthetic transaction has been added to make the event appear complete.

The midday observation added two records before the result

We compared the two recorded address sets: the later set had two additional entries and no removed entries. This is a comparison of provider responses, not proof of two newly eligible votes. The parameter request and deadline were unchanged. Our local flag reader also returned the same value-with-provenance result for the later parameter response. Both sets of original files were retained without rewriting the morning snapshot.

Why neither recorded count established activation

The official committee lifecycle documentation distinguishes recorded approvals from the eligible active-SR count at expiry. It states that at least 18 of the 27 active SRs are needed and that passing the threshold during the window does not apply a change early. Settlement occurs through the maintenance-triggering block at or after expiry.

Our proposal 108 observation was earlier than the returned deadline. The pre-expiry 04:47 UTC approvals array contained 25 distinct entries; we did not reconstruct the eligible active set at the future expiry. The count therefore supports a narrow statement about the observed record, not a forecast that all 25 will count or that the request will pass.

The general TRON proposal-reading guide remains the reusable method page. This article adds a separate dated event record for request 108. The earlier guide’s historical example 104 concerns a different parameter and date; neither its result nor its fee value can be copied into this event.

The deadline in UTC and Beijing time

We converted the actual expiration_time value as Unix milliseconds: 1793620800000 divided by 1000 gives seconds for the conversion. The resulting deadline is November 2 at 12:00:00 UTC, or 20:00:00 in Beijing and Singapore. The first two observations occurred before that boundary: about ten hours and just over seven hours earlier. The third began 16 seconds after the stated expiry; that observation time is not a claimed exact execution time.

These conversions describe the returned timestamp. They are not a guarantee of the exact execution block or the time an explorer interface will refresh. Our new pair after 20:00 Beijing is recorded above; a later reader should collect another result rather than treat either historical table as permanently current. Preserve the original observation time when sharing it.

What the earlier parameter response supplied

The pre-expiry current-parameter reads paired with proposal 108 contained a named entry for getAllowOptimizeTvmStorageKey but omitted its value property. The endpoint documentation explains proto3 default-value omission and identifies value as an int64 whose default is zero. Under that documented rule, this entry is interpreted as zero; the raw response did not literally contain a numeric zero.

That distinction matters for reproducibility. A note saying “value absent, interpreted as zero under the documented endpoint rule” preserves more evidence than silently rewriting the saved JSON. It also prevents a missing key or a failed request from being normalized into the same result. We did not modify the original files to add absent properties.

A small flag reader with provenance

The copyable local Python function below accepts one expected entry in a normal parameter-list response. It returns the value together with its provenance. It deliberately rejects missing or duplicate keys, explicit null, booleans, error envelopes and values outside the expected 0/1 flag range. It does not fetch data, sign a proposal or change a node setting.

def read_storage_key_flag(body):
    key = "getAllowOptimizeTvmStorageKey"
    if not isinstance(body, dict) or "Error" in body or not isinstance(body.get("chainParameter"), list):
        raise ValueError("Not a parameter response")
    rows = [r for r in body["chainParameter"] if isinstance(r, dict) and r.get("key") == key]
    if len(rows) != 1:
        raise ValueError("Missing or duplicate key")
    row = rows[0]
    if "value" not in row:
        return {"value": 0, "origin": "documented proto3 default; field absent"}
    value = row["value"]
    if type(value) is int and value in (0, 1):
        return {"value": value, "origin": "explicit integer"}
    if type(value) is str and value in ("0", "1"):
        return {"value": int(value), "origin": "explicit decimal string"}
    raise ValueError("Unexpected flag value")

Nine cases passed locally, and the same cases were run against the exact copyable function. One used our actual current-parameter response. Eight were clearly synthetic fixtures: explicit integer zero, explicit decimal-string one, missing key, duplicate key, explicit null, Boolean true, an error envelope and an unexpected integer two. Accepted values retained the explicit-versus-default origin; invalid cases were rejected.

This helper is intentionally narrow. It is not a complete protobuf JSON implementation or a historical network-parameter decoder. It does not validate every unrelated entry, establish which block a provider used or make an untrusted server authoritative. Its purpose is to stop these specific record shapes from collapsing into an undocumented zero.

How to repeat the public check without voting

1. Record the network and observation time. Our host was the public Mainnet provider api.trongrid.io, not the test-network host used in some documentation examples.
2. Query getproposalbyid with id 108 and retain the complete response. Match the returned proposal_id and parameter pair before interpreting timestamps or approvals.
3. Query getchainparameters separately. Locate the exact named storage-key entry, preserve whether value exists and apply only the documented omission rule.
4. After the deadline, repeat both reads and compare the state, parameter and read times. If the evidence conflicts or a request fails, retain an unresolved result instead of declaring activation.

The official proposal-query reference describes the ID-based lookup. It is a read operation, unlike proposal creation, approval or deletion. We used no wallet, signing key, governance vote, transaction broadcast or server upgrade in collecting this report.

We also attempted the public TRONSCAN proposal-detail page, but it showed a security-verification interstitial during this run. We did not bypass it and did not claim a current explorer status or upvote count. The saved node data is the basis of our numerical observation. A reader can use the ordinary official explorer when available, but should keep interface labels and raw data fields separate.

What ordinary USDT readers should do next

This event is about a TVM feature flag. The single parameter pair we received is not an Energy-price change, token migration, deposit-address replacement or instruction to move funds. The existing network-release review covers the separate software-release context; a release notice alone is not proof that this governance flag has applied.

Do not use the headline approval count to promise cheaper transfers, higher yields or a TRX price outcome. For resource pricing, use the separate dated fee-parameter audit method and the actual transaction receipt. Our report measured no before-and-after fee, throughput or contract-execution improvement.

Observation UTC / network / provider:
Proposal ID / complete parameter map:
Creation and expiry milliseconds / converted timezone:
Raw approval entries / unique addresses:
Explicit state field, or absence preserved:
Named current entry / value presence / interpretation rule:
Later observation / final-state evidence / unresolved differences:

The post-expiry result and later parameter read now resolve the earlier lack of an explicit state and value in this provider evidence. Exact execution timing, independent eligible-voter reconstruction and deployment-wide behavior remain separate questions. An estimated date or a raw count alone would not have resolved them.

Frequently asked questions

What did the post-expiry check establish?

The provider returned APPROVED and the named current parameter explicitly returned 1. We did not establish the exact execution block or independently test every node deployment.

Does the latest count mean 26 independently verified eligible votes?

No. They are unique recorded approval addresses at one time. We did not independently reconstruct the eligible active-SR set at expiry.

Is parameter 102 a new USDT transfer fee?

The observed request concerns the named TVM storage-key flag. This report provides no new USDT fee quote.

Why distinguish an absent value from zero?

The endpoint documents a default interpretation for an omitted value in a present entry. A missing key, explicit null or failed response is a different case.

Did Tronscan News vote or upgrade a node?

No. We collected anonymous public reads, checked local fixtures and retained a blocked explorer observation. No governance or wallet action was performed.

Independent Tronscan News reporting with AI-assisted drafting. Primary sources and data checked November 2, 2026; node reads at 02:06:34, 04:47:49 and 12:00:16 UTC. Two original historical diagrams, a three-time comparison, field tables and nine original local fixtures plus the new actual parameter check support this report. The provider’s APPROVED result is reported; no independently reconstructed eligible-voter tally, exact execution block, deployment audit, performance gain or current explorer detail is claimed. Browse the Tronscan News homepage; use About & Standards for corrections.