先明确核验目标与证据边界
历史公告核验通常包含三个问题：页面是否确实来自目标交易所，内容是否在所称时间已经发布，当前看到的版本是否被删改。不同问题需要不同证据，不能因为网页使用了HTTPS，就直接推断公告内容真实。HTTPS主要保护传输过程，并不能证明发布者没有误导，也不能证明页面长期未被修改。
提供的RFC 9162介绍了证书透明度协议。该协议面向TLS服务器证书的公开记录、审计和异常发现，日志采用可追加的结构，并使用默克尔树等方法支持包含证明和一致性检查。它适合辅助核验某个域名在相关时期使用过哪些公开证书，但不等同于网站内容存档，也不能证明某一则公告的文字曾经存在。
第一步：确认官方来源与页面身份
优先从交易所官方网站、官方帮助中心、公告中心或可验证的官方社交账号进入历史公告，而不是直接相信转发链接。检查域名拼写、HTTPS连接、证书中的域名范围、页面导航和站点之间的相互链接。相似域名、短链接、带有陌生跳转的页面，都应单独标记为高风险来源。
应记录页面完整地址、页面标题、公告编号或路径、显示的发布时间、抓取时间以及页面保存文件。若公告附带PDF、图片或表格，还要分别保存附件地址和文件哈希。页面截图可帮助记录视觉内容，但截图本身不具有足够的来源证明力，最好与原始页面、网页源文件或可信存档相互印证。
第二步：核对时间、版本和内容连续性
将公告中的发布时间、更新时间、适用时区和事件时间分开记录。比如“系统维护开始时间”不一定等于“公告发布时间”，页面顶部的更新时间也可能晚于首次发布。对于同一事件，应比较公告正文、帮助中心说明、状态页和官方通知之间是否存在相互矛盾的时间线。
历史页面可能被编辑、迁移或删除，因此要保存多个时间点的证据，并比较标题、正文、附件和链接是否发生变化。哈希值只能说明两次保存的文件是否相同；如果原始文件从未被可靠保存，哈希本身无法证明文件在更早时间就存在。搜索结果摘要和用户转发截图可作为线索，但不宜单独作为结论依据。
第三步：使用证书透明度作辅助检查
RFC 9162说明，证书透明度日志用于公开记录和审计公开TLS服务器证书，关注者可以监控与域名有关的新证书。核验时，可将公告使用的官方域名与证书透明度记录进行对照，观察域名是否出现过异常证书、拼写相近的域名是否混淆，以及页面所称时期的域名基础设施是否存在明显变化。
这项检查有明确限制：证书透明度记录的是证书及其日志证明，不是网页正文、公告发布时间或交易所内部授权记录。证书存在只能说明某个域名证书被记录，不能证明该域名上的公告由交易所正确发布。因此，证书信息应与官方域名来源、页面存档、签名文件和其他独立记录结合使用。
第四步：理解数字签名与密钥管理证据
NIST SP 800-57 Part 1 Rev. 5提供了密码密钥管理的一般指导，涉及密钥保护、数字签名、公钥、私钥、密钥生命周期和密钥被泄露后的处理等概念。若公告附带数字签名或可验证的签名文件，核验者需要确认签名对应的公钥来源、签名覆盖的具体文件、签名时间信息以及公钥是否在相关时期可信。
没有数字签名并不自动说明公告是假的；许多网站公告只通过账户权限和后台发布流程维护。反过来，有签名也不代表发布内容一定真实，因为签名只能证明某个私钥对特定数据进行了签名。若私钥曾泄露、密钥已撤销，或者公钥与交易所的关联无法建立，签名证据的解释力就会下降。
适用条件与常见问题
这套方法适用于核验公开网页公告、维护通知、规则变更说明和可下载的官方文件，尤其适合需要形成审计记录的场景。它不适合仅凭技术记录判断交易所是否具备某项资质、是否履行了资产兑付，也不能替代监管机构、司法机构或专业取证人员的认定。
常见问题一：网页现在打不开怎么办？可以保留原始链接、历史截图、浏览器保存文件、邮件通知和独立存档线索，并明确标注每份材料的取得时间和可信程度。问题二：不同版本内容不一致怎么办？不要擅自合并文本，应分别保存版本，记录差异及其时间来源。问题三：证书透明度记录能否证明公告真实？不能，它主要证明证书曾被公开记录，并只能辅助判断域名与网站身份。
形成结论时，建议把证据分为“直接证据”和“辅助证据”：官方页面或带可验证签名的原始文件属于较直接的材料；证书透明度记录、搜索结果、转发截图和第三方评论属于辅助材料。最终报告应写明核验范围、取得时间、未能确认的部分和证据局限，避免把技术线索表述成对公告真实性的绝对保证。