Roadmap — Planned, In Progress, Deliberately Deferred¶

Docs-site note (2026-06-25, refreshed 2026-07-11): This is a forward-looking page for the planned Vexor documentation site, modeled on the structure and feel of docs.anza.xyz / anza.xyz. Everything below is the honest open list — what is genuinely not yet done, what is in flight, and what we have deliberately chosen not to do (with the reason). It is the inverse of the Parity Status page: that page is what already works; this page is what is left. Items already done are not repeated here.

How to read this page¶

Vexor is live on testnet today, voting bank-exact as a Zig-native validator. Most of the hard consensus, runtime, and storage work is already done and deployed (see Parity Status and Architecture). What remains is a short, specific list — not a wall of TODOs. We organize it into four buckets:

Near-term open work — genuinely unfinished, actionable now.
Differentiator moats in flight — capabilities no other client has, designed/prototyped but not yet shipped.
Future feature activations — code that is already ported and tested but stays dormant until the network turns the corresponding feature on.
Deliberate deferrals — things we are consciously not doing, each with the reason. These are decisions, not bugs or gaps.

A guiding rule: we would rather under-claim than over-claim. If something is deferred, this page says so and says why, rather than dressing it up as planned.

1. Near-term open work¶

This is the entire genuinely-open, actionable list. It is deliberately short.

Item	What it is	Why it matters	Active divergence?
Transaction-bearing block production	Block production today is proven and cluster-accepted, but produces empty blocks. A transaction-bearing produce path exists and lands transactions on-chain, but is not yet proven bank-exact under all conditions, so it stays gated. This is parity work in progress on the produce path, not a voting or replay issue.	This is the last step toward genuine leader-equivalence (producing blocks with real transactions, not just placeholders).	No — gated off; the node reverts to empty-block production, which stays cluster-accepted.
`VEX_MODE` operator role selector	A single `VEX_MODE=full \\| vote \\| rpc` switch to choose the node's role (vote + produce / vote-only / follow-only), replacing today's multi-flag combination. Spec'd, implementation queued.	Operator ergonomics — removes a class of misconfiguration risk from running the wrong combination of flags.	No.
Gossip CRDS signature verification	The gossip `verify()` exists but is not yet wired into the cluster-info ingest path (insert / push / pull).	Security and network-citizenship hardening; it is the prerequisite that unblocks gossip-trust "Layer A".	No — not a bank-hash divergence.
Snapshot-trust finish (final enforcement)	The scaffolding is already in the deployed binary (full-only-boot lt-hash guard is live; known-validator config + agreement module are in). The one remaining piece is the gated post-load / pre-vote enforcement call site that actually consults it.	Completes trustless snapshot acceptance; meaningful once gossip-trust is wired (above).	No.
Snapshot creation completion	A full + incremental `.tar.zst` snapshot writer exists. Finishing it cleanly needs a Zig-native zstd encoder so the whole path stays std-only and Zig-native.	Lets a Vexor node serve snapshots, not just consume them — a step toward bootstrap independence.	No.
Archival-RPC read optimizations	`mmap`/zero-copy reads on the archival blockstore path (full transaction content for `getBlock` / `getTransaction`).	Throughput and memory for history-serving RPC nodes; not on the consensus path.	No.

Recently completed: 100% of the live vote-execution path is Vexor-authored code, with nothing reference-derived left in the consensus-critical vote path — see The Vote Program.

The honest framing: none of these are active consensus bugs. Transaction-bearing production is a genuine in-progress gap (honestly disclosed, not shipped early); the gossip and snapshot-trust items are citizenship and trust hardening; the rest are capability, ergonomics, and performance completions. The node votes bank-exact without any of them.

2. Differentiator moats in flight¶

These are capabilities that no other validator client has. They are built on Vexor's persistent, offline-replayable blockstore (see VexLedger) and are in design / prototype, not yet shipped on by default.

Real-time divergence alarm — designed. Combining the blockstore's flight recorder (which already captures each slot's consensus fingerprint — bank hash, parent hash, signature count, PoH hash, accounts lt-hash) with the proven offline-replay engine, this detects the first slot where the node's bank hash diverges from the cluster, auto-re-replays it, and emits the exact diverging account + field + owner. It collapses a normally multi-day forensic investigation into a single notification. The flight recorder is built; the alarm wires onto it. Status: designed, dormant by default.
SnapStream cross-client restart coordination — design + proof-of-concept. A scheme for coordinating a cluster restart across heterogeneous validator clients, including a proven FROST-Ed25519 threshold-signing proof-of-concept and a shipped distributor prototype. Status: design complete with working PoCs; not yet a production subsystem. The exact productionization scope is still being defined.
zseglog extraction — specified. The generic storage core under VexLedger (an append-segment, bounded, crash-safe, std-only Zig store) is specified for extraction as a standalone open-source Zig package, 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. Status: specified, not yet extracted.

All of the above are gated and dormant in their current form, with zero effect on the consensus path when off.

3. Future feature activations (ported, dormant, awaiting the network)¶

These are not unfinished work — the code is written, tested, and in the binary. It stays dormant until the network activates the corresponding feature, because turning it on early would mean accepting behavior the canonical client still rejects — i.e. it would cause a divergence. They are listed here so the roadmap is honest about what is staged and waiting.

