Bittensor’s governance architecture is undergoing one of its most consequential overhauls to date, yet community participation in the discussion has remained limited.
After months of internal debate and proposal drafting, Church of Rao is introducing a comprehensive on-chain governance system to replace the network’s current sudo-based triumvirate multisig structure.
With structural changes that affect proposers, validators, subnet owners, and execution timelines, contributors are now urging wider ecosystem engagement before the framework progresses toward full migration.
Why Governance is Being Reworked
The current governance model relies on a sudo-enabled triumvirate multisig arrangement. While functional, it centralizes authority and limits broader stakeholder oversight.
The proposed system introduces:
a. On-chain transparency and auditability,
b. A separation of powers model,
c. Formalized collective oversight mechanisms, and
d. Automated execution flows tied to defined delay periods.
The objective is to transition from a centralized administrative structure toward a more distributed, rules-based governance framework embedded directly within the runtime.
Core Structure of the New Governance Model
The pull request introduces a new pallet-governance module that establishes three primary governance pillars:
1. Allowed Proposers: These are authorized accounts, primarily controlled by the OpenTensor Foundation, that have the power to submit proposals with root execution privileges.
2. The Triumvirate: A three member approval body with voting window of 7 days, and approval requirement of 2 of 3 votes. Only proposals approved by the triumvirate move forward.
3. Dual Oversight Collectives: Contains two stakeholder bodies grouped into:
a. Economic Power Collective: Top 16 validators ranked by stake, and
b. Building Power Collective: Top 16 subnet owners ranked by moving average price.
These collectives can delay proposals, cancel proposals, and also fast track proposals Delays follow an exponential model based on net voting score.
Governance Flow Overview
The new governance process unfolds in clearly defined stages:
a. An allowed proposer submits a proposal,
b. The triumvirate votes within a 7-day window,
c. If approved, the proposal enters a delay period, initially set at 1-hour,
d. The collectives may vote to delay, cancel, or fast track., and
e. The proposal executes automatically after the delay period or immediately if fast tracked..
This replaces discretionary sudo execution with rule-based scheduling through pallet-preimage and pallet-scheduler.
Infrastructure and Runtime Updates
The implementation includes several structural upgrades:
a. Introduction of the pallet-governance module with full-test coverage,
b. Runtime benchmarking support,
c. Transition to ParityDbWeight for database consistency,
d. Integration across workspace dependencies, and
e. Emergency procedures, proposal cancellation, and withdrawal mechanisms.
In addition to these, the deployment plan is structured in three phases:
a. PHASE 1: Coexistence with the existing sudo multisig for validation,
b. PHASE 2: Refinement and addition of triumvirate seat election logic, and
c. PHASE 3: Governance vote to disable the sudo pallet entirely.
Key Open Questions Under Discussion
Despite the technical progress, several design decisions remain unsettled:
a. How should the top 16 validators be fairly selected when stake concentration through weight copiers can cluster influence under single keys,
b. Should the default review window remain at 1-hour, or be extended to 24-hours, and
c. How should emergency upgrades be handled without bypassing governance safeguards.
These structural choices may determine how power is distributed across validators, subnet operators, and institutional participants.
ZK (Zero Knowledge) Voting and Institutional Participation
One proposed enhancement includes zero knowledge-based voting mechanisms. The aim is to enable institutional validators to participate without exposing themselves to potential regulatory or legal liability through public vote disclosure.
This would introduce privacy preserving participation while maintaining on-chain verifiability.
From Centralization to Structured Oversight
The redesign represents a formal shift away from a centralized administrative model toward a layered governance system with checks and balances. Thus, it introduces:
a. Defined proposer roles,
b. A limited approval body,
c. Stake-weighted oversight collectives,
d. Transparent delay mechanics, and
e. Automated execution.
After three months of internal discussion, contributors are now calling for broader ecosystem participation before the system advances through its final migration stages.
With governance directly shaping the future trajectory of Bittensor, the coming feedback period may prove as important as the code itself.
Getting Involved
To contribute and get up-to-date intel on the procedure through official channels, follow the Church of Rao via:
Discord: https://discord.com/invite/dYG9pQ354U
X (Formerly Twitter): https://x.com/ChurchOfRao
GitHub: discord.gg/dYG9pQ354U
Virtual Forum: https://forum.bittensor.church/t/chain-governance-update/75/5
Be the first to comment