Governance Structure Tiers
TTG employs a three-tiered approach to decision-making:
1. Standard Governance (via StandardGovernor
- POWER
holders)
The primary governance layer for routine protocol management.
- Purpose: Routine adjustments and list management essential for day-to-day protocol operation.
- Scope: Modifying parameters stored in the
Registrar
like interest rates, time intervals, mint ratios; adding/removing addresses from lists (APPROVED_MINTERS
,APPROVED_VALIDATORS
,APPROVED_EARNERS
). Also controls its own proposal fee. - Voting: Uses
POWER
. Simple majority (Yes votes > No votes) of participating tokens. Occurs only during Voting Epochs. No fixed quorum percentage. - Proposal Types: Restricted to calling specific functions on
StandardGovernor
itself, which then interact with theRegistrar
or internal settings:addToList(bytes32 list, address account)
removeFromList(bytes32 list, address account)
removeFromAndAddToList(bytes32 list, address accountToRemove, address accountToAdd)
setKey(bytes32 key, bytes32 value)
setProposalFee(uint256 newProposalFee)
- Incentives: Drives
Power token
inflation andZero token
rewards for full participation within an active Voting Epoch. Requires aproposalFee
paid in the activeCashToken
. - Lifecycle: Propose (during Transfer Epoch N) → Vote (during Voting Epoch N+1) → Execute (during Transfer Epoch N+2). Expired if not executed in time.
2. Emergency Governance (via EmergencyGovernor
- POWER
holders)
A specialized governance layer for urgent protocol changes, sometimes referred to as the Priority Governor.
- Purpose: Addressing urgent issues or critical parameter changes that cannot wait for the standard cycle.
- Scope: Similar parameter and list changes via the
Registrar
asStandardGovernor
, plus the ability to set theStandardGovernor
's proposal fee. - Voting: Uses
POWER
. High threshold (e.g., 65% of total possiblePOWER
votes at snapshot required). Voting spans the proposal epoch and the subsequent one (voteEnd = voteStart + 1
). - Proposal Types: Restricted to calling specific functions on
EmergencyGovernor
itself:addToList(bytes32 list, address account)
removeFromList(bytes32 list, address account)
removeFromAndAddToList(bytes32 list, address accountToRemove, address accountToAdd)
setKey(bytes32 key, bytes32 value)
setStandardProposalFee(uint256 newProposalFee)
- Incentives: No direct token incentives (no
POWER
inflation orZERO
rewards triggered). No proposal fee required. Designed for exceptional circumstances. - Lifecycle: Propose (any epoch N) → Vote (during Epoch N and N+1) → Execute (anytime during Epoch N or N+1 as soon as threshold is met). Expired if not executed by end of Epoch N+1.
3. Meta-Governance (via ZeroGovernor
- ZERO
holders)
The highest governance layer with authority over the entire governance system structure.
- Purpose: Governing the governance system itself and fundamental protocol settings. Enables protocol upgrades and recovery.
- Scope: Initiating governance contract resets/upgrades, changing the allowed
CashToken
s, adjustingEmergencyGovernor
andZeroGovernor
voting thresholds. - Voting: Uses
ZERO
. Threshold-based (e.g., 65% of totalZERO
supply at snapshot required). Voting spans the proposal epoch and the subsequent one (voteEnd = voteStart + 1
). - Proposal Types: Restricted to calling specific functions on
ZeroGovernor
itself:resetToPowerHolders()
: RedeploysPower token
,StandardGovernor
,EmergencyGovernor
, bootstrapping newPower token
from oldPower token
balances.resetToZeroHolders()
: Redeploys same contracts, bootstrapping newPower token
from currentZero token
balances.setCashToken(address newCashToken, uint256 newProposalFee)
: Changes the designatedCashToken
(must be pre-approved) and sets theStandardGovernor
fee.setEmergencyProposalThresholdRatio(uint16 newThresholdRatio)
setZeroProposalThresholdRatio(uint16 newThresholdRatio)
- Incentives: Control over the system's future; access to protocol revenue via
DistributionVault
. No proposal fee required. - Lifecycle: Propose (any epoch N) → Vote (during Epoch N and N+1) → Execute (anytime during Epoch N or N+1 as soon as threshold is met). Expired if not executed by end of Epoch N+1.