Skip to content

Parity & Fidelity Audit

Docs-site note (2026-06-25, refreshed 2026-07-11): This page is Vexor's honest self-assessment of how closely it conforms to the Solana protocol at the byte level, verified against canonical mainnet-beta and testnet ledger history. It is written in the same spirit as the VexLedger cross-client fidelity section, extended to the whole validator. The discipline here is the point: every parity claim is grounded in source and live measurement, every known-open item is stated plainly, and deliberate deferrals are marked as deliberate with the reason. Claims that are designed-but-not-yet-proven are flagged so they read as roadmap, not as fact. The protocol baseline below is re-checked against each new network release as it ships — currently v4.2.0-beta.0, the newest testnet release.

Why this page exists

A second validator client is only useful to the network if it stays in line with the rest of the network — if it computes the same bank hash for the same block, encodes records the same way on the wire, and answers RPC the same way down to the byte. A client that drifts is worse than no second client: it splits the network.

So Vexor treats parity not as something to claim, but as something to continuously prove. This page lays out the methodology we use, the parity results that are proven today, and — just as importantly — the items that are still open or deliberately deferred. The credibility of the proven claims depends on being equally honest about the unproven ones.

The methodology — ground-truthed, not assumed

Vexor's hardest rule for any consensus- or runtime-affecting behavior is that a doc, a memory, or an assumption is never enough. Code drifts from documentation; the protocol evolves release to release. So before any behavior is treated as "correct," it is ground-truthed against independent sources:

# Source What it answers
1 The deployed binary's actual source What is really running and voting — not what a branch or a note claims. We read the source at the deployed commit, not the roadmap.
2 Canonical mainnet-beta and testnet ledger history The network's real, recorded consensus outcomes — the byte-exact target every replay is checked against, re-verified as the network upgrades (currently anchored to protocol version v4.2.0-beta.0).
3 Cross-client implementation comparison Checking behavior against more than one independent implementation of the same protocol surfaces genuine spec ambiguity, especially for consensus/runtime edge cases (cost model, replay, sigverify, snapshot).

When independent implementations of the protocol agree, that agreement is the specification. When they disagree, that is a stop signal — the discrepancy is resolved against the protocol specification before any code is touched.

This is not theoretical process — it is how Vexor confirms subtle protocol invariants before they reach the live voting path. One example: confirming that "execute every transaction regardless of cost" is a protocol invariant (per-transaction cost is an after-the-fact aggregate, never a gate that could silently skip execution).

Proven parity — what is verified today

Each item below is held to a concrete bar: it is DONE only with one of (a) deployed and voting CURRENT bank-exact on live testnet, (b) offline-replay bank-exact against a cluster-attested chain, or (c) golden-vector / known-answer tests (KATs) for dormant or feature-gated code.

Bank-exact voting on live testnet

Vexor runs as a voting validator on the live testnet cluster and stays bank-exact — its computed bank hash matches the cluster's for every slot. This is the single strongest parity signal: the bank hash is a function of essentially all account and consensus state, so byte-exact voting under sustained live load is an end-to-end proof that replay, the runtime, the SVM, sysvars, fee/rent accounting, and rewards all conform to the protocol.

Evidence (as of 2026-07-11): the node is deployed and voting CURRENT (not delinquent) on the public testnet cluster, earning ~98.7% of the maximum available vote credits (measured against the theoretical 16-vote/slot ceiling). Live parity is re-checked after every deploy.

Beyond the live voting signal, every consensus-affecting change additionally has to clear an offline golden replay — 1992 canonical slots spanning a full epoch boundary, bank hashes byte-identical to the live cluster's — before it is ever deployed. This is the standing gate, not a one-time check.

Offline replay — golden-gate bank-exact

Because VexLedger persists shreds and can re-replay them with no network, every consensus-affecting change is replayed offline against a pinned range of canonical slots and must reproduce the cluster's bank hashes exactly before it is ever deployed. This proves the replay path is deterministic and cluster-faithful independent of any live timing.

Evidence: offline golden replay — 1992 canonical slots spanning a full epoch boundary, bank hashes byte-identical to the live cluster's (the standing pre-deploy gate).

