LunarCrush
For P&H Capital
Confidential
Trial dataset v1.0 · 14 Aug 2026

Hourly social metrics for 300 assets. 24 months, point-in-time, Parquet.

Everything LunarCrush has, hour by hour, for the 300 assets you trade: posts, contributors, interactions, sentiment, spam, our composite scores and market context. 5,175,305 rows, 17,520 bars per asset, 2024-08-11 00:00 to 2026-08-10 23:00 UTC. Every bar is past settlement, so nothing in the file can be revised under a backtest.

Rows
5.18M
300 assets × 17,520 hourly bars
Complete history
293/300
7 start later, each one explained
Settlement margin
93h
past the 72h line at the delivery cut
Columns per bar
21
7 social, 4 composite, 7 market context, plus key and knowledge time
01 · Files

Take it straight into the lake

Every file carries a SHA-256 in MANIFEST.json. The dataset joins to the universe file on asset.

Loading file list…

    
02 · Point-in-time

Why nothing in this file moves

LunarCrush hourly metrics keep changing for about 72 hours after a bucket closes: posts inside a fresh bucket keep accruing interactions, and late discovery adds posts retroactively. After that the bucket is memorialized. We verified it rather than asserting it, by re-polling the same hourly series and diffing bar for bar: every bar older than 72h came back byte-identical, and every revision sat inside the window.

The delivery is cut at 2026-08-10 23:00 UTC, which was already 93 hours old when the file was written. Re-pull this window in six months and you get the same numbers.

Every row carries its own knowledge_time. That column is time + 72h, the moment the bar's value was final. It is a deterministic offset derived from the settlement rule, not a per-bar observation, and we would rather say that plainly than dress it up. Filter knowledge_time <= your_decision_time and the lookahead question is closed at the query layer instead of in a methodology paragraph. Two caveats worth stating: this is a point-in-time snapshot, not an as-of service, because the API has no as_of parameter and always returns current best knowledge. And do not reconcile these bars against the 24h rollup endpoints, which are computed on a different path and sit 1 to 3 percent off the sum of hourly bars by construction.
03 · Schema

What is in each row

(asset, time) is the composite key. time is a UTC hour bucket, left labelled, stored naive so it joins to your Binance bars with no timezone coercion. Nulls are genuine "no observation", never silent zeros.

Social

The signal columns

  • posts_createdsum
  • posts_activenever sum
  • contributors_creatednever sum
  • contributors_activenever sum
  • interactionssum
  • sentimentweighted avg
  • spamexcluded above

Composite and keys

Cross-sectional, plus the PIT column

  • galaxy_score0 to 100
  • alt_rank1 = best
  • social_dominance% of crypto social
  • market_dominance% of mcap
  • knowledge_timetime + 72h

Market context

Convenience only, use your own marks

  • open high low closecross-venue
  • volume_24hcross-venue
  • market_capUSD
  • circulating_supplyunits
The one modelling trap in this schema. posts_active and both contributors_* series are distinct-entity counts inside the bucket. Summing them across hours double-counts anything alive for more than an hour, which quietly inflates every daily and weekly aggregate built on them. Sum interactions and posts_created; take min, max or mean on the rest. The market columns are cross-venue aggregates rather than Binance prints, so they will not tie out to your execution data.

First rows, BTC

04 · Universe

The 300, and how to pull them live

Ranked by aggregate 24h USD volume across the Binance perpetual contracts on each asset, from a snapshot taken 2026-08-14. That snapshot and the selection script both ship in the bundle, so you can re-run the cut yourself. rank_by_open_interest is in the file too, because ranking the same universe on open interest instead moves about 50 names in and out of the 300.

Pull on lunarcrush_id, not on the ticker. For 11 of the 300, a bare-ticker lookup lands on a different project, so those rows carry match_method = entity_id and the id that resolves correctly. Using the id column makes your pulls reproduce this file exactly.

#AssetNameBinance 24h volumeLunarCrush idPull by BarsCoverageNote
Loading…
05 · SQL console

Query the Parquet in your browser

Optional, and it stays cold until you ask for it. Opening the console loads DuckDB-WASM and reads the Parquet straight off our CDN with HTTP range requests. No server, no auth, no telemetry, and nothing leaves your machine.

To keep it quick, the console loads a 17 MB slice: all 300 assets, the social and composite columns, and the most recent six months. It is the same schema and the same numbers as the download, just a smaller window, and it is registered as social. The full 24-month file is registered too, as social_full, if you want to hit it from here rather than downloading it. The first query against social_full streams row groups over HTTP and takes one to three minutes depending on your line; if you want the whole thing, the download link is faster.

06 · Methodology

How the 300 were chosen

Short version, because this is universe selection and not the product. We do not carry Binance market data; the contract list is only how we decided which assets to send you.

Selection

Deterministic, and shipped as a script

  • Perpetual contracts on Binance589
  • After collapsing size prefixes and quote variants531 assets
  • Ranked on summed 24h USD volume, top300
  • Snapshot date2026-08-14

Notes

Things that would otherwise surprise you

  • 1000PEPE maps to asset PEPEsocial is per asset
  • USDT, USDC and coin-margined summedone row per asset
  • Ranking sourceCoinGecko derivatives feed
  • Reproduce withbuild_universe.py
One honest limit on reproducibility. We do not own Binance market history, so you cannot regenerate "top 300 by liquidity" as of an arbitrary past date from anything in this bundle. What you can do is re-run our exact cut: the ranking snapshot we used ships as binance_ranking_snapshot_2026-08-14.json, and build_universe.py turns it back into this universe deterministically. If you would rather define the universe yourself, send the list and we will deliver against it as-is. fapi.binance.com refuses US-origin requests with an HTTP 451, which is why the snapshot comes from the CoinGecko derivatives feed rather than Binance directly.