The Vote Program — Vexor's Most-Executed Code Path¶

Docs-site note (2026-07-11): This page documents Vexor's vote-program implementation — Vexor's sole, unconditional live vote executor on testnet; no build flag selects it, and no alternate path exists to select instead. The vote program described in Consensus is this implementation. Style and grounding rules match the rest of this section: plain language, claims tied to source and to measurement, caveats stated honestly.

Overview¶

Every vote a Solana validator casts is an ordinary on-chain transaction: it invokes the vote program, a built-in program that mutates a validator's vote account (its lockout tower, its credits, its root slot). On Vexor's testnet node, vote transactions are not a niche code path — they are the large majority of everything the runtime executes. Across a measured ~990,000-instruction window, vote instructions accounted for the large majority of transaction signatures processed by the node. A validator's execution time is, to first order, the time it takes to run the vote program.

That makes the vote program's implementation quality — both its correctness and its speed — one of the highest- leverage places in the entire client. Vexor's vote program is a from-scratch, Vexor-authored implementation of the protocol's vote-program semantics, engineered for zero-allocation execution and proven correct through staged, gated validation (see below) before being trusted to run alone. It is the implementation that executes every vote instruction on Vexor's testnet node.

The four-layer architecture¶

The implementation splits cleanly into four layers, separating state-transition logic from instruction dispatch as distinct concerns:

Codec layer. Version-aware serialize/deserialize between raw account bytes and an in-memory vote-state struct. Instead of a generic reflection-based (de)serializer, this is a comptime-specialized, fixed-offset codec: it reads and writes exactly the fields a given operation touches, at known byte offsets, with bounded collections (a 31-entry lockout ring, a small fixed-capacity authorized-voters table) instead of a growable list or hash map. Zero heap allocation. This layer also owns the one field in the modern vote-state layout that exists specifically for a future Alpenglow/Votor consensus engine — a compressed BLS public key — without needing to know anything about how that field will eventually be used.
Account-I/O layer. A borrow-only-what's-touched account model: a vote instruction typically names 2-4 accounts (the vote account, an authority, a sysvar), so this layer is built so a caller can only ever materialize the accounts an instruction actually names — never a whole transaction's worth of account state.
State-transition layer. Pure functions operating on an in-memory vote-state value: pushing and popping the lockout tower, awarding credits, advancing the root slot, authorizing a new voter, updating commission. This layer is intentionally instruction-agnostic — it has no idea whether it was invoked by a TowerSync instruction or something else. That property is what makes it reusable: a future certificate-based consensus engine would call into this same layer to update the same bookkeeping, without touching it at all.
Dispatch layer. The thin front door: decode the instruction, do the account-ownership and signer checks every instruction needs, route to the right state-transition function, and serialize the result back out through layers 1-2. Kept deliberately thin so it stays auditable against the protocol's instruction dispatch rules.

This is also the module boundary that keeps the vote program ready for Solana's proposed Alpenglow consensus upgrade without requiring a second rewrite later: layers 1-3 are shared infrastructure that any future certificate-processing engine would reuse, and only the dispatch layer would need a sibling. Vexor has not built any Alpenglow/Votor logic — no BLS certificate verification, no such consensus state machine exists yet — this is purely a decision about where the seams go, made now because it costs nothing extra.

Design rationale — correctness and shape¶

Every state-transition rule in the implementation is derived directly from the protocol's vote-program specification — the version Vexor's own node runs live, not a historical snapshot — so behavior can be checked against source and against a real running cluster node.

The implementation shape favors zero-allocation execution: stack-allocated instruction decoding bounded by a fixed transaction-size limit (no heap allocation on the decode path), flat fixed-capacity structs instead of generic hash maps and growable lists, and account-ownership checks done once up front rather than re-derived per field. Vexor uses Zig's typed error unions for control flow throughout, which map naturally onto the protocol's result-oriented semantics and are straightforward to audit.

The vote-state layout targets exactly one version: every successful mutating instruction migrates an older account to the modern V4 layout in memory and always writes V4 back out, unconditionally, matching the current protocol version.

Proving it correct before trusting it¶

Rewriting the single most-executed, most consensus-critical code path in the client is not something to get subtly wrong — a bug here doesn't crash the validator, it silently produces a wrong account byte, which is exactly the kind of error that turns into a bank-hash divergence hours or days later. So the implementation is proven correct through staged, gated validation before it is trusted to run alone:

Known-answer tests drawn from canonical protocol test vectors. Correctness is checked against ground truth — the protocol's own reference expectations — not against another implementation's interpretation of it.
Staged, gated rollout. Each layer was built and proven independently before the next depended on it: the codec layer first (byte-exact round-trips against real cluster vote-account data), then account I/O, then each non-lockout instruction family (authorize, withdraw, commission, initialize), then dispatch, and last — deserving the most test density of any stage — the TowerSync family: the lockout, credit, and root-advance logic.
Full-scale live comparison. At the final validation gate, 990,000 live vote instructions were compared byte-for-byte with zero mismatches, alongside a full slot-range replay (1,992 slots) matching the cluster's bank hash.

Status: the implementation is the sole, unconditional executor that commits state for every vote instruction on Vexor's testnet node — no build flag selects it, and no alternate path exists to select instead. It cleared a live-comparison soak spanning a full epoch boundary with zero result mismatches before being trusted to run alone (epoch-boundary authorized-voter bookkeeping is exactly the kind of narrow window a short test run could miss).

Measured performance¶

Because the vote program is such a large share of total execution time, its performance is not a micro- optimization — it materially affects how much of a slot's CPU budget goes to consensus bookkeeping versus everything else. Measured across a 990,000-instruction live comparison window:

	Reference implementation	Vexor's vote program
Time per vote instruction	~8.9 µs	~1.9-2.0 µs
Relative	baseline	~4.7× faster

The improvement comes directly from the architectural choices above: no heap allocation on the hot path, no generic reflection-based codec, and account materialization bounded to only what an instruction actually touches instead of an entire transaction's account set. With vote instructions making up the large majority of testnet transaction signatures, a 4.7× reduction here is a meaningful reduction in the runtime's total per-slot execution cost, not just a narrow benchmark win.

Vote-instruction coverage¶

Vexor's vote program implements the full current protocol instruction set, including:

DepositDelegatorRewards (SIMD-0123) — implemented directly from the protocol specification.
InitializeAccountV2 (SIMD-0464) — a single, complete implementation.
Unconditional V4 vote-state handling, matching the current protocol version exactly.

These are correctness and completeness properties of the vote program itself, verified the same way as everything else in this section: against source, and against a running cluster.

Status¶

Live on testnet as the sole, unconditional production vote executor. Vexor's vote program commits the state that lands on chain for every vote instruction. No build flag selects it and no alternate path exists to select instead.
Fully validated. The implementation cleared a live-comparison soak spanning a full epoch boundary with zero result mismatches before being trusted to run alone — epoch-boundary authorized-voter bookkeeping was the narrow window a short run could have missed.
The entire live vote-execution path is Vexor-authored code, implemented directly to the protocol's vote-program specification.

Vexor is an independent Solana validator client implemented from scratch in Zig. Consensus behavior is validated byte-for-byte against canonical mainnet-beta and testnet ledger history.