先明确要查哪类文档
区块链审计风险案例的设计文档怎么查，首先要区分资料用途。设计说明回答系统原本应如何运行；审计报告记录特定范围内发现的问题；事件复盘解释故障经过。三者应交叉核对，不能用其中一份替代全部证据。以下方法主要适用于以太坊智能合约，不直接覆盖所有区块链系统。
围绕项目与版本定位资料
查找时可围绕项目名称、合约模块名称，结合“设计说明”“权限模型”“安全规范”“审计报告”等词定位资料。进入项目公开文档或代码仓库后，重点寻找架构说明、接口约定、代码注释及变更记录；这些是查找线索，不代表每个项目都公开了完整设计文档。
找到材料后，记录对应的代码版本、审计范围和依赖版本，再与案例涉及的实现对照。当前文档未必描述历史部署，修复后的规则也不能直接用于解释修复前的问题。
以安全要求建立核验框架
以太坊开发者安全文档强调访问控制、执行条件检查、多种测试方法及独立审查，并提醒审计不能发现所有缺陷。相应地，核验设计文档时，应寻找敏感操作的授权条件、必须保持的安全性质以及异常输入的处理规则。
可将案例整理为“设计要求、实现位置、触发条件、验证证据、修复状态”五项。某项没有材料支撑时，应保留为待核实问题，而不是补写成已经确认的漏洞结论。
权限风险要追到管理关系
OpenZeppelin访问控制文档区分所有者权限和角色权限，并说明角色管理员决定授权与撤权。默认管理员具有较高权限，所有权转移及放弃也会影响管理功能的可用性。
因此，权限类案例不能只检查某个函数是否有限制，还要核对谁能授予角色、谁能更换管理员，以及设计中是否明确交接规则。角色名称不同不等于实际控制者不同；采用多签也不能单独证明整个权限体系安全。
常见问题与证据边界
只有审计报告，没有设计文档怎么办？可以依据报告的审计范围、相关代码与测试梳理已知行为，但应区分“代码实际行为”和“设计预期”。没有公开材料，不等于项目没有内部设计。
文档写了安全措施，能否认定风险已解决？不能。还需对应实现、修复变更和验证结果。对于历史案例，权限状态等证据也应对应事件发生时点；通用技术文档只能提供核验标准，不能证明某个具体项目已经满足这些标准。