TRON Block Statistics: A Dated Arithmetic Audit

TRON block statistics mix recent-period observations with cumulative counters, so they cannot all be interpreted as one day’s activity. In the official response collected on 27 October 2026, the reported recent-period reward divided by its block count equals 136 TRX per block. Applying that observed ratio to the historical block count does not reproduce the cumulative reward field.

This block statistics report is an original arithmetic and scope audit of six returned fields. It explains how to reproduce the calculations, retain the discrepancy and avoid assigning an unsupported date, reward rule or supply conclusion. The collection time is 27 October 2026 at 05:31:29 UTC; the response itself does not include a native update timestamp or explicit start and end timestamps.

The practical success standard is a worksheet whose inputs, units, horizons and derived results remain distinguishable. This report is not a validator earnings forecast, a fee quote, a live network monitor or a reconstruction of all historical reward parameters.

What the block statistics source actually provides

The official block-statistic reference distinguishes recent-period block production and rewards from historical counters. We use those field definitions alongside the complete saved response, rather than inferring meaning solely from an API field’s prefix.

For this audit the public endpoint is https://apilist.tronscanapi.com/api/block/statistic. Our retained request returned HTTP 200. That successful response is evidence of this collection; it is not a promise about future API availability, credentials, quotas or response timing.

If you need to locate an individual account, token or transaction first, use the TRONSCAN guide to choosing a public record. Aggregate block statistics answer a different question from the contents of a selected block or transaction receipt.

Six fields and their reporting horizons

The last row is the naming trap: despite its last_day prefix, the reference describes a cumulative burn counter. Treating it as another 24-hour burn observation would change the interpretation by a very large amount without changing the underlying digits.

The table expands the response’s scientific-notation cumulative burn value for readability. This formatting change does not create more source precision. Our checker parses decimal JSON numbers without first converting them through binary floating-point arithmetic.

A recent-period ratio that can be reproduced

Divide the reported 3,915,712 TRX of recent-period rewards by the reported 28,792 blocks. The result is exactly 136 TRX per block for these two retained fields. Multiplying 28,792 by 136 reproduces 3,915,712.

This equality is a local arithmetic check. It does not independently establish the network’s current reward configuration or prove that every individual block had the same payout. The reward field combines the documented reward categories, while the denominator is a block count.

The documentation includes a reward example using component values that sum to 136. An example and a matching snapshot ratio are useful context, but neither authorizes publishing that amount as a fixed rule for every past or future period. Historical parameters require historical evidence.

Keep the quotient’s unit visible: TRX per reported block. It is not transactions per second, TRX per transaction, a USDT transfer fee or a return available to a particular account. Replacing the denominator silently changes the question.

Why the historical multiplication does not reconcile

Now multiply the historical block count, 87,468,611, by the observed recent-period ratio of 136. That calculation gives 11,895,731,096 TRX. The retained cumulative reward field is 12,996,293,616 TRX.

The difference is 1,100,562,520 TRX. We label it the difference between a hypothetical historical multiplication and the reported cumulative reward counter. We do not label it missing funds, a provider defect or a new issuance event.

The official reference cautions that cumulative rewards reflect historical reward rules. Our calculation therefore demonstrates why the shortcut is unsupported; it does not reconstruct the amount associated with each rule change or identify a date when a parameter changed.

To build a historical reward model, you would need the applicable parameters and their activation boundaries, the relevant production and voting observations, and a justified accounting method. None of that history can be recovered merely by dividing one present cumulative number by another.

Do not turn two reported amounts into a supply conclusion

Subtracting the recent burn field from the recent reward field gives 1,416,887.8288002014 TRX in this saved response. That subtraction is reproducible, but a correct subtraction alone does not establish a complete change in TRX supply.

A supply claim needs the correct population of additions and removals, compatible boundaries and a clear definition of the supply measure. The six block statistics fields do not independently demonstrate that every relevant supply mechanism has been included.

We therefore present the difference only as reward minus burn for two named source fields. It is not a verified net issuance figure, deflation rate, investment signal or statement about exchange liquidity. These stronger interpretations would require additional evidence.

It would be even less appropriate to subtract the cumulative burn counter from a 24-hour reward figure. Both values are expressed in TRX, but a common unit does not make their reporting horizons compatible.

A normalized interval is not measured block timing

Dividing 86,400 seconds by the reported recent block count yields approximately 3.000833565 seconds per block. This is a normalization over an assumed 24-hour interval, using the documented scope of the count.

