先明确“核验”要证明什么
对35个项目进行资料核验，第一步不是判断项目是否可靠，而是明确每条资料要证明的具体命题。例如，项目是否确实部署了某个合约，某个地址是否属于项目方，某项功能是否已经写入合约，或某笔交易是否实际发生。这些问题的证据类型不同，不能用一张网页或一段宣传文字统一证明。
区块链上的公开记录适合核对交易、区块、地址和合约状态；项目发布的源码适合解释合约逻辑；技术文档则主要用于理解设计目标。应把“项目声称实现了什么”和“链上记录实际显示了什么”分开记录，避免将宣传内容直接当作事实。
核验智能合约源码与部署代码
以太坊智能合约在部署前，会将Solidity等高级语言源码编译为以太坊虚拟机能够执行的字节码。源码验证的核心，是使用相同的源文件和编译设置重新编译，再将结果与指定合约地址上的部署代码进行比较。编译器版本、优化设置、依赖库和构造参数等信息都可能影响结果，因此这些字段应作为核验记录的一部分。
区块浏览器显示“已验证”通常意味着重新编译后的代码与链上代码能够匹配，但这不等同于合约逻辑已经被证明正确，也不等同于通过了安全审计。资料整理时应区分至少三种状态：没有公开源码、源码与字节码完成匹配、代码经过更高强度的形式化验证。它们所能支持的结论范围不同。
部分匹配与完整匹配也需要区分。合约元数据包含源文件哈希和编译信息；如果链上附带的元数据哈希与重新生成的结果一致，通常可以更严格地确认源文件和编译信息没有发生变化。若只完成一般源码匹配，则不能据此声称每个源文件字节都与最初编译版本完全一致。
用链上结构核对项目事实
对涉及比特币或类似区块链的项目，资料核验可以从区块、交易和地址之间的关系入手。比特币区块包含前一区块的区块头哈希，交易通过交易标识和默克尔树组织到区块中，因此可以核对某笔交易是否被纳入指定区块，以及相关记录是否位于某条链上。
核验时应记录网络名称、区块高度、区块哈希、交易标识和查询时间等定位信息。区块高度并非全球唯一标识，因为分叉时可能出现多个相同高度的区块；在需要精确指向某个区块时，区块哈希比单独使用高度更合适。对于交易是否最终稳定，还应注意链上分叉和节点共识情况，不能只截取一张页面截图作为完整证据。
为35个项目建立统一核验表
建议为每个项目建立相同字段的记录表：项目名称、所属网络、官方声明、涉及地址、资料链接、链上定位、源码状态、编译设置、验证工具、核验日期、证据截图或哈希，以及尚未确认的事项。统一字段能够减少不同项目之间因资料格式不同而产生的误判。
证据应尽量来自相互独立的渠道。例如，项目文档说明合约用途，区块浏览器提供地址和交易记录，开源验证服务提供源码与字节码的匹配结果。多个渠道指向同一事实时，可以提高可复核性；但它们若都只是转载项目方内容，就不能算真正独立的交叉验证。
对于无法确认的内容，应使用“未找到链上证据”“源码未验证”“地址归属未能独立确认”等限定性表述。不要因为资料缺失就推断项目不存在，也不要因为出现一个已验证合约就推断整个项目的所有组件都已验证。
适用条件与常见问题
这套方法适用于需要核对公开区块链记录、智能合约源码和项目技术声明的资料整理工作。它不能单独证明项目团队身份、商业收入、治理承诺或未来计划，也不能替代专业代码审计、法律审查和运营风险调查。
常见问题一：区块浏览器显示源码已验证，是否代表合约安全？不是。源码验证主要说明提交的源码能够对应链上字节码；合约是否存在权限过大、逻辑缺陷或可被滥用的功能，仍需阅读代码并进行安全分析。
常见问题二：项目只有白皮书和官网，是否足够核验？通常不够。白皮书可以说明设计目标，但要核对已部署功能，还需要对应网络上的地址、交易或合约证据。
常见问题三：不同浏览器的验证结果不一致怎么办？应比较网络、合约地址、编译器版本、优化参数、构造参数和验证范围，并优先保留可复现的编译信息。若差异无法解释，应将结论标为待核验，而不是选择更符合预期的一方。