执行质量基准（Implementation Shortfall 三层分解）

AXP-RIG-v1 已完成首轮校准并给出该窗口的 σ_rig、最小可判别差异 MDD、时钟误差界 u_clock 与配对容差 Δ_pair。本基准的所有跨平台结论都必须先过 MDD 门槛，未过门槛的差异只发布区间不下结论。

各平台已完成 KYC 的账户各一个，全部由团队成员本人实名开立。禁止多账户、禁止借用或伪造证件。记录每个账户的当前费率档位与 30 日成交量档，因为费率档会影响限价单的挂撤经济性。

各平台只读 + 交易权限的 API key（不含提现权限），经环境变量注入，永不进入仓库、日志或归档文件。若某平台无 API，该平台降级为人工执行并在数据集中标记 execution_mode=manual，人工样本不与 API 样本混池统计。

测试资金：本基准专用 €200-400 等值，视为可能全损。单笔名义上限 €300，任一时点在单一平台的余额不超过 €150。资金分批进入，先跑完最小档全部样本确认出入金正常，再放大。

标的集合固定：BTC/USDT、ETH/USDT，以及一个在 baerx 与至少两个对照平台同时上线的中小市值对。标的一旦锁定，全周期不更换；确需更换须升版本号并分开统计。

参考指数：AXP-PRICE-v1 定义的多源共识中价（成分、权重与异常源剔除规则以该规范为准）。本基准直接引用其输出，不自建指数，避免两套基准对"参考价"给出不同答案。

订单簿快照能力：能在提交订单的同一秒抓取该平台 L2 订单簿（≥20 档）并原样落盘。无此能力的平台不能参与理论 VWAP 协议（EXEC-02），但仍可参与实际成交偏离协议。

条款前置审查：逐平台阅读用户协议中关于自成交、API 使用、测试性下单与市场操纵的条款并存证。若某平台条款禁止 EXEC-07 的单账户自成交测试，该平台跳过该协议并记录条款出处，不做变通。

两名成员分工：一人负责 baerx，一人负责对照平台，通过共享倒计时同步提交；两台机器均为 AXP-RIG-v1 登记在册的测量节点，NTP 已对时。

preregistration.md 中已声明本基准的标的集合、金额档、样本量目标与发布门槛，并已推送（git 时间戳即证据），防止事后按结果挑选标的或档位。

法务与伦理清单签署：不跨账户对敲、不做渗透与撞库、429 即停、不伪装地区、不下达规模足以推动盘口的订单、不为触发特定成交结果而人为影响市场。

参考价锚定、跨平台配对与提交时刻同步

1. 从 AXP-PRICE-v1 的实时管道取参考共识中价 P_ref，落盘频率不低于 1 Hz；每条订单记录必须能回溯到提交时刻前后各 ±5 s 的完整参考序列，用于后续漂移校正与事后审计。
2. 两名执行者通过共享语音频道倒计时，在同一目标秒提交 baerx 与对照平台的配对订单。提交前 1 s 各自抓取本平台 ticker 与 L2 快照（EXEC-02 用），提交动作使用预先构造好的请求以压缩人为延迟。
3. 每条订单同时记录 CLOCK_REALTIME 绝对时刻与 CLOCK_MONOTONIC_RAW 单调计数（依 AXP-RIG-v1 的 RIG-02 纪律）；所有区间量一律由单调时钟计算，绝对时刻仅用于跨机配对。
4. 计算配对实测偏差 Δ_pair_actual = |t0_A − t0_B|。超过 AXP-RIG-v1 声明的 Δ_pair 容差（默认 250 ms）的配对标记为 pair_invalid，不进入跨平台统计，但保留在数据集中供审计——丢弃样本必须可见，不能静默剔除。
5. 记录提交时刻参考指数在过去 60 s 的已实现波动 rv_60s，用于事后按波动分层；高波动窗口的样本单独成层报告，不与常态窗口混池。
6. 同一标的、同一金额档的配对订单，买卖方向在样本序列中交替进行，避免单向持仓在测试期内累积成方向性敞口。
7. 每完成一组配对立即回填共享登记表，并对当次的原始 API 响应计算 sha256 落盘；当日结束前完成一次完整性核对（记录条数 = 响应文件数）。

Quantity measured

Δ_pair_actual = |t0_A − t0_B|（ms，单调时钟换算到公共时间轴）；rv_60s = (max(P_ref) − min(P_ref)) / median(P_ref) × 10000，窗口为提交前 60 s（bps）；样本有效性判据：Δ_pair_actual ≤ Δ_pair 且该小时 u_clock 的 p95 ≤ 5 ms

Fixed parameters

