Point-in-time crypto data for backtesting

Current source-backed snapshot

A backtest can look accurate while using information that was not available at the simulated decision time. CoinNudge's evidence archive separates source event time, local observation time and archive ingestion time, and it labels historical backfills instead of presenting them as contemporaneously known. This page exposes actual populated data families and first/last coverage so researchers can decide what is PIT-eligible, what is reconstructed and where a study must remain out of scope.

Input documentation: CoinNudge data services · CoinNudge sample · CoinNudge API documentation · CoinNudge methodology

Observation window: Actual catalog coverage by dataset

Calculation cadence: Auto-refresh about every 21600 seconds

Calculation version: coinnudge-pit-coverage-2.1

Download current dataset: JSON · CSV Raw values retain the dataset's published precision. Free fair-use limit: 60 requests per minute per IP, shared across all Research JSON and CSV endpoints.

Observation evidence

First 30 of 4 observations. JSON and CSV contain all published evidence. CSV dataset_section distinguishes summary and observation rows.

Stored bytes equals the sum of compressed_bytes in the published coverage rows: catalog Parquet file lengths plus listed release files. It excludes revision journals, databases and unlisted archive files and is not disk allocation. Derivative catalog counts include all stored envelopes; the derivatives study separately selects its qualified 15-minute contract observations and can have a different cutoff. Archive row count is not proof of continuous coverage or point-in-time eligibility; backfills retain later ingestion times.

How to read this page

• Which CoinNudge datasets preserve what was known, observed and ingested at each point in time?
• Large row counts and old event dates do not prove continuous coverage, historical universe completeness or point-in-time eligibility.
• Inspect the table before relying on the summary.
• JSON and CSV preserve the published evidence.

What can this page tell you quickly?

Question answered

Which CoinNudge datasets preserve what was known, observed and ingested at each point in time?

Measured scope

Actual archive catalog coverage by data family

Update schedule

Recalculated about every 6 hours from stored source observations.

Do not infer

Large row counts and old event dates do not prove continuous coverage, historical universe completeness or point-in-time eligibility.

How does point-in-time data reduce look-ahead bias?

A market value can have an old event date but enter the database later through a backfill. If a backtest uses it as though it were available on the event date, future knowledge leaks into the simulation.

Filtering by feature availability and retaining revisions makes that mistake detectable. It does not remove survivorship bias or guarantee the asset universe was complete.

Why keep three timestamps?

Event time answers when the market or announcement event occurred. Observation time answers when CoinNudge first had the relevant source evidence. Ingestion time answers when the archive envelope was persisted or backfilled.

The three can be equal for live-collected records and very different for historical recovery. Collapsing them into one column destroys the distinction a research review needs.

What does the coverage table prove—and not prove?

It proves that stored partitions contain rows between published minimum and maximum event times. It helps scope an extract and exposes which data families are still young.

It does not prove every expected interval exists. Buyers should request gap counts, historical universe membership and feature-validity distributions for the exact study before purchase.

Which keys and units define one PIT envelope?

The archive record key identifies the source record inside a dataset. event_time, observed_at, ingested_at and journal_captured_at are UTC instants represented as Unix seconds in JSON and ISO 8601 on the page. Payload fields retain dataset-specific units, while the public sample_fields object shows the actual stored names.

Deduplication uses dataset plus record_key for the source observation. A new journal envelope records another capture; it is not automatically a semantic revision. Backfilled rows remain distinguishable because their observation or ingestion time is later than their source event time.

How can I verify and cite this result?

Download the page JSON for the complete snapshot and CSV for tabular evidence. Record the API dataset key `point-in-time-data-coverage`, the returned calculation_version, observation interval and named source alongside any quoted number. The visible table rounds values for readability; the downloads retain the published precision.

The stable URL remains unchanged when the data refreshes. A new calculation time does not prove every input changed, so compare source-observed timestamps and the stated actual archive catalog coverage by data family. Missing rows remain missing rather than becoming zero or a favorable estimate.

What is measured, and what is not?

Method and data boundary

Read the immutable archive catalog and active Market Events release catalog. For each populated family publish rows, compressed bytes, partitions and event-time bounds. Publish real sanitized archive-envelope samples with record key, event_time, observed_at, ingested_at and journal capture time. A backtest may use a feature only when its availability time is no later than the simulated decision; an old event date alone is never sufficient. Storage card=sum(compressed_bytes) over the displayed rows / 1073741824, rounded to two decimals. Includes listed Parquet and release file lengths; excludes revision journals, databases and unlisted archives. This is neither logical size nor disk allocation. Derivative catalog envelopes and the qualified 15-minute contract study have distinct scopes and cutoffs.

Large row counts and old event dates do not prove continuous coverage, historical universe completeness or point-in-time eligibility.

Read the complete CoinNudge methodology

Sources and verification

• CoinNudge data servicesDataset families, status and delivery model.
• CoinNudge sampleEvent, context and outcome field examples.
• CoinNudge API documentationAuthentication, limits and timestamp fields.
• CoinNudge methodologyHistorical reconstruction boundaries.

Frequently asked questions