Governance

Overview of how governance works — token-weighted voting, proposals, and the scope of community decisions.

DeepNode uses a stake-weighted, validator-delegated governance model with the ability for delegators to override validator votes. It follows the cosmos model.

Governance allows the community to propose changes, vote on protocol upgrades, adjust domain parameters, and manage key economic settings.

The diagram below illustrates the full governance flow, from proposal creation to final outcome.

circle-info

In Phase 1 Governance will be controlled by validators. The following description is for Phase 2.

chevron-rightGovernance Figurehashtag

1. Creating a Proposal

Any network participant can submit a proposal by:

  • locking X $DN in the Proposal Vault,

  • describing the change,

  • and publishing the proposal for review.

This stake is held until the proposal concludes, and returned unless the proposal is vetoed.


2. Voting Actors

Two groups participate in voting:

A. Validators

Validators cast votes that automatically represent:

  • their own stake

  • plus the stake delegated to them (unless overridden)

Validators vote on behalf of their delegators by default.

B. Delegators

Delegators can override their validator’s vote but only with the stake they personally control. This enables decentralized participation without requiring validators to act as passive intermediaries.


3. Voting Options

Participants may choose:

  • Yes

  • No

  • Abstain

  • No with Veto

Votes flow into the Voting Module, which prepares them for tallying.


4. Tallying & Quorum

The Tally Module evaluates votes against the required quorum.

Quorum Requirement:

A minimum of 50% of total voting power must participate.

If quorum is not reached, the proposal automatically fails, and tokens are returned.

If quorum is reached, the system evaluates the results.


5. Decision Outcomes

Once quorum is met, the outcome follows this logic:

A. Pass

  • Yes > 50%

  • Proposal passes

  • Locked tokens are returned

  • Change is enacted

B. Fail (without veto)

  • No > 50%

  • Proposal fails

  • Locked tokens are returned

C. Veto

If No with Veto > 33%, the proposal is vetoed:

  • Tokens locked in the proposal are burned

  • Proposal is marked as failed with veto

  • This protects the protocol from malicious or harmful changes

Last updated