Alpenglow and your validator: what you must do, and what JPool handles

Contents

The VAT fee: the one recurring thing you must act on

Under TowerBFT, your validator voted by sending transactions, about one per slot, roughly 2 SOL of fees per epoch paid from your identity account. Under Alpenglow votes are not transactions, so that cost is gone. The Validator Admission Ticket takes its place: a flat fee taken from your vote account each epoch and burned, 0.8 SOL at mainnet's current slot time. Voting now costs well under half of what it did. The fee can change if the slot time changes, so treat 0.8 SOL as today's value, not a fixed constant. What changed is the form and the account, which is why the old habit of funding the identity account now leaves you short.

Every epoch, keep at least 0.8 SOL in the vote account above its rent-exempt minimum, the small permanent balance every Solana account holds to stay alive, about 0.82 SOL in total today. The 0.8 SOL VAT fee sits on top of that minimum, so funding exactly 0.8 SOL leaves you short. The fee is paid one epoch ahead: the charge at the start of epoch E buys admission to E+1, and the first was charged at the start of 1064. If you are short when admission is checked, commission paid at that same boundary comes too late. The fee is charged only to the vote account, never the identity account. If you withdraw from the vote account, leave the next fee behind. Miss it and your validator is not admitted for the next epoch: no votes, no blocks, and no rewards from the epoch just ended or the one you cannot vote in.

Don't want to waste time on topping up the vote account manually? Point your block-revenue commission collector at the vote account (SIMD-0232, vote-update-commission-collector) and it refills itself from block income. A few conditions decide whether you can rely on it. The switch takes two epochs to kick in, so it won't cover your next two fees, and it cannot rescue an account that is already short. After that, block income lands in the vote account block by block and counts at the next check, so it is not held back by boundary timing the way inflation commission is. Its real limit is size: it only keeps you funded if your block income clears 0.8 SOL an epoch. A validator that draws little leader revenue can still come up short, so watch the balance instead of trusting the refill. Pay the first two fees yourself, keep a few epochs of runway, and let the collector handle the rest.

If a JPool member is ever not admitted, its bond covers the delegators. The bond pays the delegators for the rewards they lose across both epochs the miss touches: the epoch that just ended, whose rewards the network holds back, and the next one, which the validator cannot vote in. Your stake stays while the bond still secures it, and it is never pulled for the miss: a pull cannot save the epoch you are out of, and it would end the bond's payment for it. While you are out of the next epoch's vote set you receive no new stake, direct stake included. If the bond cannot cover both lost epochs, your stake is drained to the pool minimum rather than removed. A second refusal in a row removes you. The bond makes your delegators whole on the money, but the missed epoch still counts as downtime in your performance window, so even a covered miss can cost you a slot.

JPool steps in before the money is lost. The keeper sends the JPool team up to two alerts an epoch, each only if someone is short: at the start, any validators running low on fees, and in the final hours, any the next boundary will turn away. The team contacts the operator in time to act, not after.

Why your realized APY now swings with leader slots

Under Alpenglow, each vote reward is split evenly between the voter and the leader of the block that carries the vote. Leaders work in fixed windows of four slots. How many windows your validator gets in an epoch depends on your stake: more stake means more windows, on average. But the exact count moves up and down from one epoch to the next. In a single epoch, one validator can get more windows than another with the same stake, just from how the slots fell. The one with more windows earns more that epoch, the one with fewer earns less, and the gap comes from the slot count, not from how well either validator ran. Because the swings go both ways, they cancel out over many epochs, and your rewards end up close to what your stake share alone would earn. In a single epoch they don't cancel, so both the operator and its delegators earn a little more or a little less.

Before Alpenglow, your inflation yield changed only with things you controlled: uptime, commission, how well you voted. Now it also moves with how many leader slots you drew, as your MEV tips always did. The even split is fixed and public, so nothing is hidden in how each reward divides; what differs between validators is how many leader slots each one drew, and JPool measures that directly from chain data.

In a single epoch, JPool's measurements put the swing at tens of basis points of APY for a mid-sized validator, and more for a small one, where one extra or missing leader slot is a bigger share of its total. Two validators with the same uptime, commission, and skill can therefore post clearly different yields in the same epoch. Ranking or billing on realized APY alone would reward and punish validators for their slot draws.

How JPool ranks you, and what it bills you: expected yield, not the draw

JPool scores your expected yield instead of the realized one. It recalculates the leader share of your reward using the slots your stake should get, at your own block-production rate. Skipped slots still count against you, because your production rate is something you control. The one thing it drops is which slots you happened to draw. MEV is counted through your MEV commission, not the tips you happened to collect, so swings in tips stay out of your score too.

