适用范围与核查目标
“杀猪盘区块链项目的设计文档怎么查”涉及两个问题：能否找到可核对的技术说明，以及说明是否符合实际部署。以下方法主要适用于以太坊及相关EVM智能合约，不能据此认定某个项目属于诈骗，也无法覆盖链下运营行为。
先建立文档与合约的对应关系
可从项目公开的技术文档、代码仓库及部署说明中寻找网络名称、合约地址、源码版本和权限设计。把这些信息对应起来，才能确定文档解释的是哪个部署实例。同名代币、代码截图或单独一份白皮书，都不足以建立这种对应关系。
设计说明应当能够回答：哪些功能由合约执行，哪些账户可以改变关键规则，相关权限如何授予或撤销。缺少这些内容时，应记录为待核实事项；不能仅凭文档缺失推断已经发生诈骗。
通过源码验证检查实现依据
以太坊开发者文档说明，源码验证的核心是核对源码在相应编译设置下生成的字节码与链上代码是否匹配；结合元数据的完整匹配还能进一步确认源文件和编译信息。源码验证与检查行为正确性的形式化验证是不同概念。
核查时可在对应网络的区块浏览器或源码验证服务中按合约地址查找源码、编译信息与匹配状态，再把文档中的功能描述对应到实现。具体服务的验证范围应以实际展示为准。“已验证”不能直接解释为“没有漏洞”或“项目可信”。
核对谁能改变系统行为
OpenZeppelin访问控制文档区分了所有者权限与角色权限。角色管理员可以授予或撤销相关角色，因此核查不应只看当前谁能执行操作，还应关注谁能分配权限。基础AccessControl不支持链上枚举全部成员，追踪成员变化可参考授权和撤销事件。
对照设计文档时，应查明增发、冻结等敏感功能是否存在、由什么权限约束，以及当前权限状态是否符合说明。即使某项所有者权限已经放弃，也仍需分别检查其他角色，不能据此推断全部管理能力都已消失。
常见问题与结论边界
只有设计文档，没有可核对的源码怎么办？能够确认的范围仅限于文档声明，尚不能确认部署实现与其一致。源码注释写着“安全”是否有效？注释帮助理解意图，实际行为仍由代码逻辑决定。
核查结果宜分别记录文档声明、实现依据和未确认事项，并注明所核对的地址与状态。技术材料之间存在矛盾值得进一步查证，但源码匹配、权限公开或文档完整，都不能单独证明链下宣传真实。