What is implied volatility?

The core idea

Implied volatility translates option prices into a volatility scale.

Options trade as prices, but desks often need to compare them as volatility. Implied volatility is the volatility input that makes a pricing model reproduce the current option price. If two BTC options have different strikes or expiries, their dollar prices are not directly comparable. Their implied volatilities are much easier to compare.

In Derivasys, IV is the first step in the path from raw exchange quotes to the volatility surface, volatility smile, SVI fit, and live dashboard.

Formula

IV is solved by matching the model price to the market price.

The pricing model can be Black-Scholes-style or another model appropriate for the market convention. The important point is that implied volatility is an output of inversion, not a price that appears on the exchange order book by itself.

Price selection

Implied volatility is only as clean as the option price sent into the solver.

A live IV worker should not treat every exchange number as the same object. Bid IV, ask IV, mark IV, trade IV, and mid IV can answer different questions. The chosen price should be explicit before that point enters the smile, SVI fit, or downstream dashboard risk node.

IV inversion

Implied volatility calculation is a guarded model inversion.

In a production crypto options pipeline, IV calculation starts with the cleaned quote state from the order book. The worker has to choose a price, check basic bounds, solve for the volatility input, and publish diagnostics so downstream SVI and dashboard consumers know whether the point is trustworthy.

Newton-style solvers are fast when the option has useful vega, but far wings, stale marks, and near-expiry options can make the solve unstable. Derivasys treats those cases as data-quality signals: fallback method, iteration count, residual, and reject reason travel with the IV point.

quote = clean_option_quote(book_state)
price = choose_mark_price(quote.bid, quote.ask, quote.mark)

if price_outside_no_arbitrage_bounds(price, quote):
    reject_iv(reason="bad_price")
else:
    iv = newton_solve(price, quote, seed=previous_iv)

    if not iv.converged or quote.vega_is_weak:
        iv = bisection_solve(price, quote, low=0.01, high=5.00)

    publish_iv(iv, diagnostics={method, iterations, residual})

This is why implied-volatility calculation links directly to order book construction andproduction monitoring. A clean surface starts with a clean IV solve, not only a smooth SVI curve.

Solver diagnostics

IV solves should publish method, residual, bounds, and reject reason.

The most useful IV number is not just the final volatility. It is the volatility plus context: whether Newton converged, whether bisection was needed, whether the value hit a bound, and whether the quote should be excluded from the fitted smile. In practice, the implied volatility solver should publish IV solve diagnostics with every accepted or rejected point.

IV state contract

Each IV point should carry quote identity, pricing context, solver telemetry, and publication status.

A raw volatility number is not enough for a live surface. The IV state contract should tell SVI, monitoring, API consumers, and the dashboard exactly which quote, forward, solver path, and publication decision produced the point.

VolState {
  quote_state_id,
  instrument,
  chosen_price_source,
  forward,
  implied_volatility,
  total_variance,
  solver_telemetry,
  status
}

Cache reuse

IV cache reuse is safe only when the displayed surface would not move.

Reusing a previous IV can protect the event loop during bursty BTC markets, but it is a product decision rather than a simple cache lookup. The cache policy must preserve the fitted smile, same-delta nodes, forward-volatility buckets, and surface health state.

The performance tuning article explains why selective IV recalculation needs replay checks before it can feed the live dashboard.

API output

An implied volatility API should expose the input quote, solver result, surface links, and replay state.

API consumers need more than IV. They need to know whether a point was accepted, rejected, reused, or held back, and which surface state consumed it. That makes the implied volatility API useful for calibration, monitoring, replay, and downstream risk systems.

Those fields connect IV to smile construction, SVI calibration, surface health monitoring, and the replay path behind Derivasys dashboard snapshots.

Total variance

SVI and forward volatility use IV after converting it to total variance.

Implied volatility is usually annualized. For fitting and term-structure work, Derivasys converts each accepted IV point into total implied variance. That is the quantity raw SVI fits across log-moneyness, and the same scale used when deriving forward volatility.

Why it matters

IV makes the surface readable.

A volatility dashboard needs more than a pile of option prices. It needs a consistent coordinate system where strikes, expiries, risk nodes, and diagnostics can be compared during active markets.

Surface workflow

One IV point becomes useful when it is placed inside the smile.

For one expiry, implied volatility across strikes forms the volatility smile. Fit that smile with SVI, connect smiles across expiries, and the result becomes a production volatility surface.

From there, desks usually extract stable nodes rather than read every strike manually. A risk reversal summarizes signed skew, while flies summarize smile curvature.

Dashboard screenshots

Live IV is useful when the quote, fit, and diagnostics stay visible.

Implied volatility should not be a detached number. The dashboard keeps IV-derived smiles beside risk nodes, quote-through-fit checks, and volatility surface diagnostics so users can see whether a move came from market structure or bad input data.

Topical path

Move from IV into the live dashboard workflow.

• Volatility surface: See where implied volatility fits in the full surface workflow.
• Forward volatility: Convert expiry IV into total variance and compare future windows.
• Option Greeks: See how IV, forwards, and time feed delta, gamma, vega, and theta.
• Variance swaps: Move from implied volatility to implied variance and realized-variance payoffs.
• Volatility smile: Move from one IV point to a full expiry curve.
• SVI: Fit the smile with a stable total-variance model.
• SSVI: Tie accepted IV slices into a surface-level total-variance shape.
• Order book construction: See the quote-state contract used before IV inversion.
• Production monitoring: Monitor solver failures, stale IV points, and surface health status.
• Performance tuning: See why IV inversion became the live BTC options bottleneck.
• Risk reversal: Turn the fitted smile into a signed skew node.
• Local volatility: See how a smooth IV surface feeds model-dynamics diagnostics.
• Dashboard: Inspect live IV, fitted smiles, risk nodes, and diagnostics.

References

Related Derivasys guides.

• Derivasys volatility surface guide
• Order book construction for crypto options
• Production monitoring for crypto volatility surfaces
• Derivasys forward volatility guide
• Derivasys option Greeks guide
• Derivasys variance swaps guide
• Derivasys volatility smile guide
• Derivasys SVI guide
• Derivasys SSVI guide
• Derivasys local volatility guide
• Derivasys risk reversal guide
• Real-time BTC options surface engineering article