Perp dex (or perpetual swap) is one of the most recent categories in the world of DeFi, because it only began to gain traction in a substantial way after the FTX bankruptcy, but we certainly cannot say that it is among the least prolific in terms of development and innovation, quite the contrary: in fact, the amount of new models, products, tools, and services complementary to the perps theme introduced in the last 2 years is impressive, and the same can be said for the amount of funding raised relative to total fundraising operations (which reaches 17%, thus ranking third in overall preferences expressed by VCs, behind only infra and web3 projects).
But why so much attention to the field? Why develop so many alternative models among them? What advantages does each model have and what shortcomings does it have? To understand the importance of the perpetual swaps topic and to answer all these questions, it is first necessary to understand what they are and how they work.
Perpetual futures are a type of derivative contract allowing traders to speculate on the price movements of a specific underlying asset (a stock, crypto, bond, commodity, etc.) without being forced to own/deliver it and without being subject to any time constraints, i.e., specific expiration dates: the type of exposure they offer is precisely "perpetual" (hence the name of the derivative instrument).
To keep the price of the perp contract pegged to the price of the underlying, these markets use the so-called funding rate mechanism, i.e. periodic payments that the strong side of the market pays to the weak side to keep positions open.
Exactly like any other derivative product, the value of a perp contract depends on the supply and demand for the same and not on the price of the underlying to which it attempts to remain pegged. The greater the price divergence between the contract (the perp mark price) and the spot value of the underlying (usually identified by the index price, i.e., the weighted average of prices offered on different centralized exchanges), the higher the funding rate.
The funding rate can reach extremely high annualized percentages (below u will find a snapshot of the highest funding rates in a market phase of low volatility and trading activity, try to imagine where it might go during high IV periods) to the point that it encourages some users to close the divergence by taking positions on the weak side and thus rebalancing the supply-demand relationship for the instrument.
The interest in the field shown by crypto VCs is justified in light of the distinctive features of perps markets compared to spot markets, which we can summarize in the following points:
access to leverage (up to 100 - 1000x, depending on the type of underlying asset)
ability to speculate on both sides of the market (both long and short)
generally deeper liquidity (thus narrower spreads and price impacts) across an increasingly broader range of assets, no longer limited to the world of cryptocurrencies (but also spanning equities, tradFi indices, commodities, and forex)
greater flexibility offered to users' crypto PFs that are able to implement hedging solutions and delta neutral strategies.
real use case and very high profit margins when compared to other categories (if managed well and with minimal volume flow)
And it is precisely for the reasons listed above that the volumes generated on perp far exceed those of the spot market, as highlighted by this infographic reported by CCData (one of the most authoritative sources on the topic, I recommend downloading their reports if you are keen to delve deeper).
Although the above data may seem encouraging, it is not when viewed from the perspective of the world of DeFi, which currently accounts for less than 1 percent of the total volume of perps generated (CEX dominance is thus very high).
Why then create so many different models among them? The answer to this question must be sought in the difficult trade-off between performance and decentralization, a "problem" that every developer focused on perps has somehow faced in the development process of their project regardless of the chosen approach. Indeed, while there is enough consensus (and agreement) that the CLOB model performs better than any other, it is also true that the aforementioned model is by nature more centralized, because:
depends on the liquidity continuously offered by MMs on the book;
the sequencer batching txns onto the L2s on which they are deployed is often centralized (and in the hands of the various teams);
the networks on which they are deployed have low latency and very high throughput but a low level of decentralization
These considerations prompted many teams to approach alternative solutions, which, however, manifested other critical issues from the outset, different from those raised by the order-book model but not less relevant.
Before examining the peculiarities of each paradigm, let us try to list the general criteria on which it would be wise to evaluate these platforms, thus simplifying the research and model analysis activities that will follow. I will not be extremely analytical and detailed in identifying the parameters because it is not the purpose of this thread; for a more in-depth study of the topic I strongly suggest reading the research papers published by Amber (link at the bottom of the post) and other firms focusing on this field (such as Reflexivityresearch), which I have taken my cue from.
The evaluation criteria you can use in protocol-specific analyses are:
the type, the model used (belonging to one or another means having determined pros and cons)
the source(s) of liquidity and how efficiently it is used ( i.e., if it comes from Liquidity pool or MM, the bid/ask spreads, the nature of the flows, whether real or toxic)
margin and liquidation management system adopted
funding rates (frequency and sensitivity to changes-variance and skew)
performance ( trade execution speed guaranteed by the stack/infrastructure, latency and throughput of the underlying chain, efficiency of matching algorithms)
MEV approach (mitigation, capture, redistribution and possible level of risk exposure)
UX (level of customization, support for different order types and integration of metrics to support trading activity, support for automation tools)
Difficulty level of stack integration by third-party protocols.