The core idea
Local volatility converts a surface into instantaneous model dynamics.
An implied volatilityquote describes one option. A volatility surfacedescribes implied volatility across strike and maturity. Local volatility goes one layer deeper: it asks what volatility function of asset level and time would reproduce that option price surface under a diffusion model.
That makes local volatility a model-dynamics concept rather than a dashboard quote. It depends heavily on the smoothness and arbitrage quality of the surface used as input, which is why SVI, SSVI, and fit diagnostics matter before anyone differentiates the surface.
Start from option prices
Local volatility is derived from a smooth surface of European option prices across strikes and expiries.
Differentiate the surface
The Dupire formula uses time and strike derivatives of call prices, so interpolation quality matters.
Read it as dynamics
The output is an instantaneous volatility function by strike and time, not another quoted implied volatility.
Dupire formula
Dupire local volatility uses derivatives of call prices by strike and maturity.
In a common risk-neutral form, local variance is computed from the maturity derivative, strike derivative, and strike convexity of European call prices. The denominator is tied to the second strike derivative, which is why bad interpolation can create unstable local-volatility estimates.
Crypto implementations need careful forward and carry handling. The exact operational form depends on whether prices are represented in spot, forward, discounted, or normalized units.
Dupire inputs
The local-volatility formula is a data-quality test on the whole surface.
A local-volatility point is not independent of the surrounding surface. It uses neighboring strikes, neighboring expiries, interpolation choices, forward state, and price convexity. That makes the input audit as important as the formula itself.
Call price grid C(K,T)
Dupire is defined on option prices, so implied-volatility points need to be converted back into a smooth call-price representation.
Maturity derivative
The time derivative reads how call prices change as expiry increases; calendar noise can dominate this term.
Strike slope
The first strike derivative depends on the chosen forward, carry convention, and how the surface is interpolated between listed strikes.
Strike convexity
The second strike derivative is the density term. If it is near zero or negative, local variance becomes unstable or invalid.
In practice, local volatility should sit after the volatility surface, SVI, and SSVI checks, not before them.
Model comparison
Local volatility is not a replacement for SVI, SSVI, or SABR.
These models answer different questions. SVI and SSVI are practical ways to fit and monitor an implied total-variance surface. SABR/SABRE gives a smile-dynamics view. Local volatility asks for the deterministic instantaneous volatility function consistent with the surface.
Implied volatility
A quote-normalized volatility number backed out from an option price for one strike and expiry.
SVI and SSVI
Parametric shapes for fitting implied total variance across one expiry or a full surface.
Local volatility
A model-consistent instantaneous volatility function inferred from the option price surface.
Production checks
Local volatility is only as stable as the fitted surface beneath it.
The practical risk is not the formula; it is differentiating a noisy surface. A production workflow should inspect quote quality, fitted residuals, butterfly behavior, calendar consistency, and forward volatility before treating local volatility as meaningful.
Smooth prices before differentiating
Local volatility is sensitive to noisy strike and expiry derivatives, so raw quote surfaces need careful smoothing.
Check butterfly and calendar behavior
Negative density or inconsistent total variance can make the Dupire denominator or numerator unstable.
Use the forward consistently
Crypto options need expiry-specific forward context before strikes, moneyness, and discounting assumptions are compared.
Treat it as a diagnostic
A local-vol surface can reveal structure, but it should be reviewed beside quote residuals, SVI fits, and risk nodes.
Numerical workflow
Compute local volatility only after the price surface has passed fit and arbitrage checks.
A practical local-volatility workflow is a chain of accepted states. First the option marks are converted into implied volatility, then expiry smiles are fit with SVIor checked with SSVI-style surface constraints. Only then should the system build a price grid and estimate Dupire derivatives.
Accept surface slices first
Use SVI or SSVI-style checks to reject bad expiry slices before any strike or maturity derivative is estimated.
Convert to a price grid
Dupire is defined on option prices, so IV points need a consistent forward, discounting convention, and call-price representation.
Estimate derivatives locally
Finite differences in strike and maturity should be computed on a smooth grid with controlled spacing and boundary treatment.
Publish diagnostics, not just values
A local-vol point should carry source expiries, residual checks, denominator health, and reject reasons.
accepted quotes -> IV surface -> total variance fit -> call price grid -> dC/dT, dC/dK, d2C/dK2 -> local variancePrice grid
The local volatility price grid should be built from one accepted surface snapshot.
Dupire local volatility is calculated from option prices, but Derivasys works upstream in implied volatility and total variance. A production workflow has to convert accepted IV slices back into a coherent call-price grid before estimating strike and maturity derivatives.
Accepted IV snapshot
Build the local-volatility grid from one accepted surface snapshot, not a mix of old and new expiry slices.
Forward-aligned prices
Convert implied volatility back into option prices with the same forward, expiry, and settlement convention used by the smile fit.
Grid spacing
Record strike and maturity spacing because finite differences can change materially when the grid is too coarse or uneven.
Boundary policy
Label one-sided differences, extrapolated wings, and first or last maturities before exposing local-volatility values.
This is where local volatility depends on implied volatility, quote-state construction, and accepted SVI or SSVI surface versions.
Derivative guardrails
Finite differences need boundary labels, denominator checks, and versioned interpolation.
Local volatility is sensitive to implementation choices that can be invisible in a high-level chart. A production system should make those choices auditable before a downstream user treats the grid as a model input.
Use total variance for fitting, prices for Dupire
Fit smiles in total-variance space when that is the stable calibration object, then convert to prices on the Dupire grid.
Keep boundary nodes labelled
Local-volatility values near wings and first or last maturities usually depend on one-sided differences or extrapolation.
Reject unhealthy denominators
Do not publish a local variance when strike convexity is too small, negative, or driven by one unsupported quote.
Version the interpolation scheme
Changing spline, grid, smoothing, or extrapolation policy can change local volatility even if raw quotes are identical.
Denominator health
Dupire denominator health should be published beside every local-volatility value.
The denominator is where a visually smooth surface can fail. A weak second strike derivative, unsupported wing, or calendar artifact can turn a small market-data issue into an unstable local variance. The output should therefore carry a denominator health label before it reaches an API response.
Convexity floor
Suppress local variance when the second strike derivative is too small or negative to support a stable Dupire denominator.
Quote support
Show how many live strikes support the local stencil so one stale wing cannot create a confident-looking model value.
Calendar numerator
Track whether the maturity derivative is driven by accepted term structure or by a noisy adjacent expiry.
Residual context
Carry SVI or SSVI residuals into the local-volatility output so derivative artifacts can be traced to the fit.
Failure modes
Most local-volatility errors are inherited from interpolation, extrapolation, or weak market data.
Local volatility can be mathematically correct and operationally useless if the inputs are not traceable. That is why a dashboard should keep local-volatility research tied to quote-through-fit residuals, forward volatility, and surface-quality checks.
Small convexity denominator
When the second strike derivative is near zero, local variance can explode even if the implied-vol chart looks visually smooth.
Calendar noise
A tiny maturity bump in total variance can turn into a large local-vol artifact after differentiation.
Wing extrapolation
Far-wing local-vol values often come from model extrapolation more than live quotes, so the dashboard should expose provenance.
Forward mismatch
Using a different forward convention from the SVI fit changes moneyness, option prices, and the Dupire derivatives.
Replay
Local volatility replay should prove that grid, stencil, and publish-status changes are intentional.
Local-volatility outputs are sensitive to implementation details, so changes to interpolation or finite differences need replay checks. A useful regression test compares not only the local-volatility numbers but also which nodes were accepted, suppressed, boundary-labelled, or rejected, giving the desk a visible local volatility publish status for every grid node.
Version the grid builder
Store the interpolation, smoothing, finite-difference, forward, and boundary-policy versions with every local-volatility grid.
Replay accepted surfaces
Rebuild local volatility from historical accepted surface snapshots before changing derivative stencils or smoothing settings.
Compare publish status
Regression checks should compare accepted, suppressed, weak-denominator, and boundary-labelled nodes, not only numeric values.
Keep dashboard provenance
A local-volatility research output should link back to the surface snapshot, fit ids, and quote-state records that created it.
LocalVolReplay {
source_surface_id,
grid_policy_version,
finite_difference_stencil,
forward_convention,
boundary_policy,
publish_status_by_node
}API diagnostics
A local volatility API should return diagnostics beside every model value.
A grid of local-volatility numbers is hard to trust without provenance. For research or downstream model use, local volatility diagnostics should explain the accepted surface, derivative health, quote support, and reason a point was published or suppressed.
surface id, currency, expiry grid, forward convention, SVI or SSVI source, and accepted snapshot timestamp.
dC/dT, dC/dK, d2C/dK2, denominator status, finite-difference stencil, and boundary/extrapolation flag.
source expiries, strike neighbors, quote counts, residual range, and whether a node is interpolation-heavy.
accepted, suppressed, stale, reused, negative variance, weak denominator, or calendar-inconsistent.
The same audit trail is useful for production monitoring. The surface monitoring article shows why freshness, reject reasons, and quote provenance need to be visible before model outputs are consumed.
Dashboard workflow
Derivasys focuses the public dashboard on the observable surface and diagnostics.
The live Derivasys dashboard exposes fitted smiles, risk nodes, quote-through-fit checks, fixed-tenor rows, and calibration diagnostics. Those are the upstream objects a local-volatility model would depend on, and they are the right place to inspect whether a surface is clean enough for model-dynamics work.
Dashboard screenshots
Surface diagnostics should be reviewed before deriving model dynamics.
Local volatility is downstream of the same fit health that powers the Derivasys dashboard. The screenshots below show the observable surface and through-fit checks that should be inspected before differentiating a price grid.
Reading path
Move from quoted IV into model dynamics.
Convert accepted option prices into IV before building a clean surface.
Read nextLocal volatility starts from a clean option price or implied-volatility surface.
Read nextUse SVI to fit stable implied total variance slices before diagnostics.
Read nextUse SSVI for surface-level consistency and static-arbitrage reasoning.
Read nextCompare surface-derived implied variance with realized-variance payoffs.
Read nextCheck maturity-to-maturity variance before differentiating across expiries.
Read nextTrace local-volatility inputs back to quote-state and forward-state records.
Read nextUse surface health and replay checks before consuming model diagnostics.
Read nextCompare local-vol dynamics with a stochastic-volatility-style smile model.
Read nextFAQ
Common questions about local volatility.
What is local volatility?
Local volatility is an instantaneous volatility function that depends on asset level and time. It is inferred from a smooth option price surface, commonly through the Dupire formula.
How is local volatility different from implied volatility?
Implied volatility is quoted for one option strike and expiry. Local volatility is a model input that describes the instantaneous volatility used by a diffusion process matching a full option surface.
What is the Dupire formula?
The Dupire formula relates derivatives of European call prices across strike and maturity to the local variance at that strike and maturity.
What inputs are needed for Dupire local volatility?
Dupire local volatility needs a smooth European call price surface, expiry-specific forward state, strike and maturity derivatives, a stable strike-convexity denominator, and diagnostics showing whether values came from interpolation or extrapolation.
How does SVI help local volatility?
SVI can provide stable implied total-variance slices before the system converts them into a call-price grid. Local volatility should still check price convexity, calendar behavior, residuals, and finite-difference stability after the SVI fit.
Does Derivasys use local volatility?
Derivasys focuses the public dashboard on implied volatility surfaces, SVI smiles, risk nodes, and diagnostics. Local volatility is a useful model and diagnostic concept that depends on the quality of the fitted surface.
Why can local volatility be unstable?
Local volatility differentiates an option price surface by strike and maturity. Small quote errors, noisy interpolation, or weak wing data can become large local-volatility artifacts.
What does negative local variance mean?
Negative local variance usually means the fitted price surface violates a consistency condition, such as calendar monotonicity or strike convexity, or that numerical derivatives are too noisy.
Should local volatility be shown without diagnostics?
No. A local-volatility grid should show surface provenance, derivative health, boundary flags, and reject reasons because the model can amplify small quote or interpolation errors.
What should a local volatility API include?
A local volatility API should include source surface id, forward convention, grid policy, finite-difference stencil, denominator health, boundary flags, publish status, and replay identifiers.
Why does the Dupire denominator matter?
The denominator contains strike convexity. If that convexity is too small, negative, or driven by weak quotes, local variance can explode or become invalid.
How should local volatility be tested before publishing?
Replay accepted historical surfaces through the grid builder, compare publish status and values, and suppress nodes whose derivative health or provenance is weak.
References
Related model and Derivasys pages.
Local volatility sits downstream of a clean options surface, so the most useful references are the surface, calibration, and no-arbitrage diagnostics around it.