202602251621-sky-subdaos-roster

🎯 Core Idea

This card is a living roster for Sky organizational units. Sky previously used subDAO language, and the current branding often refers to Stars. The goal is the same: a domain cell with a mandate, an accountability interface back to core governance, and measurable outputs.

The practical problem is that Sky governance information is split across multiple surfaces:

Sky Atlas for the specification-like governance model
the Sky forum for discussion and proposal artifacts
voting portals for ratification artifacts
Sky Fusion ecosystem actor pages for who is doing work and how incentives or agreements are framed

Because subDAO terminology and implementation can evolve, this roster is designed to be evidence-driven. Every entry should point to a canonical artifact (forum post, vote, or official page) that proves the subDAO exists and defines its mandate.

Current state of public artifacts

From the sources I can access, the Creator subDAO model is referenced as a target structure, and Spark is explicitly mentioned as a product that can transition into a Creator subDAO once the model is established. However, I do not currently have a single official page that lists a complete, authoritative roster of active subDAOs.

That means the right approach is:

treat subDAOs as a governance concept that is in progress
build the roster bottom-up from explicit ratified artifacts

Roster table format

Use this table shape for each subDAO entry:

Name
Domain or scope
Owned products or business lines
Status
- planned
- forming
- active
- transitioned
Evidence links
- forum thread
- vote
- official page

Initial confirmed entries

Creator subDAO model

Status: planned
Evidence: Sky Fusion pages reference the model as the intended structure for products.

Spark transition candidate

Status: planned
Evidence: Sky Fusion notes Spark can transition to a Creator subDAO once the model exists.

🌲 Branching Questions

➡ What is the purpose of this roster card, and what counts as a subDAO entry?

This roster is meant to be an index you can trust. The point is to avoid spreading vague subDAO talk across many notes.

A subDAO entry should only be added when there is evidence that it exists as an organizational unit, not just as an idea. Evidence can be:

an official forum post defining the subDAO
a vote artifact establishing a budget, mandate, or permissions
an official Sky page that lists it

If something is only mentioned as a future plan, list it as a candidate, not an active subDAO.

➡ What minimum evidence should be required before we call a subDAO active?

A practical threshold:

Active requires at least one ratified artifact that creates obligations, not just intentions. Examples:
- a vote establishing a budget
- a vote establishing a mandate
- a vote establishing a permission set

If there is no ratified artifact, the correct status is planned or forming.

➡ How should we classify subDAOs: by Atlas scope, by product line, or by contributor structure?

Use a two-label scheme:

Primary label: Atlas scope
- Governance, Support, Stability, Protocol, Accessibility, Agent
Secondary label: owned product or domain
- example: Spark, Savings, Liquidity Layer, governance tooling

This keeps the roster readable and makes it easy to route proposals: scope tells you which rulebook is relevant, while product tells you what to measure.

➡ What does progress mean for a subDAO, and what milestones should we track?

Progress should be defined as observable outputs.

Suggested milestones:

mandate defined and published
budget ratified
contributor set named or measurable
first deliverable shipped
recurring reporting established
key KPIs stable and improving

If a subDAO exists but cannot point to deliverables or reports, it is not yet operational.

➡ What KPIs are useful across different subDAOs without becoming vanity metrics?

Cross-domain KPIs:

time from decision to execution
number of shipped milestones per quarter
incident count and incident severity
concentration and risk health where applicable
whether growth depends on subsidies

The goal is not to standardize everything. The goal is to keep a small set of comparable signals.

➡ How should we connect ecosystem actors to subDAOs without conflating the two?

Ecosystem actors are who does work. SubDAOs are governance and accountability units.

A clean mapping:

SubDAO entry includes a section called Contributors
list ecosystem actors as contributors only if there is an explicit mandate link

Example:

Phoenix Labs can be listed as a contributor for Spark-related work because its ecosystem actor page frames it as a builder for Spark and mentions the subDAO transition model.

Avoid treating every partner or counterparty as a subDAO builder.

➡ What is the most reliable process to build a full roster from public artifacts?

A practical process:

Start from first-party indices

Sky Atlas
Sky forum tags and categories
governance portals

Search for explicit naming

forum search for subDAO and creator subDAO
collect threads that claim to establish a unit

Confirm with ratification artifacts

find the vote or budget approval that matches the thread

Add one roster row per confirmed subDAO

include evidence links
assign status planned, forming, active, transitioned

Periodically review and prune

if a candidate has no evidence after a period, keep it as a candidate but do not promote it to active

This reduces the chance of building a roster from rumors.