BLS Pubkey and the Validator Admission Ticket

BLS Pubkey and the Validator Admission Ticket

Updated October 2026 • Solana Foundation

Solana mainnet validators register a BLS pubkey on-chain, the cryptographic prerequisite for Alpenglow consensus. The feature gate that enables this (SIMD-0387) activated on mainnet on July 8, 2026. The Validator Admission Ticket (SIMD-0357, VAT), which enforces the requirement, activated on mainnet on July 22, 2026: any validator without a registered BLS pubkey now stops participating in consensus.

The VAT feature activation did not turn on Alpenglow itself. Until Alpenglow, VAT only gated admission into the validator set based on the existence of the BLS pubkey. Alpenglow's consensus switch landed separately in Agave 4.3, at epoch 1064 on October 21, 2026, and with it the complete VAT feature took effect. Validators now have 0.8 SOL deducted from their vote account at the start of each epoch. Votes are no longer onchain transactions, so there are no longer fees for voting.

Keep at least 0.8 SOL in your vote account, above its rent-exempt minimum. If the fee is not paid, your validator does not vote or produce blocks in the next epoch. See what validators need now.

Technical Details

What a BLS Pubkey Is, and Why Alpenglow Needs One

Under TowerBFT, Solana validators voted using ed25519 signatures, verified one at a time. Alpenglow's voting algorithm, Votor, needs to combine thousands of individual validator votes into a single succinct certificate rather than verifying each vote independently. BLS (Boneh–Lynn–Shacham) signatures support this kind of aggregation: many BLS signatures over the same message can be combined into one aggregate signature that still proves every contributing validator voted. Ed25519 does not support this, which is why Alpenglow requires a separate BLS keypair for each validator rather than reusing the existing vote-account identity.

Registering Your BLS Pubkey On-Chain

Registering a BLS pubkey requires the Solana CLI version 4.1.0 or higher. The registration flow, documented in Anza's vote account guide, runs through the CLI:

# Derive the BLS pubkey from your authorized voter keypair
solana-keygen bls_pubkey <AUTHORIZED_VOTER_KEYPAIR>

# Register it on-chain against your vote account
solana vote-authorize-voter-checked <VOTE_ACCOUNT> <AUTHORIZED_VOTER_KEYPAIR> <AUTHORIZED_VOTER_KEYPAIR>

# Confirm it took effect
solana vote-account <VOTE_ACCOUNT> | grep "BLS Public Key"

Under the hood, this submits a new VoterWithBLS vote-authorization variant that carries both the 48-byte compressed BLS pubkey and a 96-byte proof of possession. The proof of possession signs a domain-separated message binding the vote account to the BLS key, which stops an attacker from registering a rogue key that could interfere with aggregate signature verification. This means updating a BLS pubkey does not require changing your authorized voter — it is a distinct, additive registration.

The Validator Admission Ticket (VAT)

VAT is a separate feature gate that changes how validators are admitted into the active set each epoch. The VAT feature has two states: before Alpenglow was enabled and after.

VAT Before Alpenglow

From July 22, 2026 until Alpenglow activated, the VAT feature gate required that all voting validators have a BLS pubkey registered and enforced a limit of 2,000 validators. TowerBFT remained in effect, so votes were still transactions that landed on-chain, and voting validators were still charged about 1 SOL per epoch in aggregate voting costs.

VAT After Alpenglow

Since Alpenglow activated in epoch 1064, every voting validator included for the next epoch is charged a flat 0.8 SOL fee per epoch, burned directly to the incinerator rather than redistributed to block proposers as transaction fees are. That figure is intentionally close to the old voting costs (roughly 1 SOL per epoch).

The fee is taken from the vote account, not the identity account that paid vote transaction fees under TowerBFT, and the 0.8 SOL is in addition to the vote account's rent-exempt minimum. The fee is paid one epoch ahead: the first charge, at the start of epoch 1064, paid for participation in epoch 1065. If the vote account cannot pay it, the validator is not admitted for the next epoch and does not vote or produce blocks. The fee is charged every epoch, so the balance has to stay funded, not be funded once. Routing block revenue to the vote account can do that automatically; see Fund the VAT with commission revenue.

What Happens Now That VAT Is Active

With the VAT feature gate and Alpenglow live on mainnet:

• Validators without a registered BLS pubkey are excluded from the admitted set and stop voting — they do not participate in consensus and stop earning inflation rewards.
• Validators with a BLS pubkey registered but outside the top 2,000 by stake are excluded from the admitted set for that epoch.
• Each admitted validator pays the 0.8 SOL VAT fee from its vote account at the start of every epoch for the next one.
• VAT itself did not turn on Alpenglow consensus. SIMD-0326 - Alpenglow: new consensus algorithm activated on mainnet separately, in epoch 1064, which started on October 21, 2026, at approximately 13:36 UTC. See When Alpenglow Activated on Mainnet.

If your voting validator does not yet have a BLS pubkey registered, it is already losing consensus participation and inflation rewards — register immediately using the steps above.

What Validators Need Now That Alpenglow Is Live

Registering a BLS pubkey is not the only requirement. Since Alpenglow activated in epoch 1064 (October 21, 2026, approximately 13:36 UTC), validator operators must also:

1. Run an Agave-based client: v4.3.2 of Agave, Jito-Solana, or Harmonic Salsa. Firedancer and Frankendancer were not supported for the migration.
2. Hold at least 0.8 SOL in the vote account, above its rent-exempt minimum, to pay the VAT fee. Check it with solana balance <VOTE_ACCOUNT_ADDRESS>, top it up with solana transfer <VOTE_ACCOUNT_ADDRESS> <AMOUNT>, and leave enough behind for the next fee whenever you withdraw from it. The fee is charged at the start of every epoch and pays for the next one. To keep the account funded automatically, route block revenue to it with solana vote-update-commission-collector; the change takes two epochs to apply.

Both are covered in the Alpenglow validator operator details.

Current Activation Status

As of this writing:

• BLS pubkey registration (feature gate): active on mainnet since July 8, 2026 (also active on devnet and testnet).
• VAT (feature gate): active on mainnet since July 22, 2026 (also active on devnet and testnet).
• Alpenglow (feature gate): active on mainnet since epoch 1064, October 21, 2026, so the VAT fee is now charged every epoch.

About This Upgrade

BLS pubkeys and VAT were the prerequisites for Alpenglow, not the full Alpenglow feature set. The new consensus algorithm, with 150ms finality and off-chain voting, arrived in Agave 4.3 and activated on mainnet in epoch 1064. The migration only worked because the validator set was ready before the switch: every validator needed a BLS key registered, and the network needed a defined, capped admission process in place first. With Alpenglow live, operators also need an Agave-based client and at least 0.8 SOL above the rent-exempt minimum in the vote account for the VAT fee each epoch. Validator operators who have not registered a BLS pubkey are currently unable to participate in consensus and are not receiving on-chain inflationary rewards or block fees.

Learn more: Solana Upgrades