SIMD serializers / feature-gated runtime changes — ported, dormant. For example, the SIMD-0449 direct-account-pointers serializer is byte-exact against a canonical golden vector and present in the binary, but feature-gated off. It activates the moment the network enables the corresponding feature, and not before.
Alpenglow readiness — groundwork active, consensus logic not yet started. Alpenglow (Votor consensus + Rotor propagation) is not yet active on public testnet — it currently runs only on a separate Anza community test cluster, with no announced cutover date. Several of its prerequisite pieces are already live on Vexor's voting path today: VoteState V4 serialization, BLS public-key registration, the BLS12-381 syscalls Votor's certificates depend on, and the vote-account-table keying the rewards system needs. What Vexor does not yet have is any Votor/Rotor consensus logic itself — that is a genuinely new subsystem, not a port of something already running elsewhere in the client. Because Alpenglow activates as a hard cutover (no extended dual-consensus period), a TowerBFT-only validator would go quietly delinquent past the switch rather than error out. Status: prerequisite groundwork live; full voting-path implementation not yet started; estimated multi-month effort once undertaken. This is being tracked well ahead of any network announcement.

The discipline here is the same one that keeps Vexor bank-exact: match the protocol's behavior at the current feature set, and flip ported-but-dormant code only when the network's feature gate flips.

4. Deliberate deferrals (decisions, not bugs)¶

These are things we have consciously decided not to do right now. Each is a documented decision with a reason — not a gap, not a "to fix."

Whole-block cost-model mark_dead on actual compute units — deliberately not on the live replay path. Adding it would mean a single false positive could mark a good block dead and push the node into delinquency, on the hottest, most consensus-sensitive path. The risk is latent and adversarial-only, and fork-choice already protects against the failure it would guard. The cost is real (delinquency); the benefit is marginal. So it is a low-priority, gated-future item — intentionally deferred, not missing.
sBPF v4 — deliberately not implemented (watch-item). The current network protocol version has no enable_sbpf_v4 feature activated and rejects an ELF with e_flags=4 — exactly as Vexor does. Implementing v4 now would mean accepting what the protocol currently rejects, which would itself be a divergence. So matching the protocol here means not building it yet. The trigger to revisit is a future network activation of enable_sbpf_v4. (Note: the "V4" work that was done — VoteState V4 / SIMD-0185 — is a different thing, and it is done.)

These two illustrate the deferral philosophy: the protocol defines correct behavior, and sometimes the correct behavior is to wait. Deferring them is how we stay bank-exact, not a shortfall.

5. Path to 1.0.0¶

Vexor's version number is deliberately conservative: it runs 0.9.x while pre-production, and 1.0.0 is reserved for the production-grade milestone, not spent early. The bar for 1.0.0 is:

A clean epoch-boundary track record — the boundary-time Clock and vote-account-table correctness work (see Accomplished) holding up across multiple consecutive boundaries.
Transaction-bearing block production, cluster-accepted, at the same reliability empty-block production has today.
The broader production-readiness checklist this roadmap tracks — most importantly, no open items in section 1 above.

Until then, Vexor advertises itself honestly on the network as pre-production software, rather than claiming a maturity level it hasn't earned.

What is explicitly not on this roadmap¶

To keep this page honest in both directions, a few things that might look like roadmap items are already done and deployed, and so do not appear above:

Whole-block execution regardless of per-transaction cost (DAG/wave paths), and the SVM crypto syscalls (bn254 / alt_bn128 / poseidon, BLS12-381, curve25519).
The ZK ElGamal proof program (confidential transfer, SIMD-0153), wired into live dispatch.
Parallel transaction execution, System-CPI Nonce (Tier-1 + Tier-2), native QUIC votes, and ed25519 FEC-set dedup.
Block production (turbine real-stakes fix; empty blocks proven produced and cluster-accepted at ~97%+ leader slots), the expanded RPC method set, the account-writer half of snapshot create (the zstd encoder and manifest assembly are still open — see section 1), and the live read-only feature-status watcher.
Vote-credit coverage (near-maximum credit accrual) and epoch-boundary Clock + vote-account-table correctness — both live and deployed.
The vote program (990,000-instruction real-traffic comparison, zero mismatches, 4.7× faster than a reference implementation) — it is the live vote executor.

If you are looking for the state of those, see the Parity Status page and the Architecture section — this page is strictly the forward list.

Summary¶

The open list is short and specific: finish transaction-bearing block production, ship the VEX_MODE operator selector, wire gossip CRDS signature verification (unblocks gossip-trust Layer A), finish the snapshot-trust enforcement call site, complete snapshot creation behind a Zig-native zstd encoder, and optimize archival-RPC reads. In flight are three first-of-their-kind moats — the real-time divergence alarm (designed), SnapStream restart coordination (design + PoC), and the zseglog extraction (specified). Staged-and-dormant are the ported SIMD serializers, and Alpenglow's prerequisite groundwork is live while its consensus logic itself is not yet started. And two items are deliberately deferred — whole-block cost mark_dead (false-positive delinquency risk) and sBPF v4 (the protocol itself currently rejects it) — because the correct, bank-exact behavior is to wait. 1.0.0 is reserved for when this list, plus a clean multi-boundary track record, is done.