Skip to content

Runtime Modes — Configuration View

Docs-site note: This is the configuration-surface companion to Operating: Runtime Modes, which owns the full VEX_MODE design and mode descriptions. This page focuses on a narrower question: of the configuration that exists today, what's stable and what's gated/experimental?

VEX_MODE: planned, not implemented

A single VEX_MODE environment variable (full / vote / rpc) is spec'd to select a node's operating role in one step. It is not implemented yet — today, role selection happens via CLI subcommand (vex-fd run/validator vs vex-fd rpc), not a single env var. See Validator or RPC Node? for what's real today, and Operating: Runtime Modes for the full design table.

What's gated or experimental today

Two pieces of configuration are worth calling out specifically, because an operator could reasonably assume they are either fully on or fully off, and the truth is more specific:

Transaction-bearing block production — gated OFF

Vexor's leader path produces empty, cluster-accepted blocks today. Transaction-bearing block production exists in the source, behind a gate (VEX_TXBEARING_BROADCAST), and is not enabled. Setting that env is not a supported configuration — it's mentioned here, and in Operating: Runtime Modes, only for completeness. There is no path to transaction-bearing production today short of that gate shipping as a supported feature.

Tiling / core-pinning — dynamic pinner defaults to passthrough

Vexor applies tile-style core-pinning to specific consensus-critical stages (the wave-parallel executor, the ledger persist path) — see Why a Tile Architecture for the rationale. That consensus-critical pinning is deployed and proven, and is on by default as part of the normal launch sequence.

Separately, a generic dynamic thread-pinner also exists in source (VEX_DYNAMIC_PIN), intended to eventually place more of the validator's threads dynamically rather than via the static in-binary core map. It defaults to off — the validator runs today with the static, hand-assigned core map (the "passthrough" default), not the dynamic pinner. Turning VEX_DYNAMIC_PIN on is not part of the proven, deployed configuration.

Where the rest of this lives