适用范围：先区分链与合约
讨论 ICO 相关安全时，不能把区块链能够执行交易，等同于合约业务规则正确。本文聚焦以太坊智能合约及代币权限管理，不评价任何具体项目，也不据此判断其合规性或资金安全。
以太坊开发者安全文档强调，部署后的合约逻辑通常难以直接修改，应结合权限约束、条件检查、测试和独立审查降低风险。审计只是补充防线，不是安全保证。
权限：谁能改变系统规则
OpenZeppelin 访问控制文档区分单一所有者与角色授权，说明最小权限原则、所有权两步交接及默认管理员的风险。多签账户也可以作为合约所有者，让管理操作需要多方批准。
入门时可以把权限理解为一张责任表：谁能增发，谁能暂停，谁能更换管理员。不同地址分别持有角色，不一定意味着控制权真正分散；还要看这些地址是否由同一主体控制，以及上层管理员是否能重新分配权限。
验证：规则必须经得起异常输入
理解条件检查时，应区分外部输入是否合法与内部逻辑是否保持一致。require 常用于检查调用条件；assert 用于检查本应始终成立的不变量；revert 可以在不满足规则时明确终止执行。这些机制只有覆盖了关键约束，才具有保护作用。
测试也应从“正常情况能运行”延伸到“异常情况是否被拒绝”。例如，无权限账户不能执行管理操作，是比单纯验证管理员操作成功更完整的检查。静态分析、模糊测试和独立审查各有侧重，不能相互完全替代。
常见问题：安全标签有哪些边界
公开代码就安全吗？公开让检查成为可能，但不证明检查充分。通过审计也不代表后续修改、部署配置或权限变更自动受到同样覆盖。
放弃所有权就没有管理风险了吗？不一定。它会使依赖该所有者权限的功能无法调用，但不能据此推断其他角色或管理路径也已消失；必要维护能力也可能因此失效。
形式化验证能证明没有任何漏洞吗？其结论受形式化规格、模型及假设约束。若某项业务风险没有被写进验证目标，就不能把它视为已经排除。理解安全结论时，始终需要追问它覆盖什么、依赖什么条件。