SAEP-02: Modify Spark Liquidity Layer Core Relayer and Freezer Multisig Configuration - October 20, 2025

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 Spark Artifact Root Edit Proposal Submission Requirements Exception For Nested Contributors). It recommends edits to the Spark Artifact to (i) grant the Spark Assets Foundation (SAF) formal, operational access to the Spark Liquidity Layer (SLL) via the Core Operator Relayer Multisig, and (ii) improve incident response for the SLL by updating the Freezer Multisig threshold and signers.

Specifically:

• Add SAF as a co-controller of the Core Operator Relayer Multisig alongside Amatsu and set the threshold to 2/5 with signers distributed across Amatsu, SAF, and Phoenix Labs (PL).
• Reduce the Freezer Multisig threshold from 2/4 to 1/4 and update signers to enable faster freezes in emergencies.

These changes align with SAF’s mandate in Spark Assets Foundation and update the following artifact sections:

• Core Operator Relayer Multisig (CORE)
• Required Number of Signers (CORE)
• Freezer Multisig (CORE)
• Required Number of Signers (CORE)
• Signers (CORE)

Background

The SLL relies on tightly scoped relayer roles to perform operational actions and on a dedicated FREEZER_ROLE to halt activity across relayers in emergencies. Under the current artifact, the Core Operator Relayer Multisig holds RELAYER_ROLE authority (Relayer Role) and is controlled by Amatsu. As the ecosystem evolves, SAF’s legal and operational remit (Spark Assets Foundation) requires direct, controlled access to execute SLL operations consistent with asset stewardship.

Separately, security reviews have highlighted that, for high-severity incidents freeze latency is a critical risk factor. Reducing the Freezer Multisig threshold improves time-to-freeze, and decreases the risk of the system.

Proposal Details

1. Core Operator Relayer Multisig (RELAYER_ROLE)

• Add SAF as a co-controller alongside Amatsu.

• Set threshold to 2/5 with the following signer allocation:

  • 2 Amatsu signers
  • 2 SAF signers
  • 1 Phoenix Labs signer (PL)

• Rationale: Ensures SAF can fulfill its asset oversight mandate while maintaining shared control and separation of duties. PL’s single signer improves proposal flow and operational throughput without concentrating approval power.

2. Freezer Multisig (FREEZER_ROLE)

• Reduce threshold from 2/4 to 1/4.
• Update signers to:
  • 1 SAF signer
  • 2 Phoenix Labs signers
  • VoteWizard
• Rationale: In emergencies, speed > quorum size; a 1/4 threshold materially lowers response time. Risk of an erroneous freeze is considered less impactful than delayed freezing and is mitigated by clear unfreeze paths and post-incident review. clear unfreeze paths and post-incident review.

Justification

• Mandate Alignment: SAF must be able to exercise its asset oversight responsibilities (Spark Asset Foundation). Adding SAF signers and co-control to the Core Operator Relayer is the minimal viable change to reflect this mandate.
• Separation of Duties & Safety: A 2/5 threshold across three independent entities (Amatsu, SAF, PL) preserves decentralization while allowing efficient execution.
• Incident Response: For high-severity threats, freeze time is critical. Moving the Freezer Multisig to 1/4 materially reduces the time to freeze. The downside risk of a mistaken freeze is bounded and reversible; the downside risk of a delayed freeze is deemed greater.
• Operational Efficiency: Allowing PL to propose Core Operator transactions improves throughput while preserving SAF/Amatsu execution control.

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

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.