WIP Governance

pallets/admin-utils/src/tests/mock.rs

@@ -381,7 +381,6 @@ parameter_types! {
     pub MaximumSchedulerWeight: Weight = Perbill::from_percent(80) *
         BlockWeights::get().max_block;
     pub const MaxScheduledPerBlock: u32 = 50;
-    pub const NoPreimagePostponement: Option<u32> = Some(10);
 }
 
 impl pallet_scheduler::Config for Test {

pallets/governance/Cargo.toml

@@ -0,0 +1,43 @@
+[package]
+name = "pallet-governance"
+version = "1.0.0"
+authors = ["Bittensor Nucleus Team"]
+edition.workspace = true
+license = "Apache-2.0"
+homepage = "https://bittensor.com"
+description = "BitTensor governance pallet"
+readme = "README.md"
+
+[lints]
+workspace = true
+
+[package.metadata.docs.rs]
+targets = ["x86_64-unknown-linux-gnu"]
+
+[dependencies]
+codec = { workspace = true, features = ["max-encoded-len"] }
+frame = { workspace = true, features = ["runtime"] }
+scale-info = { workspace = true, features = ["derive"] }
+subtensor-macros.workspace = true
+frame-support.workspace = true
+frame-system.workspace = true
+sp-runtime.workspace = true
+sp-std.workspace = true
+log.workspace = true
+
+[dev-dependencies]
+pallet-balances = { workspace = true, default-features = true }
+pallet-preimage = { workspace = true, default-features = true }
+pallet-scheduler = { workspace = true, default-features = true }
+sp-core = { workspace = true, default-features = true }
+sp-io = { workspace = true, default-features = true }
+
+[features]
+default = ["std"]
+std = ["codec/std", "frame/std", "scale-info/std"]
+runtime-benchmarks = [
+	"frame/runtime-benchmarks",
+]
+try-runtime = [
+	"frame/try-runtime",
+]

pallets/governance/README.md

@@ -0,0 +1,192 @@
+# On-Chain Governance System
+
+## Abstract
+
+This proposes a comprehensive on-chain governance system to replace the current broken governance implementation that relies on a sudo-based triumvirate multisig. The new system introduces a separation of powers model with three key components: (1) multiple proposer accounts (mostly controlled by OTF) to submit proposals (call executed with root privilege), (2) a three-member Triumvirate that votes on proposals, and (3) two collective bodies (Economic Power and Building Power) that can delay, cancel, or fast-track proposals and vote to replace Triumvirate members. The system will be deployed in two phases: first coexisting with the current sudo implementation for validation, then fully replacing it.
+
+## Motivation
+
+The current governance system in Subtensor is broken and relies entirely on a triumvirate multisig with sudo privileges. The runtime contains dead code related to the original triumvirate collective and senate that no longer functions properly. This centralized approach creates several critical issues:
+
+1. **Single Point of Failure**: The sudo key represents a concentration of power with no on-chain checks or balances (i.e., no blockchain-enforced voting, approval, or oversight mechanisms).
+2. **Lack of Transparency**: The governance decision-making process (who voted, when, on what proposal) happens off-chain and is not recorded or auditable on-chain. While the multisig signature itself provides cryptographic proof that the threshold was met, the governance process leading to that decision is opaque.
+3. **No Stakeholder Representation**: Major stakeholders (validators and subnet owners) have no formal mechanism to influence protocol upgrades.
+4. **Technical Debt**: Dead governance code in the runtime creates maintenance burden and confusion.
+
+This proposal addresses these issues by implementing a proper separation of powers that balances efficiency with stakeholder representation, while maintaining upgrade capability and security.
+
+## Specification
+
+### Overview
+
+The governance system consists of three main actors working together:
+
+1. **Allowed Proposers**: Accounts authorized to submit proposals (mostly controlled by OTF)
+2. **Triumvirate**: Approval body of 3 members that vote on proposals
+3. **Economic and Building Collectives**: Oversight bodies representing major stakeholders: top 16 validators by total stake and top 16 subnet owners by moving average price respectively
+
+### Actors and Roles
+
+#### Allowed Proposers (mostly OTF-controlled)
+
+- **Purpose**: Authorized to submit proposals (calls executed with root privilege)
+- **Assignment**: Allowed proposer account keys are configured in the runtime via governance
+- **Permissions**:
+  - Can submit proposals to the main governance track (i.e., runtime upgrade proposals or any root extrinsic)
+  - Can cancel or withdraw their own proposals anytime before execution (i.e., if they find a bug in the proposal code)
+  - Can eject its own key from the allowed proposers list (i.e., if it is lost or compromised)
+  - Can propose an update to the allowed proposers list via proposal flow
+
+**Open Questions:**
+
+- Q1: Who can add/remove proposer accounts? Only governance or should Triumvirate have emergency powers?
+- Q2: Who validates that proposal code matches stated intent before Triumvirate votes? Share runtime WASM hash like Polkadot fellowship does?
+
+#### Triumvirate
+
+- **Composition**: 3 distinct accounts (must always maintain 3 members)
+- **Role**: Vote on proposals submitted by allowed proposers
+- **Voting Threshold**: 2-of-3 approval required for proposals to pass
+- **Term**: Indefinite, subject to replacement by collective vote every 6 months (configurable)
+- **Accountability**: Each member can be replaced through collective vote process (see Replacement Mechanism)
+- **Permissions**:
+  - Can vote on proposals submitted by allowed proposers
+
+**Open Questions:**
+
+- Q3: How to allow a triumvirate member to resign?
+
+#### Economic and Building Collectives
+
+- **Economic Collective**: Top 16 validators by total stake (including delegated stake) (configurable)
+- **Building Collective**: Top 16 subnet owners by moving average price (with minimum age of 6 months) (configurable)
+- **Recalculation**: Membership refreshed every 6 months (configurable)
+- **Permissions**:
+  - Can vote aye/nay on proposals submitted by allowed proposers and approved by Triumvirate
+    - More than 2/3 of aye vote for any collective fast tracks the proposal (next block execution) (threshold configurable)
+    - More than 1/2 of nay vote for any collective cancels the proposal (threshold configurable)
+    - Nays votes accumulate and delay the proposal execution exponentially until cancellation (see Delay Period section)
+  - Can replace a Triumvirate member every 6 months via single atomic vote (remove current holder + install replacement candidate, with rotating seat selection)
+  - Can mark himself as eligible for nomination to the Triumvirate
+  - Can accept a nomination to the Triumvirate
+
+**Open Questions:**
+
+- Q4: How to handle the nomination process?
+- Q5: How to incentivize the collective members to vote?
+
+### Governance Process Flow
+
+#### Proposal Submission
+
+1. An allowed proposer account submits a proposal containing runtime upgrade or any root extrinsic
+2. Proposal enters "Triumvirate Voting" phase
+3. Voting period: 7 days (configurable), after this period, the proposal is automatically rejected if not approved by the Triumvirate.
+
+- There is a queue limit in the number of proposals that can be submitted at the same time (configurable)
+- Proposal can be cancelled by the proposer before the final execution for security reasons (e.g., if they find a bug in the proposal code).
+- An allowed proposer can eject its own key from the allowed proposers, removing all its submitted proposals waiting for triumvirate approval from the queue.
+
+#### Triumvirate Approval
+
+1. Triumvirate members cast votes (aye/nay) on the proposal
+
+- 2/3 vote aye, proposal is approved: Proposal is scheduled for execution in 1 hour (configurable) and enters "Delay Period"
+- 2/3 vote nay, proposal is rejected: Proposal is cleaned up from storage (it was never scheduled for execution).
+
+- Triumvirate members can change their vote during the voting period (before the proposal is scheduled or cancelled).
+- There is a queue limit in the number of scheduled proposals and in the delay period (configurable).
+- If a triumvirate member is replaced, all his votes are removed from the active proposals.
+
+#### Delay Period (Collective Oversight)
+
+When a proposal has been approved by the Triumvirate, it is scheduled in 1 hour (configurable) and enters the "Delay Period" where the Economic and Building Collectives can vote to delay, cancel or fast-track the proposal.
+
+1. Both collectives can vote aye/nay on the proposal
+2. Delay is an exponential function of the number of nays votes, set to 2^n (configurable).
+
+- Initial delay is 1 hour (configurable).
+- After 1 nays vote, the delay is 2^1 \* 1 hour = 2 hours.
+- After 2 nays votes, the delay is 2^2 \* 1 hour = 4 hours.
+- After 3 nays votes, the delay is 2^3 \* 1 hour = 8 hours.
+- After 4 nays votes, the delay is 2^4 \* 1 hour = 16 hours.
+- After 5 nays votes, the delay is 2^5 \* 1 hour = 32 hours.
+- After 6 nays votes, the delay is 2^6 \* 1 hour = 64 hours.
+- After 7 nays votes, the delay is 2^7 \* 1 hour = 128 hours.
+- After 8 nays votes, the delay is 2^8 \* 1 hour = 256 hours.
+- After 9 nays votes, proposal is cancelled (given we have a collective size of 16, hence more than 1/2 of the collective votes nay).
+
+3. If the delay period expires without cancellation: Proposal executes automatically
+
+- The delay is calculated based on the collective with the most nays votes (i.e., if Economic has 3 nays and Building has 1 nay, the delay is based on 3 nays = 8 hours).
+- More than 2/3 of aye vote for any collective fast tracks the proposal (next block execution) (threshold configurable)
+- More than 1/2 of nay vote for any collective cancels the proposal (threshold configurable)
+- Collective members can change their vote during the delay period. If changing a nay vote to aye reduces the delay below the time already elapsed, the proposal executes immediately.
+  - **Example**: A proposal has 3 nays votes, creating a 8 hours delay. After 5 hours have elapsed, a collective member changes their nay vote to aye, reducing the delay to 4 hours. Since 5 hours have already passed (more than the new 4 hours delay), the proposal executes immediately.
+
+**Open Questions:**
+
+- Q6: Should the voting be across both collectives or each collective votes independently? What if a collective decide to go rogue and fast track proposals that the other collective is against or vice versa?
+
+#### Execution
+
+- Proposals executed automatically after the delay period if not cancelled or when fast-tracked by the collectives.
+- If executing fails, the proposal is not retried and is cleaned up from storage.
+
+### Triumvirate Replacement Mechanism
+
+Each collective can replace one Triumvirate member every 6 months through a **single atomic vote**: the collective votes to replace the current seat holder with a randomly selected new candidate from the eligible candidates. If the vote succeeds, the replacement happens immediately. The Triumvirate always maintains exactly 3 active members.
+
+#### Timing
+
+- Each collective can initiate replacement vote every 6 months (configurable)
+- Economic and Building collectives have independent cycles (seat are rotated independently)
+
+**Open Questions:**
+
+- Q7: How to have an emergency replacement vote?
+- Q8: Can a replaced member be voted back in immediately, or should there be a cooldown period?
+
+#### Rotating Seat Selection
+
+- Triumvirate seats are numbered: Seat 0, Seat 1, Seat 2
+- Each collective maintains an independent rotation index that determines which seat they target:
+- Economic Power automatically targets the next seat in rotation:
+  - If last removal was Seat 0, next automatically targets Seat 1
+  - If last removal was Seat 1, next automatically targets Seat 2
+  - If last removal was Seat 2, next automatically targets Seat 0
+- Building Power has independent automatic rotation
+- Rotation ensures no single seat is disproportionately targeted
+- Collective members cannot choose which seat to target: it's determined automatically
+
+#### Replacement Process (Single Atomic Vote)
+
+The replacement happens in a single vote where the collective votes **both** to remove the current seat holder **and** to install a specific replacement candidate. This is an atomic operation: either both happen or neither happens.
+
+**Process:**
+
+1. **Eligibility Phase**: Collective members can mark themselves as eligible for nomination to the Triumvirate.
+2. **Voting Phase**: Collective members can vote aye/nay during the voting period to replace the current seat holder.
+   - Threshold of more than 1/2 of the collective size (configurable)
+   - **If vote succeeds**: Current seat holder immediately removed, replacement candidate immediately installed
+   - **If vote fails**: No change, current member remains.
+3. **Selection Phase**: The replacement candidate is selected randomly from the eligible candidates.
+4. **Validation Phase**: The replacement candidate validates their nomination on-chain to avoid nominating inactive members.
+5. **Transition**: Atomic swap ensures Triumvirate always has exactly 3 members with no vacancy period
+
+### Implementation Phases
+
+#### Phase 1: Coexistence (Duration: TBD)
+
+1. Remove dead code: triumvirate collective and senate pallets and related code
+2. Implement the governance as a new pallet
+3. Deploy new governance pallet to runtime
+4. Configure initial Triumvirate members and allowed proposers.
+5. Run new governance system in parallel with existing sudo multisig
+6. Emergency procedures documented and tested
+7. Community review and feedback period
+
+#### Phase 2: Full Migration
+
+1. Disable sudo pallet via governance vote (new runtime)
+2. New governance system becomes sole authority