# FAQ Post for the CU List

### [Update] Questions and Answers
#### Q1. Are you going to set up all 24 New Core Units as part of the new Incubation Program?

No! We're aiming to have ~5 facilitator candidate graduates per track which would make it 15 CUs **at most**. Realistically, we would have between 8 and 12 Core Units formed as part of the program.
This will depend on the quality of the facilitator candidates and the prioirities set by the Community.

#### Q2. Are the Core Unit ideas random or do they follow a broader roadmap?

The tracks presented follow the roadmap already highlighted in [SES recent status update](link_here):

1. **Grow Revenue** - MakerDAO should aim for securing revenue through incubating and launching multiple Real-World Finance Core Units (already in progress by SES) while expanding brand strength through the new Outreach CUs.
2. **Scale the Protocol** - enable ecosystem scalability addressing critical bottlenecks, such as delegate overload, through the work of transparency & quality control CUs hand in hand with various cross-CU initiative (including the SES Ecosystem Dashboard and API).
3. **Protect the Protocol** - The legal track aims to map and mitigate critical legal risks of failure of the Protocol through decentralization.

#### Q3. Instead of producing specialised Core Units shouldn't we focus on creating cross-core-unit ones?

The limited cross-interaction bottleneck is already being addressed by the [Cross Core Unit & Stakeholder Alignment Initiative](https://forum.makerdao.com/t/governance-and-risk-176-thursday-january-27-17-00-utc/12853/2#initiative-tracking-reporting-cross-core-unit-collaboration-5).

#### Q4. How do we make sure that the Protocol expenses don't outgrow the revenue?

The first step is to ensure that revenues grow in advance to expenses. The Real-World Finance initiative and the Outreach track are focused especifically on that.
We should think of different mechanisms to make sure that the expenses are under control. For example, the DAO could ensure that the provided funds are being used efficiently. The Transparency and Quality Control Core Unit aim to help delegates and MKR holders to allocate funds efficiently.

Additionally, SES has argued in the past for a consensus mechanism to determine a DAO-wide budget cap.
This would help us to align expectations accross the DAO and with the Incubation Program.

#### Q5. Is there a way to make offboarding Core Units less traumatic than observed in the past?

This topic has been covered in several threads before. [Here is one of them](https://forum.makerdao.com/t/mip4c2-sp15-core-unit-offboarding-process-amendments/12920/7).

The Ecosystem Performance Dashboard is aimed towards not only reducing the information overload for delegates and other stakeholders, facilitating scaling up the DAO, but also to provide better feedback mechanisms to avoid offboardings in favor of early corrections and potential restructurings.

#### Q6. Is there a possibility to combine several CU ideas into one, or split up ideas into multiple CUs?

Yes, this is not only possible but an expected outcome of the incubation program which is meant to identify the right match between the skill set of the facilitator candidates, the core unit scope, and the most urgent MakerDAO needs.

#### Q7. Will the community be able to provide intermediate feedback before the core units go live?

Yes, this is one of the most important changes to the program: adding more formal feedback moments to the process.

We’re still figuring out the details, but we’re currently considering 3 separate checkpoints with a sentiment poll gauging the excitement of the community about the developing core unit concepts:

- **Checkpoint 1**: when the facilitator candidates have worked out their Mission, Vision, and Strategy.
- **Checkpoint 2**: a Core Unit Launch Pod Session when more details are available about the budget, the team, and the roadmap. This would be earlier in the process than the CULPSs that we’re used to.
- **Checkpoint 3**: a more explicit sentiment poll posted together with the initial RFC for MIP39, MIP40 and MIP41.

We hope this will encourage delegates and other stakeholders to think more thoroughly about their position on the core units in the pipeline, allowing facilitator candidates to correct course earlier in the process.

#### Q8. When will these core units become active?

While we encourage the facilitator candidates to already start operating as if they already running an official core unit as early as possible so that they can hit the ground running, we’re targeting the November cycle to make the formal proposals. This is based on our experience with prior core units and the time that was required to finish the incubation program.

---

--- ORIGINAL NOTES below ---

- We will not create 24 CUs. Max CU Capacity, expected
- Roadmap . Delegate issues . Again point to Presentation
- Reiterate X Core Unit Initiative
- Legal CU rationale about avoiding critical failure
- We argued for a DAO-wide budget cap in the past. This was rejected (should add a link to a relevant post)
- Offboarding BUs is inherent to the DAO. If you onboard you need to off board.
- Whether it's a pleasant or not, the DAO needs the ability to provide intermediate feedback, restructurings and potential off-boardings of existing core units.
> once again, refer to the transparency and quality control track (with the dashboard). That's exactly why it's needed.

Is there a process for shutting down Core Units in a non-traumatic way? I would like to understand better the process of a lifecycle of a Core Unit, so that they do not exist forever once we agree that they have served their purpose.
> link to offboarding thread

Goals
1. Revenue Growth > RWF + Outreach
2. Make the DAO scalable > T/QC + CCU initiatives
3. Avoid critical failure > Legal (they are not random)

Maker Talent
- Intermediate feedback when we introduce the Core Unit .
- only at very end delegates started to worry about viability of a Core Unit
- add forum poll following introduction : how excited are you about this Core Unit?
- Launchpad session should be done early before RFC is published + poll about concept and team
- 3rd check - posting RFC itself