Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create sip-385.md #1968

Closed
wants to merge 1 commit into from
Closed

Create sip-385.md #1968

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 59 additions & 0 deletions content/sips/sip-385.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
sip: 385
title: Pause SNX BBB & Distribute v3 fees to v2x stakers
network: Multi
status: Draft
type: Governance
author: 'cyberduck (@acyberduck)'
proposal: >-
...
created: 2024-05-17
---

<!--You can leave these HTML comments in your merged SIP 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 SIPs. Note that an SIP number will be assigned by an editor. When opening a pull request to submit your SIP, please use an abbreviated title in the filename, `sip-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." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

This SIP pauses the buyback and burn SNX mechanism on Base and replaces it with direct v3 fee distribution on Ethereum and Optimism. These fees will be claimable weekly by v2x stakers with a healthy c-ratio.

## 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".-->

This proposal pauses the current buyback and burn SNX mechanism on Base introduced by SIP-345 and replaces it with fee distribution. Collected fees will be bridged to Synthetix v2 on Ethereum and Optimism and used to buy back sUSD from the open market. These sUSD tokens will then be distributed to stakers, who can claim them weekly if they maintain a healthy c-ratio. Unclaimed sUSD fees will roll over to the following week.

## Motivation

<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate. It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is inaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->

The protocol is shifting focus to v3 products and deprecating legacy long-tail spot synths, causing sUSD to experience an ongoing depeg from USD. Currently, v2 stakers have little immediate incentive to pay off their debt, aside from the threat of liquidation. A depegged sUSD poses potential capital losses for those holding sUSD, including perps v2 traders and other users of sUSD in the DeFi landscape (e.g., Thales, Aave, LPs).

## Rationale

By periodically purchasing sUSD on the open market using v3 fees, this proposal aims to support the sUSD peg directly. Additionally, by making the fees claimable only by stakers with a healthy c-ratio, it incentivizes stakers to buy discounted sUSD on the open market to pay off their debt.

<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

## Technical Specification

<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.-->

The Treasury Council will execute any necessary on-chain actions required by this proposal on a weekly basis.

### Test Cases

<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->

N/A

### Configurable Values (Via SCCP)

<!--Please list all values configurable via SCCP under this implementation.-->

N/A

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Loading