Atlas Edit Proposal — 2026-05-11

The Executive Sheet serves as a planning instrument and documentation for the agreed content of the Spell. It is therefore one of the foundational documents in the Executive Process. Each Spell has a dedicated Executive Sheet. The Governance Point creates a new Executive Sheet for each Executive Vote cycle, listing every executive item intended for inclusion in that cycle along with the provenance of each item. In this way, the Executive Sheet helps ensure transparency and verification in the Executive Process. Past Executive Sheets are preserved in order to provide a record of Executive Votes and their provenance.

The Executive Sheet (also referred to as the "exec sheet" or "sheet") is maintained on a large Google Sheets spreadsheet with several tabs. Each Executive Vote has its own tab, whose title is the designated Target Date for each spellSpell.

The Executive Sheet provides a publicly visible list of plain-English instructions outlining the executive actions performed in a given spellSpell. Each executive action is populated in the Executive Sheet under a column and broken down into input actions (high-level actions) and derived actions (resulting from input actions).

The Executive Sheet is used by several actors in the Executive Process. It is managed and populated by the Governance Point, used by stakeholders, who are required to provide confirmation for proposed executive items, and by the Spell Team. The Executive Sheet is the source of truth for the Spell Crafter who crafts the Spell based on its content. Only the Core Facilitators haveFacilitator has write access to the Executive Sheet.

The Executive Document (also referred to as the "Executive Copy," "executive," "Executive Proposal," or "exec doc") is a formal, plain-English Markdown document that serves as the primary communication tool for presenting the contents of an Executive Vote to the community. Created after the Executive Sheet is finalized, it provides a detailed breakdown of the actions proposed in the Executive Vote. Unlike the Executive Sheet, which organizes actions in a cell-based format, the Executive Document expresses these actions in sentence format for improved readability.

Each Executive Document corresponds to a specific spellSpell and describes the actions that the spellSpell will perform if executed. It is a critical tool for ensuring transparency, clarity, and alignment among stakeholders. The document serves as a proposal that can be voted on and either approved or rejected by Sky Governance. The Core Facilitators areFacilitator is responsible for producing and finalizing the Executive Document; and any changes must be made by them.

The Executive Document is designed to be accessible to both technical and non-technical members of the Sky Ecosystem. It enables Aligned Delegates and SKY holders to understand the actions that will be executed when the spellSpell is cast. Its contents are publicly visible on the Voting Portal, where Aligned Delegates review it before voting on the spellSpell. In addition to serving as a reference for voters, the Executive Document also guides the Spell Team in developing and finalizing the Spell, ensuring that the proposed actions are accurately implemented. The contents of the Executive Document are hashed and included within the Spell code to provide an additional layer of verification.

The custom spellSpell voting page is the public interface used to submit, review, and vote on Executive Votes that are not accompanied by a formal Executive Document. It also supports voting on pre-deployed standby spellsSpells by allowing stakeholders to specify target contract addresses and calldata directly. The custom spellSpell voting page can be found at https://vote.sky.money/custom-spell.

Spell is a term specific to the Sky Protocol. It refers to all technical components of an Executive Vote, encompassing the codebase, code operations, code reviews, and overall code quality. The term "spellSpell" is often used interchangeably with the Executive Vote itself, as it represents the smart contract responsible for enacting changes to the protocol. Spells are categorized as either "regular" or "out-of-schedule." Regular spellsSpells adhere to a biweekly cadence, while out-of-schedule spellsSpells are handled with service-level agreements (SLAs) determined on a case-by-case basis.

Ecosystem Spell Validation (also referred to as "spellSpell validation" or "validation") refers to the process of performing a set of checks and high-level review of a specific spell’sSpell’s code as it exists on the blockchain (referred to as a "deployed spellSpell"). This process applies only to the deployed spellSpell and is not as comprehensive as the reviews conducted during the spellSpell development process by the Spell Reviewers. The purpose of spellSpell validation is to validate the safety of the current spellSpell in respect to its security impacts in relation to Sky Protocol smart contracts.

Each Executive Vote has a dedicated Spell Team, made up of Spell Crafters and Spell Reviewers. The Spell Team must include one Crafter, who is responsible for crafting the spellsSpells. The Spell Team must also include at least two Reviewers, responsible for reviewing and confirming that the spellsSpells are ready for the Executive Vote, at least one of whom should be a member of a different Ecosystem Actor than the Spell Crafter. A Crafter cannot serve as a Reviewer for the same spellSpell. The Spell Team is a set of technical contributors working on developing all technical and smart-contract-related aspects of a particular Executive Vote, based on instructions set out by the Governance Point.

