RabbitGo777/btc_20260818T1100.v2.1s.parquet

BTC Up/Down 5m — one-second bars, market and underlying on one clock

Polymarket runs a Bitcoin Up or Down market every five minutes, resolved off a Chainlink TWAP of BTC/USD. This is one hour of that market on a one-second grid — and, on the same grid, the spot and perpetual books from the four exchanges the price comes from, plus the oracle stream the market resolves against.

Every grid is complete and gapless, and the winning outcome is already joined onto the prediction-market rows: features from the exchange tapes, the market's own price as a competing forecast, and the label from the resolution.

A free sample from keydata.shop/samples: one hour of the real thing, same format and naming as a paid order. Full days and more coins at keydata.shop.

Need message-level detail? The raw websocket tapes these were built from — every message, in arrival order, microsecond-stamped: https://huggingface.co/datasets/RabbitGo777/btc_20260818T1100.v2.jsonl.zst

The six files

All six cover 2026-08-18 11:00:00 – 11:59:59 UTC, 6.4 MiB in total. Each loads as its own subset; the schemas differ enough between the three kinds that pooling them into one table would mean throwing most of the columns away.

One clock

Every row is a one-second bucket stamped at its left edge, UTC, bucketed by one collector's receive time — a single Hetzner server in Finland, NTP-disciplined. So the files join on ts directly: no resampling, no tolerance window, no drift correction.

Each grid is complete and gapless: all 3,600 seconds present for every instrument. A second in which nothing traded is still a row, with book columns carrying the state as it stood and trade columns null — the difference between "nothing happened" and "no data".

Bucketing is by receive time, not venue time; event_lag_ms carries the gap, reported rather than corrected away, and the collector's Finnish location makes that hop asymmetric across venues. At one-second buckets cross-venue ordering rarely matters, but it remains ordering at the collector.

book_valid is true for every row of every file, and sequence_gaps is zero throughout: no reconnects, no dropped sequences, nothing to filter out.

The subsets

polymarket — the prediction market, with the answer attached

Thirteen consecutive 5-minute Up/Down markets. Prices are probabilities between 0 and 1, quoted in USDC at a tick size of 0.001.

A row is one second of one outcome token — Up or Down of one market — so two overlapping markets produce four rows for that second; Up and Down have 5,382 rows each. Rows exist only while a market is live on the book, which is longer than its five-minute window since markets open for trading ahead of time:

Identity and the label — ts, condition_id, asset_id, outcome, coin, interval_min, market_start_ts, market_end_ts, winning_outcome, tick_size, quote_currency. winning_outcome is the resolution denormalised onto every second of that market's life, which is what makes the file trainable as it stands. Compare it against `outcome` for a binary target.

Market state — top of book, a quote-derived bar, a trade bar, ten levels of depth per side, plus bid_size_total, ask_size_total, bid_levels, ask_levels, and the quality columns. Same shape as the exchange files below, minus the bps depth columns.

Three things to know:

• —Twelve of thirteen markets are labelled; one is not. The 11:40–11:45 market resolved outside this hour, so winning_outcome is null on its 876 rows. Filter them rather than treating null as a class.
• —Trade columns are null in 53% of seconds. These markets quote continuously but trade intermittently — which is why the quote-derived mid bar exists alongside the trade bar.
• —spread_twap is in price units, not basis points. The exchange files use bps.

chainlink — the oracle the market resolves against

The smallest file and, for the Polymarket subset, the most important: the 60-second TWAP is what the markets resolve against. Not context — the answer key.

One row per second, BTC/USD, ten columns: ts, symbol, price, twap_30s, twap_60s, the same three again as price_e18 / twap_30s_e18 / twap_60s_e18, plus event_lag_ms and n_topics. Price ranged 64,123.80 to 64,337.17 over the hour.

• —Use the `_e18` columns for anything reproducing an on-chain comparison — they are the published integers as exact 18-decimal values; the doubles lose precision.
• —About 7% of seconds are empty, with n_topics at 0 and every value null. The oracle publishes near but not exactly once a second; occasionally a second gets a partial set (n_topics of 2). The grid keeps the row so the gap is visible rather than implied.
• —event_lag_ms runs around 1.7 seconds, peaking near 3.1 — publication lag, not network latency. A market resolving at time T is decided by a value stamped earlier than T, the single most important thing to get right when joining this file to the Polymarket one.

binance, bybit, okx, coinbase — the underlying

Four files, one shared 85-column schema, so anything written against one works against all four. Each covers spot and perpetual side by side, except Coinbase, which is spot only.

Per-venue points that will bite otherwise:

• —Coinbase is the only USD-quoted venue — quote_currency is USD, not USDT. Worth checking before pooling the four.
• —Coinbase's `taker_side_inferred` is true, and only Coinbase's is. It does not label the aggressing side, so its taker_buy_volume is reconstructed from book state rather than reported — weaker evidence than the same column elsewhere.
• —OKX's `contract_size` is 0.01 for the swap and 1 for spot. Size columns are not comparable across the two without that factor.
• —Binance's depth exists here and nowhere else in the sample. Binance publishes depth as diffs with no snapshot, so the raw tape alone does not yield a full book; these ten levels were built by maintaining the book across the hour.
• —Trade counts are prints, not messages: one message can carry several trades.

What it is good for

Thirteen markets, each with its full life and its resolution, against a complete one-second picture of the four venues that determine it and the oracle that settles it. The label is attached, the grids align on ts, quiet seconds are present rather than dropped.

An hour is a sample, not a study — enough to build and debug a pipeline against, not enough to fit anything on.

Provenance, and what these are not

Collected on a single Hetzner server in Finland, subscribing to each venue's public websocket API. These files are derived: each is a one-second bucketing of a raw tape, and those tapes are published alongside as .jsonl.zst archives.

The aggregation is lossy on purpose — a second of book churn becomes an open/high/low/close and a ladder — so anything needing message-level detail, queue position, or the exact sequence of events inside a second wants the raw tape instead. What it does not do: fill gaps, smooth values, forward-fill across empty seconds, or reconcile venue clocks. Nulls are real absences. v2 is the archive format version, not a data revision.

Licence and attribution

[CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — free to use, share and build on, including commercially, provided you credit the source:

Data: keydata.shop — https://keydata.shop

The underlying data is derived from each venue's public APIs and remains subject to their respective terms. Provided as-is, with no warranty. Not investment advice. Not affiliated with or endorsed by Polymarket, Binance, OKX, Bybit, Coinbase or Chainlink.