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 open, off-chain community discussion with secure, on-chain voting and execution. Governance is on-chain only; upgrade and admin authority over the core contracts ultimately rests with a 2-of-3 Gnosis Safe operating behind a 7-day MultiSigTimelock.

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 gauges broader community sentiment through informal signaling in the community channels. This is a low-stakes way to see if the idea has enough support to warrant a formal on-chain proposal.

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

If the temperature check is positive, the proposal moves to the formal, on-chain voting stage in the GovernanceManager contract.

1. Formal Submission: The proposer submits a detailed, structured proposal on-chain to the GovernanceManager contract. 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 of 7 days begins. 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: At least 10% of the total network voting power must participate.
   • Approval Threshold: At least 60% of the votes cast must be in favor of the proposal. Major decisions, such as treasury and capital deployment, allocations above $100K or 5% of AUM, and strategy approvals, require a higher 66% Oracle Chamber supermajority.

Voting power is tier-based, weighted by node tier (Micro 1x / Validator 2x / Guardian 4x / Oracle 7x), and proposals are evaluated across the protocol's two governance chambers: the Oracle Chamber (strategy and treasury oversight) and the Guardian Chamber (security oversight).

Phase 3: Timelock & Review (On-Chain)

Once a proposal successfully passes the on-chain vote, it moves to timelocked execution.

1. Queued by the Safe: The protocol's 2-of-3 Gnosis Safe queues the corresponding operation in the MultiSigTimelock contract. This queued operation contains the exact executable payload that was approved by the vote.
2. Queued in Timelock: Once approved by the Safe signers, the operation is subject to a mandatory 7-day standard delay before it can be executed (configurable between a 1-hour minimum and a 30-day maximum).
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, the Guardian Chamber 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: The Gnosis Safe calls executeOperation on the MultiSigTimelock contract, which 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.