SIP-257: Debt-ratio futures market

Summary

Create a futures market for Synthetix debt share price (debt ratio) for capital efficient debt-hedging.

Note that this not for the total amount of debt, but for the debt-share relative "price" (debt inflation / deflation).

Abstract

Debt-ratio tracks the degree to which the stakers' debt increases or decreases relative to their initial debt.

A Chainlink oracle for the debt-ratio is already part of the debt system (SIP 165). A futures market will create a more efficient market for debt hedging and will keep more of the hedging fees in the protocol.

Motivation

Pros:

• Allows some stakers to hedge debt easily and capital efficiently for a premium (funding rate payments). Advantages over directly using dSNX are:
  • Full hegding (e.g. inflation due to front-running losses is hedged, futures markets debt is hedged).
  • Capital efficiency (due to available leverage).
  • Simplicity (on same platform - L2 Optimism Kwenta).
• Allows other, more sophisticated traders, to profitably hedge the first group externally (dHedge-dSNX or otherwise). This group would arbitrage the funding rate (short the debt on perp, and long debt externally). These traders would be able to earn funding from the first group (for the actual hedging).
• Creates an additional useful market for protocol users.
• Divert fees from external hedging internally (back to stakers).
• Decouples the roles of stakers (willing to take on debt & SNX exposure) from "hedgers" (willing to hedge the debt for a profit with no exposure).
• Creates a better hedged debt pool (because more people hedge because it's simpler, and hedging is more efficient because of specialisation).

Risks and mitigations:

• Additional higher order debt sensitivity: when the skew is positive, when debt goes up, stakers hedged via perps are in profit, which increases the debt some more:
  • This effect depends on the ratio of the skew to the total debt. E.g. in case of 1M skew, and 100M debt, a sudden spike of even 10% is debt-ratio (+10M, not due to minting), would result in 1.01010% (+101k USD) additional debt increase (sum of infinite geometric series with r=0.01). With the parameters suggested below, the funding payments would be 22k per day (which would make such a skew unsustainable for any stretch of time, and profitable in 5 days, even for these extreme circumstances).
  • To counteract this, the funding rate parameters need to be set in a way that ensures that the skew small enough to not create a large increase factor. Sensitive funding parameters will both compensate the debt pool (and reduce the total debt), or ensure that the arbitrage is profitable (also reducing the skew).
  • Intially the OI caps will allow to set a hard-limit on the possible skew, but with time they can be scaled up if needed and the skew is properly controlled by funding.
• Front running risk (naive): debt-ratio rate moves with smaller changes (compared to crypto asset prices) because is essentially a composite index (that's also heavily weighted with a stable-coin) so will be easy to protect from front-running with moderate fees.
• Front running risk (via other assets): a front-runner that can reliably front-run via another Synthetix trade (e.g. another futures market, or spot exchange) will also increase debt-ratio as a side-effect (due to extracting value from the protocol), so in theory is also able to make a profit from the debt-ratio market change. However, the primary front-running will have higher ROI (than the secondary), so it will make sense to utilize all the capital in the more profitable one (the primary) rather than in the secondary (the attenuated debt-ratio).
• Debt-ratio spikes (block to block) can be seen in this Dune query (click "Line chart" tab).

Parameters:

• Defensive initial parameters: 1M OI caps, 5M SkewScale, 60bps fees for taker/maker (to discourage FR), 15bp fees for next-price taker/maker.

Risk management plan:

• Adjust parameters to prevent risks above by actively monitoring (as the rest of markets) market KPIs.
• Retire market if not viable.

Specification

The current debt-oracle has 27 decimal values. The current ExchangeRates contract only accepts up to 18 decimals.

• Modify ExchangeRates contract to safely accept larger decimal values. This change will need to be done on both layers

even though the change is only needed for Optimism, this is in order to keep ExchangeRates implementations the same.

Alternative options for the decimals issue that are possible but require more effort:

• Deploy an additional CL oracle with 18 decimals as the rest of the feeds and update dependant contracts. Touches multiple contracts, requires additional feed.
• Deploy an oracle adapter that will read from existing CL oracle, and adjust the precision and decimal value to 18. Requires a new contract.

Copyright

Copyright and related rights waived via CC0.