SNXweave Weekly Recap 49
July 26, 2022
The following post contains a recap of news, projects, and important updates from the Spartan Council and Core Contributors, as well as the Grants Council and Ambassador Council from last week.
Spartan Council and SIP updates
Present at the July 21, 2022 Spartan Council Weekly Project Sync:
Spartan Council: Afif, Ale, Burt Rock, ksett, SynthaMan, TerraBellus
Core Contributors: Cavalier, db, KALEB, Steve, Sunny, Mark
Let’s get right into it! V2X is still being wrapped up, with a couple of SIPs currently in audit: SIP-252, to allow the liquidation of escrowed SNX, and SIP-258, to incorporate directionality in the pricing of atomic swaps. 258 is top priority and is expected to be on Mainnet this week.
The Council also discussed some SCCPs. SCCP-218, which will update the ETH wrapper parameters, has been modified. It will now raise the cap by 2,500 ETH instead of 2,000, and the fee will be updated to 50 basis points. This is being done due to the recent premium seen on the sUSD peg, and the debt increase incurred by stakers due to short exposure to ETH.
SCCP-301 was proposed by TerraBellus to set the Spartan Council’s minimum active members setting to n-4, where n represents the Council’s current seat count. This means that, should the situation call for it, a Council member can be dismissed without forcing an election that could revert any dismissal. The SCCP also further defines the conditions allowing a valid meta-governance vote by specifying that a unanimous decision among non-dismissed council member meets the necessary criteria. TerraBellus said he proposed this SCCP as a result of SCCP-300 not passing, and Ale suggested it be proposed as a full SIP instead.
The Council further discussed the question of how many members it should take to pass a meta governance proposal. Ksett brought up the fact that any pDAO members also sitting on the Spartan Council breaks the decentralization/separation of power, and therefore opens another possible attack vector. There was some consensus that it doesn’t necessarily need to be unanimous, and some agreement that maybe n-2 would be an acceptable compromise.
Terra also brought up the issue surrounding the delay in c-ratio increases between L1 and L2. There is a technical limitation that prevents a single action on two separate networks to be approved in one transaction. As a result, the c-ratio on L1 stayed at 350% a bit longer. It turns out there was actually no advantage, but there was still agreement that the issue should be resolved so that something like this doesn’t happen in the future.
After the Spartan Council meeting, there were also several SIPs that were discussed, so let’s briefly review them:
SIP-255: Burn fees instead of distributing them
- Presented by db, this SIP proposes burning fees collected by the fee pool instead of allowing them to claim the fees and have it transferred to them. This will have the effect of reducing user’s debt overall, and in theory they will be able to mint more at a later date.
- He explained that the SIP was written in response to concerns that one-way flow of fees to current network imbalances would not be equitable. Burning the fees is a more effective way to distribute fees to all stakers
- Afif brought up that he would still want to somehow display how much sUSD benefit stakers were getting as a result of this improvement, but db said that would require significant changes for the UI to be able to track these distributions
- Db: “One of the biggest concerns with this proposal is that stakers with lower c-ratios would receive a larger portion of the burned fees.”
- This may create an undesirable incentive for users to keep c-ratios low if inflationary rewards dropped significantly
- Afif: “The real solution to this problem is to make liquidation punitive enough that it’s not worth it for users to be that close.”
SIP-259: Overflow in Issuer when `rateStalePeriod` > current unix timestamp
- Db also presented this SIP, explaining that there is a bug in Issuer that causes a subtraction overflow when the rateStalePeriod setting is set greater than the current timestamp.
- To prevent issues when running tests, this SIP will fix the code so that it will allow any timestamp if rateStalePeriod is greater than current timestamp.
- This isn’t a super significant security risk, but it’s a code improvement that protects the protocol from a scenario where the rateStalePeriod setting is a time in the past
SIP-260: Rate limiting
- This last SIP that db presented proposes reducing the impact of a possible security breach in the bridge by implementing a simple rate limiting functionality on all transfers processed by the bridge. Essentially, a system for limiting the amount of transfers a bridge can process.
- The rate limiter will only allow a certain number of transfers over a given time period
- The rate limit period and amount usable will be SCCP configurable parameters
- For non-attacker transfers, this would effectively put a limit on how much sUSD could be transferred in a single transaction
- The SC will be reviewing some more of the data in the SIP to set more accurate limits
- Ale also added that this adds complexity to V2X scope unnecessarily, which is limiting V3 resources
SIP-262: Create Perps Markets for XMR and DOGE
- Burt proposed this SIP, which will offer XMR-PERP and DOGE-PERP futures markets
- This SIP originally also included ETC-PERP, but the Council asked that it be removed based on majority feedback
Present at the July 21, 2022 Grants Council meeting:
Grants Team: ALEXANDER, CT, JVK, Mike
In Grants Council updates, the team had a call with some of the Kwenta guys last week to discuss the margin matching initiative. They discussed some of the incentives that Kwenta is planning, with a focus on bigger trades (generating $1million notional volume). They want to see users taking advantage of the value that zero slippage adds to a trading experience. The team will be vetting users for high-quality traders who have done heavy volume on other exchanges as well, and Kwenta will be submitting a formal request for voting.
The Council also discussed a few other ongoing initiatives, including:
- UI work is still in progress
- Team is waiting for follow up from Jade
- Gabriel has published his explainer video — check it out in our here!
- 0x had originally asked for a grant to integrate, but it looks like they’ve moved forward with their integration without the grant
- Paraswap is also working on an integration (also moving forward without a grant)
Hero Stats page
- 300 is running a task for review and feedback
Present at the July 19, 2022 Ambassador Council meeting:
Ambassadors: mastermojo, MiLLiE
Lastly, in Ambassador Council updates, the team has a Spartan Space scheduled for today at 3pm ET with Kwenta! So be sure to tune in for a great call. The Ambassadors also have several more Spaces lined up for the coming weeks.
Also, the UNI proposal that the Ambassadors submitted has been executed! The 1bp fee tier is now live on Optimism. This fee tier is ideal for short tail stable coins and pegged tokens, and should benefit all Optimism protocols with liquidity and LP incentives.
The team is also coordinating with the Grants Council to get their help in creating the Ambassador Council website. This is so that the Synthetix design aesthetic can be maintained across all of the websites — so it will likely be the same team that built and manages the Grants site.
Podcast now also on YOUTUBE
SNXweave Anchor Podcast: https://anchor.fm/snxweave
Follow us on Twitter! @snx_weave
SIP/SCCP status tracker:
SIP-252: Liquidation of SNX Escrow, Status: approved
SIP-258: Trade Directionality In Pricing of Atomic Swaps, Status: approved
SCCP-218: Update ETH Wrapper Parameters, Status: vote pending
SCCP-301: Set Spartan Council minimumActiveMembers to n-4, Status: rejected
SIP-255: Burn fees instead of distributing them, Status: vote pending
SIP-259: Overflow in Issuer when `rateStalePeriod` > current unix timestamp, Status: vote pending
SIP-260: Rate limiting, Status: vote pending
SIP-262: Create Perps Markets for XMR and DOGE, Status: vote pending