Proposal Lifecycle

All significant changes to the Noderr Protocol follow a structured, multi-stage lifecycle designed to ensure transparency, security, and robust community consensus. The process combines flexible off-chain discussion and voting with secure, on-chain execution.


The 4 Phases of a Proposal

Phase 1: Community Discussion & Temperature Check (Off-Chain)

This is the ideation stage where the proposal is born.

  1. Initial Idea: An idea for improving the protocol is formulated by a community member.
  2. Community Feedback: The idea is shared and discussed in the Noderr community channels (e.g., Discord, forums). This allows for initial feedback, refinement, and identification of potential issues.
  3. Temperature Check: The proposer creates an informal "Temperature Check" poll on Snapshot to gauge broader community sentiment. This is a low-stakes way to see if the idea has enough support to warrant a formal proposal.

Phase 2: Formal Proposal & Voting (Off-Chain)

If the temperature check is positive, the proposal moves to the formal voting stage on Snapshot.

  1. Formal Submission: The proposer submits a detailed, structured proposal on Snapshot. It must include a clear title, a comprehensive description of the change, the rationale behind it, and the specific actions to be taken (including target contracts and function calls if applicable).
  2. Voting Period: A fixed voting period begins (e.g., 5-7 days). During this time, community members can vote for, against, or abstain from the proposal using their calculated Voting Power.
  3. Consensus Reached: For the proposal to pass, it must meet two conditions at the end of the voting period:
    • Quorum: A minimum percentage of the total network voting power must participate.
    • Approval Threshold: A majority of the votes cast must be in favor of the proposal.

Phase 3: Timelock & Review (On-Chain)

Once a proposal successfully passes on Snapshot, it moves on-chain for execution.

  1. On-Chain Proposal: A trusted, privileged entity (e.g., a community multi-sig or the Noderr Foundation) creates the corresponding proposal on the GovernanceManager contract. This on-chain proposal contains the exact executable payload that was approved off-chain.
  2. Queued in Timelock: The proposal is immediately queued in the Timelock contract. This initiates a mandatory waiting period (e.g., 2-7 days, depending on the proposal's criticality).
  3. Final Review & Veto Window: The timelock serves as a final, critical review period. It gives the entire community a chance to examine the queued transaction and its potential impact. If a flaw is discovered or the proposal is deemed malicious, a designated Guardian council has the power to veto the proposal before it can be executed.

Phase 4: Execution (On-Chain)

The final step is the execution of the proposal, making the change a permanent part of the protocol.

  1. Timelock Expires: After the waiting period ends, the proposal becomes executable.
  2. Execution: Anyone can call the execute() function on the GovernanceManager. The Timelock contract then executes the proposal's payload, calling the target contracts and making the approved changes.
  3. Lifecycle Complete: The proposal is now considered Executed, and its lifecycle is complete.

results matching ""

    No results matching ""