Originally published on xroot.dev.
Solana has around 1,300 validators voting today, give or take the epoch, and the number has never mattered much to a delegator. You picked one, you delegated, it voted, you earned. Under Alpenglow the number matters a great deal, because the protocol caps the consensus set at exactly 2,000 vote accounts — and the way it fills those seats has two rules that will surprise people the first time they bite.
The rules are not in a blog post from the Foundation. They are in a filter function in the validator, and this post reads it line by line. If you delegate SOL, it decides whether your validator earns anything at all next epoch. If you run one, it decides whether you are in the room.
Four Ways to Lose a Seat
The validator builds the admitted set once per epoch by filtering every vote account and keeping the top 2,000 by stake. To survive the filter a vote account needs, in this order:
- A BLS public key in the vote state. Alpenglow votes are BLS signatures, so a vote account without one cannot vote and is dropped before stake is even considered. This is the check most likely to catch a validator that upgraded the binary and forgot the key.
- Non-zero delegated stake.
- A sufficient vote account balance that, after subtracting accrued delegator rewards, still covers the rent-exempt minimum for the 3,762-byte vote state plus one epoch's admission ticket. The subtraction was added on 3 September 2026. Delegator rewards that have accrued in the vote account are part of its lamport balance but not the validator's to spend, so the node refuses to count them.
- A stake strictly above the cut-off. The filter sorts, truncates at 2,000, and then removes every account whose stake merely equals the last admitted one. The code is one line: keep only stakes greater than the floor. If three validators tie at position 2,000, all three are out, and the admitted set is 1,997.
That last rule is the one to remember. A single lamport of stake above a neighbour is a real defence, and a single lamport below is a real eviction.
The Ticket: 1.6 SOL an Epoch, Burned
Every admitted vote account pays a Validator Admission Ticket at the epoch boundary. The amount is a table in the source, keyed to the slot time:
400 ms slots (today) — 1.6 SOL per epoch
350 ms — 1.4 SOL
300 ms — 1.2 SOL
250 ms — 1.0 SOL
200 ms — 0.8 SOL
The per-epoch figure falls as slots get faster because epochs get shorter; per year it is the same by construction — 1.6 SOL × 182.6 epochs equals 0.8 SOL × 365.2 epochs, about 292 SOL per validator per year. Across a full set of 2,000 seats that is roughly 3,200 SOL burned every epoch, or in the region of 584,000 SOL a year at today's slot time.
Since 9 September 2026 the debit shows up in block reward data as its own reward type, so explorers and tax tools will see a negative line item on every admitted vote account once the gate is live. Genesis pre-funds each bootstrap vote account with 100 epochs of tickets — 160 SOL — which is a fair guide to how much runway an operator should keep on hand.
The Minimum Balance, in One Line
The node's admission test, spelled out:
Admitted when — lamports − pending delegator rewards ≥ rent-exempt minimum for 3,762 bytes + one epoch's ticket
At the mainnet rent rate in force after the second SIMD-0437 step — 5,080 lamports per byte — the rent-exempt minimum for a vote account is about 0.02 SOL, so the bar sits at roughly 1.62 SOL before the pending-rewards subtraction. That subtraction is the trap: a validator that shares block revenue with delegators accumulates those rewards in the same account, and a balance that looks comfortable at 3 SOL can fail the test if 1.5 SOL of it belongs to delegators.
The failure is not gentle. The filter runs twice — once for consensus admission and once for reward distribution — so an account that misses the balance test misses the epoch's stake rewards as well. For a delegator, that reads as a zero-reward epoch with no warning from the validator's dashboard.
The Tools That Will Tell You, and the One That Will Not
The validator exposes its own verdict. The admin RPC method validatorAdmissionTicketStatus reports eligibility two epochs ahead, with exactly three failure reasons: vote account not found, no BLS pubkey, insufficient funds in the vote account. An operator who checks it every epoch will not be surprised.
The reference monitoring tool will not help as much as it should. The watchtower's balance check computes rent plus ticket but omits the pending-delegator-rewards subtraction, so it reports "healthy" on a vote account the node itself is about to reject. If you monitor with it, subtract the pending rewards yourself.
For a delegator there is no official tool at all. What you can compute from public data: your validator's stake rank, its margin over the 2,000th place, whether its vote account carries a BLS key, and its balance against the bar above. Every input is a plain account read.
Who This Actually Squeezes
Two groups sit on the wrong side of these rules.
- Small validators near the cut-off. Today a validator with a few thousand SOL of delegation votes like any other. Under the cap, stake rank is admission, and the strict-greater rule means the boundary is not a threshold but a cliff with a tie-breaker that favours nobody. Expect validators near position 2,000 to court delegations aggressively in the weeks before activation, and expect the cut-off stake itself to become a number people watch.
- Validators that share revenue. The pending-rewards subtraction penalises exactly the behaviour delegators want. A validator paying delegators a cut of priority fees has to keep proportionally more of its own SOL in the vote account to stay admitted. That is a fair cost, but it is an unadvertised one.
The honest limit of this post: it says nothing about which validators will be in or out, because that depends on delegations that move every epoch. The rules are fixed; the ranking is not.
Validator Admission: Questions People Actually Ask
How many validators can vote under Alpenglow?
At most 2,000 vote accounts, ranked by stake. Every account tied with the last admitted one is removed too, so the admitted set can be smaller than 2,000.
What does a validator need to be admitted under Alpenglow?
A BLS public key in its vote account, non-zero stake, a balance that covers rent plus one epoch’s ticket after subtracting accrued delegator rewards, and a stake strictly above the cut-off.
How much is the Solana validator admission ticket?
1.6 SOL per epoch at 400 ms slots, falling to 0.8 SOL at 200 ms. Per year it is about 292 SOL per validator either way; across 2,000 seats roughly 584,000 SOL a year is burned.
What happens to my stake if my validator loses its seat?
It earns nothing that epoch. The same filter gates both consensus and reward distribution, and there is no on-chain notice to delegators before the boundary.
The Two Numbers to Know Before It Goes Live
If you delegate, know your validator's margin over the cut-off in SOL and whether its vote account holds a BLS key. Either one failing costs you an epoch of rewards with no on-chain notice.
If you operate, know your vote account balance after subtracting pending delegator rewards, and keep more than one epoch of tickets in it. The genesis default of 100 epochs is generous; three is the least that survives a missed alert.
— One Feature Account Starts All of This —
The gate activates at an epoch boundary. Watch the account, not the news.
The upgrades tracker reads the feature-gate accounts from the chain every minute and shows the state per cluster. The day the Alpenglow gate flips on mainnet, the 2,000th-place stake becomes the most consequential number in Solana staking.
The consensus side of the same upgrade — the certificates, the timers and what "final" will mean — is in Alpenglow Finality in Numbers.
Constants read from the Agave validator source at commit beee69b958: runtime/src/bank.rs, vote/src/vote_account.rs, runtime/src/slot_params.rs and validator/src/admin_rpc_service.rs. The rent figure uses the 5,080 lamports-per-byte rate live on mainnet at the time of writing.
