What Vexor Has Accomplished
Docs-site note (2026-06-25, refreshed 2026-07-21): This is the "proven track record" page of the Vexor
documentation site, modeled on the structure and feel of docs.anza.xyz /
anza.xyz. Everything listed here is genuinely shipped and proven — either running
in the deployed testnet binary and voting bank-exact, or proven by an offline-replay / golden-vector gate.
Work that is partial, dormant scaffolding, or still open lives on the Roadmap, not here.
Style: clean headings, plain language, every claim grounded in source or measurement.
How to read this page — the proof bar
Vexor is a clean-room, fully Zig-native Solana validator. The bar for a milestone to appear on this page is
deliberately strict. Each one carries the type of evidence that backs it:
| Proof tier |
What it means |
| Live — bank-exact |
Deployed in the testnet binary; the node votes CURRENT and its bank hash matches the cluster. |
| Offline-replay bank-exact |
A rooted slot range re-replayed offline (no network) reproduces the cluster's bank hash exactly. |
| KAT / golden-vector |
Verified byte-for-byte against a canonical v4.2.0-beta.0 protocol reference vector. May be dormant / feature-gated (compiled in, off by default, zero consensus-path effect until enabled). |
The single source of truth for done-vs-open is the internal canonical status doc; this page reflects only its
DONE + in-the-deployed-binary set.
Consensus & voting
| Milestone |
Proof |
| Bank-exact voting on live testnet |
Live — node votes CURRENT, bank hash matches the cluster, zero divergence. This is the foundational milestone: Vexor stays in consensus byte-for-byte. |
| Whole-block execution regardless of per-tx cost |
Live — every transaction in a block executes regardless of its individual compute cost, on both the DAG and wave replay paths; deployed and voting CURRENT bank-exact. Offline gate: DAG 66/66 + WAVE 70/70 match with the over-cap branch forced. |
| Feature-activation boundary handling |
Live — in-flight feature activations are read correctly across epoch boundaries; deployed, voting bank-exact across the boundary. |
| VoteState V4 (SIMD-0185) |
Live — vote-state serialization handled correctly on the voting path. |
| Vote-credit coverage — near-maximum credit accrual |
Live — Vexor earns ~98.7% of maximum available vote credits (measured against the theoretical 16-per-slot ceiling), sustained across leader-window positions. |
| Epoch-boundary Clock + Vote-Account-Table correctness |
Live — the stake-weighted Clock sysvar estimator recomputes its drift anchor every slot, and vote-account candidacy for the rewards table is keyed on stake at the correct epoch. Deployed and gate-proven cluster-faithful across a full epoch-boundary window (1992/1992 slots byte-identical to canonical ledger history). |
| Switch-proof fork-escape |
KAT / golden-vector — the tower's cross-fork switch-proof observes both landed and gossip-relayed votes (the canonical two-source model). Slashing-safe by construction (it only ever adds observed stake, never removes lockout protection). Proven with 5/5 fork-rescue test vectors plus a clean 1992/1992 golden replay; staged for the next deploy. |
| Replay transaction-signature verification |
Live — replay verifies every transaction's signature before execution; an invalid signature marks the whole slot dead, per the protocol's whole-block validity rule (an unparseable transaction is counted but does not kill the slot). 7 KATs pass; a clean 1992/1992 golden replay confirms the whole-slot signature pre-pass is inert on real historical blocks; deployed to the live voting binary and confirmed armed (boot log announces the worker pool, and a running counter of verified/rejected transactions stays at zero rejections under normal operation). See Consensus. |
Vote program — clean-room, live
Vexor's vote-instruction execution is 100% Vexor-authored code, implemented directly to the protocol's
vote-program specification and engineered for zero-allocation, flat-buffer instruction handling. Vote
instructions are Vexor's single largest execution cost — roughly 98% of all testnet transaction signatures — so
this is one of the highest-leverage subsystems in the client. See
The Vote Program for the full technical write-up.
| Milestone |
Proof |
| Full Vote/TowerSync instruction family implemented |
Offline-replay bank-exact + KAT — every vote instruction the current protocol defines (Authorize, Withdraw, TowerSync, credit/lockout processing, root advancement, and more) has a Vexor implementation, validated with 249 reference test vectors (0 failures) plus over 200 additional hand-written test vectors. |
| Differential validation against real traffic |
Offline-replay bank-exact + live — the implementation is validated against 990,000 instructions over the offline golden-window replay, then 20.3M+ live vote instructions across live-boot sessions against real cluster traffic — zero mismatches in every run. The full golden replay gate (1,992 slots) passes byte-identical. |
| Meaningfully faster |
Measured — Vexor's vote program runs at ~2,017 ns per vote instruction versus ~8,909 ns for a reference implementation (same 990,000-instruction offline replay) — ~4.4× faster — while producing byte-identical output; sustained ~1,940 ns live over 20.3M+ real instructions. |
| Live as the sole production vote executor |
Live — bank-exact — Vexor's vote program is the only implementation that commits state for every vote instruction on the testnet node; no build flag selects it. |
Status: live in production. Vexor's vote program executes every vote instruction on Vexor's testnet node
today, as the sole, unconditional executor — see The Vote Program for the
full architecture.
Block production
| Milestone |
Proof |
| Empty-block production proven + cluster-accepted |
Live — turbine's stake-weighted broadcast produces blocks the cluster accepts, sustained across a full epoch: 152 of 156 leader slots produced (~97.4%), confirmed via public RPC (getBlockProduction) and independent skip-rate monitoring (validators.app). Note: these blocks are empty — transaction-bearing production is still in progress (see Roadmap), not claimed here. |
Runtime & SVM
| Milestone |
Proof |
| Zig-native sBPF VM (v0/v1/v2/v3) |
Live + KAT — Vexor's own clean-room sBPF interpreter, deployed on the live path across all supported ELF layouts. (Interpreter-based, matching Firedancer's approach.) |
| Parallel transaction execution (WavePool) |
Live — wave-barrier parallel executor; deployed, bank-exact under live cluster load. |
| System-program CPI nonce (Tier-1 + Tier-2) |
Live — Authorize / Upgrade / Advance / Withdraw / Initialize nonce operations via CPI handled bank-exact. |
| ZK ElGamal proof program (SIMD-0153) |
Live — confidential-transfer proof verification implemented clean-room, wired into the live builtin dispatch, deployed voting bank-exact. |
| SIMD-0449 direct-account-pointers serializer |
KAT / golden-vector — byte-exact against a v4.2.0-beta.0 reference vector. Dormant, feature-gated (off on the live path until the feature activates). |
| Compute-unit metering — protocol parity |
Live — the syscall/CPI cost-accounting surface (per-CPI invoke units, hash-syscall byte costs, heap cost, loader entry costs, the loaded-accounts-data-size gate) is verified byte-parity against the canonical protocol cost model and deployed. |
Crypto syscalls
| Milestone |
Proof |
| alt_bn128 / bn254 + Poseidon syscalls |
Live + KAT — group ops, compression, and Poseidon hashing verified byte-for-byte against canonical golden vectors (protocol version v4.2.0-beta.0); deployed, voting bank-exact. |
| Pure-Zig crypto backend (FFI-free) |
Live — ed25519, BLAKE3, BN254/alt_bn128, and Poseidon implemented from scratch in Zig (src/vex_crypto/, build flag -Dpure_zig). Verified byte-exact against known-answer test vectors — including published solana-bn254 / EIP-197 / go-ethereum vectors for BN254 — and against live cluster parity; deployed as the canonical production backend, zero Firedancer symbols linked at runtime. |
BLS12-381 + solBigModExp (variable CU) |
Live — additional curve / big-modular-exponentiation syscalls on the live path. |
| curve25519 abort-vs-soft semantics |
Live — error-handling semantics conform exactly to the protocol specification. |
Networking
| Milestone |
Proof |
| Native QUIC votes |
Live — Vexor's QUIC frame parser correctly reads max_streams_uni stream credit so votes flow over native QUIC; deployed. |
| AF_XDP fast-path ingest |
Live — kernel-bypass packet ingest active on the deployed node. |
| FEC-set ed25519 dedup |
Live — duplicate-shred dedup on the FEC path, proven bank-hash-neutral on live shreds (0 rejects, bank-exact through the deduping path). |
| Network citizenship |
Live — turbine retransmit and repair DoS hardening on the live path. |
Storage — VexLedger
| Milestone |
Proof |
| VexLedger live as the node's blockstore |
Live — Vexor's 100% Zig append-segment blockstore (a behavioral drop-in for the network's blockstore contract) runs on the voting node, stays bank-exact under load, ~1× write amplification. See VexLedger. |
| v4.2.0-beta.0 byte-fidelity — zero drift |
KAT / audit — every interop-facing record (column-family names, big-endian keys, wincode/protobuf value codecs, RPC JSON) audited byte-for-byte against the canonical protocol wire format (v4.2.0-beta.0) in two independent passes; verdict zero drift. |
| Offline bank-exact replay (6/6) |
Offline-replay bank-exact — any rooted slot re-replayed offline with no network reproduces the cluster's bank hash; 6/6 on a pinned rooted slot range. This is what makes Vexor a carrier engine and underpins the divergence-forensics tooling. |
RPC
| Milestone |
Proof |
| Core account & program RPC |
Live — getMultipleAccounts, getProgramAccounts, getHighestSnapshotSlot, and getBlock history implemented. |
| Canonical RPC tier split |
Live — --full-rpc-api tier split: the voting node serves only the minimal RPC method set and returns canonical -32601 for full/bank-data methods until full RPC is enabled, per the standard RPC tiering convention. |
Snapshots
| Milestone |
Proof |
| Snapshot loading |
Live — the mmap parallel loader reads standard-format snapshots (~86.7M accounts) in a few seconds on every boot; full-snapshot lt-hash verification against the archive. |
| Feature-status watcher |
Live — read-only feature-activation watcher on the live replay path. |
Note: snapshot creation (writing a .tar.zst archive a peer can boot from) is partial — not yet complete (the account writer exists; a Zig-native zstd encoder + manifest assembly are the remaining work). It is tracked on the Roadmap, not claimed here. Snapshot loading is fully done.
Attribution & provenance
| Milestone |
Proof |
Provenance ledger (PROVENANCE.md) |
Live — a maintained, single-source ledger mapping every Vexor file/function that reimplements, ports, or byte-exact-matches reference client behavior, keyed by stable @prov: anchors in source rather than line numbers. Keeps the attribution trail and the parity-maintenance trail in one place. |
Project-level attribution (NOTICE) |
Live — states plainly that Vexor is an original reimplementation, not a fork, that credits Agave/Firedancer/Sig as reference implementations, and that Vexor links none of their code at runtime (crypto is pure-Zig; see above). |
The headline four
If you read nothing else:
- Bank-exact voting on live testnet. Vexor votes CURRENT and its bank hash matches the cluster byte-for-byte
— the whole validator is in consensus, not just a subset of it.
- The vote program — Vexor's most-executed code path — is a clean-room, Vexor-authored implementation, live in
production. Verified against 20.3M+ live vote instructions with zero mismatches and ~4.4× faster than a
reference implementation.
- Block production proven, sustained. Turbine's stake-weighted broadcast produces blocks the cluster
accepts at ~97.4% of leader slots (152/156) across a full epoch (empty blocks; tx-bearing is on the
roadmap).
- VexLedger — a clean-room Zig blockstore, live and zero-drift. Running as the node's blockstore, audited to
zero drift against the canonical protocol wire format (v4.2.0-beta.0), with offline bank-exact replay proven
6/6.
For what is still in progress or deliberately deferred, see the Roadmap. The bar for this page is
intentionally high: if an item is partial, dormant-only-with-no-live-equivalent, or open, it is on the roadmap —
not here.