It is not a direct measurement of adjacent block timestamps. A distribution of actual intervals, gaps or outliers requires individual block observations and an explicit sampling method. The aggregate count does not show where an unusually long or short interval occurred.

Do not convert this normalized number into a claimed uptime percentage, a count of missed blocks or a performance guarantee. Those outcomes require a defined expected schedule and evidence about production opportunities, neither of which is established by this calculation.

Our guide to reading an individual TRON block page addresses the separate task of examining a specific block. Use that method when the question depends on a particular height, timestamp or included transaction.

Reproduce the block statistics audit step by step

1. Retain the response and collection time. Save all six fields and the HTTP result. Do not rename collection time as the source’s own update timestamp.
2. Assign a horizon to each field. Use the reference to distinguish recent-period values from cumulative history, especially the cumulative burn field.
3. Preserve units before calculating. The documented monetary fields here are TRX. A generic rule to divide every blockchain number by one million would corrupt these values.
4. Calculate the recent-period quotient. Divide the named reward field by its block count and retain the TRX-per-block unit.
5. Test the historical shortcut explicitly. Multiply the historical block count by that quotient and compare it with the cumulative reward field. Preserve the nonzero difference.
6. Label optional derived quantities narrowly. Reward minus burn and normalized seconds per block remain specific calculations, with the limits described above.
7. Save the calculation output. Record a successful local reproduction separately from any unsupported semantic interpretation.

The following standard-library Python example was executed locally against the saved JSON response on 27 October 2026. It performs no wallet operation, signing request or live blockchain mutation.

import json
from pathlib import Path
from decimal import Decimal, getcontext
getcontext().prec = 40
data = json.loads(Path("block-statistics-publication-source.json").read_text(), parse_float=Decimal)
blocks = Decimal(data["last_day_block_count"])
assert blocks > 0
pay = Decimal(data["last_day_pay"])
ratio = pay / blocks
historical_example = Decimal(data["whole_block_count"]) * ratio
historical_residual = Decimal(data["whole_pay"]) - historical_example
print("last-day reward per block", ratio)
print("historical count times observed ratio", historical_example)
print("reported cumulative rewards", data["whole_pay"])
print("historical difference", historical_residual)
print("normalized seconds per block", Decimal(86400) / blocks)
print("reward minus burn", pay - Decimal(data["last_day_burn"]))
assert pay == blocks * Decimal(136)
assert historical_residual != 0

What passed and what remains unresolved

The retained recent-period block count is positive, allowing division. Its reward quotient is 136, and multiplying back reproduces the reported recent reward. The historical shortcut produces a nonzero difference, which our checker deliberately retains as an expected finding.

The decimal subtraction and normalization also reproduce the values quoted here. These checks establish the arithmetic on the retained inputs. They do not certify finalization of the provider’s recent-period series, the exact rolling boundaries or a universal update instant.

The block statistics response lacks a native update timestamp. We therefore cannot demonstrate from this payload alone that all six fields were refreshed simultaneously. A successful HTTP response and a precise local collection timestamp do not fill that evidence gap.

If a later response changes one field, retain both versions and their collection times. Do not replace this report’s input while keeping the old checking date. A newly observed value may justify another calculation, but a single changed number does not identify the provider’s revision policy.

A practical worksheet before reusing the figures

For each block statistics figure, copy the original field name, value, unit, horizon and collection time into separate columns. Add another column for what you calculated. This makes it harder to confuse a returned counter with an author-created ratio.

For last_day_pay, the returned value belongs in the source-value column; 136 belongs in the derived-value column with its formula and denominator. For whole_pay, retain the actual cumulative amount. The hypothetical multiplication belongs in its own comparison column, not in place of the source counter.

For last_day_total_burn, write cumulative history in the horizon column even though the prefix appears to suggest a recent period. This explicit field mapping is the main safeguard against accidental daily-versus-cumulative comparisons.

Leave the exact start and end timestamps unresolved when the response does not provide them. A label saying recent 24 hours is not an independently verified calendar date in Beijing, UTC or another timezone. In particular, this collection is not presented as a certified complete report for 26 October.

Respond to missing or changed block statistics fields

If the block count is zero, do not divide by it. If it is absent, do not silently substitute zero or a value from another endpoint. Preserve the failed or unavailable calculation and obtain a compatible observation before continuing.

If monetary fields arrive as strings, parse them deliberately and validate their format. If units change or the reference changes its definitions, stop the affected comparison until the mapping has been reviewed. Arithmetic routines cannot determine a field’s economic meaning from its spelling.

