NOTICE
This thread will have a substantial amount of responses, so in order to make it possible for everyone to participate please click on messages that the late joiners should read, so that Discourse can hide “chatter” and so that it is possible to catch up to the thread quickly.
You have a limited amount of those clicks per day, so use them wisely.
How long do governance participants need to protest?
The new governance system of BitTensor makes it possible for validators and subnet owners to delay an upgrade proposed by OTF. In the first draft of the governance implementation, it was specified that if no validators and owners record their protests on the chain, then the upgrade goes through, and Triumvirate may deploy it. Not everyone is super happy about the minimum delay being 1h, so lets talk about it.
Speed for hotfixes
The problem is that sometimes we need to be able to deploy an emergency hotfix, so being able to do things quickly when necessary, is important for security. On the other hand, we don’t want the hotfix track to be used to deploy new features.
Default to false?
Someone said that if it is set to 1h, they will just set a script to automatically protest everything, so that the community has more time to decide. Then someone said that they trust OTF, so in order to counter the first guy, they will set a script to always support every proposal.
IDK about you, but after hearing this I no longer feel this is going to be a great system…
Other solutions
Surely there are plenty of ways this can be implemented, we can draw inspiration from other ecosystems, we can look at them in terror and vow to never do anything like that and we can design our own.
Lets discuss - what won’t work and why? What might work?
There should be a doxxed, fast-response team responsible for handling hotfixes, bugs, zero-days, and security incidents. This team should be able to bypass governance voting when necessary—strictly under the condition that no new features are introduced, only critical fixes and security patches.
It makes no sense to delay responses to these issues just so people can “vote” on whether to adopt them. For example:
Dev1: “Hey, I patched a zero-day bug that could take down the network.” Dev2: “Great! Let’s submit it to a vote and hope the community chooses to protect their own assets. Fingers crossed!”
If the purpose of voting is to enable community peer review, then the selected developers are probably not as competent as they should be. At this level, they should be capable of understanding the problem far better than 99.9% of the community. The voting process would only slow them down in the best case scenario.
Even from a principle standpoint, it doesn’t make sense. Imagine going to a hospital where a surgeon, mid-operation, turns to the audience and asks: “Should I cut here or there? If I cut here, the patient might die—but I want to respect the decentralized process.”
Decentralization does not mean abandoning common sense. For certain decisions—especially critical and important responses—a small group of highly capable individuals is better equipped to act quickly and effectively. The community could vote on who those individuals are if needed, not on every decision they make.
How about taking inspiration on how the next consensus blockchain scheme works, this should work like the upcoming NPoS consensus model, where people DELEGATE their voting power.
I want to emphasize this point further, because the risk here is serious and easy to underestimate.
In the software industry, it is standard practice for security researchers and white-hat groups to follow Responsible Disclosure. When they discover vulnerabilities, they give the software provider a reasonable window to fix the issue before making it public. For example, Google Project Zero popularized the 90-day disclosure rule.
This practice exists for one reason: to protect users. It gives teams the time needed to apply fixes effectively and reduce the risk of exploitation.
In our case, we would be doing the exact opposite. We would effectively signal to attackers that a vulnerability exists, provide insight into how it can be exploited, and give them time to act before protections are in place. The “1-hour rule” would not solve this problem, as already explained by Rhef.
Under this model, we wouldn’t just be exposed to attackers—we would actively attract them, handing over the blueprint while real user funds are at risk.
I’ll say this clearly: decentralization should be treated as a tool, not a goal in itself. It should be applied where it improves outcomes—not enforced blindly because it feels ideologically correct. Otherwise, this mindset will eventually lead to serious, and potentially catastrophic, consequences.
on messages that the late joiners should read, so that Discourse can hide “chatter” and so that it is possible to catch up to the thread quickly.