# 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.