If another report quotes a different cumulative total, compare collection times and complete source fields before calling either report wrong. A moving counter, a different horizon or a different dataset can produce distinct values without showing an arithmetic error.

The transaction-counter scope and timing audit provides a related example of why multiple returned numbers cannot automatically be treated as an exclusive breakdown. Here the principal distinction is recent-period versus cumulative block statistics.

Publish a restrained and useful result

A concise factual summary can state that the recent-period fields produce an observed reward ratio of 136 TRX per reported block, while applying that ratio to historical blocks does not reproduce cumulative rewards. Include the collection date and preserve the source’s cumulative counter.

Keep the historical difference visible and describe the shortcut being tested. That helps a reader avoid an invalid calculation without implying that the difference is an unexplained financial loss or evidence of misconduct. We did not inspect private balances or provider accounting systems.

The original contribution is the six-field scope mapping, reproduced arithmetic and explicit failure branches. The diagrams summarize those calculations; they are not screenshots of a real explorer interface or evidence of a wallet transaction. Readers can verify the method without connecting a wallet.

Check the arithmetic by hand before automating

For the recent-period reward check, split 136 into 100, 30 and 6. Multiplying 28,792 by those parts gives 2,879,200, 863,760 and 172,752. Their sum is 3,915,712, matching last_day_pay. This transparent multiplication checks the quotient without relying on an undocumented conversion factor.

For the historical block statistics test, multiplying 87,468,611 by those same parts gives 8,746,861,100, 2,624,058,330 and 524,811,666. Adding them gives 11,895,731,096. Subtract that hypothetical amount from the retained whole_pay of 12,996,293,616 to obtain 1,100,562,520.

These two calculations have different evidentiary outcomes. The recent-period multiplication reproduces its paired field. The historical shortcut does not reproduce the cumulative reward counter. Calling both calculations successful reward models would erase the distinction the audit was designed to expose.

Rounding also needs a stated purpose. Reporting the normalized interval as roughly three seconds is adequate for a brief description of this particular normalization. It would be inadequate evidence for a claim that every observed block interval was exactly three seconds. No amount of extra decimal precision in the quotient creates the missing timestamp distribution.

Keep a small provenance record with the worksheet

Retain the endpoint, collection time, HTTP result, original response and calculation version together. The reader-facing table may use comma grouping while the saved JSON uses scientific notation; document that formatting choice so a reviewer can trace a displayed figure back to the source.

Our local checker verifies the two multiplications and keeps the nonzero historical residual. It also prints the narrow reward-minus-burn and interval calculations, each with the limitations explained above. A reviewer who uses a later response should label it as a new observation rather than expect these fixed snapshot results.

This record supports a repeatable audit of block statistics. It does not establish a history of revisions, guarantee future source behavior or certify a calendar-day closing process. Those remain separate questions to investigate when the necessary evidence becomes available.

A clearly labeled failure example

As a hypothetical example, imagine a response with a missing recent-period block count but an available reward amount. The correct worksheet leaves the per-block ratio unavailable. It does not copy the historical block count into the missing denominator, because that would combine two different reporting horizons. This example is synthetic and does not describe a failure observed in our retained response.

Similarly, an empty response is not evidence of zero production. Preserve the request result and obtain a valid compatible response before computing a ratio. Separating unavailable inputs from numeric zero keeps the interpretation reviewable and prevents a technical collection problem from becoming a fabricated network statistic.

Frequently asked questions

Are all last_day fields daily values?

No. The official reference describes last_day_total_burn as cumulative historical burn. Use the documented field definition, not the prefix alone.

Is 136 TRX a permanent reward per block?

No. It is the quotient of two retained recent-period fields. This audit does not establish a permanent rule or an individual producer’s income.

Why does the historical multiplication differ from whole_pay?

The shortcut applies one observed ratio across all history. Cumulative rewards reflect historical rules, which this audit does not reconstruct period by period.

Does reward minus burn prove a change in TRX supply?

No. It is a subtraction of two named fields. A supply conclusion requires compatible boundaries and evidence covering the relevant supply mechanisms.

Does the normalized interval measure actual block delays?

No. It divides a nominal 24-hour duration by a reported aggregate count. Actual interval analysis requires individual block timestamps and a stated sampling method.

Editorial note: Tronscan News prepared this independent report with AI assistance, original worksheets and locally tested arithmetic on 27 October 2026. We did not test wallet actions, reconstruct all reward-rule changes or verify exact source refresh boundaries. Corrections information is available through the site navigation.

Find the main English guides at the Tronscan News home page.