Vote Account Initialize V2
- Idea
- Draft
- Review
- Accept
- Implement
- Active
Decision brief
Why this proposal matters
This proposal introduces the InitializeAccountV2 instruction to the Vote program, which allows creating new vote accounts with all vote state v4 fields — including BLS public keys — at account creation time.
Proposal at a glance
What changes
- If the collector is not equal to the vote account, it must be system program owned. Otherwise return InstructionError::InvalidAccountOwner.
- The collector must be rent-exempt. Otherwise return InstructionError::InsufficientFunds.
- The collector must be writable (not a reserved account). Otherwise return InstructionError::InvalidArgument.
Stakeholder map
Who is affected
Builders & client teams Medium impact
A new instruction for initializing a vote account with all vote state v4 fields will be added to the vote program with the enum discriminant value of 16u32 little endian encoded in the first 4 bytes.
Action requirement unknownValidators & operators Medium impact
There is no change. Users continue to create vote accounts using the legacy InitializeAccount instruction, then set newer fields using their respective instructions (ie. UpdateCommissionBps).
Action requirement unknownUsers & stakers Medium impact
There is no change. Users continue to create vote accounts using the legacy InitializeAccount instruction, then set newer fields using their respective instructions (ie. UpdateCommissionBps).
Action requirement unknownGovernance & ecosystem Medium impact
This proposal introduces the InitializeAccountV2 instruction to the Vote program, which allows creating new vote accounts with all vote state v4 fields — including BLS public keys — at account creation time.
Action requirement unknownExact source revision
Full proposal document
0616093b2952Summary
This proposal introduces the InitializeAccountV2 instruction to the Vote
program, which allows creating new vote accounts with all vote state v4 fields
— including BLS public keys — at account creation time.
Motivation
The existing InitializeAccount instruction for the Vote program does not
support setting all vote state v4 fields at creation time. After the activation
of vote state v4 (SIMD-0185), users must create an account with
InitializeAccount and then use multiple separate instructions to configure
fields like commission rates, collector accounts, and BLS public keys.
InitializeAccountV2 provides a unified way to set all vote state v4 fields
during account creation, streamlining the process for validators setting up
new vote accounts.
New Terminology
N/A
Dependencies
This proposal depends on the following previously accepted proposals:
SIMD-0387: BLS Pubkey management in vote account
Specifies BLS public key generation and proof of possession verification
Feature Activation Ordering
The InitializeAccountV2 instruction introduced by this proposal allows
setting all vote state v4 fields at account creation time. To prevent early
access to these fields before their respective feature gates are activated,
this SIMD's feature gate MUST be activated after all of the following:
SIMD-0180: Use Vote Account Address To Key Leader Schedule
Prerequisite for vote state v4 features to be operational
SIMD-0185: Vote Account v4
Adds the vote state v4 structure including the BLS public key field
SIMD-0291: Commission Rate in Basis Points
Enables the
inflation_rewards_commission_bpsfield viaUpdateCommissionBpsSIMD-0232: Custom Commission Collector Account
Enables the
inflation_rewards_collectorandblock_revenue_collectorfields viaUpdateCommissionCollectorSIMD-0123: Block Revenue Distribution
Enables the
block_revenue_commission_bpsfield viaUpdateCommissionBps
This ordering ensures that each vote state v4 field can only be set through
its designated instruction until all features are active, at which point
InitializeAccountV2 provides a unified way to set all fields at account
creation.
Detailed Design
Add InitializeAccountV2
A new instruction for initializing a vote account with all vote state v4 fields
will be added to the vote program with the enum discriminant value of 16u32
little endian encoded in the first 4 bytes.
pub enum VoteInstruction {
/// # Account references
/// 0. `[WRITE]` Uninitialized vote account
/// 1. `[SIGNER]` New validator identity (node_pubkey)
/// 2. `[WRITE]` Inflation rewards collector (or vote account if same)
/// 3. `[WRITE]` Block revenue collector (or vote account if same)
InitializeAccountV2(VoteInitV2), // 16u32
}
pub const BLS_PUBLIC_KEY_COMPRESSED_SIZE: usize = 48;
pub const BLS_PROOF_OF_POSSESSION_COMPRESSED_SIZE: usize = 96;
pub struct VoteInitV2 {
pub node_pubkey: Pubkey,
pub authorized_voter: Pubkey,
pub authorized_voter_bls_pubkey: [u8; BLS_PUBLIC_KEY_COMPRESSED_SIZE],
pub authorized_voter_bls_proof_of_possession: [u8; BLS_PROOF_OF_POSSESSION_COMPRESSED_SIZE],
pub authorized_withdrawer: Pubkey,
pub inflation_rewards_commission_bps: u16,
pub block_revenue_commission_bps: u16,
}
Upon receiving the transaction, the vote program will perform a BLS verification on the submitted BLS public key and associated proof of possession, as described in SIMD-0387. The transaction will fail if the verification fails.
For each collector account (indices 2 and 3), the vote program MUST perform
the following validation, matching the checks required by
UpdateCommissionCollector in SIMD-0232:
- If the collector is not equal to the vote account, it must be system program
owned. Otherwise return
InstructionError::InvalidAccountOwner. - The collector must be rent-exempt. Otherwise return
InstructionError::InsufficientFunds. - The collector must be writable (not a reserved account). Otherwise return
InstructionError::InvalidArgument.
If all checks pass, the new vote account is created with the given parameters.
The inflation rewards collector address is taken from account index 2 and the
block revenue collector address is taken from account index 3.
The BLS PoP verification will cost 34,500 CUs, as described in SIMD-0387.
Impact
Before feature gate in this SIMD is activated
There is no change. Users continue to create vote accounts using the legacy
InitializeAccount instruction, then set newer fields using their respective
instructions (ie. UpdateCommissionBps).
After the feature gate in this SIMD is activated
New vote accounts can be created using InitializeAccountV2, which sets all
vote state v4 fields at creation time including the BLS public key and proof of
possession. The legacy InitializeAccount instruction remains available.
Security Considerations
BLS public key verification and proof of possession are specified in
SIMD-0387. The same security considerations for BLS rogue-key attacks and
replay attacks described there apply to InitializeAccountV2.
Alternatives Considered
N/A
Evidence graph
Related proposals and rollout
One or more sources are unavailable.
Upstream review record
Upstream discussion & review
One or more sources are unavailable.
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity. 3
Provenance
Evidence & technical details
Rollout or chain data, source revisions, freshness and integrity.SIMD
Deployment Status
Feature Gate not yet created
Exact source revision
Sources & integrity
- Proposal document pinned_commit_blob
0616093b2952ed6de52c4a27d66aadd11d48d4f9 - simd-document document · stale · Sep 11, 2026
0616093b2952ed6de52c4a27d66aadd11d48d4f9
One or more sources are unavailable.
One or more sources are unavailable.
simd.watch community discussion · SIMD-0464
Powered by Giscus · Sign in with GitHub to comment
Community comments load when this section approaches the viewport.