Validators

A validator is any entity that runs part of the model on its own hardware, signs its outputs, and stakes the network's token against the correctness of those outputs. Validators are the network's compute substrate.

What validators do

A validator does one or more of:

1. Serves inference. Runs forward passes of a published checkpoint against incoming queries.
2. Trains. Participates in distributed training runs as a worker in a 3D-parallel job.
3. Evaluates. Runs eval suites against new checkpoints before they are promoted.
4. Stores data. Holds a shard of the content-addressed dataset and serves it on demand.
5. Audits. Re-executes a sample of other validators' outputs and submits challenges on mismatch.

Most validators do a subset, not all. Hardware tiers and the validator's own selection determine which roles it can take.

Hardware tiers

The tier of a validator is verified at registration by an on-chain attestation that captures hardware identity through TEE-issued certificates. Tier upgrades require re-attestation; tier downgrades happen automatically when a validator fails to meet its tier's latency SLO.

Critical: the Light tier exists because the codex's commitment is that participation should not require institutional capital. A node with a single 24GB GPU can serve at least the language surface in its distilled variant and the audit role for all surfaces.

Staking and slashing

Each validator stakes the network's token. The stake serves two functions: it provides a bond against fraud, and it weights the validator's selection probability in the routing layer.

The slashing conditions are:

1. Output divergence. An audited query whose output disagrees with the consensus output beyond the surface's tolerance window. Penalty: configurable, currently $0.5\%$ of stake per incident, capped at $20\%$ per epoch.
2. Attestation forgery. A signed attestation that does not match the validator's actual computation. Penalty: full slash.
3. Liveness failure. Sustained failure to respond to dispatched jobs within the latency SLO. Penalty: temporary deregistration, no stake loss.
4. Censorship. Selectively dropping queries based on content. Penalty: full slash, after challenge.

Slashing requires a successful challenge through the challenge service. Challenges have a 48-hour window during which any participant can submit a fraud proof. Successful challengers receive a fraction of the slashed stake.

Selection and rewards

Validators are selected for jobs by a probability proportional to

$\Pr(\text{validator } i \mid \text{job}) \propto s_i^\alpha \cdot q_i \cdot \mathbb{1}[\text{tier eligible}]$

where $s_i$ is stake, $q_i$ is a moving-window quality score from prior audits, and $\alpha \in [0, 1]$ is a stake-weighting parameter set by governance. With $\alpha = 1$ the selection is purely stake-weighted; with $\alpha = 0$ it is purely quality-weighted. The current operating point is $\alpha \approx 0.7$.

Rewards are paid from the treasury per attested job. Reward magnitude is a function of the surface, the latency tier, and the duration of the job. Validators receive rewards in the network token; the relationship between the token and the validator's operating costs is the subject of Token.

Verification mechanics

Validator output is verified statistically, not cryptographically. The mechanisms:

Random redundant dispatch. A fraction $p_{\mathrm{audit}}$ of jobs are dispatched to two validators. Mismatches trigger a third-validator resolution and, if confirmed, slashing of the divergent party.

Eval-suite sampling. Periodically, every validator runs a standard eval suite against the active checkpoint. Reported scores are cross-validated; outliers are flagged.

TEE attestation. For training jobs, the worker process runs inside an attested execution environment. The attestation binds the computation to specific hardware and to a specific code binary.

Loss-curve commitment. For training, the validator commits at each checkpoint to a hash of the loss curve. Re-execution must reproduce the curve within an $\varepsilon$-band.

None of these mechanisms provides cryptographic certainty. Together, with the slashing bond, they provide economic certainty: the expected cost of cheating exceeds the expected gain by a configurable margin.

Economic model

Let $C_{\mathrm{cheat}}$ be the cost to a validator of an attempted fraud (mostly the slashing risk), $G_{\mathrm{cheat}}$ be the expected gain (typically negligible for inference, larger for training jobs), and $p_{\mathrm{detect}}$ the probability of detection. The honest-validator condition is

$p_{\mathrm{detect}} \cdot C_{\mathrm{cheat}} > G_{\mathrm{cheat}}.$

The protocol's parameters are set to keep this inequality wide. Specifically:

• $p_{\mathrm{detect}}$ is bounded below by $p_{\mathrm{audit}}$, which is configurable per surface.
• $C_{\mathrm{cheat}}$ is the validator's stake, which is constrained to a minimum proportional to the maximum job value the validator is eligible for.
• $G_{\mathrm{cheat}}$ is upper-bounded by the protocol's per-job payment.

What validators are not

A validator is not a node in a consensus protocol. The chain achieves consensus through its own validator set; OGI validators provide compute, not consensus. The two notions of "validator" overlap in name only.

A validator is not a customer. Validators do not consume the model's output; they produce it. End users consume through gateways. The two roles are deliberately separate.