Vote-instruction execution — byte-identical across live traffic

Vexor's vote-instruction execution is a from-scratch, Vexor-authored implementation of the protocol's vote-program semantics, built for zero-allocation, flat-buffer instruction handling, and is the sole, unconditional vote executor.

Evidence: instruction-for-instruction differential comparison against 990,000+ real vote instructions captured from live epoch-boundary traffic — zero mismatches. The same sample shows the vote program executing at ~1.9 µs per instruction versus ~8.9 µs for a reference implementation — 4.7× faster — with byte-identical output.

VexLedger — zero-drift interop audit

Every interop-load-bearing blockstore record was line-checked against the network's canonical wire-format specification across two independent passes, with a verdict of zero P0 drift:

  • Column-family names — every name byte-matches the protocol's canonical naming (exact snake_case; no typo, casing, or pluralization drift).
  • Key encoders — every interop key is big-endian with the correct field widths and tuple order. The classic width traps are all handled: erasure_meta.fec_set_index is u64 in the key while merkle_root_meta's is u32 (a 12-byte key, not 16); address_signatures is the full pubkey ++ slot ++ tx_index(u32 BE) ++ sig 108-byte tuple in order.
  • Value codecs — wincode for the meta family (SlotMetaV3, Index, ErasureMeta, MerkleRootMeta, FrozenHashVersioned) and protobuf for transaction_status and rewards — each matching the network's canonical column routing. Wrong codec would make the value unreadable cross-client; none is wrong.
  • RPC JSON renderers — the transaction-error, transaction-wire, meta, and protobuf renderers byte-match the network's canonical serde output, golden-locked by KATs (exact vector counts: see source).

Evidence: line-by-line specification audit of the column, metadata, and protobuf schemas; consensus-/RPC-critical encoders carry golden KATs derived from canonical reference data. Confidence: HIGH. See also VexLedger cross-client fidelity.

SVM crypto syscalls — golden-vector KATs

The cryptographic syscalls are verified byte-for-byte against canonical golden vectors derived from the protocol specification:

  • bn254 / alt_bn128 group ops, compression, and poseidon — verified against canonical golden vectors, with KAT coverage including the G2 byte-vectors.
  • ZK ElGamal proof program (confidential transfer, SIMD-0153) — a byte-faithful verifier; real proofs verify and corrupt proofs reject, with end-to-end handler KATs.
  • SIMD-0449 direct-account-pointers serializer — byte-exact against a canonical golden vector (dormant, feature-gated).

Evidence: KATs / golden vectors against canonical reference data.

sBPF interpreter — protocol-compliant execution

Vexor has its own sBPF virtual machine — a clean-room implementation (interpreter.zig, verifier, ELF loader, memory-region and v0/v1/v2/v3 layouts) — that executes bank-exact. The sBPF specification does not mandate JIT compilation; interpretation is a fully protocol-compliant execution strategy, so it has no bearing on consensus parity.

Evidence: bank-exact live execution + KATs.

Honest caveats — known-open and deferred parity items

This section is the reason the section above is trustworthy. Nothing here is a current bank-hash divergence on the live voting path; each is stated with its real status.

Open (genuinely not done — but not an active divergence)

  • Gossip message signature verification is a planned hardening item, not yet wired into cluster-info ingest (insert / push / pull). This is security/citizenship hardening and a prerequisite for known-validator snapshot-trust enforcement — it is not a bank-hash divergence. It is the single clearest open item on the actionable list.

  • Snapshot-trust enforcement — only the final call site remains. The scaffolding (full-only-boot lt-hash guard, known-validator config wiring, the agreement module with KATs) is already in the deployed binary; what is missing is the gated post-load/pre-vote enforcement call on a live path. It is deliberately gated behind the gossip signature-verification item above to be meaningful.

  • VexLedger RocksDB export tool is latent (by design). Vexor's blockstore is a native append-segment store, not RocksDB, so tools built for RocksDB-backed clients cannot open the .seg files directly. The byte-primitives for an exportable RocksDB form — the value codecs and most key encoders — exist and are KAT-proven; what is unbuilt is the sig/pubkey export-key assembly and the directory writer. This is an unbuilt convenience surface, not a drift: there is no live name-keyed interop surface to break today, and the export, when built, is name- and codec-correct from day one. (See the VexLedger fidelity note.)

