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.
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:
- Propose. The Safe submits the operation to the timelock.
- Approve. The required signers approve the queued operation. The timelock
etacounts from approval. - Wait. The 7-day standard delay runs out.
- 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.
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.
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.
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 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:
- Check that the participant runs an eligible node, by its Utility NFT and node tier.
- Read the participant's current TrustFingerprint to confirm tier standing.
- Apply the tier multiplier to get the voting weight.
- 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.