Reading on-chain and exchange data: build a research process before an alert

Write the research question first

Start with a question you can assess without placing a trade: “What happened around occurrences of this precisely defined condition?” Our proposed workflow treats a chart as a research worksheet. Write the condition, observation window, alternative explanations and rejection criteria before choosing a threshold. Make the deliverable a documented finding rather than a trading instruction.

The English Pro Charts documentation describes analysis of on-chain, macroeconomic and exchange data. It also describes saving charts, selecting time intervals and editing a metric line’s data source. These are statements about the documentation, not a verification of feature access on a particular account. Pro Charts documentation.

Use this worksheet for BTC reserves, stablecoin reserves, Funding Rates, Open Interest, SOPR, SOSD, Realized Cap and exchange inflows. We apply an explicit editorial boundary: we leave detailed metric definitions and formulas unconfirmed where the permitted materials do not provide the corresponding methodology. The article offers our proposed verification process, not a complete technical glossary of those eight metrics.

Make a data specification you can inspect

Our proposed specification starts with the provider’s exact series name, definition, calculation method, underlying data, unit and coverage. Add the observation interval, aggregation rule, publication delay, research horizon and limitations. Leave an unanswered field marked “unresolved”. Do not turn an assumption into a completed specification.

For a first exercise, choose one series and one question. For a multi-metric study, create a separate specification for every input. For an automation experiment, add a configuration version and a record of the observations used in testing. These are our suggested working conventions rather than requirements attributed to a provider.

Treat timing as a separate research task. Record when an observation is said to apply and when you received it. Ask the provider for the expected publication delay. We do not assign a typical delay in seconds or minutes here. Our proposed rule is to exclude an unresolved series from an exercise that requires exact synchronization.

Choose a horizon in advance, such as a seven-day observation exercise with a twenty-four-hour post-event window. Those numbers are hypothetical study settings, not recommended market parameters. Write down which result would contradict your initial hypothesis. Also record which data problem would invalidate the comparison itself, such as an unexplained change in units or coverage.

Inspect reserves and inflows with separate worksheets

For BTC reserves, our proposed questions concern included exchanges, address coverage, units and revisions to historical classifications. For stablecoin reserves, request the token list, included networks and aggregation method. Keep the exact series name alongside your plain-language working label; leave the meaning of an unfamiliar aggregate unresolved until you obtain its specification.

For exchange inflows, prepare a different set of questions: what counts as a transfer, how is the destination identified, which time boundary applies and how are internal movements treated? If a series is labelled net rather than gross, ask for the calculation. Our convention keeps reserves and inflows in separate fields throughout the initial exercise.

Consider a hypothetical observation: the selected BTC reserve series rises while an inflow condition is met. Write “both conditions occurred inside the chosen window”. Then list checks rather than conclusions: matching exchange coverage, matching timestamps and an explanation of any revised labels. Do not add a statement about holders’ selling intentions to this worksheet.

For an alternative-reading exercise, create two branches. In the first, suppose the specifications match and examine the event under your original hypothesis. In the second, suppose a coverage discrepancy remains and suspend the comparison. Both branches are proposed research decisions; neither establishes an explanation for a real market movement.

Funding Rates and Open Interest need an instrument record

Our proposed Funding Rates record asks for the exchange, contract, sign convention, rate unit and applicable period. Request an explicit distinction between settled and estimated observations if both are offered in the selected tool. Keep them in separate fields until their meanings are documented.

For Open Interest, ask for the contract identifier, displayed unit and method used to combine instruments, if aggregation is involved. If you intend to compare two venues, put their specifications side by side before plotting them together. Our proposed admission rule requires either documented comparability or a clearly stated reason for treating the series differently.

A hypothetical study could examine price observations around a combination of Funding Rates and Open Interest conditions. Phrase the question neutrally: “What was the distribution of the selected price change after condition A and condition B occurred?” Do not write a directional forecast into the condition name. Use a label such as “research event 01”.

For alternative explanations to investigate, list changed instrument coverage, changed units and mismatched timing. For rejection criteria, specify unresolved methodology, insufficient observations under your chosen study rule or a mismatch between the saved configuration and the actual inputs. These are our proposed controls for this exercise, without a claim of predictive value.

Verify SOPR, SOSD and Realized Cap before interpretation

The English alert documentation lists Long Term Holders SOPR and Bitcoin Reserve on Exchanges as examples of on-chain metrics, and Funding Rates as an exchange metric example. Treat that list as a starting point for identifying series rather than a full explanation of their calculations. Alert documentation.

For SOPR, our proposed checklist requests the exact variant, provider formula, included observations and filtering rules. Ask for an explanation of any cohort label in the series name. Keep thresholds out of the research plan until the metric’s interpretation has been documented.

For SOSD, leave the acronym expansion unresolved in this article. Ask the selected data provider for its full name, methodology and a worked calculation. Our proposed convention excludes an unexplained acronym from a combined alert. A familiar-looking label should still have its own specification in your worksheet.

For Realized Cap, request the valuation formula, valuation timestamp, asset coverage and unit. Add a field for the provider’s stated interpretive limitations. We do not assign this metric a capital-inflow interpretation or a decision threshold here. Our proposed acceptance criterion is that you can explain what a single reported observation represents by referring to the methodology.

Translate the question into an alert specification

The English documentation distinguishes an Alert triggered by one condition from a Pro Alert that combines multiple conditions. It describes a time window, a sleep period after activation and a choice of activation when a condition starts, remains or stops being met. Alert and Pro Alert.

Our proposed specification contains the series identifier, operator, threshold, unit, interval, activation rule, combination window and repeat policy. Add explicit handling instructions for missing, delayed and repeated observations. In an initial exercise, use “manual review required” for cases you have not resolved.

Prepare hand-written test cases before using historical observations: a value below the threshold, exactly at the boundary, above it and returning below it. For a combined condition, include an example where the second component arrives outside the allowed window. Write the expected notification result for each case. Treat this as a test of the specification, without attaching an expected financial outcome.

Separate historical review from forward supervision

The English Backtests guide describes counting historical alert occurrences and displaying average and median price changes before and after activation. It also describes testing one condition or several conditions together. Backtests guide.

Our proposed review asks you to record the sample period, event count, research horizon and all tested variants. Keep a preparation period separate from an evaluation period. Add explicit assumptions for fees, slippage and liquidity before discussing a simulated result. Include a separate note on the risk of fitting choices to the observed history. Do not turn a historical worksheet into a promised future return.

For supervision, we propose a notification-only stage followed by manual comparison of expected and observed activations. Record discrepancies, test a stop procedure and assign responsibility for reviewing the configuration. Suggested suspension criteria include missing data, a changed definition, unresolved timing or an alert that behaves differently from its saved specification. This is our proposed oversight process, without a claim that it guarantees safety or reduces losses.

The MaxData Help Hub presents an assistant for questions about MaxData and the workspace. Help Hub. Bring it a concrete request: the exact SOSD expansion, each series’ methodology, units, intervals and publication delays. Our proposed completion rule is simple: every input has an inspectable definition, every hypothesis has a rejection criterion and every alert has a written specification.