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.
- Initial Idea: An idea for improving the protocol is formulated by a community member.
- 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.
- 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.
- 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).
- 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.
- 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.
- On-Chain Proposal: A trusted, privileged entity (e.g., a community multi-sig or the Noderr Foundation) creates the corresponding proposal on the
GovernanceManagercontract. This on-chain proposal contains the exact executable payload that was approved off-chain. - Queued in Timelock: The proposal is immediately queued in the
Timelockcontract. This initiates a mandatory waiting period (e.g., 2-7 days, depending on the proposal's criticality). - 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.
- Timelock Expires: After the waiting period ends, the proposal becomes executable.
- Execution: Anyone can call the
execute()function on theGovernanceManager. TheTimelockcontract then executes the proposal's payload, calling the target contracts and making the approved changes. - Lifecycle Complete: The proposal is now considered
Executed, and its lifecycle is complete.