BLS Pubkey and the Validator Admission Ticket

BLS Pubkey and the Validator Admission Ticket

Updated July 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) 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 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 Now That VAT Is Active

With the VAT feature gate 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. SIMD-0326 - Alpenglow: new consensus algorithm will be activated once Agave 4.3 is on mainnet (expected in Q4 2026).

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.

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).

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. Both prerequisites are now live on mainnet. 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