Build1 publisher3 min readPublished
Solana's second validator commission defaults to keeping all priority fees
Four SIMDs put commission into basis points and let validators split priority fees with delegators. The sharing is opt-in. The whole-percent field RPC still publishes rounds up, so a move of up to 99 basis points can hide behind it.
The Engineer · Build desk
What happened
- SIMD-0123 lets a Solana validator share block revenue, the priority fees from blocks it produces, with its delegators, split by a second commission field held in basis points.
- SIMD-0291 stores commission as basis points from 0 to 10,000 instead of a single byte from 0 to 100, and every old value converts exactly, so 5 percent becomes 500 basis points.
- A vote account that has not been explicitly upgraded to the new state layout counts as 10,000 basis points, so the validator keeps all block revenue. Most have not been upgraded, the post says.
- SIMD-0249 drops the rule confining raises to the first half of an epoch and requires a full epoch delay on any commission change in either direction. A raise filed today applies to the epoch after next.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Any comparison table or stake-selection tool still reading the legacy commission byte is ranking validators on a ceiling, a figure that sits above the rate any of them actually charges.
- decision A delegator picking a validator now has to read two basis-point fields and assume 100 percent on priority fees until that validator publishes otherwise.
- exposure A validator that does share block revenue puts the delegators' accrued portion beyond its own reach and out of the balance the network counts for Alpenglow admission.
- precedent Lowering commission used to take effect immediately; under the new delay a validator loses the ability to make a goodwill cut land in the current epoch.
The split is one multiply and one divide. When `block_revenue_sharing` is active, the leader's fee deposit is multiplied by min(bps, 10,000) and divided by 10,000 to get the validator's cut. The remainder is deposited into the vote account as pending delegator rewards, according to the post [10]. Rounding goes to the delegator, by at most one lamport [11]. At the 10,000 default the remainder is zero [5].
Only part of the fee gets split. A transaction pays a base fee of 5,000 lamports per signature, plus an optional priority fee [6]. Half the base fee is burned, leaving 2,500 lamports per signature for the leader [7][1]. The burn share is a constant with a compile-time assertion that it is at most 100 [7]. Priority fees are never burned, so the leader gets all of them [8]. Before this change the leader meant the validator's identity account, and delegators received inflation rewards minus commission and nothing from fees [9].
Upgrading a vote account to the new state layout does not set the block-revenue commission. The field has to be written [13].
Writing it is slow to take hold, too. The split is computed from 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 waits roughly two epochs for the lower rate to apply to its blocks [15]. One epoch is about two days at current slot times, and one day at 200 ms slots [22]. Two epochs is therefore about four days of collecting the old rate [4].
RPC still derives the legacy commission field by dividing basis points by 100 and rounding up [17]. One basis point, a rate of 0.01 percent, reports as 1 percent, a hundred times the real rate [3]. Move from 401 to 500 basis points and the legacy field shows 5 percent on both sides of a 24.7 percent increase in what the validator charges [18][2]. Two fields escape the rounding: `inflationRewardsCommissionBps` and `blockRevenueCommissionBps` [17].
The delay in SIMD-0249 replaces a cruder rule that is still in the code: raises were only permitted during the first half of an epoch, and lowering was always allowed [19]. The reward calculation had already been using a commission frozen two epochs back, and the source comment says it is "to prevent last minute commission rugs" [21].
SIMD-0232 lets a validator route its own cut to a collector account of its choice, so the identity account is no longer the only destination [4].
All of this is one write-up's reading of the code, published on dev.to and originally on xroot.dev [23], and it does not say when the `block_revenue_sharing` feature gate activates on mainnet [24]. The default matters in proportion to a validator's priority-fee revenue.
What to watch
- Whether staking dashboards add blockRevenueCommissionBps as its own column or keep publishing the rounded legacy percent.
- The first validators to set block-revenue commission below 10,000 basis points and advertise it to attract stake.
- An announced activation epoch for the block_revenue_sharing feature gate on mainnet.