先界定需要核验的对象
“美国海底比特币交易所”可能是项目名称、媒体描述、社交平台用语，或者对某项基础设施设想的概括。核验前应先固定具体对象：公告标题、发布机构、原始网址、声称的发布日期、涉及的公司或监管主体，以及公告中可验证的事实。仅凭一个关键词，无法确认它指向哪一家机构，也不能据此判断项目是否真实存在。
现有材料提供的是可信时间戳协议和网页注释数据模型的技术说明，并未提供任何美国海底比特币交易所的公告、公司登记信息或监管文件。因此，不能把这些技术标准当作该项目存在或某份公告真实发布的直接证据。它们只能帮助建立证据保存和比对方法。
检查公告来源与内容一致性
第一步是寻找发布主体的原始渠道，例如机构官网的公告栏目、正式文件库或可确认归属的公共档案。应记录网页完整地址、页面标题、正文、附件、页面显示时间和抓取时间，同时保存页面的原始文件或截图。来源之间若只有转述关系，转述内容只能作为线索，不能替代原始公告。
随后比较多个独立记录：官网页面、新闻稿附件、监管披露、公司注册记录、公开会议材料和可靠的网页存档。比较时重点查看标题、主体名称、发布日期、联系人、文件编号、附件版本及关键措辞是否一致。网页上显示的日期可能是更新时间，而不是首次发布日，必须结合页面元数据、存档时间和文件内部日期判断。
可信时间戳能证明什么
RFC 3161描述了时间戳请求和响应的基本机制。申请方先对需要证明的文件计算哈希值，再把哈希摘要提交给时间戳机构。时间戳机构返回包含时间、哈希算法、数据摘要和自身签名等信息的时间戳令牌。验证者可以重新计算现有文件的哈希值，并检查它是否与令牌中的摘要一致。
这种机制主要支持“某份特定数据在某个时间之前已经存在”的证明。它不能单独证明文件内容真实、发布者身份正确，也不能证明公告中的事实已经发生。验证时还要检查令牌签名、时间戳机构证书、使用的安全策略、哈希算法、随机数或其他请求关联信息，以及相关证书状态。只要文件内容改变，重新计算出的摘要通常就会不同，原时间戳不能直接覆盖修改后的版本。
用结构化注释保存证据关系
W3C Web Annotation Data Model把注释表示为相互关联的资源，通常包括注释正文和目标资源。用于历史公告核验时，可以把公告网页或文件作为目标，把核验记录作为注释正文，并补充网页地址、选定文本片段、文件摘要、存档地址、核验时间和证据类型。这样能清楚区分“公告原文写了什么”和“核验者据此作出的判断”。
注释模型本身不负责证明内容真实性，也不规定必须使用哪一种传输协议。它的价值在于让证据定位更加明确，便于不同工具或平台共享记录。例如，核验记录应指出某项结论对应公告中的哪一段文字、哪个附件或哪个存档版本，而不是只留下一个无法复查的结论。
适用条件与常见问题
如果原始公告仍可访问，且能取得完整文件、稳定网址和可复核的发布时间，可以优先进行内容比对，再使用哈希和可信时间戳固定证据版本。如果原页面已经删除，应同时寻找官方存档、监管披露和可信网页存档，并明确区分“曾经存在页面的证据”和“页面内容真实无误的证据”。如果只有社交平台截图或转述，结论应限定为“发现相关说法”，不能升级为已证实公告。
常见问题是：时间戳是否等于官方认证？不是，它主要证明数据存在时间及摘要匹配关系。网页存档是否等于原始发布？也不是，存档只能说明某个时间点保存了某种页面表现。多个网站转载是否构成独立证据？如果都来自同一篇未核实的稿件，仍然只能算一个信息源。只有当发布主体、文件链条或记录来源彼此独立时，交叉核验的价值才会提高。