Coinbase 与 OKX 自成交保护：披露与 API 审计

已核验的来源事实

1. Coinbase Exchange says orders from the same user cannot fill one another and the taker order's STP instruction takes precedence. 2. Coinbase documents decrement-and-cancel, cancel-oldest, cancel-newest and cancel-both behaviors for the Exchange matching engine. 3. OKX says mandatory STP applies at master-account scope, including the master and its affiliated subaccounts across order-book trading products. 4. OKX documents cancel-maker as the default, with cancel-taker and cancel-both available through the API for supported orders.

对照表

1. 控制测试：Account scope

交易控制披露只有转换成可测试规则才有意义。Account scope需要检查user, portfolio, master account and subaccounts。应使用沙箱、非生产环境或最小可逆测试，然后draw the exact account relationship。可以保存配置和事件证据，但绝不能记录凭据，并应验证文档所述的撤单、拒绝、减量或历史记录行为。

审计要模拟失败路径，而不只看设置流程。需要追问哪套策略拥有 maker 与 taker 订单、平台按哪个账户边界判断、哪个消息能证明干预，以及部分成交或断线后如何对账。平台文档只能说明支持什么，不能证明操作者配置正确。behavior across unrelated legal entities因此必须保留为明确缺口。

Account scope这一行最终应形成一条与user, portfolio, master account and subaccounts绑定的监控规则。执行者应draw the exact account relationship，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，behavior across unrelated legal entities仍是独立生产风险。

2. 控制测试：Default mode

Default mode需要检查behavior when no explicit parameter is sent。应使用沙箱、非生产环境或最小可逆测试，然后pin the documented default in the strategy spec。

审计要模拟失败路径，而不只看设置流程。future default changes因此必须保留为明确缺口。

Default mode这一行最终应形成一条与behavior when no explicit parameter is sent绑定的监控规则。执行者应pin the documented default in the strategy spec，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，future default changes仍是独立生产风险。

3. 控制测试：Cancel maker

Cancel maker需要检查treatment of the resting order。应使用沙箱、非生产环境或最小可逆测试，然后model queue-position loss。

审计要模拟失败路径，而不只看设置流程。execution after a network delay因此必须保留为明确缺口。

Cancel maker这一行最终应形成一条与treatment of the resting order绑定的监控规则。执行者应model queue-position loss，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，execution after a network delay仍是独立生产风险。

4. 控制测试：Cancel taker

Cancel taker需要检查treatment of the incoming order。应使用沙箱、非生产环境或最小可逆测试，然后handle the rejection or cancellation event。

审计要模拟失败路径，而不只看设置流程。partial execution under future liquidity因此必须保留为明确缺口。

Cancel taker这一行最终应形成一条与treatment of the incoming order绑定的监控规则。执行者应handle the rejection or cancellation event，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，partial execution under future liquidity仍是独立生产风险。

5. 控制测试：Cancel both

Cancel both需要检查whether both sides are removed。应使用沙箱、非生产环境或最小可逆测试，然后reconcile both client order IDs。

审计要模拟失败路径，而不只看设置流程。race conditions among concurrent strategies因此必须保留为明确缺口。

Cancel both这一行最终应形成一条与whether both sides are removed绑定的监控规则。执行者应reconcile both client order IDs，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，race conditions among concurrent strategies仍是独立生产风险。

6. 控制测试：Decrement behavior

Decrement behavior需要检查quantity reduction rather than full cancellation。应使用沙箱、非生产环境或最小可逆测试，然后consume change or restatement messages。

审计要模拟失败路径，而不只看设置流程。rounding at product precision因此必须保留为明确缺口。

Decrement behavior这一行最终应形成一条与quantity reduction rather than full cancellation绑定的监控规则。执行者应consume change or restatement messages，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，rounding at product precision仍是独立生产风险。

7. 控制测试：Order coverage

Order coverage需要检查supported products and order types。应使用沙箱、非生产环境或最小可逆测试，然后verify the exact endpoint and order schema。

审计要模拟失败路径，而不只看设置流程。availability for a new product因此必须保留为明确缺口。

