BLS Pubkey and the Validator Admission Ticket

Q3 2026 • Solana Foundation

Solana mainnet validators can now create a BLS pubkey on-chain, the cryptographic prerequisite for Alpenglow consensus. The feature gate that enables this (SIMD-0387) is already active on mainnet. A separate feature gate, the Validator Admission Ticket (SIMD-0357, VAT), will enforce the requirement: once VAT activates on mainnet, any validator without a registered BLS pubkey stops participating in consensus.

The VAT feature activation does not turn on Alpenglow itself. Alpenglow's consensus switch lands separately in Agave 4.3. The VAT feature only gates admission into the validator set based on the existence of the BLS pubkey. Once the full Alpenglow consensus switch happens in Agave 4.3, the complete VAT feature will be enabled. When both VAT and Alpenglow are enabled, validators will have 1.6 SOL deducted from their vote account at the start of each epoch. Votes will no longer be on-chain transactions, so there will no longer be fees for voting.

Technical Details

What a BLS Pubkey Is, and Why Alpenglow Needs One

Solana validators currently vote 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 activation has two different states: before Alpenglow is enabled and after Alpenglow is enabled.

VAT Before Alpenglow

In the first state, before Alpenglow is enabled, the VAT feature gate will require that all voting validators have a BLS pubkey enabled and it will also enforce a limit of 2,000 validators. Since TowerBFT, the current Solana consensus algorithm, will remain in effect, votes will continue to be transactions that land on-chain. Voting validators will continue to be charged about 2 SOL per epoch in aggregate voting costs.

VAT After Alpenglow

In the second state, after Alpenglow is enabled, every voting validator included for the next epoch is charged a flat 1.6 SOL fee per epoch, burned directly to the incinerator rather than redistributed to block proposers as transaction and vote fees are today. That figure is intentionally close to existing voting costs (roughly 2 SOL per epoch).

What Happens When VAT Activates

Once the VAT feature gate is 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.
• None of this turns on Alpenglow consensus itself. VAT only determines who is eligible to participate once Alpenglow activates later, in Agave 4.3.

Registering a BLS pubkey today is an important action item to make sure your voting validator continues to participate in consensus.

Current Activation Status

As of this writing:

• BLS pubkey registration (feature gate): active on mainnet, devnet, and testnet.
• VAT (feature gate): active on devnet and testnet, not yet activated on mainnet. Scheduled for mainnet activation the week of July 20, 2026.

About This Upgrade

BLS pubkeys and VAT are important prerequisites, not the full Alpenglow feature set. The new Alpenglow consensus algorithm with 150ms finality and off-chain voting will arrive in Agave 4.3. The migration to Alpenglow only works if the validator set is ready before the switch: every validator needs a BLS key registered, and the network needs a defined, capped admission process to move into place first. Validator operators who fail to create a BLS pubkey before the VAT activation will be unable to participate in consensus and will not receive on-chain inflationary rewards or block fees.

Learn more: Solana Upgrades