字段规格
两种容器格式，两个并不共用字段表的平台。下面列的每一项都是你在文件里真的会遇到的列或键，按数据集分开。
outcometick 是什么：Polymarket 与 Predict.fun 加密涨跌市场的 Chainlink 结算价流与盘口，以及 Polymarket 的成交流——持续采集，逐文件校验，通过 API 下载。已归档 155 个完整 UTC 日（自 2026-06-08 起；Predict.fun 自 2026-06-13 起）。Polymarket 7 个币种，Predict.fun 3 个币种。单平台订阅 ¥65/月起。
两种格式
结算流与 K 线是 gzip 压缩的 CSV，带表头。市场事件流是 gzip 压缩的 JSONL——一行一个 JSON 对象，顺序就是帧到达的顺序。归档期不做任何重排。每个文件也有 Parquet 版（/v1/files 加 format=parquet）：行和列完全相同，类型已经解析好，嵌套字段保留为嵌套列。
结算流 —— CSV（Polymarket 侧）
prices、twap30s、twap60s 共用同样这五列。整个归档里只有这里同时带三个各自独立的时间戳（至 2026-10-19 UTC）；server_ts_ms 自 2026-10-20（UTC）起为空。
| feed_ts_ms | 事件时间：上游给这条报价打的时间戳（UTC 毫秒） |
| value | 浮点价格，查询方便用 |
| full_accuracy_value | 只要 relay 发布，这里就是同一个价格的定点整数串（1e18）。要重算输赢就用这个，别用 value |
| server_ts_ms | 上游服务端发出的时间（UTC 毫秒）；2026-10-20（UTC）起为空 |
| recv_ms | 我们收到的时间（UTC 毫秒）。三个分开存，从不合并——延迟链路你可以自己量 |
市场事件 —— JSONL 的信封（Polymarket 侧）
book、price_change、best_bid_ask、last_trade_price 的每一行都带同样六个顶层键。注意这里是两个时间戳而不是三个，而且事件那个不叫 feed_ts_ms。
| slug | 这一帧属于哪个市场 |
| asset_id | 这一帧说的是哪个 outcome token。price_change 上为 null，因为那种行一次携带两侧的变化 |
| event_type | 与 dataset 同名 |
| event_ts_ms | 上游事件时间（UTC 毫秒） |
| recv_ms | 我们收到的时间（UTC 毫秒） |
| payload | 上游的消息体，按收到的样子保留 |
payload 里有什么，按数据集分
| book | bids 与 asks，各是一个 {price, size} 对象数组，另有 hash、market、asset_id、timestamp。一行只是一个 outcome token 的盘口快照（是哪个看信封的 asset_id），它的两侧档位都在这一行里。某一侧是空数组表示那一侧没有挂单，不是「这次没报」 |
| price_change | price_changes 是一个数组，每项带 hash、side、size、price、asset_id、best_ask、best_bid。两个 outcome token 出现在同一行里，这也是信封上 asset_id 为 null 的原因 |
| best_bid_ask | 针对某个 asset_id 的 best_bid、best_ask 与 spread。只有价格——这条流没有挂单量，深度仍要看 book 或 price_change |
| last_trade_price | 针对某个 asset_id 的 side、size、price、fee_rate_bps、transaction_hash |
用这些重建档位之前要知道：book 与 price_change 是按采集频率抽稀保存的，不是逐帧——快照按 outcome token、增量按市场保留，两次被保留的帧之间到达的帧不在归档里。price_change 的每一项是把某个价位设成一个绝对挂单量（size 为 0 表示删除），所以如果删除恰好落在两次保留之间，重建出来的档位里会一直留着这个价位，直到该 token 的下一行 book 整体替换它。重建方法：每个 token 从最近一行 book 开始，在其上应用 price_change，再删掉高于最新最优买价的买档和低于最新最优卖价的卖档——最优价取自不限流的 best_bid_ask（归档有这条流的日子），没有时取 price_change 那一项自带的 best_bid 与 best_ask。这样能删掉所有已被最优价越过的档位，但补不回被丢掉的帧里新增或改量的档位：在下一次快照前，某个价位可能缺失或挂单量是旧的，盘口顶部也一样，因为 best_bid_ask 只有价格、没有挂单量。要看最新的最优买卖价本身，直接读 best_bid_ask。SDK 已经按这套规则实现好了：Node 用 outcometick/data 里的 OrderBook（npm i outcometick），Python 用 outcometick.data 里的 OrderBook（pip install outcometick）。把 book、price_change、best_bid_ask 三个文件的行按 recv_ms 合并后依次喂给它，再按 outcome token 读 ladder()。
markets —— 一个市场一行
元数据、strike，以及结算结果出现之后的结算。raw 键里是上游市场对象的原样副本，结算配置就在那里面。
| slug / asset / interval_sec | 身份与时长。interval_sec 的单位是秒 |
| condition_id / token_ids | 链上标识。token_ids 有两项，第一项是「涨」——这是实测定下来的，不是假设。Polymarket Protocol V2 市场（约 2026-11-02 起新建的市场，raw.version 为 "v2"）的 token_ids 是 V2 position id，也就是 CLOB 交易它们用的 id |
| start_sec / end_sec | 市场窗口，单位是秒——不像事件流那样是毫秒 |
| resolved / outcome_prices | 结算结果。["1","0"] 表示 Up 赢，["0","1"] 表示 Down 赢。只有完整的二元对才有意义 |
| strike_value | 这一局的「要超越的价格」，是定点整数串（1e18）。无法诚实确定时为空，不会拿邻近 tick 猜 |
| raw | 上游市场对象按收到的样子保留，含 raw.cryptoMarketConfig——见市场怎么判定输赢 |
klines —— CSV
由结算流推导，所以是 OHLC，没有成交量列。ticks 数的是这个桶里有多少次结算更新，不是成交量。
| ts_ms | 桶的起点（UTC 毫秒） |
| open / high / low / close | 桶内价格 |
| ticks | 落在这个桶里的结算更新次数——是更新计数，不是成交量 |
Predict.fun 不共用上面这套字段
列名不同、档位形状不同、时间单位也不同。两个平台都订阅的话，把它们当成两种格式来处理，而不是一种格式多几个字段。
| prices（CSV） | price_feed_id、symbol、provider、publish_time、server_ts、price、recv_ms。publish_time 与 server_ts 的单位是秒，而 recv_ms 是毫秒；价格列叫 price，不叫 value |
| orderbook（JSONL） | market_id、category_slug、update_ts_ms、recv_ms、payload。payload 里 bids 与 asks 是 [price, size] 数组对——不是 Polymarket 那侧的 {price, size} 对象——另有 version、orderCount、lastOrderSettled、settlementsPending |
| markets（JSONL） | category_slug、asset、interval_label、market_id、price_feed_id、price_feed_symbol、price_feed_provider、condition_id、start_sec、end_sec、start_price、end_price、status。这里的价格是普通十进制字符串，不是 1e18 定点 |
拿它写结算校验之前有一件事要知道：status 记的是上游最后一次告诉我们的状态，而一个市场拿到 end_price 之后就不再被重读了。所以能说明 Predict.fun 市场已结算的字段是 end_price。当天数据发布时还没结束的市场（日线，以及刚过午夜开始的小时市场）在当天文件里 end_price 为空；它也会出现在次日文件里，结算值以次日文件为准。
统一市场表（Parquet，两个平台）
format=parquet 时用 dataset=markets_unified：一行一个市场，Polymarket 与 Predict.fun 同一套列，一条查询就能一起读。每个文件由同一天的 markets 文件生成，下载权限与它相同。
| venue、market_id、condition_id、slug | polymarket 或 predict。market_id 在 Polymarket 是 condition_id，在 Predict.fun 是 market_id；slug 在 Polymarket 是 slug，在 Predict.fun 是 category_slug |
| asset、interval | BTC、ETH 等；5m、15m、1h、1d |
| open_ts_ms、close_ts_ms | 开始与结束时间，毫秒（start_sec、end_sec × 1000） |
| open_price | DECIMAL(38,18)。判定涨跌所对照的价格：Polymarket 是 strike_value 除以 1e18，Predict.fun 是 start_price |
| settle_price | DECIMAL(38,18)。Predict.fun 的 end_price。Polymarket 为空，它的结算值在 settle_feed 指明的那条流里 |
| outcome | UP、DOWN 或 TIE（Predict.fun 价格不变时 50:50 兑付）。该文件里市场还没结算，或结果读不出时为空 |
| settle_provider、settle_feed | Polymarket：chainlink 与它结算所用的流（twap60s、twap30s 或 prices）。Predict.fun：小写的 price_feed_provider 与 price_feed_symbol |
| token_up、token_down | Polymarket 的 token id，文本。Predict.fun 为空 |
同一文件里出现两次的市场保留最后一行。Predict.fun 当天出货时还没结束的市场在次日文件里结算，所以同一个 market_id 出现在两天时，取有 outcome 的那一行。
想专门看其中一类： Polymarket 历史数据 · Polymarket 盘口数据 · Chainlink 结算价数据 · Polymarket 结算审计 · Predict.fun 结算审计 · Predict.fun 历史数据 · Predict.fun 盘口数据 · 与其他服务商的对比