参考序列频率 ≥1 Hz（低于此则漂移校正的时间分辨率不足以匹配秒级订单生命周期）；Δ_pair 默认 250 ms（取自 AXP-RIG-v1；该值须比典型订单存活期小一个量级）；波动分层阈值取全样本 rv_60s 的三分位点，事前在 preregistration 中锁定，不按结果调整。

Sample size

每标的 × 每金额档 × 每方向 ≥30 组有效配对，跨 ≥15 个交易日，覆盖亚洲盘、欧洲盘、美盘与周末四个时段层。三个标的 × 两个金额档 × 两个方向 ≈ 360 组有效配对为目标下限；N=30 是 bootstrap 分位数区间开始稳定的经验下限，低于此只发布原始散点不发布区间估计。

Control

baerx 与至少一个对照平台在同一目标秒提交，同标的、同方向、同名义金额（差异 ≤±2%，因最小下单精度不同难以完全相等，该差异须记录并在归一化时按名义金额加权）。参考指数由 AXP-PRICE-v1 独立管道提供，不取自任何被测平台，避免用被测对象给自己当基准。

Statistical treatment

配对无效率（pair_invalid 占比）本身作为一个发布指标——它衡量的是我们仪器的配对能力而非平台质量，须与 AXP-RIG-v1 的 σ_rig 一并报告。有效样本按时段层与波动层交叉分层，各层分别报中位数与 IQR，不做跨层加权平均（不同层的市场机制不同，合并会掩盖结构）。

Reproducibility check

公开配对脚本、参考序列与全部原始响应哈希。第三方可用我们发布的 books/ 与 reference_mid.csv 重跑配对判据，验证 pair_invalid 的判定与我们一致；不一致即说明判据实现有分歧，须公开处置。

Known pitfalls

最常见的错误是用绝对时钟差算区间量，虚拟机上的 realtime 会被 NTP 微调，得到负延迟或跳变；必须用单调时钟。第二个坑是把 pair_invalid 静默丢掉，这会让样本变成非随机子集——高波动时段更容易超时，丢掉它们等于系统性剔除了最有信息量的样本。第三个坑是买卖方向不交替，测试期内累积出方向性敞口，市场一动就把执行测试变成了持仓损益。

Risk

涉及真实资金。单笔名义从 €100 档起，确认全流程正常后再上 €300 档。任何时点单一平台余额不超过 €150。每个交易日结束时把闲置资金撤回，不为省手续费长期留仓。

SUPPORTS / 确立每一条订单的提交时刻、当时的中立参考价、跨平台配对是否在容差内，以及样本在时段与波动上的分布。它是后续所有偏离量能够跨平台比较的前提条件。

DOES NOT SUPPORT / 本协议本身不产出任何执行质量结论，只建立可比性。配对成功也不意味着两个平台面对的是完全相同的市场状态——不同平台的流动性供给方不同，250 ms 内的微观状态可以有实质差异，这一点无法通过配对消除，只能通过样本量与分层来稀释。

三层偏离分解：预览价、订单簿理论 VWAP、实际成交 VWAP

1. 在提交订单前 1 s 内，抓取该平台 L2 订单簿快照（≥20 档，原样落盘为 JSON 并计 sha256）。快照与提交之间的间隔 Δ_snap 必须记录，超过 1.5 s 的样本标记 snap_stale，不用于理论 VWAP 计算。
2. 若平台前端或 API 在下单界面显示预估成交价、预估收到数量或预估费用，逐字记录该数值与其显示时刻，作为 P_preview。无预览功能的平台该字段写 null，并在报告中说明该平台不提供事前价格指示——这本身是一个披露事实，归 AXP-DISC-v1 交叉引用。
3. 用落盘的订单簿快照离线模拟吃掉同样名义金额，逐档累加直到名义金额满足，得到理论成交均价 P_sim_vwap。模拟脚本必须开源并附固定输入的黄金样例与单元测试，使第三方能验证我们的簿walk实现无误。
4. 提交订单，记录终态与全部成交明细（逐笔价格、数量、时间戳、费用），计算实际成交均价 P_exec_vwap（按数量加权，含所有部分成交）。
5. 计算三层偏离：预览偏离 prev_dev、理论偏离 sim_dev、实际偏离 exec_dev，全部以提交时刻参考中价 P_ref_submit 为共同基准，方向由 side 归一（买入为正表示付出更多）。
6. 计算兑现落差 realization_gap = 实际相对理论的差额——这一层剥离了参考价，只比较"平台自己展示的簿"与"平台自己给出的成交"，因此不受跨平台参考价争议影响，是本基准信息量最高的单一指标。
7. 对未完全成交的订单，按 EXEC-04 的口径处理，并在本协议中同时记录 fill_ratio；fill_ratio < 1 的样本在报告 exec_dev 时必须单独成层，因为部分成交的均价天然偏优（先吃到的是最好的档）。

