# Governance

Who controls the protocol today, and how DAO voting will work.

> **Testnet.** A multisig behind a timelock controls the protocol. DAO voting is planned and not active. See [Testnet Status](../../introduction/testnet-status.md).

## What is live today

A **2-of-3 Gnosis Safe** (`0x62c12b8b…`) proposes every change to a **`MultiSigTimelock`** (`0x0400bF…`) with a 7-day standard delay.

The timelock is `DEFAULT_ADMIN` and `UPGRADER` of the core protocol contracts. Upgrades and parameter changes go through the 2-of-3 Safe and the timelock. Some deployer roles from the original testnet deployment remain and are being removed.

A change runs in four steps:

1. **Propose.** The Safe submits the operation to the timelock.
2. **Approve.** The required signers approve the queued operation. The timelock `eta` counts from approval.
3. **Wait.** The 7-day standard delay runs out.
4. **Execute.** The Safe executes the operation onchain.

The delay gives users time to exit or organize a response if a harmful change is queued.

Node admission is not a governance vote. Operators join by application and an install token. See the [Node Setup Guide](../../node-operators/setup-guide.md).

## What is planned

Two-chamber DAO voting through the `GovernanceManager` contract. The contract is deployed, but no proposal has been created. Full DAO governance is on the roadmap for Q1 2028.

`GovernanceManager` will handle node and oracle elections and protocol parameter votes. It cannot upgrade contracts. Upgrades stay with the Safe and the timelock.

### Two chambers

- **Oracle Chamber:** strategy and capital decisions.
- **Guardian Chamber:** security oversight.

The Oracle seat count is dynamic. Ongoing 66% elections set it, up to a ceiling. It is not a fixed 10 seats.

### Thresholds

These are configured in `GovernanceManager` for the planned votes. They do not govern core contract upgrades.

| Rule | Value |
| :--- | :--- |
| To submit a proposal | TrustFingerprint of at least 70% |
| Quorum | 10% of voting power |
| Standard approval | 60% of votes cast |
| Oracle supermajority | 66% of the Oracle Chamber |
| Timelock after a vote passes | 7 days standard, 1 day emergency |

The 66% Oracle supermajority applies to major decisions:

- Treasury and capital deployment
- Allocations above $100K or 5% of AUM
- Strategy approval
- Oracle elections

The contracts involved are `TreasuryManager`, `OracleCoordinator` and `StrategyRegistry`.

These thresholds are the planned DAO design. The 66% threshold enforced onchain today is in `ValidatorConsensus`, which needs 66% agreement and at least 2 validators for attestation consensus.

Only eligible proposers will be able to create onchain proposals. That keeps spam out of the timelock queue. For the steps a proposal goes through, see [Proposal lifecycle](./proposal-lifecycle.md).

## Voting power

Voting weight is set by node tier. It is not time weighted. The multipliers are defined onchain in `TierVotingPower.sol` and apply to a participant's accumulated voting power balance.

| Tier | Voting weight | NODR stake | TrustFingerprint to enter | Governance rights |
| :--- | :--- | :--- | :--- | :--- |
| Micro | 1× | 0 | – | Voting power balance |
| Validator | 2× | 25,000 | 0.70 | Voting power balance |
| Guardian | 4× | 50,000 | 0.80 | Vote (Guardian Chamber) |
| Oracle | 7× | 150,000 | 0.90 | Vote and propose (Oracle Chamber) |

Two tiers have extra gates:

- **Guardian:** governance approval plus a Utility NFT.
- **Oracle:** election by a 66% Oracle vote plus a Utility NFT.

The onchain Utility NFT is free and minted by the protocol. It gates eligibility and is not sold. Unstaking has a 21-day cooldown. See the [Staking guide](../../getting-started/for-users/staking-guide.md).

### The formula

**Voting Power = `NODR_Staked` × `Role_Factor` × `TrustFingerprint_Score`**

- **`NODR_Staked`:** the NODR a participant has staked in the protocol.
- **`Role_Factor`:** the tier weight in the table above.
- **`TrustFingerprint_Score`:** the [TrustFingerprint](../trustfingerprint/README.md) reputation score, on a 0.00–1.00 scale (0–10000 onchain).

The formula is conceptual. It shows how stake, role and reputation combine to set a participant's tier and influence.

Onchain, voting weight comes from the tier multipliers. Stake and TrustFingerprint decide tier eligibility and standing. They do not continuously scale vote weight on their own.

### How a vote will be counted

Voting power will be read at the block where the proposal is created, the snapshot block. Then the system will:

1. Check that the participant runs an eligible node, by its Utility NFT and node tier.
2. Read the participant's current TrustFingerprint to confirm tier standing.
3. Apply the tier multiplier to get the voting weight.
4. Tally votes in the relevant chamber against the quorum, approval and supermajority thresholds.

### Vote escrow

A vote escrow model (veNODR) has been explored as a future, conceptual direction. It is not implemented. Governance uses the tier multipliers above.

## Next

- [Proposal lifecycle](./proposal-lifecycle.md)
- [Voting guide](../../getting-started/for-users/voting-guide.md)
- [TrustFingerprint](../trustfingerprint/README.md)
- [Contract addresses](../smart-contracts/contract-addresses.md)