For P&H Capital
For P&H Capital
Aggregated social metrics for the underlyings behind the 300 most liquid Binance
perpetual contracts, in 17,520 hourly buckets per asset covering
2024-08-11 00:00 → 2026-08-10 23:00 UTC. Parquet, no raw posts, drop straight
into your data lake. Every bar in this file was already past the settlement line when it was
written, so nothing in here can be revised out from under a backtest. The extended file carries
all 531 Binance perp underlyings we cover, so you can define the
universe yourself without a redelivery. Query it below. DuckDB runs in your browser, straight
against the Parquet, and nothing leaves your machine.
This was your first question on the call, so it gets the first section. LunarCrush hourly metrics move for roughly 72 hours after a bucket closes: posts published inside the bucket keep accruing interactions, and late discovery adds posts retroactively. After that window the bucket is memorialized and does not change again.
We verified it rather than asserting it. 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. So the delivery is cut at
2026-08-10 23:00 UTC, which was already 90 hours old
when the file was built. Re-pull this window in six months and you get these same numbers.
as_of parameter, it always returns current
best-knowledge. For live trading the right pattern is to poll hourly and store your own vintages,
or to take scheduled vendor-delivered PIT snapshots, and we can set the latter up. Second, do not
reconcile these bars against the 24h rollup endpoints (/coins/list/v2); those are
computed on a different path and sit 1–3% off the sum of hourly bars structurally. The hourly
series is the authoritative one.
Every PERPETUAL contract on Binance futures, with the contract-size prefix
normalized off (1000PEPE → PEPE) and quote variants collapsed onto
the underlying, because social data is per-asset not per-contract. 24h USD volume summed
across the variants, ranked, top 300 taken.
One caveat that will change your universe: a single 24h volume snapshot is a noisy liquidity measure, because freshly listed contracts spike straight to the top of it. Ranking the same universe by open interest instead swaps roughly 50 names in and out of the top 300. Both ranks ship in the manifest and the extended file carries all 531 underlyings, so you can re-cut on a 30-day ADV, an OI floor or a spread cap without waiting on us.
| # | Asset | Binance contracts | 24h volume | Open interest | Bars | Coverage | History from |
|---|---|---|---|---|---|---|---|
| Loading universe… | |||||||
Binance liquidity snapshot 2026-08-14 via the CoinGecko binance_futures derivatives feed, because
fapi.binance.com refuses US-origin requests (HTTP 451). Full table in
lunarcrush_pnh_universe.csv.
LIT is Lighter on Binance and Litentry almost everywhere else.
OPEN is OpenLedger on Binance and Opendoor Technologies as an equity ticker.
Asking a social data vendor for "LIT" and getting something back is easy; getting
the right thing back is not. So every asset here was resolved deliberately, and the result
is recorded on every row of the manifest.
Each Binance base asset was resolved against the LunarCrush API, the returned entity receipt compared to the project CoinGecko lists behind that exact contract. Where they disagreed and a correct entity existed, the whole 24-month series was re-pulled by LunarCrush numeric id instead of the ticker. Where no correct entity existed we kept the series and flagged it rather than quietly shipping it.
| # | Asset | Project on the Binance contract | LunarCrush entity | Topic | LC id |
|---|---|---|---|---|---|
| Loading… | |||||
MET landing on MetLife, ARX on Accelerant Holdings or OPEN
on Opendoor, treat the series as suspect until it is mapped by hand. Ask and we will resolve
any of them manually and redeliver those columns.
Computed live in your browser from the delivered Parquet: hours where an asset's interactions ran more than 20× its trailing week mean, one row per asset, largest first. This is the cheapest useful thing to do with the file and a reasonable first sanity check that the hourly resolution is carrying real information rather than noise.
| Asset | Hour (UTC) | Interactions | Trailing 7d mean | Shock | Posts | Sentiment |
|---|---|---|---|---|---|---|
| Querying the Parquet… | ||||||
Composite key is (asset, time). time is a UTC hour bucket, left
labelled: a row stamped 14:00 covers 14:00:00–14:59:59. Nulls are genuine
"no observation", never silent zeros.
The signal columns
posts_createdsumposts_activenever sumcontributors_creatednever sumcontributors_activenever suminteractionssumsentimentweighted avgspamexcluded aboveBlended, cross-sectional
galaxy_score0–100alt_rank1 = bestsocial_dominance% of crypto socialmarket_dominance% of mcapConvenience only, use your own marks
open high low closecross-venuevolume_24hcross-venuemarket_capUSDcirculating_supplyunitsposts_active and the two
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 / mean on the _active series. The market
columns are cross-venue aggregates, not Binance perp prints, so they will not tie out to your
execution data, so use your own marks for anything touching PnL.
DuckDB-WASM in your browser, reading the Parquet from our CDN over HTTP range requests. No
server, no auth, no telemetry: the queries run on your machine. Tables:
hourly (the top 300 panel), universe_hourly (all
531 underlyings), universe (the manifest / join table),
gaps (the coverage diff).
Native columnar Parquet, zstd compressed, one row per asset-hour, sorted by liquidity rank then time. Schemas, methodology and the honest coverage notes are in the README.