Skip to content

Usage & Security

Security Considerations

Key security aspects of the TTG system include:

  • Trusted Parties: The model relies on the honest behavior of several actors:
    • Validators are trusted for offchain data verification and intervention (cancel/freeze).
    • Minters are trusted to manage offchain collateral responsibly.
    • Governance Participants (POWER/ZERO holders and delegates) are trusted to vote in the protocol's best interest.
  • Governor Security & Access Control:
    • Modifying the Registrar is strictly limited to StandardGovernor and EmergencyGovernor.
    • Proposal actions within governors are restricted to predefined internal functions targeting self, preventing arbitrary code execution by proposals.
    • Epoch-based locks on POWER token transfers/delegations during Voting Epochs are a key defense against StandardGovernor vote manipulation.
    • ZeroGovernor holds significant, concentrated power over the entire governance structure via the resetTo* and threshold/CashToken setting functions.
  • Voting Thresholds:
    • EmergencyGovernor and ZeroGovernor employ high voting thresholds requiring substantial consensus (minimum _MIN_THRESHOLD_RATIO of 2.71% enforced, typically set much higher like 65%), protecting against capture but demanding significant coordination for action.
    • StandardGovernor uses economic incentives (POWER inflation / ZERO rewards) rather than a fixed quorum percentage to encourage participation, relying on rational actors voting to avoid dilution/missed rewards.
  • CashToken Safety: The system relies on the assumption that allowed CashTokens (list controlled by ZeroGovernor, initially set at deployment) are standard, well-behaved ERC20 tokens without malicious hooks (e.g., transfer fees, reentrancy vectors, rebasing). Using non-standard tokens could introduce vulnerabilities. WETH and M are the currently expected/intended CashTokens.
  • Reset Mechanism (ZeroGovernor): The ability for ZeroGovernor to redeploy core governance contracts (resetToPowerHolders, resetToZeroHolders) is the ultimate control mechanism. It enables protocol upgrades and recovery but represents a central point of authority vested in ZERO holders. Execution mid-epoch effectively cancels ongoing proposals in the old governors.
  • Inflation/Reward Complexity: The intricate interplay between StandardGovernor tracking voter participation per epoch, Power token calculating and deferring inflation realization (markParticipation, _sync), and Zero token receiving mint calls requires precise implementation. Bugs could disrupt core incentives.
  • Epoch-Based Timing: The system relies heavily on the PureEpochs mechanism for proper functioning (voting windows, transfer locks, auction timing). All participants must be aware of the current epoch status and restrictions.
  • Emergency Actions: The EmergencyGovernor provides faster execution for urgent needs but requires a higher consensus threshold, balancing responsiveness with security.

Roles in Governance

  • Power token Holder: Owns POWER. Benefits from POWER inflation if their voting power (direct or delegated) fully participates in StandardGovernor voting epochs. Can vote directly or delegate. Can purchase discounted POWER in auctions. Subject to dilution if inactive.
  • Power token Delegatee: An address (can be the holder themselves) to which POWER voting power is delegated. Casts votes in StandardGovernor and EmergencyGovernor. If they vote on all StandardGovernor proposals in an active epoch, they trigger POWER inflation for the holder and receive ZERO token rewards directly to their own address.
  • Zero token Holder: Owns ZERO . Can vote in ZeroGovernor or delegate. Can claim accumulated assets from the DistributionVault pro-rata to their ZERO holdings in past epochs. Benefits indirectly from POWER auctions (proceeds go to Vault).
  • Zero token Delegatee: An address (can be the holder themselves) to which ZERO voting power is delegated. Casts votes in ZeroGovernor. Does not directly receive ZERO rewards from StandardGovernor voting (those go to the POWER Delegatee).
  • Proposer: Any address can create proposals in any governor. Must pay a fee in CashToken for StandardGovernor proposals (refunded on success). No fees for EmergencyGovernor or ZeroGovernor.
  • Executor: Any address can call execute() on a Governor for a passed proposal (Succeeded state) during its valid execution window.
  • Distributor (Vault): Any address can (and should periodically) call distribute(token) on the DistributionVault to ensure new funds are accounted for and become claimable by ZERO holders for the relevant epoch.

Interacting with TTG

  • Voting: Use castVote, castVotes, or their WithReason / BySig variants on the appropriate Governor (StandardGovernor, EmergencyGovernor, ZeroGovernor). Check the proposal state() and be mindful of epoch restrictions (esp. StandardGovernor voting only in Voting Epochs).
  • Delegation: Use delegate or delegateBySig on Power token (only during Transfer Epochs) or Zero token (anytime). Remember ZERO rewards go to the POWER delegatee.
  • Checking POWER Balance: Crucially, always call Power token.sync(account) before relying on Power token.balanceOf(account) if you expect the balance might have changed due to inflation. This function realizes any pending inflation into the actual balance. Use getPastVotes for historical voting power checks (which inherently accounts for inflation up to that point).
  • Claiming Vault Rewards: Call DistributionVault.claim(...) specifying the token and a past epoch range (startEpoch, endEpoch). Use getClaimable(...) to check expected amounts first. Ensure distribute(token) has been called recently for the desired token to make funds available for the latest completed epochs.
  • Power token Auctions: Call Power token.buy(...) during Transfer Epochs. Check amountToAuction() and getCost(amount) beforehand. Ensure your account has sufficient CashToken allowance approved to the Power token contract.

Conclusion

M0's Two-Token Governance system offers a sophisticated and resilient framework for decentralized decision-making. By carefully separating powers across three governor tiers, leveraging a deterministic epoch-based clock, and implementing robust incentive mechanisms via Power token inflation and Zero token rewards/revenue sharing, TTG encourages active participation while maintaining security and adaptability.

The key components work in concert:

  1. Power token and Zero token provide distinct spheres of influence: operational vs. meta-governance.
  2. StandardGovernor, EmergencyGovernor, and ZeroGovernor offer tailored processes for different decision types.
  3. The Registrar ensures a single, secure source of truth for parameters.
  4. The DistributionVault aligns economic incentives for Zero token holders.
  5. The Epoch System creates predictable cycles and enhances security.

The intricate architecture of TTG provides both the flexibility needed for routine adjustments and the security required for long-term protocol stability and evolution. Understanding the specific roles, rules, and interactions of the tokens and contracts is key to effective participation.