Originally published on xroot.dev.
The post on validator commissions covered how a validator's cut is set. This is the next chapter, and it is less discussed than the commission changes because it is buried in consensus code rather than in a vote-account field.
The alpenglow feature gate had not activated on mainnet as of 17 September 2026, so a validator still earns vote rewards by landing vote transactions, one per slot, paying a fee for each. Under Alpenglow there are no vote transactions. Votes are signed messages between validators, and the reward for a vote is paid only when a later leader certifies it — and when it is paid, half goes to that leader.
This post is the reward pipeline as the validator implements it, with the constants, and what it does to the income of a validator and the delegators behind it.
The Per-Slot Reward, and Who Gets Which Half
The validator computes each slot's inflation reward for a voting validator as:
reward — epoch reward budget × validator's stake ÷ (slots per epoch × total stake)
validator reward — reward ÷ 2
leader reward — reward − validator reward
The voter keeps half. The leader of the slot that certified the vote keeps the other half, and any odd lamport rounds to the leader. Across an epoch a validator's income is therefore half of its own votes plus half of everyone's votes during the slots it led — and the second half scales with how often it leads, which scales with stake.
Worth knowing: the pre-Alpenglow system running on mainnet today has a cruder rounding rule. When a vote reward splits between a validator and its delegators and either side would round to zero, the legacy code skips the reward entirely and does not advance the credits counter. Alpenglow's split hands the residual lamport to the voter instead. Small validators on the old system have been losing rounding dust for years; the new one stops that.
You Are Paid Only If the Leader Eight Slots Later Says So
A vote is not rewarded when it is cast. It is rewarded when it appears in a reward certificate, and reward certificates are built by the leader of the slot eight slots after the one you voted in. The leader of slot N assembles the certificates for slot N − 8 from the votes it has received, and ships its block whether or not those certificates are complete — the code uses a non-blocking request with a small queue rather than waiting.
Two things follow for a validator's income:
- Your vote has to reach the right leader in time. Not the current leader — the one eight slots ahead. A validator whose votes propagate slowly, or whose connection to upcoming leaders is poor, votes correctly and is not paid.
- The leader has discretion of a kind. It certifies the votes it has. It cannot invent votes, but a vote that arrives late is simply absent from the certificate and earns nothing. There is no appeal.
The votes themselves travel over a dedicated QUIC transport between validators, not through the transaction pipeline, so the fee that used to accompany every vote transaction disappears with it. Under Alpenglow the cost of voting is bandwidth, and the reward for voting depends on latency to leaders.
The Epoch Budget Is Fixed On Chain Before the Epoch Starts
The pool of SOL to be paid as vote rewards is computed at the start of the epoch and written into an on-chain account — a program-derived address under the Alpenglow program that stores the current and previous epoch's state. Every slot's payout draws from that fixed budget by the formula above. Nothing a validator does during the epoch changes the size of the pot; it only changes their share.
After the migration the vote account's historical "epoch credits" field stops counting votes and starts counting reward lamports. The runtime pushes a sentinel row at the migration epoch to mark the change. Any tool that reads epoch credits as a performance metric will see a nonsense value at the boundary and lamports afterwards — a silent unit change that every staking dashboard will have to handle.
The Admission Filter Runs Twice
The post on the 2,000-seat cap covers who gets to vote. The same filter runs again at reward time: a vote account that fails the admission test — no BLS key, zero stake, balance below rent plus one epoch's ticket after subtracting pending delegator rewards — is excluded from reward distribution as well as from consensus. For a delegator this compounds: a validator that slips out of the set does not just stop voting, it stops earning for the epoch, and so do you.
What This Does to Delegator Income
Your validator's inflation income becomes two streams: half of its own vote rewards, and half of the vote rewards of every validator during its leader slots. Both are then subject to the inflation commission it charges you. A validator with more stake leads more often and collects more of the second stream — the reward curve bends further toward large validators than it does today.
Connectivity becomes yield. Two validators with identical stake and commission will earn differently if one reaches the next leaders faster. The metric that predicts it — how quickly a validator's votes are certified — is measurable from the ledger after activation, and it is the metric a careful delegator should ask for.
The commission fields do not change. The two-commission post still applies; this post changes the size of the number the commission is taken from.
Alpenglow Rewards: Questions People Actually Ask
How are Solana validators paid under Alpenglow?
Each slot’s inflation reward for a voter is split in half: the voter keeps one half and the leader who certifies the vote keeps the other. Votes are no longer transactions, so there is no vote fee.
When is a vote rewarded under Alpenglow?
When it appears in a reward certificate built by the leader of the slot eight slots later. A vote that reaches that leader late is not certified and earns nothing.
Do delegators earn less under Alpenglow?
Your validator’s income becomes half of its own votes plus half of everyone’s votes during its leader slots, still minus its inflation commission. Larger validators lead more often and collect more of the second stream.
What happens to the epoch credits field after the Alpenglow migration?
It accumulates reward lamports instead of vote credits, with a sentinel row at the boundary. Tools reading it as a performance score will need updating.
What to Watch After Activation
- If you delegate: the share of your validator's votes that actually appear in reward certificates. A validator that votes and is not certified is invisible in a commission table and visible in its reward account.
- If you operate: your latency to upcoming leaders, not to the network in general. Under this reward rule, peering is revenue.
- Everyone: the epoch-credits field changes units at the migration. Until dashboards catch up, read reward lamports from the vote account directly.
— Not Live on Mainnet as of Sep 17, 2026 —
The alpenglow feature account was still inactive on 17 September 2026, and it flips at an epoch boundary.
The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state per cluster. The timers and certificates that decide when a vote counts at all are in Alpenglow Finality in Numbers.
Open the Upgrades Tracker ↗Read the finality post
Constants read from the Agave validator source at commit beee69b958: runtime/src/block_component_processor/vote_reward.rs, votor-messages/src/reward_certificate.rs and core/src/certs_requestor.rs. The 50/50 split is a constant in that source — re-read it before depending on the ratio.