Quantity measured

s = +1（买）/ −1（卖） prev_dev_bps = s × (P_preview − P_ref_submit) / P_ref_submit × 10000 sim_dev_bps = s × (P_sim_vwap − P_ref_submit) / P_ref_submit × 10000 exec_dev_bps = s × (P_exec_vwap − P_ref_submit) / P_ref_submit × 10000 realization_gap_bps = s × (P_exec_vwap − P_sim_vwap) / P_sim_vwap × 10000 P_sim_vwap = Σ(price_i × qty_i) / Σ(qty_i)，逐档消耗直至 Σ(price_i × qty_i) ≥ notional

Fixed parameters

订单簿深度 ≥20 档（浅于此在 €300 档可能吃穿快照）；Δ_snap 上限 1.5 s（快照与提交间隔越长，理论 VWAP 越失真；1.5 s 是人工执行下可稳定达成的上界）；金额档 €100 与 €300（两档足以显示冲击成本的非线性，又不至于大到推动盘口）；所有价格保留平台原始精度，不预先四舍五入。

Sample size

与 EXEC-01 共用样本，每层 ≥30 组有效配对。无订单簿快照能力的平台只产出 exec_dev，不产出 sim_dev 与 realization_gap，该缺口须在数据集与报告中显式标注，不得用其他平台的值补齐。

Control

同一 pair_id 下的对照平台执行完全相同的三层分解。realization_gap 的跨平台比较尤其有力：它不依赖参考价的选择，两个平台各自和自己的簿比，比较的是"谁的展示深度更兑现"。

Statistical treatment

三层偏离均报中位数与 IQR，不用均值（分布右偏且有长尾）。跨平台差异用配对差的移动块 bootstrap（块长与重采样次数沿用 AXP-RIG-v1 的 RIG-01 设定，10,000 次，BCa 区间）。配对差优于独立比较，因为它消除了共同的市场状态。发布门槛：|配对差中位数| 必须超过 AXP-RIG-v1 的 MDD，否则只发布区间并标注"差异不可判别"。

Reproducibility check

发布全部订单簿快照原始 JSON、簿walk 脚本、黄金样例与单元测试。第三方拿我们的快照重算 P_sim_vwap 必须逐位复现；任何差异都是实现分歧而非数据分歧，须公开修正。这是本基准最强的可复现性抓手——理论 VWAP 是纯确定性计算，不存在"我们那天网络不好"的辩解空间。

Known pitfalls

快照太浅是最隐蔽的失效：若 book_walked_levels 接近 book_levels_captured，说明理论 VWAP 是在不完整的簿上算的，值偏优且不可用，必须联查这两个字段。第二个坑是各平台的订单簿聚合方式不同——有的按价格精度合并档位，必须用原始 L2 而非前端展示的聚合视图。第三个坑是把含费与不含费的价格混在一起比；本基准全部使用**不含手续费**的成交价，手续费归 AXP-COST-v1 处理，两者绝不能重复计入。第四个坑是部分成交样本不分层，导致 exec_dev 被系统性低估。

Risk

涉及真实资金。市价单在薄簿上可能显著偏离预期，先在 €100 档跑满样本再考虑 €300 档；中小市值标的的 €300 档在下单前先用簿walk 估算冲击，若估算超过 100 bps 则跳过该次并记录原因，不为了拿数据而承受不合理的损失。

SUPPORTS / 确立在具体标的、金额档与采样窗口下：平台事前展示的价格指示与中立参考价差多少；按平台自己发布的订单簿应当得到什么价；实际拿到了什么价；以及展示深度与实际成交之间的兑现落差有多大。

DOES NOT SUPPORT / realization_gap 偏大不能归因为任何特定原因。低流动性、做市商在快照后撤单、快照与撮合之间的时序差、隐藏流动性、以及平台侧的处理，都能产生同样的量，本基准无法区分它们。**尤其不能据此写"平台吃客损"或"操纵滑点"。** 预览价偏离也不能确立平台误导：预览本就是估计值，且不同平台的预览口径（含费/不含费、含点差/不含点差）不同，口径差异须逐平台记录并在比较时说明。 本协议的结果不能外推到未采样的标的、金额档、时段，也不能外推到更大的机构级名义金额。

市场漂移剥离与场所可归因执行成本

