先明确“核验”要回答什么问题
核验一则交易所 CEO 的历史公告，通常需要分别回答三个问题：公告内容是否在所称日期之前已经存在，保存下来的文件或页面是否保持原样，以及公告是否确实由相关个人或机构发布。把这三个问题分开，有助于避免把“网页上显示了一个日期”误认为完整证据。网页日期可以被修改，截图也可能缺少来源和上下文。
时间戳和数字签名解决的是不同环节。时间戳服务可以对某份数据的摘要进行签发，用于证明该数据在某个时间点之前已经存在；数字签名则通过非对称密钥，让验证者使用公钥检查数据的完整性以及签名与私钥之间的对应关系。它们能增强证据链，但不能自动证明某个社交账号、网站或密钥一定属于 CEO。
用时间戳核对公告的历史存在性
RFC 3161 描述的时间戳协议以数据摘要为对象。申请方先对公告文件、网页存档或其他数据计算哈希值，再把包含算法标识和哈希结果的请求提交给时间戳机构。机构返回时间戳令牌，令牌通常包含时间、唯一编号、所采用的政策标识以及对令牌的数字签名。验证时，必须重新计算当前材料的哈希值，并检查它是否与令牌中的数据摘要一致。
因此，时间戳更适合支持这样的判断：某一份具体内容在时间戳所表示的时点之前已经存在。它不直接证明内容一定由 CEO 撰写，也不证明内容发布在某个交易所官方渠道。若只保存了截图而没有原始文件、页面源数据或对应摘要，通常无法完成严格的哈希比对。
核验时间戳时还要检查响应状态、时间戳机构证书、签名有效性、数据摘要算法和令牌政策。RFC 3161 的验证思路包括确认请求与响应中的随机数是否一致、确认令牌中的摘要和算法与待核验数据相符，并检查签名证书的状态。任何一项关键校验失败，都应降低对该时间证据的信任。
用数字签名检查内容是否被改动
数字签名通常先对待签名数据进行哈希，再使用签名者的私钥生成签名。验证者使用对应公钥检查签名。如果公告内容在签名后被改动，即使只改动一个字符，重新计算出的摘要也可能不同，签名验证就会失败。由此，数字签名可以支持内容完整性和签名密钥对应关系的判断。
但签名验证成功仍然需要回答“公钥属于谁”。如果公钥来自无法确认的文件、匿名账号或未经验证的转载页面，验证结果只能说明某个私钥签过这份数据，不能单独证明该私钥属于交易所 CEO。较可靠的做法是寻找独立渠道确认公钥，例如交易所长期使用的官方域名、公开的密钥指纹、经过可信渠道交叉确认的签名公告，或者能被多个独立记录相互印证的发布信息。
数字签名提供来源认证、数据完整性和对签名者责任的支持，但不提供公告内容的保密性，也不能自动阻止重放或复制旧公告。验证者仍要比较签名对象、发布时间、公告版本和发布场景，确认被验证的正是争议中的那一份材料。
建立一条可复核的证据链
实际核验可以先固定原始材料。保存公告的完整文本、页面地址、页面标题、发布时间显示、附件和下载文件，并记录获取时间。对文件和网页内容计算哈希值，保留计算工具、算法名称和结果。若有时间戳令牌，也应保存完整令牌及其验证所需的证书链。
接着核对来源关系。检查公告是否位于交易所控制的官方域名，域名是否与历史记录和其他官方渠道一致，页面是否存在明显的转载、二次编辑或断章取义迹象。对于社交平台公告，应保存原帖地址和上下文，同时查找交易所官网、公告中心或其他独立渠道是否有相同内容。多个来源相互印证时，要确认它们不是从同一份未经核实的转载复制而来。
最后区分证据强度。带有可验证签名和时间戳的原始材料，能够较好支持完整性和历史存在性；官方存档与独立时间记录可以补充发布渠道；截图、搜索摘要和他人转述只能作为线索。若缺少原始数据、签名公钥或时间戳验证材料，应明确表述为“目前无法充分核验”，而不要把页面显示日期当成确定结论。
常见问题与适用边界
时间戳能否证明 CEO 在某日亲自发布公告？不能。时间戳主要证明特定数据在某时点之前已经存在，不能单独证明作者身份、发布账号控制权或公告内容真实性。身份问题需要依靠公钥归属、官方渠道和独立证据共同判断。
截图能否代替原始公告？通常不能完成完整技术核验。截图保留了视觉内容，却往往缺少可重算的原始数据、签名对象、时间戳令牌和页面上下文。它可以帮助定位材料，但应尽量补充原页面、原文件或可信存档。
网页后来被修改，时间戳是否仍有用？如果时间戳针对的是修改前的具体数据，并且当前保存的数据能够通过哈希比对，时间戳仍可支持修改前版本的存在性判断。它不能证明修改后的页面仍与旧版本完全相同。
这套方法适用于公告文件、公开声明、政策文本、社交平台导出的数据及其附件等可固定的数据对象。它不能替代对交易所运营主体、账号控制权、法律责任或事实背景的全面调查，也不应据此推导市场价格、收益或交易决策。