适用范围：聚焦智能合约安全
讨论区块链项目技术风险，首先要明确评估对象。以下主要适用于以太坊智能合约及类似应用，重点是测试、代码审查和访问控制，不能据此认定某个项目安全，也不覆盖所有底层网络风险。
误区一：审计通过就是安全保证
以太坊开发文档将独立审查视为补充防线，而不是发现全部漏洞的保证；同时强调，单元测试应与其他验证方法结合。
审计和测试回答的是不同问题。阅读安全结论时，需要明确它针对什么代码、检查哪些行为，以及有哪些未覆盖条件。“接受过审计”本身不是对整个系统的无限担保。
误区二：测试通过或形式化验证意味着没有漏洞
正常输入下功能可用，不代表异常输入和不同调用顺序也安全。单元测试的结论受测试用例限制，模糊测试可探索更多输入，形式化验证则针对明确规定的性质进行证明。
常见问题是：已经证明某项性质，还可能出问题吗？可能。证明成立有其模型与假设边界，遗漏的安全要求不会自动得到保障。
误区三：有多个角色或多签，就不存在集中风险
OpenZeppelin访问控制文档区分了业务角色与角色管理员：能够执行某项操作，不等于能够分配该权限；默认管理员通常具有广泛的角色管理能力。文档也说明，放弃所有权会使仅所有者可调用的管理功能无法继续调用。
因此，角色名称多，不等于控制权分散。需要同时考虑谁持有角色、谁能重新授权，以及多个账户是否实际由同一主体控制。多签增加授权门槛，但不能修复业务代码中的漏洞。
误区四：去掉管理员一定更安全
撤销管理权限可以限制人为干预，却也可能取消必要的维护能力。是否适合这样做，取决于系统是否仍需受保护的管理操作，而不是“无管理员”这一标签。
判断技术风险，应把代码行为、验证边界和权限关系放在一起看。单一安全措施只能处理特定问题，不能替代对系统整体设计的理解。