On-Chain Perpetuals & Derivatives

An on-chain perpetuals protocol allows users to hold leveraged long or short positions without an expiry date. The protocol's solvency depends on its ability to accurately track position values, calculate liquidation thresholds, and execute liquidations before a position's collateral is exhausted. Every one of these functions depends on oracle prices. If the oracle price can be manipulated, the protocol's accounting can be made to misrepresent the value of positions and collateral — allowing an attacker to borrow against inflated collateral values, avoid liquidation on underwater positions, or trigger profitable liquidations on positions that should not be liquidatable. The liquidation mechanism itself is a second major attack surface: any external call made during a liquidation before the position state is marked as closed creates a reentrancy opportunity, and any accounting asymmetry in the liquidation reward calculation can be exploited to extract value from the protocol's reserves.

The Mango Markets attack is the most instructive example of oracle manipulation in perpetuals because it was not a bug in the conventional sense — it was a logical consequence of the oracle design operating exactly as specified. The oracle blended prices from thin markets and was therefore susceptible to manipulation. The attacker did not need to find a contract vulnerability; they needed only to understand how the oracle worked and have sufficient capital to move the market. This is an important distinction: the vulnerability was not in the code but in the economic assumptions the code was built on. The Euler attack represents a different class of failure — one where a legitimate protocol function (asset donation) interacted with the liquidation mechanism in a way that was never intended and was not detectable without cross-function analysis. The attack required understanding both the donation mechanics and the liquidation incentive structure in combination, not either in isolation. This is why perpetuals protocols cannot be audited by reviewing individual functions: the attack surface is in the interactions between components. The dYdX insurance fund attack points to a fundamental tension in perpetuals design: protocols need an insurance fund to remain solvent through normal market volatility, but that insurance fund itself creates an attack vector. Any protocol whose insurance fund can be depleted faster than it is replenished has a survival risk that is independent of any code vulnerability. The common thread is that perpetuals protocols are economically adversarial environments — every incentive, every parameter, and every external data dependency is a potential attack surface for a sufficiently motivated and capitalised attacker.