Roadmap — Planned, In Progress, Deliberately Deferred¶

Docs-site note (2026-06-25, refreshed 2026-07-16): 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 five buckets:

Near-term open work — genuinely unfinished, actionable now.
Differentiator moats in flight — capabilities no other client has, designed/prototyped but not yet shipped.
Ecosystem tooling in flight — developer-facing tooling (SDK, conformance runner, decode library) built alongside the validator, not on its consensus path.
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 an experimental run showed its produced blocks can disagree with the node's own replay of them — the cluster correctly skips those slots rather than accepting a divergent block. 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.

Done since the last refresh: retiring the legacy vote-program reference implementation — the Sig-derived component that served as the differential-test oracle during the vote-program rewrite has been fully removed from the tree (Stage 8, 2026-07-12, −31,181 lines; see The Vote Program). 100% of the live vote-execution path is now Vexor-authored code, with nothing reference-derived left in the consensus-critical vote path — this item is complete and no longer repeated in the table above per this page's own rule. The real-time divergence alarm, previously tracked here as a design, is also done and moved off this list — it is armed and running live (see Reliability & Conformance and Accomplished).

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.

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. (The vote-program clean-room rewrite that used to be tracked here has shipped — it is now the live vote executor; see Accomplished and the retirement item in section 1.)

3. Ecosystem tooling in flight¶

Separate from the validator itself, a small set of supporting Zig tooling is being built alongside it — developer-facing pieces, not consensus-path code. None of it runs on the voting node; it is listed here for the same reason everything else on this page is: honest visibility into what's actually built versus in progress.

A Zig SDK for writing Solana on-chain programs — in progress, host-tested only. A from-scratch Zig program SDK (comptime Anchor-compatible IDL generation, an Anchor-parity account-constraint DSL, Borsh encode/decode, SPL Token / Token-2022 bindings) compiled to real sBPF and proven against Vexor's own VM. As of this writing the merged, tested baseline is 182 passing host-side tests; a further batch of work (runtime PDA seeds, additional syscall bindings) exists on an unmerged branch and is not yet counted here. Two small example programs have been compiled to sBPF and exercised through Vexor's VM; none has been deployed to a live cluster. Status: in progress, not a shipped product.
A Solana conformance test runner — findings-stage, now clearing its own gate. A harness that runs a large third-party fixture corpus (47,240 instruction-level test vectors) against Vexor's sBPF VM and native program dispatch, to find behavioral bugs mechanically instead of one incident at a time. The most recent pass scores 93.64% pass rate on the 16,897 fixtures currently in scope (a large, explicitly-excluded "known-gap" set — precompiles, loader-management instructions, and roughly twenty not-yet-implemented vote-program variants — is reported separately, not folded into the percentage). That clears the methodology's own ≥80% gate by 13.64 points, up from an earlier 79.05% pass that missed it. The improvement came from three named, root-caused fixes: a missing account-owner precondition check in the vote program, a spurious PDA-marker rejection in the system program's TransferWithSeed handling, and a compute-unit-accounting gap on BPF-path failures. A smaller set of residual bugs remains and is disclosed, not hidden. Status: a real, working tool that now passes its own bar — still not yet wired into the validator's own pre-deploy gate battery above.
A byte-exact account/transaction decode library (zdecode) — two milestones complete. A standalone decoder for common on-chain state (SPL Token/Token-2022, Stake, Vote, Nonce, sysvars, transaction wire formats) aimed at indexers, with a conformance story that includes vectors generated directly from Agave's own Rust crates, not hand-typed expectations. Its first milestone shipped the pure-Zig decoder core; its second added a C ABI export layer with Rust and WASM/npm bindings, plus a live-testnet integration example that cross-checks real decoded accounts against Agave's own RPC output. 209 tests pass across the three toolchains (Zig-native core, Rust, WASM). Status: two milestones shipped; continuous scheduled live-RPC conformance and a handful of lower-confidence decoders (an extinct historical vote-account format, one long-stable sysvar) remain explicitly open, not silently assumed done.

None of this is part of the validator's consensus, replay, or vote path, and none of it is claimed as production-grade yet — it's early-stage tooling, reported here at the same honesty bar as everything else on this page.

Showcase programs — three now live on testnet¶

Three example programs built with the Zig SDK above were deployed to public Solana testnet on 2026-07-16 — separate from, and not part of, the Vexor validator's own consensus path. Each is deployed and confirmed executable on-chain (verified via account inspection: executable: true, owned by the upgradeable BPF loader); none has yet been exercised with a live instruction call, since none of the three repos has a client/invocation script built yet — that is explicit follow-on work, not silently assumed done.

Program	What it demonstrates	Program ID	Deploy slot
`zattest`	An append-only on-chain registry where a validator client can publish signed health/conformance attestations — exercising realloc account-growth chains in the SDK.	`2R5zoyHktPD8zXFbVLmCXr6Na47VhCjm7XWwSDp9qcyW`	422,416,389
`zconform`	An on-chain client-conformance oracle where independent validator clients publish per-slot bank-hash attestations and the program records raw disagreement between them — client-diversity conformance made publicly visible.	`DGmvDNBQdJ5B6iXvLiPEkwP8U2b6USqEKh46p4xhVraJ`	422,416,795
`zorderbook`	An on-chain central-limit order book — a performance-oriented matching engine with the whole book in a single zero-copy account, no bulk-array copies on the hot path (M1: matching-engine ledger only, no token custody or settlement yet).	`Hh6EGBQD1kezgwb2a2xAyTzBWgFVVDXKb7cvcXApabpg`	422,416,852

A fourth program, zprofile (an on-chain compute-unit cost-model canary), built cleanly but its testnet deployment was rejected — honestly, a cluster-capability gap rather than a bug: its whole premise depends on the sol_remaining_compute_units syscall, gated behind a network feature (remaining_compute_units_syscall_enabled) that is not yet active on testnet. It will redeploy once that feature activates.

4. 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 an Agave rc.1 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 canonical client's behavior at the current feature set, and flip ported-but-dormant code only when the network's feature gate flips.

5. 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 canonical client (Agave rc.1) has no enable_sbpf_v4 and rejects an ELF with e_flags=4 — exactly as Vexor does. Implementing v4 now would mean accepting what Agave rejects, which is by definition a divergence. So matching the canonical client here means not building it yet. The trigger to revisit is a future Agave 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 canonical client defines correct behavior, and sometimes the correct behavior is to wait. Deferring them is how we stay bank-exact, not a shortfall.

6. 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 recent boundary-time Clock and vote-account-table fixes (see Accomplished) holding up across multiple consecutive boundaries with no regressions.
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:

The DAG/wave cost-skip divergence fix (execute-regardless), 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.
The vote-credit coverage fix (near-parity credit accrual) and the epoch-boundary Clock + vote-account-table fixes — both live and deployed.
The vote-program clean-room rewrite (990,000-instruction real-traffic comparison, zero mismatches, 4.7× faster than the implementation it replaces) — it is now the live vote executor; only the legacy reference implementation's retirement remains (see section 1).

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, optimize archival-RPC reads, and retire the legacy vote-program reference implementation now that its Vexor-authored replacement is the live executor. In flight are two first-of-their-kind moats — SnapStream restart coordination (design + PoC) and the zseglog extraction (specified); the real-time divergence alarm that used to be tracked alongside them has shipped and is armed live (see Accomplished). Also in progress, on the developer-tooling side rather than the validator itself: a Zig program SDK, a Solana conformance test runner, and a byte-exact decode library (zdecode) — see section 3. 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 (Agave itself 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.