On-chain derivatives have evolved over the years. Perpetual Swaps were introduced in 2016 by BitMEX. From then, it has gone through multiple iterations and reached PMF in the industry.
According to the data from The Block, DEX to CEX futures trading volume is around 7%. It has seen an upward trend, which reflects the growth in this DeFi vertical. This growth should be attested with knowledge about how these protocols work, their architecture, and an understanding of the possible attack vectors.
This post outlines the perpetual derivatives protocol's architecture, different liquidity models, and possible security vulnerabilities. We’ll be starting with the fundamentals of leverage, liquidation, market makers, and order books, then explore protocol classifications and move towards a security-focused perspective at the end.
Key Fundamentals in Perpetual Derivatives Protocols
Before diving deep into the derivatives protocol’s classification, let’s focus on understanding the fundamentals around key terms.
Perpetuals
Perpetuals are a type of futures contract that doesn’t have an expiry date. Like futures, it helps users to speculate on the price of a certain asset.
Users can either open a long or short perpetual position, reflecting whether they think the price of an asset is going to go up or down, respectively.
Leverage
Leverage is an important component of perpetual contracts. Users can opt to increase their risk exposure to a certain asset by using it. Users can simply deposit initial collateral or margin and take a leveraged trade upon it, effectively increasing their position size.
With the increased position size, traders are effectively borrowing the remaining capital apart from their initial margin, which adds up fees and risk.
Liquidity Providers (LPs)
Liquidity Providers as traders are important for a good perpetual protocol’s flywheel. The capital borrowed by the trader comes from LPs. In return, LPs earn a part of the fees, which acts as an interest earned on the liquidity provided, also called APY (Annual Percentage Yield).
LPs are always on the opposite side of the traders, which means when traders lose money, they make money; conversely is also true.
Liquidity Pools
Liquidity Pools store the liquidity provided by LPs and accrue interest on the deposited assets through fees.
OI (Open Interest)
Open Interest is the sum of the notional value of all the long and short positions opened in the exchange.
Long OI is the sum of the notional value of all the long positions opened on the exchange; conversely, true for short OI.
Protocols generally have a limit on OI based on the liquidity available in the pools.
Funding Rate
Perpetual markets are usually imbalanced between the short and long sides. If a market is continuously going up, users might be opening more long positions than short positions. This deviates the price of the perpetual contract from the spot prices.
In order to balance these markets, protocols utilize funding rates, in which the side having the larger OI pays to the smaller, which acts as an incentive to open trade on the opposite side.
There are two types of Funding Rates, which are called Positive Funding Rates, when the long OI > short OI, and Negative Funding Rates, when the short OI > long OI. When these rates are positive, the price of the perpetual contract is above the spot price, which means the long side pays the short side, and conversely is also true. Funding rates are calculated at regular intervals, usually in 8 hours.
Market Makers
Market Makers are not necessarily used by every perpetual protocol, depending on their market-making model, as some utilize AMMs (Automated Market Makers). Market making is a protocol to secure the liquidity in any particular market. One goal of market makers is to keep the market liquid enough and provide the best possible prices with the least slippage.
Orderbooks
Orderbooks, as the name suggests, store a list of user orders that are executed when the asset reaches a certain price. It acts as a source of liquidity and an order matching engine based on the protocol’s design.
Makers and Takers
Maker's orders are stored in the Orderbook, hence promoting a more liquid market. They pay a maker fee to the exchange.
Takers are the traders who execute the trade at the market price, and makers are the traders who execute the trade when an asset hits a particular price, also known as limit orders. Takers pay a taker fee to the exchange, generally higher than maker fees.
Stop Loss and Take Profit (SL/TP)
These are more of the features in an exchange, as users can choose when they want to drop a position based on the loss or the profit, depending on their risk appetite.
Liquidation Price
Calculating the liquidation price is important before opening any position in the exchange. Every exchange has its own way of calculating this price, depending on the fees it charges and other risk parameters.
The liquidation price of a position depends on leverage, position size, fees, and the initial collateral a user provides.
Let’s understand this with an example:
- The user opens a long position on ETH with $1000 as collateral and 5x leverage, making the position size $5000.
- The entry price (price of the asset when the position was opened) was $2600.
- The loss buffer before liquidation happens on exchanges ranges between 0.4%-1% of the position size. So, considering it is 0.5%, the buffer would be $25.
- Using the above formula, the loss would be
(2600 - P) * (5000/2600). The variablePhere is the liquidation price. - Subtracting the loss from the initial collateral and equating it with the buffer would provide the liquidation price.
6. Solving for P would get us the value of ~ $2066, which is our liquidation price.
Insurance Funds
Insurance funds are more common in the exchanges that use a Central Limit Orderbook (CLOB) model. Insurance funds are utilized where an exchange suffers from an external attack, like a smart contract hack, bad debt, etc.
Slippage
Slippage is the difference between the price at which the trader wants the order to be executed and the actual price at which the trade gets executed.
The formula to calculate the slippage percentage:
Understanding Classification of Perpetual Derivatives Protocols
Now, since we have covered the fundamentals, we can dive into the classification of derivative protocols based on different categories.
Liquidity Source
Derivatives Protocol can source liquidity from multiple avenues, depending on the architecture it follows. They can source it from liquidity providers, orderbooks, or rather consider a hybrid approach using both of them. This section explores different liquidity sources a derivative protocol can utilize.
Pool-Based Model
Protocols like GMX, Jupiter fall under this category. Pool-based protocols source liquidity from Liquidity Providers (LPs). LPs provide this liquidity and earn interest on their provided liquidity, also called APY (Annual Percentage Yield). This yield is generated from the fees paid by the traders like borrowing fees.
Pool-based protocols have the following fees involved:
- Borrowing Fees: The fees paid by the traders to borrow liquidity from the liquidity pool. The borrowing is dynamic, depending on the Utilization Rate of a particular pool.
- Funding Fees: Funding fees are calculated at regular time intervals and paid between long and short positions.
- Price Impact Fees: These fees are paid by either LPs or Traders, depending on whether they are imbalancing the pool. A balanced pool would have equal amounts of tokenA and tokenB, or if having multiple tokens, then paid if the risk parameters are passed.
- Liquidation Fees: These fees are taken if the position needs to be liquidated. Positions are liquidated if the market hits the liquidation price of the position.
- Protocol Fees: These are the fees charged by the protocols, like open/close position fees.
Protocols like GMX involve various keepers handling different components of the business. Moreover, a fee is also paid to DAO/Treasury utilized for incentives, token buybacks, and more.
Note: The above image is for representational purposes only and does not reflect the exact architecture or functioning of any specific protocol
Central Limit Orderbook (CLOB) Model
Central Limit Orderbook (CLOB) model sources its liquidity from the orderbook. Users usually place orders that are filled by the matching engines. The matching engine job is to fulfill the user’s orders by creating an orderbook with enough depth. These orders can be placed by other users, market makers, or algorithms, which keep the liquidity deep and provide the least possible price impact and slippage to the user.
CLOB-based model also has similar fees, but there is a different fee, called maker/taker fees, which are explained above. Hyperliquid also utilizes CLOB. CLOB models have their own pricing engine, as orderbooks are an on-chain price discovery source.
Note: The above image is for representational purposes only and does not reflect the exact architecture or functioning of any specific protocol
Hybrid Model
The Hybrid Model, as the name suggests, sources liquidity from both the AMMs and CLOB to provide the best possible order execution to the users with the least slippage.
Drift protocol is a great example of a Hybrid Model as it sources its liquidity from orderbook, market makers, and AMMs.
Liquidity Management
There are mainly two types of liquidity pool management: one is pooled and the other is isolated. Both serve their own set of users. Pooled Liquidity Model gives exposure to multiple assets, while isolated pools limit exposure to a certain asset.
Pooled Liquidity Model
Pooled liquidity is offered by protocols like Jupiter as users provide liquidity in a single pool. This pool holds multiple assets and is the single source from which the funds are borrowed. This pool earns fees from traders and accrues in value.
In the case of Jupiter, they provide a liquid tradable token like JLP (Jupiter Liquidity Provider) to provide liquidity in the exchange. JLP increases in value over time as it accrues value through fees on the exchange.
Isolated Liquidity
Isolated Liquidity is the design popularized in GMX V2. Liquidity Providers can provide liquidity to these isolated pools, which provide them exposure to the asset of their choice. The isolated risk model helps users to limit their risk exposure.
In GMX, traders can provide liquidity in GM (GMX Markets) of ETH, BTC, SOL, and more. The OI limit is decided based on the liquidity in a particular market. Though GMX also provides markets like GLV (Global Liquidity Vaults) that have exposure to different assets and can be classified under the Pooled Liquidity Model.
Market Types
Market types can differentiate the markets based on the assets backing the position. If the assets backing a position would move at the same velocity as the asset user longed, then the position is fully backed otherwise, it is not.
There are three types of tokens in a market:
- Index Token: These are the tokens that users usually long or short. Suppose a user wants to speculate on the price of ETH; then ETH is the index token.
- Long Token: Long Token is the asset backing the long position.
- Short Token: Short Token is the asset backing the short position, usually stablecoins.
Fully Backed Market
Fully backed markets are the markets where the market index token is equal to the market long token. This means if a trader wants to speculate on the price of ETH, their collateral is also stored in ETH, meaning if the value of ETH goes up, the collateral value also goes up, and the positions can be fully paid out during the settlement.
Synthetic Markets
Synthetic markets are markets where the long token is not equal to the index token. Positions opened in these markets are not necessarily fully backed. Suppose a user is opening a PEPE long position, and the backing asset is not PEPE but ETH. So if PEPE outgrows ETH in value during high volatility, then the position cannot be fully paid from the ETH.
To mitigate such situations, protocols like GMX utilize ADL (Auto-deleveraging). ADL partially or fully closes the positions if market conditions are highly volatile.
Attack Vectors in Perpetual Derivatives Protocols
This section explores the attack vectors surrounding the Perpetual Derivatives Protocol. Read more about different smart contract vulnerabilities here.
Oracle Manipulation Attack
Perpetual Derivatives utilize oracles to provide the price feed of a certain asset. This price feed is essential for trade execution, calculating liquidation prices, performing liquidation, and more.
Protocols that get hit by an oracle exploit usually depend on a weak oracle, like getting the prices from Uniswap reserves, which isn’t ideal as the reserves can be easily manipulated by Flashloans.
KiloEx Hack
KiloEx, a pool-based perpetual protocol, got exploited for ~$7.4M due to a price manipulation attack on 14th April, 2025. The attacker was able to manipulate the price feed of the oracle due to poor access control.
Once the attacker manipulated the price, they opened a long position after decreasing the ETH price to $100 and closed the position after increasing it to $10000. This price manipulation helped the attacker to siphon liquidity from the liquidity pools.
How to prevent such an attack?
To prevent a protocol from Oracle Manipulation Attack, the developers and auditors should utilize external decentralized Oracle services like Chainlink or use TWAP (Time Weighted Average Price) feeds in some cases. Read more about these attacks and their mitigation here.
Business Logic Attacks
These attacks are generally on the protocol’s business logic and how it handles certain edge cases, which can be utilized to put a protocol into a bad debt.
Hyperliquid Jelly Token
This was an external attack or an attack on the business logic. This attack happened on 26th March, 2025. The attackers had opened a large short position in the Jelly token. Meanwhile, they pumped the price of the token, since it was a micro-cap token having a market cap of only $25M.
The short position was set to liquidate, but couldn’t be liquidated normally, so it was passed to the Hyperliquid Liquidity Provider (HLP) Vault. This short position was getting into more losses, and this loss was democratized among all the LPs of the vault. In order to prevent the LPs, HL changed the oracle price of the Jelly token to its original price before the manipulation happened.
Hyperliquid Over-Leveraged Position
Hyperliquid previously allowed for high leverage on assets like ETH and BTC. High leverage also comes as a risk for protocol. On 12th March, 2025, a trader opened a huge long position on the exchange. The trader then removed their collateral from the position, profiting around $1.8M.
As HL had no partial liquidation support and let users withdraw the collateral without re-evaluating the margin, the HLP vault suffered a loss of $4M.
How to prevent such an attack?
To prevent such attacks, the platform shouldn’t provide over-leverage opportunities, as it can have a cascading impact on the protocol’s liquidity. Having caps at certain business points really helps in preventing such type of attacks.
Insurance Fund Attack
The attacks are targeted to exploit the logic around how and when the protocol utilizes insurance funds. The insurance funds are utilized to safeguard the protocol from any external attack.
DYDX, YFI, and Sushi Incident
In November 2023, the dydx insurance fund got hit with a $9M attack by attackers exploiting the platform’s logic. The root cause of the incident was that the attacker manipulated the spot prices of YFI and Sushi and subsequently opened long positions on the same tokens. Since the tokens were less liquid, it was easy to manipulate them. In order to settle these positions, the insurance fund took a hit.
How to prevent such an attack?
Insurance funds are a great way to prevent the protocol from external attacks, and that’s what happened in the case of Dydx, but it could’ve been prevented by not allowing less liquid tokens to trade or capture larger OI on the exchange, and capping the risk exposure of the exchange to a certain asset.
Orderbook Manipulation Attack
Orderbooks can be manipulated if not managed properly. There should be proper risk caps to manage certain edge conditions and market volatility.
Filament Finance Exploit
On April 6, 2025, Filament Finance was hit with an attack where the manipulators opened several positions and started fulfilling them from different accounts, artificially inflating the prices of the assets. When these prices were later pushed in the opposite direction, the positions went undercollateralized.
The attacker self-liquidated itself; the issue here was how the protocol maps the collateral from the liquidated positions. They didn’t differentiate the active and liquidated collateral, hence giving an inflated sense of collateral, helping the attacker profit.
How to prevent such an attack?
Having caps and verifying the order handling logic is key to preventing such attacks. Moreover, always verify the order flow and edge conditions in the protocol.
Frontrunning and Sandwich Attack
These attacks are pretty common as the trades go in a public orderbook or are publicly visible. Once the attacker notices any large orders, they push their position ahead of the user by providing more tips to the validator.
Once the user order comes in, they get more slippage, and the attacker earns a profit when the user position executes.
How to prevent such an attack?
Users and Protocols can use private RPC keys from the platform, like Alchemy, to prevent themselves from sandwich attacks through MEV, as these transaction requests are not available in public mempools.
Conclusion
Perpetual Derivatives Protocol has seen a great trend in growth. With protocols like Hyperliquid and innovations around hyper-performant blockchains, on-chain price discovery is getting better.
There are multiple types and features in the perpetual derivatives protocol suited for users with different risk parameters. These protocols still witness multiple attack vectors like Oracle Manipulation Attacks, Business Logic Attacks, and many more. To prevent a protocol from such attacks, they should implement a robust auditing process.
At QuillAudits, with our 7+ years of experience in testing and auditing smart contracts attested with our multi-layered auditing framework, we ensure that protocols and users are secure.
