先区分公告内容与项目事实
“迦勒币上交易所”是一个包含具体项目名称的说法，但现有材料没有提供该项目的官方公告、交易所页面或可独立确认的项目资料。因此，不能仅凭关键词判断它是否曾经上架，也不能把网络截图、转述或搜索摘要当作已经证实的事实。核验时应先明确要确认的命题：是某项目曾发布上架通知，还是某交易所确实开放了交易，抑或只是计划、预告或社区传闻。不同命题需要不同证据。
核对公告原文和网页状态
首先保存公告页面的完整地址、页面标题、正文、发布时间、发布主体以及页面上的交易对或开放时间等信息。页面是否仍能访问、是否出现编辑痕迹、是否只有图片而缺少正文，也应记录下来。网页响应中的 Last-Modified 表示源服务器认为资源最近一次修改的时间，可用于判断服务器记录的修改时间，并帮助缓存或爬虫处理资源。它不是内容创建时间，也不能单独证明公告在该时间已经发布。
Last-Modified 的时间按照 HTTP 规范使用 GMT 表示，查看时应避免把服务器时间直接当成本地时间。还要注意，同一页面可能因编辑、迁移、缓存或内容管理系统处理而改变该字段；有些服务器也可能不提供该响应头。因此，Last-Modified 只能作为时间线中的一个辅助线索，不能替代官方发布记录或内容完整性校验。
用内容指纹确认文件是否被改动
如果需要比较网页存档、导出的公告文件或截图附件，可以对保存的原始文件计算哈希值，并在不同时间保存哈希结果。哈希值可以帮助识别两个文件是否发生变化，但它本身只能说明内容是否一致，不能自动说明哪一份是真的，也不能证明文件形成的时间。核验记录应同时保留文件来源、下载时间、原始地址和文件格式。
RFC 3161 描述了网络时间戳协议。其基本思路是向时间戳机构提交数据的哈希表示，由时间戳机构返回包含可信时间、数据摘要信息及签名的时间戳令牌。验证者需要检查令牌状态、数据摘要、哈希算法、时间戳机构证书、签名以及请求与响应中的随机数等信息。只有当待核验文件重新计算出的哈希与令牌中的数据摘要一致时，时间戳才支持该文件在相应时间点已经存在这一判断。
建立多来源交叉核验链
较稳妥的核验应至少比较三类记录：项目或发行方的原始公告、交易所自身的公告或市场页面、以及可追溯的网页存档或带时间戳的文件。三者的项目名称、合约或资产标识、交易对、开放时间和公告措辞应相互对应。若只有社交平台转发，或公告只写“即将上线”而没有实际开放记录，就不应把它表述为已经完成交易所上架。
还要检查页面之间是否存在时间矛盾。例如，公告的 Last-Modified 晚于所谓上架时间，并不必然意味着公告虚假，因为页面可能后来被编辑；但这意味着需要继续查找早期存档、版本记录或带时间戳的原始文件。若不同页面使用不同资产标识，或者只有截图没有可验证原文，也应将结论限定为“发现相关说法”，而不是“已确认”。
常见问题与适用边界
Last-Modified 能证明公告发布时间吗？不能。它反映的是源服务器认为资源最近修改的时间，可能晚于首次发布，也可能因服务器配置、缓存或编辑行为而失真。它适合辅助整理时间线，不能单独作为发布日期证明。
网页截图能作为证据吗？截图可以保留当时看到的界面和文字，但通常缺少可验证的原始文件、响应头和完整上下文。应把截图与原始页面、存档地址、下载记录或时间戳令牌结合使用。
RFC 3161 时间戳能证明公告内容真实吗？不能。它主要证明某一数据摘要在特定时间前已提交并获得时间戳，不负责判断项目身份、交易所是否认可该资产、公告是否具有法律效力或内容是否属实。核验结论必须明确区分“文件存在时间”和“公告事实成立”。
在无法取得官方页面或可靠存档时，最谨慎的写法是说明证据不足，并列出已核对的页面、时间字段、文件哈希和矛盾点。不要用技术字段推导出材料未支持的项目结论，也不要据此进行交易或收益判断。