MEV counts in the ranking, the benchmark, and the bond, so a validator on plain Agave with no Jito tip distribution account, or one that collected nothing, earns zero MEV yield for any epoch it draws eight or more leader slots. To earn MEV credit, run a client that opens a Jito tip distribution account, such as Jito-Solana. Stake timing matters too: an epoch's reward is earned on the previous epoch's stake but paid out over the current one, so when your stake jumps your delegators see a lower rate for one epoch, and a higher one when stake leaves. JPool scores, benchmarks, and bills on the stake the reward was earned on, so its own delegation does not mark your yield down for the swing it causes.

Billing is handled even more carefully than ranking, because charging someone always sets a higher bar than ranking them. Once you remove the effect of which slots you drew, you don't get one exact number. You get a range we can prove: a floor and a ceiling on what your yield would have been without the slot-count swing. JPool does not pick a single point in that range and bill against it. It uses both ends directly.

JPool reads those ranges in the direction that favors you. Your own yield is taken at its high end, your best case. The benchmark is taken at the low end of each of the top 30 validators you are measured against, averaged into their collective worst case. You are billed only when even your best case comes in below that benchmark. That test is deliberately hard to trip: your best case is already the highest your yield could have been once the slot draw is removed, so if even it falls short of the benchmark, the gap is not a low slot count but real underperformance, and that is what the bill covers. If your best case reaches the benchmark, you pay nothing, because the whole gap could come from slot count alone. Even a best case below the benchmark is billed only if you also lag over the longer window the benchmark uses, not on a single epoch alone.

A quick example. For the epoch, the benchmark comes out at 5.1 percent. Your yield is measured at 4.8 percent. Set the slot count aside and a range of 4.6 to 5.0 percent remains: the least and the most you could have earned once slot count is no longer in play. JPool bills at the top of that range, your best case of 5.0 percent. Even there you fall under 5.1, so the 0.1-point gap cannot come from slot count, and if you also lag over the longer benchmark window the bond covers it: up to about 0.29 SOL for the epoch on 100,000 SOL of delegated stake. A second validator measures 5.0 percent, with a range of 4.8 to 5.2 percent. Its best case, 5.2 percent, clears the benchmark, so its whole shortfall could be slot count alone, and it is billed nothing. Both headline yields landed under the benchmark. Only the one whose best case was still short got a bill.

And when the numbers are not there to do this safely, JPool bills nothing rather than guess. If it cannot work out a usable range for you, you are simply not billed a yield gap for that run. If a whole run has fewer than 30 validators to build the benchmark from, it charges no yield gap at all and alerts the team instead.

One more thing works on this same expected basis. Both your yield and the benchmark are measured after commission, so JPool aims for an effective 0 percent commission for delegators. A validator charging 5 to 7 percent, below the 10 percent cap, is still billed for the gap that commission opens against the top validators' after-commission yield. Above 10 percent the hard cap applies: the validator's pool stake goes to zero and the excess is billed on top.

A staged switch, nothing for you to deploy

On JPool's side, the switch to expected yield needed no deploy, and each switch is tied to the epoch when Alpenglow's on-chain switch actually turned on, which JPool reads fresh from the chain on each run. You had nothing to ship or flip at the deadline. If that switch had been delayed, JPool's changes would have waited with it. The transitions land in order, and the schedule is enforced in code rather than by hand.

At epoch 1064, the performance ranking, the benchmark, and the performance bond all move to expected yield together, and the bond begins billing between its bounds. At 1065, JPool starts reading a vote account's credits as the previous epoch's reward rather than a vote count, the meaning they took on at the 1064 handoff. A reward jumps around far more than a vote count does, so the old cutoffs that read those credits are switched off until JPool can reset them on real mainnet data. No validator is dropped by a limit built for the old kind of number. At 1066 the performance ranking starts measuring yield over the same longer stretch the benchmark already uses, instead of just the last ten epochs. If the on-chain switch or the admission record is unreadable on a run, nothing guesses and the previous allocation stands; if the expected-yield feed is unhealthy, the run falls back to realized yield and bills no yield gap; if credits are unreadable, the credit cutoffs switch off for that run. The keeper has run the pool live since 18 October 2026 and was checked across real epoch boundaries before the switch.

What JPool is still watching

Two questions can only be settled once mainnet has run under Alpenglow for a stretch of epochs. The first is whether mainnet's leader-slot variance behaves as it did on testnet, where the expected-yield correction removed almost all of it. JPool logs a leader-luck check for every finalized epoch, and with 1064 onward now on the books it is working through what those first clean readings show. The second is the set of reward-based credit thresholds, which stay off until there is enough mainnet data to recalibrate them rather than being set on a guess.

One boundary's forfeited epoch cannot be billed. The runtime only starts recording who it paid from the migration epoch onward, so a missed admission at the 1064 boundary forfeits the epoch that just ended, 1063, with no payment record to bill against. The epoch then sat out is still billed as downtime. The first boundary whose forfeited epoch JPool can bill is 1065. From there it watches the two open questions above and will reset the credit thresholds once the data is in.