Deliberate deferrals (documented decisions, with reasons — not bugs)

  • Whole-block cost mark_dead on actual compute units is intentionally not added to the live replay path. A false positive would mark a good block dead and cause delinquency on the hottest consensus path. It is a latent, adversarial-only concern, protected by fork choice, and is a low-priority gated-future item rather than a live gap.

  • sBPF v4 is a watch-item, deliberately not implemented. The current network protocol version has no enable_sbpf_v4 feature activated and rejects e_flags=4 — exactly as Vexor does. Implementing it now would mean accepting what the protocol currently rejects, which would itself be a consensus divergence. The trigger to implement is a future network activation of the enable_sbpf_v4 feature. (Note: the "V4" work that was done — VoteState V4 / SIMD-0185 — is a different thing and is complete.)

Designed, not yet proven (roadmap — read as such)

  • The VexLedger real-time divergence alarm (auto-detect the first diverging slot, re-replay it, emit the exact diverging account/field/owner) is designed and wires onto the live flight recorder, but is not yet a proven end-to-end capability. It is listed here so it is not mistaken for a shipped feature.

The discipline as a differentiator

The parity tooling itself is part of what keeps Vexor in line — and is unusual among clients:

  • Golden-vector harness. A reusable harness extracts byte-exact reference vectors from canonical protocol test data and locks Vexor's output against them. This is how dormant, feature-gated code (serializers, syscalls, proof programs) is proven correct before a cluster ever activates it — parity is verified ahead of activation, not discovered after a divergence.

  • Offline-replay carrier forensics. Any rooted slot can be re-replayed offline, with no network, to reproduce the cluster's bank hash. Should a divergence ever be suspected, this turns what would otherwise be a multi-day forensic hunt into a bounded procedure: pin the carrier slot, discriminate block-vs-execution, and isolate the exact program / account / field — and crucially, gate the fix offline (the replay must reproduce the cluster's bank hash) before anything is deployed.

  • Ground every claim in source, not memory. This discipline is enforced precisely because docs, notes, and worklogs go stale and the protocol evolves release to release. Every "it's correct" on this page traces to a read of the deployed source and canonical protocol reference data — not to a recollection.

The result is a validator whose parity is measured continuously and proven from source, with the open items held in plain sight rather than papered over. That honesty is the foundation the proven claims stand on.

Status summary (2026-07-11)

Area Status Basis
Voting bank-exactness (live testnet) ✅ Proven CURRENT in-cluster; ~98.7% of max vote credits (2026-07-11)
Offline replay parity ✅ Proven 1992/1992 golden-gate slots on every consensus change
Vote-instruction execution (Vexor-authored) ✅ Proven 990k+ live-instruction differential comparison, zero mismatches, 4.7× faster
VexLedger interop (names/keys/codecs/RPC JSON) ✅ Proven two-pass specification audit + golden KATs vs canonical reference data, zero drift
SVM crypto syscalls (bn254/poseidon/ZK/0449) ✅ Proven golden-vector KATs against canonical reference data
sBPF interpreter ✅ Parity bank-exact execution; interpretation is a protocol-compliant strategy
Gossip message sig-verify ⬜ Open planned hardening item, ingest call not yet made (not a divergence)
Snapshot-trust enforcement call site ⬜ Open scaffolding deployed; final gated call remains
VexLedger RocksDB export tool ⏳ Latent (by design) primitives proven; writer + sig/pubkey key assembly unbuilt
Whole-block cost mark_dead ⏸ Deferred (with reason) false-positive delinquency risk on hot path
sBPF v4 ⏸ Deferred (with reason) current protocol version rejects e_flags=4; implementing now = accepting what the protocol currently rejects
Real-time divergence alarm 🛠 Designed wires onto flight recorder; not yet proven end-to-end