Merge branch 'master' into sccp-346

content/sccp/sccp-2122.md → content/sccp/sccp-2132.md

@@ -1,11 +1,9 @@
 ---
-sccp: 2122
+sccp: 2132
 network: Ethereum & Optimism
-title: Reduce target staking ratio to 300%
+title: Reduce target staking ratio to 250%
 author: Cavalier (@cavalier)
-status: Implemented
-proposal: >-
-  https://snapshot.org/#/snxgov.eth/proposal/0xa4702dc982b92d1bf72fe55e8b2bff34ab3c4f0bcbfe53fd9a9b7dff1bc34465
+status: Draft
 created: 2024-07-05
 type: Governance
 ---
@@ -16,19 +14,19 @@ type: Governance
 
 <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the SCCP.-->
 
-Lower the target c-ratio to 300%
+Lower the target c-ratio to 250%
 
 ## Abstract
 
 <!--A short (~200 word) description of the variable change proposed.-->
 
-This SCCP changes the target c-ratio from 500% to 300%, and reduces the cost to recover a flagged account from liquidation by up to 31%.
+This SCCP changes the target c-ratio from 500% to 250%
 
 ## Motivation
 
 <!--The motivation is critical for SCCPs that want to update variables within Synthetix. It should clearly explain why the existing variable is not incentive aligned. SCCP submissions without sufficient motivation may be rejected outright.-->
 
-The target c-ratio was increased to 500% by https://sips.synthetix.io/sccp/sccp-285. With the SNX price below $2, a c-ratio of 500% puts undue pressure on stakers, and inhibits their ability to burn back to target to remove a liquidation flag. This SCCP reduces the target c-ratio back to 300% where it should remain until price volatility has decreased, and the price of SNX is above $3 for at least several weeks. Stability of the c-ratio is critical for stakers to make informed decisions about their staking strategy. This SCCP should provide confidence to stakers that the ratio will remain at 300% until SNX recovers and price volatility declines.
+With the SNX price below $2, a c-ratio of 500% puts undue pressure on stakers, and inhibits their ability to burn back to target to remove a liquidation flag. This SCCP reduces the target c-ratio back to 250% where it should remain until price volatility has decreased, and the price of SNX is above $3 for at least several weeks. Stability of the c-ratio is critical for stakers to make informed decisions about their staking strategy. This SCCP should provide confidence to stakers that the ratio will remain at 250% until SNX recovers and price volatility declines.
 
 ## Copyright
 

content/sccp/sccp-2133.md

@@ -0,0 +1,27 @@
+---
+sccp: 2133
+network: Ethereum & Optimism
+title: Facilitate sUSD Transfers from L2 to L1 - Peg Rebalancing
+author: Cavalier (@cavalier)
+status: Draft
+created: 2024-07-05
+type: Governance
+---
+
+<!--You can leave these HTML comments in your merged SCCP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new SCCPs. Note that an SCCP number will be assigned by an editor. When opening a pull request to submit your SCCP, please use an abbreviated title in the filename, `sccp-draft_title_abbrev.md`. The title should be 44 characters or less.-->
+
+## Simple Summary
+
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the SCCP.-->
+
+The TC plans to buy sUSD on optimism in order to help with the peg. However, given the need for sUSD liquidity on ethereum, to manage cratio, they request that they receive the sUSD immediately on ethereum. Hence This SCCP proposes, to facilitate this transaction with TC sending sUSD 10 million to pdao, pdao burning the sUSD on optimism and minting an equivalent amount on ethereum to the TC. No impact on the debt pool would materialize from executing this SCCP.
+
+## Motivation
+
+<!--The motivation is critical for SCCPs that want to update variables within Synthetix. It should clearly explain why the existing variable is not incentive aligned. SCCP submissions without sufficient motivation may be rejected outright.-->
+
+The changes entail the TC sending sUSD to pdao on optimism. Pdao burns the sUSD on optimism and mints an equivalent amount on ethereum.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

content/sccp/sccp-346.md

