Skip to content

Validator or RPC Node?

Docs-site note: Grounded directly in vex-fd's command dispatch (src/main.zig) and its --help output. Vexor is testnet-only, version 0.9.x pre-production — nothing on this page implies mainnet readiness.

A Solana validator client can run in different roles depending on whether it votes and produces blocks, or simply follows the cluster and serves RPC requests. This page describes what Vexor supports today, via its CLI subcommands, and what's planned as a single unified mode switch.

Today: two real subcommands

vex-fd ships two commands that launch the node in different roles. Both are real, shipped, verified against --help and the command-dispatch code — not aspirational:

Command Role What it does
vex-fd run (alias vex-fd validator) Full validator Votes on the cluster and, when it's the leader, produces blocks. This is Vexor's default, live-tested role — the one the current testnet deployment runs.
vex-fd rpc RPC / follower node Does not vote. Internally this is implemented as run with --no-voting --full-rpc-api injected automatically — the same relationship Agave's agave-validator --no-voting --full-rpc-api has to a normal validator.

There is no separate vex-fd vote-only subcommand or mode. Voting without producing blocks is not a role Vexor exposes today, by CLI subcommand or by any documented environment-variable combination.

Block production is empty-block only, today

Whichever role you run, block production (when it happens, i.e. under run/validator during a leader slot) is currently empty, cluster-accepted blocks — transaction-bearing block production exists behind a gate and is not yet enabled. See Runtime Modes for what's gated today.

RPC surface is minimal

--full-rpc-api widens the served JSON-RPC method set, but Vexor's RPC implementation is still partial. Don't rely on a Vexor RPC node for cluster-wide facts (stake, delinquency, vote-account health) — query the public testnet RPC for those instead. See the caveat in Staking Setup.

Planned: VEX_MODE

A single VEX_MODE environment variable is spec'd but not implemented. It's designed to make role selection a one-flag decision instead of assembling flags by hand:

Value Role
full (planned default) Vote and produce blocks — today's run/validator behavior.
vote Vote only; never produce or broadcast blocks. Not available today in any form.
rpc Follow the cluster only — no voting, no block production. Closest to today's vex-fd rpc, but as an env-driven switch rather than a subcommand.

Until VEX_MODE lands, treat it as coming — the run/validator and rpc subcommands above are what actually exist. Full detail on the design and on what's gated alongside it lives in Runtime Modes and the Environment Variable Reference.

Choosing today

  • Want to vote and (eventually) produce blocks? Use vex-fd run --testnet --bootstrap --identity <keypair> --vote-account <keypair> ... — see Deploying Vexor for the full launch sequence.
  • Want a follower node that serves RPC and never votes? Use vex-fd rpc --testnet --ledger <dir> ... — no identity/vote-account keys are required to vote (though a node still needs an identity keypair to participate in gossip and, if you intend to serve archival data, its own snapshot/ledger).
  • Want vote-only, no block production? Not available yet — wait for VEX_MODE=vote, or track its status on this page.

See also