# Structure 1
A basic, hypothetical DAO structure built on token-based governance, with a treasury, token-holders and a Core team.

The structure is configured such that token-holders retain ultimate governance power, and delegate various powers to the core team.

This is similar to some DAO structures today, and closely models the shareholder <-> board of directors model that many corporations use, where token-holders: (1) elect "executives" to run the organisation and (2) act as the check/balance on the actions of the elected executives.


### Scenario 1.1 – Core team wants to increase their treasury spending limit
The org is configured such that the core team can create a proposal to increase their treasury spending limit, but the token holders have to pass it.

The governance chain for a successful vote is as follows:
1. Core team member creates the proposal
2. Core team votes and agrees to put it to token holders
3. Token holders pass the vote and the core team spending limit is updated


#### 1.1.1 Spending limit is increased in the org specification
The core-team spending limit is a parameter in the org spec. A core-team member changes the spending limit to the new desired value in the spec and generates the transaction necessary to make the change on-chain
#### 1.1.2 Transaction submitted
A core-team member submits the generated transaction. This creates a proposal for core-team members to vote on, that if successful, would put the spending-limit increase vote to token holders.
#### 1.1.2 Token-holder vote
Once the core-team pass the initial vote, this creates a proposal for token-holders to vote on. If successful, this would implement the proposed change by upping the core team’s spending limit

### Scenario 1.2 – Token holders want to change the approach to spending limit governance
Token holders decide they don’t want to have to vote every time the core-team wants to increase their treasury spending limit, and instead want to take a more optimistic approach.

In this new approach they allow the core-team to increase their own spending limit through a timelock on which the tokenholders retain veto power. This gives the core-team the autonomy to update their own spending limits, but still gives the token-holders the ability to block the request if they disagree.

#### 1.2.1 – The proposed governance process for spending limit increases
1. Core team member updates the spending limit in the org spec and executes the generated transaction on chain
2. Core team votes to pass the spending limit increase
3. The proposal passes and enters the timelock for 7 days, during which the token holders can veto the proposal
4. If not vetoed, the transaction can be executed and the proposed spending limit increased.


#### 1.2.2 – The path to implementing this new governance process
The proposed new governance process is itself proposed and passed through governance:

1. The token-holders create an updated org spec that has the new timelock governance system – with core team members as the proposers and voters – and delegates the spending limit administration to this new governance system
2. A transaction is created for this proposal that token-holders execute on-chain. This creates a proposal to implement the governance changes that token-holders vote on.
3. If the vote passes, the org structure is updated to implement the new governance system.