SIMD-0357

TL;DR

This SIMD describes how the validator admission ticket (VAT) collection described in [SIMD 326](https://github.com/solana-foundation/solana-improvement-documents/pull/326) will be implemented. Specifically, how it affects validator operation procedures. The validator admission ticket is a mechanism translating the current cost of voting into a similar economic equilibrium for Alpenglow. By charging every voting validator 1.6 SOL per epoch, it replaces the current voting fee at ~2 SOL per epoch, and reduces the likelihood there are too many voting validators immediately after Alpenglow launches. The general VAT concept has already been accepted with the governance vote on SIMD 326. Everything specified below are protocol-level changes, they need to be implemented by all Solana clients. The client specific data structure changes are omitted.

Summary

This SIMD describes how the validator admission ticket (VAT) collection described in [SIMD 326](https://github.com/solana-foundation/solana-improvement-documents/pull/326) will be implemented. Specifically, how it affects validator operation procedures. The validator admission ticket is a mechanism translating the current cost of voting into a similar economic equilibrium for Alpenglow. By charging every voting validator 1.6 SOL per epoch, it replaces the current voting fee at ~2 SOL per epoch, and reduces the likelihood there are too many voting validators immediately after Alpenglow launches. The general VAT concept has already been accepted with the governance vote on SIMD 326. Everything specified below are protocol-level changes, they need to be implemented by all Solana clients. The client specific data structure changes are omitted.

Motivation

Adding more staked validators to a blockchain does come with costs. At the very least, the votes and corresponding rewards need to be processed by every voting validator. Therefore, every additional staked validator increases the number of messages for every validator. Right now every voting validator pays voting fee on any vote transaction included in a block. The voting fee adds up to ~2 SOL per epoch if the validator votes most of the time. It is a burden, yet at the same time it's an economic barrier to having too many voting validators. VAT is only a temporary solution to maintain the current economic equilibrium. This proposal intentionally strives to keep voting validator protocol costs similar to pre-Alpenglow consensus.

Key Changes

• Validator Admission Ticket(VAT): The 1.6 SOL charged once per epoch to
• When a new bank crosses an epoch boundary (bank.epoch() >
• Perform stake activation and deactivation so that the intended stake values
• The calculation iterates all vote accounts and filters those that meet
• The account has a balance of at least VAT plus the necessary storage rent amount for a new epoch
• The account has a BLS public key
• If the number of filtered accounts exceeds 2,000, sort them according to the
• Sort in descending order of stake (largest to smallest)
• Do not tiebreak. If total valid vote accounts exceed the limit of 2000, omit all accounts whose stake is equal to that of the 2001st account
• Subtract VAT from the vote account for each validator in the accepted
• Record the VAT fee subtraction in the bank, move the lamports directly into

Impact

The voting set of validators will be strictly capped at 2,000. The validator operators must also take care to keep their vote account topped up, instead of relying on funds inside identity account.

Backwards Compatibility

This feature is not backwards compatible.

Security Considerations

Keeping funds in vote accounts for VAT is safer than keeping funds in identity accounts. Because the keypair for identity account needs to be in a hot wallet to support real-time validator operations, while the vote authorized withdrawer keypair does not need to be in a hot wallet. In furtherance of improving operational security, a future simd may change the deposit location of validator rewards to the vote account. This would eliminate the necessity for any funds to be controlled by a hot keypair.