1. 对每条订单，取提交时刻参考中价 P_ref_submit 与成交完成时刻（最后一笔 fill 的时间）参考中价 P_ref_done，计算订单存活期内市场自身的位移 drift_bps。
2. 从实际偏离中扣除漂移，得到漂移校正后的实现落差 IS_adj_bps。这是本基准对外发布的主指标：它回答的是"扣掉市场自己在动的部分，这个场所让我多付了多少"。
3. 同时计算未校正的 exec_dev 并一并发布。两个数都要给——校正是有假设的（假设参考指数在这几秒内代表了公允价格的移动），读者有权看到原始值。
4. 对成交耗时极短（< 500 ms）的订单，漂移项本身就很小，校正近似于无操作；对成交耗时长的订单，校正是决定性的。因此必须按 time_to_fill 分层报告校正前后的差异，让读者看到校正在何时起作用。
5. 反向检验：把同一批订单的 drift_bps 按 side 分组。若买单的漂移分布与卖单的漂移分布存在系统性差异，说明下单时机与市场方向存在相关性（例如都在同一波行情里下的单），样本存在选择偏倚，须扩大采样时段重做。
6. 对参考指数在订单存活期内出现成分源剔除或数据中断的样本，标记 ref_degraded 并从主统计中剔除，但保留在数据集中——校正依赖参考序列的连续性，序列有洞时校正不可信。
7. 把校正后的落差与 AXP-RIG-v1 的 σ_rig 比较：若 IS_adj 的量级与仪器噪声同阶，则该金额档下本基准不具备判别力，须如实报告"该档位下差异低于仪器分辨率"而不是报一个看似精确的数字。

Quantity measured

drift_bps = s × (P_ref_done − P_ref_submit) / P_ref_submit × 10000 IS_adj_bps = exec_dev_bps − drift_bps 等价展开：IS_adj_bps = s × (P_exec_vwap − P_ref_done) / P_ref_submit × 10000 —— 即以成交完成时刻的公允价为基准衡量成交价，市场位移被自然消去。 time_to_fill_ms = t_last_fill_mono − t0_submit_mono（单调时钟）

Fixed parameters

P_ref_done 取最后一笔成交时刻最近的参考采样点，插值方式为最近邻（不做线性插值，插值会在参考序列稀疏时引入虚假精度）；time_to_fill 分层阈值：<500 ms / 500 ms–5 s / >5 s，事前锁定；ref_degraded 判据：订单存活期内参考序列有任何一秒缺失，或 AXP-PRICE-v1 标记了成分源剔除。

Sample size

与 EXEC-01/02 共用样本。time_to_fill 三层中，每层 ≥20 个有效样本才发布该层结论；不足则合并相邻层并说明合并事实。

Control

配对的对照平台在同一窗口经历同样的市场漂移，因此配对差 IS_adj(A) − IS_adj(B) 是本基准最稳健的量——即使参考指数本身有偏，只要偏得一致，配对差就不受影响。这也是为什么跨平台结论优先用配对差发布，而不是各自的绝对值。

Statistical treatment

IS_adj 报中位数、IQR 与 BCa bootstrap 区间。校正效果用 exec_dev 与 IS_adj 的分位数差呈现，不用"校正减少了 X%"这类相对表述（分母接近零时会爆炸）。side 分组的漂移分布差异用两样本稳健检验（如 Brown-Mood 中位数检验）筛查选择偏倚，该检验只用于诊断样本质量，不作为平台结论。

Reproducibility check

发布 reference_mid.csv 全序列、逐订单的 P_ref_submit / P_ref_done 取值点索引，以及校正脚本。第三方拿同一序列重算 IS_adj 必须逐位复现。另发布一份"校正敏感性"附表：用 ±1 s 的参考取值点重算 IS_adj，展示结论对取点的敏感度——若结论随取点翻转，则该结论不发布。

Known pitfalls

最大的概念错误是只报校正值不报原始值，读者无法判断校正做了多少工作。第二个坑是在参考序列稀疏时做线性插值制造虚假精度。第三个坑是忽略 below_mdd 标记，把低于仪器分辨率的差异当成真实差异发布——这是评测最容易失信的地方，因为它一旦被指出，整套数据的可信度都会被连带质疑。第四个坑是买卖方向与行情方向相关而不自知，drift 的 side 分组检验就是为了抓这个。

Risk

无额外资金风险（复用 EXEC-01/02 的订单）。纯离线计算。

SUPPORTS / 确立在具体标的、金额档、时段与波动分层下，扣除市场自身位移之后，各平台的实现落差中位数及其不确定度区间，以及跨平台配对差是否超过仪器的最小可判别差异。

DOES NOT SUPPORT / 漂移校正建立在"参考共识指数代表了这几秒内的公允价格移动"这一假设上。在参考成分源本身也在剧烈波动或流动性枯竭时，该假设弱化，校正后的值不比未校正的更可信——这也是为什么两个值必须同时发布。 IS_adj 不能确立平台撮合引擎的性能、不能确立平台是否优先撮合自营流、不能外推到机构级名义金额（大单的冲击是非线性的），也不能作为"该平台整体更好或更差"的依据——执行只是众多维度之一。

