Why On-Chain Options Are Still Thin — And the Liquidity Model That Fixes It

The puzzle

Crypto options has a textbook product-market fit. Funds want vol exposure, treasuries want covered calls, and market makers want venue diversity. And yet the on-chain share of options activity is somewhere south of 1%, while spot DEXs routinely cross 20% of total spot. If demand were the problem we'd see thicker order books and tighter spreads, and we don't.

It's a design problem, not a demand problem

Spot AMMs work because spot is linear. Hold X of asset A, pay or receive Y of asset B. Risk is symmetric, predictable, and bounded. The constant-product invariant x · y = k is a clever way to keep the pool solvent without any active management. Liquidity providers eat impermanent loss, but on average the math works out.

Options break every assumption in that paragraph.

An option is convex. For long gamma, small spot moves don't move you much, while large spot moves explode your P&L. For short gamma, which is where most AMM-like options vaults end up, small moves earn theta but large moves can wipe a position before the protocol notices. There is no risk-symmetric invariant. The risk surface depends on the entire current Greek profile of the pool, which in turn depends on every position the pool holds, and that changes with every trade.

You can't capture that with a bonding curve.

Three failure modes

On-chain options designs cluster into a few shapes, and each one fails for a slightly different reason:

Fragmentation. Most DOVs (DeFi Option Vaults) and tranche-style products lock collateral by strike-expiry. A pool selling January 30K BTC calls is a separate pool from January 35K BTC calls. The capital can't net against the inventory, so the system is structurally over-collateralized. Liquidity is brittle. You can't quote a 100-lot when each lot lives in its own silo.

Inefficiency. Even within a single pool, the dominant pattern is to use conservative collateralization, posting the worst-case loss for each leg independently. The protocol stays solvent against scenarios that will never simultaneously occur, capital sits idle, and spreads stay wide. Real depth never appears.

Exploitability. This is the killer. Almost every on-chain options design quotes from an external implied volatility surface, usually pulled from Deribit. That surface updates discretely, so between updates the pool's quote is stale. If the off-chain IV moves and the pool hasn't yet seen the new oracle value, an informed trader can buy underpriced vol from the pool and sell it on a centralized venue minutes later. This is Loss Versus Rebalancing (LVR), formalized for spot AMMs by Milionis et al. in 2022, and it's worse for options than for spot because the convexity makes the mispricing nonlinear.

Why LVR is worse for options

For a spot pool, the worst case during oracle lag is bounded by the spread on the underlying. You lose roughly the size of the price change times the trade size. Painful, but linear.

For an options pool, the same lag exposes you to gamma and vega simultaneously. A spot move during lag costs you gamma PnL and shifts the vol surface, which costs you vega PnL. Both are nonlinear in size, so adverse selection compounds. And unlike spot impermanent loss, which sometimes mean-reverts, options adverse selection is persistent, because theta decay and convex sensitivity move in the same direction.

This is why on-chain options vaults look attractive on a backtest with frozen IV and look catastrophic when you replay them against tick-level Deribit data. We've measured this. Static IV AMMs lose roughly 8–14% of TVL annualized to LVR under realistic oracle lag. That's not fees, not IL, but straight extractable value to informed flow.

The fix: make implied volatility endogenous

Here's the core idea I've been working on in a forthcoming paper. Treating the pool's quoted IV as a pure oracle output is the wrong abstraction. It should instead be the result of a function whose inputs include the pool's own state.

Concretely, the quoted volatility for any (strike, expiry) bucket b takes the form:

Where:

• σ_ref(b) is the oracle reference IV for the bucket, the noisy and lagging anchor.
• S(I_b) is an inventory skew function. As the pool accumulates exposure in a bucket, the function widens the quoted IV, so the pool starts to quote against itself.
• G(U) is a utilization gate. As the pool's solvency-weighted utilization approaches capacity, the gate widens quotes globally and biases new flow toward unwinding rather than building inventory.

Both S and G are bounded smooth functions. They don't introduce discontinuous halts that informed traders can game, and instead raise the marginal price of risk continuously as risk concentrates.

Why this works

Under oracle lag, the threat is that the off-chain world has moved and the pool hasn't noticed. Endogenous IV doesn't try to detect that, because detection is impossible without a fresh oracle. Instead, it raises the cost of extraction by making the next-marginal trade more expensive whenever the pool's risk state has drifted.

If an informed trader picks off the pool with a 100-lot, the next 100-lot they try to take is quoted at a wider IV, so their second trade is no longer mispriced. By the time the oracle updates, the pool has already widened defensively.

The math gets careful here, because you have to avoid circular dependence (you can't price using post-trade state, since post-trade state depends on the price). The route I take is pre-trade marginal pricing with average-price execution: compute a quote schedule from current state, integrate it over the trade size, and execute at the average. It stays solvent, it's atomic, and there's no fixed-point loop.

What the numbers say

We backtested this against two canonical baselines (a scheduled option-writing vault and a Black-Scholes AMM that quotes oracle IV without state-dependent adjustments) using real Deribit BTC option chain snapshots from early 2026 (4 Jan, near-expiry; 9 Jan, weekly).

Under controlled oracle lag, the LVR extracted from each model as a fraction of TVL:

An order of magnitude better. And critically, the gain is largest exactly where existing designs are weakest, at near-expiry pin risk, where gamma is highest and stale anchors are most exploitable.

What this unlocks

A working on-chain options primitive isn't an end in itself, but the missing layer between spot DEXs and a full institutional-grade financial layer.

Once you can quote convexity safely under oracle lag, you can build:

• Real options markets on tokenized real-world assets.
• Structured products composed from primitive options legs.
• Hedged synthetic positions that actually replicate institutional risk profiles.
• Lending markets that take options as collateral with sane LTVs.

This is the work I'm shipping inside Solistic. Synthetic equities and tokenized treasuries are the visible surface, and I've written separately about that side of the architecture. Underneath, the same liquidity model has to apply to convex risk for the system to scale past toy size. We don't get a real on-chain capital market until this primitive works.

What's deferred

A few things I'm not claiming. ULM doesn't eliminate oracle lag; it conditions the quote on internal state to reduce extraction. The game-theoretic analysis treats one informed trader, while multi-agent equilibria with cross-venue MEV need separate work. And the endogenous controller depends on calibration: there are parameter regimes where it overshoots and creates instability. Those issues are real but addressable, and the paper spends its second half on them.

But the headline result holds: convexity on-chain doesn't require giving up to extraction. The LVR floor is much lower than current designs suggest, provided you stop pretending the pool's IV is an oracle output and start treating it as state.