一、把金融链当成统一技术标准
“金融链”这一称呼不足以说明系统架构。讨论设计时，应先明确采用哪种链、哪些操作在链上完成、谁能管理合约。本文讨论通用技术概念，不将名称或应用领域视为某个系统已经具备安全性与可靠性的证明。
二、只比较吞吐量，不区分确认与结算
以太坊扩容文档将吞吐量、确认速度、安全性和去中心化共同纳入考量，并区分链上与链下扩容。误区是把“处理得快”直接等同于“结算已完成”。理解金融业务流程时，应分别看交易提交、执行和最终确认，不能用一个速度指标替代全部环节，也不能把低手续费等同于低风险。
三、把所有链下方案都视为同一种安全模型
该扩容文档区分依托主网安全机制的二层方案与采用独立共识的侧链，也指出Rollup与Validium的数据存放方式不同。因此，能与主网通信、兼容相同合约接口，不代表获得相同保障。方案比较应分别说明执行位置、验证方式和数据可用性；应用专用网络同样需要解释这些边界。
四、认为管理员越统一，系统就越可靠
OpenZeppelin访问控制文档区分单一所有者与基于角色的授权，强调最小权限原则。单管理员适合职责简单的场景；当增发、暂停等职责需要分离时，应明确各角色的权限，而不是默认让同一账户掌握全部操作。组织中存在多个岗位，也不意味着合约已经实现相应的权限隔离。
五、只划分业务角色，不检查角色管理权
该访问控制文档还提醒，默认管理员权限集中，所有权转移可能需要接收方确认，放弃所有权会使仅限所有者的操作无法调用。设计时不仅要回答“谁可以执行”，还要回答“谁能授权、撤权和接任”。角色名称不同并不必然意味着控制权分散，权限交接也不能只被视为更换一个地址。
六、认为去掉管理员就能解决所有问题
减少管理权限与保留维护能力是不同的设计目标。对于仍需要管理操作的系统，撤销权限前应明确哪些功能将不可用，以及这是否符合业务要求。不能把“没有管理员”简单理解为完整的安全结论，也不能反过来认为保留管理员就能保证系统可持续运行。
七、常见问题：是否存在通用的最佳方案
没有脱离条件的统一答案。选择扩容路径，需要考虑确认要求、数据存放方式及可接受的信任假设；选择权限模型，需要考虑职责数量与交接需求。判断设计是否清楚，关键是能否说明性能改善来自哪里、依赖哪些参与者，以及重要权限由谁控制，而不是只列出技术名称。