Run a Validator

The live testnet, veylith-testnet-10, is operated by a closed set of 4 validators. The core node repository is closed until mainnet, when it becomes source-available, so validator operation is not yet open to the public. A public validator program with signed binaries and a Docker image opens later; this page records the roles and guarantees that program will build on. The protocol direction favors a deterministic validator registry, state-derived active sets, and explicit key roles.

Key roles

• Operator account: owns validator lifecycle actions, signed with the operator's ML-DSA-44 account key.
• PQ consensus key: ML-DSA-44 key material used in hybrid consensus certificates.
• Classical consensus key: Ed25519 session key used alongside the PQ key in the same certificates.
• Validator identity: the registry record that binds operator, keys, status, and stake-derived voting power.

Consensus model

Validators participate in a DAG that provides availability and ordering, and finality comes from checkpoint certificates signed by the validator set with hybrid ML-DSA-44 + Ed25519. There is no view-based pacemaker and no leader timeout to tune. Anti-equivocation runs as a liveness-class availability collector: an equivocating validator loses the ability to make progress, and there is no slashing of stake.

Identity binding

Node startup is identity-bound. A node refuses to start when the configured chain_id or genesis hash does not match, and refuses to open a database stamped by a different chain. A misconfigured validator therefore fails fast instead of joining the wrong network.

Economics checks

Operators should monitor the public economics summary:

curl https://test.noxycore.io/v0/economics/summary

It reports total supply, total bonded amount, and treasury balance. Per-validator economics endpoints are not exposed over the public HTTP API today.

Validator voting power must come from committed bond state. Local config can point a node at its own keys, but it must not change active-set membership.

Documentation rule

When this page grows into a command guide, every command should show the exact config path, chain ID expectation, and failure mode. Operator docs should be boring and repeatable.