适用范围：先明确哪些业务交给合约
区块链垂直应用需要注意哪些问题，可以先从业务规则如何转化为合约规则入手。以下讨论适用于使用智能合约执行流程、维护状态或管理权限的应用，重点是技术安全与管理边界，不能替代行业合规和业务有效性的判断。
设计时应明确哪些主体能提交信息、批准操作和修改规则。例如，业务上的“审核通过”需要落实为具体账户权限、前置条件和状态变化，否则流程图中的约束未必会在链上生效。
权限分配：操作权与授权权分别检查
OpenZeppelin访问控制文档区分了单一所有者与角色权限，并强调最小权限原则。角色管理员可以授予或撤销相应角色，因此管理角色本身也需要保护。
对于存在录入、审核和维护等不同职责的业务，可以分别定义权限，再检查谁有权分配这些权限。如果同一账户能够自行授权并完成全部敏感操作，表面上的角色拆分仍可能缺乏实际制约。多账户配置也需要结合实际控制人判断。
异常处理：让业务限制成为可验证规则
以太坊智能合约安全文档强调访问控制、输入与状态检查，以及测试和独立审查的结合；审计不能保证发现全部问题。
应用应把业务要求写成能够验证的条件，例如只有处于待审核状态的记录才能被批准，未经授权的账户不能修改结果。测试除了覆盖正常流程，还应检查重复提交、越权调用和操作顺序变化，确认异常不会留下不一致状态。
验证范围：通过测试意味着什么
常见问题是把“测试通过”理解为“系统没有漏洞”。测试结论受到用例范围限制；形式化验证的结论也依赖所定义的性质、模型与假设，不能直接扩大为整个业务系统绝对安全。
验收时应说明验证覆盖了哪些权限、状态和异常路径，以及哪些外部依赖未被覆盖。独立审查应结合业务规则，否则实现即使符合代码设计，也可能遗漏真实流程中的限制。
维护交接：上线前考虑规则如何变化
权限交接需要检查接收账户是否能够实际管理合约；放弃所有权可能使受所有者权限保护的功能无法继续调用。这类操作应结合应用后续维护需求评估。
还应预先明确人员离任后如何撤销权限、规则变化时如何处理既有记录，以及谁负责异常响应。若系统支持升级或暂停，需要交代其授权边界；若不支持，也应明确相应限制，避免把合约部署完成等同于维护责任结束。