Governance facilitator multisigs are multisignature wallets that enable designated governance participants within Sky Protocol to execute operational functions—such as distributing compensation, adjusting bounded protocol parameters, and triggering emergency security actions—without requiring a full executive vote for each individual action. These wallets implement threshold signing schemes (for example, requiring 2-of-3 or 3-of-5 signers to approve a transaction) to prevent any single individual from unilaterally controlling protocol funds or parameters.
As of February 2026, the Sky ecosystem maintains over two dozen distinct multisig wallets spanning core governance operations, BEAM parameter adjustments, emergency security freezes, and Star Agent liquidity layer management. Each multisig is documented in the Sky Atlas with its on-chain address, signing threshold, and signer composition, creating a verifiable chain of accountability that community members can audit directly on-chain [1] [2].
The multisig framework evolved from MakerDAO's earlier core unit wallet system, which was formalized under MIP47 (MakerDAO Multisignature Wallet Management) [9]. That governance proposal established the principle that all multisig wallets holding protocol funds must be disclosed to governance, considered owned by Maker Governance, and subject to community oversight. The current Sky Protocol multisig architecture builds on this foundation while introducing more granular role separation between Core Facilitators, Core GovOps, Ecosystem Actors, and specialized operational agents.
Multisig Framework and Standards
Sky Protocol uses Gnosis Safe (now rebranded as Safe) as the standard multisig implementation across the ecosystem [9]. Safe is an industry-standard smart contract wallet that supports flexible multi-signature schemes, allowing governance to configure any M-of-N threshold. This standardization provides several advantages: consistent security properties across all operational wallets, well-audited contract code, compatibility with existing blockchain tooling, and transparent on-chain verification of all transactions and signer compositions.
The governance framework distinguishes between several categories of multisig wallets based on their operational scope and the authority they exercise. Each category serves a distinct function within the protocol's operational hierarchy, and the signing threshold and signer composition are calibrated to balance operational efficiency with security requirements. The Sky Atlas codifies the exact parameters for each multisig, meaning any changes to addresses, thresholds, or signers must pass through the formal governance process [1].
Multisig Categories
The Sky ecosystem organizes its multisig wallets into four primary categories based on function:
- Treasury Multisigs — Manage protocol fund disbursements for compensation, budgets, and operational expenses. These include the Core Council Buffer and Aligned Delegates Buffer multisigs, which hold funds allocated by executive votes and distribute them according to Atlas-defined rules [1] [2].
- BEAM Operator Multisigs — Control bounded parameter adjustments for protocol stability mechanisms. Operators can only modify parameters within governance-set bounds (minimum, maximum, step size, and cooldown periods), preventing unauthorized changes to core protocol economics [6] [7].
- Emergency and Security Multisigs — Enable rapid response to security threats by pausing or freezing affected protocol components without waiting for the standard Governance Security Module delay. These multisigs trade decentralization for speed in crisis scenarios [3] [5].
- Star Agent Liquidity Layer Multisigs — Manage cross-chain capital allocation operations for each Star Agent (Spark, Grove, Keel, OBEX). Each Star has a standardized three-multisig structure: Prime Relayer, Core Operator Relayer, and Freezer [11] [14] [17] [22].
Signer Roles
The primary signer roles across Sky Protocol multisigs are:
- Core Facilitator — The primary governance enforcer responsible for Aligned Delegate management, compensation calculations, and operational compliance. Controls signer slots on treasury and bridge security multisigs [1] [2].
- Core GovOps — The operational governance team that shares signing authority with the Core Facilitator on treasury multisigs and manages Core Operator Relayer functions across multiple Star Agents [1] [15].
- Operational GovOps Amatsu — A specialized operational entity that serves as Core Operator Relayer signer for Grove and Keel liquidity layer multisigs [15] [18].
- Core Executor Agent Atlas Axis — Controls the BEAM operator multisigs that adjust protocol stability parameters within bounded ranges [6] [7].
- Ecosystem Actors — External entities such as Phoenix Labs (Spark) and Star-specific teams that hold signer slots on their respective liquidity layer multisigs [11] [12].
Core Governance Multisigs
The core governance multisigs manage the most sensitive operational funds within Sky Protocol—the budgets that fund Aligned Delegates, governance facilitators, and core operations. Both treasury multisigs share an identical signer structure that distributes control between the Core Facilitator and Core GovOps, ensuring no single governance role can unilaterally access protocol funds.
Core Council Buffer Multisig
The Core Council Buffer serves as the primary operational treasury for Sky's core governance infrastructure. Executive votes allocate funds from the protocol surplus to this multisig, which then disburses them according to Atlas-defined budgets and schedules.
| Property | Value |
|---|---|
| Address | 0x210CFcF53d1f9648C1c4dcaEE677f0Cb06914364 |
| Threshold | 3-of-4 |
| Signers | 2 addresses controlled by Core Facilitator + 2 addresses controlled by Core GovOps |
| Atlas Reference | A.2.3.1.4.1.1.1.1 |
The 3-of-4 threshold means that at minimum one signer from each role (Core Facilitator and Core GovOps) must approve any transaction, plus one additional signer from either role [1]. This design prevents either the Core Facilitator or Core GovOps from acting alone while still allowing transactions to proceed if one signer from either side is unavailable.
Aligned Delegates Buffer Multisig
The Aligned Delegates Buffer holds funds earmarked for monthly compensation payments to recognized Aligned Delegates. The Core Facilitator calculates compensation amounts based on delegate participation rates and rankings, then initiates payouts through this multisig.
| Property | Value |
|---|---|
| Address | 0x37FC5d447c8c54326C62b697f674c93eaD2A93A3 |
| Threshold | 3-of-4 |
| Signers | 2 addresses controlled by Core Facilitator + 2 addresses controlled by Core GovOps |
| Atlas Reference | A.2.3.1.4.1.2.1.1 |
The signer structure mirrors the Core Council Buffer, maintaining the same cross-role approval requirement [2]. Monthly compensation distributions follow the Atlas-defined schedule, with Ranked Delegates receiving annual allocations of 400,000 USDS (Level 1), 175,000 USDS (Level 2), or 48,000 USDS (Level 3), paid in monthly installments contingent on meeting the 95% governance voting participation threshold.
BEAM Operator Multisigs
BEAM (Bounded External Access Module) operator multisigs enable designated agents to adjust specific protocol parameters within governance-defined bounds without requiring an executive vote for each change. This mechanism provides operational agility for time-sensitive stability adjustments while constraining the maximum possible impact of any single parameter change. The BEAM Payload Safety framework establishes strict bounded ranges—including minimum values, maximum values, step sizes, and cooldown periods—that operators cannot exceed.
Both BEAM operator multisigs are controlled by the Core Executor Agent Atlas Axis, the entity responsible for executing operational protocol changes in accordance with Atlas mandates.
Stability Parameter BEAM Operator Multisig
The SP-BEAM (Stability Parameter BEAM) operator multisig controls adjustments to stability fees, the DAI Savings Rate, and the Sky Savings Rate. These parameters directly affect protocol revenue and user yields, making their management one of the most operationally significant multisig functions in the ecosystem.
| Property | Value |
|---|---|
| Address | 0xe1c6f81D0c3CD570A77813b81AA064c5fff80309 |
| Threshold | 2-of-3 |
| Signers | 3 addresses controlled by Core Executor Agent Atlas Axis |
| Atlas Reference | A.3.7.1.3.5.1.1 |
The 2-of-3 threshold allows operational continuity even if one signer key is unavailable, while still requiring multi-party approval [7]. All parameter changes must fall within governance-set bounds, and an on-chain cooldown period (tau) prevents rapid successive adjustments.
stUSDS BEAM Operator Multisig
The stUSDS BEAM operator multisig manages parameters specific to the stUSDS mechanism, including the stUSDS rate, SKY borrow rate, deposit caps, and debt ceilings.
| Property | Value |
|---|---|
| Address | 0xBB865F94B8A92E57f79fCc89Dfd4dcf0D3fDEA16 |
| Threshold | 2-of-3 |
| Signers | 3 addresses controlled by Core Executor Agent Atlas Axis |
| Atlas Reference | A.4.4.1.3.8.4.1.1 |
The same 2-of-3 threshold and bounded parameter constraints apply as with the SP-BEAM multisig [6]. If either BEAM multisig is compromised, governance can execute a Halt Spell to immediately disable the affected BEAM without waiting for the Governance Security Module delay.
Emergency and Security Multisigs
Emergency multisigs provide rapid-response security capabilities for scenarios where the standard governance process (propose, vote, wait for GSM delay, execute) would be too slow to prevent damage. These multisigs typically have lower signing thresholds to enable faster action, balanced by strict scope limitations—they can only pause or freeze affected components, not modify protocol parameters or move funds.
SparkLend Security Access Multisig
The SparkLend Security Access Multisig is authorized to pause or freeze markets within SparkLend in response to code exploits, oracle failures, or other technical vulnerabilities. It is added as a ward in the FreezerMom contract, granting it the specific authority to trigger SparkLend's emergency freeze mechanism.
| Property | Value |
|---|---|
| Address | 0x44efFc473e81632B12486866AA1678edbb7BEeC3 |
| Threshold | 3-of-5 |
| Signers | VoteWizard, LDR, Hexonaut, MonetSupply, LucasManuel |
| Atlas Reference | A.1.9.4.2.1.5 |
This multisig is notable for having individually named signers rather than role-based signer slots [5]. The 3-of-5 threshold provides resilience against key compromise while requiring majority agreement among security-focused community members. All emergency actions taken by this multisig must be reported to the Sky community within a reasonable timeframe on the Sky Forum, maintaining accountability for crisis interventions.
LayerZero Bridge Freezer Multisigs
The LayerZero bridge freezer multisigs provide emergency pause capabilities for the cross-chain bridge infrastructure connecting Ethereum and Solana. These multisigs are restricted to emergency use only—specifically in response to code exploits or technical vulnerabilities that threaten bridged assets.
Ethereum LayerZero Freezer Multisig
| Property | Value |
|---|---|
| Address | 0x38d1114b4cE3e079CC0f627df6aC2776B5887776 |
| Threshold | 2-of-4 |
| Signers | 2 addresses controlled by Core Facilitator + 2 addresses controlled by Core GovOps |
| Atlas Reference | A.1.9.4.1.3.1.1.1 |
The Ethereum-side freezer multisig uses the same Core Facilitator / Core GovOps signer structure as the treasury multisigs, but with a lower 2-of-4 threshold to enable faster emergency response [3]. This means a single signer from each role can freeze the bridge without waiting for additional approvals.
Solana LayerZero Freezer Multisig
| Property | Value |
|---|---|
| Address | 5hARLsT1VA2AmuGL2AXUeSyyFG6o2Fcpb9S6aKXNsbeK |
| Threshold | 2-of-4 |
| Signers | 2 addresses controlled by Amatsu + 2 addresses controlled by Keel |
| Atlas Reference | A.1.9.4.1.3.1.2.1 |
The Solana-side freezer multisig uses a different signer composition—Amatsu and Keel rather than Core Facilitator and Core GovOps—reflecting the operational entities with direct presence on Solana infrastructure [4].
Star Agent Liquidity Layer Multisigs
Each Sky Star that operates a liquidity layer maintains a standardized three-multisig structure for managing cross-chain capital allocation. This architecture separates concerns into three distinct operational functions, each with its own address, threshold, and signer composition tailored to the specific Star's operational model. The three multisig types serve complementary roles: Prime Relayers handle routine capital movements, Core Operator Relayers manage operational governance functions, and Freezer multisigs enable emergency intervention.
Spark Liquidity Layer
Spark is the largest Star Agent by total value locked and operates across Ethereum, Base, and Arbitrum. Its multisig structure reflects its scale, with Ecosystem Actor Phoenix Labs playing a central operational role alongside governance signers.
Spark Prime Relayer Multisig
| Property | Value |
|---|---|
| Address | 0x8a25A24EDE9482C4Fc0738F99611BE58F1c839AB |
| Chains | Ethereum, Base, Arbitrum |
| Threshold | 1-of-2 |
| Signers | 2 addresses controlled by Ecosystem Actor Phoenix Labs |
| Atlas Reference | A.6.1.1.1.2.6.1.2.1.2.2.1.1 |
The 1-of-2 threshold on the Prime Relayer enables rapid capital movements, as routine allocation operations require minimal delay [11]. This lower threshold is acceptable because Prime Relayer actions are bounded by the governance-approved allocation parameters.
Spark Core Operator Relayer Multisig
| Property | Value |
|---|---|
| Address | 0x8Cc0Cb0cfB6B7e548cfd395B833c05C346534795 |
| Chains | Ethereum, Base, Arbitrum |
| Threshold | 2-of-5 |
| Signers | Amatsu (2) + Spark Assets Foundation/SAF (2) + Phoenix Labs (1) |
| Atlas Reference | A.6.1.1.1.2.6.1.2.1.2.2.2.1 |
The Core Operator Relayer has the most diverse signer composition of any Spark multisig, distributing control across three entities [12]. Phoenix Labs may create and propose transactions, but execution requires the 2-of-5 threshold, ensuring cross-entity approval.
Spark Freezer Multisig
| Property | Value |
|---|---|
| Address | 0x90D8c80C028B4C09C0d8dcAab9bbB057F0513431 |
| Chains | Ethereum, Base, Arbitrum |
| Threshold | 1-of-4 |
| Signers | Spark Assets Foundation/SAF (1) + Phoenix Labs (2) + VoteWizard (1) |
| Atlas Reference | A.6.1.1.1.2.6.1.2.1.2.2.3.1 |
The 1-of-4 threshold on the Freezer multisig prioritizes speed of emergency response—any single signer can trigger a freeze [13]. This design accepts higher trust assumptions in exchange for the ability to halt operations within a single block when a vulnerability is detected.
Grove Liquidity Layer
Grove operates on Ethereum mainnet with a governance structure that emphasizes internal control through its own team while using Operational GovOps Amatsu for Core Operator functions.
| Multisig | Address | Threshold | Signers |
|---|---|---|---|
| Prime Relayer | 0x0eEC86649E756a23CBc68d9EFEd756f16aD5F85f |
4-of-7 | 7 addresses controlled by Grove [14] |
| Core Operator Relayer | 0x4364D17B578b0eD1c42Be9075D774D1d6AeAFe96 |
2-of-3 | 3 addresses controlled by Operational GovOps Amatsu [15] |
| Freezer | 0xB0113804960345fd0a245788b3423319c86940e5 |
2-of-4 | VoteWizard, JanSky, LDR, CivicSage [16] |
Grove's Prime Relayer has the highest threshold ratio (4-of-7) of any Star Agent, requiring majority approval among Grove's own signers for routine capital movements [14]. The Freezer multisig uses individually named community signers rather than role-based slots, similar to the SparkLend Security Access Multisig approach.
Keel Liquidity Layer
Keel is the only Star Agent currently operating across both Ethereum and Solana, requiring separate multisig deployments on each chain. The Ethereum multisigs use Gnosis Safe while the Solana multisigs use Squads (the Solana-native multisig standard).
Keel Ethereum Multisigs
| Multisig | Address | Threshold | Signers |
|---|---|---|---|
| Prime Relayer | 0xA4F39dAae4Dc86c27c46b9a0605AE2c911451F95 |
1-of-2 | 2 addresses controlled by Keel [17] |
| Core Operator Relayer | 0x0f72935f6de6C54Ce8056FD040d4Ddb012B7cd54 |
2-of-3 | 3 addresses controlled by Operational GovOps Amatsu [18] |
| Freezer | 0xBCCB60cf518391d3315D63313F7bb764d02541fE |
2-of-5 | Operational GovOps Amatsu (2) + Operational Facilitator Endgame Edge (2) + Keel (1) [19] |
Keel's Ethereum Freezer multisig has the most diverse signer composition of any Star Freezer, spanning three distinct entities [19]. This distribution reflects governance's emphasis on cross-entity oversight for emergency actions affecting a multi-chain Star.
Keel Solana Multisigs
| Multisig | Address | Threshold | Signers |
|---|---|---|---|
| Core Operator Relayer | 7JvfSy4mWcw1EAy7vjvsHnKeC28UZeAURhVi4nQjUM6h |
2-of-3 | 3 addresses controlled by Operational GovOps Amatsu [20] |
| Freezer | AUAJeXgLDNoDbBZ1uRguj9hWDZJSQkmoy4xk9U5zJF8h |
2-of-4 | Signers to be specified in a future Atlas iteration [21] |
The Solana Freezer multisig address is deployed, but the specific signer composition had not been finalized in the Atlas as of February 2026 [21].
OBEX Liquidity Layer
OBEX operates on Ethereum mainnet with a governance structure that uses Operational GovOps Ozone (distinct from Operational GovOps Amatsu) for Core Operator functions.
| Multisig | Address | Threshold | Signers |
|---|---|---|---|
| Prime Relayer | 0x5d36918C8F4726a62257AA79a50E53D553465663 |
4-of-7 | 7 addresses controlled by OBEX [22] |
| Core Operator Relayer | 0x2b1D60B11B7015fB83361a219BE01B7564436054 |
2-of-3 | 3 addresses controlled by Operational GovOps Ozone [23] |
| Freezer | 0x1924b6990B63c5f820b81a23CD40383808D416D8 |
2-of-4 | 4 addresses controlled by OBEX [24] |
OBEX mirrors Grove's high-threshold Prime Relayer design (4-of-7), while its Freezer is controlled entirely by OBEX's own signers rather than cross-entity community members [22] [24].
Security Model and Considerations
The multisig architecture across Sky Protocol reflects a deliberate set of security tradeoffs that balance operational speed against the risk of compromise. Understanding these design choices is essential for evaluating the protocol's governance security posture.
Threshold Design Principles
Signing thresholds follow a consistent pattern across the ecosystem: higher thresholds for fund-holding treasury multisigs, moderate thresholds for operational and Core Operator functions, and lower thresholds for emergency freeze capabilities. The Core Council Buffer and Aligned Delegates Buffer both use 3-of-4, requiring cross-role approval for any fund movement [1] [2]. BEAM operator and Core Operator Relayer multisigs generally use 2-of-3, enabling operations when one signer is unavailable while still requiring multi-party approval [6] [7]. Emergency Freezer multisigs use the lowest thresholds—as low as 1-of-4 for Spark—prioritizing speed of response over consensus [13].
Signer Diversity and Role Separation
The protocol implements role separation by requiring signers from distinct organizational entities. Treasury multisigs split control between Core Facilitator and Core GovOps. Star Agent Core Operator Relayers are managed by Operational GovOps entities (Amatsu or Ozone) rather than the Stars themselves, creating external oversight of operational functions [15] [23]. This separation ensures that the entity proposing a transaction is not the same entity that ultimately controls its execution.
Accountability and Transparency
All multisig addresses and configurations are published in the Sky Atlas, making them publicly auditable [1]. Any changes to multisig parameters—addresses, thresholds, or signer compositions—must pass through the formal executive vote process. Emergency actions taken by security multisigs carry a mandatory reporting requirement: all interventions must be disclosed to the Sky community on the Sky Forum within a reasonable timeframe [5].
Known Limitations
The current multisig architecture has several limitations that governance participants should be aware of:
- Key compromise risk — BEAM operator multisigs controlled by a single entity (Core Executor Agent Atlas Axis) mean that compromising that entity's keys could enable unauthorized parameter changes within bounded ranges [6] [7].
- Incomplete signer disclosure — While the Atlas publishes multisig addresses and thresholds, individual signer addresses are not always linked to public identities, limiting community ability to verify signer independence.
- Cross-chain complexity — Keel's dual-chain deployment introduces additional coordination overhead, and the Solana Freezer multisig's signer composition remained unspecified as of February 2026 [21].
- Gnosis Safe signing friction — Multisig wallets using Gnosis Safe cannot easily produce signed messages required by certain governance processes (such as Aligned Delegate recognition), creating operational friction for participants who prefer multisig security over externally owned accounts [9].
Historical Context
The current multisig framework evolved from MakerDAO's earlier core unit wallet system. MIP47, adopted during the MakerDAO era, established the foundational principle that all operational multisig wallets must be disclosed to and considered owned by the governance community [9]. The legacy GovAlpha core unit maintained a governance-administered multisig at 0x01D26f8c5cC009868A4BF66E268c17B057fF7A73, which was disclosed on the MakerDAO forum in accordance with MIP47 requirements [10].
All multisig operations ultimately exist downstream of the Pause Proxy (0xbe8e3e3618f7474f8cb1d074a26affef007e98fb), the governance-controlled execution proxy through which executive votes take effect on-chain [8].
The transition from MakerDAO's core unit structure to Sky Protocol's facilitator and agent model brought significant changes to multisig governance. The earlier system used relatively simple per-unit multisigs with ad hoc signer compositions. The current Atlas-driven model standardizes multisig parameters, codifies signer roles, and introduces the three-multisig pattern (Prime Relayer, Core Operator Relayer, Freezer) across all Star Agent liquidity layers, creating a more systematic and auditable governance structure.
Complete Multisig Reference
The following table provides a consolidated view of all governance facilitator and operational multisigs documented in the Sky Atlas as of February 2026:
| Category | Multisig | Address | Threshold | Primary Controller |
|---|---|---|---|---|
| Treasury | Core Council Buffer | 0x210C...9364 |
3/4 | Core Facilitator + Core GovOps |
| Treasury | AD Buffer | 0x37FC...93A3 |
3/4 | Core Facilitator + Core GovOps |
| BEAM | SP-BEAM Operator | 0xe1c6...c309 |
2/3 | Core Executor Agent Atlas Axis |
| BEAM | stUSDS Operator | 0xBB86...EA16 |
2/3 | Core Executor Agent Atlas Axis |
| Security | SparkLend Freezer | 0x44ef...FdD3 |
3/5 | Named community members |
| Security | ETH LayerZero Freezer | 0x38d1...7776 |
2/4 | Core Facilitator + Core GovOps |
| Security | SOL LayerZero Freezer | 5hAR...sbeK |
2/4 | Amatsu + Keel |
| Spark | Prime Relayer | 0x8a25...39AB |
1/2 | Phoenix Labs |
| Spark | Core Operator | 0x8Cc0...4795 |
2/5 | Amatsu + SAF + Phoenix Labs |
| Spark | Freezer | 0x90D8...3431 |
1/4 | SAF + Phoenix Labs + VoteWizard |
| Grove | Prime Relayer | 0x0eEC...5F85f |
4/7 | Grove |
| Grove | Core Operator | 0x4364...Fe96 |
2/3 | Operational GovOps Amatsu |
| Grove | Freezer | 0xB011...0e5 |
2/4 | Named community members |
| Keel (ETH) | Prime Relayer | 0xA4F3...F95 |
1/2 | Keel |
| Keel (ETH) | Core Operator | 0x0f72...cd54 |
2/3 | Operational GovOps Amatsu |
| Keel (ETH) | Freezer | 0xBCCB...1fE |
2/5 | GovOps Amatsu + Endgame Edge + Keel |
| Keel (SOL) | Core Operator | 7Jvf...M6h |
2/3 | Operational GovOps Amatsu |
| Keel (SOL) | Freezer | AUAJ...JF8h |
2/4 | TBD |
| OBEX | Prime Relayer | 0x5d36...5663 |
4/7 | OBEX |
| OBEX | Core Operator | 0x2b1D...6054 |
2/3 | Operational GovOps Ozone |
| OBEX | Freezer | 0x1924...16D8 |
2/4 | OBEX |
Related Articles
- Aligned Delegates — Covers the Aligned Delegate compensation framework that the AD Buffer multisig disbursed funds for
- BEAM Payload Safety — Details the bounded parameter adjustment mechanism controlled by BEAM operator multisigs
- Executive Votes — Explains the governance process through which multisig parameters are established and modified
- Governance Security Module — Describes the time-lock mechanism that emergency multisigs can bypass during crises
- Sky Governance Voting — Covers the voting infrastructure including recent multisig configuration updates
- Spells — Details the MOM (Module Oversight Manager) contracts that interact with emergency multisigs
- Sky Atlas — The constitutional document that codifies all multisig parameters and governance rules
Sources
- Core Council Buffer Multisig Address - A.2.3.1.4.1.1.1.1
- Aligned Delegates Buffer Multisig Address - A.2.3.1.4.1.2.1.1
- Ethereum LayerZero Freezer Multisig Address - A.1.9.4.1.3.1.1.1
- Solana LayerZero Freezer Multisig Address - A.1.9.4.1.3.1.2.1
- SparkLend Security Access Multisig Address - A.1.9.4.2.1.5
- stUSDS BEAM Operator Multisig Address - A.4.4.1.3.8.4.1.1
- SP-BEAM Operator Multisig Address - A.3.7.1.3.5.1.1
- Pause Proxy Address - A.4.6.1.1.2.1.1
- MIP47: MakerDAO Multisignature Wallet Management
- GovAlpha Administered Multi-sig | MakerDAO Forum
- Spark Prime Relayer Multisig Address - A.6.1.1.1.2.6.1.2.1.2.2.1.1
- Spark Core Operator Relayer Multisig Address - A.6.1.1.1.2.6.1.2.1.2.2.2.1
- Spark Freezer Multisig Address - A.6.1.1.1.2.6.1.2.1.2.2.3.1
- Grove Prime Relayer Multisig Address - A.6.1.1.2.2.6.1.2.1.2.2.1.1
- Grove Core Operator Relayer Multisig Address - A.6.1.1.2.2.6.1.2.1.2.2.2.1
- Grove Freezer Multisig Address - A.6.1.1.2.2.6.1.2.1.2.2.3.1
- Keel Prime Relayer Multisig Address (Ethereum) - A.6.1.1.3.2.6.1.2.1.2.2.1.1
- Keel Core Operator Relayer Multisig Address (Ethereum) - A.6.1.1.3.2.6.1.2.1.2.2.2.1
- Keel Freezer Multisig Address (Ethereum) - A.6.1.1.3.2.6.1.2.1.2.2.3.1
- Keel Core Operator Relayer Multisig Address (Solana) - A.6.1.1.3.2.6.1.2.1.2.3.3.1
- Keel Freezer Multisig Address (Solana) - A.6.1.1.3.2.6.1.2.1.2.3.4.1
- OBEX Prime Relayer Multisig Address - A.6.1.1.5.2.6.1.2.1.2.2.1.1
- OBEX Core Operator Relayer Multisig Address - A.6.1.1.5.2.6.1.2.1.2.2.2.1
- OBEX Freezer Multisig Address - A.6.1.1.5.2.6.1.2.1.2.2.3.1