区分法律协议与可执行代码
智能合约自动化的是流程中可形式化的部分，无法表达所有法律例外和争议处理方式。每个代码版本都应关联对应的协议文本、数据模型和批准的运行规程。对每个自动决策说明触发事实及其真实性责任方。
先建立业务对象状态机：创建、批准、发运、验收、付款、争议和取消。明确的状态转换比一组松散函数更容易测试，也更容易映射到 ERP。
划分链上与链下边界
链上只保存多方共同验证所需的最小证据：标识、状态、证据哈希、签名和时间。产品数据、个人信息、扫描件、计算模型和大文件留在企业系统中，用稳定标识和哈希把精确版本绑定到交易。
这样可以降低成本和泄露风险，但外部存储的可用性也成为架构的一部分。归档、备份和保留策略必须保证多年后仍可验证证据。
使用集成适配器，不让 ERP 直接连接节点
独立服务把业务事件转换为合约命令，使用授权服务密钥签名，跟踪确认并把结果返回 ERP。它还负责模式验证、限额、去重、重试队列和审计。
每个操作都要有幂等键。超时后的重试不能创建第二次发运或付款。必须区分已提交、已入块、达到确认要求和已拒绝；ERP 不能因为交易刚发出就认为流程完成。
为预言机建立独立信任模型
合约无法自行验证 API 响应、汇率、传感器读数或交付事实。预言机把事实带上链，也引入新的信任边界。应定义允许来源、数据签名、最大时效、确认数量、聚合规则及来源冲突时的安全行为。
在企业场景中，预言机可以是一组签名组织或受保护网关。合约验证来源和新鲜度，运维人员则必须看到延迟和通道故障。
把密钥和身份作为独立服务
区分用户身份、服务账户和链上地址。策略应说明谁可发起操作、谁在技术上签名，以及如何把业务动作追溯到具体员工。关键密钥应进入受保护托管或硬件模块，而不是写在集成代码中。
还要支持不停机轮换、离职或事件后的撤销、管理操作的多方批准，以及企业角色和地址之间的可审计映射。
处理重组、延迟和故障
不同网络提供不同最终性保证。适配器必须等待约定的确认数量或明确最终性事件，能够承受临时分叉并重新核对状态。持久队列记录原始命令、交易标识、当前阶段和最近错误。
网络或预言机不可用时，业务流程应进入可见的等待状态，而不是按假设继续。紧急人工决定需要指定角色、理由、双人批准和事后对账。
可观测性必须连接两个世界
一个关联 ID 应连接 ERP 文档、集成消息、交易、合约事件和监控记录。运行视图展示提交与确认延迟、队列长度、错误率、交易成本、过期预言机数据和状态差异。
日志不能包含私钥或不必要的个人数据，但必须足以还原哪个代码、输入和权限产生了结果。
验收覆盖完整链路
测试正常流程、重复命令、超时、节点不可用、错误预言机值、密钥轮换、ERP 回滚、合约升级和人工恢复。每个场景后都要核对各参与方记录。
只有当业务用户看到明确状态、工程师能够安全重试、安全团队掌控密钥，并且争议可以从源文档追溯到链上交易时，系统才真正达到生产就绪。