​
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

For detailed information about roles and permissions, see the Agora Governor 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

Below is an overview of the proposal states used in Agora.

  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

While the end goal for any protocol is full decentralization (where the DAO and voters have full control over token transfers, protocol upgrades, and more), we recommend a measured, progressive approach to decentralization. At launch, we recommend maximum safety and control:

  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

As the governance system matures:

  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

This progressive approach ensures the governance system can evolve safely while maintaining security and stability.