先区分要核验的对象
“历史公告”至少包含两类问题：一是这份文字或文件是否确实由声称的发布方发布，二是公告描述的交易所、资产、网络或功能是否真实发生。前者属于来源真实性与内容完整性核验，后者还需要业务记录、公开网络数据或其他独立证据。不要把页面存在、截图清晰或有人转发，直接当成事实成立。
就现有材料而言，NIST关于数字签名的说明支持一个通用判断：数字签名用于确认签名者身份，并发现签名生成后数据是否被修改。W3C可验证凭证模型则强调，凭证可以被机器验证，但“可验证”不等于其中所有主张自动为真，验证者仍需根据自身规则审查发行者、证明、主体和具体声明。上述原则适用于公告核验，但并未证明任何特定派币项目或交易所公告。
第一步：固定原始材料
优先保存公告的原始网页、附件、公告编号、页面标题、发布时间、更新记录和发布域名。对于动态页面，还应记录页面正文的完整版本，必要时保存网页存档或文件副本，并注明获取时间。截图只能作为线索，因为它通常缺少可验证的上下文、网页地址和版本信息。
检查域名时，要注意名称相近的仿冒站点、跳转页面和社交平台二次发布。搜索结果摘要、群聊转发、短链接和图片上的标识，都不能替代发布方的正式记录。若公告只出现在单一匿名账号或无法确认归属的页面，应将结论限定为“未能确认来源”。
第二步：核验签署与完整性
如果公告附有数字签名、签名文件或可验证的发布证明，应先确认验证所需的公钥、证书或密钥标识来自可信渠道，再验证签名是否对应当前文件。验证成功通常只能说明特定密钥签署了未被修改的内容；还要判断该密钥是否确实属于公告发布方，以及密钥在公告发布时间是否有效。
如果文件只有哈希值，哈希可以帮助发现文件内容变化，但本身不能证明文件是谁发布的。若签名验证失败、文件版本与签名对象不一致，或公钥来源无法确认，就不能把该材料当作已认证公告。不要因页面使用HTTPS、带有锁形图标或拥有品牌标志，就推断内容已经经过业务审查。
第三步：核对公告中的事实
对于“上线某去中心化交易所”“开放某网络功能”或“完成某次迁移”等主张，应拆成可独立检查的事实。例如，公告发布者是谁、涉及哪个网络或合约、使用了什么唯一标识、事件发生时间是什么、是否存在相匹配的公开记录。链上记录可以辅助确认交易、合约调用或状态变化，但不能单独证明某个网页公告的作者身份。
如材料涉及可验证凭证，可分别观察发行者、持有者和验证者角色，以及凭证的证明材料、有效期和撤销状态。验证凭证的密码学证明，仍不等同于发行者声明内容在现实业务中的完整真实性。对于交易所名称、资产归属、兑换承诺或账户权益等问题，还需查阅对应服务的正式规则和可核验记录，不能从凭证格式直接推导结论。
常见问题与结论表达
问：一张带日期的公告截图能否作为证据？答：可以作为待核验线索，但通常不足以证明来源和未被修改。应补充原始链接、版本记录、签名或其他独立材料。
问：数字签名验证通过，是否代表公告内容一定真实？答：不代表。它主要解决签名者关联和内容完整性问题，不能替发布方证明所有业务描述、时间安排或权益主张。
问：怎样写出审慎的核验结论？答：可按证据强度表述为“已确认页面来源”“已确认文件签名与完整性”“发现与公开记录相符”或“目前无法确认”。若缺少发布方身份、原始版本或独立事实记录，应明确说明缺口，不把未核验内容写成项目已证实事实。