分段耗时、部分成交与终态分类

1. 为每条订单记录四个时刻（全部用单调时钟计算区间）：t0 提交、t1 平台回执并返回订单 ID、t2 首笔成交、t3 终态（完全成交、部分成交后过期、或被拒）。
2. 拆出三段耗时：提交到回执 ack_latency、回执到首笔成交 first_fill_latency、首笔到终态 completion_latency。分段的意义在于把网络与接口链路（AVAIL 的范畴）与撮合行为分开——ack_latency 主要反映链路，须减去 AXP-AVAIL-v1 当期同平台的基线延迟后再解读。
3. 终态分类必须穷举且互斥：FILLED（完全成交）、PARTIAL_EXPIRED（部分成交后到期或被撤）、REJECTED（平台拒单）、ERROR_UNKNOWN（响应缺失或超时且事后无法确认终态）。ERROR_UNKNOWN 必须单独统计——把它并入任何一类都会污染结论。
4. 对 REJECTED，逐字记录平台返回的错误码与文案原文，不做归纳改写；错误码分布本身是一个可发布的披露质量指标（交叉引用 AXP-DISC-v1）。
5. 对 PARTIAL_EXPIRED，同时记录 fill_ratio 与未成交部分的剩余名义。报告 exec_dev 时部分成交样本必须单独成层——先成交的部分天然是簿上最好的档，混池会系统性高估执行质量。
6. 对 ERROR_UNKNOWN，在事后 T+1 通过账户流水与成交历史反查真实终态并回填 resolved_status；无法反查的保持 UNKNOWN 并计入"不可确认率"这一独立发布指标。
7. SDK 自动重试必须关闭。若使用的客户端库默认重试，须在代码中显式禁用并在 REPRODUCE.md 中说明——自动重试会把失败洗成成功，是执行质量测量中最隐蔽的数据污染源。

Quantity measured

ack_latency_ms = t1 − t0（单调） first_fill_latency_ms = t2 − t1 completion_latency_ms = t3 − t2 ack_latency_adj_ms = ack_latency_ms − AVAIL_baseline_p50_ms（同平台同期基线） fill_ratio = 已成交名义 / 提交名义 不可确认率 = count(ERROR_UNKNOWN 且未能反查) / 总提交数

Fixed parameters

客户端超时 30 s（长于绝大多数撮合，短于人工可接受的等待）；重试次数 0（强制）；T+1 反查窗口 24 h；AVAIL 基线取同平台、同节点、同 24 小时窗口的 p50，避免用跨期基线做减法。

Sample size

与 EXEC-01 共用。终态分布的统计需要更大样本才稳定：REJECTED 与 ERROR_UNKNOWN 是低频事件，若总样本中某类终态少于 5 例，只报原始计数不报比率（小分母的比率没有意义）。

Control

配对平台同窗口执行同样的分段记录。ack_latency 的跨平台比较必须先各自减去自己的 AVAIL 基线，否则比较的是网络路径差而不是平台行为——这正是 AXP-RIG-v1 存在的理由。

Statistical treatment

各段耗时报 p50/p90/p99 与最大值，不报均值。终态分布报计数与 Wilson 区间（小样本下比正态近似可靠）。分段耗时之和应等于端到端耗时，每条记录都做这个恒等校验，不等则标记 timing_inconsistent 并排查——这是一个廉价而有效的数据质量闸门。

Reproducibility check

发布客户端配置（含显式的零重试与超时设定）、原始响应与时刻字段。第三方可用同配置复跑并比较自己的 ack_latency 分布；若其分布与我们相差远超各自的 AVAIL 基线差，说明某一方的客户端实现有额外开销，须共同排查。

Known pitfalls

SDK 默认重试是头号污染源，必须显式关闭并在数据集中留证。第二个坑是把 ERROR_UNKNOWN 并入失败或成功——两种并法会把结论推向相反方向，唯一正确做法是单列。第三个坑是不减 AVAIL 基线就跨平台比 ack_latency，得到的是机房到机房的距离。第四个坑是部分成交样本混池，systematically 高估执行质量。

Risk

涉及真实资金。ERROR_UNKNOWN 状态下资金去向不明，必须在 T+1 完成反查并核对账户余额；反查未果的样本要暂停该平台的后续加码，先解决资金归属问题。

SUPPORTS / 确立在采样窗口内各平台的分段耗时分布、终态分布、部分成交比例，以及在扣除各自网络基线后的回执延迟差异。同时确立我们自己的不可确认率——这是对本刊数据完整性的自我披露。

