适用范围与判断边界
“杀猪盘区块链项目的设计文档怎么查”涉及两个问题：能否取得项目的技术说明，以及说明能否与实际系统相互印证。这里讨论以太坊智能合约及采用类似权限机制的系统，不对任何具体项目作诈骗定性。文档缺失、描述含糊或权限集中，可以形成待核实的问题，不能单独构成诈骗结论。
先确认文档描述的对象
查阅项目公开的设计说明时，先寻找其对应的网络、合约地址和功能范围。无法对应到具体合约的文字，难以用于核验实际运行规则。宣传页面、设计说明和链上程序各自提供不同信息，需要建立明确对应关系。
以太坊开发文档说明，智能合约是部署在特定地址上的程序，包含代码和状态，用户通过交易调用其功能；合约本身不能直接获取链外信息。因此，文档若声称依据外部业务数据自动执行，应进一步说明数据如何进入合约。
把功能描述转换成权限问题
阅读设计说明时，可围绕具体功能追问：谁能创建代币，谁能限制转移，谁能授予或撤销这些权限？将每项功能与执行条件、授权账户对应起来，比只看“自动运行”等概括性表述更容易发现信息缺口。
OpenZeppelin权限文档区分所有者管理和角色管理：前者可用onlyOwner限制操作，后者可用onlyRole分配不同权限。角色管理员能够管理相应角色，默认管理员尤其需要关注。核验时既要看谁能执行功能，也要看谁能改变授权。
核对当前权限及其变化
设计说明表达的是预期规则，权限核查还需要关注当前状态。若系统采用动态角色管理，应结合授权与撤销事件核对角色变化；不能仅凭部署时的说明判断现在由谁控制。
基础AccessControl不直接支持链上枚举全部角色成员，核查可能需要处理RoleGranted、RoleRevoked事件；采用可枚举扩展时，才有相应成员查询接口。信息无法完整取得时，应明确保留“权限状态尚未核实”的结论。
常见问题与证明边界
公开合约是否说明项目可信？公开性提供了检查程序的条件，但不能据此确认链外业务真实或项目不存在欺诈。设计文档也需要与实际代码、状态相互印证。
放弃所有权是否代表无人控制？它影响受所有者权限保护的功能，仍需检查是否存在其他角色权限。多签要求达到规定数量的有效签名，但签名门槛本身无法证明签名者彼此独立。
查不到内部设计文档怎么办？智能合约公开不意味着内部文档也会公开。可将结论限定为已能核对的功能与权限，并列明缺失内容，不把无法查证的信息补写成事实。