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 the Agave, Firedancer, and Sig reference implementations.
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,
grounded in Firedancer's fd_gossip_msg_ser.c, not independently re-verified against Agave's own ContactInfo
serializer in this pass): 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.
(This section describes the registry mapping as documented in Vexor's own source comments referencing Agave's
client_ids.rs; it has not been independently re-checked against the current upstream file in this pass — flagged
here rather than asserted as freshly verified.)
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¶
Vexor's gossip identity used to advertise Agave's defaults — version 2.2.0, commit 0, client ID 0. Client
ID 0 is SolanaLabs in Agave's registry, so every explorer that resolved it displayed Vexor nodes as "Solana
Labs 2.2.0" — a different client entirely, and a stale version at that. That was a byproduct of never having set
the fields, not an intentional claim, but the effect on anyone reading gossip was the same: a validator that was
not Agave, reporting itself as Agave.
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. Advertising SolanaLabs 2.2.0 would have been false. Between
an accurate "unknown" and an inaccurate "known", Vexor advertises the accurate one.
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.