On-Chain Governance

While off-chain signaling on Snapshot is the primary method for community discussion and consensus building, the execution of proposals that alter the protocol is handled securely on-chain through the GovernanceManager contract.

This separation ensures that only proposals with significant community backing and proper technical validation can modify critical protocol parameters, upgrade contracts, or manage the treasury.

Core Contracts

• GovernanceManager.sol: The central hub for on-chain governance. It manages the proposal lifecycle after a Snapshot vote has passed, including queuing, timelocks, and execution. It does not handle voting directly; it acts upon the results of off-chain votes.
• GovernanceVoting.sol: A contract that works in tandem with the manager to define the structure of proposals and voting receipts. It is designed to be extended for different voting strategies.

The On-Chain Process

1. Proposal Creation: After a proposal has successfully passed on Snapshot, a privileged role (e.g., a multi-sig held by the Noderr Foundation or a council of elected Guardians) creates a corresponding on-chain proposal by calling propose() on the GovernanceManager.

   • The on-chain proposal must contain the exact targets, values, and calldatas that were specified and approved in the Snapshot vote.
   • A link to the successful Snapshot proposal is included in the on-chain proposal's description for verification.

2. Timelock Queue: Upon a successful propose() call, the proposal is not yet active. A separate, privileged action must call queue() on the GovernanceManager. This queues the proposal and sets its eta (earliest time of arrival), which is the timestamp when the timelock expires. The timelock duration is fixed in the contract:

   • Standard Proposals: 2 days (timelockDelay)
   • Emergency Proposals: 1 day (emergencyTimelockDelay)

3. Execution: After the timelock period has passed, anyone can call the execute() function on the GovernanceManager. This will execute the proposal's payload, making the specified changes to the protocol.

Security Mechanisms

• Timelock: The mandatory delay is the most critical security feature, giving users time to exit the system or organize a response if a malicious or harmful proposal is queued.
• Veto Power: A designated Guardian or Oracle council holds the power to veto a queued proposal during the timelock period. This is an emergency-only function to prevent hostile takeovers or the execution of flawed proposals.
• Role-Based Access: The ability to create on-chain proposals is restricted to trusted entities, preventing spam and ensuring that only vetted proposals make it to the timelock queue.