@@ -0,0 +1,31 @@
+---
+sccp: 346
+network: Ethereum
+title: Update Liquidation Ratio
+author: Cavalier
+status: Draft
+created: 2024-08-05
+type: Governance
+---
+
+## Simple Summary
+
+<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the SCCP.-->
+
+This SCCP proposes to decrease the SNX `liquidationRatio` from 120% to 105% on the ethereum network.
+
+## Abstract
+
+<!--A short (~200 word) description of the variable change proposed.-->
+
+Since the implementation of [SIP-306](https://sips.synthetix.io/sips/sip-306/) on the ethereum network, accounts that are below the `liquidationRatio` ratio, are immediately liquidated with the snx and debt socialized among stakers on v3. The only staker on v3 is the Treasury Council, who is comfortable with the change.
+
+## Motivation
+
+<!--The motivation is critical for SCCPs that want to update variables within Synthetix. It should clearly explain why the existing variable is not incentive aligned. SCCP submissions without sufficient motivation may be rejected outright.-->
+
+Treasury is the sole staker on v3 connected to v2x at the moment, and they have the ability to absorb the liquidated snx with a significantly lower penalty. Hence, this SCCP proposes to lower the liquidation penalty in order to improve the system health by allowing for gradual liquidations to materialize. 
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

content/sips/sip-398.md

@@ -137,7 +137,7 @@ In summary, these analyses show that Chainlink Data Streams empirically presents
 
 ### Economics
 
-To ensure Chainlink Data Streams can sustainably provide Synthetix with an independent, verifiable, and low-latency source of financial market data, this proposal establishes an economic framework involving a revenue-sharing fee structure. Specifically, 1.5% of the total trading fees and liquidation fees generated on markets where Chainlink Data Streams are used would be paid in exchange for the oracle service. The proposed split of fees is as follows: For every $100 of trading fees generated, 1.5% would go to the oracle services. The remaining amount would then be divided among the protocol, LPs (Liquidity Providers), integrators, and the keeper incentive as seen fit by Synthetix. This arrangement provides Synthetix access to Data Streams, including all generally available feeds, along with unlimited onchain verifications at no added premium. 
+To ensure Chainlink Data Streams can sustainably provide Synthetix with an independent, verifiable, and low-latency source of financial market data, this proposal establishes an economic framework involving a revenue-sharing fee structure. Specifically, 1.2% of the total trading fees and liquidation fees generated on markets where Chainlink Data Streams are used would be paid in exchange for the oracle service. The proposed split of fees is as follows: For every $100 of trading fees generated, 1.2% would go to the oracle services. The remaining amount would then be divided among the protocol, LPs (Liquidity Providers), integrators, and the keeper incentive as seen fit by Synthetix. This arrangement provides Synthetix access to Data Streams, including all generally available feeds, along with unlimited onchain verifications at no added premium. 
 
 ### Deployment Plan
 

content/sips/sip-402.md

@@ -0,0 +1,74 @@
+---
+sip: 402
+title: Remove Account Cooldown Timer for Rewards Claim Function
+network: Ethereum, Optimism, Base & Arbitrum
+status: Draft
+type: Governance
+author: Robin (@0xrobin2192)
+created: 2024-08-02
+---
+
+## Simple Summary
+
+This proposal outlines a plan to remove the cooldown timer reset when users claim rewards.
+
+## Abstract
+
+A 24 hour cooldown on withdrawing funds exists to prevent just-in-time liquidity MEV and resets when any action is taken by a user for a given account. Currently, this timer resets when users claim rewards, which has no impact on debt balance. 
+
+This proposal seeks to add a new function `loadAccountAndPermissionNoRecording` which does not call `recordInteraction`, and replace `loadAccountAndValidatePermission` with `loadAccountAndPermissionNoRecording` in the `claimRewards` function.
+
+Note this proposal is not inclusive of PNL claims, which are representative of positive pool performance.
+
+
+## Motivation
+
+The motivation behind this SIP is to remedy poor UX, as users are frequently confused when they wait 24 hours for funds to become withdrawable, claim rewards, and then realize that their previously withdrawable funds are now locked for another 24 hours.
+
+## Specification
+
+Create a new function `loadAccountAndPermissionNoRecording` which copies the `loadAccountAndValidatePermission` function but removes the `recordInteraction(account)` call.
+
+Modify `claimRewards` function to call `loadAccountAndPermissionNoRecording` instead of `loadAccountAndValidatePermission`.
+
+
+### Rationale
+
+`loadAccountAndValidatePermission` is used elsewhere in the codebase, so a new function is needed. The simplest path forward is to copy the `loadAccountAndValidatePermission` function while removing the function call that resets the cooldown timer, `recordInteraction`.
+
+
+### Technical Specification
+
+Define the new function `loadAccountAndPermissionNoRecording` as: 
+```
+  /**
+     * @dev Loads the Account object for the specified accountId,
+     * and validates that sender has the specified permission. These
+     * are different actions but they are merged in a single function
+     * because loading an account and checking for a permission is a very
+     * common use case in other parts of the code.
+     */
+    function loadAccountAndPermissionNoRecording(
+        uint128 accountId,
+        bytes32 permission
+    ) internal returns (Data storage account) {
+        account = Account.load(accountId);
+
+        if (!account.rbac.authorized(permission, ERC2771Context._msgSender())) {
+            revert PermissionDenied(accountId, permission, ERC2771Context._msgSender());
+        }
+    }
+
+```
+
+### Test Cases
+
+Test cases will be added to the code base before release.
+
+### Configurable Values
+
+NA
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).