SAEP-13: Risk Curation Framework - March 23, 2026

Spark's Operational Facilitator has placed a proposal into the voting system on behalf of nested contributor Phoenix Labs.

Review

The Spark community can hereby express support or opposition to the following changes, as described by the author of the proposal:

Summary

This proposal is submitted by Phoenix Labs in its role as a nested contributor, as defined in section A.6.1.1.1.2.2.2.2.1.2.1.1.1 of the Spark Artifact. The proposal recommends that Spark governance adopt a Risk Curation Framework, under which certain on-chain activities may be executed by approved external contributors (“Curators”) subject to explicit governance approval, timelock protections, and defined cancellation authorities.

The proposed framework is intended to improve operational efficiency and responsiveness in Spark’s risk management processes, while maintaining Spark governance’s ultimate authority over all risk-relevant decisions.

Background

Spark governance oversees a growing set of risk parameters across Spark-managed protocols, vaults, and integrations. As the protocol expands across assets, chains, and execution venues, certain categories of on-chain actions benefit from execution by specialized contributors with deep domain expertise.

At present, Spark governance directly authorizes and executes most risk-related changes, which can introduce operational friction and latency even in cases where governance consensus is clear. At the same time, maintaining strong safeguards around risk authority, change transparency, and alignment with the Sky Atlas and Spark Artifact remains critical.

This proposal introduces a Risk Curation Framework that allows Spark governance to delegate limited execution authority to approved Curators, while retaining governance approval requirements, mandatory timelock delays, and broad cancellation powers to ensure safety, alignment, and accountability.

Proposal Details

We propose that Spark governance adopt a Risk Curation Framework with the following principles:

• Spark governance may delegate certain on-chain activities to be executed by external contributors via curator roles.

• Any change executed by a Curator must first be approved by Spark governance through a polling process.

• Following governance approval, the Curator may directly execute the approved change by submitting the corresponding onchain transaction.

• All admin or privileged controls exercised by curator roles must be subject to a minimum timelock delay of three (3) days between scheduling and execution.

• During the timelock delay, pending changes may be cancelled by Spark governance, Sky governance, or a designated guardian role.

• Pending changes may be cancelled for reasons including:

  • Misalignment or conflict with the Sky Atlas or Spark Artifact

  • Excessive or unacceptable risk

  • Emergency situations

  • Cancellation requested by the Curator

Justification

The Risk Curation Framework enables Spark governance to delegate execution responsibilities. Requiring explicit governance approval prior to execution ensures that all risk decisions remain governed by Spark governance, while curator execution improves responsiveness and operational efficiency.

Mandatory timelock delays and broad cancellation authority provide strong safety guarantees, allowing governance or guardians to intervene if circumstances change, new information emerges, or risks escalate. Explicitly enumerating each instance of delegated authority ensures transparency, auditability, and granular control.

This framework is extensible by design, allowing Spark governance to approve additional instances or modify existing ones over time without weakening core risk protections.

The proposed Spark Artifact changes can be found in the following pull request: https://github.com/sky-ecosystem/next-gen-atlas/pull/209

Outcomes

• If "For" receives the most votes, the proposal will be approved. The associated pull request will be merged into Spark's artifact. When required, the listed changes will proceed to implementation by the relevant actors.

• If "Against" receives the most votes, the proposal will be rejected. No changes will be implemented.