diff --git a/Sky Atlas/Sky Atlas.html b/Sky Atlas/Sky Atlas.html index 265f0c8..b982cfe 100644 --- a/Sky Atlas/Sky Atlas.html +++ b/Sky Atlas/Sky Atlas.html @@ -2690,6 +2690,140 @@

Sections & Primary Docs

Core Following the interim deployment, the Prime will work with the Core Council Risk Advisor to complete a full risk assessment. Once the means to calculate an official Capital Requirement Ratio for the deployment has been determined, the Prime can propose a subsequent spell to lift the testing constraints and reduce RRC to the Atlas-calculated value. + + + A.1.9 - Execution Of Agent Spells + + Execution Of Agent Spells + Core + The execution of Agent Spells is described in the subdocuments herein. Two methods are available: direct execution in a Sky Core Spell and execution through StarGuard. Execution through StarGuard is the preferred method and any exceptions require valid reasoning, except as specified in A.1.9 - Short-term Transitionary Measures. + + + + A.1.9 - Execution Through StarGuard + + Execution Through StarGuard + Core + When the execution through the StarGuard method is used, the Agent Spells are whitelisted in Sky Core Spells and later executed using the StarGuard module. The Sky Core Spell includes a whitelist of approved Agent Spells, which allows them to be executed via separate transactions. This enhances resilience and scalability, ensuring robust handling of payloads from multiple active Agents while minimizing risks to Sky Core. + + + + A.1.9 - StarGuard + + StarGuard + Core + For each Agent, a StarGuard contract is deployed to manage whitelisting and execution of Agent Spells. This contract acts as a standardized "proxy wrapper". + + + + A.1.9 - StarGuard Functionality + + StarGuard Functionality + Core + When initiated in a Sky Core Spell, the StarGuard whitelists relevant Agent Spells, enabling their secure execution. This whitelisting allows Agent Spells to run independently, supporting arbitrary complexity and custom features like office hours or expiration times. StarGuard also supports dropping a whitelisted Agent Spell, providing a mechanism to revoke access if needed for security or error correction. This is done via the drop() function. + + + + A.1.9 - StarGuard Ownership + + StarGuard Ownership + Core + The StarGuard contract is owned by the Pause Proxy, ensuring centralized control and preventing unauthorized changes. + + + + A.1.9 - Responsibilities For Agents + + Responsibilities For Agents + Core + The Agents are required to include logic for the public view method isExecutable() in their Spell. This function is used to signal if the Spell is ready to be executed in a particular block or not. StarGuard cannot execute an Agent Spell if isExecutable() returns False. The value that must be returned for execution to be possible is True. + + + + A.1.9 - StarGuard Whitelisting Authority + + StarGuard Whitelisting Authority + Core + Only the owner, the Pause Proxy, is able to whitelist new Agent Spells via a Sky Core Spell. + + + + A.1.9 - StarGuard Max Delay + + StarGuard Max Delay + Core + A configurable maxDelay sets the maximum duration between the whitelisting of the Agent Spell in the Sky Core Spell and the execution of the Agent Spell. This feature ensures Spells do not linger indefinitely, enforcing timely processing and reducing risks from delayed or forgotten actions. The recommended value for maxDelay is seven (7) days. + + + + A.1.9 - Requirements For Whitelisting + + Requirements For Whitelisting + Core + The requirements for whitelisting are: + + This information must be provided by the Agent Spell reviewers to the Governance Point. + + + + + A.1.9 - Permissionless Execution + + Permissionless Execution + Core + The triggering of an Agent Spell is permissionless; anyone can initiate execution. A keeper job, StarGuardJob, allows keepers to monitor and execute eligible Spells at the earliest possible block. + + + + A.1.9 - Function Call For Execution + + Function Call For Execution + Core + Execution is initiated on the StarGuard contract via its exec() function, which performs necessary validation checks before calling the SubProxy's exec(spellDataCopy.addr, abi.encodePacked(StarSpellLike.execute.selector)) to perform the Spell's actions. + + + + A.1.9 - Validation Checks By StarGuard + + Validation Checks By StarGuard + Core + The following checks are enabled by the contract: + + + + + + A.1.9 - Direct Execution Through Sky Core Spell + + Direct Execution Through Sky Core Spell + Core + When the execution through the Sky Core Spell method is used, the Agent Spells are executed directly in the Sky Core Spells. + + + + A.1.9 - Sky Core Spell Executes Agent Spell + + Sky Core Spell Executes Agent Spell + Core + Execution of an Agent Spell is initiated by the Sky Core Spell, which directly calls exec() on the Agent's SubProxy contract to perform the Spell's actions in the same transaction. The SubProxy limits rights to the specific Agent, preventing access to Sky Core contracts. The current SubProxy contract is designed to execute the Agent Spell in the same transaction as the Sky Core Spell. + + + + A.1.9 - Short-term Transitionary Measures + + Short-term Transitionary Measures + Core + During the transitioning phase, before StarGuard is fully implemented and tested, only the Spark Agent will use the process specified in A.1.9 - Execution Through StarGuard. Other Agent Spells will use the process specified in A.1.9 - Direct Execution Through Sky Core Spell. + A.1.9 - Sky Core Governance Security - Executive Process Definition - Executive Process Breakdown @@ -11877,11 +12011,11 @@

Sections & Primary Docs

- A.2.4 - Direct Sky Exposures + A.2.4 - Sky Direct Exposures - Direct Sky Exposures + Sky Direct Exposures Core - Direct Sky Exposures are exposures that are held directly by Sky but implemented through the Allocation System of a Prime Agent. The documents herein define the rules for Direct Sky Exposures. + Sky Direct Exposures are exposures that are held directly by Sky but implemented through the Allocation System of a Prime Agent. The documents herein define the rules for Sky Direct Exposures. @@ -11889,23 +12023,20 @@

Sections & Primary Docs

Designation Process Core - Direct Sky Exposures are designated directly by Sky Governance via the Atlas Edit Proposal process. Direct Sky Exposures are recorded in A.2.4 - Current Direct Sky Exposures and must specify the asset that is being designated as a Direct Sky Exposure and the Prime Agent responsible for implementing the Exposure. + Sky Direct Exposures are designated by the Core Facilitator in consultation with the Core Council Risk Advisor via posts to the Sky Forum under the “Sky Core” category. Sky Direct Exposures are recorded in A.2.4 - List Of Current Sky Direct Exposures and must specify the asset that is being designated as a Sky Direct Exposure and the Prime Agent responsible for implementing the exposure. - A.2.4 - Current Direct Sky Exposures + A.2.4 - Current Sky Direct Exposures - Current Direct Sky Exposures - Core - The current Direct Sky Exposures are specified in the documents herein. - - - - A.2.4 - JAAA Direct Exposure Through Grove - - JAAA Direct Exposure Through Grove - Core - Investments in JAAA on Ethereum Mainnet by Grove are designated as Direct Sky Exposures. + Current Sky Direct Exposures + Active Data Controller +

The list of current Sky Direct Exposures is defined as Active Data in A.2.4 - List Of Current Sky Direct Exposures.

The Active Data is updated as follows:

+ + @@ -11918,7 +12049,7 @@

