Comment on page
Overview

Organizations protocol is a general-purpose permission system based on the idea of human coordination by granular rules.
This setup helps any kind of Organizations structure to be easily set up and run in a few lines of code or less. With Organizations, you can compose your governance based on different needs and different governance rules for each part of the protocol.

You can compose an Organization via two different layers: 
The Root layer is where the technological development of the project is carried out, updates and bug fixing to the architecture of the Organization are performed. In the Root Layer you can run new code, add/remove/update the architecture and components of the Organization. A core team including Solidity technicians with coding skills is the ideal Root Layer host; i.e, people who are capable of carrying out the technological development of the project. 
The Governance Layer, consisting of one or more sub-DAOs, is where economic/financial decisions are made. It is of more interest to governance token holders and others interested in helping manage the project but who don't have coding skills.
The Root Layer and the Governance Layer are 'independent' from each other; votes on the Root Layer do not affect the Governance Layer. This design makes it possible to create granular, multi-layered governance systems dedicated to users with different needs.
The two layers define the horizontal permission system. The Root and the Governance Layer, having different purposes of use, have also a different operation. However, the two layers share the Proposals concept. 
Proposals are code execution requests that once voted and passed, directly execute the code without the intervention of the core team or any other person. Proposals are not simple Polls but the tool to make decisions in an on-chain Organization. The Root layer allows, through Proposals, to execute any kind of code, even malicious code, that can lead to more or less important changes in the architecture and in the Organization operation; the code of a Root Proposal can be freely written. The Governance layer allows, through Proposal, to execute code from existing models, called Proposal models. In particular, at the Governance layer it is possible to have two types of Proposals:
1.Surveyless Proposals -> users vote for one of the options provided for that specific Proposal provided by a Proposal Model.
2.Survey Proposal -> users can propose their option for that specific Proposal provided by a Proposal Model.
In order to manage these two different horizontal layers in a rational way, it is possible to define a granular and customizable system of permissions represented by the type of governance desired. In fact, it is possible to define for the Root Layer and for each Proposal Model of each subDAO that make up the Governance Layer who can do what. In particular, our guidelines provide 3 different options:
Host Management 
Only the host can make changes. This should only be used for the Root Layer.
Host and Holder Management
Both the host and governance token holders must approve changes.
Holder Management
Only governance token holders can make changes.
For example, an Organization could have a host+holders governance at the Root Layer and holders only at the Governance one where only the host, or the core team, can propose changes at the Root level that need the votes of the holders to pass while at the Governance level the holders have exclusive control and decision-making power.
Organization architecture, or the horizontal permissions system, represents the structure while granular governance, or the vertical permissions system, represents the permissions you build on top of it. In this way, it is possible with the v0.5 protocol to define completely different Organizations both in terms of architecture, i.e. the components of the two horizontal layers, and in terms of governance, i.e. the permissions of the vertical layers, being able to create Organizations ranging from completely decentralized to completely centralized.
Both the Root Layer and the subDAOs that make up the Governance Layer are flexible and customizable structures composed of Components. The only mandatory Component, both for a Root and a sub-DAO, is the Proposal Manager, that is the Component that allows creating, voting and executing Proposals. All other Components are optional and depend on the desired operation of the Organization you are building. 
EthereansOS, through Factories, provides a series of Components already developed that can be used at Root or Governance Layer such as:
Treasury Manager
This is the treasury. It can be used to receive, store and send ETH and other tokens. Its functions can easily be replaced by and extended with others; a Treasury Manager can simply be modified, rather than replaced with a new one.
State Manager
This is the Organization main information storage. It allows any linked Component to read and write pieces of information in a memory area common to all Components.
Delegations Manager 
This is the Component that allows an Organization to have Delegations. 
Investments Manager
This allows the Organization to invest in the crypto market by buying tokens from ETH, storing and selling them at fixed and preset intervals.
Treasury Splitter Manager
This Component allows the Organization to automate the splitting of its funds on a routine basis to different Components of the Organization.
You can find the complete list of Components already developed in the documentation.
However, each developer can create his own Component at will and attach it to his Organization, at Root or Governance level.
An Organization, as described so far, represents the ideal base layer to build any kind of application on Ethereum as an AMM where token holders can vote for example to change the fees for LP providers or a NFT marketplace where token holders can vote for example to change the fees of the protocol or the standards of tokens supported. Or an Organization that creates NFTs, such as games or crypto-art, to sell in a marketplace where the Items Collection is managed by the Organization that has the power to mint and change the Metadata.
Last modified 1yr ago