Network Governance and Voting

Novij Protocol governance is recorded in the public append-only Network System Chain. It holds network settings, Relay, Storage and Service registries, proposals, voting snapshots, ballots, and results. Relay nodes finalise decisions automatically and deterministically under Protocol v3 rules.

Governance and voting in the Novij Protocol Network System Chain

1. Four voting groups

  • Relay — 22.5%. Active Relay nodes receive weight from verified effective uptime.
  • Storage — 22.5%. Active, continuously ready Storage nodes receive weight from verified availability.
  • Wallet — 45%. Weight comes from eligible balances and delegated tokens.
  • Service — 10%. Only governance-approved services participate; multiple agents of one service do not multiply its external weight.

Consensus uses integer ppm values: 225000, 225000, 450000, and 100000. Percentages above are for display only.

2. Voting-power snapshot

  • At vote start, VOTE_SNAPSHOT fixes eligible voters, balances and delegation, active nodes and services, availability, and group weights.
  • Balance, delegation, node status, and uptime changes after vote_start do not alter an open vote.
  • Wallets must meet min_wallet_cast_power from active System Settings; the initial recommendation is 10,000 NPT.
  • Smaller holders can delegate locked voting power to another wallet without granting the delegate the right to spend those tokens.

3. Options and counting

  • The allowed options are YES, NO, ABSTAIN, and COMPLAINT.
  • A non-vote is not ABSTAIN, does not count toward quorum, and is never transferred to the leader.
  • Explicit ABSTAIN is added to the single leading option within its group; when leaders are tied, it remains neutral.
  • Quorum is checked for every active group, then its result contributes to the final score using the fixed group weight.

4. Duration and automatic finalisation

  • A proposal lasts from 3 to 10 days.
  • A shorter duration requires an extra deposit: (10 − duration_days) × 200 NPT under the initial System Settings.
  • A mathematically irreversible YES may pass early. NO, COMPLAINT, NO_QUORUM, and other mutable outcomes wait until vote_end.
  • Relay nodes run finalisation automatically; neither a post-deadline user signature nor an open voting page is required.

5. Proposal types and thresholds

  • Settings, node/service approval, and node removal: over 50%; settings_update requires a 100 NPT deposit.
  • Token mint: 1,000 NPT deposit and at least 66.667%.
  • Blocklist/delete: 10 NPT deposit and over 50%; blocking wallet actions requires 25 NPT and at least 60%.
  • DevFund wallet change: 5,000 NPT deposit, over 70%, and a recommended seven-day effective delay.
  • Emergency action: requires a follow-up emergency_ratification vote with a threshold over 50%.

The effective deposits, quorum rules, and thresholds always come from active System Settings, not from local UI configuration.

6. Outcomes and deposits

  • NO_QUORUM or a tied lead does not change network state.
  • The deposit is returned after a passed YES, an ordinary NO, or a missed threshold without proven misconduct.
  • A winning COMPLAINT transfers the deposit to the DevFund/penalty wallet and applies a 12-hour cooldown to the initiator.
  • NPT is not burned: penalties and confiscated deposits are transferred to wallets selected by System Settings.

7. Blocklist and deletion

  • BLOCKLIST_ADD prevents future operations on a target but does not itself require physical data deletion.
  • DELETE_TOMBSTONE requires Storage nodes to remove the payload; only minimal metadata and proofs remain in the system chain.
  • Relay runtime tables are a projection of the Network System Chain and cannot replace it as the source of decisions.