先确定研究对象和适用范围
“乌托邦”这一名称不足以唯一确定项目，现有证据也未建立它与特定网络、合约地址或代码版本的对应关系。因此，本文解释通用核验方法，不对该项目是否存在、采用何种技术或是否安全作出结论。
研究记录应明确网络、地址、代码版本及观察时点。以太坊的源码验证方法适用于相应智能合约环境；比特币账本的核验规则不能直接套用于所有区块链。
源码证据：确认公开代码与部署代码的关系
ethereum.org 的合约验证说明指出，源码验证通过重新编译和字节码比对，检查公开源码是否对应部署合约；纳入元数据哈希的完整匹配，还能更严格地核对源码文件与编译信息。源码验证与检验行为正确性的形式化验证属于不同概念。
研究报告若声称“合约已验证”，应保留合约地址、源码文件、编译器版本、编译设置及匹配结果。核验时需要处理构造参数、链接库和不可变变量等因素，不能把简单文本相同当作全部验证过程。
链上证据：确认记录归属及其证明范围
Bitcoin Developer Guides 对账本的说明表明，全节点按照共识规则验证区块；区块通过前一区块头哈希连接，默克尔树支持核对交易是否被纳入区块。分叉时同一高度可能出现不同区块，因此区块高度不能充当全局唯一标识。
引用链上记录时，应保存网络、交易标识和区块哈希，使他人能够定位并复核。交易被收录，只能支持相应链上记录的存在；地址背后的主体身份、实际业务用途等主张，需要另行举证。
把研究结论写成可复核的判断
每项主张应对应明确证据。例如，“公开源码对应某地址的部署代码”需要编译匹配记录；“某交易被某区块收录”需要交易与区块证据。多个页面重复同一宣传说法，不构成多份独立技术证明。
记录中还应区分核验通过、核验失败和信息不足。缺少地址或编译设置时，应说明无法完成哪一步，避免把尚未核验写成已经证伪。
常见问题：已验证是否等于安全
源码匹配不等于没有漏洞，完整匹配也不能证明注释中的承诺正确实现。形式化验证的结论同样取决于所定义的性质与假设，不能扩展为对全部业务行为的保证。
两份技术文档能够支持核验方法，却不能替代某个项目自身的证据。对“乌托邦”的具体判断，仍须以可定位的项目材料及实际核验结果为基础。