The Spell Crafter (the Crafter) is the person or entity who parses the written instruction set of a proposed Executive to Solidity code in order to develop the spellSpell in the first instance. Every addition, modification, or removal of code or content within the spellSpell must be performed by the Crafter. The designated Spell Crafter must be rotated, such that the same person does not craft the spellsSpells for two consecutive Executive Votes. The Spell Crafter is a member of the Spell Team for a particular Executive Vote.

The Spell Reviewers (the Reviewers) are the people or entities responsible for reviewing the draft spellSpell as parsed by the Spell Crafter. The Reviewers are responsible for verifying the spellSpell, finding issues and catching bugs and mistakes in the spellSpell, and otherwise ensuring its quality. There is an important delineation between the function of Spell Crafters and Spell Reviewers: the Reviewers may not perform any addition, modification or removal of code or content within the spellSpell, although they may suggest changes to the Spell Crafter. Spell Reviewers are members of the wider Spell Team for a particular Executive Vote.

The Governance Point is selected from the Core Facilitatorsthe Core Facilitator. Currently, the only Core Facilitator is JanSky. Each Spell also has a designated Governance Backup. The Governance Backup is required to assume the responsibilities of the Governance Point if the original Governance Point becomes unavailable, effectively stepping into the role as needed. The Governance Point is responsible for coordinating the Executive Vote and ensuring that the information in the Executive Sheet accurately reflects the progress of the spellSpell.

The Technical Point has domain expertise as the crafter of the smart contracts, but the Governance Point also has crucial context and should serve as a cross-check to the extent they can. The Governance Point is expected to ask questions where needed.

The Technical Point role is filled by the Spell Team or the Spell Crafter from that group. For each Executive Vote, a Spell Team is selected from the Spell Roster to steward the spellSpell development process.

Within the Spell Team, the Spell Crafter serves as the primary point of contact for the Governance Point and any external parties. If the Spell Crafter is unavailable or if disagreements arise, the Governance Point’s secondary point of contact is the Spell Reviewers.

Input or opinions from external parties on technical details should be treated as informational and should not influence the spellSpell decision-making process.

The Content Liaisons are the stakeholders involved in a specific spellSpell. They participate in the verification process and confirm the accuracy of items relevant to their area of expertise, to ensure accuracy of those items in the Executive Sheet. Many different actors in the Sky Ecosystem serve as Content Liaisons for Executive Votes.

Office hours are set to "Yes" if a spellSpell introduces major changes that can affect external parties, or if a stakeholder makes a specific request for the office-hours modifier to be switched on. Typical examples include collateral offboarding, onboarding new modules, oracle changes, and other actions that may have a significant impact on the protocol or its users.

While stakeholders can request that Office Hours be switched on, the final decision and responsibility for setting this parameter rests with the Spell Crafter. If the office hours modifier is on, the spellSpell can only be executed between 14:00 and 21:00 UTC, Monday - Friday. The purpose of this modifier is to ensure that Ecosystem Actors are available to address any issues that may arise during or shortly after the execution of the spell. The spellSpell. The Spell will have an extra restriction on top of the GSM Pause Delay, meaning it can only be cast during that timeframe, regardless of when it was approved.

The Order of Operations parameter is relevant when actions within a spellSpell, or across multiple spellsSpells, must be executed in a specific order to ensure that the correct final value is set. This applies to cases where dependencies, conflicting changes, or timing-sensitive modifications require precise sequencing to achieve the intended outcome. The Order of Operations parameter is set to "Yes" when actions must be executed in a specific order.

Every action that should be included in the spellSpell must be present in the Executive Sheet. Each executive action is populated in the Executive Sheet under a column and broken down into "input" actions and "derived" actions. An Input Action represents a high-level category, and a Derived Action breaks down the Input Action into specific, actionable steps or changes. Each action in the Executive Sheet, whether input or derived, must have sufficient provenance to support its presence during the spellSpell.

The text for both "input" and "derived" actions listed in the Executive Sheet should follow previous wording and structural patterns. There should be no deviation from existing patterns of wording or sentence structure used in the Executive Sheet unless it is absolutely required for the spellSpell process to be completed. The instructions should be specific and follow previous instructions in the archive.

In the Google Sheet document, there is a tab named "spellSpell progress tracking". The Governance Point must:

1. Add a new column for the Executive Vote. The column should be added to the right in the document to make sure that the Executive Votes are sorted in chronological order.

2. Enter the Target Date.

