误区一：所有区块链决策都靠链上投票
以太坊治理介绍说明，其核心协议采用链下治理，涉及讨论、技术实现与多方协调；运行在以太坊上的DAO则可以采用链上治理。核心协议的变更不能简单用一次代币投票衡量社区共识。
因此，讨论投票系统时，首先要明确决策对象：是应用参数、组织资金，还是底层协议规则。某个应用的表决结果，只在相应权限与治理范围内生效。
误区二：地址数量等于参与人数
地址是链上账户标识，不能直接当作独立自然人的证明。按地址计票、按代币权重计票与按身份计票，表达的是不同的治理规则。
评价代表性时，需要看投票权如何分配、能否委托以及是否集中。公开可查的投票记录，有助于核验过程，但无法单独证明参与者具有同等影响力。
误区三：当前余额就是有效投票权
OpenZeppelin的Governor指南展示了基于历史快照确定投票权的机制，并将权重来源、法定票数和计票方式拆分为可配置模块。这说明投票结果取决于明确的合约规则。
在采用快照的系统中，应核对提案对应的快照时点及委托状态。投票期间余额发生变化，不代表该提案的有效票权会同步变化；快照机制也不能被理解为对所有治理风险的全面防护。
误区四：赞成票多就一定通过
表决通常需要分别检查参与门槛和赞成条件。赞成票超过反对票，并不必然满足法定票数；弃权票是否计入门槛，也取决于计票模块。
例如，OpenZeppelin的GovernorCountingSimple将赞成票与弃权票计入法定票数。此规则适用于该模块，不能推广到所有投票系统。阅读结果时，应同时查看计票口径与通过条件。
误区五：通过就会立即生效
提案通过、进入等待阶段与最终执行，是需要区分的状态。采用时间锁的系统可能要求延迟执行，具体流程还取决于执行权限和合约条件。
常见问题是“投票成功，为什么设置没有改变”。应进一步核对提案是否已执行，以及执行是否成功。界面显示的表决状态不能替代对执行结果的确认。
误区六：示例参数可以直接套用
投票延迟和持续时间必须结合系统时钟理解：区块数量与时间戳对应不同单位，按假定出块速度换算的时长也有适用条件。
同样，提案门槛和法定票数需要结合参与结构判断。理解一个系统是否适用，应把权重、门槛、时间和执行条件连起来看，而不能仅凭“采用链上投票”判断其治理质量。