The attack surface scales with how many assumptions your system makes about external state. Most perp protocols assume oracles are honest, liquidity is stable, and users are rational. Three assumptions, three attack surfaces.
We built Perk with the opposite approach. Assume oracles lie (EMA smoothing with hard caps per tick, on chain circuit breakers, multi source aggregation). Assume liquidity disappears (Percolator's warmup ramps position effectiveness over a slot window so flash loans are economically irrational before the position even has weight). Assume users are adversarial (K index tracking recalculates every open position's PnL on liquidity changes so nobody can exploit depth shifts).
The clever part: we separated the risk engine from the execution layer entirely. Percolator handles margin, funding, liquidation, warmup, and ADL. It doesn't care if trades come from a vAMM, an orderbook, or an RFQ. That separation means an exploit in execution can't cascade into the risk model. Most protocols couple these, so one oracle manipulation can drain the vault.
The real insight is that a smaller, formally auditable risk engine with a huge test surface beats a monolithic system with a huge attack surface. You can't eliminate the attack surface. You can make it so the parts that matter most are the parts you trust most.
What I’ve learned so far is that perps have an insanely huge attack surface.