适用范围与判断起点
“云贸”所指平台的底层网络、合约代码与部署方式尚无法核验，因此这里只讨论通用技术问题。判断具体系统时，需要先明确它是否使用智能合约、由谁验证账本，以及哪些主体可以修改业务规则。不同架构的安全条件不能直接互相套用。
账本记录有哪些可信边界
比特币开发者指南介绍了节点按共识规则验证区块、区块通过哈希连接，以及分叉时选择累计工作量最大的有效链等机制。这些机制用于约束交易记录的有效性和历史修改，不能证明任意平台都具备相同保障。
业务应用还需要区分记录一致性与业务真实性。例如，一份业务记录被写入账本，只能在相应验证条件下说明该记录被收录；其描述的商品、交付或身份是否真实，仍需独立核验。
智能合约需要关注哪些控制
以太坊智能合约安全文档强调访问控制、输入检查、多种测试方法及独立审查。公开可调用的函数需要明确权限边界，敏感操作可采用角色分工或多重签名；审计只能增加发现漏洞的机会，不能保证没有漏洞。
若系统采用智能合约，应具体核对谁能升级、暂停或更改关键参数。角色数量增加并不自动消除集中控制风险，还要看这些角色是否由同一主体掌握，以及某个权限失陷后能影响哪些操作。
测试应覆盖业务规则和异常路径
正常流程执行成功，只能说明已测试的场景符合预期。核验时还应关注越权调用、无效输入、重复操作及状态变化后的行为，检查业务约束是否始终成立。
形式化验证也有适用边界：它能够针对明确规格和模型证明特定性质，结论受规格、模型及假设限制。审查结果应与实际部署版本对应，代码更新后需重新评估受影响部分。
常见问题：上链与上线是否意味着完成
上链后是否绝不变化？需要结合网络共识及确认机制判断，比特币存在分叉和链重组的可能，业务系统应定义相应的确认与异常处理规则。
发现合约问题能否直接修复？已部署代码通常不能像普通应用一样直接修改；支持升级的系统也依赖预先设计的权限与升级机制。因此，采用合约前就应明确修复、暂停和恢复的条件，避免把上线视为安全工作的终点。