The Governance Point must ensure that the progress for the spellSpell is updated accurately in the spellSpell progress tracker. When a step is completed, the Governance Point must write "done" in the spellSpell progress tracker column. This is an ongoing responsibility throughout the lifecycle of the Executive Vote to maintain real-time accuracy.

The Executive Document contains both text content and metadata fields, which are essential for its functionality and clarity. These include:

• The title field provides a concise and descriptive summary of the Executive Document, making it easy for stakeholders to identify the proposal.
• The summary field offers a high-level overview of the actions included in the spellSpell, helping voters quickly understand the scope and purpose of the proposal.
• The date field ensures that the proposal is aligned with the governance schedule and provides a clear reference for when the spellSpell is intended to be executed. The date specifies the Target Date of the spellSpell in UTC time.
• The address field contains the Ethereum address of the deployed Mainnet spellSpell on the blockchain, allowing stakeholders to verify its contents and execution status. When the Executive Vote is published on the Voting Portal the spellSpell address is a hyperlink that links to Etherscan.

The document uses different levels of Markdown headings to organize its content into distinct sections:

• First-level heading is used for the title of the document.
• Second-level headings are used for the four major sections of the Executive Document: Executive Summary, Proposal Details, Review, and Resources.
• Third-level headings are used within the Proposal Details section to describe individual input executive actions. Each action is presented under its own third-level heading, making it easy to identify and review.
• Fourth-level headings are used to describe specific derived actions within an input action. These headings provide additional context or detail necessary for understanding the implications of the input action, such as actions triggered by an Agent spellSpell or changes to market parameters.

This structured approach ensures that the document is both easy to navigate and comprehensive.

This section provides a detailed breakdown of each item included in the proposal. It includes:

• Input executive actions, which are presented under third-level Markdown headings. Each action includes links to the authorization and proposal documents and explains the implications of the action if the proposal passes.
• Derived actions, which are described under fourth-level Markdown headings when they provide additional context or detail necessary for understanding the implications of an input action. These headings are used to outline specific actions triggered by an input action, such as actions executed by a Prime spellSpell or changes to market parameters. Derived actions that are overly technical, redundant, or irrelevant to the proposal's primary focus may be excluded to maintain clarity and accessibility.

This section ensures that all actions are clearly explained and linked to their reasoning and authorization documents.

When an issue has been reported by a Spell validator, the Core FacilitatorsFacilitator or the Spell Team who worked on the Spell areis likely to respond to the issue. The Spell validator must assume that the parties providing the answer are acting maliciously and lying to prevent the discovery of their attack.

The validator may only consider the issue as resolved once they are comfortable that the issue does not constitute a bug or attack that poses a threat to the Sky Protocol. Only the validator who raised the issue is permitted to consider an issue as resolved, and any unresolved issue will prevent the Spell from passing validation.

Publicly reporting issues found during Spell validation is the recommended method of issue reporting. Issues reported publicly may be reported to Core Facilitatorsthe Core Facilitator using the "#new-Spells" channel in the Sky Builder Discord Group. In cases of potentially malicious Core FacilitatorsIf the Core Facilitator may be acting maliciously, issues should be reported to Aligned Delegates and wider Sky Governance using the "#governance" channel in the Sky Builder Discord Group. In cases where this is not possible, posts made to the Sky Forum may be used; however, these should be used as a last resort as they will likely cause a slower response time.

Sky Protocol uses circuit-breakers to mitigate undesired scenarios, which circuit-breakers are called MOM contracts. MOM contracts must first be triggered through a spellSpell, after which they bypass the GSM Pause Delay and can immediately act on the Protocol. See Exceptions.

In emergency scenarios, time is a scarce resource. Therefore, Standby Spells are used in validated emergency scenarios to trigger a MOM contract. In an emergency situation, spellSpell teams can then focus on crafting an ad hoc Emergency Spell to solve the root cause of an issue, if appropriate. Due to Standby Spells, it is no longer necessary in an emergency for spellSpell teams to spend time crafting and reviewing a spellSpell whose sole purpose is to trigger a mitigation of the issue, i.e., the MOM contract.

Standby Spells open new attack vectors that must be mitigated pursuant to ADs' Role In Standby Spells.

The currently available Standby Spells are defined in the subdocuments herein. The following list of Standby Spells is not exhaustive: that is, the Core Facilitator, in collaboration with the Emergency Response Group and spellSpell teams, has the discretion to develop and use a Standby Spell that is not listed in the subdocuments below. When that occurs, however, the Core Facilitator must ensure that the new Standby Spell is subsequently added to the subdocuments below.

The Executive Vote occurs approximately every two weeks, although this cadence can vary based on decisions made by the Core Facilitator and the current spellSpell team.

