误区一：网络正常运行，应用就一定安全
以太坊能够执行合约，并不代表合约设计符合使用者的预期。程序可能按代码完成操作，却因权限遗漏或逻辑缺陷产生损失。理解风险时，需要分别看执行规则是否可靠、业务规则是否正确。
这里讨论的是智能合约及其管理权限风险，不能据此判断所有以太坊应用，也不能将某类合约缺陷直接视为底层网络故障。
误区二：代码不可变，就不会出现安全问题
不可变性约束代码修改，并不自动纠正代码错误。ethereum.org 的智能合约安全说明指出，部署后的缺陷修补往往受到限制，因此部署前的验证尤其重要。
对具体应用，还需要区分固定代码与预先设计的升级机制。能够升级意味着存在修改逻辑的权限，需要进一步理解谁控制该权限；无法升级则需要面对缺陷难以直接修复的问题。
误区三：通过审计或测试，就等于没有漏洞
审计提供额外检查，测试验证选定场景，两者都有覆盖范围。普通测试通过，可能只说明已设置的输入得到预期结果，未必包含异常输入和复杂调用组合。
模糊测试可以探索更多输入，形式化验证可以证明特定模型下的安全性质，但结论仍受规格与假设限制。常见问题是“有审计报告是否足够”：还需要看报告对应的代码版本、检查范围以及发现问题的处理情况。
误区四：多个角色或多签，天然消除了集中控制
OpenZeppelin 的访问控制文档区分了所有者权限、业务角色及管理角色。角色可以拆分职责，但角色数量不能直接说明实际控制权分散程度。
例如，铸造与暂停分别由不同角色负责，如果同一账户能重新分配这些角色，控制权仍可能集中。多签通过签名门槛约束操作，其效果也取决于签名者是否独立，以及密钥是否存在共同失陷的可能。
误区五：放弃所有权，只会带来安全收益
放弃所有权可能使受所有者权限保护的管理功能无法再调用。这适用于确实不再需要这些功能的设计，不能直接套用于仍依赖管理操作的合约。
“放弃所有权后是否完全没有管理员”也不能只看一个状态字段，还要检查其他角色和升级权限。转移所有权时，两步接收机制有助于降低误交接风险，但不能替代对新管理方的判断。
误区六：加入权限检查，就完成了安全设计
权限检查回答谁能执行操作，业务约束回答操作在什么条件下成立。获授权的账户仍可能提交错误参数，因此身份、输入和状态之间的关系都需要验证。
判断安全措施是否有效，应把它放回具体功能中：它防止哪类错误，依赖什么前提，失效后影响哪些操作。单个安全标签无法涵盖整套合约的风险。