Order coverage这一行最终应形成一条与supported products and order types绑定的监控规则。执行者应verify the exact endpoint and order schema，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，availability for a new product仍是独立生产风险。

8. 控制测试：Event evidence

Event evidence需要检查REST, WebSocket and order-history signals。应使用沙箱、非生产环境或最小可逆测试，然后persist the venue's cancellation reason。

审计要模拟失败路径，而不只看设置流程。message loss during an outage因此必须保留为明确缺口。

Event evidence这一行最终应形成一条与REST, WebSocket and order-history signals绑定的监控规则。执行者应persist the venue's cancellation reason，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，message loss during an outage仍是独立生产风险。

9. 控制测试：Strategy ownership

Strategy ownership需要检查multiple bots sharing one account hierarchy。应使用沙箱、非生产环境或最小可逆测试，然后allocate account boundaries before deployment。

审计要模拟失败路径，而不只看设置流程。human orders crossing automated orders因此必须保留为明确缺口。

Strategy ownership这一行最终应形成一条与multiple bots sharing one account hierarchy绑定的监控规则。执行者应allocate account boundaries before deployment，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，human orders crossing automated orders仍是独立生产风险。

10. 控制测试：Test plan

Test plan需要检查sandbox or minimal-size collision tests。应使用沙箱、非生产环境或最小可逆测试，然后prove every configured mode before scale。

审计要模拟失败路径，而不只看设置流程。production-only edge behavior因此必须保留为明确缺口。

Test plan这一行最终应形成一条与sandbox or minimal-size collision tests绑定的监控规则。执行者应prove every configured mode before scale，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，production-only edge behavior仍是独立生产风险。

决策场景

场景 1：当Account scope成为关键约束

假设读者最关心的是user, portfolio, master account and subaccounts，正确做法不是寻找一个适用于所有人的赢家，而是draw the exact account relationship，保存证据，并在投入资金或权限前定义停止条件。只要证据变化，就重新打开决策，而不是继续沿用旧结论。这样得到的是一条能够重复执行的操作规则，而不是一次性的主观看法。

场景 2：当Default mode成为关键约束

假设读者最关心的是behavior when no explicit parameter is sent，正确做法不是寻找一个适用于所有人的赢家，而是pin the documented default in the strategy spec，保存证据，并在投入资金或权限前定义停止条件。

场景 3：当Cancel maker成为关键约束

假设读者最关心的是treatment of the resting order，正确做法不是寻找一个适用于所有人的赢家，而是model queue-position loss，保存证据，并在投入资金或权限前定义停止条件。

场景 4：当Cancel taker成为关键约束

假设读者最关心的是treatment of the incoming order，正确做法不是寻找一个适用于所有人的赢家，而是handle the rejection or cancellation event，保存证据，并在投入资金或权限前定义停止条件。

场景 5：当Cancel both成为关键约束

假设读者最关心的是whether both sides are removed，正确做法不是寻找一个适用于所有人的赢家，而是reconcile both client order IDs，保存证据，并在投入资金或权限前定义停止条件。

场景 6：当Decrement behavior成为关键约束

假设读者最关心的是quantity reduction rather than full cancellation，正确做法不是寻找一个适用于所有人的赢家，而是consume change or restatement messages，保存证据，并在投入资金或权限前定义停止条件。

常见问题

本文是否建议使用或避开某个平台或产品？

不是。它是一套基于来源的决策框架。最终结论取决于用户地区、签约实体、账户、产品、交易规模、风险承受能力与实时条款。

公布的费率或控制措施是否永久有效？

不是。公开费率和控制规则会变化，实际条款也可能针对账户。应核对登录后的实时页面。

页面返回 HTTP 200 是否证明产品正常可用？

不能。公开页面存在，不代表特定地区或账户一定能使用该产品，账户级证据才是最终依据。

为什么必须公开列出未知事项？

因为用假设填补证据空白会制造虚假精确。未知事项说明下一步应该核验什么。

最安全的第一步是什么？

写清具体任务，核验官方来源，采用最小权限和最可逆的路径，并在适合时先做小额测试。