SIP-279: Perps v2
Author | |
---|---|
Status | Implemented |
Type | Governance |
Network | Optimism |
Implementor | Leonardo Massazza (@leomassazza), MEB (@barrasso) |
Release | TBD |
Proposal | Loading status... |
Created | 2022-09-27 |
Simple Summary
This SIP proposes a redesign of the Synthetix perpetual futures mechanism to support (1) unconstrained open interest limits, (2) broader asset compatibility, and (3) efficient execution.
Abstract
Core upgrades include a premium/discount pricing function that adiabatically collects and distributes premium along a path invariant curve in skew space, as well as a velocity-based funding rate model that is also zero-sum and path invariant in funding rate space. Challenges related to oracle latency are also putatively mitigated via price feeds with decentralized oracle networks that update off-chain with on-chain verification.
Motivation
The current Synthetix perps market design is highly constrained in terms of scalability and efficiency. The most notable limitations pertain to capital inefficiency (restrictive open interest limits), weak risk management incentives, funding rate instability, and high fees / wide spreads.
Specification
Overview
There are three high level improvements proposed here: (1) premium/discount pricing function, (2) funding rate velocity model, and (3) on/off-chain hybrid oracle implementation. (1) can be implemented through a simple change to how exchanges are priced. Instead of quoting a pure oracle price, markets would instead quote oracle_price + premium
where premium
is directly proportional to fractionalized skew. (2) can be implemented via modification to funding rate calculations where fractionalized skew dictates the instantaneous funding rate velocity rather than instantaneous funding rate. (3) requires relatively minimal contract changes that will be outlined in a separate SIP but touched upon at a high level here.
Rationale
Restrictive open interest limits are a symptom of inefficient risk management. While proportional skew funding provides a non-zero incentive to balance debt pool risk, it has proven generally ineffective. Notably, there are two primary limitations of this model. One is that while the intention is optimize for balanced open interest, there is no incentive to completely offset exposure as funding would instantaneously disappear without "memory" of prior imbalances. Additionally as Synthetix perps markets reach equilibrium with external markets, risk does not necessarily converge to zero (e.g. hard-to-borrow assets with perpetually negative funding for an extreme illustration). Lastly, funding rates that are instantaneously proportional to skew also present UX challenges in the form of volatile/unpredictable funding rates.
Premium/discount function
The architecture outlined in this SIP takes a layered approach to risk management. Rather than leaning exclusively on funding payments to limit LP risk, a skew-dependent premium is applied to prices quoted by the market (premium for long skew, discount for short skew). By storing premium from takers (expanding skew) to adiabatically distribute to makers (compressing skew), this mechanism creates a high frequency rebalancing incentive while also placing soft limits on maximum exposure held by the debt pool (without the need for explicit restrictive OI limit). Simulating price impact in this way also increases compatibility for assets with a wider range of liquidity profiles and protects LPs from market manipulation.
Funding rate velocity
This model represents a mathematically minor adjustment to the current system, but with significant implications to the overall mechanism. Put simply, instead of r = c * skew
, instead we have dr/dt = c * skew
. In practice, the effect of this change is that funding rates will continuously drift higher/lower in the presence of uncorrected position imbalances, creating a natural price discovery mechanism for funding rates while simultaneously smoothing out funding rate trajectories. Another notable change is that with this mechanism, LPs would no longer exclusively earn funding (e.g. short skew + positive funding, LPs pay funding). Instead, funding flows through LPs without gain or loss over time (i.e. can be mathematically shown that net funding earned by LPs over time is zero). See plots below illustrating debt pool earning funding when dr/dt > 0
while paying equal and opposite funding when dr/dt < 0
Hybrid oracle approach
This approach creates multiple execution tiers: (1) traditional execution through purely on-chain oracle, (2) asynchronous execution through on-chain oracle, or (3) asynchronous execution using off-chain oracle network whose validity is verified on-chain. Tier (1) is superior in composability, while tier (3) is superior in performance and execution efficiency (tier (2) is somewhere in between). With signed price updates made available off-chain, on-chain costs are only incurred when an exchange is made thus improving cost sustainability while also improving liveliness.
Technical Specification
Premium/discount function
A single configurable variable, skewScale
, is used to modulate market liquidity via a linear premium/discount curve represented as premium = skew / skewScale
. When a trade is made, the price is pushed from point A to B along the linear curve. Thus, the actual execution price can be represented as the average price along the curve. For a linear function, the integral can be simply represented as executionPrice = oraclePrice * (1 + 0.5 * (premium_before + premium_after))
.
Funding rate velocity
This function controls how quickly funding rates change when skew is uncorrected using the skewScale
variable along with maxFundingVelocity
, which represents the funding rate velocity when skew = skewScale
(in practice, the premium/discount function limits skew to roughly <1% of skewScale). In the context of funding rate calculations, skewScale
fractionalizes skew which is then normalized to maxFundingVelocity
. Every time a trade is made, the average funding rate since the last trade can be interpolated using the velocity after the last trade and the time elapsed in between. When positions on both sides of the market are balanced, funding rates are at rest wherever the neutralizing trade was made.
Hybrid oracle orders
The proposed implementation is highlighted more in SIPs 281 and 285, but a high level overview will be provided here. Due to the intrinsic latency of any external price source, the most practical option is to settle orders asynchronously; that is to say:
- user queues market order
- configurable minimum delay period elapses
- keeper retrieves most recent off-chain price update
- keeper updates on-chain price on-demand and confirms user’s order
Note that Synthetix contracts would enforce that ΔT between (1) and (4) is sufficiently delayed. Delay thresholds can be configured via SCCP, but would likely be set to ~12 seconds initially (roughly equal to Ethereum L1 block time). In other words, the off-chain timestamp from the price update used to confirm the order must be during the L1 block epoch immediately after the order was queued, which would result in an average realized settlement delay of 6 seconds. In the future when L2 blocks are produced more regularly with native timestamps, this delay threshold can likely be shortened considerably.
Test Cases
Premium/discount function ETH/USD long order
ETH/USD oracle price
= $2000longOI
= 500 ETH,shortOI
= 400 ETH,skew
= 100 ETHskewScale
= 10^6 ETH- User longs 100 ETH
premiumBefore
= 0.0001 ,skewAdjustedPrice
= $2000.2premiumAfter
= 0.0002 ,skewAdjustedPrice
= $2000.4executionPrice
= 2000 * (1 + 0.5 * (0.0001 + 0.0002)) = $2000.3
Funding rate velocity ETH/USD long order
ETH/USD oracle price
= $2000longOI
= 500 ETH,shortOI
= 500 ETH,skew
= 0 ETHfundingRate
= 0% / day,fundingRateVelocity
= 0% / day^2skewScale
= 10^6 ETH ,maxFundingVelocity
= 300%- User #1 longs 100 ETH (200,000 sUSD)
longOI
= 600 ETH,shortOI
= 500 ETH,skew
= 100 ETHfundingRate
= 0% / day,funidngRateVelocity
= 0.03% per day- 24 hours, user #2 shorts 100 ETH
longOI
= 600 ETH,shortOI
= 600 ETH,skew
= 0 ETHfundingRate
= 0.03% / day ,fundingRateVelocity
= 0% / day^2- User #1 accrued funding = 200000 * 0.5 * (0% + 0.03%) = 30 sUSD
Configurable Values (Via SCCP)
skewScale
maxFundingVelocity
Copyright
Copyright and related rights waived via CC0.