先明确：核验的到底是什么
历史公告核验通常包含三个不同问题：这份内容是否曾经存在？它是否确实由该交易所发布？内容在发布后是否被修改？三个问题不能由同一种证据单独回答。网页截图可能有助于展示内容，但截图本身容易被编辑，也通常缺少可独立验证的来源和时间信息。
因此，核验结论应区分“页面曾在某时可见”“文件在某时已经存在”“发布主体身份得到确认”以及“公告中的事实或承诺后来确实发生”。其中，可信时间戳主要服务于前两项，不能自动证明公告内容真实，也不能证明交易所具备履约能力。
第一步：确认发布渠道和主体身份
先保存公告的原始链接、页面标题、完整正文、附件、图片、页面显示时间及抓取时间。优先检查交易所官方域名、官方公告系统、帮助中心、状态页面和已知的官方账号，而不是只依赖转发帖、群聊消息或搜索引擎摘要。域名相似、短链接跳转和只显示品牌标识的页面，都需要额外确认其归属。
还应比较同一公告是否出现在多个官方渠道，检查措辞、编号、附件名称和发布日期是否一致。若公告只存在于第三方截图，最多可以把它作为待核查线索，不能直接当作已确认的官方文件。对于已经更换域名或停止运营的平台，应记录旧域名、新域名、公告链接之间的关联，但不要仅凭名称相似就认定两个主体相同。
第二步：固定原始内容并计算哈希
对网页正文、下载文件和关键图片分别保存原始副本，并记录文件格式、字节大小、下载地址和保存时间。随后使用哈希函数为每个文件生成摘要值。哈希值不是内容本身，但文件哪怕只改动一个字符，摘要通常也会变化，因此可以帮助比对不同时间保存的副本是否一致。
保存时不要只保留可编辑文档或截图，最好同时保留原始下载文件、页面源代码或可复现的页面快照，并建立清晰的文件命名规则。例如可将公告日期、页面标识和文件哈希的部分值写入记录。哈希记录应与原文件分开保存，避免原文件和核验记录同时被替换。
第三步：理解可信时间戳能证明什么
RFC 3161描述了时间戳服务的基本机制：申请方先对数据计算哈希摘要，再把摘要提交给时间戳机构；时间戳响应会包含受保护的时间、摘要和相关策略信息，并由时间戳机构签名。核验时，需要确认响应状态、摘要算法、摘要值、时间戳机构标识、签名以及请求中的随机数等内容是否匹配。
实际核验中，重点是重新计算当前文件的哈希，并与时间戳中记录的摘要比较。如果一致，只能说明该数据在时间戳所示时间之前已经以该内容存在。若公告之后被修改、重新排版或替换附件，新的文件哈希通常不会再匹配原时间戳。时间戳机构的证书状态、签名用途和适用策略也应一并检查。
第四步：检查数字签名和密钥状态
如果公告文件带有数字签名，应验证签名是否对应当前文件、签名证书是否属于预期发布主体，以及证书在签署时是否处于有效状态。NIST SP 800-57强调密钥材料的保护、使用周期、备份、撤销和泄露处置；这些原则意味着不能只看到“签名有效”就停止核验，还要关注签名密钥后来是否被泄露、撤销或替换。
签名验证失败可能是文件被改动、证书链不完整、算法或软件不兼容，也可能是签名本来就不适用于该文件。相反，签名验证通过也主要说明文件与签名匹配，并不自动证明公告中的业务事实已经发生。应把“文件完整性”和“内容真实性”分别记录。
第五步：用独立证据交叉印证
历史公告最好与多个相互独立的证据进行比对，例如官方站点的其他页面、同一时期的官方邮件、监管或司法公开文件、服务状态记录、用户可验证的系统提示，以及可靠的网页存档。独立证据应尽量不是互相复制的同一份转发内容，否则数量增加并不代表证明力增加。
比对时关注时间线是否自洽：公告发布时间是否早于引用的事件，后续公告是否承认或否定前文，附件版本是否与正文匹配，页面修改时间是否只是网站系统更新。若不同证据存在冲突，应保留冲突本身，分别标记为已确认、部分确认、无法确认或相互矛盾，不要为了形成单一结论而删除不利材料。
常见问题与适用边界
问题一：截图上有日期，能否证明公告当日发布？不能。截图可以保留当时看到的内容，但日期可能来自页面文字或设备显示，缺少独立时间证明。问题二：网页存档能否证明内容真实？网页存档有助于证明某个页面曾被保存，但其覆盖范围、保存时间和完整性仍需查看，不能替代主体身份和签名核验。
问题三：时间戳能否证明交易所没有删改公告？不能。它只能锁定被盖章的具体数据；若交易所后来删除原页面，时间戳可以帮助证明保存副本的存在，但不能恢复未被保存的内容。问题四：没有数字签名是否代表公告是假的？也不能。很多网站公告并不使用文件签名，此时应依靠官方渠道、独立存档、发布账号控制权和其他同期证据综合判断。
对于争议较大的材料，建议保留原始文件、哈希值、时间戳响应、证书链、核验软件输出和证据来源说明，并记录每次复制或转换。若用途涉及诉讼、仲裁或监管提交，还应按照适用法律和机构要求进行证据保全；技术核验结果本身不等于法律上的最终认定。