DOES NOT SUPPORT / 分段耗时不能确立平台撮合引擎的内部性能：ack_latency 里仍混有平台前置网关、鉴权、风控检查等环节，本基准无法进一步拆分。REJECTED 比例高不等于平台不稳定，也可能是我们的参数触发了合理的风控。**平台文档中关于"撮合延迟 X 微秒"的表述属文档类证据**：它能确立平台声称了什么，不能确立我们观测到的端到端耗时；我们的观测同样不能证伪它，因为两者测的不是同一段。

撤单确认延迟与挂单存活期行为

1. 挂一张远离盘口的限价单（价格偏离最优价 ≥50 bps，确保不会意外成交），记录挂单回执时刻，等待固定时长后发起撤单，记录撤单请求时刻 t_cancel_req 与撤单确认时刻 t_cancel_ack。
2. 撤单确认后立即查询订单状态，确认终态为 CANCELED 且未成交量等于原始量；若出现"撤单确认但仍有成交"的情况，单独记录为 cancel_race 事件——这是一个高价值的低频观察。
3. 重复该协议覆盖三种挂单存活期：立即撤（<1 s）、短存活（60 s）、长存活（600 s）。存活期不同可能触及平台不同的订单管理路径。
4. 同时测试通过 API 撤单与通过前端界面撤单两条路径（若平台同时提供），记录两者的确认延迟是否一致——差异本身是产品行为的事实。
5. 对支持批量撤单或"撤销全部"的平台，单独测该接口的确认延迟，但不与单笔撤单混池统计。
6. 记录撤单期间平台是否返回中间态（如 PENDING_CANCEL）及其持续时长；有中间态与无中间态是两种不同的产品设计，须如实区分而非归一。
7. 全程只操作本账户自己的订单，不做任何形式的高频挂撤压力测试；单个测试日内每平台撤单操作不超过 60 次，避免触及平台的挂撤比限制或被判定为异常行为。

Quantity measured

cancel_ack_latency_ms = t_cancel_ack − t_cancel_req（单调） cancel_ack_latency_adj_ms = cancel_ack_latency_ms − AVAIL_baseline_p50_ms cancel_race_rate = count(撤单确认后仍发生成交) / 总撤单数 intermediate_state_duration_ms = t_final_canceled − t_pending_cancel（无中间态则 null）

Fixed parameters

限价偏离 ≥50 bps（足够远以避免意外成交，又不至于远到被平台拒绝）；三种存活期 <1 s / 60 s / 600 s；单平台单日撤单上限 60 次（远低于任何合理的挂撤比阈值，且足以在 15 个交易日内积累样本）；订单大小取该标的最小下单量的 1-2 倍（撤单测试不需要大额，减少意外成交的损失敞口）。

Sample size

每平台 × 每存活期 ≥25 次撤单，跨 ≥10 个交易日。cancel_race 是低频事件，若零次发生，报"在 N 次撤单中未观察到"并给出 Wilson 上界，不写成"不存在该风险"。

Control

配对平台在同一时段执行相同的三种存活期测试。跨平台比较同样必须先减去各自的 AVAIL 基线。

Statistical treatment

撤单延迟报 p50/p90/p99 与最大值。三种存活期分别统计，不合并（不同路径）。cancel_race_rate 用 Wilson 区间；零事件时报单侧上界（规则三：N 次零事件的 95% 上界约为 3/N）。

Reproducibility check

发布撤单脚本、限价偏离参数与全部原始响应。第三方复跑时应得到同量级的 p50；由于撤单延迟对网络位置敏感，比较前必须双方都披露各自的 AVAIL 基线。

Known pitfalls

限价偏离设得太近会导致意外成交，污染样本且造成损失；偏离太远部分平台会直接拒单。第二个坑是把三种存活期混池——它们可能走不同代码路径。第三个坑是高频挂撤：既可能触发平台风控，也可能被认定为异常交易行为，本协议的 60 次/日上限是保守设计，不要为了样本量突破它。

Risk

涉及真实资金但敞口极小（最小下单量、远离盘口）。真实风险是行为风险：高频挂撤可能触及平台条款中的异常交易条款。严格遵守日上限，且在 preregistration 中声明测试意图与时间窗，必要时事前告知平台。

SUPPORTS / 确立在采样窗口内各平台单笔撤单的确认延迟分布、是否存在中间态及其时长、以及在我们的样本量下是否观察到撤单竞态。

DOES NOT SUPPORT / 撤单延迟不能确立平台在高负载或极端行情下的撤单表现——我们的测试都在常态负载下进行，且我们无法也不应该制造负载。零 cancel_race 观察不能确立平台不存在竞态，只能给出一个上界。也不能据此推断平台的订单管理架构。

限价单公平性的可观测代理指标（不证明 FIFO）

