Moderation and Voting

Moderation and voting in the Novij Protocol network

Moderation in the Novij Protocol network relies on bicameral voting and a trust-driven consensus. Decisions are made by nodes and holders, with each chamber contributing 50% of the final weight. Vote weight depends on transparent metrics (uptime, stake) and the trust coefficient R, calculated exclusively from voting history. The obligation to vote applies only to those who opted in (activated the voting right with a deposit). This design ensures resilience, anti-abuse safeguards and participant anonymity.

1. Right and obligation to vote

  • Right ≠ obligation. The duty to vote applies only to participants who opted in — activated their voting right.
  • Deposit for the voting right: 100 NPT. This is required to apply for participation.
  • R < 0.5 → deposit is burned. If the trust coefficient drops below 0.5, the voting right is lost and the 100 NPT deposit is burned in favour of the Dev Fund.

2. Who has the right to vote (two chambers at 50% each)

  • Node chamber (50%). Active relay/storage nodes with paid participation and validated uptime.
  • Holder chamber (50%). Wallets trusted by ≥ 5% of the total supply, excluding wallets that are already part of the node chamber.

A decision is valid only when the majority by weight matches in both chambers.

3. Voting types

  • Minting new tokens.
  • Banning/unbanning addresses.

4. Voting mechanism

4.1 Initiation

  • Any participant with the right to vote (see section 2) may initiate a vote.
  • Creating a vote costs 1 NPT.
  • Default voting duration — 5 days; minimum — 3 days.
  • Accelerating the decision: +1 NPT per day shortened (down to 2 days).

4.2 Participation

  • Only opted-in participants with the 100 NPT deposit vote within their chamber.
  • Participation is free. Abstaining counts as trusting the majority but lowers R.

4.3 Decision-making

  • Each chamber counts the majority by total weight.
  • The outcome is valid only if both chambers agree (each contributes 50%).
  • If one chamber does not vote at all, its 50% weight is counted towards the winning decision of the other chamber.

5. Vote weight mechanism

Vote weight is calculated differently for nodes and holders, yet multiplied by the trust coefficient R in both cases.

5.1 Nodes (relay/storage)

A node’s base weight depends on uptime and is confirmed by heartbeat and logs.

Wnode = (1 + floor(Uptime_in_days / 7)) × R

  • 1 day → W = (1 + 0) × R
  • 45 days → W = (1 + 6) × R = 7R
  • 90 days → W = (1 + 12) × R = 13R
  • Failing to pay the daily fee resets the weight; reconnecting restarts it at 1×R.

5.2 Holders (non-nodes with trust ≥5% supply)

Wholder = √(Stake_in_tokens) × R

  • The square root of stake limits whale dominance.
  • The ≥5% trust threshold is calculated separately from the stake size.

6. Trust coefficient R

Range: 0.5 – 1.5. Applied to both node and holder weights. R is derived solely from voting history.

6.1 Increasing R

  • +0.1 to R for every 30 days of voting without penalties.
  • Gaining +0.5 (e.g. from 1.0 to 1.5) requires 150 days of honest participation.

6.2 Decreasing R

  • Each missed vote: −0.1 (capped at 0.1 per calendar day).
  • Abstaining counts as trusting the majority but still incurs the penalty.

6.3 Blocking and burning

  • If R < 0.5 the participant loses the voting right.
  • The 100 NPT deposit is burned in favour of the Dev Fund.

7. Moderation outcomes

7.1 Blocking

  • If the weighted majority in both chambers votes “For”, the address/object is blocked.
  • The network denies service (block reads/writes, authorisation, etc.).

7.2 Unblocking

  • Triggered by a new vote; the rules mirror the original procedure.

8. Technical notes

  • Node uptime is confirmed via heartbeat and network logs.
  • Network parameters (e.g. acceleration fee) may be adjusted by a dedicated vote.
  • All votes and results are on-chain and auditable.