加密交易所充值确认数：Binance、Kraken 与 Coinbase 披露审计

已核验的来源事实

1. Binance says required confirmations vary by cryptocurrency and warns that unsupported assets, networks, addresses or memos can prevent crediting. 2. Kraken distinguishes confirming, credited and successful deposit states, including a state where trading is available before withdrawal. 3. Kraken publishes asset-specific confirmation and approximate processing-time information but says network execution time can vary. 4. Coinbase tells users to use the transaction hash and correct network explorer, then distinguish on-chain confirmation from account crediting.

对照表

1. 控制测试：Asset identity

API 安全披露只有转换成可测试控制才有意义。Asset identity需要检查the exact coin or token received。在支持时使用非生产或最低权限环境创建密钥，然后match ticker, contract and supported asset。可以保存权限页面证据，但绝不能记录秘密值，并应验证被禁止的操作确实遭到拒绝。

审计应模拟失败路径，而不只看设置流程。需要追问：密钥泄露后能做什么；网络限制能阻止什么；哪个日志能发现异常；撤销需要多久。平台文档只能描述可用设置，不能证明用户或供应商配置正确。support for an unlisted representation因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。文档清楚、默认限制、IP 绑定、非对称签名、过期机制与审计可见性都是积极信号，但它们不会自动认证交易所、第三方机器人或操作者终端。真正有用的结果，是与权限和责任人绑定的整改清单。

2. 控制测试：Network identity

Network identity需要检查the chain selected at both ends。在支持时使用非生产或最低权限环境创建密钥，然后compare network names and contract addresses。

审计应模拟失败路径，而不只看设置流程。recovery after a mismatch因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

3. 控制测试：Memo or tag

Memo or tag需要检查secondary destination identifiers。在支持时使用非生产或最低权限环境创建密钥，然后copy and verify every required memo。

审计应模拟失败路径，而不只看设置流程。manual recovery eligibility因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

4. 控制测试：Transaction hash

Transaction hash需要检查the on-chain receipt and explorer record。在支持时使用非生产或最低权限环境创建密钥，然后save the hash before contacting support。

审计应模拟失败路径，而不只看设置流程。off-chain internal transfers因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

5. 控制测试：Confirmation threshold

Confirmation threshold需要检查the venue's current required state。在支持时使用非生产或最低权限环境创建密钥，然后read the live asset-specific requirement。

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

披露质量与实际安全结果要分开评分。

6. 控制测试：Credited state

Credited state需要检查whether the balance can be traded。在支持时使用非生产或最低权限环境创建密钥，然后separate displayed balance from final availability。

审计应模拟失败路径，而不只看设置流程。temporary account holds因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

7. 控制测试：Withdrawal availability

Withdrawal availability需要检查whether deposited funds can leave。在支持时使用非生产或最低权限环境创建密钥，然后wait for the platform's completed state。

审计应模拟失败路径，而不只看设置流程。risk-control delays因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

8. 控制测试：Maintenance

Maintenance需要检查wallet or node service interruptions。在支持时使用非生产或最低权限环境创建密钥，然后check the official status surface。

审计应模拟失败路径，而不只看设置流程。unannounced incident duration因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

9. 控制测试：Support evidence

Support evidence需要检查asset, network, amount, hash and redacted history。在支持时使用非生产或最低权限环境创建密钥，然后prepare a minimal evidence packet。

审计应模拟失败路径，而不只看设置流程。discretionary recovery outcome因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

10. 控制测试：Disclosure quality

Disclosure quality需要检查freshness, specificity and exception handling。在支持时使用非生产或最低权限环境创建密钥，然后date the comparison and preserve unknowns。

审计应模拟失败路径，而不只看设置流程。account-specific implementation因此必须作为审计缺口保留。

披露质量与实际安全结果要分开评分。

决策场景

场景 1：当Asset identity成为关键约束

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

场景 2：当Network identity成为关键约束

假设读者最关心的是the chain selected at both ends，正确做法不是寻找一个适用于所有人的赢家，而是compare network names and contract addresses，保存证据，并在投入资金或权限前定义停止条件。

场景 3：当Memo or tag成为关键约束

假设读者最关心的是secondary destination identifiers，正确做法不是寻找一个适用于所有人的赢家，而是copy and verify every required memo，保存证据，并在投入资金或权限前定义停止条件。

场景 4：当Transaction hash成为关键约束

假设读者最关心的是the on-chain receipt and explorer record，正确做法不是寻找一个适用于所有人的赢家，而是save the hash before contacting support，保存证据，并在投入资金或权限前定义停止条件。

场景 5：当Confirmation threshold成为关键约束

假设读者最关心的是the venue's current required state，正确做法不是寻找一个适用于所有人的赢家，而是read the live asset-specific requirement，保存证据，并在投入资金或权限前定义停止条件。

场景 6：当Credited state成为关键约束

假设读者最关心的是whether the balance can be traded，正确做法不是寻找一个适用于所有人的赢家，而是separate displayed balance from final availability，保存证据，并在投入资金或权限前定义停止条件。

常见问题

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

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

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

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

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

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

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

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

最安全的第一步是什么？

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