How Perp v3 works
Overview
With Perp v3, we have built something that’s better for traders, better for LPs and better for the ecosystem. Perp v3 offers four key unique selling points:
Flexible Liquidity Framework
There are many ways to trade perps onchain these days, with no clear winner yet. Previous and current generations of onchain perp exchanges rely on oracles for pricing, use AMM or vAMM models, or handle order matching offchain.
Perp v3 moves beyond this with a flexible liquidity framework that makes it easy to add new liquidity models quickly without having to rebuild the entire system. This lets Perp v3 provide:
Easier ways for new and casual users to trade and [Soon™️] provide liquidity.
Sophisticated ways for expert users and builders to trade and LP.
More flexibility for devs to integrate with, expand and build on top of Perpetual Protocol.
Liquidity and longtails
To start, Perp v3 will offer 2 liquidity provisioning methods, with more to come soon.
Oracle pricing for major, mature assets where robust oracle prices are available.
Spot-hedged liquidity pools let you trade new and niche assets that don't have a mature or readily available oracle price feed, as well as give arb traders new opportunities to cash in on slower moving spot markets.
[Soon™️] Smart Maker JIT-style liquidity that brings you the benefit of CEX-tier liquidity while giving you full custody of your funds for the entire lifecycle of your trade.
More to be announced...
Learn more in Liquidity Provision Strategies.
More performance
Perp v3 marks a big step forward in ease of use and performance, with the goal of matching and exceeding the CEX trading experience. This includes
2-click trades - no waiting for your wallet to open
Higher leverage, up to 50x and beyond
Fast price updates with pull-oracles from Pyth
More markets, including hot tokens
Not just an aggregator
Maybe you’re thinking, sounds like an aggregator. Well it kind of is, but with a major advantage.
An aggregator also aggregates risk from each platform where you have positions. No thanks. With Perp v3 you benefit from having all your positions under one roof, with one of the most credible teams in Defi:
High Lindy Effect
Doxxed team
Non-US-based
Building onchain since 2020
Fully non-custodial
How is this achieved?
Perp v3 is a modular platform that allows unprecedented flexibility for liquidity providers, traders and builders. It consists of
Multiple liquidity sources within the Liquidity Framework to find the best prices from multiple options.
A router that fetches the best prices from all sources for the trader.
The vault, router and clearinghouse smart contracts work together to execute trades, track user accounts and manage user funds completely onchain.
An offchain database holds signed orders and sends them to be executed after the front-running period (3 seconds) or, for limit orders, when the trigger price is reached.
All positions are backed by isolated margins using collateral from users' futures accounts (ie. Perp v3 vault).
How a trade happens
User enters order details (leverage, position size or value)
The Perp v3 router requests quotes from available Liquidity Strategies to find the best price
User confirms order which is signed using Session Keys (see Perp Smart Account)
The order is sent to the Order Gateway, which either executes the order after a safety delay (if applicable depending on the Liquidity Strategy) or stores the order for future execution (in the case of limit orders, etc.)
The order is executed
Market orders: by the clearinghouse and either
succeeds: the order went through; collateral is assigned to the position as margin, and the position is updated in the user's account;
fails: the order failed due to slippage; the user is notified and collateral is returned to the user's account.
Limit orders, etc.: when the user's trigger conditions are met, the order is retrieved from the offchain database and sent for execution;
succeeds (full fill): the order went through (see Market order above)
succeeds (partial fill): the order partially completed, and will continue to stay active until either filled or the order expiry date passes;
fails: the order failed due to slippage; the system will continue trying to fill the order when the trigger conditions are met.
Liquidity Framework Strategies
The liquidity framework integrates liquidity sources we're calling Strategies. The Perp v3 router will automatically get quotes from all available Strategies and choose the best price for you. At launch, two Strategies will be available: Oracle and Spot-Hedge.
Oracle Strategy
The Oracle Strategy is simple on the surface: LPs place funds in pools which provide liquidity for traders to trade using oracle prices. Perp v3 innovates on this model with dynamic spreads and a flexible fee structure that uses a borrowing fee similar to lending markets and, depending on the market, funding payments.
Initially we will work with Pyth, leveraging their pull-oracle price feeds to get the freshest prices exactly when traders need them. As other oracles with similar performance become available, we will look at integrating them as well.
Spot-Hedge Strategy
The Spot-Hedge Strategy employs hedging using onchain spot markets. This type of pool will allow LPs to benefit from automated market-making using prices from onchain spot markets. This has at least three benefits:
Any token with an onchain spot market can support a perpetual futures market, even before oracles are available.
Traders can arb spot prices if the market connected to the Strategy is lagging other markets.
LPs market-make in a delta neutral way, so every trade is hedged atomically in the same transaction as it is executed.
Perp OGs familiar with Hot Tub will notice this sounds familiar for a reason: this is an extension of the same vault tech that Hot Tub is based on.
Future
Perp v3's liquidity framework allows a high level of flexibility when designing and implementing more ways to provide liquidity. Look forward to more in the future. We also welcome your ideas! Contact us
Trader-facing components
Relay & Gateway
The gateway seeks the best path to execute a trade by evaluating the status of liquidity sources for the requested asset. This works in a similar way to routers used by Uniswap, 1inch and other spot DEXs.
Once the path is found and the transaction is signed by the user, the gateway sends the transaction to the blockchain and pays the gas fee.
The gateway also handles the system-imposed 3 second delay for oracle-price trades to protect against attempts to frontrun the oracle. This is a common delay in any oracle-based trading system, and is designed to prevent traders from being able to reliably frontrun oracle price updates.
If a significant price change occurs during this delay and your slippage settings are exceeded, you will be notified that the transactions was cancelled (reverted).
Clearinghouse
All positions are recorded in the clearinghouse, and each position's state (size, notional value, margin, fees due/owed, etc.) is recorded and updated here. Margin for each position is held by the clearinghouse. Position PnL, margin ratio, liquidation conditions, etc. are determined by the clearinghouse.
Futures Account (Vault)
All funds needed to place trades must be deposited into the trader's futures account. When a trade is placed (position is opened), collateral is moved from the futures account to the clearinghouse, where it serves as the position margin. When a position is closed, margin is returned to the futures account, and can be used to back new positions or withdrawn to the trader's wallet.
Actions such as add margin and remove margin update the user's account so that funds in their futures account are allocated to a specific position.
P&L Pool
All position P&L flows via the P&L pool between being realized and returning to the trader's futures account. This ensures all profits earned by traders have corresponding losses from other system participants, as well as helping guard against exploits and attacks that might withdraw outsize profits.
Before allowing a trader's P&L to be moved to their futures account, the P&L pool ensures there is enough margin available in the system to allow withdrawal, as well as checking that the trader's account does not have bad debt.
Unclaimable P&L
In some cases, profits may not be claimable right away if a significant amount of other traders' losses have not been realized. In this case, it may be necessary for losses to be realized before your profits are unlocked.
While in the P&L pool, profits are realized and guaranteed to be claimable once losses are claimed.
Order fulfillment
| Order type | Notes |
|---|---|
Market order | Market orders are 'fill or kill'. Either they are 100% filled, or they are killed and there is no change to your account. A typical cause for an order to be killed is your slippage tolerance being exceeded. |
Limit order | Limit orders may be partially filled and generally will not be killed until the order is fully filled. Limit orders may be killed if the remaining order size is below the min. order size after partial fill. |
Funding rate and payments
Depending on the market, traders may pay or earn premiums, called funding payments in perpetual contract terms, to hold a position.
In Perp v3, funding is paid according to:
Open Interest (OI) skew - if long OI exceeds short OI, longs pay shorts; if short OI exceeds long OI, shorts pay longs.
Funding rates based on point 1 above, updated every block (15 seconds).
Funding payments based on point 2 above, to the nearest second that a trade is open. So if a trade is open for 60 seconds, the aggregate funding rate during those 60 seconds will be used to calculate the funding due or owed for that position.
Funding payments are tracked by the clearinghouse and settle when updates to the position occur (close, add/remove margin, liquidation). Funding payments are made directly to/from the position margin.
LP-facing components
Oracle-price LP pools
This pool type became popular in 2022, quickly becoming a trader favorite thanks to easy-to-understand pricing and spreads, as well as simple LP options compared to Uniswap v3 and Perp v2.
Perp v3 establishes a liquidity pool for each asset that uses oracle price, and all trades using this liquidity option are filled according to the current oracle price plus a dynamic spread based on open interest skew (the relative balance of longs vs shorts in any given market).
To prevent oracle frontrunning, all trades are delayed by 3 seconds before they can be executed.
Spot-hedge LP pools
This is a novel pool type based on the Hot Tub product launched by Perpetual Protocol in early 2023. Hot Tubs perform automated arbitrage between a perpetual futures DEX and onchain spot markets, for example buying an asset and shorting the asset's futures contract when the two diverge, and reversing the process when prices return to the same level.
In Perp v3, a similar method is used to provide a counterparty to traders. When a trader places a trade, the opposite trade is taken on the spot market via the automated vault.
There are several benefits of such a system:
Relative lack of reliance of outside oracles, meaning markets can launch as soon as there is a reasonable level of liquidity onchain.
Multiple onchain spot markets can be used at the same time by leveraging aggregators such as 1inch.
LPs earn yield in a similar way to Hot Tub users, so rather than facing impermanent loss in an unhedged liquidity pool, LPs provide and earn in one token, including stable assets in the case of quote vaults (e.g. USDT denominated vaults).
As with Hot Tub, spot-hedge pools are deployed in pairs:
QuoteVault containing liquidity in a stable asset (the quote asset)
BaseVault containing liquidity in the underlying asset (the base asset).
Long positions are opened using the QuoteVault (spot-hedge pool buys the spot asset), and short positions are opened using the BaseVault (spot-hedge pool sells the spot asset).
Funding payments for LPs
Currently makers/LPs do not pay funding on Perp v3.
Fee and Spread Calculation
Fees
For actual fees, see Fees & system limits
Taker fees
Relayer fee
A flat fee is paid in USDT for each trade to cover gas. This fee is bundled in the price of each trade, and paid from your futures account.
Relayer fees apply to market orders, limit orders and close position.
Protocol fee
0% initially. This fee may be charged at a later date.
Borrowing fee
This fee is paid continuously as long as the position is open.
The fee is based on the utilization ratio of the liquidity used to open the position. The higher the proportion of liquidity in a Strategy is used, the higher the borrowing fee will be.
Borrowing fees for longs and shorts will be different.
Borrowing fees are based on the position's open notional (USD value at the time the position is opened).
Borrowing fees can be 0 but not negative (ie. traders cannot receive borrowing fees).
Funding fee
Some markets may have funding fees, paid based on the ratio of longs to shorts (ratio of long open interest and short open interest).
Maker / LP fees
Makers aka LPs always earn fees - you never pay a fee as a maker or LP.
Coming Soon™️ 🏗️ At launch, Perp v3 is limited to whitelisted makers only. Once the liquidity framework model has been proven, Strategies will be opened to users to add liquidity permissionlessly.
Oracle Strategy spreads
Spreads are calculated dynamically based on the ratio of longs to shorts. For detailed information, see Oracle Maker Pricing.
Spot-hedge Strategy spreads
Spreads in spot-hedge pools are based on spot liquidity, pool liquidity, plus the borrowing fee. This makes it highly dynamic, and it is therefore recommended to take quotes directly from the UI or from the Quoter contract.
Other Strategy spreads
Each Liquidity Framework Strategy has its own risk considerations relating to liquidity provisioning, and therefore has its own spread mechanism. Details will be published as new Stategies are researched and deployed.
Liquidation
For maintenance margin ratios see Perp contract specs
Liquidations are based on position value according to index prices (oracle prices). This includes positions opened in spot-hedge pools, where spot TWAP or other oracles may be used.
Taker liquidation
Liquidations occur when the value of the position and the value of the underlying margin reach a set ratio: the maintenance margin ratio (MMR). If the ratio of position to margin falls below the MMR, the position will generally be partly liquidated in such a way that leaves the margin ratio above the MMR. Please see Perp contract specsfor the MMR of each market.
Partial liquidation conditions
Perp v3 supports partial liquidations for positions in order to minimize the impact on traders. If the margin ratio is between the MMR and 0.5 x MMR, the liquidator must perform a partial liquidation. If the margin ratio is below 0.5 x MMR, the entire position may be liquidated. (E.g. if MMR is 5%, as long as the margin ratio is between 5% and 2.5%, partial liquidation will be used.)
Liquidators
Liquidators monitor position health and call the clearinghouse liquidation function when the position appears eligible for liquidation. The clearinghouse evaluates the state of the position and permits or denies the liquidation call.
If the liquidation is permitted, the position is partly or completely liquidated depending on the position size and margin ratio. The trader pays a liquidation penalty from the position margin, which is first paid into the P&L Pool. This penalty is then added to the liquidator's unrealized PnL as a reward which the liquidator can realize via the P&L Pool. The liquidator also takes control of the liquidated portion of the position, with a discount, and may choose to close or hold the position.
Maker/LP liquidation
It is possible to provide liquidity with leverage in some pool types, and a minimum margin ratio is enforced by each pool. If a maker's margin ratio falls below the minimum, liquidators can liquidate the position.
Liquidation penalty
50% of the liquidated margin is awarded to the liquidator
50% of the liquidated margin is retained by the #pnl-pool
Last updated