一、治理层级：先确定改变什么
讨论区块链治理方案涉及哪些技术概念，首先要确定治理对象。底层协议治理处理网络规则的变更；应用治理则可能处理合约参数、升级或资金管理。两者都需要决策机制，但权限范围不同，应用的投票结果不能直接改写底层协议。
二、链上治理与链下治理
以太坊官网的治理说明指出，其核心协议采用链下治理，通过利益相关方讨论和技术协调推进变更；运行在以太坊上的去中心化自治组织，则可以使用链上治理。链上治理通常把投票记录在区块链上，部分方案还能按批准结果执行预先编写的操作。
适用哪种方式，取决于决策能否明确表达为程序，以及执行对象是否受治理机制控制。链上记录提高了过程的可核验性，但不能替代对提案内容的讨论。
三、提案规范、客户端与升级
以太坊改进提案，即EIP，用于描述潜在功能或流程变化。核心协议变更还需经过讨论、实现、测试和升级协调。客户端是执行协议规则的软件，不同实现需要对变更形成一致理解；存在重大分歧时，可能出现不兼容的链分裂。
这里应区分提案文档与生效规则：提出方案不代表已被接受，完成实现也不代表网络已经采用。判断治理进度，要分别查看规范、测试和部署状态。
四、投票权、委托与历史快照
OpenZeppelin的治理文档以模块化Governor合约组织提案和表决。ERC20Votes提供投票权委托与历史记录，使治理能够读取指定时间点的投票权，而不是随时使用当前余额。
快照的意义是统一计票依据，避免余额转移导致同一份权重被重复使用。持有数量、被委托的投票权和实际参与表决的权重不宜混为一谈，具体关系取决于所采用的规则。
五、门槛、时钟与时间锁
治理参数包括提案门槛、投票延迟、投票期和法定参与门槛。OpenZeppelin提供不同计票模块，并支持与时间锁衔接；其治理时钟可以使用区块高度或时间戳。
提案门槛回答谁能发起表决，法定参与门槛回答参与是否充分，通过条件回答结果是否获准。时间锁则在执行前引入等待期。这些参数不能互相替代，时间单位也必须明确，避免把区块数量直接理解为固定时长。
六、常见问题：投票通过就能执行吗
不一定。应分别检查结果是否满足通过条件、是否需要排队等待，以及执行机制是否拥有目标操作所需权限。自动执行只适用于已经建立相应代码和权限关系的方案。
评价治理方案，也不能只看是否采用代币投票。更完整的问题是：谁能提出变更、权重如何确定、反对意见如何处理，以及最终由什么机制落实决策。