Developing an Open Interest Indicator: Why the Metric Diverges
Open interest for the same coin across different venues does not match exchange values — the reason is different methodology, not a calculation error.
One venue counts only perpetual contracts, another adds dated futures, a third recalculates volume into the underlying asset at the current price rather than the entry price.
Summing such numbers produces a discrepancy with the exchange interface, and it cannot be relied upon in trading logic.
Open interest aggregation begins with bringing venues to a common base: contract size, multiplier, and the timestamp according to the venue's server time. The fate of instruments traded in several settlement units is decided separately — otherwise the same coin is counted twice. We store a snapshot and revision history so that the value can be recalculated retroactively.
Data gaps during volatility are the second source of distortion. During a sharp move, venue streaming channels deliver a snapshot with a delay or drop the subscription.
If the last known number is substituted at the gap, the indicator draws a flat line and the signal is late; if zero, a false open interest reset appears.
This is addressed with a confidence flag: the value is marked as unconfirmed, overwritten by the next snapshot, and backfilled from history.
Alert latency is usually a consequence of polling and a retry queue: the signal should trigger on an actual metric change, not on a timer. Next, we break down how this is addressed in Open Interest indicator development.
What a Custom Open Interest Calculation Provides
Venues calculate open interest by different rules: at CME Group these are contracts with a fixed notional, at crypto exchanges it is volume in coins, and some venues round the value on publication.
A ready-made chart from the exchange provides an already aggregated number, so the discrepancy between sources cannot be explained, and during a sharp price move it masks the real dynamics of positions.
A custom open interest calculation is built from primary data: we pull updates from each venue, bring the value to a common base, and only then aggregate. This produces a unified cross-venue metric — one scale, consistent timestamps, and the same publication interval. The discrepancy between sources is visible as a separate series, not as an error on the chart.
Resilience to liquidations is built into the processing layer. A cascade of closes arrives as a batch of updates, some delayed or repeated: the stream is buffered, duplicates are filtered by record ID, and the missed interval is backfilled from history.
Data quality control runs in parallel — the value is reconciled with an independent source, and if the discrepancy is above the threshold, an alert fires rather than silent smoothing.
What stops breaking:
- the chart is not redrawn retroactively when the source changes;
- venue comparison remains correct on any interval;
- spikes from cascade liquidations are visible and explainable;
- a gap in a venue's stream is marked with a quality flag.
Calculation Options: Snapshots, Event Stream, Hybrid Scheme
Open interest can be collected in two different ways: by periodic polling of the venue (state snapshots) and by subscribing to a change stream, where each update arrives as a separate event.
Snapshots provide an even series without gaps between points; the stream provides minimal latency and completeness, but requires reconciliation with a snapshot to restore the value after a connection break.
What to choose is decided by the consumer's sensitivity to latency and how often the instrument universe changes on the venue. Below is an honest comparison: where each option breaks and what has to be built on top.
| Option | When it fits | Limitations |
|---|---|---|
| Venue state snapshots | Retrospective analysis, calculation from history, venues with no public event stream | Accuracy is limited by the polling interval; spikes between points are lost |
| Change stream | Signals and alerts where latency matters | A connection break creates a gap in the series; historical backfill and value reconciliation are needed |
| Hybrid calculation scheme | Production indicator with long history and live updates | More demanding to maintain: two sources, reconciliation and discrepancy resolution logic |
The hybrid turns out to be the working option: a reference snapshot at startup and on a schedule sets the base value, the change stream refines it between snapshots, and a discrepancy above the threshold triggers a rebuild of a segment of the series.
This way the indicator survives connection breaks and changes in the instrument universe without gaps.
Implementation Stages: From Requirements Analysis to Handover
We start with requirements analysis, not code: it determines which venues and contracts are included in the calculation, what history depth is needed, and how often the value updates.
Then we fix the data schema, agree on the output format, and only then build the calculation core. Each stage ends with a verifiable artifact — that is why Open Interest indicator implementation proceeds predictably, without surprises at the finish.
- Requirements analysis. We clarify the list of exchanges and instruments, the history horizon, the recalculation frequency, and the method of delivering values — dashboard, API, or event stream. Outcome: an agreed metric definition.
- Data schema. We define sources, normalization rules, and gap handling: collection gaps, contract rollover, weekends. We fix what is considered the reference when discrepancies occur.
- Building the calculation core. We implement open interest calculation, aggregation by instruments and periods, and caching. The logic is covered by automated tests before the first run on production data.
- Validation on historical data. We run the calculation on accumulated history and compare it with an independent source. This catches rounding errors, duplicates, and time zone offsets.
- Reconciliation with the venue. We compare values with exchange data at control points, analyze discrepancies, and document acceptable deviations.
- Acceptance of the calculation. We hand over the methodology and tests, grant access to monitoring, and confirm matching on an agreed set of checks.
- Handover and training. We provide source code, configuration, and operating instructions, review typical failures, and support the first independent run.
What Remains in the Customer's Environment After Delivery
After the indicator is delivered, the customer's environment retains not only the working calculation but also everything needed to maintain it in-house: update, debug, and hand it over to a new engineer. Below is the list of artifacts we record at acceptance.
- Data schema. Which fields come from exchange streams (open interest, volumes, timestamps), in what units, at what frequency, and how different venues are normalized to a common format.
- Configurations. List of sources, polling intervals, aggregation and recalculation rules, trigger thresholds — moved to separate files and editable without rebuilding.
- Indicator documentation. Calculation formulas, behavior during stream gaps, session breaks, and contract rollover, response to delayed data.
- Update procedures. Procedure for connecting a new venue or instrument, releasing changes to the calculation, and mandatory checks before rollout.
- Data access policies. Roles, access keys, separation of read and settings-change permissions, audit log.
- Failure alerts. Metrics and thresholds, notification channels, on-call sequence of actions when a stream is lost or values diverge.
- Reference datasets. Historical data slices used to verify calculation correctness after any change.
- Deployment instructions. Bring up the service from scratch, migrate it to another environment, roll back to a previous version.
We hand over each artifact with a walkthrough on a call: the engineer goes through the schema, shows where to change settings, and answers the customer team's questions.
Case Study: How the Discrepancy with Exchange Values Was Resolved
The customer is an analytics team that builds signals on futures open interest.
The indicator collected values from several venues, but they diverged from exchange dashboards by up to several percent: in some cases partial trades were lost, in others volume doubled on stream reconnection.
Every morning the analyst manually reconciled instrument slices — it took more than two hours, and some discrepancies surfaced only after a position was opened.
What changed: collection moved to the venue's event stream instead of polling, deduplication by trade ID and state snapshot storage were added.
The aggregate is now recalculated independently from raw data — if it diverges from the dashboard, the value is flagged and goes to a review queue, not into a signal.
We separately set up automatic reconciliation with a reference: at each interval the indicator compares itself with public CoinGlass data and generates a deviation report. Manual work decreased by about 90% — the analyst reviews only discrepancies above the threshold.
After the rework, the share of values with a discrepancy greater than 0.5% fell from 4% to 0.2%, and update latency — from five minutes to two seconds.
Anomalies in open interest are visible almost immediately; reaction time to a sharp rise or reset dropped from an hour to a couple of minutes. A collector failure is now noticeable by missing snapshots, not by a loss on a position.
How Does a Calculated Indicator Differ from an Exchange Value?
The exchange value of open interest is calculated by the venue itself: it sees all positions in its contracts and updates the metric on candle close or at the next slice.
The metric's accuracy is maximal, but it describes a single venue, and liquidations enter the public stream with a delay.
A calculated indicator collects the metric from several sources: we pull public trade and position streams, bring contracts to a common notional, and sum them.
The set of venues is specified explicitly — top by volume or only those where the client trades, like public aggregators such as CoinGlass. Without a liquidation filter, a cascade of forced closes produces a spike that did not exist in the market.
The main discrepancy is metric update latency: the venue publishes the value on a schedule, while the calculated series recalculates on every event and, during a sharp move, leads the exchange value.
For signals this is an advantage; for reconciliation with the venue report, it is a source of discrepancies that is accounted for in tolerances.
| Source | When it fits | Limitations |
|---|---|---|
| Exchange value | Work within a single venue, reconciliation with its reports | Does not see the whole market, publication delay, different venue methodologies |
| Calculated indicator | Consolidated analytics and signals across multiple venues | Depends on stream availability, requires normalization and a liquidation filter |
| Hybrid | Risk control: both coverage and accuracy matter | More complex to maintain, requires monitoring of source discrepancies |
The source is chosen for the task: exchange value for reporting, calculated indicator for signals, hybrid for risk control. The set of venues and liquidation processing rules are fixed in the specification before work starts.
Technical Concerns Before Starting Work
Before starting, customers check not the aggregation formula but the resilience of the data stream and the cost of further expansion. Below are the questions most often raised in technical meetings and our answers.
The indicator collects open interest from several sources: venue streaming channels and backup scheduled polling.
Each source writes to a separate storage with a timestamp, and the calculation layer merges the data into a single series — a failure of one venue does not distort the overall picture.
What happens if the connection to the exchange breaks?
The channel is automatically re-established with an increasing delay, and the missed interval is closed by backup polling for the past minutes. The point of the break is marked with a separate flag so that analytics does not mistake the gap for zero open interest.
How is calculation correctness verified?
Every hour the aggregated value is reconciled with the venue's reference response; a discrepancy above the threshold raises an alert. We separately monitor series completeness: the share of missed intervals and time to recovery are visible on one dashboard.
How much effort does it take to add a new venue?
The source is connected via a separate adapter to the common interface: contract description, field normalization, tests on historical data. A new venue does not affect the calculation core, so expansion proceeds predictably.
What is included in the support handover?
The data schema, on-call and alert procedures, instructions for typical failures, and a walkthrough with your team. If needed, we remain on support — the responsibility boundary is fixed in advance.
Let's Discuss the Task and Come Back with an Estimate and Plan
We start the task discussion with the domain part: which venues and contract types are in focus — perpetual futures, quarterly, options — whether a breakdown by exchange or a composite index is needed, over what period history is required, and how often the indicator should update.
From the customer, a scenario is enough: how the signal is used in a decision and what discrepancy with the venue's published value is considered unacceptable.
In parallel, we request access to venue data: public streams, history via API, and where available, a test environment with read-only keys.
This, even before the estimate, shows whether the depth of trades and open interest snapshots is sufficient for the calculation, or whether the source will have to be collected through an aggregator.
Then we do a trial calculation: take a window of several days for one or two contracts, calculate open interest, compare with the venue's published value, and show the discrepancy as a percentage. After that, we come back with an estimate and work plan.
What the response includes:
- list of venues and contracts: what each provides — open interest snapshots, trade feed, order book depth;
- trial calculation result — matching the published value within the specified accuracy or an analysis of the causes of divergence;
- estimate and staged work plan: data collection, calculation, indicator rendering, alerts, acceptance;
- signal delivery scheme: page widget, API, or messenger messages;
- requirements for history depth and recalculation frequency so that the indicator does not lag behind the market;
- documentation set: calculation formula, configurations, deployment instructions.