diff --git a/Sky Atlas/Sky Atlas.html b/Sky Atlas/Sky Atlas.html
index d7d904c..360f368 100644
--- a/Sky Atlas/Sky Atlas.html
+++ b/Sky Atlas/Sky Atlas.html
@@ -467,7 +467,7 @@
Articles
Risk Capital |
Article |
- Prime Agents who invest capital from Sky’s Collateral Portfolio using the Allocation System Primitive must hold Risk Capital to protect Sky from potential losses on these investments. This Article sets forth the framework governing Risk Capital. |
+ Prime Agents who invest capital from Sky's Collateral Portfolio using the Allocation System Primitive must hold Risk Capital to protect Sky from potential losses on these investments. This Article sets forth the framework governing Risk Capital. |
@@ -1675,7 +1675,7 @@ Sections & Primary Docs
- the Aligned Delegates ranked as Ranked Delegate on a daily basis;
- the budget to be deposited into each Aligned Delegate's AD Buffer, which is modified pursuant to voting and communication metrics;
- - the balance of each Aligned Delegate’s AD Buffer; and
+ - the balance of each Aligned Delegate's AD Buffer; and
- the amount to be paid out to each Aligned Delegate.Once calculated by the Core Facilitator, AD payouts are bundled into the next Executive Vote.
|
@@ -1694,7 +1694,7 @@ Sections & Primary Docs
Aligned Delegates - Budget And Participation Requirements - Payout Limitations For ADs Triggering Atlas Edit Weekly Cycle Proposals |
Core |
- If an AD has triggered an Atlas Edit Weekly Cycle Proposal pursuant to A.1.11 - Weekly Governance Cycle - Atlas Edit Weekly Cycle - Triggering Requirement, no payouts may be made that would reduce their AD Buffer below one (1) month’s worth of the budget specified in A.1.5 - Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots until the Proposal has been voted on or rejected by the Core Facilitator for misalignment. |
+ If an AD has triggered an Atlas Edit Weekly Cycle Proposal pursuant to A.1.11 - Weekly Governance Cycle - Atlas Edit Weekly Cycle - Triggering Requirement, no payouts may be made that would reduce their AD Buffer below one (1) month's worth of the budget specified in A.1.5 - Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots until the Proposal has been voted on or rejected by the Core Facilitator for misalignment. |
@@ -1718,7 +1718,7 @@ Sections & Primary Docs
|
Aligned Delegates - Budget And Participation Requirements - Voting-Activity Metrics |
Section |
- The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-activity metrics over the past six (6) months. This budget modification takes into account the overall participation of the Ranked Delegate in all votes they are eligible to cast as an Aligned Delegate (AD). If an RD participates in less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting activity, the RD’s budget is reduced correspondingly. Should an RD’s voting activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract. |
+ The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-activity metrics over the past six (6) months. This budget modification takes into account the overall participation of the Ranked Delegate in all votes they are eligible to cast as an Aligned Delegate (AD). If an RD participates in less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting activity, the RD's budget is reduced correspondingly. Should an RD's voting activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract. |
@@ -1726,7 +1726,7 @@ Sections & Primary Docs
|
Aligned Delegates - Budget And Participation Requirements - Voting-Communication Metrics |
Section |
- The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-communication metrics over the past six (6) months. An AD is required to provide an explanation for each vote they participate in. This budget modification takes into account the Ranked Delegate’s fulfillment of this voting-communication requirement in all votes they are eligible to cast as an Aligned Delegate (AD). If an RD provides the required voting-communication on less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting-communication activity, the RD’s budget is reduced correspondingly. Should an RD’s voting-communication activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract. |
+ The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-communication metrics over the past six (6) months. An AD is required to provide an explanation for each vote they participate in. This budget modification takes into account the Ranked Delegate's fulfillment of this voting-communication requirement in all votes they are eligible to cast as an Aligned Delegate (AD). If an RD provides the required voting-communication on less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting-communication activity, the RD's budget is reduced correspondingly. Should an RD's voting-communication activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract. |
@@ -1742,7 +1742,7 @@ Sections & Primary Docs
|
Aligned Delegates - Budget And Participation Requirements - Signal Account Requirement |
Core |
- RDs are required to maintain an active Signal account to facilitate communications related to emergency / urgent situations. This requirement applies regardless of whether an RD has been appointed to the Emergency Response Group. See A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. RDs must provide their Signal username to the Core Facilitator. The Core Facilitator is responsible for maintaining an internal registry of RDs’ Signal accounts. Because the ranked RDs are continually changing, the Core Facilitator must ensure that the internal registry is maintained on a frequent basis. The Core Facilitator must check the active status of the RDs’ Signal accounts by sending test messages and confirming the RDs’ timely response; this must be done regularly, on a schedule known only to the Core Facilitator. If an RD fails to timely respond to the test messages, the Core Facilitator must remove them from RD status. |
+ RDs are required to maintain an active Signal account to facilitate communications related to emergency / urgent situations. This requirement applies regardless of whether an RD has been appointed to the Emergency Response Group. See A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. RDs must provide their Signal username to the Core Facilitator. The Core Facilitator is responsible for maintaining an internal registry of RDs' Signal accounts. Because the ranked RDs are continually changing, the Core Facilitator must ensure that the internal registry is maintained on a frequent basis. The Core Facilitator must check the active status of the RDs' Signal accounts by sending test messages and confirming the RDs' timely response; this must be done regularly, on a schedule known only to the Core Facilitator. If an RD fails to timely respond to the test messages, the Core Facilitator must remove them from RD status. |
@@ -1942,7 +1942,7 @@ Sections & Primary Docs
|
Emergency Response System - Emergency Response - Definition Of Emergency Situations |
Core |
- An emergency situation is any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members and users of the Ecosystem. Pursuant to A.0.1 - Atlas Preamble - General Provisions - Facilitators’ Broad Discretionary Capacity, the Facilitators have broad discretion to apply the emergency-situation processes defined in A.1.8 - A1 - Emergency Response System - Emergency Response to urgent situations. Urgent situations are defined as any situation that involves a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity. |
+ An emergency situation is any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members and users of the Ecosystem. Pursuant to A.0.1 - Atlas Preamble - General Provisions - Facilitators' Broad Discretionary Capacity, the Facilitators have broad discretion to apply the emergency-situation processes defined in A.1.8 - A1 - Emergency Response System - Emergency Response to urgent situations. Urgent situations are defined as any situation that involves a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity. |
@@ -1969,7 +1969,7 @@ Sections & Primary Docs
| The membership of the Emergency Response Group is defined as Active Data in A.1.8 - Emergency Response Group Current Membership. The Active Data is updated as follows:
- The Responsible Party is the Governance Facilitators.
- - The Update Process must follow the protocol for ‘Direct Edit’.
+ - The Update Process must follow the protocol for 'Direct Edit'.
|
@@ -2044,7 +2044,7 @@ Sections & Primary Docs
Emergency Response System - Emergency Response - Changes To Approved Emergency Contact Mechanisms |
Core |
- The Governance Facilitators may recommend changing the approved emergency contact mechanism specified in A.1.8 - Emergency Response System - Emergency Response - Approved Emergency Contact Mechanisms, but they must do so in consultation with the Protocol Security Workstream Lead. The Governance Facilitators’ recommendation is subject to a poll through the Operational Weekly Governance Cycle. |
+ The Governance Facilitators may recommend changing the approved emergency contact mechanism specified in A.1.8 - Emergency Response System - Emergency Response - Approved Emergency Contact Mechanisms, but they must do so in consultation with the Protocol Security Workstream Lead. The Governance Facilitators' recommendation is subject to a poll through the Operational Weekly Governance Cycle. |
@@ -2056,9 +2056,9 @@ Sections & Primary Docs
|
|
- A.1.8 - Emergency Response System - Emergency Response - Facilitators’ Roles And Responsibilities
+ A.1.8 - Emergency Response System - Emergency Response - Facilitators' Roles And Responsibilities
|
- Emergency Response System - Emergency Response - Facilitators’ Roles And Responsibilities |
+ Emergency Response System - Emergency Response - Facilitators' Roles And Responsibilities |
Core |
The Support Facilitators are empowered to declare an emergency situation, in consultation with the responsible Facilitator of the impacted Scope(s) and any relevant Scope Advisor(s). After an emergency situation has been declared, the Support or Governance Facilitators are responsible for coordinating emergency-situation processes to ensure they are civil, consistently applied and aligned. The Governance Facilitators are responsible for publishing Polls and Executive Votes. Any participant in the Sky Ecosystem, including Ecosystem Actors, Aligned Delegates or other community members, can request that the Support Facilitators declare an emergency. The Support Facilitators are granted broad discretion in handling such requests. |
@@ -2162,7 +2162,7 @@ Sections & Primary Docs
Emergency Response System - Emergency Response - Accountability Measures for Ecosystem Actor Individuals And Teams |
Core |
- For Ecosystem Actors appointed to the Emergency Response Group, fulfilling the responsibilities of this role is as critical to their overall performance evaluation as their customary deliverables. The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members’ failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner. If the deficient Emergency Response Group Member is an Ecosystem Actor individual, the individual should be removed from the Group. If the deficient Emergency Response Group Member is part of an Ecosystem Actor team, the specific member who has failed to meet requirements should be removed from the Group. If different Emergency Response Group Members from the same Ecosystem Actor team consistently fail to meet requirements, the Ecosystem Actor team as a whole should be removed from the Group. The removal of a Member from the Group is done at the discretion of the Support Facilitators and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review. When an Ecosystem Actor is removed from the Emergency Response Group for deficient performance, the Support Facilitators must transparently announce this action via a post to the Sky Forum. Further, the removal must be incorporated into the evaluation of the Ecosystem Actor’s overall performance. The Support Facilitators has the discretion to decide if documentation supporting the removal should be retained internally or publicly shared on the Forum (with redactions, if needed). |
+ For Ecosystem Actors appointed to the Emergency Response Group, fulfilling the responsibilities of this role is as critical to their overall performance evaluation as their customary deliverables. The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members' failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner. If the deficient Emergency Response Group Member is an Ecosystem Actor individual, the individual should be removed from the Group. If the deficient Emergency Response Group Member is part of an Ecosystem Actor team, the specific member who has failed to meet requirements should be removed from the Group. If different Emergency Response Group Members from the same Ecosystem Actor team consistently fail to meet requirements, the Ecosystem Actor team as a whole should be removed from the Group. The removal of a Member from the Group is done at the discretion of the Support Facilitators and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review. When an Ecosystem Actor is removed from the Emergency Response Group for deficient performance, the Support Facilitators must transparently announce this action via a post to the Sky Forum. Further, the removal must be incorporated into the evaluation of the Ecosystem Actor's overall performance. The Support Facilitators has the discretion to decide if documentation supporting the removal should be retained internally or publicly shared on the Forum (with redactions, if needed). |
@@ -2170,7 +2170,7 @@ Sections & Primary Docs
|
Emergency Response System - Emergency Response - Accountability Measures For Alignment Conservers |
Core |
- For an Alignment Conserver who has been appointed to the Emergency Response Group, the requirements of this role become as critical to the assessment of their overall performance as their customary obligations. The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members’ failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner. Where the deficient Member is an Alignment Conserver, that Member should be derecognized pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process. Where the deficient Alignment Conserver is the Support Facilitators, the Protocol Security Workstream Lead and a majority of active Scope Facilitators must reach consensus in order to initiate a derecognition proceeding against the Support Facilitators. Once this threshold is met, the procedure defined in A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process should be followed. In the interim, other Scope Facilitators must step in temporarily to coordinate emergency response. The initiation of derecognition is done at the discretion of the Support Facilitators (or other Scope Facilitator) and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review. When an Alignment Conserver is removed from the Emergency Response Group and derecognized for deficient performance, the Governance Facilitators must transparently announce this action pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Derecognition Notice. The Support Facilitators have the discretion to decide if documentation supporting the Alignment Conserver’s derecognition and removal should be retained internally or publicly shared on the Forum (with redactions, if needed). |
+ For an Alignment Conserver who has been appointed to the Emergency Response Group, the requirements of this role become as critical to the assessment of their overall performance as their customary obligations. The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members' failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner. Where the deficient Member is an Alignment Conserver, that Member should be derecognized pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process. Where the deficient Alignment Conserver is the Support Facilitators, the Protocol Security Workstream Lead and a majority of active Scope Facilitators must reach consensus in order to initiate a derecognition proceeding against the Support Facilitators. Once this threshold is met, the procedure defined in A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process should be followed. In the interim, other Scope Facilitators must step in temporarily to coordinate emergency response. The initiation of derecognition is done at the discretion of the Support Facilitators (or other Scope Facilitator) and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review. When an Alignment Conserver is removed from the Emergency Response Group and derecognized for deficient performance, the Governance Facilitators must transparently announce this action pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Derecognition Notice. The Support Facilitators have the discretion to decide if documentation supporting the Alignment Conserver's derecognition and removal should be retained internally or publicly shared on the Forum (with redactions, if needed). |
@@ -5344,7 +5344,7 @@ Sections & Primary Docs
|
Sky Core Governance Security - Emergency Spells - Emergency Spells Definition |
Core |
- Emergency Spells are expedited ad hoc spells that, while typically compliant with all customary quality-assurance processes, do not adhere to the normal spell cadence. Emergency Spells solve the root issue of an emergency / urgent situation impacting the Protocol and are used when a rapid response time is needed. The Support and Governance Facilitators are responsible for managing the use of Emergency Spells pursuant to A.1.8 - Emergency Response System - Emergency Response - Facilitators’s Roles And Responsibilities and A.1.8 - Emergency Response System - Emergency Response - Known And Uncontentious Remedies. |
+ Emergency Spells are expedited ad hoc spells that, while typically compliant with all customary quality-assurance processes, do not adhere to the normal spell cadence. Emergency Spells solve the root issue of an emergency / urgent situation impacting the Protocol and are used when a rapid response time is needed. The Support and Governance Facilitators are responsible for managing the use of Emergency Spells pursuant to A.1.8 - Emergency Response System - Emergency Response - Facilitators's Roles And Responsibilities and A.1.8 - Emergency Response System - Emergency Response - Known And Uncontentious Remedies. |
@@ -5360,7 +5360,7 @@ Sections & Primary Docs
|
Sky Core Governance Security - Emergency Spells - Standby Spells Definition |
Core |
- Sky Protocol uses circuit-breakers to mitigate undesired scenarios, which circuit-breakers are called MOM contracts. MOM contracts must first be triggered through a spell, after which they bypass the GSM Pause Delay and can immediately act on the Protocol. See A.1.9 - Sky Core Governance Security - Governance Security Delay Requirements - 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, spell 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 spell teams to spend time crafting and reviewing a spell 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 A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells. |
+ Sky Protocol uses circuit-breakers to mitigate undesired scenarios, which circuit-breakers are called MOM contracts. MOM contracts must first be triggered through a spell, after which they bypass the GSM Pause Delay and can immediately act on the Protocol. See A.1.9 - Sky Core Governance Security - Governance Security Delay Requirements - 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, spell 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 spell teams to spend time crafting and reviewing a spell 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 A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells. |
@@ -5500,9 +5500,9 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Support Scope Facilitators’ Role In Standby Spells
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Support Scope Facilitators' Role In Standby Spells
|
- Sky Core Governance Security - Emergency Spells - Support Scope Facilitators’ Role In Standby Spells |
+ Sky Core Governance Security - Emergency Spells - Support Scope Facilitators' Role In Standby Spells |
Core |
The role of the Support Facilitators in the Standby Spell process is as follows:
@@ -5515,11 +5515,11 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Governance Facilitators’ Role In Standby Spells
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Governance Facilitators' Role In Standby Spells
|
- Sky Core Governance Security - Emergency Spells - Governance Facilitators’ Role In Standby Spells |
+ Sky Core Governance Security - Emergency Spells - Governance Facilitators' Role In Standby Spells |
Core |
- All Governance Facilitators must promptly acknowledge receipt of the Support Facilitators’ decision to use a Standby Spell. This acknowledgment must take place in the communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. The Governance Facilitators are responsible for actioning the Standby Spell and liaising with the Ranked Delegates (and other Aligned Delegates as needed) to gather the necessary support for it. |
+ All Governance Facilitators must promptly acknowledge receipt of the Support Facilitators' decision to use a Standby Spell. This acknowledgment must take place in the communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. The Governance Facilitators are responsible for actioning the Standby Spell and liaising with the Ranked Delegates (and other Aligned Delegates as needed) to gather the necessary support for it. |
@@ -5527,7 +5527,7 @@ Sections & Primary Docs
|
Sky Core Governance Security - Emergency Spells - Requirement To Validate Authenticity Of Standby Spell |
Core |
- One Authorized Representative, as defined in the subdocument below, from each Governance Facilitator must validate the authenticity of the Standby Spell. This validation must be in the form of a written communication in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. Only the entities specified in A.1.9 - Sky Core Governance Security - Emergency Spells - Current Entities Authorized To Validate Authenticity of Standby Spell are authorized to provide the validation of authenticity. Pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells, ADs are prohibited from voting for a Standby Spell without this validation of authenticity. |
+ One Authorized Representative, as defined in the subdocument below, from each Governance Facilitator must validate the authenticity of the Standby Spell. This validation must be in the form of a written communication in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. Only the entities specified in A.1.9 - Sky Core Governance Security - Emergency Spells - Current Entities Authorized To Validate Authenticity of Standby Spell are authorized to provide the validation of authenticity. Pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells, ADs are prohibited from voting for a Standby Spell without this validation of authenticity. |
@@ -5561,9 +5561,9 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells
+ A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells
|
- Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells |
+ Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells |
Core |
ADs are strictly prohibited from voting to use a Standby Spell unless they have first confirmed all of the following requirements:
@@ -5580,7 +5580,7 @@ Sections & Primary Docs
|
Sky Core Governance Security - Emergency Spells - AD Reliance On Governance Facilitators In Standby Spell Process Where Governance Facilitator Is Nonresponsive |
Core |
- There is an exception to the requirement that all Governance Facilitators must validate the authenticity of a Standby Spell. In situations where a Governance Facilitator has failed to respond to the emergency situation, the Support Facilitators may temporarily grant the responding Governance Facilitator(s) the sole authority to validate the authenticity of the Emergency Spell pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells. The Support Facilitators must communicate this in writing in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. |
+ There is an exception to the requirement that all Governance Facilitators must validate the authenticity of a Standby Spell. In situations where a Governance Facilitator has failed to respond to the emergency situation, the Support Facilitators may temporarily grant the responding Governance Facilitator(s) the sole authority to validate the authenticity of the Emergency Spell pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells. The Support Facilitators must communicate this in writing in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. |
@@ -5588,7 +5588,7 @@ Sections & Primary Docs
|
Sky Core Governance Security - Emergency Spells - Misalignment To Vote For Unvalidated Standby Spell |
Core |
- It is severe misalignment for an Aligned Delegate to vote for a Standby Spell whose authenticity has not been validated pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells. Aligned Delegates in breach of this requirement must be immediately derecognized and their full AD Buffer should be confiscated. |
+ It is severe misalignment for an Aligned Delegate to vote for a Standby Spell whose authenticity has not been validated pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells. Aligned Delegates in breach of this requirement must be immediately derecognized and their full AD Buffer should be confiscated. |
@@ -5759,14 +5759,14 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Support Facilitators’ Role In Protego Usage
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Support Facilitators' Role In Protego Usage
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Support Facilitators’ Role In Protego Usage |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Support Facilitators' Role In Protego Usage |
Core |
The role of the Support Facilitators in the usage of Protego is as follows:
- Protego can only be used in response to a properly validated and categorized emergency scenario, for which the Support Facilitators are responsible. See A.1.8 - Emergency Response System - Emergency Response - Incident Validation and A.1.8 - Emergency Response System - Emergency Response - Incident Categorization.
- - The decision to initiate the process to use Protego is reserved for the Support Facilitators; where possible, the Support Facilitators should consult with the responsible Facilitator of the impacted Scope(s) and any relevant Scope Advisor(s). See A.1.8 - Emergency Response System - Emergency Response - Facilitators’ Roles And Responsibilities.
+ - The decision to initiate the process to use Protego is reserved for the Support Facilitators; where possible, the Support Facilitators should consult with the responsible Facilitator of the impacted Scope(s) and any relevant Scope Advisor(s). See A.1.8 - Emergency Response System - Emergency Response - Facilitators' Roles And Responsibilities.
- The Support Facilitators must explicitly communicate the decision to use Protego in the secure, private communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group or on a “war room” video call.
- If the decision to use Protego is first reached on a video call, the Support Facilitators are required thereafter to promptly document their decision in the secure, private communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group.
- If the Support Facilitators decide to use Protego, TechOps Services must promptly trigger an incident to the Emergency Response Group as specified in A.1.8 - Emergency Response System - Emergency Response - Emergency-Contact Mechanism Trigger.
@@ -5775,25 +5775,25 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators’ Role In Protego Usage
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators' Role In Protego Usage
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators’ Role In Protego Usage |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators' Role In Protego Usage |
Core |
- All Governance Facilitators must promptly acknowledge receipt of the Support Facilitators’ decision to use Protego. This acknowledgment must take place in the communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. The Governance Facilitators are responsible for actioning the usage of Protego and liaising with the Ranked Delegates (and other Aligned Delegates as needed) to gather the necessary support for it. |
+ All Governance Facilitators must promptly acknowledge receipt of the Support Facilitators' decision to use Protego. This acknowledgment must take place in the communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. The Governance Facilitators are responsible for actioning the usage of Protego and liaising with the Ranked Delegates (and other Aligned Delegates as needed) to gather the necessary support for it. |
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators’ Role In Protego Usage - Requirement To Validate Authenticity Of Emergency Drop Spell
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators' Role In Protego Usage - Requirement To Validate Authenticity Of Emergency Drop Spell
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators’ Role In Protego Usage - Requirement To Validate Authenticity Of Emergency Drop Spell |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Governance Facilitators' Role In Protego Usage - Requirement To Validate Authenticity Of Emergency Drop Spell |
Core |
- One Authorized Representative, as defined in the subdocument below, from each Governance Facilitator must validate the authenticity of the Emergency Drop Spell, if applicable. This validation must be in the form of a written communication in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. Only the entities specified in A.1.9 - Sky Core Governance Security - Emergency Spells - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell are authorized to provide the validation of authenticity. Pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Protego Usage, ADs are prohibited from voting for an Emergency Drop Spell without this validation of authenticity. |
+ One Authorized Representative, as defined in the subdocument below, from each Governance Facilitator must validate the authenticity of the Emergency Drop Spell, if applicable. This validation must be in the form of a written communication in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. Only the entities specified in A.1.9 - Sky Core Governance Security - Emergency Spells - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell are authorized to provide the validation of authenticity. Pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Protego Usage, ADs are prohibited from voting for an Emergency Drop Spell without this validation of authenticity. |
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Requirement To Validate Authenticity Of Emergency Drop Spell - Governance Facilitators’ Role In Protego Usage - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Requirement To Validate Authenticity Of Emergency Drop Spell - Governance Facilitators' Role In Protego Usage - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Requirement To Validate Authenticity Of Emergency Drop Spell - Governance Facilitators’ Role In Protego Usage - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - Requirement To Validate Authenticity Of Emergency Drop Spell - Governance Facilitators' Role In Protego Usage - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell |
Core |
This document defines the term “Authorized Representative” as used in A.1.9 - Sky Core Governance Security - Emergency Spells - Requirement To Validate Authenticity Of Emergency Drop Spell. The entities listed below are authorized to validate the authenticity of an Emergency Drop Spell on behalf of the specified Governance Facilitators:
@@ -5821,14 +5821,14 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs’ Role In Protego Usage
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs' Role In Protego Usage
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs’ Role In Protego Usage |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs' Role In Protego Usage |
Core |
ADs are strictly prohibited from voting to use an Emergency Drop Spell, or to give authority to the Protego contract, unless they have first confirmed all of the following requirements:
- - Receipt of the Support Facilitator’s official notification of the emergency scenario in the Emergency Contact Mechanism specified in A.1.8 - Emergency Response System - Emergency Response - Emergency-Contact Mechanism Trigger;
- - Receipt of the Support Facilitators’ announcement of the decision to use Protego or an Emergency Drop Spell in the communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group; and
+ - Receipt of the Support Facilitator's official notification of the emergency scenario in the Emergency Contact Mechanism specified in A.1.8 - Emergency Response System - Emergency Response - Emergency-Contact Mechanism Trigger;
+ - Receipt of the Support Facilitators' announcement of the decision to use Protego or an Emergency Drop Spell in the communication channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group; and
- All Governance Facilitators have validated the authenticity of the Emergency Drop Spell, if applicable. This validation must fulfill two requirements: (1) the validation must be in the form of a written communication in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group; and (2) the validation must be provided by the authorized entities listed in A.1.9 - Sky Core Governance Security - Emergency Spells - Current Entities Authorized To Validate Authenticity of Emergency Drop Spell.
After ADs have confirmed all requirements are met, they must either (1) promptly vote to approve the usage of Protego or the Emergency Drop Spell, or (2) communicate any concerns to the Governance Facilitators and collaborate with the latter for a speedy resolution.
@@ -5836,19 +5836,19 @@ Sections & Primary Docs
|
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs’ Role In Protego Usage - AD Reliance On Governance Facilitators In Emergency Drop Spell Process Where Governance Facilitator Is Nonresponsive
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs' Role In Protego Usage - AD Reliance On Governance Facilitators In Emergency Drop Spell Process Where Governance Facilitator Is Nonresponsive
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs’ Role In Protego Usage - AD Reliance On Governance Facilitators In Emergency Drop Spell Process Where Governance Facilitator Is Nonresponsive |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs' Role In Protego Usage - AD Reliance On Governance Facilitators In Emergency Drop Spell Process Where Governance Facilitator Is Nonresponsive |
Core |
- There is an exception to the requirement that all Governance Facilitators must validate the authenticity of an Emergency Drop Spell. In situations where a Governance Facilitator has failed to respond to the emergency situation, the Support Facilitators may temporarily grant the responding Governance Facilitator(s) the sole authority to validate the authenticity of the Emergency Drop Spell pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Protego Usage. The Support Facilitators must communicate this in writing in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. |
+ There is an exception to the requirement that all Governance Facilitators must validate the authenticity of an Emergency Drop Spell. In situations where a Governance Facilitator has failed to respond to the emergency situation, the Support Facilitators may temporarily grant the responding Governance Facilitator(s) the sole authority to validate the authenticity of the Emergency Drop Spell pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Protego Usage. The Support Facilitators must communicate this in writing in the secure channel specified in A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. |
|
- A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs’ Role In Protego Usage - Misalignment To Vote For Unvalidated Emergency Drop Spell
+ A.1.9 - Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs' Role In Protego Usage - Misalignment To Vote For Unvalidated Emergency Drop Spell
|
- Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs’ Role In Protego Usage - Misalignment To Vote For Unvalidated Emergency Drop Spell |
+ Sky Core Governance Security - Emergency Spells - Protego - Protego Usage Process Definition - ADs' Role In Protego Usage - Misalignment To Vote For Unvalidated Emergency Drop Spell |
Core |
- It is severe misalignment for an Aligned Delegate to vote for an Emergency Drop Spell whose authenticity has not been validated pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Protego Usage. Aligned Delegates in breach of this requirement must be immediately derecognized and their full AD Buffer should be confiscated. |
+ It is severe misalignment for an Aligned Delegate to vote for an Emergency Drop Spell whose authenticity has not been validated pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Protego Usage. Aligned Delegates in breach of this requirement must be immediately derecognized and their full AD Buffer should be confiscated. |
@@ -6044,7 +6044,7 @@ Sections & Primary Docs
|
Weekly Governance Cycle - Atlas Edit Weekly Cycle - Triggering Requirement |
Core |
- An Atlas Edit Weekly Cycle Proposal (also “Weekly Cycle Proposal” or “AEW Proposal”) can proceed to a vote only if it is triggered by a Ranked Delegate whose AD Buffer contains at least one (1) month’s worth of budget at the time of triggering the Proposal. The value of this threshold in USDS is currently specified in A.1.5- Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots. The Core Facilitator is responsible for confirming that these requirements are met. Aligned Delegates (including Ranked Delegates) are prohibited from authoring an Atlas Edit Weekly Cycle Proposal. Ranked Delegates are limited to triggering Proposals authored by others. To trigger a Proposal, the Ranked Delegate must post a reply to the Author’s Weekly Cycle Proposal on the Forum. The Ranked Delegate’s post should signal their intent to trigger the Weekly Cycle Proposal. Where more than one Ranked Delegate posts an intention to trigger a Weekly Cycle Proposal, the first Ranked Delegate to post a reply to the Author’s Forum post shall be treated as the triggering Ranked Delegate. If the Weekly Cycle Proposal is subsequently voted down, the triggering Ranked Delegate loses their entire AD Buffer. |
+ An Atlas Edit Weekly Cycle Proposal (also “Weekly Cycle Proposal” or “AEW Proposal”) can proceed to a vote only if it is triggered by a Ranked Delegate whose AD Buffer contains at least one (1) month's worth of budget at the time of triggering the Proposal. The value of this threshold in USDS is currently specified in A.1.5- Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots. The Core Facilitator is responsible for confirming that these requirements are met. Aligned Delegates (including Ranked Delegates) are prohibited from authoring an Atlas Edit Weekly Cycle Proposal. Ranked Delegates are limited to triggering Proposals authored by others. To trigger a Proposal, the Ranked Delegate must post a reply to the Author's Weekly Cycle Proposal on the Forum. The Ranked Delegate's post should signal their intent to trigger the Weekly Cycle Proposal. Where more than one Ranked Delegate posts an intention to trigger a Weekly Cycle Proposal, the first Ranked Delegate to post a reply to the Author's Forum post shall be treated as the triggering Ranked Delegate. If the Weekly Cycle Proposal is subsequently voted down, the triggering Ranked Delegate loses their entire AD Buffer. |
@@ -6135,7 +6135,7 @@ Sections & Primary Docs
| Monthly Governance Cycle - Atlas Edit Monthly Cycle - Triggering Requirement
|
Core |
- An Atlas Edit Monthly Cycle Proposal can proceed to verification by the Core Facilitator only if it is triggered by a Ranked Delegate whose AD Buffer contains at least one (1) month’s worth of budget at the time of triggering the Proposal. The value of this threshold in USDS is currently specified in A.1.5 - Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots. The Core Facilitator is responsible for confirming that these requirements are met. Aligned Delegates (including Ranked Delegates) are prohibited from authoring an Atlas Edit Monthly Cycle Proposal. Ranked Delegates are limited to triggering Proposals authored by others. To trigger a Proposal, the Ranked Delegate must post a reply to the Author’s Monthly Cycle Proposal on the Forum. The Ranked Delegate should indicate their intent to trigger the Monthly Cycle Proposal. Where more than one Ranked Delegate posts an intention to trigger a Monthly Cycle Proposal, the first Ranked Delegate to post a reply to the Author’s Forum post shall be treated as the triggering Ranked Delegate. If the Proposal is edited subsequent to being triggered, the Proposal must be triggered again before proceeding further in the Atlas Edit Monthly Cycle process. If the Monthly Cycle Proposal is voted down, the triggering Ranked Delegate loses their entire AD Buffer. |
+ An Atlas Edit Monthly Cycle Proposal can proceed to verification by the Core Facilitator only if it is triggered by a Ranked Delegate whose AD Buffer contains at least one (1) month's worth of budget at the time of triggering the Proposal. The value of this threshold in USDS is currently specified in A.1.5 - Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots. The Core Facilitator is responsible for confirming that these requirements are met. Aligned Delegates (including Ranked Delegates) are prohibited from authoring an Atlas Edit Monthly Cycle Proposal. Ranked Delegates are limited to triggering Proposals authored by others. To trigger a Proposal, the Ranked Delegate must post a reply to the Author's Monthly Cycle Proposal on the Forum. The Ranked Delegate should indicate their intent to trigger the Monthly Cycle Proposal. Where more than one Ranked Delegate posts an intention to trigger a Monthly Cycle Proposal, the first Ranked Delegate to post a reply to the Author's Forum post shall be treated as the triggering Ranked Delegate. If the Proposal is edited subsequent to being triggered, the Proposal must be triggered again before proceeding further in the Atlas Edit Monthly Cycle process. If the Monthly Cycle Proposal is voted down, the triggering Ranked Delegate loses their entire AD Buffer. |
@@ -6802,7 +6802,7 @@ Sections & Primary Docs
- the Artifact provides clear authorization for all actions taken by the Agent;
- the Artifact accurately reflects the current state of the Agent and its operations;
- - the Artifact conforms to all specifications in the Sky Core Atlas, including, without limitation, the specifications for each of the Sky Primitives (see A.2.4); and
+ - the Artifact conforms to all specifications in the Sky Core Atlas, including, without limitation, the specifications for each of the Sky Primitives (see A.2.4); and
- the Artifact is free of significant ambiguities or contradictions.
If the Agent has an Operational Executor Agent then this responsibility is shared by Operational GovOps and the Operational Facilitator.
|
@@ -6813,7 +6813,7 @@ Sections & Primary Docs
Review By Core GovOps |
Core |
- The documents herein define the process for review of Agent Artifacts for their compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact. |
+ The documents herein define the process for review of Agent Artifacts for their compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact. |
@@ -6821,7 +6821,7 @@ Sections & Primary Docs
|
Core GovOps Initiatives Review Of Agent Artifact |
Core |
- Core GovOps may review an Agent Artifact for its compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact at any time. This review may either be initiated by Core GovOps in response to an issue that has arisen or be conducted as part of a regular review process established by Core GovOps. |
+ Core GovOps may review an Agent Artifact for its compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact at any time. This review may either be initiated by Core GovOps in response to an issue that has arisen or be conducted as part of a regular review process established by Core GovOps. |
@@ -6829,7 +6829,7 @@ Sections & Primary Docs
|
Core GovOps Shares Initial Findings With Agent |
Core |
- If Core GovOps identifies deficiencies in an Agent Artifact relative to the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact, Core GovOps shares those findings with the Agent and its Operational Executor Agent, if applicable. |
+ If Core GovOps identifies deficiencies in an Agent Artifact relative to the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact, Core GovOps shares those findings with the Agent and its Operational Executor Agent, if applicable. |
@@ -6853,7 +6853,7 @@ Sections & Primary Docs
|
Remediation By Agent |
Core |
- The Agent must submit a Root Edit Proposal to update its Artifact to address the deficiencies identified in the final set of findings (see A.1.14 - Publication Of Final Findings By Core GovOps). If the Agent does not, Core GovOps may propose an Atlas Edit Proposal to directly modify the Agent Artifact to address the deficiencies. |
+ The Agent must submit a Root Edit Proposal to update its Artifact to address the deficiencies identified in the final set of findings (see A.1.14 - Publication Of Final Findings By Core GovOps). If the Agent does not, Core GovOps may propose an Atlas Edit Proposal to directly modify the Agent Artifact to address the deficiencies. |
@@ -6869,7 +6869,7 @@ Sections & Primary Docs
|
Penalties |
Core |
- Penalties for an Agent failing to meet the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact will be specified in a future iteration of the Atlas. |
+ Penalties for an Agent failing to meet the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact will be specified in a future iteration of the Atlas. |
@@ -6885,7 +6885,7 @@ Sections & Primary Docs
|
Process For Carrying Out Changes |
Core |
- Updates to Agent Artifacts to conform to changes in specifications may either be carried out by each Agent (see A.1.14 - Changes By Agents) or carried out directly by Core GovOps (see A.1.14 - Changes By Core GovOps). If Core GovOps chooses to directly carry out the changes, it must communicate this directly to the affected Agents before submitting an Atlas Edit Proposal. Otherwise the process for changes carried out by Agents applies. |
+ Updates to Agent Artifacts to conform to changes in specifications may either be carried out by each Agent (see A.1.14 - Changes By Agents) or carried out directly by Core GovOps (see A.1.14 - Changes By Core GovOps). If Core GovOps chooses to directly carry out the changes, it must communicate this directly to the affected Agents before submitting an Atlas Edit Proposal. Otherwise the process for changes carried out by Agents applies. |
@@ -8579,7 +8579,7 @@ Sections & Primary Docs
|
Limitations On Usage Of Root Edit Primitive Prior To Tokens Being Publicly Held |
Core |
- Until the tokens of a Prime Agent are Publicly Held, as defined in A.2.4 - Publicly Held Definition, the Root Edit Primitive will not be operational. Instead, if a Prime Agent wishes to edit its Agent Artifact, it must use the customary Atlas Edit Proposal processes specified in the Sky Core Atlas at A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle or A.1.12 - A2 - Monthly Governance Cycle - Atlas Edit Monthly Cycle. The process for Prime Agents to use the Atlas Edit Proposal process is further specified in A.2.4 - Atlas Edit Proposal Process For Prime Agents. |
+ Until the tokens of a Prime Agent are Publicly Held, as defined in A.2.4 - Publicly Held Definition, the Root Edit Primitive will not be operational. Instead, if a Prime Agent wishes to edit its Agent Artifact, it must use the customary Atlas Edit Proposal processes specified in the Sky Core Atlas at A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle or A.1.12 - A2 - Monthly Governance Cycle - Atlas Edit Monthly Cycle. The process for Prime Agents to use the Atlas Edit Proposal process is further specified in A.2.4 - Atlas Edit Proposal Process For Prime Agents. |
@@ -8587,7 +8587,7 @@ Sections & Primary Docs
|
Publicly Held Definition |
Core |
- The tokens of a Prime Agent shall be deemed Publicly Held if they are held by at least 2,000 Public Holders who collectively own 10% or more of the Prime Agent’s portion of its genesis supply, as defined in A.2.4 - Agent Token Genesis Supply. Public Holders are unique wallet addresses, excluding any address reasonably believed to be controlled by the Prime Agent, its core contributors, or their affiliates. An entity is affiliated with another if it directly or indirectly controls, is controlled by, or is under common control with such other entity. To qualify as a Public Holder, tokens owned by a wallet address must not be subject to any contractual, legal, or technical transfer restrictions, including:
+ | The tokens of a Prime Agent shall be deemed Publicly Held if they are held by at least 2,000 Public Holders who collectively own 10% or more of the Prime Agent's portion of its genesis supply, as defined in A.2.4 - Agent Token Genesis Supply. Public Holders are unique wallet addresses, excluding any address reasonably believed to be controlled by the Prime Agent, its core contributors, or their affiliates. An entity is affiliated with another if it directly or indirectly controls, is controlled by, or is under common control with such other entity. To qualify as a Public Holder, tokens owned by a wallet address must not be subject to any contractual, legal, or technical transfer restrictions, including:
- time-based vesting or lock-up schedules;
- contractual resale limitations (including any limitations imposed by token purchase agreements, SAFTs, or other similar instruments); or
@@ -8602,7 +8602,7 @@ Sections & Primary Docs
|
Atlas Edit Proposal Process For Prime Agents |
Core |
- Prime Agents that do not have an operational Root Edit Primitive must work with Core GovOps to use the Atlas Edit Weekly Cycle (see A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle) process to update their Agent Artifacts, as specified in the documents herein. |
+ Prime Agents that do not have an operational Root Edit Primitive must work with Core GovOps to use the Atlas Edit Weekly Cycle (see A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle) process to update their Agent Artifacts, as specified in the documents herein. |
@@ -8724,10 +8724,10 @@ Sections & Primary Docs
| Core |
The Upkeep Rebate Primitive allows a Prime Agent (”Holding Agent”) to claim a rebate on its Ecosystem Upkeep Fees when it holds any portion of the token supply of another Prime Agent (”Issuing Agent”). Ecosystem Upkeep Fees are accounted on a monthly basis. The Upkeep Rebate is calculated on the same cadence per Holding Agent as follows:
- - The Holding Agent’s share of the Issuing Agent’s token supply at the time the Issuing Agent pays its Ecosystem Upkeep Fees, multiplied by
+ - The Holding Agent's share of the Issuing Agent's token supply at the time the Issuing Agent pays its Ecosystem Upkeep Fees, multiplied by
- The total monthly Ecosystem Upkeep Fees paid by the Issuing Agent. For a Prime Agent deploying the Distribution Requirement Primitive, the value of its total monthly Ecosystem Upkeep Fee is calculated pursuant to A.2.4 - Calculation of Distributed Tokens. For a Prime Agent deploying the Market Cap Fee Primitive, the value of its total monthly Ecosystem Upkeep Fee is calculated pursuant to A.2.4 - Valuation.
- This resulting rebate amount is applied against the Holding Agent’s Ecosystem Upkeep Fees due in the calendar month immediately following the Issuing Agent’s payment.
+ This resulting rebate amount is applied against the Holding Agent's Ecosystem Upkeep Fees due in the calendar month immediately following the Issuing Agent's payment.
|
@@ -12697,7 +12697,7 @@ Sections & Primary Docs
Treasury Management - Treasury Management - Allocation Steps - Step 0: Net Revenue - Income - Stability Fees From Base Rate |
Core |
- Stability Fees are the fees that Sky Core charges Prime Agents to borrow from Sky. See A.3.2 - Core Stability Parameters - Parameters - Base Rate. Sky Core’s legacy ALM infrastructure is currently being transferred to Prime Agents; during this transition period and until this transfer is fully complete, income generated from the Sky Core Collateral Portfolio contributes to net revenue. See A.3.4 - Application To Sky Core. |
+ Stability Fees are the fees that Sky Core charges Prime Agents to borrow from Sky. See A.3.2 - Core Stability Parameters - Parameters - Base Rate. Sky Core's legacy ALM infrastructure is currently being transferred to Prime Agents; during this transition period and until this transfer is fully complete, income generated from the Sky Core Collateral Portfolio contributes to net revenue. See A.3.4 - Application To Sky Core. |
@@ -12706,7 +12706,7 @@ Sections & Primary Docs
|
Treasury Management - Treasury Management - Allocation Steps - Step 0: Net Revenue - Income - Internal Senior Risk Capital Income |
Core |
- Internal Senior Risk Capital income is the revenue attributed to Sky from the total payments made by Primes for Originated Senior Risk Capital (OSRC). ISRC itself comprises surplus capital allocated from designated buffers funded by the Sky Treasury Management Function. While Primes pay a single clearing price for their OSRC based on the monthly Origination Process, the total revenue received by Sky is subsequently allocated proportionally, with the portion corresponding to ISRC’s share of the Total Senior Risk Capital (TSRC) pool designated as ISRC Income. See A.2.5 - Treasury Management - Treasury Management - Sourcing Of Internal Senior Risk Capital From Surplus Buffers. |
+ Internal Senior Risk Capital income is the revenue attributed to Sky from the total payments made by Primes for Originated Senior Risk Capital (OSRC). ISRC itself comprises surplus capital allocated from designated buffers funded by the Sky Treasury Management Function. While Primes pay a single clearing price for their OSRC based on the monthly Origination Process, the total revenue received by Sky is subsequently allocated proportionally, with the portion corresponding to ISRC's share of the Total Senior Risk Capital (TSRC) pool designated as ISRC Income. See A.2.5 - Treasury Management - Treasury Management - Sourcing Of Internal Senior Risk Capital From Surplus Buffers. |
@@ -12715,7 +12715,7 @@ Sections & Primary Docs
|
Treasury Management - Treasury Management - Allocation Steps - Step 0: Net Revenue - Income - External Senior Risk Capital Fees |
Core |
- External Senior Risk Capital Fees are levied by Sky and calculated as 5% of the net interest earnings generated by the External Senior Risk Capital (ESRC) pool each Monthly Settlement Cycle. These earnings represent the portion of the total revenue from Primes ’ Originated Senior Risk Capital (OSRC) payments that is attributed proportionally to ESRC, based on its contribution to the Total Senior Risk Capital (TSRC) pool for that cycle. This 5% fee is deducted before the remaining ESRC earnings contribute to the srUSDS conversion rate. See A.3.3 - ESRC Earnings Fee. |
+ External Senior Risk Capital Fees are levied by Sky and calculated as 5% of the net interest earnings generated by the External Senior Risk Capital (ESRC) pool each Monthly Settlement Cycle. These earnings represent the portion of the total revenue from Primes' Originated Senior Risk Capital (OSRC) payments that is attributed proportionally to ESRC, based on its contribution to the Total Senior Risk Capital (TSRC) pool for that cycle. This 5% fee is deducted before the remaining ESRC earnings contribute to the srUSDS conversion rate. See A.3.3 - ESRC Earnings Fee. |
@@ -13287,7 +13287,7 @@ Sections & Primary Docs
|
Sky Core Monthly Settlement Cycle - Monthly Settlement Cycle Overview - Implementation - Process Definition - Resolution Of Differences By Core GovOps Atlas Axis - Disputes By Prime Agents |
Core |
- A Prime Agent may dispute the calculation of the net amount due to or from it (a “Dispute Notice”). The Dispute Notice must be posted as a reply to the Initial Calculation within five (5) calendar days of the posting of the Initial Calculation. The Dispute Notice must specify the errors in the Initial Calculation and the Prime’s own calculation of the net amount due to or from it. The required contents of the Dispute Notice will be further specified in a future iteration of the Atlas. Core GovOps Atlas Axis may at its discretion resolve the differences between the calculations using the process specified in A.2.6 - Resolution Of Differences By Core GovOps Atlas Axis. Alternatively, Atlas Axis may elect to determine the correct amount and true up any differences in the next Monthly Settlement Cycle as specified in A.2.6 - True Up In Subsequent Monthly Settlement Cycle. In either case Atlas Axis must post its decision as a reply to the Dispute Notice. |
+ A Prime Agent may dispute the calculation of the net amount due to or from it (a “Dispute Notice”). The Dispute Notice must be posted as a reply to the Initial Calculation within five (5) calendar days of the posting of the Initial Calculation. The Dispute Notice must specify the errors in the Initial Calculation and the Prime's own calculation of the net amount due to or from it. The required contents of the Dispute Notice will be further specified in a future iteration of the Atlas. Core GovOps Atlas Axis may at its discretion resolve the differences between the calculations using the process specified in A.2.6 - Resolution Of Differences By Core GovOps Atlas Axis. Alternatively, Atlas Axis may elect to determine the correct amount and true up any differences in the next Monthly Settlement Cycle as specified in A.2.6 - True Up In Subsequent Monthly Settlement Cycle. In either case Atlas Axis must post its decision as a reply to the Dispute Notice. |
@@ -14601,7 +14601,7 @@ Sections & Primary Docs
|
Subsequent Allocation Mechanism |
Core |
- After the initial cash grant (see A.2.10 - Initial Allocation Mechanism) but before the SPK or GROVE token is decentralized enough to allow meaningful governance by token holders, the respective founding teams may propose subsequent cash grants to their Prime Foundations. Sky must consent to each subsequent cash grant via approving the Sky Atlas modification. |
+ After the initial cash grant (see A.2.10 - Initial Allocation Mechanism) but before the SPK or GROVE token is decentralized enough to allow meaningful governance by token holders, the respective founding teams may propose subsequent cash grants to their Prime Foundations. Sky must consent to each subsequent cash grant via approving the Sky Atlas modification. |
@@ -14617,7 +14617,7 @@ Sections & Primary Docs
|
Genesis Capital Backstop |
Core |
- Each genesis capital allocation is subject to the Genesis Capital Backstop (see A.3.9 - Genesis Capital Backstop). |
+ Each genesis capital allocation is subject to the Genesis Capital Backstop (see A.3.9 - Genesis Capital Backstop). |
@@ -14904,7 +14904,7 @@ Sections & Primary Docs
|
Spark Senior Risk Capital |
Core |
- In the short term before the implementation of the Senior Risk Capital system, Sky will provide Spark with 15 million USDS of Senior Risk Capital. See A.3.3 - Short Term Transitionary Measures. This Senior Risk Capital will not be transferred by Sky to Spark's SubProxy Account; instead, it will be credited towards Spark’s Total Risk Capital. See A.3.3 - Total Risk Capital. |
+ In the short term before the implementation of the Senior Risk Capital system, Sky will provide Spark with 15 million USDS of Senior Risk Capital. See A.3.3 - Short Term Transitionary Measures. This Senior Risk Capital will not be transferred by Sky to Spark's SubProxy Account; instead, it will be credited towards Spark's Total Risk Capital. See A.3.3 - Total Risk Capital. |
@@ -14976,7 +14976,7 @@ Sections & Primary Docs
|
Transfer From Liquidity Bootstrapping Budget To Keel |
Core |
- Sky has transferred 500,000 USDS from the Sky Ecosystem Liquidity Bootstrapping Budget to Launch Agent 2 to provide liquidity to decentralized finance protocols on Solana (see A.5.9 - Launch Project - Sky Ecosystem Liquidity Bootstrapping). This amount shall be treated as an advance against Launch Agent 2’s Genesis Capital Allocation and deducted from Launch Agent 2’s allocated capital funds at the time of the Capital Transfer. The transfer must be made to a multisig controlled by Launch Agent 2’s Operational Executor Agent and the multisig must have the ability to withdraw the liquidity provided to decentralized finance protocols at any time. The address of the multisig on Solana is 6cTVPDJ8WR1XGxdgnjzhpYKRqcv78T4Nqt95DY8dvMmn. |
+ Sky has transferred 500,000 USDS from the Sky Ecosystem Liquidity Bootstrapping Budget to Launch Agent 2 to provide liquidity to decentralized finance protocols on Solana (see A.5.9 - Launch Project - Sky Ecosystem Liquidity Bootstrapping). This amount shall be treated as an advance against Launch Agent 2's Genesis Capital Allocation and deducted from Launch Agent 2's allocated capital funds at the time of the Capital Transfer. The transfer must be made to a multisig controlled by Launch Agent 2's Operational Executor Agent and the multisig must have the ability to withdraw the liquidity provided to decentralized finance protocols at any time. The address of the multisig on Solana is 6cTVPDJ8WR1XGxdgnjzhpYKRqcv78T4Nqt95DY8dvMmn. |
@@ -14992,7 +14992,7 @@ Sections & Primary Docs
|
Pre-Pioneer Incentive Pool |
Core |
- Keel is eligible for a Pre-Pioneer Incentive Pool. See A.2.4 - Pre-Pioneer Incentive Pool. The Pre-Pioneer Incentive Pool is calculated on a monthly basis as (1) the Sky Savings Rate multiplied by all USDS balances on Solana, less (2) all Integration Boost payments made to partners on Solana. Payments are made on a monthly basis from the Integration Boost wallets specified in A.2.4 - Near Term Process to a Pre-Pioneer Incentive Pool wallet controlled by Keel’s Operational Executor Agent. The address of the Pre-Pioneer Incentive Pool wallet on Solana is 8JmDPG5BFQ6gpUPJV9xBixYJLqTKCSNotkXksTmNsQfj. Funds from the Pre-Pioneer Incentive Pool wallet may be used to incentivize partners on Solana to promote USDS adoption as directed by Keel. Funds from the Pre-Pioneer Incentive Pool may not be transferred to Keel’s SubProxy Account, Keel Foundation, or Matariki Labs. |
+ Keel is eligible for a Pre-Pioneer Incentive Pool. See A.2.4 - Pre-Pioneer Incentive Pool. The Pre-Pioneer Incentive Pool is calculated on a monthly basis as (1) the Sky Savings Rate multiplied by all USDS balances on Solana, less (2) all Integration Boost payments made to partners on Solana. Payments are made on a monthly basis from the Integration Boost wallets specified in A.2.4 - Near Term Process to a Pre-Pioneer Incentive Pool wallet controlled by Keel's Operational Executor Agent. The address of the Pre-Pioneer Incentive Pool wallet on Solana is 8JmDPG5BFQ6gpUPJV9xBixYJLqTKCSNotkXksTmNsQfj. Funds from the Pre-Pioneer Incentive Pool wallet may be used to incentivize partners on Solana to promote USDS adoption as directed by Keel. Funds from the Pre-Pioneer Incentive Pool may not be transferred to Keel's SubProxy Account, Keel Foundation, or Matariki Labs. |
@@ -16463,7 +16463,7 @@ Sections & Primary Docs
|
Core Stability Parameters - Parameters - Agent Credit Line Borrow Rate - Use Of Funds |
Core |
- Funds borrowed by Agents from Sky at the Agent Credit Line Borrow Rate must be deposited into the Agent’s Allocation Vault and used to invest in Allocation System Instances. See A.2.4 - Allocation System Primitive. These funds may not be transferred to the Agent’s SubProxy account or otherwise outside of the Agent’s designated accounts for its Allocation System Primitive. |
+ Funds borrowed by Agents from Sky at the Agent Credit Line Borrow Rate must be deposited into the Agent's Allocation Vault and used to invest in Allocation System Instances. See A.2.4 - Allocation System Primitive. These funds may not be transferred to the Agent's SubProxy account or otherwise outside of the Agent's designated accounts for its Allocation System Primitive. |
@@ -16471,7 +16471,7 @@ Sections & Primary Docs
|
Core Stability Parameters - Parameters - Agent Credit Line Borrow Rate - Accrued Interest |
Core |
- Interest accrues on borrowed funds and is reflected in the Allocation Vault balance. Prime Agents must regularly transfer interest payments to the Allocation Vault to pay down accrued interest, ensuring the Allocation Vault balance returns to the principal amount only. Any accrued but unpaid interest reduces the Prime Agent’s available Total Risk Capital. See A.3.3 - Total Risk Capital Definition. |
+ Interest accrues on borrowed funds and is reflected in the Allocation Vault balance. Prime Agents must regularly transfer interest payments to the Allocation Vault to pay down accrued interest, ensuring the Allocation Vault balance returns to the principal amount only. Any accrued but unpaid interest reduces the Prime Agent's available Total Risk Capital. See A.3.3 - Total Risk Capital Definition. |
@@ -17289,7 +17289,7 @@ Sections & Primary Docs
|
Aave And SparkLend |
Core |
- Because Aave and SparkLend liquidate a maximum of 50% of a user’s position, the Slippage parameter for Aave and SparkLend should be the estimated slippage for liquidating half of the position in one block. See A.3.3 - Slippage. |
+ Because Aave and SparkLend liquidate a maximum of 50% of a user's position, the Slippage parameter for Aave and SparkLend should be the estimated slippage for liquidating half of the position in one block. See A.3.3 - Slippage. |
@@ -18085,7 +18085,7 @@ Sections & Primary Docs
|
Calculate Risk Weighted Assets |
Core |
- Credit RWA, Market RWA, Counterparty Credit Risk RWA, and Credit Valuation Adjustment RWA are calculated by multiplying the Exposure At Default (see A.3.3 - Calculate Exposure At Default Including Credit Risk Mitigation) by the applicable Risk Weights (see A.3.3 - Determine Risk Weights). |
+ Credit RWA, Market RWA, Counterparty Credit Risk RWA, and Credit Valuation Adjustment RWA are calculated by multiplying the Exposure At Default (see A.3.3 - Calculate Exposure At Default Including Credit Risk Mitigation) by the applicable Risk Weights (see A.3.3 - Determine Risk Weights). |
@@ -18101,7 +18101,7 @@ Sections & Primary Docs
|
Apply Leverage Adjustment |
Core |
- The fifth step is to adjust the Aggregate RWA specified in A.3.3 - Aggregate Risk Weighted Assets for leverage (see CRE99.128-133). |
+ The fifth step is to adjust the Aggregate RWA specified in A.3.3 - Aggregate Risk Weighted Assets for leverage (see CRE99.128-133). |
@@ -18109,7 +18109,7 @@ Sections & Primary Docs
|
Determine Required Risk Capital |
Core |
- The final step is to multiply the adjusted Aggregate RWA specified in A.3.3 - Apply Leverage Adjustment by an 8% capital ratio to arrive at Instance Financial RRC. |
+ The final step is to multiply the adjusted Aggregate RWA specified in A.3.3 - Apply Leverage Adjustment by an 8% capital ratio to arrive at Instance Financial RRC. |
@@ -20602,7 +20602,7 @@ Sections & Primary Docs
|
Surplus Buffer And Smart Burn Engine - Surplus Buffer |
Section |
- The Surplus Buffer is the difference between Sky’s assets and liabilities. Protocol revenue increases the Surplus Buffer and expenses decrease the Surplus Buffer.
+ | The Surplus Buffer is the difference between Sky's assets and liabilities. Protocol revenue increases the Surplus Buffer and expenses decrease the Surplus Buffer.
|
@@ -20619,7 +20619,7 @@ Sections & Primary Docs
Surplus Buffer And Smart Burn Engine - Surplus Buffer - Current Value |
Core |
- The current value of the Surplus Buffer can be calculated using the Vat contract, Sky’s central accounting contract, located on the Ethereum Mainnet at 0x35D1b3F3D7966A1DFe207aa4514C12a259A0492B. The current value of the Surplus Buffer is the difference between:
+ | The current value of the Surplus Buffer can be calculated using the Vat contract, Sky's central accounting contract, located on the Ethereum Mainnet at 0x35D1b3F3D7966A1DFe207aa4514C12a259A0492B. The current value of the Surplus Buffer is the difference between:
- The assets of the Vow contract obtained by calling the
dai function on the Vat contract with the address of the Vow contract, and
- The liabilities of the Vow contract obtained by calling the
sin function on the Vat contract with the address of the Vow contract.
@@ -20953,7 +20953,7 @@ Sections & Primary Docs
|
Measures For Endgame Transition - Native Vault Engine - Liquidation Ratio |
Core |
- The Liquidation Ratio parameter limits the maximum amount of Dai debt that a vault user can draw from their vault given the value of their collateral locked in that vault. In practice, it expresses the minimum collateral in percentage terms that can support a given Dai debt. If the ratio of a Vault user’s collateral to their debt drops below this value, their vault can be liquidated. Each vault type has its own Liquidation Ratio. The Liquidation Ratio for each vault type is expressed as a percentage value of the collateral that must be present in the vault to support its debt. Changes to the Liquidation Ratio are subject to the Operational Weekly Cycle, requiring a Governance Poll followed by an Executive Vote. |
+ The Liquidation Ratio parameter limits the maximum amount of Dai debt that a vault user can draw from their vault given the value of their collateral locked in that vault. In practice, it expresses the minimum collateral in percentage terms that can support a given Dai debt. If the ratio of a Vault user's collateral to their debt drops below this value, their vault can be liquidated. Each vault type has its own Liquidation Ratio. The Liquidation Ratio for each vault type is expressed as a percentage value of the collateral that must be present in the vault to support its debt. Changes to the Liquidation Ratio are subject to the Operational Weekly Cycle, requiring a Governance Poll followed by an Executive Vote. |
@@ -21655,7 +21655,7 @@ Sections & Primary Docs
|
Genesis Capital Backstop - Implementation |
Core |
- In the near term, transfers are made through Executive Votes and may be made through Emergency Spells (see A.1.9 - A4 - Sky Core Governance Security - Emergency Spells) as part of the Emergency Response System (see A.1.8 - A1 - Emergency Response System - Emergency Response) A solution must be developed to allow these transfers to be accomplished on an automated basis without waiting for the GSM Pause Delay (see A.1.9 - A2 - Sky Core Governance Security - Governance Security Delay Requirements). . |
+ In the near term, transfers are made through Executive Votes and may be made through Emergency Spells (see A.1.9 - A4 - Sky Core Governance Security - Emergency Spells) as part of the Emergency Response System (see A.1.8 - A1 - Emergency Response System - Emergency Response) A solution must be developed to allow these transfers to be accomplished on an automated basis without waiting for the GSM Pause Delay (see A.1.9 - A2 - Sky Core Governance Security - Governance Security Delay Requirements). . |
@@ -21671,7 +21671,7 @@ Sections & Primary Docs
|
Genesis Capital Backstop - Genesis Agent Capital Shortfalls |
Core |
- Transfers of capital from Genesis Agents may cause capital shortfalls for Genesis Agents under the Risk Framework (see A.3.3). Sky will work in good faith with such Agents to waive penalties for a reasonable period of time to allow the Agents to rebuild their capital. |
+ Transfers of capital from Genesis Agents may cause capital shortfalls for Genesis Agents under the Risk Framework (see A.3.3). Sky will work in good faith with such Agents to waive penalties for a reasonable period of time to allow the Agents to rebuild their capital. |
@@ -22178,7 +22178,7 @@ Sections & Primary Docs
|
SKY Staking Mechanism - SKY Staking - SKY Staking Voting Rewards - Sources of Voting Rewards - Treasury Management Function-Derived Voting Rewards |
Core |
- USDS rewards are distributed via two distinct mechanisms based on the staker’s activity level: the High Activity Staking Reward (HASR) and the Standard Activity Staking Reward (SASR). SASR is the base reward when funding from the Treasury Management Function is available; HASR is an additional boost reserved for High-Activity wallets. See A.2.5 - Treasury Management - Treasury Management - Allocation Steps - Step 2: High Activity Staking Rewards - Payout From High Activity Staking Rewards Buffer. |
+ USDS rewards are distributed via two distinct mechanisms based on the staker's activity level: the High Activity Staking Reward (HASR) and the Standard Activity Staking Reward (SASR). SASR is the base reward when funding from the Treasury Management Function is available; HASR is an additional boost reserved for High-Activity wallets. See A.2.5 - Treasury Management - Treasury Management - Allocation Steps - Step 2: High Activity Staking Rewards - Payout From High Activity Staking Rewards Buffer. |
@@ -24117,7 +24117,7 @@ Annotations
|
Chief Contract - Element Annotation |
Annotation |
- The element “Chief Contract” refers to the contract that implements the Sky Protocol’s on-chain voting mechanism. Under this mechanism, the hat, or current executive authority, is elected via token-weighted votes. |
+ The element “Chief Contract” refers to the contract that implements the Sky Protocol's on-chain voting mechanism. Under this mechanism, the hat, or current executive authority, is elected via token-weighted votes. |
@@ -24337,7 +24337,7 @@ Annotations
|
Included In An Executive Vote - Element Annotation |
Annotation |
- The element “Included In An Executive Vote” refers to the Support Facilitators’ act of adding a Resilience Research and Preparedness grant payment to an Executive Vote. The Support Facilitators are also responsible for providing provenance for such requests by confirming payment requests on the Executive Sheet. See Executive Sheet - Element Annotation. |
+ The element “Included In An Executive Vote” refers to the Support Facilitators' act of adding a Resilience Research and Preparedness grant payment to an Executive Vote. The Support Facilitators are also responsible for providing provenance for such requests by confirming payment requests on the Executive Sheet. See Executive Sheet - Element Annotation. |
@@ -24895,7 +24895,7 @@ Tenets
|
Ranked Delegate Loss Of Rank After Triggering Proposal Is Inconsequential |
Action Tenet |
- A Weekly Cycle Proposal is considered correctly triggered when the triggering Aligned Delegate is a Ranked Delegate with at least one (1) month’s worth of budget in their AD Buffer at the time of triggering the Proposal. It is inconsequential if, after triggering the Proposal, the Ranked Delegate loses Ranked Delegate rank. |
+ A Weekly Cycle Proposal is considered correctly triggered when the triggering Aligned Delegate is a Ranked Delegate with at least one (1) month's worth of budget in their AD Buffer at the time of triggering the Proposal. It is inconsequential if, after triggering the Proposal, the Ranked Delegate loses Ranked Delegate rank. |
@@ -24903,7 +24903,7 @@ Tenets
|
Ranked Delegates Must Stake Their AD Buffer To Trigger Weekly Cycle Proposals |
Action Tenet |
- To deter spurious or misaligned proposals, Ranked Delegates must “stake” their AD Buffer to trigger a Proposal. A Ranked Delegate can trigger a Weekly Cycle Proposal only if their AD Buffer contains at least one (1) month’s worth of budget at the time of triggering the Proposal. This “staking” requirement of one month’s worth of budget remains in effect until the triggered Proposal is fully resolved - that is, until either (1) the Proposal is rejected by the Core Facilitator for misalignment, or (2) a Sky Governance vote on the Proposal concludes in an approval or rejection. If the Proposal is voted down or rejected for misalignment, the RD will lose their entire AD Buffer. |
+ To deter spurious or misaligned proposals, Ranked Delegates must “stake” their AD Buffer to trigger a Proposal. A Ranked Delegate can trigger a Weekly Cycle Proposal only if their AD Buffer contains at least one (1) month's worth of budget at the time of triggering the Proposal. This “staking” requirement of one month's worth of budget remains in effect until the triggered Proposal is fully resolved - that is, until either (1) the Proposal is rejected by the Core Facilitator for misalignment, or (2) a Sky Governance vote on the Proposal concludes in an approval or rejection. If the Proposal is voted down or rejected for misalignment, the RD will lose their entire AD Buffer. |
@@ -25024,9 +25024,9 @@ Scenarios
|
Delay In Payment To Ranked Delegate Triggering Proposal |
Scenario |
- Entity is a Ranked Delegate with one (1) month’s worth of budget in their AD Buffer. Entity triggers a Weekly Cycle Proposal. Immediately thereafter, Entity loses their Ranked Delegate rank. Three days later, before the Proposal has been voted on, the Core Facilitator distributes compensation to other Aligned Delegates but do not distribute compensation to Entity. |
+ Entity is a Ranked Delegate with one (1) month's worth of budget in their AD Buffer. Entity triggers a Weekly Cycle Proposal. Immediately thereafter, Entity loses their Ranked Delegate rank. Three days later, before the Proposal has been voted on, the Core Facilitator distributes compensation to other Aligned Delegates but do not distribute compensation to Entity. |
Aligned |
- Paying out the AD Buffer would have led to Entity’s AD Buffer dropping below the required threshold of one (1) month’s worth of budget while the Proposal was still unresolved. In this Scenario, the triggering AD cannot receive payout from the AD Buffer until the triggered Proposal is voted on and approved by Sky Governance. Assuming that the Proposal is approved, the Core Facilitator is authorized to disburse the entire contents of the AD Buffer to the triggering AD in the next AD compensation cycle. However, if the Proposal is rejected by the Core Facilitator for misalignment or voted down by Sky Governance, the triggering AD would lose their entire AD Buffer. |
+ Paying out the AD Buffer would have led to Entity's AD Buffer dropping below the required threshold of one (1) month's worth of budget while the Proposal was still unresolved. In this Scenario, the triggering AD cannot receive payout from the AD Buffer until the triggered Proposal is voted on and approved by Sky Governance. Assuming that the Proposal is approved, the Core Facilitator is authorized to disburse the entire contents of the AD Buffer to the triggering AD in the next AD compensation cycle. However, if the Proposal is rejected by the Core Facilitator for misalignment or voted down by Sky Governance, the triggering AD would lose their entire AD Buffer. |
@@ -25044,9 +25044,9 @@ Scenarios
|
Ranked Delegate Triggers Proposal And Loses Ranked Delegate Rank Immediately Thereafter |
Scenario |
- Entity is a Ranked Delegate with at least one (1) month’s worth of budget in their AD Buffer. Entity triggers a Weekly Cycle Proposal. Immediately thereafter, Entity loses their Ranked Delegate rank. The Core Facilitator continues to prepare a Governance Poll for the Proposal. |
+ Entity is a Ranked Delegate with at least one (1) month's worth of budget in their AD Buffer. Entity triggers a Weekly Cycle Proposal. Immediately thereafter, Entity loses their Ranked Delegate rank. The Core Facilitator continues to prepare a Governance Poll for the Proposal. |
Aligned as to Entity. Aligned as to the Core Facilitator. |
- The fact that Entity lost their Ranked Delegate rank after triggering the Proposal is inconsequential. Entity satisfied the requirement of being a Ranked Delegate with at least one (1) month’s worth of budget in their AD Buffer at the time of triggering the Proposal, and thus the Proposal was properly triggered. The Core Facilitator acted correctly to prepare a Governance Poll for the Proposal in accord with the process definition for the Atlas Edit Weekly Cycle. |
+ The fact that Entity lost their Ranked Delegate rank after triggering the Proposal is inconsequential. Entity satisfied the requirement of being a Ranked Delegate with at least one (1) month's worth of budget in their AD Buffer at the time of triggering the Proposal, and thus the Proposal was properly triggered. The Core Facilitator acted correctly to prepare a Governance Poll for the Proposal in accord with the process definition for the Atlas Edit Weekly Cycle. |
@@ -27105,7 +27105,7 @@ Agent Scope Database
|
Spark |
Core |
- Nested Contributors are always authorized to submit Artifact Edit Proposals and do not have to fulfill the token-holding requirements defined in Root Edit Proposal Submission. However, all other procedural requirements within the Root Edit process continue to apply. To see the Agent’s Nested Contributors, see Phoenix Labs. |
+ Nested Contributors are always authorized to submit Artifact Edit Proposals and do not have to fulfill the token-holding requirements defined in Root Edit Proposal Submission. However, all other procedural requirements within the Root Edit process continue to apply. To see the Agent's Nested Contributors, see Phoenix Labs. |
@@ -60059,7 +60059,7 @@ Agent Scope Database
|
Launch Agent 4 |
Core |
- aunch Agent 4 is an incubation-focused Prime within the Sky Ecosystem. It provides capital, infrastructure, and technical support to early-stage teams building on Sky Primitives. Launch Agent 4’s purpose is to accelerate aligned builders through structured incubation and funding. The subdocuments herein define the operating model, structure, mandate, and operational standards of Launch Agent 4. |
+ Launch Agent 4 is an incubation-focused Prime within the Sky Ecosystem. It provides capital, infrastructure, and technical support to early-stage teams building on Sky Primitives. Launch Agent 4's purpose is to accelerate aligned builders through structured incubation and funding. The subdocuments herein define the operating model, structure, mandate, and operational standards of Launch Agent 4. |
|
|