先把“好项目”拆成可核验的问题
“好项目”包含多种判断，研究时应分别提出问题：声称的交易是否发生，敏感操作由谁控制，运行代码是否接受过检查，发现的问题是否修复。每个问题需要对应证据，不能用一张审计标识或一组交易截图代替全部论证。
核验时可记录具体主张、原始证据位置、对应版本和适用范围。结论也应保持同样精度，例如“该版本接受过独立审查”，而不是直接扩大为“项目安全可靠”。
链上记录能证明什么
Bitcoin Developer Guides 的区块链说明介绍了节点验证、交易标识和默克尔树：节点按共识规则验证区块，交易可以通过相关哈希证明其被纳入某个区块。分叉情况下，同一高度可能出现不同区块，因此区块高度不能充当全局唯一标识。
核验交易类主张时，应明确网络、交易标识和所属区块，并区分交易被收录与其业务含义。某笔转账存在，并不能单独证明参与者是独立用户，也不能证明项目履行了链下承诺。这些问题需要额外证据。上述具体机制适用于比特币，不能直接套用到所有区块链。
安全证据要对应运行代码与权限
Ethereum 开发者安全文档强调访问控制、测试、独立审计和漏洞奖励等措施。它指出，单元测试覆盖有限，审计也无法发现所有漏洞；多签和角色权限有助于约束敏感操作，但安全性仍取决于具体设计。
据此核验项目时，应把报告中的合约、代码版本和实际部署对象对应起来。若合约支持升级，还要检查审查后的变更。涉及增发、暂停或升级权限的主张，应落实到权限配置；仅看到“采用多签”，仍不足以判断签名方是否独立、权限是否合理。
测试与审计结论有哪些适用条件
评估测试证据，应关注它检查了哪些输入、边界条件和安全属性。测试通过只能支持已检查范围内的结论，不能覆盖未编写的用例。形式化验证也依赖所写规格、模型与假设，不能把某项属性得到证明扩大成整个系统没有风险。
评估审计证据，可核对检查范围、发现的问题、修复状态和复核记录。报告存在与问题解决是两件需要分别核实的事；被排除在范围外的组件，也不能自动获得相同结论。
常见问题：证据越多就越可靠吗
多个页面转载同一份报告，仍然只有一条原始证据。更有意义的交叉核验，是让链上记录、代码和独立审查分别回答不同问题，再检查它们是否指向同一对象和版本。
没有公开事故记录，不能证明不存在缺陷；代码公开，也不等于已经充分检查。遇到缺少版本、权限或修复信息的情况，适当结论是相关主张尚未核实，并说明缺口，而不是据此认定项目优劣。