Table of Contents
Bittensor could move to fully onchain governance as early as this summer, marking one of the most consequential structural changes in the network’s history.
The proposal introduces a decentralized governance system designed to move Bittensor away from centralized coordination and toward a process where network decisions are made, reviewed, and executed entirely onchain. If implemented, the system would govern everything from runtime upgrades to key protocol changes through a two-stage process intended to balance speed, accountability, and predictability.
Proposal/concept slides can be viewed HERE
Rather than adopting a traditional token-voting DAO structure, the proposal introduces a small decision-making body designed for speed, paired with a broader review layer designed to slow, accelerate, or even cancel changes before they take effect. Every stage, from proposal submission to execution, would happen onchain without relying on offchain multisigs or discretionary intervention.
In this guide, we’ll break down exactly how the proposed governance system works, who gets to participate, what tradeoffs it makes, and why it could reshape how Bittensor evolves moving forward.
The Core Idea: Fast Decisions, Broader Review
Most blockchain governance systems struggle to balance speed with accountability. Small groups can move quickly but concentrate power, while large token-holder assemblies are more decentralized but often move slowly, become difficult to coordinate, or fail to reach consensus at all.
The proposed Bittensor model attempts to split those responsibilities into two distinct stages.
In the first stage, a small three-member committee called the Triumvirate would make fast initial decisions on proposals. Instead of long debate cycles or open-ended voting periods, the group would operate within a fixed seven-day window and either approve or reject a proposal with a threshold of 2/3 votes.
If approved, the proposal would not immediately execute.
Instead, it would move into a second stage called Review, where a broader body of validators and subnet builders would examine the decision before it takes effect. During this period, reviewers could fast-track a proposal, slow it down, or cancel it entirely, depending on how support develops.
Under the proposed rules, 75% approval would fast-track execution, while 51% rejection would cancel the proposal outright.
To recap, the Triumvirate is designed to quickly answer the question:
Should this proposal move forward?
The slower review layer answers:
Does the broader network agree this should happen, and how quickly should it happen?
In practice, the design prioritizes fast execution while preserving a review mechanism designed to reduce mistakes, governance capture, or rushed upgrades.
Why Bittensor Isn’t Using Traditional DAO Governance
Most governance systems force networks into uncomfortable tradeoffs.
Move quickly, and governance becomes centralized around a small group of operators or multisig holders. Maximize participation, and decision-making can become slow, contentious, or difficult to coordinate. Optimize for safety, and upgrades may take so long that the network struggles to adapt.
Bittensor’s governance challenge is especially unusual because the network sits at the intersection of finance, AI infrastructure, and rapidly evolving software systems. Runtime upgrades, subnet incentives, validator mechanics, and emission rules may eventually require a cadence of decision-making that traditional token-voting systems struggle to support.
The proposal frames the problem around three goals, arguing that most governance systems tend to optimize for only two these these goals at once:
- Decisive: proposals should move quickly and avoid governance paralysis.
- Checked: important decisions should face broader review before execution.
- Predictable: execution rules should be transparent and enforced onchain rather than relying on discretionary intervention.
For example, traditional DAOs often maximize decentralization and legitimacy but sacrifice speed. Multisigs can move quickly and predictably but rely heavily on trust in a small number of operators. Meanwhile, open token voting systems may expose networks to governance attacks, low participation, or decision-making dominated by a handful of large holders.
Therefore, instead of choosing one model outright, the Bittensor governance proposal attempts to combine elements of several systems.
A small committee handles rapid decision-making. A broader, automatically selected review body provides oversight. Execution thresholds, delays, and voting rules live directly onchain. This gives us speed at the front, scrutiny before execution, and predictable rules throughout the process.
Who Actually Gets to Govern?
One of the biggest questions surrounding any governance system is who actually gets a seat at the table?
Under this proposal, Bittensor governance would be divided across five collectives, each serving different roles within the system:
- Proposers: submit governance proposals.
- Triumvirate: the first-stage decision body.
- Economic collective: validators who participate in review.
- Building collective: subnet builders who participate in review.
- Economic eligible: a staging pool used to determine future validator participation.
While five collectives exist, only two groups actively govern decisions: the Triumvirate, and Reviewers (combination of Economic and Building reviewers).
In Bittensor, validators represent the network’s economic and security layer, while subnet operators represent the people actively building the ecosystem. To ensure both groups are properly represented in governance and to prevent one constituency from dominating governance, the proposal brings both into the review process.
The Triumvirate: Bittensor’s Fast Decision Layer
The first stage of governance belongs to the Triumvirate, a three-member committee responsible for deciding whether proposals move forward at all.
The group would vote during a fixed seven-day decision period, with two of three votes required for approval or rejection.
At launch, the proposal suggests the Triumvirate would remain curated, meaning members are selected rather than automatically computed onchain. However, the framework explicitly leaves open the possibility of moving this process onchain in the future.
Its job is intentionally narrow: make fast initial decisions and decide whether proposals deserve broader review.
In practice, the Triumvirate functions less like a permanent governing council and more like an initial filter.
Economic Reviewers: Validators Earn Seats
The Economic collective consists of validators selected through onchain metrics. Seats rotate every 60 days, with membership determined by smoothed stake value rather than short-term balance spikes.
To qualify, validator coldkeys must operate at least one root-registered hotkey. Rankings are based on an EMA (exponential moving average) system designed to reduce manipulation from temporary stake movements.
The top 16 validator coldkeys earn review seats.
Importantly, membership is computed automatically by the runtime, not appointed manually.
Building Reviewers: Subnet Operators Get a Voice
The Building collective is made up of subnet builders.
Rather than stake, these seats are determined by subnet maturity and performance. Only subnets older than 180 days qualify, and seats are awarded based on the strongest mature subnet controlled by an operator.
The proposal explicitly prevents one entity from accumulating influence through multiple successful subnets:
one owner, one seat.
Like validator seats, membership rotates every 60 days and is selected automatically through onchain criteria.
A Governance System That Changes Speed, Not Just Outcomes
Once a proposal passes the Triumvirate and enters review, it moves into what the proposal calls a dynamic delay system, where reviewers do more than simply vote yes or no.
Instead, votes actively shape how long a proposal waits before execution.
Under the proposed framework, every approved proposal enters review with a default 24-hour delay before enactment. From there, reviewer sentiment can speed things up, slow things down, or stop execution altogether.
Strong support accelerates the process.
If reviewers reach 75% approval, the proposal is automatically fast-tracked, allowing it to move toward execution more quickly.
Growing opposition has the opposite effect.
Rather than immediately failing, proposals encountering resistance can be slowed down, extending the review period and giving the network additional time to evaluate potential risks or unintended consequences.
At the extreme end, 51% rejection cancels the proposal entirely.
The proposal describes this as an “ease-out” curve, meaning changes to execution timing happen gradually. Neutral sentiment tends to keep proposals near the default delay window, while stronger signals increasingly push execution faster or slower.
The proposal also includes several guardrails designed to prevent manipulation during this phase.
Safety Rails: What Stops Governance Abuse?
Governance systems are ultimately stress-tested during bad outcomes, not smooth ones.
What happens if participants try to manipulate voting? What if governance gets spammed with proposals? What prevents execution from changing midway through a vote?
The proposal includes several mechanisms intended to reduce those risks while keeping governance operationally predictable.
Frozen Voter Sets
One of the more important protections is that review participants are snapshotted when voting begins.
Once a proposal enters review, the eligible voter set becomes fixed for the duration of that referendum. Validators cannot suddenly gain or lose influence mid-process because of stake movements, ranking changes, or collective rotations.
In practice, this means governance decisions happen against a stable voter base rather than a constantly shifting one.
The same logic applies to governance rules themselves. Thresholds and parameters are frozen during active review, preventing the network from changing the rules of the game after voting has already begun.
No Governance Backdoor
The proposal also removes alternative pathways around review.
Every proposal must begin in Track 0, meaning the Triumvirate acts as the required entry point for governance.
Review cannot be submitted independently, bypassed, or escalated through another mechanism. If a proposal fails at the first stage, it stops there.
That structure is designed to make governance behavior predictable and reduce ambiguity around how changes reach execution.
Limits on Governance Spam
To prevent proposal overload, the system introduces queue restrictions.
Under the proposed framework:
- A maximum of 20 referenda can remain active at one time.
- Individual proposers are limited to five active proposals simultaneously.
This keeps governance bandwidth finite to prevent the system from becoming overwhelmed by low-quality or excessive submissions.
Emergency Intervention and Execution Safety
The proposal also introduces an emergency mechanism allowing active or scheduled referenda to be terminated before execution if necessary.
Execution itself is handled atomically, meaning proposal enactment and bookkeeping occur together rather than through fragmented processes that could create inconsistencies or stale state. Moreover, governance records are cleaned up gradually through chunked draining, reducing the risk that governance maintenance itself creates sudden block-weight spikes or operational instability.
Together, these safeguards help the governance framework anticipate manipulation, congestion, and edge cases before they emerge.
A Governance System Built for the Bittensor of Tomorrow
The framework, if launched, would begin with a relatively narrow starting point: two governance tracks, limited collectives, and a small first-stage decision body. But beneath that minimal rollout sits a governance engine designed to support much more over time.
Future iterations could introduce emergency governance tracks for urgent fixes, lighter pathways for lower-stakes parameter changes, delegator review pools, weighted voting systems, alternative voting curves, and broader participation mechanisms. Over time, governance itself could even take over privileged runtime functions traditionally handled through more centralized forms of coordination.
As the proposal puts it:
“The machinery is deliberately bigger than the runtime uses.”
In other words, the framework is being designed not only for Bittensor as it exists today, but for the network Bittensor may become.
FAQs
What is Bittensor’s proposed decentralized governance system?
Bittensor’s proposed governance system is a new on-chain governance framework introduced by Const that would allow protocol upgrades and network decisions to be approved, reviewed, and executed entirely on-chain. The system uses a two-stage process involving a small decision-making committee and a broader review layer made up of validators and subnet builders.
When could Bittensor decentralized governance launch?
According to Const, Bittensor could move toward decentralized governance sometime this summer, though the proposal is still under discussion and subject to refinement before implementation.
How would Bittensor governance work?
Under the proposal, governance would happen in two stages:
- Triumvirate decision phase: A three-member committee decides whether proposals move forward. Two of three votes are required to approve or reject a proposal.
- Review phase: Automatically selected validators and subnet builders review approved proposals before execution. They can fast-track, delay, or cancel proposals depending on support levels.
What is the Triumvirate in Bittensor governance?
The Triumvirate is a proposed three-member decision body that would serve as the first stage of Bittensor governance. Its role is to make fast initial decisions on proposals before broader network review takes place.
Who gets to vote in Bittensor governance?
The proposal introduces two main review groups:
- The Economic collective, made up of validators selected through on-chain stake metrics.
- The Building collective, made up of mature subnet operators selected based on subnet performance.
Both groups would rotate every 60 days and be selected automatically through on-chain criteria.
Does Bittensor governance use token voting?
Not in the traditional sense.
Rather than open token-holder voting for every proposal, the proposed system uses computed review groups made up of validators and subnet builders. The goal is to balance decentralization with faster decision-making.
How are proposals approved or rejected?
After passing the Triumvirate, proposals enter review.
- 75% approval fast-tracks execution.
- 51% rejection cancels the proposal.
- Neutral support keeps proposals on a default execution timeline.
The system also allows governance participants to influence how quickly proposals execute.
What problems is Bittensor governance trying to solve?
The proposal is designed to address common governance tradeoffs around speed, accountability, and predictability.
Const argues many governance systems become too slow, overly centralized, or vulnerable to governance attacks. The proposed model attempts to combine fast decision-making with broader oversight and fully on-chain execution.
Could Bittensor governance expand in the future?
Yes.
The proposal is intentionally designed to evolve over time. Future iterations could introduce emergency governance tracks, delegator participation, weighted voting, conviction voting, and additional review systems as the network matures.
Disclaimer: This article is for informational purposes only and does not constitute financial, investment, or trading advice. The information provided should not be interpreted as an endorsement of any digital asset, security, or investment strategy. Readers should conduct their own research and consult with a licensed financial professional before making any investment decisions. The publisher and its contributors are not responsible for any losses that may arise from reliance on the information presented.
