Governance Technical Overview

​

System Components

​

Core Components

• Token
  • Tracks token holder balances
  • Manages voting power of delegates
  • Enables voting on proposals
• Governor
  • Provides primary access control logic
  • Processes proposals and associated votes
  • Determines proposal success or failure
  • Manages voting periods and thresholds
• Timelock
  • Receives instructions from governor for successful proposals
  • Implements time delay for stakeholder response
  • Executes approved instructions after delay period

​

Additional Components

• Modules (e.g., approval voting)
  • Provide optional voting strategies
  • Enable features like multiple choice voting
  • Extend governor functionality

​

Privileged Roles

• Governor Manager
  • Trusted address with proposal submission rights
  • Can bypass proposal threshold requirements
  • Typically controlled by the foundation initially
• Security Council
  • Trusted multisig with protocol upgrade capabilities
  • Can perform emergency upgrades when needed
  • Ensures protocol safety during critical changes
• Governor Admin
  • Trusted multisig with broad system privileges
  • Enables manual execution and intervention
  • Can be same address as Security Council (optional)
  • Acts as last-resort safeguard

​

Proposal Lifecycle

​

Example Voting Cycle

​

Proposal States

1. PENDING The proposal has been created but is not yet ready for voting. This is typically a waiting period before voting begins.
2. ACTIVE The proposal is currently in its voting period and can accept votes. During this state, only admins can cancel the proposal.
3. CANCELLED
   The proposal was cancelled by either the admin or the proposer (depending on the governance system). Once cancelled, the proposal cannot be executed.
4. DEFEATED
   The proposal failed to meet the required voting thresholds or quorum requirements and cannot be executed.
5. SUCCEEDED
   The proposal passed the voting requirements and is ready to be queued for execution. Successful proposals can be queued by calling the queue function. Anybody with gas can make this transaction.
6. QUEUED
   The proposal has been queued and is waiting for the timelock period to pass. During this state:
   • The proposal can still be cancelled by the admin
   • Once the timelock period passes, it becomes eligible for execution
7. PASSED The proposal has been queued for execution, but for any reason hasn’t been executed on chain after 10 days. Reasons might include nobody calling the execute function or a proposal with invalid on-chain instructions. Example would include a signal-only vote done on-chain with no-op instructions that cause the timelock to revert. This state exists only off-chain, to clarify that no action is needed by the user, since it’s off chain.
8. EXECUTED
   The proposal has been executed, meaning its contained actions have been carried out. This is the final state of a successful proposal.
9. CLOSED
   The proposal’s voting period has ended but it did not meet the requirements to succeed. This is similar to DEFEATED.

​

Initial Launch Configuration

1. High Proposal Threshold
   • Set initially high to restrict proposal creation
   • Only Governor Manager (Foundation) can propose initially
   • Enables controlled governance rollout
2. Manual Protocol Upgrades
   • Protocol upgrades executed manually at first
   • Continues until successful proposal track record
   • Ensures maximum safety during early phase

​

Example Proposal Types

1. Token Transfer Proposal
   • Fully executed on-chain
   • Standard governance process
   • Automated execution through timelock
2. Normal Protocol Upgrade
   • Requires Security Council execution
   • Manual implementation for safety
   • Additional verification layer
3. Emergency Protocol Upgrade
   • Bypasses standard governance process
   • Direct Security Council execution
   • Reserved for critical situations

​

Progressive Decentralization

1. Proposal Threshold Reduction
   • Gradually lower proposal requirements
   • Enable broader community participation
   • Allow smaller token holders to propose
2. Upgrade Process Evolution
   • Move toward fully on-chain upgrades
   • Reduce manual intervention
   • Increase automation of execution
3. Community Empowerment
   • Expand voting power distribution
   • Enhance proposal creation access
   • Foster decentralized decision-making