币安与 OKX 储备证明：披露与自助核验审计

已核验的来源事实

1. 币安说明了 Merkle Tree 与 zk-SNARK 流程，用户可核验本人是否被纳入某个带日期的账户快照。 2. 币安当前自助核验指南说明，快照按月生成，并应使用与报告周期匹配的核验工具版本；报告不是实时资产页面。 3. 币安自己的说明承认储备证明存在时点和链下负债可见性限制。 4. OKX 说明了 zk-STARK 证明、公开钱包地址、可下载的储备与负债文件，以及账户资产和钱包资产的比较。 5. OKX 表示月度报告会分列交易所保管与第三方托管余额，快照数据也可能包含借贷形成的债务或负权益。 6. 两家披露都不能证明全部链下义务、未来提现条件或快照后的资产状态。

对照表

1. 控制测试：Snapshot time

交易控制披露只有转换成可测试规则才有意义。Snapshot time需要检查the exact point represented。应使用沙箱、非生产环境或最小可逆测试，然后record the timestamp beside every ratio。可以保存配置和事件证据，但绝不能记录凭据，并应验证文档所述的撤单、拒绝、减量或历史记录行为。

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

Snapshot time这一行最终应形成一条与the exact point represented绑定的监控规则。执行者应record the timestamp beside every ratio，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，conditions after the snapshot仍是独立生产风险。

2. 控制测试：Asset scope

Asset scope需要检查which coins and account products are included。应使用沙箱、非生产环境或最小可逆测试，然后match personal holdings to the coverage list。

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

Asset scope这一行最终应形成一条与which coins and account products are included绑定的监控规则。执行者应match personal holdings to the coverage list，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，uncovered asset backing仍是独立生产风险。

3. 控制测试：Liability scope

Liability scope需要检查gross balances, debt and negative equity。应使用沙箱、非生产环境或最小可逆测试，然后read the calculation rules before interpreting ratios。

审计要模拟失败路径，而不只看设置流程。off-chain obligations outside the proof因此必须保留为明确缺口。

Liability scope这一行最终应形成一条与gross balances, debt and negative equity绑定的监控规则。执行者应read the calculation rules before interpreting ratios，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，off-chain obligations outside the proof仍是独立生产风险。

4. 控制测试：User inclusion

User inclusion需要检查Merkle or zero-knowledge membership proof。应使用沙箱、非生产环境或最小可逆测试，然后download and independently verify the personal record。

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

User inclusion这一行最终应形成一条与Merkle or zero-knowledge membership proof绑定的监控规则。执行者应download and independently verify the personal record，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，incorrect operator execution仍是独立生产风险。

5. 控制测试：Wallet ownership

Wallet ownership需要检查signed messages and public addresses。应使用沙箱、非生产环境或最小可逆测试，然后verify signatures with published tools。

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

Wallet ownership这一行最终应形成一条与signed messages and public addresses绑定的监控规则。执行者应verify signatures with published tools，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，undisclosed custody arrangements仍是独立生产风险。

6. 控制测试：Balance check

Balance check需要检查on-chain holdings at the named block height。应使用沙箱、非生产环境或最小可逆测试，然后recompute the visible balance。

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

Balance check这一行最终应形成一条与on-chain holdings at the named block height绑定的监控规则。执行者应recompute the visible balance，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，assets moved after capture仍是独立生产风险。

7. 控制测试：Proof software

Proof software需要检查open-source validator and file integrity。应使用沙箱、非生产环境或最小可逆测试，然后pin versions and verify checksums。

审计要模拟失败路径，而不只看设置流程。supply-chain risk in downloaded tools因此必须保留为明确缺口。

Proof software这一行最终应形成一条与open-source validator and file integrity绑定的监控规则。执行者应pin versions and verify checksums，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，supply-chain risk in downloaded tools仍是独立生产风险。

8. 控制测试：Custody split

Custody split需要检查exchange wallets and third-party custodians。应使用沙箱、非生产环境或最小可逆测试，然后identify which balances depend on another custodian。

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

Custody split这一行最终应形成一条与exchange wallets and third-party custodians绑定的监控规则。执行者应identify which balances depend on another custodian，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，third-party liabilities仍是独立生产风险。

9. 控制测试：Audit boundary

Audit boundary需要检查cryptographic proof versus financial-statement assurance。应使用沙箱、非生产环境或最小可逆测试，然后avoid calling the snapshot a complete audit。

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

Audit boundary这一行最终应形成一条与cryptographic proof versus financial-statement assurance绑定的监控规则。执行者应avoid calling the snapshot a complete audit，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，full solvency between reports仍是独立生产风险。

10. 控制测试：Publication cadence

Publication cadence需要检查how quickly old evidence becomes stale。应使用沙箱、非生产环境或最小可逆测试，然后schedule a recurring recheck。

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

Publication cadence这一行最终应形成一条与how quickly old evidence becomes stale绑定的监控规则。执行者应schedule a recurring recheck，保存平台响应，并为异常指定责任人。文档质量是积极信号，但不能认证交易所或交易系统；在真实观察之前，future report delays仍是独立生产风险。

决策场景

场景 1：当Snapshot time成为关键约束

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

场景 2：当Asset scope成为关键约束

假设读者最关心的是which coins and account products are included，正确做法不是寻找一个适用于所有人的赢家，而是match personal holdings to the coverage list，保存证据，并在投入资金或权限前定义停止条件。

场景 3：当Liability scope成为关键约束

假设读者最关心的是gross balances, debt and negative equity，正确做法不是寻找一个适用于所有人的赢家，而是read the calculation rules before interpreting ratios，保存证据，并在投入资金或权限前定义停止条件。

场景 4：当User inclusion成为关键约束

假设读者最关心的是Merkle or zero-knowledge membership proof，正确做法不是寻找一个适用于所有人的赢家，而是download and independently verify the personal record，保存证据，并在投入资金或权限前定义停止条件。

场景 5：当Wallet ownership成为关键约束

假设读者最关心的是signed messages and public addresses，正确做法不是寻找一个适用于所有人的赢家，而是verify signatures with published tools，保存证据，并在投入资金或权限前定义停止条件。

场景 6：当Balance check成为关键约束

假设读者最关心的是on-chain holdings at the named block height，正确做法不是寻找一个适用于所有人的赢家，而是recompute the visible balance，保存证据，并在投入资金或权限前定义停止条件。

常见问题

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

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

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

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

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

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

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

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

最安全的第一步是什么？

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

来源与编辑方法

产品可用性、费用、控制措施与法律条款可能因地区、签约实体、账户等级和时间而变化，采取行动前应核对官方实时页面与本人账户界面。