---
# System prepended metadata

title: Opolis Commons Governance

---

# Opolis Commons Governance 

***Primary Goal***: Come up with an initial governance framework for allowing Commons employee members meaningful governance rights over the Commons without overwhelming them with governance decisions for which they might have little or no context.

***Secondary Goal***: Ensure full-time or dedicated contributors to the Commons operations / technology are able to effectively execute on the goals and decisions made by the Commons membership  without undo interference or micro-management.


## Relevant Considerations For Goverance

* Cooperative Law and Commons Bylaws
* Membership size 
* Token distribution 
* Technical and compliance requirements 
* Participation (Willingness to Participate)
* Information / Context 
* Governance as a distraction 
* Factions / DAO politics 
* Checks and balances 
* Incentives of different constituencies (investors, members, contributors)


## Suggested Decision-making Tiers 

I think we can break the types of decisions being made into a few different tiers in order to determine the best group for making calls on questions / decisions within that tier. 

1. **High-level and directional decisions**: These are decisions that relate to the long-term strategy, health, and operations of the Commons. These decisions should be thought of ones that set or alter a decision that would affect all or most commons members and/or would involve material treasury outlays or other resources. 

Meta Question - What things does the commons want to delegate to the board of stewards and/or the core team? 

What decisions do we want the community to make out of the gate: 
    * Fee changes 
    * Material, Major Core Feature Changes (Benefits and Payroll)
    * Annual Budget / Plan 
        * Material Changes To Tokenomics 
        * New tokens
        * Epoch difficulty
        * Killing tokens
    *  Expansion to new countries / different markets 
    *  Major new products that represent a material shift in direction and fall outside the budget and/or material changes to current product that do the same.   
    *  Changes in governance structure 
    *  New Board of Stewards members
    *  Fees  
    *  New membership classes, material investments, material asset sales, meaningful bylaw changes, acquisitions, or mergers of the Commons Cooperative (or as otherwise required by CO Coop law)

1. **Mid-Level Strategic Circle Decisions or Proposals**: These are decisions that relate to the mid-term strategies with respect to a single area of the Commons (ex. product, marketing, membership, etc). These should be more signal votes from the membership, like on annual product roadmap, or decisions made by the Board of Stewards, like on more granual insurance plan decisions. These decisions probably require more context than the average member might have or want to have. These types of decisions should not have a material affect on every member's experience or the overall health / direction of the Commons.   

    *Examples*: 
    *         Annual product roadmap  
    *         Annual marketing plan / events to attend / sponsorships  
    *         Detailed insurance plan updates 
    *         New initiatives or experiments that don't yet require material amounts of resources
    *         New executive contributor hires (C-level and Executive Stewards)
    *         Compensation of executives 
    *         Removal of executives 


Term limits for the board of stewards members 
Make up of the board 

1. **Day-To-Day Decisions**: These are the day-to-day or week-to-week decisions that should be made by the full-time contributors and executive contributors to the Commons. These decisions require a high amount of context, so rest with the dedicated contributors to the Commons. The Board of Stewards should be kept well aprised of the Common's operations, plans, issues, and teams, but neither the Board of Stewards nor general membership should be bothered with this level of decision making or operations.    

    *Examples*: 
    *         Low- and mid-level hires  
    *         Particular circle budget spending decisions   
    *         Payroll and benefits compliance 
    *         Product or technical sprints 
    *         Membership / marketing operations



## Voting on Tier 1 Decisions - Binding Votes 

Tier 1 decisions involve binding votes made by the employee membership of the Opolis Commons. The impact of these decisions will affect the entire membership and the future of the Commons (hence the reason for having members vote on them in the first place). Given the weight and impact of these votes, it's important to consider: 

* What are the rules of the vote? 
* Who can vote?
* How are votes cast? 
* Are there any checks on the outcome?

### Rules of the Vote?  

There are two potential voting types we've talked about: 

1. Quadratic voting with $WORK tokens 
2. One Member : One Vote 

Each has advantages and disadvantages. One Member: One Vote would be the more standard voting practice in a cooperative setting. Quadratic voting would weight decisions-making more towards early members (and member / investors), who have lots of tokens and thus voting power, even with the handicapp of quadratic calculation. 

Voting periods likely shouldn't be overly long so these decisions can still be made with some swiftness. A good balance between moving fast and moving carefully might be: 

* A two-week proposal discussion period 
* A one-week voting period 

The proposed quorum for binding votes such as this is at least 20% of the eligible members. 

### Who Can Vote?  
We have previously decided that only employee members in good standing can participate in binding votes. 

### How Are Votes Cast?  
Regardless of whether we ultimately land on one member, one vote or quadratic voting, a Snapshot strategy to reflect that decision makes the most sense for our community. This will likely require a concerted effort to move more of our community off Magic wallets or we'll have to build in Snapshot voting functionality for Magic users. 

### Are There Checks on the Outcome? 
We need to be careful what checks we put on the voting power of our community. Community is our biggest competitive moat and, if we lose them, we have failed. At the same time, direct democracy can be messy and subject to hijacking by trolls and those willing to spread misinformation. 

The suggestion is as follows: 
* The Board of Stewards can veto / override a decision of the Commons members by unanimous consent of the Board of Stewards, except when the vote is with respect to the election of a new BoS member. 
* The Commons can override a Stewards vote or veto with a quorum of over 50% of eligible voters and at least 2/3rd of those voters voting to override the vote or veto. 


## Next Steps 

Step 1 (Deadline Nov. 17): Decide on voting weight and mechanics

 [X] Survey: https://opolis.typeform.com/to/JzCLTScJ
 [ ] Custom Snapshot Strategy? 
     * Preference for on-chain vote on Polygon and use the bridge to mint the tokens on mainnet
     * Issue is the Magic wallet, which means probably self-hosting snapshot
     * Start with quadratic voting based on staked work on snapshot
     * Then consider delegation based on vote weight 
     * Then consider consumptive voting (burning work for votes) and reassess quadratic voting generally
     

Step 2 (Deadline Dec. 8): Decide on when / for what people vote / who can make proposals / BoS Members Voting (do they recuse themselves from community votes)
 [ ] Survey: TBD
 [ ] Update Draft Bylaws  

Step 3 (Deadline Jan 19): Decide on checks and balances 
 [ ] Survey: TBD
 [ ] Update Draft Bylaws
 [ ] Announcement / Public Comment Period 
 
 Step 4 (Deadline Feb 2): Consider public comments / feedback 
  [ ] Make Bylaws Adjustments 
  [ ] Final Announcements 
  [ ] Kickoff BoS Election Process 
  
  ## Checks and Balances Discussion 
  
  * ENS as an example. Their decision types mapped to mechanism (on-chain or off-chain). They do delegate decisions out to different groups and organizations to run different aspects of the DAO, deal with admin overhead, take care of projects. 

  * 
 



 
        