A few days ago, Ostium was compromised due to access to privileged keys: pricing and execution.
This allowed the exploiter to open trades at prices drastically below the market and close them at the market price. After the trade, the funds were immediately withdrawn from the protocol and bridged to Ethereum, resulting in losses of roughly $18 million.
There's been a lot of talk about ways to protect against such compromises, from instant settlement to better key security, but most solutions are naive.
In this article, I'll walk through some of the mitigations we have in place that are both operationally realistic and practical.
Before the trade
Perp DEXs rely on two things: price indexes and margin currency. There's a lot of prior work on best practices for aggregating robust price indexes, but not as much on securing these price oracles.
- Spot price: this is provided by an oracle provider and verified on-chain, Chainlink in our case.
- Mark price: this has to be computed off-chain (it's gas-intensive on-chain) because it requires information not available on-chain.

Tolerance Bands
The mark price is updated every 2 seconds, so you can forget about using multi-sigs to protect against key compromise. Instead, we use Tolerance Bands on the smart contract that automatically reject mark price updates that are too far from the spot oracle price.

So even if the mark price admin key is compromised, the attacker can only push the price +/- 5% of the spot oracle price.
Siloed Admin Keys
The price key is powerful but narrow. It can only propose a mark and relay oracle reports. There's a completely different admin key that controls the tolerance bands, and the bands can only be increased to a maximum of +/- 20% in the worst case.

The attacker cannot compromise the oracle prices (Chainlink), change tolerance bands (tolerance admin), or disable the oracle (multi-sig). You can see a full explainer and visual interactive here: https://perplfoundation.github.io/explainers/mark-price/index.html
After the Trade
There's been a lot of renewed discussions on how protocols can protect funds in the event of a hack, and instant settlement was again the topic de jour.
You want to stop getting hacked?
— Armani Ferrante (@armaniferrante) July 15, 2026
Kill instant settlement.
It’s just not worth it.
Every exchange and protocol should add mandatory withdrawal delays.
People will hate it. People might dunk on me for saying this, but these people don’t care about you or the safety of your… https://t.co/rNL1hxIb9f
Naively implementing a standard delay on withdrawals would ruin the user experience of trading on a DEX and kill trading strategies for whales and market-making firms.
— Perpl (@perpltrade) April 21, 2026
Burst Window
The smart contract limiter allows for 10% of the TVL to be withdrawn every hour. The hourly limit is not made immediately available in full. Instead, the protocol splits each cycle into two phases. This prevents an attacker from draining the entire hour's allocation in a single transaction.
At the start of a new cycle, the contract makes approximately 25% of the hourly limit available upfront as the burst amount. After that burst is consumed or the first 15 minutes elapse, the remaining 75% unlocks gradually, block by block.

Bypass Address
Some protocol actors need to move funds without touching the rate limiter. The operator of a market-making vault needs to rebalance. An automated liquidation keeper needs to sweep collateral immediately. A protocol treasury contract may manage funds on a schedule that doesn't align with 60-minute cycles.
TLDR:
We’ve built a defense-in-depth system that meaningfully raises the bar without sacrificing the core trading experience.
We did it by combining siloed admin keys, tight tolerance bands around trusted oracles, and a sophisticated rate limiter with burst windows and bypass mechanisms. Even if a privileged key is compromised, the damage is now tightly constrained, both in price manipulation and in how quickly funds can be extracted.
In an industry quick to reach for dramatic but impractical solutions, sometimes the most effective protection comes from thoughtful, layered engineering that accepts reality while refusing to let it win.
Security in DeFi is a job that will never be finished.
We’ll keep shipping.
Read more: https://perplfoundation.github.io/explainers/mark-price/overview.html