Originally published on xroot.dev.
Every staking dashboard shows one number next to a validator's name: commission, as a whole percent. That number has been a lie by omission for a while and is about to become a lie outright, because Solana validators now have two commissions, both set in basis points, only one of which the dashboards show — and the one they hide defaults to 100%.
Four proposals landed together to make this happen. SIMD-0123 lets a validator share block revenue — priority fees — with delegators. SIMD-0291 moves commission from whole percent to basis points. SIMD-0232 lets the validator route its cut to a collector account of its choice. SIMD-0249 replaces the old anti-rug rule for commission changes with a mandatory one-epoch delay. Here is what each one does, from the code that enforces it, and what to check on your own validator.
Where a Fee Goes Today
Start with the flow that has not changed. Every transaction pays a base fee, 5,000 lamports per signature, and optionally a priority fee. Half of the base fee is burned — a constant with a compile-time assertion that it is at most 100 — and the other half goes to the leader who produced the block. The priority fee is never burned. All of it reaches the leader.
Until now, "the leader" meant the validator's identity account, full stop. Delegators got inflation rewards minus a commission, and nothing from fees, no matter how much priority-fee revenue the validator collected in a hot epoch.
Block Revenue Sharing: The Second Commission
With block_revenue_sharing active, the leader's share of fees is split by a second commission, block_revenue_commission_bps:
validator's cut — deposit × min(bps, 10,000) ÷ 10,000
delegators' cut — the remainder, deposited into the vote account as pending delegator rewards
The rounding favours the delegator by at most one lamport. The delegators' portion accrues in the vote account and is not the validator's to withdraw; it is also, as the admission-ticket post covers, subtracted from the balance the network counts for Alpenglow admission.
Now the default. A vote account that has not been explicitly upgraded to the new state layout — and most have not — is treated as 10,000 basis points: the validator keeps 100% of block revenue. Upgrading the vote account to the new version does not change that; it has to be set. So the honest reading of a dashboard that shows "5% commission" is: 5% on inflation rewards, and, unless the validator has published otherwise, 100% on priority fees.
Worth knowing: the fee split is computed using the vote state as it was at the start of the previous epoch, because that is the state the current leader schedule was built from. A validator that lowers its block-revenue commission today will not see the lower rate applied to its blocks for roughly two epochs.
Basis Points, and the Rounding That Hides a Change
Commission used to be a single byte, 0 to 100. SIMD-0291 stores it as basis points, 0 to 10,000, which is exact for every old value (5% becomes 500 bps) and gives a validator a hundred times the resolution to move in.
The old field did not go away. For compatibility, RPC still reports a whole-percent commission, derived from the basis points by dividing by 100 and rounding up. A validator at 1 basis point shows as 1%. A validator at 501 bps shows as 6%. The truthful fields are inflationRewardsCommissionBps and blockRevenueCommissionBps, and any tool still reading the legacy byte is reading a ceiling, not a rate.
The same resolution is a place to hide. Because the legacy field rounds up, a move from 401 to 500 bps — 4.01% to 5.00%, very nearly a 25% raise — renders as 5% both before and after. A delegator watching the whole-percent number sees nothing happen.
The Raise Rule Changed: From "First Half of the Epoch" to "One Epoch Later"
The old protection against commission rugs was crude but visible: a validator could only raise commission during the first half of an epoch, so a raise never surprised delegators mid-epoch. Lowering was always allowed. That check is still in the code.
SIMD-0249 turns it off and replaces it with something stronger: any commission update, up or down, takes effect only after a full epoch delay. A raise filed today applies to the epoch after next. The reward calculation had already been using a commission frozen two epochs back — the source comment says it is "to prevent last minute commission rugs" — so the delay now matches the accounting.
For a delegator this is the useful part. A raise is visible on chain a full epoch before it costs you anything, which is about two days today and one day at 200 ms slots. That is enough time to move stake if you are watching the vote account. It is not enough if you are watching a dashboard that rounds to whole percent and refreshes weekly.
The Collector: Where the Validator's Cut Lands
SIMD-0232 adds a collector account for each commission kind. The validator's block-revenue cut no longer has to land in the identity key; it can go to a treasury, a multisig, or a DAO. The inflation collector defaults to the vote account itself and the block-revenue collector to the identity, so nothing moves unless an operator moves it.
The CLI in Agave 4.4 exposes all of it: vote-update-commission-bps with a --commission-kind of inflation-rewards or block-revenue, and vote-update-commission-collector for the destination. The same two-epoch lag applies to collector changes as to the rate.
Block Revenue Sharing: Questions People Actually Ask
Do Solana validators share priority fees with delegators?
Only if they set a block-revenue commission below 10,000 basis points. A vote account that has not been upgraded and configured defaults to 10,000, which means the validator keeps 100% of block revenue.
Why does the explorer show my validator’s commission as a whole percent?
Compatibility. The legacy field is derived from basis points by rounding up, so 1 bps shows as 1%. The truthful fields are inflationRewardsCommissionBps and blockRevenueCommissionBps.
How much notice do I get before a Solana commission raise?
One full epoch. Under SIMD-0249 any commission change takes effect an epoch after it lands, so the raise is visible on chain before it applies.
Where does the validator’s fee share go?
To its block-revenue collector account, which the operator can set to any address. The collector and rate are read from the vote state at the start of the previous epoch, so changes lag by about two epochs.
What to Check on the Validator Holding Your Stake
Three account reads answer everything above:
- Both commissions, in basis points. Read the vote account and look at the bps fields, not the rounded percent. If the block-revenue field is 10,000 or absent, you receive nothing from priority fees, whatever the dashboard says.
- Whether the vote state is the new version. A pre-v4 state cannot share block revenue at all; the default is the validator keeping everything until it is upgraded and configured.
- Pending commission changes. With the delay rule active, a raise is on chain an epoch before it applies. That epoch is your notice period; use it.
This post does not rank validators or say who shares. It says what the fields mean and where the defaults sit, which is the part the dashboards have not caught up with. The reason it matters more each year is that inflation is now decaying twice as fast — as the inflation side of validator income shrinks, the fee side is what is left.
— Four Gates, Four Different Answers —
None of this is live until its feature account says so.
block_revenue_sharing, commission_rate_in_basis_points, custom_commission_collector and delay_commission_updates are four separate gates that can be live on different clusters at different times. The upgrades tracker reads all of them from the chain every minute.
Mechanism read from the Agave validator source at commit beee69b958: runtime/src/bank/fee_distribution.rs, programs/vote/src/vote_processor.rs, rpc-client-types/src/response.rs and account-decoder/src/parse_vote.rs.