1. **先明确本协议的能力边界并写进方法页**：在没有带订单 ID 的逐笔成交公开数据的前提下，价格-时间优先（FIFO）**既无法被证明也无法被证伪**。本协议只产出可观测的代理指标，不产出排队公平性结论。
2. 在最优买价（或卖价）挂一张限价单，记录挂单确认时刻与当时该价位的可见挂单总量 queue_ahead_visible。
3. 持续订阅该平台的公开成交流，监测是否出现"市场以该价位或更优价格发生了成交，且累计成交量超过 queue_ahead_visible，但我们的单未成交"的情形。这种情形记为一次 trade_through_no_fill 事件。
4. 对每次事件记录：穿越时的累计成交量、我们单的未成交量、事件持续时长，以及事件结束时我们的单是否最终成交。
5. 同时记录相反的正面观察：我们的单在市场触及该价位后按预期成交的次数与延迟，作为分母。
6. 对每个平台，把该代理指标与其公开文档中声明的撮合规则并列呈现（文档声明取自 AXP-DISC-v1 的取证）。并列不是比较真伪，而是让读者看到"平台声称什么"与"我们观察到什么"两条独立的信息。
7. 隐藏流动性检查：若平台文档提及冰山单或隐藏单，则 queue_ahead_visible 天然低估真实队列，该平台的 trade_through_no_fill 率不可与无隐藏单的平台直接比较，须在报告中标注。

Quantity measured

trade_through_no_fill_rate = count(穿越但未成交事件) / count(市场触及我方价位的总次数) queue_ahead_visible = 挂单确认时刻，同价位在我方之前的可见挂单总量（基础币） excess_volume_ratio = 穿越期间该价位累计成交量 / queue_ahead_visible —— 该比值 >1 且我方仍未成交，才构成一次事件；比值越大，视觉上越异常， 但仍不构成 FIFO 违反的证据（隐藏流动性、同价位新增挂单均可解释）

Fixed parameters

挂单量取最小下单量的 1-2 倍（越小越不影响盘口，也越不容易改变队列结构）；excess_volume_ratio 触发阈值 1.5（留出快照与成交流之间时序误差的余量，避免边界噪声制造伪事件）；单次挂单最长观察 300 s，超时撤单；每平台每日不超过 30 次挂单观察。

Sample size

每平台 ≥150 次挂单观察，跨 ≥15 个交易日。事件为低频，若某平台零事件，报"N 次观察中未触发"与 Wilson 上界。

Control

配对平台同时段执行同一协议。但**跨平台比较该指标须极为克制**：不同平台的隐藏流动性政策、同价位新增挂单速率、成交流的推送完整性都不同，差异的解释空间极大。

Statistical treatment

率值用 Wilson 区间。excess_volume_ratio 报分布而非单一统计量——分布形态比中位数更有信息量。**不做跨平台显著性检验**：解释空间过大，做检验会给读者一种可以下结论的错觉。只并列呈现各平台的率值与区间，并附完整的替代解释清单。

Reproducibility check

发布成交流订阅日志、挂单记录与事件判定脚本。第三方可用我们的原始日志重跑事件判定，验证判据实现一致。由于本指标依赖公开成交流的完整性，还须发布成交流的丢包/断连统计——推送不完整会制造伪事件，这一点必须可被第三方检验。

Known pitfalls

最危险的坑是把这个代理指标写成"不公平撮合"的证据——那是一个本数据支撑不了的指控，且一旦被平台或读者指出方法缺陷，会连累整套基准的可信度。第二个坑是忽略成交流的完整性：断连期间的成交没收到，会把正常成交误判为穿越未成交。第三个坑是在有冰山单的平台上与无冰山单的平台横比。第四个坑是挂单量过大改变了队列本身。

Risk

涉及真实资金但敞口极小。限价单在最优价可能成交，须接受这一结果并按 EXEC-02 口径记录；成交后立即平仓，不累积持仓。每日挂单次数上限 30 次，避免异常交易行为认定。

SUPPORTS / 确立在我们的观察样本中，各平台出现"市场以我方价位成交且累计量超过可见队列前量、而我方订单未成交"这一可观测情形的频率与其分布。并确立各平台公开文档对撮合规则的声明内容。

DOES NOT SUPPORT / **绝对不能支持任何关于价格-时间优先是否被遵守的结论。**没有带订单 ID 的逐笔成交公开数据，队列位置不可观测，FIFO 不可证明也不可证伪。 trade_through_no_fill 事件有多种无害解释：隐藏或冰山流动性、同价位在我方之后但被路由到不同撮合分片、成交流推送不完整、我方挂单确认与队列快照之间的时序差。本协议无法区分它们。 文档中声明的撮合规则属文档类证据：它确立平台声称了什么，不确立实际如何；我们的观测也不能证伪它。两者并列呈现，不做真伪裁决。

