Solana's validator admission ticket: what a missing BLS key costs
Since the first slot of epoch 1006, Solana builds its leader schedule and inflation reward distribution only from validators that have registered a BLS public key. A validator with no registered key gets no leader slots and no inflation rewards, and the stake delegated to it earns nothing either.
At the first slot of epoch 1006, around 23 July 2026, Solana began building its leader schedule and its inflation reward distribution only from validators that have registered a BLS public key on their vote account. A validator without one now gets zero leader slots and zero inflation rewards, and the stake delegated to it earns nothing either.
As of epoch 1008, 21 of 707 mainnet validators are still keyless. All 102 validators in Marinade's delegation set are registered.
SIMD-0357 rewrites how validators pay for consensus.
Almost none of that is live yet. What activated at epoch 1006 is an eligibility check, nothing more.
What the admission ticket requires
Four feature gates got the network here, in order.
| Feature gate | SIMD | What it does | Activated |
|---|---|---|---|
vote_state_v4 | SIMD-0185 | The VoteStateV4 vote-account layout | Slot 409,968,000, epoch 949 |
enable_bls12_381_syscall | SIMD-0388 | BLS12-381 syscalls | Epoch 986 |
bls_pubkey_management_in_vote_account | SIMD-0387 | Lets an operator register a BLS public key on the vote account | Slot 431,568,000, epoch 999 |
validator_admission_ticket | SIMD-0357 | The gate that requires one | Slot 434,592,000, first slot of epoch 1006 |
Registration came from SIMD-0387; SIMD-0357 made it a condition of participation. The two get conflated easily, helped along by a stale cross-reference inside SIMD-0387 that mis-titles 0357 as a BLS key requirement. The field was settable for seven epochs before anything depended on it, which is why the change caught operators by surprise.
The funnel above is SIMD-0357 in full, once Alpenglow consensus is live. Today only the eligibility filter runs: the ticket is not charged, and an excluded validator keeps voting rather than falling silent.
In agave 4.1.x, the client mainnet runs, that filter is VoteAccounts::clone_and_filter_for_vat. What survives becomes epoch_stakes, read for both the leader schedule and the reward snapshot. Both call sites are gated on validator_admission_ticket alone, which is why enforcement did not wait for Alpenglow.
The 1.6 SOL charge is verified as not collected: the path that would collect it requires both alpenglow and validator_admission_ticket, and alpenglow is not active. 252 validators in the epoch 1008 leader schedule hold under 1.7 SOL in their vote account, which a live charge would rule out.
What happens to a validator without a key
No leader slots. Epoch 1008's leader schedule contains 664 identities and not one is keyless. The smallest stake in it is 53 SOL, so size is not what excluded them. None of the 21 held a slot in epoch 1007 or 1008, yet all of them did in 1006, whose schedule was computed before the gate.
No inflation rewards, for operator or stakers. On a keyless validator with 274,615 SOL of stake and 8% commission, commission rewards ran 6.64, 6.66 and 6.64 SOL across epochs 1002 to 1004, then stopped. For 1005, 1006 and 1007 there is no reward record at all, which is different from a record showing 0.000. A stake account with 101,928 SOL delegated to it was paid 28.41 then 28.36 SOL, then nothing, while a comparable account on a registered validator kept being paid through 1007.
Stakers absorb this too
This lands on every stake account delegated to that vote account. Nothing about those accounts is wrong. They earn nothing while the validator stays keyless.
Vote credits fall too, by a longer route
Median epoch vote credits, keyless against registered:
| Epoch | Keyless median | Registered median | Ratio | Gate active |
|---|---|---|---|---|
| 1004 | 6,891,160 | 6,891,183 | 100.00% | no |
| 1005 | 6,898,000 | 6,897,988 | 100.00% | no |
| 1006 | 4,840,827 | 6,888,894 | 70.27% | yes |
| 1007 | 4,834,536 | 6,904,531 | 70.02% | yes |
| 1008 | 2,810,530 | 4,025,909 | 69.81% | yes |
Both 1008 medians are lower because that epoch was still running at the snapshot. Registered controls tracked individually held 99.7% to 99.9% of the maximum across all five epochs, so the shortfall is specific to the keyless cohort.
The cause sits downstream of the same filter. StakedNodesUpdaterService builds the stake-weighted table leaders use to prioritize incoming transactions from that filtered set, so a keyless validator became an unstaked peer at the boundary, its votes are admitted late or not at all, and under timely vote credits (SIMD-0033) a later vote pays less. Credits land at roughly 70% of the registered median. Keyless validators do keep voting, rather than going delinquent. Public communication implied they would be dropped from consensus entirely. That is not what happens today.
Where the inference sits
The deprioritization is in the code. Why the shortfall settles near a consistent 70% is inference: leader implementations differ in how they treat an unstaked peer's vote traffic.
Where the cluster stands
Measured 2026-07-28 at 08:19 UTC, slot 435,707,691, during epoch 1008.
- 707 validators, 686 registered, 21 without a key. 97.03% coverage by count.
- 428,718,803 SOL of active stake, 99.7645% of it on registered validators. The 21 keyless validators hold 1,009,833 SOL, or 0.2355%.
- Of those 21, 15 are actively voting and 6 are delinquent.
- Marinade's delegation set: 102 of 102 registered, covering 6,282,295 SOL, and 100% coverage on each product.
Checking this needs raw account data
The getVoteAccounts RPC method does not expose the BLS field. Confirming whether a validator is registered means fetching the vote account and parsing the raw VoteStateV4 data.
What Marinade did
Anza's notice landed on 17 July 2026. Marinade checked its whole delegation set the same day and found validators holding 2.34M SOL of Marinade stake, 36.5% of the delegated book, with no key registered. Marinade's own validator already had a key set.
Marinade did not start from a cleaner position than the cluster: on 22 July about 2.5% of its stake still sat on keyless validators, against 0.75% of network stake. What it can claim is that the exposure reached zero before the boundary.
| Check | Marinade stake on keyless validators |
|---|---|
| 17 July | 2.34M SOL |
| 21 July, morning | ~462,000 SOL |
| 21 July, afternoon | ~278,000 SOL |
| 22 July, one hour before the gate | ~158,000 SOL |
Marinade posted the requirement in Discord and messaged operators directly, repeatedly. 30 registered inside those five days.
Two operators had not registered by the deadline, so Marinade moved 100% of its stake off both, about 144,000 SOL, timing deactivation so the stake went fully inactive exactly at the 1006 boundary. Residual exposure after the gate was about 2.58 SOL.
On 24 July a standing eligibility exclusion merged, covering 33 vote accounts network-wide that held 2.11M SOL, 0.49% of active stake at the time. It re-applies on every auction run, so the auction cannot delegate to a keyless validator without manual intervention.
note
The exclusion is an eligibility requirement, not a sanction. A missing BLS key is a configuration gap, not misconduct, and entries come off as soon as an operator registers.
What to do now
That split arrives with Alpenglow. Today vote fees still come from the identity account.
If you run a validator, fetch your vote account and confirm a BLS public key is set. A healthy dashboard is not evidence.
If you delegate to a single validator, check your stake account's reward history. A missing reward record for a recent epoch is the signal, not a zero one. Ask your operator whether a BLS key is registered.
Recovery is fast, and partial. Eligibility returns on its own at the next epoch boundary, as 19 late registrants showed: back to roughly 100% of the registered credit median, leader slots regained. Part of the missed inflation returns with them. Measured against Marinade's ledger records of mainnet stake rewards, the first payout after registering runs about 2.2 to 2.4 times the pre-gate baseline. One validator with about 144,000 SOL delegated to it was paid 104.0 SOL for epoch 1007 against a 43.7 SOL baseline, on unchanged stake, and four other late registrants match that ratio. The mechanism is credits_observed: a keyless validator keeps accruing partial vote credits, which convert into rewards once it is admitted again. Leader slots accrue no such counter, which is why the block rewards attached to them stay lost.
If you stake through Marinade, the delegation set was fully registered as of epoch 1008 and the auction screens out keyless vote accounts on every run.
The path to Alpenglow
Mainnet still runs TowerBFT across 4,055 nodes. The alpenglow feature gate, SIMD-0326, has no feature account on mainnet at all: not activated, not staged. It covers Votor, the voting half of the consensus rewrite; the propagation half, Rotor, gets its own proposal later. How Solana propagates blocks today covers what Turbine does now and what Rotor would change.
The admission ticket is groundwork for Alpenglow consensus, and enforcement of the ticket did not wait for Alpenglow to activate. That is the part operators missed.
Sources: Agave feature-set crate (feature gate names and activation slots), Agave bank.rs, Agave vote_account.rs and Agave staked_nodes_updater_service.rs in agave v4.1.0 (the filter path), Solana mainnet feature accounts and raw VoteStateV4 vote-account data for epochs 1002 to 1008 read 2026-07-28, SIMD-0326, Marinade delegation and auction records for epochs 1006 to 1008, Marinade's mainnet_beta_stakes BigQuery dataset (Marinade's record of mainnet stake and reward data, network-wide).
