---
# System prepended metadata

title: Rules of the Game

---

# Rules of the Game

## Governance

https://vitalik.ca/general/2022/09/20/daos.html

This is easier to write out than the meme, so I can be more concise here

Essentially, we are building a game. So it's important to discover win states for our community, and individuals within the community. 

Also, with all games, there are strict, explicit rules and roles that we all must follow in order for the game to fair and fun for all parties involved. 


### Win State

- We all win when we have more prospective clients than operating capacity to take on said work. We pick and choose the work that interests (both financially and ideologically) 
- Every core member in our DAO earns well above the industry standard. 
- We have a repuation for providing the highest quality service and products in the space

### Governance Rules

- Your voting power is proportional to your stake
- Your stake cannot be bought. It can only be earned. 
- The amount of stake you earn each month is proportional to your position within the DAO heirarchy x your level of commitment (with a large bonus for full-timers)
- You get bonus stake based on customer satisfaction. 
- You get bonus stake for work completed
- You get bonus stake for doing extra work that you may not be paid for. 

Ok, but who decides that. What is this heirachy? 

### Authority Rules

- Each division/domain has a lead. 
- The DAO votes that lead in. The DAO is also responsible for voting that lead out. 
- That leader is responsible for all hiring/firing within that division. They also handle things like reviews and promotions. 
- A lead handles a dispute between members of a division. 
- Leads handle disputes between members of differing divisions. 
- Leads are responsible for all output/deadlines within their own division. 
- Leads also work, unless their division is so large that they only have to time to work in a managerial capacity. 
- Sub-leads can also be used within a division, though a shallow structure is better. 
- Each division has defined roles for every member, even if that role is somewhat elastic. 
- The leader can award bonus stake (eg. for extra work), but must get approval from other DAO leads. Usually there is an agreed upon rate. 
- Division leads take full responsibility for everything that happens within their own domain. 
- Division leads are ultimately responsible for major DAO decisions. 
- If the division feels its necessary to elect a single leader, they may do so
    - but only if there is a clear exit path and set term.
    - At the end of that term there is a review to see if we want to continue 
    - Division leads can remove the dictator at any time. 
    - Division leads can extend a dictator's term.
- If members within a division have majority non-confidence vote in their leader, then DAO operations cease and they work full time on finding a resolution. 
    - Sometimes the DAO may elect to demote, fire, or kick that leader
    - Hopefully, that leader and the rest of division find a comprimise and can continue work. 
- The DAO can elect to remove entire divisions. 

The underlying spirit of this structure is to ensure that the true authority comes from the bottom up, while maintaining accoutability and vision throughout a given domain. 

The desired effect is that these rules exist in case of emergency, but are rarely used. We want people to focus on their craft, not politics. By giving them explicit paths to handle disagreements, we take the guess work out of trying to figure out how to deal with them when they arise. 


### Growth/Revenue Rules

- We operate under the assumption that his DAO will generate a profit
- We operate under the assumption that it will be extremely hard to turn a meaningful profit in the beginning and that sacrifices will be necessary to get there. 
- 5% of revenues are sent to the DAO treasury before being distributed. Leads can vote to change this rate, but ideally this number is small. We want to maximize how much we can offer talent. 
- Before a given project or service, the lead informs members of what the pay will be. Ideally there will be set rates for certain services (eg. Hourly rate for consultion) that help automate this process. 
- If a domain does not provide revenue, or is not directly responsible for other profits in other divisions, then leads have the responsiblity of voting to remove it or restructuring it to cater to market demand. 
    - An exeception to this might be some sort of R&D or discovery process. This should have a fixed budget and term. 


## Proposed Structure

In my mind, here's how the structure should start.

Ops/Account Mgmt:
- Handles internal basic operations (eg. Payroll, community messaging)
- Maintains relationships with the clients and developers.
- Takes in all requests and questions from clients and passes them to the person who can best solve the customer's problem
- Collects customer satisfaction data 

Marketing/Revenue/Growth
- Studies demand for existing revenue streams
- Ideates and implements paths to new revenue streams
- Searches for new clients
- Promotes services to clients
- Provides the DAO with data about the efficacy of each revenue stream and division and recommneds changes based on market demand
- Packages service offerings from engineering and makes it easy to sell and market to clients/customers/devs


Engineering/Education/Evangelism
- Responsible for the completion of engineering related services 
- Resposiblle for technical consultation 
- Resonsible for providing technical support to clients where needed
- Creates content that helps other developers build with our tools. 
- Passes product feedback from clients back to the current owner of the product. Example, client has a feature request for a certain JS library, they send that to Magesmiths or Roundhaus Labs
- Comes to pitch meetings and shares the vision on how products can be built and what sort of services we can offer. 
 
 
## Potential Revenue Streams

Services: 
- Building a custom DAO app for a single DAO
- Building a custom DAO app for many DAOs (eg. Yeeter)
- Offering tech support, consultations, developer relations to people who are building DAOs.
- Taking on ecosystem grants to create DAO builder communities 
- Taking on ecosystem grants to create DAO specific products

Product (Later stage):
- As we build more products, its very likely that the tools that we use can be offered as products
- Not all of our packages need to be open source, and there's its likely we could offer to some premium tools to builders looking accelerate their productivity 