Under Alpenglow, Half of Every Vote Reward Goes to the Leader

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:

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.

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

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.

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.