Validator node

A validator secures the network: it discovers peers from the on-chain registry, receives signed commitment records from providers, audits a sampled fraction of replies, and (when it holds the settlement role) gathers peer co-signatures and submits the on-chain quorum settle. The binary is ogong-validatord.

Build

cargo build --release --features settlement \
  -p validator-service --bin ogong-validatord --bin ogong-verifierd

The settlement feature is what enables on-chain settle; build without it for an audit-/cosign-only node.

Run

ogong-validatord \
  --bind 0.0.0.0:4533 \
  --alpha 1 \
  --verifier-endpoint 127.0.0.1:4544 \
  --verifier-cert /path/to/verifier.der

Key flags

Without --verifier-endpoint, audited replies await a manual verdict submission instead of auto-dispatch. With no --peer, the node draws its audit beacon solo.

In production the audit randomness comes from the threshold-BLS committee beacon (set up by a dealerless DKG across the registered validators); the per-validator VRF described by --peer is the bootstrap fallback used until that committee key is established.

Discovery - no manual peering

A validator reads the on-chain registry every ~30s (at confirmed commitment) to discover peers. You stake and register the node on-chain with its real endpoint and cert; from then on the mesh finds itself. The --peer flag exists for the audit beacon and for setups without registry discovery.

consensus_id = sha256(cert) ties a registered validator to the cert it presents over QUIC, so peers pin each other by their on-chain-registered certs.

Settlement environment

When a node holds the settlement role it needs these (the evm feature reads them):

There is no authority key: a release settles only when k co-signatures clearing the stake-weighted two-thirds quorum are assembled. Cosign-only peers run without the sink env (strip it with env -u if reusing a shell).

A peer only co-signs a release it independently holds in its own log, so the handling node forwards each metered record to its co-signer peers before it settles; a peer that never received the record declines. This is automatic; peers just need to be reachable on their bound address.

The whole committee, whatever its size, settles in one call: the handling node passes the gathered co-signatures as a Signature[] array and the settle contract ecrecovers each, sums the distinct signers’ bonded stake, and releases once it clears the quorum. There is no per-signer account triple, no address lookup table, and no accumulate-then-settle path; committee size is bounded by gas, not transaction size. Measured settle gas is roughly 192k / 239k / 346k at k = 3 / 9 / 21 co-signers.

Staking and activation

Anyone can become a validator with no gatekeeper: bond MIN_VALIDATOR_STAKE and register on-chain. Newly-staked stake counts toward the quorum only after an activation delay (set at deploy time via OGONG_ACTIVATION_SECONDS; 0 locally), so a freshly-bonded stake cannot be used to front-run an in-flight settle. Activating that stake into the quorum is self-only — you activate your own bond, not anyone else’s (a validator could otherwise activate a peer’s aged-dormant stake at an adversarial moment to spike the quorum bar and revert an in-flight settle) — and the validatord self-activates once the delay elapses, so in practice you only stake and register. The co-signer also binds each settle’s payout to the provider’s on-chain registered address, so the residual can never be redirected. Unstaking removes stake from the quorum immediately.

The verifier

ogong-verifierd is the audit muscle a validator dispatches to. It re-runs sampled steps of a committed trajectory on an independent engine and returns a verdict.

ogong-verifierd \
  --bind 0.0.0.0:4544 \
  --provider-url http://127.0.0.1:11436 \
  --k 2 \
  --cert-out verifier.der

Run the verifier against a separate engine instance from the provider’s; soundness comes from independent re-execution, not co-location.

See How verification works for the audit theory.