\n\n日本語要約: DeFiに不足しているボラティリティデータを提供するオンチェーンOracleのプロダクトコンセプトです。オーダーブックデータからrealized volatilityを算出し、スマートコントラクトに配信する仕組みをTypeScriptプロトタイプとSolidityインターフェースのコード例とともに提案します。
\n
I’ve been thinking about a gap in DeFi infrastructure that seems surprisingly under-served: volatility data. We have robust price oracles, but almost nothing purpose-built for serving volatility estimates on-chain. This post walks through a product concept I’ve been prototyping — a volatility oracle that computes realized vol from high-frequency orderbook data and makes it available to smart contracts.
\nPrice oracles are table stakes at this point. Every lending protocol, every DEX, every derivatives platform relies on some form of price feed. But volatility? That’s a different story entirely.
\nThink about who actually needs vol data on-chain:
\nOptions protocols are the obvious case. You can’t price options without implied volatility, and you can’t calibrate your vol surface without realized vol as a reference. Protocols that sell options on-chain are essentially flying blind or relying on off-chain computation that users have to trust.
\nRisk management in lending protocols is another big one. Liquidation thresholds are typically static — you set a collateral ratio of 150% and call it a day. But a 150% ratio means very different things when ETH is trading at 10% annualized vol versus 80%. A vol-aware liquidation engine could dynamically adjust thresholds, reducing unnecessary liquidations during calm markets and protecting the protocol during volatile ones.
\nLiquidation engines themselves could benefit from vol-adjusted parameters. If you know volatility is spiking, you can widen your liquidation buffers proactively rather than reacting after the damage is done.
\nThe current state of affairs is that protocols either hardcode assumptions about volatility, compute it off-chain in trusted backends, or simply ignore it. None of these are great.
\nThe idea is straightforward: ingest high-frequency orderbook data from major exchanges, compute realized volatility using multiple estimators, and push the results on-chain as an oracle feed that any smart contract can consume.
\nHere’s the high-level architecture:
\nBinance WS → Aggregator (0.5s VWAP) → Vol Calculator → Oracle Contract → DeFi ConsumersThe key insight is that orderbook microstructure data — the actual bids and asks updating dozens of times per second — gives us much better volatility estimates than the traditional approach of using daily OHLC candles. We’re capturing information about price dynamics that gets lost when you downsample to hourly or daily bars.
\nThe aggregator computes volume-weighted average prices at 500ms intervals, giving us a clean price series that incorporates the full depth of the orderbook rather than just last-trade prices. This feeds into the volatility calculator, which maintains rolling windows and outputs annualized vol estimates. Those estimates get pushed to a Solidity oracle contract whenever they change by more than a configurable threshold.
\nNot all volatility estimators are created equal. I’m implementing several and letting consumers choose which one suits their use case.
\nThe classic approach. Take a rolling window of log returns, compute the standard deviation, annualize it.
\n$$\\sigma{realized} = \\sqrt{\\frac{252}{n} \\sum{i=1}^{n} (r_i - \\bar{r})^2}$$
\nSimple, well-understood, but inefficient — it only uses closing prices and throws away intra-period information.
\nUses the high-low range within each period, which captures more information about price dynamics:
\n$$\\sigma{parkinson} = \\sqrt{\\frac{1}{4n \\ln 2} \\sum{i=1}^{n} (\\ln Hi - \\ln Li)^2}$$
\nThis is roughly 5x more efficient than the close-to-close estimator for the same number of observations. The tradeoff is that it assumes continuous trading (no gaps), which is fine for crypto markets.
\nGoes further by using full OHLC data:
\n$$\\sigma{GK} = \\sqrt{\\frac{1}{n} \\sum{i=1}^{n} \\left[ \\frac{1}{2}(\\ln Hi - \\ln Li)^2 - (2\\ln 2 - 1)(\\ln Ci - \\ln Oi)^2 \\right]}$$
\nEven more efficient, roughly 8x better than close-to-close for the same observation count.
\nWith traditional OHLC data from daily candles, you’re working with maybe 30 data points for a monthly vol estimate. With 500ms VWAP snapshots from orderbook data, you get ~170,000 observations per day. Even accounting for the autocorrelation in high-frequency data (which you need to correct for), the statistical precision of your vol estimate is dramatically better.
\nMore importantly, you can detect vol regime changes in minutes rather than days. For DeFi protocols that need to react quickly — say, tightening liquidation parameters during a flash crash — this responsiveness is the whole point.
\nHere’s an interactive prototype of the volatility oracle dashboard. It simulates a real-time BTC price feed and computes all three volatility estimators continuously. Try adjusting the window size and update threshold, or hit “Inject Volatility Spike” to see how each estimator responds to sudden regime changes.
\n\nHere’s the core of the prototype. This service connects to a WebSocket feed, maintains a rolling window of VWAP prices, and computes realized vol on demand.
\nimport WebSocket from \"ws\";\n\ninterface PricePoint {\n timestamp: number;\n vwap: number;\n}\n\nclass VolatilityService {\n private prices: PricePoint[] = [];\n private readonly windowSize: number;\n private readonly aggregationMs: number;\n private currentBucket: { sumPQ: number; sumQ: number; ts: number } | null = null;\n\n constructor(windowSize = 3600, aggregationMs = 500) {\n this.windowSize = windowSize; // seconds of history to keep\n this.aggregationMs = aggregationMs;\n }\n\n connectToFeed(wsUrl: string, symbol: string): void {\n const ws = new WebSocket(wsUrl);\n ws.on(\"message\", (data: string) => {\n const msg = JSON.parse(data);\n if (msg.s === symbol && msg.e === \"trade\") {\n this.ingestTrade(msg.T, parseFloat(msg.p), parseFloat(msg.q));\n }\n });\n }\n\n private ingestTrade(timestamp: number, price: number, qty: number): void {\n const bucketTs = Math.floor(timestamp / this.aggregationMs) * this.aggregationMs;\n if (!this.currentBucket || this.currentBucket.ts !== bucketTs) {\n if (this.currentBucket && this.currentBucket.sumQ > 0) {\n this.prices.push({\n timestamp: this.currentBucket.ts,\n vwap: this.currentBucket.sumPQ / this.currentBucket.sumQ,\n });\n this.pruneOldPrices();\n }\n this.currentBucket = { sumPQ: 0, sumQ: 0, ts: bucketTs };\n }\n this.currentBucket.sumPQ += price * qty;\n this.currentBucket.sumQ += qty;\n }\n\n computeRealizedVol(windowSeconds?: number): number {\n const window = windowSeconds || this.windowSize;\n const cutoff = Date.now() - window * 1000;\n const relevant = this.prices.filter((p) => p.timestamp >= cutoff);\n if (relevant.length < 2) return 0;\n\n const logReturns: number[] = [];\n for (let i = 1; i < relevant.length; i++) {\n logReturns.push(Math.log(relevant[i].vwap / relevant[i - 1].vwap));\n }\n\n const mean = logReturns.reduce((a, b) => a + b, 0) / logReturns.length;\n const variance =\n logReturns.reduce((sum, r) => sum + (r - mean) ** 2, 0) / (logReturns.length - 1);\n\n // Annualize: scale by observations per year\n const obsPerYear = (365.25 * 24 * 3600 * 1000) / this.aggregationMs;\n return Math.sqrt(variance * obsPerYear);\n }\n\n private pruneOldPrices(): void {\n const cutoff = Date.now() - this.windowSize * 1000;\n this.prices = this.prices.filter((p) => p.timestamp >= cutoff);\n }\n}The service exposes the current vol estimate via a simple REST endpoint (not shown here for brevity, but it’s a basic Express route returning { annualizedVol, timestamp, windowSeconds, sampleCount }). This is what the oracle updater process polls to decide whether to push a new value on-chain.
A key design choice: the 500ms VWAP aggregation smooths out individual trade noise while preserving meaningful price movements. If you compute returns on raw trade-by-trade data, you get a lot of microstructure noise (bid-ask bounce, etc.) that inflates your vol estimate. The VWAP bucketing handles this elegantly.
\nOn the smart contract side, I want something simple and composable. Here’s the interface:
\n// SPDX-License-Identifier: MIT\npragma solidity ^0.8.19;\n\ninterface IVolatilityOracle {\n struct VolData {\n uint256 realizedVol; // Annualized vol in basis points (e.g., 5000 = 50%)\n uint256 parkinsonVol; // Parkinson estimator\n uint256 garmanKlassVol; // Garman-Klass estimator\n uint256 timestamp; // When this was computed\n uint32 windowSeconds; // Observation window used\n uint16 confidence; // Sample count / quality metric\n }\n\n function getVolatility(bytes32 pair) external view returns (VolData memory);\n function getRealizedVol(bytes32 pair) external view returns (uint256 vol, uint256 timestamp);\n function isStale(bytes32 pair, uint256 maxAge) external view returns (bool);\n\n event VolatilityUpdated(bytes32 indexed pair, uint256 realizedVol, uint256 timestamp);\n}\n\ncontract VolatilityOracle is IVolatilityOracle {\n mapping(bytes32 => VolData) private _latestVol;\n mapping(address => bool) public authorizedUpdaters;\n uint256 public updateThresholdBps = 100; // Only update if vol changed by >1%\n\n modifier onlyUpdater() {\n require(authorizedUpdaters[msg.sender], \"unauthorized\");\n _;\n }\n\n function pushUpdate(bytes32 pair, VolData calldata data) external onlyUpdater {\n VolData storage current = _latestVol[pair];\n uint256 delta = _absDiff(current.realizedVol, data.realizedVol);\n require(\n delta * 10000 / (current.realizedVol + 1) >= updateThresholdBps,\n \"change below threshold\"\n );\n _latestVol[pair] = data;\n emit VolatilityUpdated(pair, data.realizedVol, data.timestamp);\n }\n\n function getVolatility(bytes32 pair) external view returns (VolData memory) {\n return _latestVol[pair];\n }\n\n function getRealizedVol(bytes32 pair) external view returns (uint256, uint256) {\n VolData storage d = _latestVol[pair];\n return (d.realizedVol, d.timestamp);\n }\n\n function isStale(bytes32 pair, uint256 maxAge) external view returns (bool) {\n return block.timestamp - _latestVol[pair].timestamp > maxAge;\n }\n\n function _absDiff(uint256 a, uint256 b) internal pure returns (uint256) {\n return a > b ? a - b : b - a;\n }\n}A few design decisions worth noting:
\nPush model with threshold. The updater only sends a transaction when vol has changed meaningfully (configurable threshold, defaulting to 1% relative change). This keeps gas costs manageable — during stable markets, updates might happen every few minutes; during volatile periods, more frequently.
\nStaleness check built in. Consumers can call isStale() to verify the data is fresh enough for their use case. A lending protocol might tolerate 5-minute-old data; an options protocol might want sub-minute freshness.
Multiple estimators in one struct. Different consumers have different needs. By publishing all three estimators in a single update, we amortize the gas cost across multiple use cases.
\nBasis points representation. Using uint256 with basis points (50% vol = 5000 bps) avoids floating point entirely while giving sufficient precision for any practical application.
\nI’ve been building a simple dashboard to visualize the feed in real time — nothing fancy, just a React frontend with a chart showing the rolling vol estimate, the raw VWAP prices it’s computed from, and the on-chain update history. It’s useful for debugging and for demonstrating to potential integrators that the feed is responsive and accurate.
\nThe most interesting visualization is overlaying the three estimators. During normal markets they track closely, but during dislocations (flash crashes, sudden liquidity events) the Parkinson estimator reacts fastest because it captures the intra-bucket range expansion immediately. Watching them diverge and reconverge is genuinely interesting from a market microstructure perspective.
\nThis prototype works, but there’s a gap between “works on my laptop” and “production oracle that protocols depend on.” Here’s what I’m thinking about:
\nEven with the threshold-based update mechanism, gas costs add up. On L1 Ethereum, pushing updates every few minutes for multiple pairs gets expensive quickly. The obvious answer is deploying on L2s (Arbitrum, Base, etc.) where updates cost fractions of a cent. You could also explore a pull-based model where consumers pay for their own reads from an off-chain data availability layer, but that adds complexity.
\nRelying on a single exchange’s orderbook is a centralization risk and a manipulation vector. The production version needs to aggregate across multiple venues — Binance, OKX, Bybit, Coinbase — and use some form of outlier detection to handle cases where one venue’s data diverges (possibly due to manipulation or technical issues).
\nI’m thinking a median-of-estimators approach across venues, with automatic exclusion of any source that deviates more than 2 standard deviations from the median. This is similar to how existing price oracle networks handle multi-source aggregation.
\nThis is the hard problem. If someone knows that a DeFi protocol uses this vol oracle to set liquidation thresholds, they could theoretically manipulate the underlying orderbook data to spike the vol estimate, causing the protocol to widen thresholds, and then exploit the looser parameters.
\nDefenses include: using longer observation windows (harder to sustain manipulation), requiring consistent signals across multiple venues, implementing rate-of-change limits on the oracle output (vol can’t jump more than X% per update), and incorporating TWAP-style smoothing.
\nThe end game isn’t running this as a standalone service. It’s getting vol data integrated into existing oracle networks so that it benefits from their existing security models, node operator sets, and consumer ecosystems. The computation methodology described here could run as a module within a decentralized oracle network, with multiple independent node operators each computing vol from their own data sources and reaching consensus on the output.
\nThere are more sophisticated approaches worth exploring: realized kernels (which handle microstructure noise more elegantly), jump-robust estimators (bi-power variation), and multi-scale realized volatility. Each has tradeoffs between noise sensitivity, computation cost, and the assumptions they make about the price process.
\nI think there’s a real product here. The DeFi options market is growing, lending protocols are getting more sophisticated about risk management, and everyone needs better vol data. The gap between “price oracle” and “volatility oracle” is mostly an engineering challenge at this point — the statistical methods are well-established, the data sources exist, and the smart contract interface is straightforward.
\nThe prototype is running locally, ingesting Binance trade data and computing vol estimates that look reasonable when compared against Deribit’s implied vol surface. Next steps are multi-venue aggregation, a proper deployment on a testnet, and conversations with potential consumers about what API they actually want.
\nIf you’re building something in the DeFi derivatives or risk management space and would find a vol oracle useful, I’d love to hear about your requirements. The interface design should be driven by actual consumer needs rather than my assumptions about what’s useful.
","tableOfContents":"","frontmatter":{"title":"Building a Volatility Oracle Prototype: Computing Realized Volatility from Orderbook Data and Serving It On-Chain","date":"April 10, 2026","description":"A product concept for an on-chain volatility oracle that computes realized volatility from orderbook microstructure data, with TypeScript prototype and Solidity interface."}}},"pageContext":{"slug":"/volatility-oracle-prototype/","previous":{"fields":{"slug":"/polymarket-orderbook-analysis/"},"frontmatter":{"title":"Analyzing Bid-Ask Spreads and Liquidity Shifts in Polymarket's 5-Minute Binary Option Orderbooks"}},"next":null}}}