Why Vexor Is Different¶
Docs-site note (2026-06-25): This is an early authored page of the planned Vexor documentation site, modeled on the structure and feel of docs.anza.xyz / anza.xyz. The site itself will be built out when Vexor is production-ready across testnet and mainnet; this page is written now so the project's thesis is documented while it is fresh. Style: clean headings, plain language, claims grounded in source + live measurement, status tagged DONE / PARTIAL / PLANNED so nothing reads as shipped before it is.
The thesis — client diversity matters, and Vexor is independent¶
Every major Solana outage to date has traced back, in one way or another, to a consensus monoculture: when almost the entire network runs the same client, a single implementation bug can halt the chain. The agreed remedy across the ecosystem is client diversity — multiple, independently-implemented validators that reach the same consensus answer by different code paths, so that no single bug can stop everyone at once.
Vexor exists to be one of those independent implementations. It is a from-scratch, 100% Zig-native Solana
validator client — not a fork of Agave, and not a thin binding around someone else's engine. It is a clean-room
implementation that reaches the same bank_hash as the live cluster through its own consensus, runtime, sBPF
VM, networking, and blockstore code.
That word independent is the whole point. A diversity client only reduces monoculture risk if its bugs are different bugs. A fork inherits the upstream implementation and therefore inherits the upstream bug class; a language binding inherits the bound engine's behavior. Vexor shares almost no implementation lineage with Agave, so a latent bug in one is unlikely to exist in the other — which is exactly the property the network needs.
An honest framing up front (we do not oversell):
- "Zig" is not our wedge. Sig (Syndica) is also written in Zig; "a Zig validator" is not unique. Our differentiation is independence proven by byte-exact correctness against the live cluster, plus the tooling we built to get there — not the language and not raw speed.
- "Fastest" is not us. Firedancer is the raw-performance client. We do not claim that title.
- "100% Zig-native" — true without caveat. There is no Rust FFI on any consensus path, and the binary links
zero Firedancer code at runtime: ed25519, BLAKE3, BN254/alt_bn128, and Poseidon all run through Vexor's own
src/vex_crypto/, verified byte-exact against known-answer test vectors and live cluster parity (build flag-Dpure_zig, the canonical production default). An alternate build option can link Firedancer'sballetAVX-512 leaf crypto instead, kept as a reference configuration, but it is not what the production binary ships with. Consensus, runtime, VM, blockstore, networking, and leaf crypto — all Zig.
How Vexor differs from each existing client¶
Today Solana has a small set of validated clients. Vexor aims to be a genuine fourth independent implementation alongside them. Here is how it relates to each:
| Language | Lineage | Blockstore | Focus | Vexor's relation | |
|---|---|---|---|---|---|
| Agave (Anza) | Rust | Reference impl | RocksDB (C++ LSM) | The incumbent; the monoculture to diversify | Vexor is a clean-room behavioral drop-in, not a fork; reaches the same bank_hash by independent code |
| Firedancer (Jump) | C / C++ | Independent | Custom fd_blockstore (no persistence — rebuilds shreds from the network on restart) |
Raw-performance king | Vexor shares FD's "no RocksDB" storage discipline but adds persistence + crash recovery + offline replay |
| Jito-Agave (Jito) | Rust | Agave fork (MEV: bundles, block-engine, BAM) | RocksDB (inherited) | MEV / restaking on top of Agave | Not an independent client — a fork; Vexor's independence is the contrast |
| Sig (Syndica) | Zig | Independent | rocksdb-zig binding (RocksDB under a Zig binding) |
Historically RPC / read / gossip / accountsdb; maturing toward full consensus | Both are Zig, but Vexor's blockstore is its own Zig append-segment store (no RocksDB), and Vexor is consensus/voting-first |
A few clarifications, stated fairly:
- Sig is not "read-only." It began read / RPC / gossip / AccountsDB-focused and is actively maturing toward
full consensus. The accurate distinction is storage and focus, not capability ceiling: Sig uses a
rocksdb-zigbinding (RocksDB underneath, via Zig), whereas Vexor's blockstore — VexLedger — is a ground-up Zig append-segment store with no RocksDB at all (see VexLedger). - Jito is a fork, not a separate client. It is Agave plus MEV machinery; it inherits Agave's consensus implementation (and bug class). It does not add implementation diversity.
- Firedancer made the same blockstore call we did — both abandoned RocksDB — but FD deliberately skips persistence (it rebuilds shreds from the network on restart). Vexor keeps them, which is what unlocks offline replay and the divergence-forensics capabilities below.
Differentiators that are shipped and proven (DONE)¶
Everything in this section is confirmed either by being deployed and voting bank-exact on live testnet, by offline-replay bank-exact parity against a cluster-attested chain, or by KAT / golden-vector for feature-gated code, per the canonical status doc (2026-06-23).
VexLedger — a live, Zig-native, byte-audited blockstore — DONE¶
Vexor's blockstore is VexLedger, a purpose-built 100% Zig append-segment store that replaces Agave's RocksDB entirely. It is live on testnet today as the voting node's blockstore, stays bank-exact under load, and adds negligible overhead with ~1× write amplification (versus RocksDB's multi-× LSM compaction overhead).
Every interop-facing record is validated byte-for-byte against the canonical protocol wire-format
specification, currently anchored to the newest testnet release (v4.2.0-beta.0 — Vexor re-anchors this
audit to each new release as it ships), with a verdict of zero known drift — every column-family name, every
big-endian key, and every value codec (wincode for the meta families, protobuf for transaction_status /
rewards) matches the canonical format, and RPC JSON output byte-matches the canonical reference. Full detail on
the VexLedger page.
Bank-exact voting at the live tip — DONE¶
Vexor votes on the live testnet cluster and produces the same bank_hash as the cluster, byte-for-byte. This
is the load-bearing claim behind "independent and correct": it is backed by Vexor's own per-slot parity
tooling, which keeps it that way on every deploy (see below).
Offline bank-exact replay (carrier / divergence forensics) — DONE¶
Because VexLedger persists shreds and can re-replay them, any rooted slot can be re-replayed offline, with no
network, and reproduces the cluster's bank_hash exactly (proven 6/6 on a pinned rooted slot range). This
offline-replay engine is the foundation of Vexor's divergence-forensics tooling: pin a diverging slot, replay it
offline, and isolate the exact diverging program / account / field. (The always-on, real-time version of this
is a designed moat — see Planned.)
Block production (empty blocks) proven and cluster-accepted — DONE¶
Vexor produces blocks in its leader window that the cluster accepts (verified via public oracle: the produced
slots appear in getBlocks / getBlock and getBlockProduction reflects them). Turbine broadcasts each
produced block using real epoch stake weights.
Precision: the empty-block production path is the part proven live and cluster-accepted. Tx-bearing block production — the full transaction-inclusion gate (sequential fee-payer running-balance + blockhash-age + in-block dedup + cross-block status cache + cost-model) — is built but gated and revertible, not yet live-proven. It is listed under Partial, not here.
Own canonical sBPF interpreter VM (Firedancer-parity) — DONE¶
Vexor has its own clean-room Zig sBPF VM — a byte-/bank-exact interpreter validated against the protocol's sBPF execution semantics (anchored to the current network protocol version, v4.2.0-beta.0) and at interpreter-parity with Firedancer (FD also interprets; JIT is an optimization some clients choose, not a protocol requirement, so "no JIT" is not a parity gap). It supports sBPF v0/v1/v2/v3, and the syscall surface is implemented natively in Zig — including ZK ElGamal proof verification (confidential transfer, SIMD-0153) and the bn254 / alt_bn128 / poseidon / BLS12-381 crypto syscalls — as real Zig/native ports, not FFI shims into someone else's runtime.
Kernel-bypass networking + native QUIC votes + FEC dedup — DONE¶
- AF_XDP zero-copy networking — kernel-bypass RX (zero-copy, proven live) plus a real TX ring.
- Native Zig QUIC vote submission — a full client-auth QUIC TPU path (mTLS identity cert, ALPN
solana-tpu, correctmax_streams_uniflow-control handling). Most independent setups lean on Agave's QUIC stack; this is Vexor's own. - FEC-set ed25519 sigverify dedup — bank-hash-neutral signature-verification dedup across erasure sets, proven correct on live shreds (0 false rejects, bank-exact).
Operational differentiators — DONE¶
- Explicit tile→core topology with a per-deploy runtime verifier. Every thread has a declared core home, and
the deploy path reads
/procto prove the live thread→core map and flag any floater on a consensus core. No mainstream validator self-verifies its pinning at deploy time. - Canonical RPC minimal/full tier split. The voting node serves exactly the standard minimal RPC footprint (12 methods); heavier RPC is gated behind an explicit mode — byte-faithful to the canonical RPC specification, with clean consensus/RPC separation.
- Productionized build/deploy. One blessed canonical build with hard gates on divergence-critical flags and instant rollback binaries.
Capabilities that are partial (PARTIAL)¶
These are built and present but not yet live-proven on the consensus path, or implemented-but-dormant by default. We label them honestly rather than counting them as shipped.
| Capability | Status | What's true today |
|---|---|---|
| Tx-bearing block production | PARTIAL | Full inclusion gate built (fee-payer balance + blockhash-age + dedup + status cache + cost-model), gated and revertible; empty-block production is the part proven live |
| Flight recorder (per-slot consensus fingerprint into VexLedger) | PARTIAL | Implemented; dormant by default behind a config flag (VEX_LEDGER_FLIGHT=1), zero effect on consensus when off |
| VexLedger content / archival RPC (getBlock / getTransaction history) | PARTIAL | Content path built + audited byte-clean against the canonical RPC specification, deployed but opt-in / dormant by default |
| Pruning + tunable fsync telemetry | PARTIAL | Implemented and gated; rolling out on a maintenance build |
Moats that are designed or planned (PLANNED)¶
These are the longer-term differentiators. They are design-complete or proposed, not shipped. We mark them so explicitly — a designed moat is not a shipped moat.
Real-time divergence alarm — PLANNED (designed)¶
Combining the flight recorder with the offline-replay engine, Vexor is designed to detect the first rooted slot
where its bank_hash diverges from the cluster, automatically re-replay that slot offline, and emit the
exact diverging account + field + owner — collapsing what is normally a multi-day forensic investigation into
a single notification. The offline tooling underneath is shipped (see DONE);
the always-on, real-time alarm that wires onto the flight recorder is designed, not yet live. No other
validator client self-diagnoses divergence to account+field granularity in real time.
SnapStream — cross-client restart coordination — mixed: shipped distribution + PLANNED autopilot¶
SnapStream is Vexor's snapshot / recovery infrastructure. Be precise about which layers exist:
- SHIPPED: cross-client, integrity-verified snapshot + increment distribution for any client (C-ABI), on the time-to-recovery critical path.
- SHIPPED: a custom QUIC server with MASQUE (RFC 9298) transport hardening (endpoint obfuscation, smaller DDoS / correlation surface).
- PLANNED (proposed, with proven PoCs): an opt-in, threshold-authorized, cross-client restart-coordination
autopilot — a coordinator publishes agreed restart params (slot, expected bank hash, shred version, hard-fork,
snapshot) once, and every opted-in client of any language auto-provisions and relaunches, collapsing
time-to-supermajority after a halt. The cryptographic authorization model is de-risked by PoC (FROST
threshold Ed25519, verifiable under stock ed25519; plus a stake-weighted, role-diverse governance policy), but
the autopilot itself is not shipped. It complements — does not replace — the protocol's
wen_restartmechanism (SIMD-0046).
zseglog — extractable open-source storage engine — PLANNED (specified)¶
VexLedger's generic storage core (a bounded, prunable, crash-safe, std-only Zig append-segment store) is specified for extraction as a standalone, MIT, open-source Zig package — zseglog — with the Solana-specific column families layered on top. It fills a real gap in the Zig ecosystem (a maintained, embeddable KV / segment store) and is a planned shipped public good. Specified, not yet released.
At a glance — shipped vs planned¶
| Differentiator | Status |
|---|---|
| Independent, clean-room, Zig-native validator | DONE |
| Bank-exact voting at the live testnet tip | DONE |
| VexLedger append-segment blockstore (live, byte-audited zero-drift) | DONE |
| Offline bank-exact replay (carrier forensics, 6/6 proven) | DONE |
| Own canonical sBPF interpreter VM (FD-parity) + native crypto syscalls | DONE |
| AF_XDP zero-copy RX + native QUIC votes + FEC dedup | DONE |
| Per-deploy tile→core pinning verifier; canonical RPC tier split | DONE |
| Empty-block production (cluster-accepted) | DONE |
| Tx-bearing block production (inclusion gate) | PARTIAL (gated) |
| Flight recorder; content/archival RPC | PARTIAL (dormant) |
| Real-time divergence alarm | PLANNED (designed) |
| SnapStream restart-coordination autopilot | PLANNED (proposed; PoCs proven) |
| zseglog open-source extraction | PLANNED (specified) |
Status (2026-06-25)¶
- Independent Zig validator, voting bank-exact on live testnet — the core diversity claim, proven.
- VexLedger live + byte-audited zero-drift against the canonical protocol wire-format specification (v4.2.0-beta.0); offline replay 6/6 bank-exact; own sBPF VM at FD-parity.
- Empty-block production proven cluster-accepted; tx-bearing production built but gated.
- Moats (real-time divergence alarm, SnapStream restart autopilot, zseglog) are designed / proposed / specified — clearly not yet shipped.
- Re-confirm any "DONE" against the live binary before relying on it; the canonical status doc is the source of truth, and this page mirrors it.