Client Identity¶
Docs-site note (2026-07-11): Part of the planned Vexor documentation site (Anza-style). Grounded in Vexor's
core/version.zig(the single source of truth for version/client-id fields) and the gossip code that consumes it (vex_network/gossip.zig,vex_network/bincode.zig).
Overview¶
Vexor is an independent Solana validator client implemented from scratch in Zig. Consensus behavior is validated byte-for-byte against canonical mainnet-beta and testnet ledger history.
Every validator advertises its client software over gossip, in the ContactInfo record that also carries its
addresses and shred version. That advertisement — semantic version, build commit, and a numeric client ID — is
how explorers, dashboards, and other tooling identify what software is producing a given node's blocks and votes.
Vexor's identity fields are defined in one place, core/version.zig, and consumed by both the gossip
self-advertisement and the metrics reporter's boot announcement, so the two are always consistent.
What Vexor advertises¶
| Field | Value | Where it's set |
|---|---|---|
| Version | 0.9.0 (semver major.minor.patch) |
core/version.zig, VEXOR_VERSION |
| Client ID | 86 |
core/version.zig, CLIENT_ID |
| Commit | first 8 hex characters of the build's git hash, packed to a u32 |
set once at boot, before gossip starts |
| Feature set | 0 |
unset — Vexor does not invent a feature-set value it can't back |
These follow the modern ContactInfo version-block shape Vexor's gossip code targets (vex_network/bincode.zig):
version fields are LEB128 varints (single-byte for any value under 128, which covers Vexor's current
0.9.0/86) and the commit is a fixed u32 — so nothing about advertising this identity changes gossip packet
layout.
The full human-readable version string, used in logs and the metrics reporter's boot point, is built as:
Versioning policy: 0.9.x now, 1.0.0 at production¶
Vexor is versioned deliberately conservatively while it is pre-production: the current series is 0.9.x. The
1.0.0 milestone is reserved for when the validator meets its production-readiness bar — this is an intentional
signal to anyone reading the version off gossip or a dashboard, not an accident of a young project. Operators
should not read 0.9.x as "unstable" in the day-to-day sense; it reflects where Vexor sits on its own roadmap
toward a declared production milestone, not the maturity of any individual subsystem.
Client ID 86 — and why it shows up as Unknown(86)¶
Agave maintains a registry mapping small integer client IDs to known validator clients (version/src/client_ids.rs
in the Agave source) — for example 0 is SolanaLabs/Agave's own legacy default, with other small integers reserved
for Jito, Firedancer, Sig, and related clients. Vexor did not request a slot in that registry before choosing
an ID, so it advertises 86 (chosen for 'V'), which has no entry in Agave's table.
The practical effect: any tool that resolves a gossip client ID against Agave's registry — explorers, dashboards,
solana gossip-style output — will render Vexor's client as Unknown(86) rather than as a recognized name.
That is expected and, for now, the honest outcome: an unregistered ID rendering as "unknown" is the correct
behavior of that tooling, not a bug in Vexor.
The longer-term path is an upstream pull request to anza-xyz/agave adding a registered "Vexor" entry to
client_ids.rs — the same path other independent clients have taken to move from Unknown(N) to a named entry.
Until that lands, Unknown(86) is what operators and explorers will correctly see.
Why honest identity matters¶
An independent client's credibility rests on exactly the kind of byte-for-byte verifiability described in the
attribution above — and that credibility only means something if the client is also honest about
what it is at the metadata layer. Advertising Unknown(86) is a strictly true statement: this node is running
software the reader's tooling doesn't yet recognize. Vexor's version and client-ID fields are sourced from its
own build (core/version.zig), not borrowed defaults, so every field a peer or explorer reads back is accurate
to what is actually running.
Where this shows up¶
- Gossip
ContactInfo— the version and client-ID fields described above, read by any peer or tool that resolves gossip CRDS data (see Networking, the Gossip — CRDS section). - Metrics reporter boot announcement — the
validator-newpoint'sversionfield carries the same version string (see Observability).
Both draw from the same core/version.zig source, so a node's advertised identity is consistent everywhere it
appears.