Governance 1.0 是波卡的第一代开放治理模型，我们已经在《OpenGov 链上治理模块的基础介绍》一文中有所介绍。Governance 1.0 的核心特征是采用三院制的结构。
在项目发展前期阶段，三院制可以很好的协调团队与社区之间的治理权力，而且可以最大限度保证治理决策的安全与灵活。但随着项目的成熟，社区必然要求项目治理更加去中心化。OpenGov 就是波卡顺应这种诉求的产物。
相比 Governance 1.0，OpenGov 带来的最显著的变化是取消了理事会和技术委员会，所有的决策全部通过公投来处理。**与此同时，增设了更多的治理轨道（Track），完善了治理流程和委托机制，并创建了 Fellowship （专家团）。 ** 本文将为大家系统的介绍一下 OpenGov 的框架和结构。
在 OpenGov 中，一个提案从开始到终结共分为以下几个步骤：
提案被发起后进入准备期，这个阶段发起者需要放入押金，如果准备期结束时没有放入押金，提案自动失效。该阶段开始后，用户立即可以开始参与投票，但这个阶段，无论投票达到什么样的阈值，提案都不会被结束。（防止大户在其他人来不及留意的情况下，迅速通过提案）
该阶段，用户始终可以参与投票，投票达到阈值之后，进入确认期。投票阈值分为两个，分别是相对多数阈值和绝对多数阈值，也就是说，一个提案必须同时满足相对多数门槛和绝对多数门槛，才可以进入确认期。需要注意的是，这两个阈值是动态变化的，它是两条曲线，决策期越接近结束，阈值往往越小。其中，相对多数的阈值不会小于 50%
如果直到决策期结束，提案都没有满足阈值要求，该提案视为被拒绝。
在决策期满足阈值条件的提案会进入确认期，进入确认期后，用户依旧可以投票。在确认期内，该提案始终需要保持满足阈值条件，确认期一结束，提案就会正式被通过，进入执行期。如果在确认期内，用户继续投票导致提案不再满足阈值条件，该提案将退回决策期。再次进入确认期的提案，其确认期重新计时。
提案通过之后，会进入执行期，执行期结束后，该提案正式在链上生效。提案发起者可以自定义执行期，但不能小于提案所在轨道设定的最小执行期。
OpenGov 中，公投（Referenda）是唯一的权力机构，为了提升公投决策的效率，有更多的轨道用来处理提案，不同的轨道有不同的参数。
以 Polkadot 为例，Polkadot 设置了 26 个不同的轨道，如下图（截止2023.8.9）。
其中，轨道容量是指该提案轨道可以同时进行的最大提案数，押金是指提案发起者需要抵押的资金，押金的存在可以防止提案者提交垃圾提案。准备期、决策期、确认期、最小执行期则是该轨道的提案各个阶段的期限。除此之外，每个轨道的两个阈值曲线也是不同的。
这些不同的提案轨道，有的权限大，有的权限小，涉及的提案的危险程度不同，越危险的提案往往对系统越大的影响或者涉及越大金额的财库支出。我们发现权限较大的轨道容量更小，准备期、确认期、最小执行期更长，且需要的押金越大。
Small Tipper、Big Tipper、Small Spender、Medium Spender、Big Spender、Treasure 这几个轨道都可以用来发起从财库拨款的提案，但他们所能支付的单笔金额上限是不同的，对应的各项参数也不同。例如，权限最小的 Small Tipper 轨道可支持一次性从财库支付最多 250 DOT，该轨道的准备期、确认期、最小执行期分别只有 1 min、10mins、1min，提案押金仅为 1 DOT，权限最大的 Treasure 轨道可支持一次性从财库支付最多 10,000,000 DOT，其准备期、确认期、最小执行期则高达2hrs、3hrs、1day，提案抵押金高达 1000 DOT。此外，二者的轨道容量也差别很大， Small Tipper 的轨道容量为 200 个，Treasure 的轨道容量只有 10 个。
非财库类提案也是如此，权限最大的 root 轨道，支持对链上代码进行任意修改的提案，对系统影响程度重大，因此轨道容量只有 1，抵押高度 100K DOT，其准备期、确认期和最小执行期都较长。其他仅对某个细分领域进行管理，对系统影响程度较小的轨道则拥有更宽松的参数。
通过这样的设计，OpenGov 既可以做到敏捷的处理非危险提案的同时，也可以谨慎的处理危险提案。
我们还发现，有些轨道可以处理一些特殊类型的提案，例如 Referendum Canceller 和 Referendum Killer 可以用来取消垃圾提案或者恶意提案，Whitelist Caller 则可以用来处理紧急提案，Fellowship admin 可以用来管理 Fellowship 相关事务，我们将在下篇展开陈述。