A scheduled Executive Vote can be postponed if deemed necessary by the Core Facilitator and the current spellSpell team.

Additional Executive Votes outside the regular schedule may be introduced if deemed necessary by the Core Facilitator and the current spellSpell team.

If there are no substantive changes due to be made to the Sky Protocol, the Core Facilitator, in conjunction with the spellSpell teams, may opt not to publish an Executive Vote. This decision should be announced and justified on the Sky Forum.

After the Atlas Edit Proposal is triggered, the Core Facilitator must verify that the Atlas Edit Proposal follows the template specified in Atlas Edit Proposal Template.

The Core Facilitator must also verify that the AEP has been submitted to the Atlas Github repository with a Pull Request by the AEP Author. Alternatively, the AEP author can request the Core Facilitator to create the Pull Request for them.

If the AEP is successfully verified, the Core Facilitator must

• Approve the AEP and assign it a formal #
• Update the Preamble to the AEP
• Merge the Pull Request

The Core Facilitator is required to review all Atlas Edit Proposals (AEPs) submitted for Formal Submission to determine whether they are misaligned.

Once an Atlas Edit Proposal has been formally submitted and has passed the Core Facilitators’Facilitator’s review, the AEP enters the Monthly Governance Cycle.

Initiation of the Agent Termination Protocol requires the token holders of an Agent to follow the special voting requirements prescribed in the Root Edit Primitive for the Agent’s termination. Typically, these special voting requirements include a supermajority (two-thirds of votes) in support of the decision to terminate, as well as a high minimum quorum (20% of all tokens must participate in the vote) and a lengthy voting period (two weeks) in order to provide the Agent’s token holders with sufficient notice. In addition, the Sky Core Facilitators must issue a notice in the Sky Forum publicizing, as specified in Agent Termination Process. These requirements include a minimum voting period, a minimum quorum, a supermajority approval threshold, and advance notice of the Agent’s proposed termination and subsequent votethe subsequent Agent vote issued in the Sky Forum by the Operational Facilitator.

If the Agent Termination Protocol is activated, the Agent’s designated Executor Agent is tasked with ensuring the smooth and seamless wind-down of all of the Agent’s activities and functions. The Executor Agent must ensure that the cessation of any functionality is clearly communicated and signaled to users or other stakeholders, with a wind-down period calibrated to enable a smooth transition. Sky Core Facilitators must oversee the Agent Termination Process and ensure that the Executor Agent is executing the wind-down of the Prime Agent’s business activities in a manner aligned with Sky Core and end users’ interests. The Executor Agent should also, to the extent practicable, ensure that the assets or holdings of the Prime Agent are proportionately disbursed to Prime Agent The Core Facilitator must oversee the Agent Termination Process and ensure that the Executor Agent is executing the wind-down of the Prime Agent’s business activities in a manner aligned with Sky Core and end users’ interests. The Executor Agent should also, to the extent practicable, ensure that the assets or holdings of the Prime Agent are proportionately disbursed to Prime Agent token holders.

Once the Executor Agent has ensured that all operational activities and functions of the Prime Agent have been wound down, the Sky Core FacilitatorsOperational Facilitator must issue a notice in the Sky Forum indicating the formal termination of the Agent. Any residual assets or holdings of the Prime Agents, that could not be disbursed to Prime Agent token holders, revert to ownership by Sky Core.

In the event of any dispute between the Agent or Agent token holders, and the designated Executor Agent carrying out the Agent Termination Process, the Sky Core FacilitatorsCore Facilitator must mediate. If there are operational disagreements between an Agent’s Founder or Agent token holders and the Executor Agent, the Sky Core Facilitators haveCore Facilitator has discretion to direct the Executor Agent to take a particular action as consistent with the Sky Core Atlas and the relevant Agent Artifact.

Multisig signers may be rotated as operational or security requirements evolve. All signer rotations must be communicated to Core GovOpsthe Protocol Security Workstream Lead by the Multisig Administrator, accompanied by clear documentation describing the reason for the change, the outgoing signer, and the incoming signer. Core GovOps must update the Multisig Registry to reflect the changes.

Any change to Multisig signer composition must be promptly communicated to Core GovOpsthe Protocol Security Workstream Lead by the Multisig Administrator. Core GovOps must update the Multisig Registry to ensure it includes, including all updated signer addresses.

Signer rotations must not reduce the total number of signers or decrease the signing threshold unless the Multisig Administrator provides a clear operational or security justification that is submitted to and approved by Core GovOpsthe Protocol Security Workstream Lead.