Brokerage Ratio on TRON: 4 Important Reward Checks

A TRON brokerage ratio is the percentage of a candidate’s applicable reward pool that the candidate retains. The voter reward ratio describes the remainder for voters; APR is a different estimate. A displayed 100% voter reward ratio therefore does not mean a 100% annual return, nor that each voter receives the whole pool.

We made three anonymous Mainnet ratio queries on November 3, 2026. All three responses explicitly supplied brokerage 0. This tutorial explains those dated results, a tested strict field reader and an original hypothetical pool calculation. We did not vote, stake, claim rewards, update a candidate’s settings or recommend a representative.

1. Identify what the brokerage ratio divides

The official reward-calculation guide describes Brokerage as the candidate’s retained share before the voter portion is distributed. The denominator is an applicable reward pool. It is not a wallet’s principal, a token price or the amount someone staked.

A brokerage ratio of 20 in a clearly hypothetical example means20% retained and80% remaining for the voter pool. It does not mean20% of a reader’s staked TRX is transferred to the candidate. This article interprets a percentage field and does not execute a distribution or reconstruct a real account’s lifetime rewards.

Keep the field name with its number. A screenshot cropped to show only “80%” loses the label that identifies its denominator. Before comparing two pages, record whether each number is Brokerage, Voter Reward Ratio, individual vote share, production ratio or APR.

2. Keep the voter reward ratio separate from APR

The official TRONSCAN field guide distinguishes the voter reward ratio from an annual estimate. Its usual complement is 100% minus Brokerage. APR instead depends on current inputs and is not a guaranteed return.

Those percentages answer different questions. The voter reward ratio asks how much of an applicable candidate pool is left for voters collectively. An individual share asks how much of that voter pool belongs to one allocation under the relevant snapshot. An annual estimate introduces a period and assumptions that neither of those two fractions supplies.

Consequently, our observed brokerage ratio 0 supports a calculated 100% pool remainder under the documented complement. It supplies no annualized performance number. We did not measure a year of rewards, prices, compounding, a reader’s vote share or future candidate settings.

Our actual three-response comparison

At approximately 04:33:54 UTC on November 3, 2026, we queried wallet/getBrokerage for two public candidate addresses and walletsolidity/getBrokerage for the first address. The addresses came from our saved bounded witness-list source sample. We did not select them as the best performers or use source-list order as a rank.

All requests used api.trongrid.io with the public address and visible=true. All returned HTTP 200 and the explicit JSON object containing brokerage 0. We retained each request time and response. The latest and solidified views agreed on that field for the first address during these sequential observations.

This agreement is not an independent-provider consensus test or a historical maintenance-cycle reconstruction. The reads were not pinned to a common block. A ratio observed now must not be applied retrospectively to every reward cycle simply because it is visible when the article is read.

The GetBrokerage reference defines the field as an integer from 0 to 100, with 1 representing one percentage point. Its example host is a test network. Our recorded Mainnet host is stated separately, so readers do not silently change networks while following the reference.

3. Preserve zero, missing and error as different results

Our actual brokerage ratio was explicitly0. That is stronger evidence than a response in which the field is absent. An empty object does not give our reader a number to subtract from 100. Similarly, a service Error object cannot be treated as a successful zero commission observation merely because the transport returned HTTP 200.

We tested a local strict reader with nine fixtures. Explicit integer 0,20 and100 produced candidate/voter pairs0/100,20/80 and100/0. A missing field returned an unknown result. A synthetic Error object, Boolean true, numeric string, negative integer and value above 100 were rejected locally.

Only the three recorded public responses are live observations. The remaining fixtures were invented solely to test local branches and were never sent to the network. A strict reader can prevent a reporting mistake; it does not validate the provider’s entire dataset or establish the candidate’s future policy.

Original synthetic reward-pool worksheet

Assume a hypothetical pool of 100 reward units, a 20% brokerage ratio and one voter’s applicable 25% share of the remainder. The candidate retains 20 units. The voter pool is 80 units. The hypothetical individual receives 25% of 80, which is 20 units.

We checked this with decimal arithmetic:100 × (1 −20/100) ×25/100 =20. The result is denominated in the invented pool units. It is not20% APR, an actual 20 TRX payment or a recommendation to allocate votes. No date interval or principal value was supplied that could turn this example into a return estimate.

If the individual share changes while the brokerage ratio stays constant, the individual’s calculated portion changes. If the pool size changes, the same percentages apply to a different quantity. Those two simple observations explain why a fixed ratio on a candidate page is insufficient to predict a fixed personal payout.

The worksheet also shows a frequent double-counting error. After calculating the 80-unit voter pool, do not multiply by the 80% complement a second time unless a separately defined rule requires another share. The retained amount and the voter remainder are two portions of the same assumed pool, not two independent deductions from it.

4. Match current settings to the correct reward period

The official voting-rewards guide lists several inputs beyond the candidate’s ratio, including vote shares and maintenance snapshots. A current percentage does not identify all the inputs that applied when older rewards accumulated.

For a historical question, preserve the relevant cycle and the actual data available for that period. Do not overwrite an older ratio in an evidence note with today’s read and then describe the result as historical verification. This review did not retrieve historical brokerage settings or calculate rewards across several cycles.

Claiming rewards is another distinct action. A query result is not a completed withdrawal, and a field-reader test does not increase a spendable balance. This tutorial performs only public reads and local calculations. It provides no claim transaction, candidate-settings update or wallet-signing workflow.

Repeat our read-only ratio check

1. Start with a verified public candidate identifier and record its source. Our two came from a saved witness-list sample, not a recommendation list.
2. Use the documented getBrokerage query against the intended network. Record the host, route, address representation and check time.
3. Inspect the response body as well as HTTP status. Require an explicit valid integer before deriving the voter-pool complement.
4. If comparing node views, label latest and solidified reads separately. Our one-address comparison agreed but was sequential and not block-pinned.
5. Write the denominator beside every percentage. Leave APR, an individual claim amount and a historical cycle unknown unless you have the additional evidence needed for those questions.

The success criterion is a reproducible note containing the raw brokerage ratio, the calculated pool remainder, source address, network and timestamp. Our comparison satisfies that narrow task. It does not establish a best candidate, guaranteed earnings, wallet control or the appropriateness of changing an allocation.

For broader page navigation, see our TRONSCAN beginner guide. To distinguish a queryable reward from principal, use the reward and unstaking record guide; to read a submitted candidate list, continue to the complete vote-allocation explanation. Each addresses a different record.

The Tronscan News home page organizes our independent English coverage. AI assisted preparation; primary sources, three anonymous responses and the local arithmetic were checked November 3, 2026. The diagrams and worksheet are original. We did not test wallet connection, vote submission, reward claiming or a real distribution.

Frequently asked questions

What does a brokerage ratio of0 mean in the saved response?

It explicitly reports 0% retained under that query’s field definition. The documented complement is 100% for the applicable voter pool, not an annual return.

Does 100% Voter Reward Ratio mean 100% APR?

No. It describes a pool share. An annual return estimate requires different inputs and is not supplied by this complement.

Can an empty response be treated as zero Brokerage?

Our strict reader leaves a missing field unknown. Do not replace an unavailable field or Error object with a calculated 100% voter share.

Does today’s brokerage ratio explain every older reward?

No. A historical calculation needs the relevant cycle’s settings and vote data. Our reads were current, dated observations.

Did this tutorial claim or distribute any rewards?

No. It used anonymous read-only endpoints and synthetic local calculations. No wallet or transaction was used.