Machine-learning data evaluation guide · By CoinNudge Research · · Guide updated 2026-10-03 · 14 min read
Can a crypto dataset train a model without future-data leakage?
A crypto dataset is ready for a prospective machine-learning experiment only when every input could have been known at the decision time, the target is measured later, and the train/test split respects time and overlapping outcome windows. A completed future-return label does not make a retrospective feature eligible. In CoinNudge's deliberately selected 15-row Market Events sample, 13 rows have a complete 24-hour outcome but only 3 have locally known features; just 1 row satisfies both conditions plus a usable active-buy field. That one row cannot train or validate a model. The sample shows the checks a buyer should run on a full dated release, not a claim that the whole paid dataset has only one eligible row.
Inspect sample row fields · Check exact coverage
Can this crypto dataset actually support machine learning?
- Define a prediction timestamp first, then filter features by feature_available_at and documented PIT eligibility rather than event_time alone.
- Keep later returns, MFE and MAE exclusively as labels or post-event analysis. Pending, gap and null labels are excluded or explicitly handled; never replace them with zero.
- In the selected 15-row sample, 13 have complete 24h outcomes but only 1 also has locally known features and usable active-buy context. No model-performance inference follows from this sample.
- Hourly controls are observations with no recorded qualifying event in the prior hour; they are not verified negatives or automatically matched controls.
Which fields must a crypto machine-learning dataset define?
Specify one row's unit before choosing features: an event, a fixed hourly observation, a completed candle or a venue-symbol-time tuple. Then freeze the decision timestamp, eligible asset universe, target horizon and unavailable-data policy. A model trained on event-only rows answers a different question from a model comparing events with eligible non-events.
For each candidate field record its unit, venue, source time and earliest usable time. A historical candle recovered after the decision date can be useful for retrospective analysis, yet it cannot be represented as a snapshot observed by CoinNudge at that earlier time. A provider should make that distinction exportable.
| ML dataset field family | Example | Eligibility question |
|---|---|---|
| Identity and decision key | symbol, venue, sample_time, row_id | What exactly is one training example? |
| Candidate features | price, quote_volume_5m, valid taker_buy_fraction | Was each value available by decision time? |
| Feature quality | feature_status, taker_status, feature_available_at | Is it locally known, retrospective, invalid or missing? |
| Future label | status_24h and return_pct_24h | Did the complete 24h window mature without a gap? |
| Release provenance | calculation_version, release ID, checksum | Can another researcher rebuild the exact row set? |
Verify: Market Events field dictionary · Point-in-time data guide
How many sample crypto rows survive a leakage-safe eligibility screen?
Only 1 of the 15 selected sample rows passed the declared locally-known, usable-active-buy and mature-24h screen; that is this historical demonstration's eligibility count, not a proportion of the current paid products. We evaluated the unchanged 2026-09-25-v2 selected sample with this declared rule: feature_status must equal locally_known, feature_pit_eligible must be true, feature_available_at must not exceed sample_time, taker_status must equal usable, and status_24h must equal complete. The row count falls from 15 to 3 when locally known and time eligibility are required, stays 3 after checking the active-buy field, then falls to 1 after 24-hour maturity. Thirteen rows have a complete 24-hour outcome on their own, but 12 of those are retrospective at this strict feature-availability test.
The retained row is a DOGEUSDT recorded price event. It is a concrete schema check, not a viable training set. A buyer must run the same eligibility query on the exact paid release, requested assets and calendar period. Even a larger count requires non-overlapping or embargoed evaluation, a comparable baseline and review of class/asset balance.
| Sequential rule on selected 15 rows | Rows retained | Why this gate exists |
|---|---|---|
| All selected Market Events rows | 15 | Format sample across six spot pairs |
| Locally known and available by sample_time | 3 | Reject retrospectively reconstructed features |
| Also taker_status = usable | 3 | Require a valid active-buy field for this example |
| Also status_24h = complete | 1 | Require a mature 24h label |
| Complete 24h outcome alone | 13 | Not equivalent to eligible pre-event inputs |
Verify: Unchanged row-level sample · Selected-sample quality report · Field dictionary and status meanings
Which crypto features and labels would leak future information?
For a 24-hour direction question, information available only after sample_time is not a valid input. return_pct_24h, mfe_pct_24h and mae_pct_24h are outcomes, not predictor columns. A funding or OI number from another venue needs its own source observation and available time; matching a symbol string does not make it simultaneously known or economically identical.
A complete outcome may coexist with retrospective volume context. That row can be useful for describing what happened, but adding its future-recovered context to a historically executable model would overstate what was known. Treat event_time, event_recorded_at, price_time, feature_available_at and derivative_available_at as distinct concepts.
| Candidate column or state | Possible ML role | Required handling |
|---|---|---|
| price / quote_volume_5m | Feature if eligible | Check closed bar and available time |
| taker_buy_fraction | Feature if usable | Require valid positive-volume source; missing is not zero |
| feature_status = retrospective | Analysis context | Exclude from historical as-known training inputs |
| return_pct_24h / MFE / MAE | Future label or evaluation | Never include in input X at the decision time |
| status_24h = pending or gap | Unmatured or missing label | Do not silently convert to flat return |
Can hourly comparison rows be used as negative training examples?
Not without defining the target. A Market Events control means no recorded qualifying event in the preceding hour on the fixed control grid. It does not certify that every possible rule was evaluated and negative. It is also not matched to an event by volatility, hour of week, asset or market regime merely because the row exists.
To estimate whether an event improves a future outcome, construct the eligible population and controls under one declared rule. Preserve excluded and unmatched rows. Split by time before choosing thresholds, and avoid putting outcome-overlapping controls in the same comparison. A highly accurate classifier on an event-only or handpicked sample may simply learn selection policy.
Verify: Market Events sample field dictionary · Full event-study coverage report
How should a crypto ML dataset be split and versioned?
Use an earlier training period, later validation period and untouched final test period, all ordered by decision availability. If a 24-hour target window overlaps the next sample, leave a suitable gap or group overlapping events so the two sides do not share the answer interval. Cross-asset rows on the same date may also share one market shock; a random row split can make a result look more independent than it is.
Store the selected release ID, schema, feature allowlist, eligibility code, exclusions and row-ID hash. Revisions or newly matured labels should create a new experiment version. A later file must not silently overwrite the training set used for a reported result.
Verify: Scikit-learn time-series split documentation · Sample file manifest · CoinNudge research method
How should you join crypto features and labels without turning nulls into signals?
Join by the declared row key and decision timestamp, and check feature availability before selecting a predictor. Do not join an OI or funding value merely to the nearest future time, and do not assume a missing active-buy amount is zero selling or zero buying.
Keep identity columns and quality flags until the final selection. Record counts before and after each gate; reject duplicate feature-label keys, unknown source-time semantics and labels with a pending or gap status. For a taker-buy ratio, require a valid numerator and positive quote-volume denominator before dividing. An imputation fitted on all dates would expose the training pipeline to the test distribution; fit any documented preprocessing only on the training partition.
Use complete future returns or MFE/MAE only as labels or evaluation columns. A row with a mature outcome but later-recovered context can answer a retrospective descriptive question, not what a live model necessarily knew. The preserved 15 → 3 → 1 sample funnel demonstrates that distinction, not the usable proportion of another dataset.
Verify: Historical sample schema and time-status definitions · Frozen sample row-level evidence
What would constitute a credible crypto ML evaluation rather than a high accuracy score?
Compare a frozen model with simple baselines on a later untouched period, using the same eligible rows and costs where a trading claim is made. Report population, class balance, missingness, time coverage and economic outcomes as well as a prediction metric; a selected-event classifier can be accurate at learning the selection rule without finding a trading advantage.
Freeze training, validation and test boundaries by decision time. Remove or separate any training label interval that reaches into validation/test; enforce the same policy across symbols sharing market shocks. A chronological splitter alone does not automatically purge variable-length outcome overlap. Fit thresholds, scalers and feature selection using earlier data only, then save their versions.
Retain the source edition, allowed feature list, row-ID hash, exclusion ledger, split dates, overlap policy and baseline outputs. When later labels mature or a source is revised, create a new experiment version. This guide supplies a screening method and selected sample audit, not a completed model trial or an asserted minimum training size.
Verify: Chronological split reference and its gap parameter · Immutable sample manifest · Validate AI strategy backtests
What should a buyer test before purchasing crypto training data?
Run acceptance on the exact proposed pack edition and historical period. Calculate usable rows by symbol, month, event kind and time-availability state, not just a headline total. Audit null reasons, label maturity, overlapping horizons, revisions and historical universe membership.
The retained 15-row illustration demonstrates fields and why its strict screen retains only one row; it cannot certify the current pack catalogue or a training population. New purchases are fixed-edition research packs with defined feature and label files, not the old six-pair monthly plans. A retrospective feature pack can support a retrospective model study but must not be marketed as an as-known live history.
Reject the proposed experiment when available-time evidence is missing for an as-known claim, when evaluation rows overlap the training target interval, or when a must-have group disappears without an exclusion count. The remedy is to change the claim, obtain suitable evidence or redesign the population—not to fill unknown features with zero.
| Acceptance check | Pass evidence from proposed release | Fail or HOLD condition |
|---|---|---|
| As-known inputs | Feature available by each decision time | Retrospective columns presented as live features |
| Mature labels | Complete outcome window with missing reasons | Pending treated as zero or dropped without count |
| Population | Dated symbol/event/control counts and exclusions | Only present-day surviving coins or handpicked winners |
| Reproducibility | Schema, version, row IDs and manifest | Unversioned rows or silent revisions |
| Legal delivery | Permitted use, users, redistribution and scope | Unclear rights for the planned training workflow |
Verify: Current coverage catalogue · Evaluate a selected sample · Data quality buyer checklist
Take the next step with this evidence.
Choose ongoing Telegram monitoring or inspect structured data in your own research workflow.
Receive qualifying events in Telegram.
Use the ready-made alert checklist, message explanations and daily briefing. Check the supported categories and coins before subscribing; every Research page is not a separate alert category.
Check the alert list · View alert plans
Inspect the data before choosing a pack.
Prepared research packs supply scoped features, separate outcomes where available and quality flags. Buy a fixed edition once and download directly; API use is optional.
Check data pack samples · Explore the full data catalog · Compare data plans
Each purchased pack includes its specified fields and published date range. This page's full dataset is not automatically included. Other data families require coverage, date, field and source-use confirmation before purchase. Telegram Pro is a separate 30-day service; historical packs are one-time purchases.
Frequently asked questions
Can I train a crypto price-prediction model on your free 15-row sample?
No reliable model can be trained or validated from this deliberately selected example. Under one strict 24h active-buy eligibility check, only 1 of 15 rows is usable. The sample exists to test field meanings and delivery.
Why is a completed 24-hour return not enough to use a row?
The target may be complete even when its proposed input features were reconstructed later. Only information actually available by the decision time belongs in a historically executable input set.
Are hourly controls negative trading signals?
No. They record no qualifying event in the preceding hour under the documented grid; they do not certify a negative result for every possible rule and are not automatically matched to an event.
Do the current crypto data packs include a ready-made profitable ML model?
No. Fixed-edition packs deliver their listed data files and quality states, not a validated profitable model. Select and audit the exact features, labels, time availability and population for the task. Retrospective data must not be presented as locally observed historical snapshots.
How can I avoid look-ahead bias in crypto ML?
Freeze the prediction time; require inputs to be available by then; put later returns only in labels; split train and test in time with a suitable overlap gap; save the exact release and eligibility code.
Sources and verification
- CoinNudge selected Market Events rows15 deliberately selected rows and timestamps.
- CoinNudge field dictionaryField meanings, nullable states and time semantics.
- CoinNudge quality reportSample-only feature and outcome status counts.
- Scikit-learn time-series cross validationOfficial chronological-split reference.
Test availability and label maturity on the dataset you intend to use.
Start with the public schema, then check a dated release against your model's exact features, population and test period.
Inspect the data sample