单账户自成交防护（STP）行为观察

1. **前置条款审查**：确认该平台用户协议未禁止单账户内的对向挂单测试。若条款禁止或表述不清，跳过该平台并记录条款出处与原文。**任何情况下都不做跨账户对敲**——那可能构成市场操纵，本协议绝对禁止。
2. 在同一账户内，先挂一张远离盘口的限价买单（偏离最优价 ≥30 bps 的被动侧），确认挂单成功并记录订单 ID 与时刻。
3. 随后在同一账户挂一张会与前者交叉的限价卖单，名义金额取最小下单量的 1-2 倍，记录提交时刻。
4. 观察结果并分类：STP_TRIGGERED（平台阻止了自成交，记录其模式：撤销较早单 / 撤销较新单 / 减量）、SELF_TRADE_OCCURRED（实际发生了自成交）、REJECTED_UPFRONT（下单即被拒）、NO_STP_NO_TRADE（两单都在但未交叉，需检查参数是否真的构成交叉）。
5. 对 STP_TRIGGERED，记录平台返回的具体模式标识与文案原文，并核对账户余额与持仓确认无实际成交。
6. 对 SELF_TRADE_OCCURRED，记录成交价、量、产生的手续费，并立即停止该平台的本协议测试——重复制造自成交没有额外信息量，且会累积不必要的手续费与异常交易记录。
7. 把观察结果与该平台公开文档中关于自成交防护的声明并列呈现（文档取证来自 AXP-DISC-v1）。
8. 每个平台本协议最多执行 3 次，且只在低波动时段进行，避免远离盘口的挂单被市场行情意外扫到。

Quantity measured

本协议为分类观察，不产出连续量。 结果域 = {STP_TRIGGERED, SELF_TRADE_OCCURRED, REJECTED_UPFRONT, NO_STP_NO_TRADE} STP 模式域 = {cancel_oldest, cancel_newest, decrement_both, other, not_disclosed}

Fixed parameters

被动侧挂单偏离 ≥30 bps（远到不易被市场扫到，近到主动单能可靠交叉）；订单量取最小下单量的 1-2 倍（自成交若真发生，损失限于手续费与最小价差）；每平台执行次数上限 3 次；仅在 rv_60s 处于低波动层时执行。

Sample size

每平台 ≤3 次。这是一个行为存在性观察，不是统计量估计，样本量小是设计意图而非局限——重复执行不增加信息且增加异常交易记录。

Control

各平台执行同一协议，但结果为分类而非数值，呈现方式为并列的行为对照表而非排序——不同的 STP 模式各有取舍，没有单一的"更好"。

Statistical treatment

不做统计推断。结果以行为对照表呈现：平台 × 观察结果 × STP 模式 × 文档声明。零次触发只能表述为"在我们的 N 次测试参数下未观察到 STP 生效"。

Reproducibility check

发布完整的下单参数（价格偏离、数量、时序）与原始响应。第三方用同参数复跑应得到同一分类结果；若结果不同，说明 STP 行为依赖账户等级、地区或其他未记录的变量，这本身是重要发现。

Known pitfalls

最严重的错误是把它扩展成跨账户对敲——那越过了市场操纵的红线，会导致封号、资金冻结，且可能有法律后果。协议里写死单账户，执行时不得变通。 第二个坑是在高波动时段执行，远离盘口的被动单被行情扫到，产生真实的方向性成交。 第三个坑是重复执行累积异常交易记录，可能触发平台风控并影响其他协议的账户可用性。 第四个坑是把"平台未披露 STP"写成缺陷——未披露是一个披露事实，归 AXP-DISC-v1 评分，不是执行质量问题。

Risk

涉及真实资金，敞口限于最小下单量的手续费与价差。真实风险是账户风险：即使单账户对向挂单在多数平台被允许，重复操作仍可能被风控标记。严格遵守每平台 3 次上限。执行前必须完成条款审查，条款不清即跳过——不确定时选择不做。

SUPPORTS / 确立在具体的订单参数、账户等级与执行时点下，各平台是否阻止了同账户内的自成交，若阻止则采用何种模式，以及平台公开文档是否披露了该行为。

DOES NOT SUPPORT / **未观察到 STP 生效不能写成"该平台没有自成交防护"**——防护可能只在特定订单类型、特定账户等级或特定参数下触发，我们只测了一组参数。 本协议也不能确立跨账户的自成交防护行为（我们不做也不应做跨账户测试），不能确立平台对第三方自成交的处理，更不能作为任何关于刷量的推断依据——刷量涉及的是平台与其他参与者的行为，本协议只观察我们自己账户内的一个功能是否存在。