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.
\nCore 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.
\nThe 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.
\nThere 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.
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.
\nPremium/discount function
\nThe 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.
\nFunding rate velocity
\nThis 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
\n
\n
\nHybrid oracle approach
\nThis 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.
\nPremium/discount function
\nA 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
\nThis 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
\nThe 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:
\nNote 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.
\nPremium/discount function\nETH/USD long order
\nETH/USD oracle price = $2000longOI = 500 ETH, shortOI = 400 ETH, skew = 100 ETHskewScale = 10^6 ETHpremiumBefore = 0.0001 , skewAdjustedPrice = $2000.2premiumAfter = 0.0002 , skewAdjustedPrice = $2000.4executionPrice = 2000 * (1 + 0.5 * (0.0001 + 0.0002)) = $2000.3Funding rate velocity\nETH/USD long order
\nETH/USD oracle price = $2000longOI = 500 ETH, shortOI = 500 ETH, skew = 0 ETHfundingRate = 0% / day, fundingRateVelocity = 0% / day^2skewScale = 10^6 ETH , maxFundingVelocity = 300%longOI = 600 ETH, shortOI = 500 ETH, skew = 100 ETHfundingRate = 0% / day, funidngRateVelocity = 0.03% per daylongOI = 600 ETH, shortOI = 600 ETH, skew = 0 ETHfundingRate = 0.03% / day , fundingRateVelocity = 0% / day^2skewScale\nmaxFundingVelocity
Copyright and related rights waived via CC0.
"}},"pageContext":{"id":"04f2ed2b-9083-5996-b5b3-b13a8c7f8945","frontmatter__sip":279,"__params":{"frontmatter__sip":"279"}}},"staticQueryHashes":[]}