先把项目主张改写成可核对的问题
“技术可靠”“数据透明”都过于宽泛。核验时应先明确：要确认公开源码与部署代码一致，还是某笔交易确实被收录？不同问题需要不同证据，不能用一个验证标签替代所有判断。
可以按“主张、核验对象、证据位置、适用范围、未解决问题”整理材料。项目介绍只能说明其公开说法；只有能够定位、检查并对应到该说法的材料，才能支持具体结论。
源码验证证明的是什么
Ethereum 的合约验证文档区分了源码验证与形式化验证：前者检查源码编译结果与部署代码是否匹配，后者依据指定性质判断合约行为是否符合预期。结合元数据哈希的完整匹配，还能加强对源文件及编译信息一致性的确认。
因此，看到“已验证”，应继续核对网络、合约地址、源文件和编译设置，并确认验证结果属于何种匹配。标签首先回答代码对应关系，不自动回答权限是否合理、业务设计是否可靠或是否存在漏洞。
链上记录证明的是什么
Bitcoin 开发者指南说明，全节点依据共识规则验证区块；区块通过哈希连接，交易通过默克尔树汇总。默克尔证明用于检查交易是否被某个区块包含。发生分叉时，相同高度可能对应不同区块，因此区块高度不是全局唯一标识。
核对记录时，应保留网络、交易标识和区块哈希，而不只记录截图或高度。交易被收录、交易满足协议规则、交易所代表的链下业务真实，是不同层次的问题，不能相互替代。
让证据与结论逐项对应
如果主张是“公开代码就是部署代码”，应提供对应地址的源码验证结果，而不是只提供代码仓库。如果主张是“某笔交易存在”，应给出可定位的交易记录，而不是只展示汇总数字。
核验结论应保留限定条件。例如，“该地址的源码获得匹配结果”比“整个项目已被证明可靠”更准确。材料缺少地址、版本或记录标识时，应写明尚不能确认，而不是用一般技术原理填补证据缺口。
两个来源不等于两次独立验证
Ethereum 文档与 Bitcoin 开发者指南分别说明合约验证和账本机制，能够提供不同角度的技术依据，但不能共同证明某个未被检查的项目可靠。两套机制的适用对象不同，也不应把比特币的具体规则直接套用到所有区块链。
多个页面若转述同一份公告，并不会因此形成多份独立证据。应区分解释原理的文档、项目自身的声明，以及针对具体对象产生的核验结果。
常见问题与结论边界
源码完整匹配是否意味着绝对安全？不是。匹配解决的是一致性问题，不代表程序逻辑已经得到全面安全评估。形式化验证也需要说明验证了哪些性质、采用哪些假设。
链上有记录是否意味着宣传属实？不是。记录只能支持其实际表达的链上事实。对无法由现有材料覆盖的身份、业务或其他链下主张，应另行寻找对应证据；没有证据时，保留未证实的判断。