一、把抗篡改理解为数据天然真实
NIST的区块链技术概述将区块链描述为具有篡改可察觉性和抗篡改性的分布式账本，并强调正常运行条件下已发布交易的稳定性。这不等于所有写入内容都真实，也不是脱离运行条件的绝对保证。
在金融业务中，账本记录是否稳定，与记录对应的业务事实是否准确，是两个问题。完善技术时，需要分别考虑记录保护和输入核验，不能用“已经上链”替代对数据来源的判断。
二、把自动执行理解为规则必然正确
智能合约执行的是已经编码的规则，而不是自动判断业务设计是否合理。以太坊智能合约安全文档强调访问控制、条件检查和代码质量评估，说明自动化并不会消除程序漏洞。
例如，某项敏感操作即使完全按代码执行，若缺少授权检查，仍可能被不应拥有权限的账户调用。评估合约时，应同时检查执行是否符合代码，以及代码是否符合预期业务约束。
三、把权限分散理解为风险已经消失
单一管理账户可能成为关键风险点。角色分工和多重签名可用于限制敏感操作，但作用不同：角色控制解决谁能做什么，多重签名解决一项操作需要哪些参与者共同批准。
适用条件取决于权限结构。多个账户存在，并不能单独证明控制有效；仍需检查权限是否过大、角色能否相互越权，以及关键操作是否真正受到共同授权约束。
四、把测试通过或审计完成当作安全证明
测试只覆盖已经设计或探索到的情况，独立审计也不能保证发现全部缺陷。对涉及资产和权限的合约，正常流程之外，还应关注异常输入、未授权调用及关键状态约束。
常见问题是：形式化验证能否保证绝对安全？它能够针对明确规范和模型证明特定性质，但结论受规范、模型及假设限制。若业务要求本身遗漏重要约束，证明成立也不代表整个系统没有风险。
五、忽视部署后的维护边界
合约部署后，修复缺陷可能受到代码不可变性的限制。因此，完善技术不能只关注上线功能，还需提前明确维护权限、异常处置责任，以及升级或暂停机制是否存在及由谁控制。
这些原则适用于区块链金融系统的通用技术评估。具体实现仍需结合网络运行条件、合约设计和管理权限判断，不能仅凭采用区块链或完成审计，就认定某个项目安全可靠。