Skip to content

Commit

Permalink
create sccp 372 / update 406 / sccp 2151 (#2165)
Browse files Browse the repository at this point in the history
* create sccp 372

* Update sccp-372.md

* Update sip-406.md

* Update sip-406.md

* Update sip-406.md

* Update sip-406.md

* Update sip-406.md

* update params

* update parameters

* Create sccp-2151.md

* Update sccp-2151.md

* Update sccp-2151.md
  • Loading branch information
kaleb-keny authored Dec 6, 2024
1 parent cc25202 commit c08e863
Show file tree
Hide file tree
Showing 3 changed files with 103 additions and 6 deletions.
31 changes: 31 additions & 0 deletions content/sccp/sccp-2151.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
sccp: 2151
network: Ethereum
title: Deploy sUSD in AAVE
author: Kaleb (@kaleb-keny)
status: Vote_Pending
created: 2024-12-05
type: Governance
proposal: >-
https://snapshot.org/#/snxgov.eth/proposal/0xc975f275b03b975cfea4e8a5a6c39050d78423c08cca18cd77c87088ecc02b36
---

# Simple Summary

This SCCP proposes deposit in a special Treasury account 5m sUSD backed by the protocol. The funds would be used by Treasury to alleviate the sUSD borrow pressure on AAVE on optimism. Treasury would be required to burn the funds once usage of these funds had run it's course.

# Abstract

The proposal entails:
- Minting 5m sUSD
- Sending it to the [TC wallet address](https://etherscan.io/address/0x99f4176ee457afedffcb1839c7ab7a030a5e4a92)
- Treasury would be required to deposit the sUSD on AAVE on optimism
- Treasury would burn the sUSD along with any interest profit made on the deposit as the usage of these funds had run it's course

# Motivation

The main motivation is to alleviate the high demand for sUSD on aave optimism, with the apy hitting highs.


# Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
59 changes: 59 additions & 0 deletions content/sccp/sccp-372.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
sccp: 372
title: Deploy More Markets to Perps V3 Base and Arbitrum
network: Arbitrum & Base
status: Vote_Pending
proposal: >-
https://snapshot.org/#/snxgov.eth/proposal/0x7dfe429b79f136243c3a9821508aee40fd4c708ff2ccd9faac6a3e70335b20c5
type: Governance
created: 2024-12-04
author: Kaleb
---

# Simple Summary

This SCCP proposes to deploy the below markets on Perps V3 on Base and Arbitrum:

| **Market** | **minimumInitialMarginRatio** | **initialMarginRatio** | **maintenanceMarginScalar** | **skewScale** | **maxMarketSize** | **maxMarketValue** |
|:----------:|:-----------------------------:|:----------------------:|:---------------------------:|:-------------:|:-----------------:|:------------------:|
| MORPHO | 5% | 1.36 | 0.317 | 2,000,000 | 1,000,000 | 1,000,000 |
| CHILLGUY | 5% | 1.36 | 0.317 | 8,000,000 | 6,000,000 | 2,000,000 |
| AERO | 5% | 0.322 | 0.317 | 500,000 | 1,000,000 | 300,000 |


Aside from the above parameters , the perps markets will have the following configurations as well:
- TakerFeeRatio: 10 bp
- MakerFeeRatio: 0 bp
- maxFundingVelocity: 9
- flagRewardRatio: 3 bp
- minimumPositionMargin: 50
- lockedOiRatio: 0.5
- maxLiquidationLimitMultiplier: 1.5
- maxLiquidationPD: 5 bp
- endorsedLiquidator: "0x11233749514Ab8d00C0A5873DF7428b3db70030f"


# Abstract

The parameters configurations description is as follows:
- initialMarginRatio is a scalar applied on the minimumInitialMarginRatio to determine the minimum initial margin required to support a given portfolio of positions
- maintenanceMarginScalar is a scalar applied on the initialMargin in order to obtain the maintenanceMargin. When traders fall below the maintenance margin, they are liquidated.
- skewScale is the scaling factor of the relevant market in the underlying currency for computing price impact and funding rates
- maxMarketSize is the max market value of the relevant market in the underlying currency
- maxMarketValue is the max market value of the relevant market in USD
- maker/taker fees pertain to fees charged when trading
- maxFundingVelocity is the main parameter that allows to nudge funding rates
- minimumPositionMargin is the minimum margin required
- lockedOiRatio is the multiplier that determines the minimum amount of perp collateral required to back a given perp market
- maxLiquidationLimitMultiplier is a parameter that rate limits liquidations. It is applied on the sum of maker and taker fees with a liquidation rate limit being triggered if pd exceeds that value
- maxLiquidationPD is the minimum pd that triggers a reset of the liquidation capacity
- endorsedLiquidator is a liquidator address that can bypass the rate limit
- the collateral liquidation penalty is the penalty paid to the liquidator for executing a liquidation


# Motivation

The more options traders have via Synthetix Perps, the less likely they will move their margin to other trading venues to trade markets we don't provide.

# Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
19 changes: 13 additions & 6 deletions content/sips/sip-406.md
Original file line number Diff line number Diff line change
@@ -1,29 +1,36 @@
---
sip: 406
title: FeatureFlag - Atomic Synth Trading & Wrappers
network: Arbitrum
status: Draft
network: Arbitrum & Base
status: Vote_Pending
proposal: >-
https://snapshot.org/#/snxgov.eth/proposal/0x6000da3b53be810fefd9bc19b8ab4f1a975d63ad68197a73636050a7246d3a72
type: Governance
author: Kaleb (@kaleb-keny)
---

## Simple Summary

The sip proposes to put in place feature flag into the on `atomicOrderModule` and `WrapperModule` , essentially allowing the protocol to disable atomic trades, wraps and unwraps on specified synths.
The sip proposes to put in place a feature flag into the `asyncOrderModule`, `atomicOrderModule` and `WrapperModule` , essentially allowing the protocol to disable atomic trades, wraps and unwraps.

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

The current implementation of the spot market on v3 does not allow for disabling of atomic orders or wrapping/unwrapping of synths. This SIP would allow the protocol to enable/disable those functions.
The current implementation of the spot market on v3 does not allow for disabling of atomic orders or wrapping/unwrapping of synths. This SIP would allow the protocol to enable/disable those functions. In addition, a general purpose flag would be added that allows the owner to disable trading on the entire spot market.

## Motivation

The main motivation is to allow the protocol to disable synth trading and wrapping/unwrapping on specified synths.
The main motivation is to allow the protocol to have more fine tuned and general control over synth trading and wrapping.

## Specification

The specification would be incorporating the standard v3 feature flag [module](https://github.com/Synthetixio/synthetix-v3/blob/d8240a31967b518d95237ee939ba7222e6618454/utils/core-modules/contracts/modules/FeatureFlagModule.sol) into the [atomicOrderModule](https://github.com/Synthetixio/synthetix-v3/blob/d8240a31967b518d95237ee939ba7222e6618454/markets/spot-market/contracts/modules/AtomicOrderModule.sol) and the [wrapperModule](https://github.com/Synthetixio/synthetix-v3/blob/d8240a31967b518d95237ee939ba7222e6618454/markets/spot-market/contracts/modules/WrapperModule.sol). Whereby each `marketId` would be need to be have the trading / wrapping feature enabled on it, otherwise transactions involved synths that have not been enabled would revert.
The specification would be incorporating the standard v3 feature flag [module](https://github.com/Synthetixio/synthetix-v3/blob/d8240a31967b518d95237ee939ba7222e6618454/utils/core-modules/contracts/modules/FeatureFlagModule.sol) into the [atomicOrderModule](https://github.com/Synthetixio/synthetix-v3/blob/d8240a31967b518d95237ee939ba7222e6618454/markets/spot-market/contracts/modules/AtomicOrderModule.sol) and the [wrapperModule](https://github.com/Synthetixio/synthetix-v3/blob/d8240a31967b518d95237ee939ba7222e6618454/markets/spot-market/contracts/modules/WrapperModule.sol). Whereby each `marketId` would be need to be have the trading / wrapping feature enabled on it, otherwise transactions involved synths that have not been enabled would revert. In addition, a general purpose would be added to all the relevant spot market modules to allow the owner to curtail exchanges.

The requirement spec is covered under [PR](https://github.com/Synthetixio/synthetix-v3/pull/2339), essentially it entails adding the following flags:
- `spotMarketEnabled` would enable the entire spot market for all synths, i.e. atomic, async and wrappers
- `atomicOrdersEnabled` would enable atomic orders on a specific synth, whereby the non-core USD need to be enabled for the atomic swap transaction to go through
- `wrapperEnabled` would enable wraps & unwraps on a specific synth, whereby the non-core USD need to be enabled for the wrap/unwrap transaction to go through

### Configurable Values (Via SCCP)

Expand Down

0 comments on commit c08e863

Please sign in to comment.