TRON Multisig Fee: 3 Important Q2–Q3 Data Checks

The TRON multisig fee discussion has updated quarterly burn evidence, but the requested reduction is not the same as an enacted network fee. On November 3, 2026, our read-only Mainnet parameter response still returned getMultiSignFee = 1000000 sun, equivalent to 1 TRX. The discussion requests 500,000 sun.

The news event reviewed here is the author’s November 1 update to the Q2–Q3 worksheet in TIP issue 938, originally opened October 6. November 3 is our source and parameter check date. This article supplies a reproducible calculation sheet and a way to separate a proposed multisig fee, a current parameter and an observed transaction charge.

What changed in the multisig fee discussion

The author’s November 1 comment points readers to an updated worksheet and discusses the relative scale of multisignature surcharge burn across two quarters. It updates supporting evidence; it does not announce a completed Mainnet parameter change.

The open proposal discussion requests a reduction in the multisig fee from 1 TRX to 0.5 TRX. Issue 938 is a GitHub discussion identifier. It must not be entered into a chain proposal lookup as if the same number necessarily identifies an on-chain governance record.

Keep three dates in a source note: the original discussion date, the later evidence-update date and the time you observed the live parameter. This prevents an older proposal with a recent comment from being presented as a newly activated fee reduction. We did not independently verify an enactment history or an eligible-voter tally for this request.

Current parameter versus proposed multisig fee

We posted an empty JSON object to the public wallet/getchainparameters read endpoint at api.trongrid.io, around 01:10:56 UTC on November 3. The response included explicit integer values for both named keys. We divided sun by 1,000,000 to express TRX. This was a dated provider observation, not a fee estimate for a reader’s transaction.

The official chain-parameter reference is the starting point for repeating the read. Preserve the endpoint, timestamp, key and returned integer together. If a key is absent or a request fails, report the result as missing or failed; do not substitute zero or a proposal’s requested value.

Our Q2–Q3 calculation from the visible table

We transcribed the two visible quarter rows and used decimal arithmetic. The table below is our recalculation of those inputs. The source’s multisignature column concerns surcharge burn, not every resource charge associated with those transactions. We did not download and independently reconstruct the author’s full indexed dataset.

The formula is surcharge burn / listed total burn × 100. Using the unrounded Q3 inputs gives approximately 0.7008203153 percent. A caption discussing roughly 0.72 percent cannot be reproduced from these two displayed Q3 numbers alone. The reason for that small basis difference remains unresolved in this review; it is not proof that the complete dataset is wrong.

Across these displayed rows, multisign surcharge burn declines by about 13.53 percent from Q2 to Q3. Their two-quarter mean is 1,715,621.5 TRX. A statement about a two-quarter average should retain that averaging method; it should not replace the distinct quarter figures or imply they are equal.

A half-fee illustration is not realized savings

As a clearly hypothetical arithmetic exercise, hold the source’s transaction counts unchanged and multiply each by a 0.5-TRX surcharge. The resulting Q2 figure is 920,071.5 TRX and Q3 is 795,550 TRX. These are scenario outputs, not observed post-change burn or a forecast of user behavior.

That calculation assumes the same qualifying counts and a single applied surcharge per counted transaction. It does not estimate effects on transaction demand, other network charges, token price, wallet behavior or total future burn. A lower proposed multisig fee cannot by itself establish that a whole transaction would cost half as much.

The source author’s clarification defines the column through a count multiplied by the multisign fee and describes exclusions including failed transactions and very small TRX spam transfers. Those scope choices matter when comparing the worksheet with an explorer’s all-transaction counter. We retained the definitions rather than forcing unlike totals to match.

A reusable calculation note for the quarterly rows

Readers can reproduce the calculation with a calculator that preserves enough decimal places. Enter 1,591,100 divided by 227,033,943.68, then multiply by 100. The result starts 0.7008203153. Retain that unrounded intermediate number and round only the final displayed percentage to four decimal places: 0.7008 percent.

Repeat the same operation with 1,840,143 and 261,367,784.84 for Q2. Do not mix Q2’s numerator with Q3’s denominator. A spreadsheet cell formatted as a percentage already multiplies its displayed value by 100; entering an additional factor of 100 into that percentage-formatted cell would display a result one hundred times too large.

For the quarter-to-quarter change, subtract 1,840,143 from 1,591,100 and divide the difference by the earlier 1,840,143. Multiply by 100. The negative result means the source’s counted surcharge amount decreased between these rows. It does not mean every day declined, because a quarterly aggregate contains no daily sequence.

We also performed a simple reverse check on both hypothetical half-surcharge amounts: multiplying each by two reproduces the original surcharge number exactly. That checks transcription and arithmetic for this scenario. It cannot verify the author’s transaction classification, filters, underlying SQL output or completeness of the source table.

If your result differs, first check comma removal, decimal separator, copied quarter and whether the output cell uses percentage formatting. If those agree, preserve the difference as an unresolved question about the source basis. Changing the denominator until a caption matches would conceal the problem rather than reproduce the calculation.

This worksheet remains useful if the discussion later changes: keep the original inputs and date, then add a new observation beside them. Do not silently overwrite an earlier parameter read or present a later value as what the November 3 response originally contained. A supported historical comparison needs evidence from each observation time.

How to verify the next claim without signing anything

1. Record the exact discussion URL, issue creation date and evidence-update date. Identify whether a number is an issue identifier or an on-chain proposal identifier.
2. Read the current Mainnet parameter from the official documented path. Save the raw key, integer, endpoint and observation time.
3. Write the proposed value in a separate column. Only a supported execution record and a corresponding state observation can establish a specific change.
4. For a burn comparison, keep quarter boundaries, transaction filters, numerator and denominator together. Recompute the visible inputs before quoting a percentage.
5. For an individual payment question, inspect the actual transaction receipt and its other resource charges. A general parameter table is insufficient to reconstruct every final debit.

Success is a note that lets another reader reproduce the arithmetic and see what remains unverified. No wallet connection, message signature, permission change or payment is required for this source comparison. If an alleged read-only fee checker asks for a recovery phrase or a signed authorization, it has moved outside this workflow.

Where this update fits in the wider guides

Use our TRON permission and signature guide for weights and thresholds, the dated chain-fee parameter audit to distinguish parameter keys, and the proposal lifecycle guide for discussion, voting and execution states. These solve different tasks from this quarter-data reconciliation.

The Tronscan News home page organizes our independent English coverage. We are not TRONSCAN or the network’s governing authority. This article was prepared with AI assistance and checked against the linked primary discussion, saved parameter response and original decimal calculations on November 3, 2026. Corrections can use the site’s About & Standards route.

Frequently asked questions

Has the TRON multisig fee already been halved?

Our November 3 provider read returned 1,000,000 sun. The discussion’s requested 500,000-sun value is not proof of activation. We did not establish a completed change.

Is GitHub issue 938 a Mainnet proposal number?

No equivalence is established here. It is the identifier of a GitHub discussion. Verify an on-chain proposal through its own actual record.

Is the multisig fee the permission-update fee?

No. The dated response contains separate keys and values. Editing permissions and interpreting a multisignature transaction charge are distinct tasks.

Did this article independently rebuild all quarterly burn data?

No. We recomputed two visible table rows and recorded the author’s stated scope. We did not reproduce the complete underlying index or certify an all-chain total.

Does a proposed half surcharge mean every transfer costs half?

No. The hypothetical example changes one surcharge under fixed counts. Other charges, actual transactions and any future parameter change require separate evidence.