On-Chain Governance

Noderr governance is fully on-chain — there is no off-chain Snapshot layer. Authority is split across two distinct systems:

• Core-contract admin and upgrade authority is held by a 2-of-3 Gnosis Safe (0x62c12b8b…) acting through a MultiSigTimelock (0x0400bF…, 7-day delay). The timelock is the DEFAULT_ADMIN and UPGRADER of the core protocol contracts. This is the only path that can upgrade contracts or change privileged core parameters.
• On-chain DAO governance — node and oracle elections plus protocol parameter votes — is handled by the two-chamber GovernanceManager contract. The GovernanceManager is not the core-contract admin authority; it does not upgrade contracts.

This separation ensures that contract upgrades and privileged changes route through a timelocked multi-sig, while community-facing decisions (elections, parameter votes) are settled by on-chain node voting.

Core Contracts

• MultiSigTimelock.sol: The core-contract admin and upgrade authority. It is the DEFAULT_ADMIN and UPGRADER of the core protocol contracts, driven by the 2-of-3 Gnosis Safe with a 7-day standard delay. All contract upgrades and privileged core-parameter changes flow through this timelock.
• GovernanceManager.sol: The on-chain DAO contract. It runs the two-chamber voting process for node/oracle elections and protocol parameter votes. It handles this voting on-chain directly. It is not the core-contract admin authority and cannot upgrade contracts.
• TierVotingPower.sol: Defines voting weight by node tier. Voting power is tier-based, not time-weighted: Micro 1× / Validator 2× / Guardian 4× / Oracle 7×.

The GovernanceManager DAO operates through two chambers: an Oracle Chamber (strategy and capital decisions) and a Guardian Chamber (security oversight).

Governance Thresholds

These thresholds apply to the on-chain DAO (GovernanceManager) — node/oracle elections and parameter votes. They do not govern core-contract upgrades, which are controlled by the Safe + MultiSigTimelock.

• Proposal threshold: a proposer must hold at least 70% TrustFingerprint to submit a proposal.
• Quorum: 10% of voting power must participate for a vote to be valid.
• Standard approval: 60% of votes in favor passes a standard proposal.
• Oracle supermajority: 66% of the Oracle Chamber is required for major decisions: treasury and capital deployment, allocations above $100K or 5% of AUM, strategy approval, and Oracle elections (TreasuryManager, OracleCoordinator, StrategyRegistry).

The On-Chain Process

There are two distinct execution paths depending on what is being changed.

Core-contract upgrades and privileged changes

Contract upgrades and privileged core-parameter changes are executed by the 2-of-3 Gnosis Safe through the MultiSigTimelock:

1. Propose: the Safe submits the operation to the timelock.
2. Approve: the required signers approve the queued operation. The timelock eta begins counting from approval.
3. Wait: the mandatory 7-day standard delay elapses.
4. Execute: the Safe executes the operation, applying the change on-chain.

This path is the sole authority for upgrading contracts.

On-chain DAO proposals (elections and parameter votes)

Node/oracle elections and protocol parameter changes are handled entirely on-chain by the GovernanceManager:

1. Proposal Creation: an eligible proposer (meeting the 70% TrustFingerprint threshold) calls propose() on the GovernanceManager with the exact targets, values, and calldatas. Voting is settled on-chain by node voting power — there is no off-chain Snapshot step.

2. Voting and Timelock Queue: once a vote passes (quorum 10%, approval 60%, or 66% Oracle-Chamber supermajority for major decisions), the proposal is queued via queue(), which sets its eta (earliest time of arrival) when the timelock expires.

3. Execution: after the timelock period has passed, execute() applies the proposal's payload.

Node admission itself is permissionless self-registration through the NodeAdmissionController (Validator and Oracle tiers) — it is not gatekept by a governance proposal.

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: The Guardian Chamber, as the security-oversight body, 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.