Sections & Primary Docs

  • Rate limits; and
  • Aggregate exposure limits.
    • - The Core Facilitator must post the initial values for these parameters and any updates to them to the Sky Forum under the "Sky Core" category. The values for the parameters for Sky Direct Exposures are set by the Core Facilitator and supersede any values for these parameters specified in the Risk Framework. + The Core Facilitator must post the initial values for these parameters and any updates to them to the Sky Forum under the “Sky Core” category. The values for the parameters for Sky Direct Exposures are set by the Core Facilitator and supersede any values for these parameters specified in the Risk Framework. @@ -11927,7 +12058,7 @@

    Sections & Primary Docs

    Treatment Of Exposures In Excess Of Aggregate Exposure Limit Core - Any investments in assets that would otherwise qualify as Direct Sky Exposures by a Prime Agent in excess of the aggregate exposure limit are not Direct Sky Exposures and are subject to the customary requirements pursuant to A.2.6 and A.3.3. + Any investments in assets that would otherwise qualify as Sky Direct Exposures by a Prime Agent in excess of the aggregate exposure limit are not Sky Direct Exposures and are subject to the customary requirements pursuant to A.2.6 and A.3.3. @@ -13151,12 +13282,175 @@

    Sections & Primary Docs

    - A.2.5 - - Treasury Management - Treasury Management - Short Term Transitionary Measures + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures Treasury Management - Treasury Management - Short Term Transitionary Measures Core - As a short-term transitionary measure, the net revenue of the Sky Protocol is currently allocated manually through Executive Votes rather than through the allocation steps defined above. This manual process will be removed in a future iteration of the Atlas. + As a short-term transitionary measure, the net revenue of the Sky Protocol is currently allocated through the allocation steps defined above with the modifications specified in the documents herein. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital + Core + In the short term, 21% of Step 1 Capital is allocated as specified in the documents herein. The remaining 79% of Step 1 Capital becomes Step 4 Capital and is allocated as specified in A.2.5 - Allocation Of Step 4 Capital. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer + Core + 20% of Step 1 Capital is allocated to the Core Council Buffer, as specified in the documents herein. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer + Core + The Core Council Buffer is a multisig controlled by the Core Facilitator and Core GovOps to transfer funds on behalf of the Core Council. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Address + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Address + Core + The address of the Core Council Buffer Multisig on the Ethereum Mainnet is 0x210CFcF53d1f9648C1c4dcaEE677f0Cb06914364. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Required Number Of Signers + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Required Number Of Signers + Core + The Core Council Buffer Multisig has a 3/4 signing requirement. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Signers + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Signers + Core + The signers of the Core Council Buffer Multisig are two (2) addresses controlled by the Core Facilitator and two (2) addresses controlled by Core GovOps. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Usage Standards + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Usage Standards + Core + The Core Facilitator and Core GovOps must use the Core Council Buffer Multisig to disburse funds on behalf of the Core Council. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Modification + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Core Council Buffer - Core Council Buffer - Core Council Buffer Multisig Modification + Core + The Core Facilitator and Core GovOps can change the signers of the Core Council Buffer Multisig so long as: + + + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer + Core + 1% of Step 1 Capital is allocated to the Aligned Delegates Buffer, as specified in the documents herein. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer + Core + The Aligned Delegates Buffer is a multisig controlled by the Core Facilitator and Core GovOps to transfer funds to Aligned Delegates. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Address + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Address + Core + The address of the Aligned Delegates Buffer Multisig on the Ethereum Mainnet is 0x37FC5d447c8c54326C62b697f674c93eaD2A93A3. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Required Number Of Signers + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Required Number Of Signers + Core + The Aligned Delegates Buffer Multisig has a 3/4 signing requirement. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Signers + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Signers + Core + The signers of the Aligned Delegates Buffer Multisig are two (2) addresses controlled by the Core Facilitator and two (2) addresses controlled by Core GovOps. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Usage Standards + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Usage Standards + Core + The Core Facilitator and Core GovOps must use the Aligned Delegates Buffer Multisig to disburse funds to Aligned Delegates. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Modification + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 1 Capital - Allocation To Aligned Delegates Buffer - Aligned Delegates Buffer - Aligned Delegates Buffer Multisig Modification + Core + The Core Facilitator and Core GovOps can change the signers of the Aligned Delegates Buffer Multisig so long as: + + + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 4 Capital + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 4 Capital + Core + In the short term, Step 4 Capital is allocated as specified in the documents herein. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 4 Capital - Allocation To SKY Buybacks + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 4 Capital - Allocation To SKY Buybacks + Core + 300,000 USDS per day of Step 4 Capital is allocated to SKY buybacks. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 4 Capital - Allocation To Surplus Buffer + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Allocation Of Step 4 Capital - Allocation To Surplus Buffer + Core + Any remaining Step 4 Capital is allocated to the Surplus Buffer. + + + + A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures - Implementation + + Treasury Management - Treasury Management - Short Term Transitionary Measures - Implementation + Core + The allocations specified in A.2.5 - Allocation Of Step 1 Capital are effective retroactive to September 1, 2025. The next available Executive Vote must include these allocations for the period from September 1, 2025 to September 30, 2025. The amounts to be transferred are 3,876,387 USDS to the Core Council Buffer and 193,820 USDS to the Aligned Delegates Buffer. @@ -13191,7 +13485,7 @@

    Sections & Primary Docs

    Sky Core Monthly Settlement Cycle - Monthly Settlement Cycle Overview - Implementation Core - The documents herein define the initial implementation of the Monthly Settlement Cycle. This initial implementation of the Monthly Settlement Cycle does not include the Senior Risk Capital System, which is still being developed, and funds continue to be allocated through Executive Votes rather than the allocation steps of the Treasury Management Function. See A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures. + The documents herein define the initial implementation of the Monthly Settlement Cycle. This initial implementation of the Monthly Settlement Cycle does not include the Senior Risk Capital System, which is still being developed, and funds continue to be allocated through the modified Treasury Management Function. See A.2.5 - Treasury Management - Treasury Management - Short Term Transitionary Measures. @@ -13607,7 +13901,7 @@

    Sections & Primary Docs

    Sky Core Monthly Settlement Cycle - Monthly Settlement Cycle Overview - Implementation - Implementation Stages - Stage 2 - Stage 2 Timing Core - Stage 2 is currently expected to be implemented in the February 2026 Monthly Settlement Cycle for the period from January 1, 2026 to January 31, 2026. + Stage 2 will be implemented in the December 2025 Monthly Settlement Cycle for the period from November 1, 2025 to November 30, 2025. If there is no December 2025 Monthly Settlement Cycle, then Stage 2 will be implemented in the January 2026 Monthly Settlement Cycle for the period from November 1, 2025 to December 31, 2025. @@ -14976,7 +15270,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 Keel 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 Keel's Genesis Capital Allocation and deducted from Keel's allocated capital funds at the time of the Capital Transfer.

    The transfer must be made to a multisig controlled by Keel'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.

    @@ -16235,19 +16529,19 @@

    Sections & Primary Docs

    - A.3.2 - Core Stability Parameters - Role Of Core Executor Agents - Setting Base Rate - Adjustment Process - Level Of Actively Stabilizing Collateral + A.3.2 - Core Stability Parameters - Role Of Core Executor Agents - Setting Base Rate - Adjustment Process - Level Of Actively Stabilizing Collateral In Lite PSM - Core Stability Parameters - Role Of Core Executor Agents - Setting Base Rate - Adjustment Process - Level Of Actively Stabilizing Collateral + Core Stability Parameters - Role Of Core Executor Agents - Setting Base Rate - Adjustment Process - Level Of Actively Stabilizing Collateral In Lite PSM Core - The Core Executor Agents should consider the level of Actively Stabilizing Collateral (see A.3.4 - Actively Stabilizing Collateral) using the following non-binding guidelines: + PSM ASC is defined as the level of Actively Stabilizing Collateral (see A.3.4 - Actively Stabilizing Collateral) in the Lite PSM (see A.3.4 - Lite Peg Stability Module) as a percentage of the Sky Collateral Portfolio (see A.3.4 - Minimum Actively Stabilizing Collateral). The Core Executor Agents should consider the level of PSM ASC using the following non-binding guidelines: @@ -17275,7 +17569,6 @@

    Sections & Primary Docs

    The Instance Financial CRR for Fluid is 3% of the amount of funds supplied to Fluid that are borrowed. - A.3.3 - Ethena-Related Assets @@ -20050,7 +20343,7 @@

    Sections & Primary Docs

    Application To Sky Core Core - While its legacy ALM infrastructure is being transferred to Prime Agents, Sky Core manages the portion of the Sky Collateral Portfolio not deployed by Prime Agents ("Sky Core Collateral Portfolio"). During this transitional period, Sky Core must maintain, with respect to the Sky Core Collateral Portfolio, the same percentage of Actively Stabilizing Collateral and Demand Absorption Buffer required of Prime Agents. The required percentages are specified in A.3.4 - Minimum Actively Stabilizing Collateral. This requirement remains in effect only until all legacy ALM infrastructure has been fully transitioned to Prime Agents. + While its legacy ALM infrastructure is being transferred to Prime Agents, Sky Core manages the portion of the Sky Collateral Portfolio not deployed by Prime Agents ("Sky Core Collateral Portfolio"). During this transitional period, Sky Core allocates the Sky Core Collateral Portfolio to Actively Stabilizing Collateral as specified in A.3.4 - Sky Core Asset Liability Management Rules. @@ -20122,7 +20415,7 @@

    Sections & Primary Docs

    Minimum Actively Stabilizing Collateral Core - Prime Agents must maintain at least 25% of their Collateral Portfolio in Actively Stabilizing Collateral. + Prime Agents must maintain at least 5% of their Collateral Portfolio in Actively Stabilizing Collateral. @@ -20201,7 +20494,31 @@

    Sections & Primary Docs

    Penalties For Failing To Satisfy Actively Stabilizing Collateral Requirement Core - If a Prime Agent does not maintain the Minimum Actively Stabilizing Collateral, it will continuously be penalized at a rate of 200% APY on the missing Actively Stabilizing Collateral. This penalty is calculated retroactively per second and settled monthly during the Settlement Cycle. + In the near term there will be no penalties for Prime Agents for failing to maintain the Minimum Actively Stabilizing Collateral. Instead, failures to maintain the Minimum Actively Stabilizing Collateral will be detected and reported as specified in A.3.4 - Reporting Of Failures To Satisfy Actively Stabilizing Collateral Requirement. + + + + A.3.4 - Reporting Of Failures To Satisfy Actively Stabilizing Collateral Requirement + + Reporting Of Failures To Satisfy Actively Stabilizing Collateral Requirement + Core + In the near term, the Core Council Risk Advisor must develop a tool to automatically detect and report failures by Prime Agents to maintain the Minimum Actively Stabilizing Collateral. Each violation by a Prime Agent must be reported within 24 hours to the following parties: + + In addition, the Core Council Risk Advisor must include a summary of all such violations in the Independent Calculation it prepares as part of each Monthly Settlement Cycle. See A.2.6 - Independent Calculation By Core Council Risk Advisor On Behalf Of Core Council. + + + + A.3.4 - Near Term Exemption For Keel + + Near Term Exemption For Keel + Core + In the near term, due to limitations in the infrastructure on Solana, Keel is exempt from the requirement to maintain the Minimum Actively Stabilizing Collateral. This exemption will be removed in a future iteration of the Asset Liability Management Framework. @@ -20273,7 +20590,7 @@

    Sections & Primary Docs

    Penalties For Failure To Satisfy Peg Defense Obligations Core - If an Agent fails to fulfill the Peg Defense Obligations, then a penalty of 20 bps on all missing buy volume is applied, calculated in finished blocks of 6 hours from when the Peg Defense Event begins, and settled retroactively as part of the Settlement Cycle. + Penalties for failing to fulfill the Peg Defense Obligations will be specified in a future iteration of the Asset Liability Management framework. @@ -20289,31 +20606,7 @@

    Sections & Primary Docs

    Sky Core Asset Liability Management Rules Core - Pursuant to A.3.4 - Application To Sky Core, Sky Core manages the Sky Core Collateral Portfolio through a simple set of Asset Liability Management rules. These rules allocate excess capital beyond what is needed in the PSMs into Low Risk Real World Assets, and draw on those Low Risk Real World Assets to replenish the PSMs when the balance in the PSMs fall too low. - - - - A.3.4 - Excess Assets In Peg Stability Modules - - Excess Assets In Peg Stability Modules - Core - If more than 30% of the Sky Core Collateral Portfolio is in PSMs, then any excess above the 30% mark must be allocated towards Low Risk Real World Assets. - - - - A.3.4 - Lack Of Assets In Peg Stability Modules - - Lack Of Assets In Peg Stability Modules - Core - If less than 20% of the Sky Core Collateral Portfolio is in PSMs, then Low Risk Real World Assets must be sold off to return the PSM exposure to 25%. - - - - A.3.4 - Optimizations - - Optimizations - Core - Core GovOps can use the Operational Weekly Governance Cycle to modify the Sky Core Asset Liability Management Rules in order to make them more efficient or more resilient. This modification can involve changing any of the logic defined in A.3.4 - Sky Core Asset Liability Management Rules. + Pursuant to A.3.4 - Application To Sky Core, Sky Core manages the Sky Core Collateral Portfolio by allocating capital to the Lite PSM (see A.3.4 - Lite Peg Stability Module). @@ -20628,28 +20921,134 @@

    Sections & Primary Docs

    - A.3.6 - A2 - Surplus Buffer And Smart Burn Engine - Surplus Buffer Splitter Parameters + A.3.6 - A2 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Surplus Buffer And Smart Burn Engine - Surplus Buffer Splitter Parameters + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters Section - The current Surplus Buffer Splitter parameters are: + The current Smart Burn Engine parameters are: + The rewardsDuration for the LSEV2-SKY-A USDS rewards contract must be set such that it is equal to the splitter.hop parameter. + + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module + Core + The Splitter Module splits funds transferred to it from the Surplus Buffer between accumulating SKY and paying USDS rewards to SKY stakers. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters + Core + The parameters of the Splitter Module are defined in the documents herein. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - Splitter Interval Parameter + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - Splitter Interval Parameter + Core + The hop parameter is the time interval between kicker.kbump funds being transferred from the Surplus Buffer to the Splitter. Together with the kicker.kbump parameter, it controls the rate at which funds are transferred from the Surplus Buffer to the Splitter. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - Splitter Interval Parameter - Splitter Interval Current Value + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - Splitter Interval Parameter - Splitter Interval Current Value + Core + The current value of the hop parameter is specified in A.3.6 - A2 - Smart Burn Engine Parameters. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - SKY Accumulation Percentage Parameter + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - SKY Accumulation Percentage Parameter + Core + The burn parameter is the percentage of each transfer from the Surplus Buffer to the Splitter that is sent to the Flapper contract, which accumulates SKY. The remainder of each transfer is sent to the contract for USDS rewards for SKY stakers. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - SKY Accumulation Percentage Parameter - SKY Accumulation Percentage Current Value + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Splitter Module - Splitter Module Parameters - SKY Accumulation Percentage Parameter - SKY Accumulation Percentage Current Value + Core + The current value of the burn parameter is specified in A.3.6 - A2 - Smart Burn Engine Parameters. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module + Core + The Kicker Module allows funds to be transferred from the Surplus Buffer to the Splitter as long as the Surplus Buffer is above a specified signed threshold. This allows funds to be transferred from the Surplus Buffer to the Splitter even when the Surplus Buffer is negative, as long as the Surplus Buffer is above the specified threshold. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters + Core + The parameters of the Kicker Module are defined in the documents herein. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Threshold Parameter + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Threshold Parameter + Core + The khump parameter is the minimum value of the Surplus Buffer for funds to be transferred from the Surplus Buffer to the Splitter contract. It is a signed integer with RAD precision. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Threshold Parameter - Kicker Threshold Current Value + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Threshold Parameter - Kicker Threshold Current Value + Core + The current value of the khump parameter is specified in A.3.6 - A2 - Smart Burn Engine Parameters. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Lot Size Parameter + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Lot Size Parameter + Core + The kbump parameter is the amount of funds transferred from the Surplus Buffer to the Splitter every splitter.hop interval when the Surplus Buffer is greater than kbump. Together with the splitter.hop parameter, it controls the rate at which funds are transferred from the Surplus Buffer to the Splitter. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Lot Size Parameter - Kicker Lot Size Current Value + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Kicker Module Parameters - Kicker Lot Size Parameter - Kicker Lot Size Current Value + Core + The current value of the kbump parameter is specified in A.3.6 - A2 - Smart Burn Engine Parameters. + + + + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Deployment + + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Kicker Module - Deployment + Core + The activation of the Kicker Module will be executed in the October 30, 2025 Executive Vote. This action is authorized to proceed directly to an Executive Vote without a prior Governance Poll. - A.3.6 - Surplus Buffer And Smart Burn Engine - Surplus Buffer Splitter Parameters - Modification + A.3.6 - Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Modification - Surplus Buffer And Smart Burn Engine - Surplus Buffer Splitter Parameters - Modification + Surplus Buffer And Smart Burn Engine - Smart Burn Engine Parameters - Modification Core - The parameters of the Surplus Buffer Splitter can be modified pursuant to the Operational Weekly Cycle. The Core Facilitator, in consultation with the Core Council Risk Advisor, can propose changes to the bump and hop parameters directly via an Executive Vote without requiring a Governance Poll. Changes to other parameters require a Governance Poll followed by an Executive Vote. + The parameters of the Smart Burn Engine can be modified pursuant to the Operational Weekly Cycle. The Core Facilitator, in consultation with the Stability Scope Advisors, can propose changes to the kbump and hop parameters directly via an Executive Vote without requiring a Governance Poll. LSEV2-SKY-A-USDS rewardsDuration should always match the value of the hop parameter without requiring prior governance authorization. Changes to other parameters require a Governance Poll followed by an Executive Vote. @@ -21704,6 +22103,18 @@

    Sections & Primary Docs

    Core The Genesis Capital of an Agent is the lesser of (1) the amount of capital contributed by Sky to the Agent and (2) the total capital of the Agent. + + + A.3.9 - Genesis Capital Backstop - Genesis Capital - Amount Of Capital Contributed By Sky To Agents + + Genesis Capital Backstop - Genesis Capital - Amount Of Capital Contributed By Sky To Agents + Core + The amount of capital contributed by Sky to Agents is: + + + A.4.1 - A1 - Core Tokens - USDS @@ -22154,7 +22565,7 @@

    Sections & Primary Docs

    SKY Staking Mechanism - SKY Staking Section - SKY holders can stake their tokens via the SKY Staking Mechanism available on Ethereum Mainnet and SkyLink Deployments. SKY stakers earn voting rewards sourced from the Sky Treasury Management Function. In lieu of USDS rewards, SKY stakers can choose to earn Agent Token Rewards, including SPK and the tokens of other Prime Agents incubated by Sky. SKY stakers can also borrow USDS against their staked collateral using the SKY-backed borrowing mechanism defined herein. + SKY holders can stake their tokens via the SKY Staking Mechanism available on Ethereum Mainnet and SkyLink Deployments. SKY stakers earn voting rewards sourced from the Sky Treasury Management Function. In lieu of USDS rewards and SKY rewards, SKY stakers can choose to earn Agent Token Rewards, including SPK and the tokens of other Prime Agents incubated by Sky. SKY stakers can also borrow USDS against their staked collateral using the SKY-backed borrowing mechanism defined herein. @@ -23239,98 +23650,191 @@

    Sections & Primary Docs

    SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures Core - The documents herein define short-term logic for SKY staking rewards and SKY-backed borrowing pending the implementation of the Sky Treasury Management Function and the stUSDS system. Short-term logic regarding MKR staking rewards and MKR-backed borrowing is also included herein. + The documents herein define short-term logic for SKY staking rewards pending the implementation of the Sky Treasury Management Function. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term Staking SKY Rewards + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term USDS Rewards For SKY Stakers - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term Staking SKY Rewards + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term USDS Rewards For SKY Stakers Core - USDS rewards for SKY stakers will be enabled as specified in A.4.1 - Core Tokens - SKY - MKR To SKY Upgrade. Until the Treasury Management Function (TMF) is live, USDS rewards for SKY stakers will be temporarily funded by the Smart Burn Engine; this interim mechanism will be discontinued once the TMF becomes operational. + Until the Treasury Management Function (TMF) is fully implemented, USDS rewards for SKY stakers will be temporarily funded by the Smart Burn Engine, subject to the parameters of the Smart Burn Engine; this interim mechanism will be discontinued once the TMF becomes fully operational. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term Staking Rewards - SKY Staking Rewards Parameters + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term Staking Rewards - SKY Staking Rewards Parameters + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers Core - When SKY Staking launches, the short-term Staking Rewards parameters will be specified in this document pursuant to A.4.1 - Core Tokens - SKY - Update Smart Burn Engine Parameters. + Until the Treasury Management Function (TMF) is fully implemented, SKY rewards for SKY stakers will be temporarily funded by SKY from the Protocol Treasury as specified in A.4.4 - Implementation; this interim mechanism will be discontinued once the TMF becomes fully operational. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY-Backed Borrowing + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY-Backed Borrowing + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation Core - SKY-backed borrowing will be enabled as specified in A.4.1 - Core Tokens - SKY - MKR To SKY Upgrade. In the short term, pending the development of the stUSDS system, SKY-backed borrowing will be funded directly by Sky. This funding must be replaced by the stUSDS system as soon as the stUSDS system is developed. + SKY rewards for SKY stakers are implemented through the Staking Rewards contract, the Vested Rewards Distribution contract, and the Vesting Stream contract, as specified in the documents herein. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY-Backed Borrowing - SKY-Backed Borrowing Parameters + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY-Backed Borrowing - SKY-Backed Borrowing Parameters + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract Core - When SKY Staking launches, the risk parameters for SKY-backed borrowing funded directly by Sky will be specified in this document pursuant to A.4.1 - Core Tokens - SKY - Launch SKY Staking and A.4.1 - Core Tokens - SKY - Update Liquidation Parameters For Borrowing Against Staked SKY. + The Staking Rewards contract is the user facing contract that allows SKY stakers to stake their SKY to receive SKY rewards. It maintains the balance of staked SKY receiving SKY rewards for each user and the associated accumulated rewards balance. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR Staking Rewards + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Address - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR Staking Rewards + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Address Core - As the legacy governance token of the Sky Protocol, MKR stakers are currently eligible for USDS rewards. This functionality will be phased out as specified in A.4.1 - Core Tokens - SKY - MKR To SKY Upgrade. The documents herein define the parameters for USDS rewards to MKR stakers during this interim period. + The address of the Staking Rewards contract on the Ethereum Mainnet is 0xB44C2Fb4181D7Cb06bdFf34A46FdFe4a259B40Fc. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR Staking Rewards - MKR Staking Rewards Parameters + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR Staking Rewards - MKR Staking Rewards Parameters + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters Core - The short-term staking rewards parameters are: - + The parameters of the Staking Rewards contract are specified in the documents herein. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Owner + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Owner + Core + The owner of the Staking Rewards contract is the contract that has the ability to control administrative functions for the Staking Rewards contract. The value of the owner parameter is the MCD_PAUSE_PROXY. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR-Backed Borrowing + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Rewards Distribution Contract Address - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR-Backed Borrowing + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Rewards Distribution Contract Address Core - Borrowing against staked MKR is currently supported and funded directly by Sky. This functionality will be phased out as specified in A.4.1 - Core Tokens - SKY - MKR To SKY Upgrade. The documents herein define the risk parameters for MKR-backed borrowing during this interim period. + The Rewards Distribution contract address rewardsDistribution is the address of the Rewards Distribution contract associated with the Staking Rewards contract. The value of the rewardsDistribution parameter is the address of the Rewards Distribution contract specified in A.4.4 - Rewards Distribution Contract Address. - A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR-Backed Borrowing - MKR-Backed Borrowing Parameters + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Rewards Token - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short-Term MKR-Backed Borrowing - MKR-Backed Borrowing Parameters + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Rewards Token Core - The current risk parameters for MKR-backed borrowing funded directly by Sky are: - + The Rewards Token rewardsToken is the token that users receive as rewards. The value of the rewardsToken parameter is SKY, representing SKY Tokens. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Staking Token + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Staking Rewards Contract - Staking Rewards Contract Parameters - Staking Token + Core + The Staking Token stakingToken is the token that users stake to earn rewards. The value of the stakingToken parameter is LSSKY, representing staked SKY Tokens. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract + Core + The Rewards Distribution contract is the contract that handles the regular transfer of reward tokens from the Vesting Stream contract to the Staking Rewards contract for distribution to end users. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Address + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Address + Core + The address of the Rewards Distribution contract on the Ethereum Mainnet is 0x675671A8756dDb69F7254AFB030865388Ef699Ee. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Parameters + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Parameters + Core + The parameters of the Rewards Distribution contract are specified in the documents herein. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Parameters - Staking Rewards Contract Address + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Parameters - Staking Rewards Contract Address + Core + The Staking Rewards contract address stakingRewards is the address of the Staking Rewards contract associated with the Rewards Distribution contract. The value of the stakingRewards parameter is the address of the Staking Rewards contract specified in A.4.4 - Staking Rewards Contract Address. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Parameters - Vesting Stream Contract Address + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Rewards Distribution Contract - Rewards Distribution Contract Parameters - Vesting Stream Contract Address + Core + The Vesting Stream contract address dssVest is the address of the Vesting Stream contract associated with the Rewards Distribution contract. The value of the dssVest parameter is the address of the Vesting Stream contract specified in A.4.4 - Vesting Stream. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract + Core + The Vesting Stream contract manages various vesting streams that vest SKY Tokens from the Protocol Treasury. One of these vesting streams regularly vests SKY Tokens to the Staking Rewards contract. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream + Core + The address of the Vesting Stream contract is the address corresponding to the MCD_VEST_SKY_TREASURY key in the Chainlog. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Contract Parameters + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Contract Parameters + Core + The parameters of the vesting stream managed by the Vesting Stream contract that vests SKY Tokens to the Staking Rewards contract are specified in the documents herein. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Contract Parameters - Vesting Total + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Contract Parameters - Vesting Total + Core + The Vesting Total vestTot is the number of rewards tokens to be vested in total over the Vesting Duration. The initial value of the vestTot parameter is 1,000,000,000 SKY. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Contract Parameters - Vesting Duration + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Contract Parameters - Vesting Duration + Core + The Vesting Duration vestTau is the total duration over which the Vesting Total number of tokens are to be vested linearly. The initial value of the vestTau parameter is 180 days. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Parameter Modification + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Implementation - Vesting Stream Contract - Vesting Stream Parameter Modification + Core + The parameters of the vesting stream that vests SKY Tokens to be transferred to the Staking Rewards contract may be modified by the Core Facilitator on the recommendation of the Core Council Risk Advisor through the Operational Weekly Cycle, and can be effected directly via an Executive Vote, without a prior Governance Poll. It is expected that the parameters will be reviewed and updated approximately every 90 days. + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Source Of SKY Rewards + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Source Of SKY Rewards + Core +

    Initially, the SKY Tokens in the Protocol Treasury to fund SKY rewards for SKY stakers will be funded by the 500,000,000 SKY transferred by the Sky Frontier Foundation to the Protocol Treasury.

    The vestTot and vestTau parameters of the Vesting Stream contract are set such that these 500,000,000 SKY will be distributed over three (3) months. After these three (3) months, SKY rewards must be funded by SKY acquired through buybacks and the parameters of the Vesting Stream contract must be adjusted accordingly.

    + + + + A.4.4 - SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Source Of SKY Rewards - Authorization Of Transfer By Sky Frontier Foundation + + SKY Staking Mechanism - SKY Staking - Short Term Transitionary Measures - Short Term SKY Rewards For SKY Stakers - Source Of SKY Rewards - Authorization Of Transfer By Sky Frontier Foundation + Core + Sky Governance hereby confirms that the transfer of the 500,000,000 SKY tokens specified in A.4.4 - Source Of SKY Rewards is consistent with the terms of the grant to the Sky Frontier Foundation. See A.2.15 - A1 - Ecosystem Entity Grants. @@ -24377,7 +24881,7 @@

    Annotations

    Monitoring And Ensuring - Element Annotation Annotation - This element refers to the ongoing responsibility of Support Facilitators to monitor the progress of routine governance processes, check for compliance with the rules, and confirm that all necessary documentation and approvals are in place. + This element refers to the ongoing responsibility of Core GovOps to monitor the progress of routine governance processes, check for compliance with the rules, and confirm that all necessary documentation and approvals are in place. @@ -24505,7 +25009,7 @@

    Annotations

    Properly Notified - Element Annotation Annotation - This element means that the Support Facilitators have been informed in accordance with the prescribed procedures, including the timing, method, and content of the notification, as required by the relevant Scope. + This element means that Core GovOps have been informed in accordance with the prescribed procedures, including the timing, method, and content of the notification, as required by the relevant Scope. @@ -24825,13 +25329,21 @@

    Tenets

    Action Tenet Currently, in the transition to Endgame, the Immutable Documents (Articles and Sections) can be amended pursuant to A.1.11 and A.1.12. Once the Sky Ecosystem enters the Endgame State, the Immutable Documents of the Atlas will be forever locked down and cannot be changed. + + + In The Transition To Endgame - Immutable Documents Can Be Amended + + In The Transition To Endgame - Immutable Documents Can Be Amended + Action Tenet + Currently, in the transition to Endgame, the Immutable Documents (Articles and Sections) can be amended pursuant to A.1.11 and A.1.12. Once the Sky Ecosystem enters the Endgame State, the Immutable Documents of the Atlas will be forever locked down and cannot be changed. + Key Atlas Contributors Key Atlas Contributors Action Tenet - Key Atlas contributors are individuals or teams that play a crucial role in the development of the Atlas. Relevant workstreams can include community building, research, data collection, data processing, data review, drafting, peer review, etc. The Support Facilitators, in consultation with Atlas Axis or other relevant Ecosystem Actors, will distribute funding based on criteria such as the scope of the contribution, its impact on the Atlas, and the quality of the work produced. + Key Atlas contributors are individuals or teams that play a crucial role in the development of the Atlas. Relevant workstreams can include community building, research, data collection, data processing, data review, drafting, peer review, etc. The Core Facilitator, in consultation with Atlas Axis or other relevant Ecosystem Actors, will distribute funding based on criteria such as the scope of the contribution, its impact on the Atlas, and the quality of the work produced. @@ -25493,6 +26005,19 @@

    Active Data

    Active Data The current Sky Core Integration Boost Reimbursement Amounts are: + + + A.2.4 - List Of Current Sky Direct Exposures + + List Of Current Sky Direct Exposures + Active Data + The current Sky Direct Exposures are: + + + A.2.9 - Lawyer Registry Current Approved Legal Counsels @@ -27153,7 +27678,7 @@

    Agent Scope Database

    Spark Core - Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Governance Facilitators to update the Atlas GitHub repository located at Pull requests · sky-ecosystem/next-gen-atlas · GitHub to reflect proposals approved by Prime Governance. + Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Core Facilitator to update the Atlas GitHub repository located at Pull requests · sky-ecosystem/next-gen-atlas · GitHub to reflect proposals approved by Prime Governance. @@ -28915,7 +29440,6 @@

    Agent Scope Database

    Core This Instance's associated Instance Configuration Document is located at Ethereum Mainnet - Curve USDC/USDT Pool Instance Configuration Document. - Ethereum Mainnet - Curve pyUSD/USDC Pool Instance Configuration Document Location @@ -29550,7 +30074,7 @@

    Agent Scope Database

    - Avalanche/dfn> + Avalanche Spark Core @@ -41922,7 +42446,7 @@

    Agent Scope Database

    Grove Core - Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Governance Facilitators to update the Atlas GitHub repository located at https://github.com/sky-ecosystem/next-gen-atlas/pulls to reflect proposals approved by Prime Governance. + Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Core Facilitator to update the Atlas GitHub repository located at https://github.com/sky-ecosystem/next-gen-atlas/pulls to reflect proposals approved by Prime Governance. @@ -43742,11 +44266,99 @@

    Agent Scope Database

    - Relayer Multisig + Prime Relayer Multisig + + Grove + Core + The Prime Relayer Multisig has the RELAYER_ROLE as defined in Relayer Role, and is controlled by Grove. + + + + Prime Relayer Multisig - Address + + Grove + Core + The address of the Prime Relayer Multisig on the Ethereum Mainnet is 0x0eEC86649E756a23CBc68d9EFEd756f16aD5F85f. + + + + Prime Relayer Multisig - Required Number Of Signers + + Grove + Core + The Prime Relayer Multisig currently has a 4/7 signing requirement. + + + + Prime Relayer Multisig - Signers + + Grove + Core + The signers of the Prime Relayer Multisig are seven (7) addresses controlled by Grove. + + + + Prime Relayer Multisig - Usage Standards + + Grove + Core + The signers of the Prime Relayer Multisig must use the Multisig to exercise the RELAYER_ROLE in accordance with the instructions specified in the Grove Artifact. + + + + Prime Relayer Multisig - Modification + + Grove + Core + Grove can change the signers of the Prime Relayer Multisig at any time, so long as there are at least two (2) signers and at least a majority of signers are required to execute transactions. + + + + Core Operator Relayer Multisig Grove Core - The Core Operator Relayer Multisig has the RELAYER_ROLE as defined in Relayer Role. In a future iteration of the Grove Artifact, additional logic will be added herein. + The Core Operator Relayer Multisig has the RELAYER_ROLE as defined in Relayer Role and is controlled by Amatsu. + + + + Core Operator Relayer Multisig - Address + + Grove + Core + The address of the Core Operator Relayer Multisig on the Ethereum Mainnet is 0x4364D17B578b0eD1c42Be9075D774D1d6AeAFe96. + + + + Core Operator Relayer Multisig- Required Number Of Signers + + Grove + Core + The Core Operator Relayer Multisig currently has a 2/3 signing requirement. + + + + Core Operator Relayer Multisig - Signers + + Grove + Core + The signers of the Core Operator Relayer Multisig are three (3) addresses controlled by Operational GovOps Amatsu. + + + + Core Operator Relayer Multisig - Usage Standards + + Grove + Core + The signers of the Core Operator Relayer Multisig must use the Multisig to exercise the RELAYER_ROLE in accordance with the instructions specified in the Grove Artifact. + + + + Core Operator Relayer Multisig - Modification + + Grove + Core + Operational GovOps Amatsu can change the signers of the Core Operator Relayer Multisig at any time, so long as there are at least three (3) signers and at least two thirds of signers are required to execute transactions. @@ -43754,7 +44366,54 @@

    Agent Scope Database

    Grove Core - The Freezer Multisig has the FREEZER_ROLE as defined in Freezer Role. In a future iteration of the Grove Artifact, additional logic will be added herein. + The Freezer Multisig has the FREEZER_ROLE as defined in Freezer Role and is controlled by the Core Facilitator and Operational Facilitator. + + + + Freezer Multisig - Address + + Grove + Core + The address of the Freezer Multisig on the Ethereum Mainnet is 0xB0113804960345fd0a245788b3423319c86940e5. + + + + Freezer Multisig - Required Number Of Signers + + Grove + Core + The Freezer Multisig currently has a 2/4 signing requirement. + + + + Freezer Multisig - Signers + + Grove + Core + The Freezer Multisig has the following signers: + + + + + + Freezer Multisig - Usage Standards + + Grove + Core +

    The signers of the Freezer Multisig should exercise their authority to freeze the Grove Liquidity Layer in the event that Grove is not complying with rules regarding Risk Capital or Asset Liability Management, or in the event of another emergency. The signers should consult with Operational GovOps Amatsu before exercising such authority, unless such consultation would cause a delay that could result in a loss of user funds or harm to Sky or Grove. Operational GovOps Amatsu may also ask the signers to exercise the Freezer Multisig in an emergency. The signers will work with Amatsu and, if necessary, other Operational GovOps, in good faith in determining whether to exercise their authority based on such request.

    Each action executed by the Freezer Multisig, including any function calls and their parameters, must be reported to the Sky community within a reasonable time frame through a post on the Sky Forum.

    + + + + Freezer Multisig - Modification + + Grove + Core +

    Modification of the signers of the Freezer Multisig must be approved through an Atlas Edit Proposal.

    The only exceptions to this are if: 1) a signer self-reports a loss of access to their private key due to any reason; or 2) a signer explicitly expresses their wish to be removed as a signer. In both cases, the signer is required to communicate the loss of access to their private key, or the wish to be removed as a signer, in the form of a public Sky Forum post. The specific signer should be replaced as soon as possible, which does not require a Governance Poll.

    Any changes to the multisig signers that do not fall within the two exceptions listed above, or that have not been ratified by Sky Governance, should be questioned immediately and treated as malicious. Where malicious activity is suspected, the Facilitators must prepare an expedited Executive Vote so that Sky Governance can vote on removing external security access from the multisig.

    @@ -46301,206 +46960,7 @@

    Agent Scope Database

    Grove Core - Ethena - - - - Asset Supplied By Grove Liquidity Layer - - Grove - Core - USDC - - - - Token - - Grove - Core - PT-sUSDe - - - - Broker - - Grove - Core - FalconX - - - - Contract Addresses - - Grove - Core - The documents herein define the Instance contract addresses. - - - - Token Address - - Grove - Core - 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 - - - - Underlying Asset Address - - Grove - Core - 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 - - - - Broker Address - - Grove - Core - 0xD94F9ef3395BBE41C1f05ced3C9a7dc520D08036 - - - - Rate Limit IDs - - Grove - Core - The specific RateLimitID(s) for this conduit's inflow and outflow will be specified in a future iteration of the Grove Artifact. - - - - Inflow RateLimitID - - Grove - Core - The inflow RateLimitID is: 0x098ad67dc41c1a5892ec3ef5fd411198dc11962475e9ef2e0362e6cb7f5a2174. - - - - Outflow RateLimitID - - Grove - Core - The outflow RateLimitID is: 0x027191d7c552bd41037422747bcde7caca7d1f6afc5ea9b85f8a47432c70be67. - - - - Rate Limits - - Grove - Core - The current maxAmount and slope for this conduit's inflow/outflow are defined in the subdocuments herein. - - - - Deposit Rate Limits (via FalconX) - - Grove - Core - The deposit rate limits are: - - - - - - Withdrawal Rate Limits (via FalconX) - - Grove - Core - The withdrawal rate limits are: - - - - - - Redemption Rate Limits (via Pendle Protocol) - - Grove - Core - The redemption rate limits are: - - - - - - Off-chain Operational Parameters - - Grove - Core - The documents herein contain specific off-chain parameters for this Instance. - - - - Instance-specific Operational Processes - - Grove - Core - The documents herein contain operational procedures or monitoring requirements unique to this Instance that deviate from or otherwise supplement the general Grove Liquidity Layer processes. - - - - Aave - - Grove - Core - The Ethereum Mainnet Instances of the Aave Protocol with Active Status are stored herein. - - - - Ethereum Mainnet - Aave Core v3 USDC Instance Configuration Document - - Grove - Core - The documents herein contain the Instance Configuration Document for the Aave Core v3 USDC Instance. - - - - RRC Framework Full Implementation Coverage - - Grove - Core - Pending - - - - Parameters - - Grove - Core - The documents herein define the parameters of the Aave Core v3 USDC Instance of the Allocation System Primitive. - - - - Instance Identifiers - - Grove - Core - The documents herein define the Instance identifiers. - - - - Network - - Grove - Core - Ethereum Mainnet - - - - Target Protocol - - Grove - Core - Aave Core v3 + Ethena @@ -46516,7 +46976,15 @@

    Agent Scope Database

    Grove Core - aEthUSDC + PT-sUSDe + + + + Broker + + Grove + Core + FalconX @@ -46532,7 +47000,7 @@

    Agent Scope Database

    Grove Core - 0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c + 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 @@ -46540,7 +47008,15 @@

    Agent Scope Database

    Grove Core - 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 + 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 + + + + Broker Address + + Grove + Core + 0xD94F9ef3395BBE41C1f05ced3C9a7dc520D08036 @@ -46548,7 +47024,7 @@

    Agent Scope Database

    Grove Core - The specific RateLimitID(s) for this conduit's inflow and outflow are defined in the subdocuments herein. + The specific RateLimitID(s) for this conduit's inflow and outflow will be specified in a future iteration of the Grove Artifact. @@ -46556,7 +47032,7 @@

    Agent Scope Database

    Grove Core - The inflow RateLimitID is: 0x5b6ed3b27d9aa6a9aaf68fc5c0980d9122ac4123093cce0241e4e047c154e214. + The inflow RateLimitID is: 0x098ad67dc41c1a5892ec3ef5fd411198dc11962475e9ef2e0362e6cb7f5a2174. @@ -46564,7 +47040,7 @@

    Agent Scope Database

    Grove Core - The outflow RateLimitID is: 0xc0a083c57c21570181e9781d750d04917923daac34e804bad63a5a241c92a850. + The outflow RateLimitID is: 0x027191d7c552bd41037422747bcde7caca7d1f6afc5ea9b85f8a47432c70be67. @@ -46576,26 +47052,40 @@

    Agent Scope Database

    - Deposit Rate Limits + Deposit Rate Limits (via FalconX) Grove Core The deposit rate limits are: - Withdrawal Rate Limits + Withdrawal Rate Limits (via FalconX) Grove Core The withdrawal rate limits are: + + + + + + Redemption Rate Limits (via Pendle Protocol) + + Grove + Core + The redemption rate limits are: @@ -46617,11 +47107,19 @@

    Agent Scope Database

    - Ethereum Mainnet - Aave Core v3 RLUSD Instance Configuration Document + Aave Grove Core - The documents herein contain the Instance Configuration Document for the Aave Core v3 RLUSD Instance. + The Ethereum Mainnet Instances of the Aave Protocol with Active Status are stored herein. + + + + Ethereum Mainnet - Aave Core v3 USDC Instance Configuration Document + + Grove + Core + The documents herein contain the Instance Configuration Document for the Aave Core v3 USDC Instance. @@ -46637,7 +47135,7 @@

    Agent Scope Database

    Grove Core - The documents herein define the parameters of the Aave Core v3 RLUSD Instance of the Allocation System Primitive. + The documents herein define the parameters of the Aave Core v3 USDC Instance of the Allocation System Primitive. @@ -46669,7 +47167,7 @@

    Agent Scope Database

    Grove Core - RLUSD + USDC @@ -46677,7 +47175,7 @@

    Agent Scope Database

    Grove Core - aEthRLUSD + aEthUSDC @@ -46693,7 +47191,7 @@

    Agent Scope Database

    Grove Core - 0xFa82580c16A31D0c1bC632A36F82e83EfEF3Eec0 + 0x98C23E9d8f34FEFb1B7BD6a91B7FF122F4e16F5c @@ -46701,7 +47199,7 @@

    Agent Scope Database

    Grove Core - 0x8292Bb45bf1Ee4d140127049757C2E0fF06317eD + 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 @@ -46717,7 +47215,7 @@

    Agent Scope Database

    Grove Core - The inflow RateLimitID is: 0xd8ebadbd4eb7be4a44bcadbfa0d3e4ca014faa5e1973f993a4193ce396a61208. + The inflow RateLimitID is: 0x5b6ed3b27d9aa6a9aaf68fc5c0980d9122ac4123093cce0241e4e047c154e214. @@ -46725,7 +47223,7 @@

    Agent Scope Database

    Grove Core - The outflow RateLimitID is: 0x574251b6fde351d987ce5235618a87bef48d50787414912b19ff8992cb2ae476. + The outflow RateLimitID is: 0xc0a083c57c21570181e9781d750d04917923daac34e804bad63a5a241c92a850. @@ -46743,8 +47241,8 @@

    Agent Scope Database

    Core The deposit rate limits are: @@ -46770,19 +47268,123 @@

    Agent Scope Database

    - Interim Deployment + Instance-specific Operational Processes + + Grove + Core + The documents herein contain operational procedures or monitoring requirements unique to this Instance that deviate from or otherwise supplement the general Grove Liquidity Layer processes. + + + + Ethereum Mainnet - Aave Core v3 RLUSD Instance Configuration Document + + Grove + Core + The documents herein contain the Instance Configuration Document for the Aave Core v3 RLUSD Instance. + + + + RRC Framework Full Implementation Coverage + + Grove + Core + Pending + + + + Parameters + + Grove + Core + The documents herein define the parameters of the Aave Core v3 RLUSD Instance of the Allocation System Primitive. + + + + Instance Identifiers + + Grove + Core + The documents herein define the Instance identifiers. + + + + Network + + Grove + Core + Ethereum Mainnet + + + + Target Protocol + + Grove + Core + Aave Core v3 + + + + Asset Supplied By Grove Liquidity Layer Grove Core - This Instance is currently defined as an Interim Deployment (see A.1.9 - Interim Deployments) and as such has CRR of 100%. The testing parameters of this Interim Deployment are specified in the documents herein. + RLUSD - Maximum Allocation + Token Grove Core - The maximum allocation for this Interim Deployment is $25 million. + aEthRLUSD + + + + Contract Addresses + + Grove + Core + The documents herein define the Instance contract addresses. + + + + Token Address + + Grove + Core + 0xFa82580c16A31D0c1bC632A36F82e83EfEF3Eec0 + + + + Underlying Asset Address + + Grove + Core + 0x8292Bb45bf1Ee4d140127049757C2E0fF06317eD + + + + Rate Limit IDs + + Grove + Core + The specific RateLimitID(s) for this conduit's inflow and outflow are defined in the subdocuments herein. + + + + Inflow RateLimitID + + Grove + Core + The inflow RateLimitID is: 0xd8ebadbd4eb7be4a44bcadbfa0d3e4ca014faa5e1973f993a4193ce396a61208. + + + + Outflow RateLimitID + + Grove + Core + The outflow RateLimitID is: 0x574251b6fde351d987ce5235618a87bef48d50787414912b19ff8992cb2ae476. @@ -46790,15 +47392,40 @@

    Agent Scope Database

    Grove Core - The Rate Limits for this Interim Deployment are defined in Rate Limits. + The current maxAmount and slope for this conduit's inflow/outflow are defined in the subdocuments herein. - Instance-specific Operational Processes + Deposit Rate Limits Grove Core - The documents herein contain operational procedures or monitoring requirements unique to this Instance that deviate from or otherwise supplement the general Grove Liquidity Layer processes. + The deposit rate limits are: + + + + + + Withdrawal Rate Limits + + Grove + Core + The withdrawal rate limits are: + + + + + + Off-chain Operational Parameters + + Grove + Core + The documents herein contain specific off-chain parameters for this Instance. @@ -46953,30 +47580,6 @@

    Agent Scope Database

    Core The documents herein contain specific off-chain parameters for this Instance. - - - Interim Deployment - - Grove - Core - This Instance is currently defined as an Interim Deployment (see A.1.9 - Interim Deployments) and as such has CRR of 100%. The testing parameters of this Interim Deployment are specified in the documents herein. - - - - Maximum Allocation - - Grove - Core - The maximum allocation for all Interim Deployments in Aave Horizon is $25 million. - - - - Rate Limits - - Grove - Core - The Rate Limits for this Interim Deployment are defined in Rate Limits. - Instance-specific Operational Processes @@ -47138,30 +47741,6 @@

    Agent Scope Database

    Core The documents herein contain specific off-chain parameters for this Instance. - - - Interim Deployment - - Grove - Core - This Instance is currently defined as an Interim Deployment (see A.1.9 - Interim Deployments) and as such has CRR of 100%. The testing parameters of this Interim Deployment are specified in the documents herein. - - - - Maximum Allocation - - Grove - Core - The maximum allocation for all Interim Deployments in Aave Horizon is $25 million. - - - - Rate Limits - - Grove - Core - The Rate Limits for this Interim Deployment are defined in Rate Limits. - Instance-specific Operational Processes @@ -49442,7 +50021,7 @@

    Agent Scope Database

    Keel Core - Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Governance Facilitators to update the Atlas GitHub repository located at https://github.com/sky-ecosystem/next-gen-atlas/pulls to reflect proposals approved by Prime Governance. + Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Core Facilitator to update the Atlas GitHub repository located at https://github.com/sky-ecosystem/next-gen-atlas/pulls to reflect proposals approved by Prime Governance. @@ -53217,7 +53796,7 @@

    Agent Scope Database

    Launch Agent 3 Core - Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Governance Facilitators to update the Atlas GitHub repository located at https://github.com/sky-ecosystem/next-gen-atlas/pulls to reflect proposals approved by Prime Governance. + Until the Powerhouse system supports updating Agent Artifacts, the Operational Facilitator works with the Core Facilitator to update the Atlas GitHub repository located at https://github.com/sky-ecosystem/next-gen-atlas/pulls to reflect proposals approved by Prime Governance.