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 make this happen, and on mainnet three are live: basis-point commissions since 16 July 2026 (epoch 1003), the one-epoch delay since 22 June 2026 (epoch 991) and custom collectors since 8 September 2026 (epoch 1031). The fourth — the block-revenue split itself — has a gate that had not activated as of 17 September 2026. 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
Once block_revenue_sharing activates — it had not on mainnet as of 17 September 2026 — the leader's share of fees is split by a second commission, block_revenue_commission_bps:
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.
The default once it activates. 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. Correction, 17 September 2026: an earlier version of this post read that default as already in force. It applies from the moment the sharing gate activates, and that gate had not activated on mainnet as of 17 September 2026.
Worth knowing: the fee split will be 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, but it has not run on mainnet since 22 June 2026.
SIMD-0249 turned it off at epoch 991, on 22 June 2026, and replaced 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 36 hours at today's 300 ms slots, 30 hours from epoch 1037 at 250 ms, 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. Correction, 17 September 2026: this read "about two days today", which was the epoch length at 400 ms slots. Mainnet has run 300 ms slots since epoch 1024, and the 250 ms gate activated at epoch 1036 and takes effect at epoch 1037.
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?
Not yet on mainnet: the sharing gate had not activated as of 17 September 2026. Once it does, 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, which is about 36 hours at today’s 300 ms slots and 30 hours from epoch 1037, when 250 ms slots take effect. 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?
Once the sharing gate activates, 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 will receive nothing from priority fees once sharing activates, 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 set to decay twice as fast — as the inflation side of validator income shrinks, the fee side is what is left. Correction, 17 September 2026: this read "is now decaying twice as fast". The double-disinflation gate, SIMD-0550, had not activated on mainnet as of 17 September 2026 either.
— Four Gates, Four Different Answers —
A gate is live only when 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. On mainnet the last three were live as of 17 September 2026 and the sharing gate was not. 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.