Why Byte-Faithful Parity¶

Docs-site note (2026-07-11): This page argues why Vexor commits to strict byte-for-byte parity with the canonical client rather than being "behaviorally close" — and the discipline that enforces it. It is the rationale; the proven results (vote-success rate, offline-replay counts, the audited record set) live in Parity & Fidelity Audit and are not repeated here. Claims are grounded; caveats are stated plainly.

The decision¶

Vexor commits to byte-for-byte parity with Agave on every consensus- and interop-load-bearing surface — not "approximately the same behavior," but the same bytes. The target is re-anchored to the newest testnet release as Agave ships (currently v4.2.0-beta.0), not frozen to one version — parity means matching what the live cluster runs today, not a snapshot from the past. This page explains why a softer target is not actually available for a consensus client, and what method we use to hold the strict one.

This is a decision about method, and it is one of the things that most distinguishes Vexor: parity is not something we assert, it is something we continuously prove from source.

Why "behaviorally close" is not a category¶

For most software, "close enough" is a coherent goal. For a consensus client it is not, and the reason is the bank hash.

At the end of every slot, a validator computes a single hash that commits to essentially all of its state — the account set (via the accounts lt-hash), the parent bank hash, the signature count, the proof-of-history hash, and more. That hash is what the validator votes on. Two validators agree on a block if and only if they compute the same bank hash for it.

A hash has no notion of "close." Change one byte of any input — a fee rounded the other way, a rent calculation off by a lamport, a sysvar field serialized in a different order, a feature gate that flips one slot early — and the output is a completely different hash. There is no partial credit. So:

A validator that is "behaviorally close" to canonical computes the same bank hash on the blocks where its small differences happen not to matter, and a different bank hash on the one block where they do. On that block it votes a different fork. There is no middle state — it is byte-exact, or it is on the wrong fork the moment a difference surfaces.

And a client that votes the wrong fork is worse than no second client: instead of adding resilience, it splits the network's view of the chain. This is exactly why byte-faithfulness and independence (see How Vexor is different) are the same commitment — an independent client is only an asset to the network if it stays byte-exact.

That is the whole argument. Strict parity is not perfectionism; it is the only target that exists for the surface that determines which fork you vote on.

The discipline that enforces it¶

Committing to a strict bar is meaningless without a method that holds it. Vexor uses three, layered from "before you write code" to "before you deploy."

Three-way ground-truth¶

The 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; client versions drift from each other. So before any behavior is treated as correct, it is checked against three independent sources:

#	Source	Why it is consulted
1	The deployed binary's actual source	What is really running and voting — read at the deployed commit, not what a branch or a note claims.
2	Agave, newest testnet release (currently v4.2.0-beta.0)	The canonical, byte-faithful target — re-anchored to each new testnet release as the live cluster upgrades. We read what Agave actually does, not what an older pin says it did.
3	Pinned Firedancer (cross-check)	An independent second implementation, especially for consensus/runtime. When Agave and Firedancer agree, that agreement is the specification.

The strongest signal is Agave == Firedancer: two independent canonical implementations agreeing is the spec, and Vexor matches it. When they disagree, that is a stop signal — the discrepancy is resolved before any code is touched. This is not theoretical process; it has caught real bugs a single-source check would have missed (see the worked examples in Parity & Fidelity Audit).

That three-way check only stays usable if the parity trail itself doesn't rot. Vexor keeps a maintained provenance ledger (PROVENANCE.md) mapping every file/function that reimplements, ports, or byte-exact-matches an upstream Agave/Firedancer/Sig behavior, keyed by stable @prov: anchors in source rather than line numbers — so when the upstream reference changes, the exact Vexor code that needs re-checking is one grep away, and the attribution required for reimplementing Apache-2.0 code (see NOTICE) stays accurate as the codebase moves.

Golden-vector test harness¶

For records, serializers, syscalls, and proof programs, "looks right" is not proof. Vexor uses a reusable harness that extracts byte-exact reference vectors directly from Agave's own crate internals (behind Agave's unstable-API feature gates) and locks Vexor's output against them as known-answer tests. The payoff is that dormant, feature-gated code can be proven byte-correct before the cluster ever activates it — parity is verified ahead of activation, not discovered after a divergence.

Offline-replay bank-exact gate¶

The final gate is the strongest: any rooted slot can be re-replayed offline, with no network, and must reproduce the cluster's bank hash. When a fix touches the consensus path, the rule is that the offline replay of a pinned, cluster-attested slot range must come out bank-exact before the change is deployed. A fix is not "done" because it compiles or passes a unit test — it is done when it reproduces the cluster's hash on real slots. (The proven offline-replay results are in Parity & Fidelity Audit.)

An honest boundary — what is not byte-faithful, on purpose¶

Byte-faithfulness applies to the surfaces that interop and consensus actually observe — the bank hash, the on-the-wire record encodings, the RPC JSON. It does not mean every internal representation mirrors Agave's.

The clearest example is the blockstore. Vexor's VexLedger stores blocks in its own append-segment format on disk — deliberately not a RocksDB database — because a purpose-built store is the right structure for the workload (Firedancer made the same choice with its own format). So agave-ledger-tool cannot open VexLedger's segment files directly. The byte-faithful guarantee there is behavioral and at the wire boundary: the validator behaves identically, the column-family names / keys / value codecs match the anchored Agave release exactly, and the RPC responses are byte-identical — while the on-disk layout is free to be better. See the VexLedger cross-client fidelity note for exactly where the line is drawn.

This is the point of being precise about the bar: byte-faithful where the network observes you, free to innovate where it does not.

Why this is a differentiator of method¶

Most clients treat parity as a property to claim. Vexor treats it as something to prove continuously, from source: ground every behavior in three independent sources, lock byte-output with golden vectors extracted from Agave itself, and gate every consensus fix behind an offline replay that must reproduce the cluster's bank hash. Combined with the operational honesty of grading every claim and stating every open item plainly, the result is a client whose correctness is measured, not asserted — which is exactly what an independent client has to be to make the network more resilient instead of less.