先区分公告事实与链上事实
区块链货币交易所的历史公告通常属于交易所网站、社交账号、帮助中心或客服渠道发布的链下信息。区块链本身不会自动证明某一段文字曾由交易所发布，因此核验时应把问题拆成两部分：第一，公告是否确实来自该交易所，发布时间和版本是否可靠；第二，公告所描述的充值、提现、合约交互或资产变动，是否能在对应区块链上找到相符记录。两类证据的证明对象不同，不能相互替代。
核对公告来源和时间线
首先记录公告的完整标题、页面地址、发布时间、更新时间、发布主体以及正文版本。优先比对交易所官方域名下的公告页、帮助中心和认证账号；搜索结果摘要、转发内容、聊天记录和截图只能作为线索，不能单独作为最终依据。若原页面已经删除，可寻找网页存档、订阅邮件或同时期的官方转载，但应注意存档时间不一定等于原始发布时间，页面内容也可能在首次保存前已经被修改。
时间线核对尤其重要。应将公告中的时间统一为同一时区，再与交易哈希、区块时间和交易所公开的维护窗口进行比较。区块时间是区块头中的记录，具有链上参考价值，但它并不等同于交易所网页的发布时间，也不能单独证明公告在某个时刻已经对外发布。
用比特币记录验证交易描述
比特币网络中的区块链是按顺序连接并带有时间信息的交易记录。每个区块包含前一区块头的哈希，交易还可通过交易标识符，也就是交易哈希，进行定位。因此，当公告给出了比特币交易哈希、地址、区块高度或提现批次信息时，可以在区块浏览器或自行连接的节点中核对交易是否存在、进入哪个区块、输入输出是否与描述大致一致。
核对时不能只看区块高度。资料说明，不同分叉中可能出现相同高度的区块，所以区块哈希比高度更适合作为唯一定位信息。还要留意短暂分叉和重组：交易所在区块未获得足够后续区块前，最终归属仍可能变化。交易存在只能证明该交易被记录或曾被观察到，不能直接证明交易所已经完成内部记账、收款人身份或公告中所有业务承诺。
用以太坊交易字段验证操作类型
以太坊交易由账户发起并经私钥签名，通常包含发送地址、接收地址、数值、nonce、输入数据、燃料上限和费用参数等字段。若公告涉及代币充值、提现、合约迁移或暂停某项功能，可根据交易哈希核对发送方、接收方、区块状态以及输入数据。接收地址是普通账户时，可能代表价值转移；接收地址是合约时，则可能是一次合约调用，不能仅凭页面显示的金额判断具体业务。
合约调用的输入数据通常是十六进制编码，其中前四个字节常用于标识函数，后续内容按照合约接口编码参数。只有在合约地址、接口定义和参数解析都可靠时，才能较有把握地说明调用目的。对于交易所公告中的“已完成”“已到账”或“已支持”等表述，还应分别检查链上交易状态、事件日志和交易所账户状态；链上成功并不自动等于用户界面中的余额已经更新。
确认状态、证据一致性与适用范围
比特币核验应保存交易哈希、区块哈希、区块高度、输入输出和查询时间，并记录查询所使用的网络。以太坊核验则应保存交易哈希、区块号、状态、发送与接收地址、输入数据以及相关日志。截图容易缺少网络、时间和完整字段，最好同时保留可复查的原始页面或结构化查询结果。
以太坊交易先进入待处理交易池，再由验证者纳入区块；之后区块可能获得更高确认程度，并进一步达到已确认或最终确定状态。因而，公告若声称某操作已经不可逆，应核对的不只是交易哈希，还包括所在区块及其后续确认状态。对于尚未纳入区块的交易，只能视为待处理记录，不能当作已经完成。
常见问题
公告页面还在，是否就一定真实？不一定。应确认域名、发布主体、页面时间和正文是否与其他官方渠道一致；钓鱼页面、仿冒域名和后续修改都可能造成误判。
链上有一笔相同金额的转账，是否能证明公告属实？不能。相同金额并不唯一对应某项业务，且地址归属、内部订单和用户身份通常无法仅凭公开链上数据确定。
只有区块高度没有交易哈希怎么办？可以用地址、时间范围和金额作为检索线索，但这些条件可能对应多笔交易，证据强度低于交易哈希与区块哈希的组合。
交易状态显示成功，是否代表提现已完成？只能说明相应链上交易按该网络规则被处理成功。是否完成交易所内部审核、扣账、风控和用户侧到账，还需要交易所自身的记录或可验证的后续证据。