Validator Governance

Validator governance is consensus state. Validator membership intent changes only through protocol-versioned transactions executed in committed blocks.

Transactions

• REGISTER_VALIDATOR_NODE: registers a new validator node and validator row.
• SUSPEND_VALIDATOR: marks an active or pending validator as suspended.
• REACTIVATE_VALIDATOR: restores a suspended validator to active.
• RETIRE_VALIDATOR: permanently retires a validator.
• UPDATE_VALIDATOR_ENDPOINT: updates operator endpoint metadata and Raft addresses.
• UPDATE_VALIDATOR_VOTING_POWER: updates consensus-state voting power for future BFT engines.

All validator governance transactions require chain:admin. Genesis grants chain:admin through chain_access_rules; system/genesis execution remains allowed.

Operators can build and submit validator governance transactions with the generic transaction CLI:

npm run noos -- tx build --type REGISTER_VALIDATOR_NODE --payload-file validator.json --signer-public-key="<admin-public-key>" --signer-private-key-path admin.key --output validator-tx.json
npm run noos -- tx submit --file validator-tx.json --yes

The CLI does not directly mutate validator tables. It signs canonical transactions and submits them through /transactions.

State

Validator governance state hashes include:

• node_id
• organization_id
• public_key
• endpoint
• raft_http_url
• raft_tcp_address
• status
• voting_power
• metadata

Statuses are pending, active, suspended, and retired. Retired validators cannot be reactivated.

Runtime Membership

Governance defines the intended active validator set. Governance transactions do not hot-reconfigure Raft voters by themselves. For HashiCorp Raft, operators can review the reconciliation plan and explicitly execute runtime membership changes. Noosraft still requires configuration/deployment changes.

Observability reports both the governance active set and the runtime Raft voter set, plus a warning when they differ.

Use Raft Membership Reconciliation to produce an operator plan that lists missing runtime validators, unexpected runtime voters, endpoint mismatches, and safe operations. The plan is read-only until an operator explicitly approves execution.

Peer Scoring Boundary

Peer scoring is local operational defense only. Ban, quarantine, timeout, and malformed-peer penalties never mutate validator status or voting power.

Snapshots And Replay

Snapshots include chain_access_rules and validator governance metadata. Replay re-executes governance transactions deterministically, including canonical failures such as non-admin attempts or reactivation of retired validators.

Not Implemented Yet

• automatic governance-to-Raft membership changes
• staking
• slashing
• Byzantine evidence handling
• governance-driven key/certificate rotation