Polymarket 盘口数据，
快照与增量都有。
全深度快照，加上快照之间的增量更新，按收到的样子归档，抽稀按当天生效的采集频率。按顺序重放，你拿到的是归档记录下来的那个盘口——某笔成交当时遇到的那些档位，以及它成交在哪一档——而不是别人替你抹平过的一个中间价。
归档里有什么
这里列的是归档中的盘口数据。你的 key 实际能取到哪些币种、哪些周期、哪些天，用 /v1/meta 查就行，不必信页面上的说法。- book
- 全深度盘口快照
- price_change
- 盘口增量，带最优买卖价
- best_bid_ask
- 盘口顶部，未抽稀——与 price_change 携带的是同一个最优买卖价，但每次更新都出一行，而不是按采集节奏；只有价格没有挂单量，深度仍需 book 或 price_change
- last_trade_price
- 成交流，未抽稀
- tick_size_change
- 最小变动价位的变更
为什么是这份归档
快照加增量，不只有快照
快照确立盘口，增量在两次快照之间把它推进下去。只有定期快照的归档，说不出两张之间的盘口长什么样，而你要建模的那笔成交恰恰就在那个缝里。盘口与增量流按采集频率抽稀，而这个频率在归档期间变过——所以你重放的是被采集下来的东西，不是「平台发出的每一条消息」这种承诺。
盘口顶部是例外：它是单独一条流，每次更新出一行，不随采集频率抽稀。它只带价格，不带挂单量；深度仍要从 book 和增量流读取。把盘口顶部当成深度，是唯一一种会悄无声息废掉整个回测的错误。
延迟是可测量的，不是假设出来的
book、price_change 与 best_bid_ask 三条流都带上游事件时间与我们的接收时间，两个字段分开存，从不合并成一个归一化时间戳。要建模延迟，你需要的正是这个差值——只发一个时间戳的数据源已经把它毁掉了。（结算价流还带第三个，上游服务器时间，因为那一层才有这个字段。）
到达顺序照留，乱序也不动
对一个要被重建的盘口来说，帧的到达顺序本身就是数据。一条被人悄悄重排成整齐序列的流，已经没法告诉你你的策略在那一刻会看到什么了——它告诉你的是某个清洗脚本事后的判断。我们按收到的样子归档，乱序的也照收，要不要重排由你自己定。
缺口就留成缺口，不做插值。每个文件都带字节数与 SHA-256，你可以自己证明拿到的就是我们发布的那份。补过洞之后照样能重建出一个看着完整的盘口，但那不是实际观测到的。
怎么取
一把 key，用 /v1/files 加你要的筛选。每条结果都带 sha256 和下载 url。# 列出你的 key 能取到的盘口文件（不给日期就是范围内最新的一天） curl -H "Authorization: Bearer $OT_KEY" \ "https://outcometick.com/v1/files?venue=polymarket&dataset=book,price_change&asset=btc" # 只要盘口顶部，未抽稀 curl -H "Authorization: Bearer $OT_KEY" \ "https://outcometick.com/v1/files?venue=polymarket&dataset=best_bid_ask&asset=btc" # 下载其中一个——url 由上一条列表返回，/v1/dl 会 302 到对象存储 URL=$(curl -s -H "Authorization: Bearer $OT_KEY" \ "https://outcometick.com/v1/files?venue=polymarket&dataset=book&asset=btc" \ | jq -er '.files[0].url') curl -L -H "Authorization: Bearer $OT_KEY" "$URL" -o book.jsonl.gz
上面这些，不买 key 也能先验一遍。公开样本归档是真实的一天，目录布局和文件格式与付费归档相同——让你的解析器对着它跑，校验和自己核。ot run 还能在本地用队列同一个引擎重放它。