Enter your search text in the box above

Select a result to preview

202602251429-sky-spark-governance-processes

#org #method

🎯 Core Idea

This card summarizes how governance processes work across Sky and Spark, focusing on the practical workflow of getting a change from an idea to an executed action. It also clarifies the roles that act like committees in practice, such as risk and operational review bodies.

A useful framing is that both ecosystems have two layers:

Spark governance process (high-level)

Spark governance documentation describes a structured pipeline:

In practice, the committees are the review bodies. They are not necessarily sovereign, but they shape what reaches a vote and how it is presented.

Sky and Maker-style governance cadence

Maker governance documentation explains two common vote types:

Sky has inherited much of the governance language and infrastructure that previously existed around Maker. When you are trying to understand a Sky change, it often helps to classify it into one of these categories:

Security committee versus risk council

In DeFi governance, a security committee usually refers to a small group empowered to respond quickly to incidents, coordinate upgrades, or execute emergency actions. In Spark’s public governance docs, the closest visible role is the Spark Risk Council, which is explicitly part of the review pipeline.

If you want to understand the real security posture, focus on:

How weekly governance meetings fit

Weekly governance meetings are usually part of off-chain coordination. They help with agenda setting, proposal review, and clarifying open questions. Even when decisions are formally ratified on-chain, calls often determine what is mature enough to move forward.

Because the Sky forum is sometimes hard to access from automated fetches, the best workflow is:

🌲 Branching Questions

➡ What are the concrete responsibilities and powers of the Spark Risk Council and the Operational Facilitator?

Spark’s governance docs describe both as mandatory review steps in the proposal pipeline.

What is not clearly specified in the public governance overview is whether these roles have special on-chain powers (for example, emergency execution rights). The docs are explicit about their place in the pipeline, but the extent of any emergency authority needs to be verified from protocol contracts and role/permission documentation.

A practical reading is that these bodies are committees in the governance workflow even if they are not committees in a constitutional sense. If a proposal cannot pass these reviews, it will not reach a vote through the standard process.

➡ What is the exact lifecycle of a Spark proposal from forum post to Snapshot vote to execution, and what can block it at each step?

Based on Spark governance documentation, the lifecycle is:

  1. Proposal drafting and submission

What can block it:

  1. Review phase

What can block it:

  1. Voting

What can block it:

  1. Execution
    Spark docs describe Snapshot voting as part of the governance pipeline, but the execution mechanism is not fully described in the short overview page. In Maker-style governance, execution typically happens via an on-chain executive action after off-chain coordination and signaling. For Spark and Sky, the safest way to understand execution is to identify the on-chain artifact that corresponds to the Snapshot outcome.

What can block it:

➡ Which changes should be handled as polls versus executive-style changes, and how should I tell the difference in Sky practice?

Maker governance documentation distinguishes two main vote types:

A practical way to classify changes in Sky practice:

Even if Sky uses different names, the distinction is useful because it tells you what you should look for:

➡ What are typical security-incident workflows in these ecosystems (what can be done quickly, what requires governance)?

Typical DeFi incident response has two modes:

Spark’s governance overview explicitly includes Risk Council and Operational Facilitator review before Snapshot voting, which suggests most changes are intended to flow through the normal review and vote path.

To determine what can be done quickly in Spark or Sky, look for:

If these are not documented clearly, assume the ecosystem prefers governance-based changes, and treat emergency execution as an exception that must be justified and audited.

➡ How should I read Sky Atlas scopes as a routing guide for proposals and committees?

The Atlas scope list is a useful classification system:

A good practice is to label a proposal with a primary scope and then ask whether it crosses into a secondary scope. Cross-scope proposals are where confusion and hidden coupling usually show up.

➡ What does nested contributor status practically enable, and how does it shape governance throughput?

Spark governance documentation defines eligible proposers as:

Practically, this does two things:

The tradeoff is governance centralization risk: the more proposal submission is restricted to a small set, the more agenda-setting power concentrates. The mitigation is that proposals still require review and a Snapshot vote.

➡ What is the weekly cadence for governance in practice, and how do calls and forums influence what reaches a vote?

Maker governance documentation describes a weekly cadence:

In practice, cadence is more than a schedule. Off-chain coordination determines what is ready to enter the voting queue.

How calls and forums influence outcomes:

Even when the final decision is on-chain, most proposals succeed or fail based on the quality of the off-chain coordination phase.

📚 References