[Governance 1/4] Introduce pallet-multi-collective#2805
Conversation
🛡️ AI Review — Skeptic (security review)VERDICT: SAFE BASELINE scrutiny: l0r1s has write permission, an older account, substantial prefetched contribution history, no Gittensor allowlist hit, and matching in-PR authorship; branch governance-multi-collective -> governance-umbrella. Static-only Skeptic review of the prefetched diff found no FindingsNo findings. Prior-comment reconciliation
ConclusionNo malicious pattern or security vulnerability was identified in the current PR diff. Prior findings no longer apply to this review because the files they referenced are absent from the updated diff. 📜 Previous run (superseded)
🔍 AI Review — Auditor (domain review)VERDICT: 👍 Gittensor UNKNOWN; author has repo write permission and substantial prior Subtensor contribution history, so review is calibrated as established contributor work. No blocking domain findings from static review. This PR introduces a standalone The overlapping PRs are expected stacked governance/workspace work rather than better duplicate implementations of this pallet. One PR-body cleanup remains: the Detailed Reference link text names FindingsNo findings. ConclusionApprove on domain review: the new membership extrinsics have explicit origins, bounded storage, generated weights, integrity/try-state checks, and broad unit coverage for sorted membership, bounds, hooks, and rotation behavior. I did not run tests because no finding required runtime confirmation. |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👍 |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: VULNERABLE |
|
🔄 AI review updated — Skeptic: SAFE Auditor: 👍 |
| .binary_search(&remove) | ||
| .map_err(|_| Error::<T>::NotMember)?; | ||
| let pos_add = members | ||
| .binary_search(&add) |
There was a problem hiding this comment.
How large are member vectors anticipated to be? For small vectors simple iteration is often more efficient than binary search.
There was a problem hiding this comment.
How large are member vectors anticipated to be? For small vectors simple iteration is often more efficient than binary search.
Biggest collective will be 64 in the initial wiring but we may quickly add new collectives of unknown size. I preferred binary search here instead of linear search to make the pallet future proof even though we have a relatively small overhead for small collectives.
Summary
Part of #2804.
Adds
pallet-multi-collective, a generic membership pallet for storing multiple named collectives under a runtime-definedCollectiveId.This is a building block for governance membership only. It does not add voting, proposing, or runtime governance behavior by itself.
What Changed
pallet-multi-collective.add_member,remove_member,swap_member,set_members, andforce_rotate.OnMembersChangedand term-rotation hooks for downstream consumers.Detailed Reference
See
pallets/multi-collective/README.mdfor the full design reference. It covers the membership storage model, extrinsic behavior, origin configuration, member-change hooks, rotating terms, integrity checks, migration notes, and an example runtime configuration.Reviewers may want to focus on the boundary behavior:
swap_memberpreserves member count atomically,set_membersrejects duplicate input instead of silently deduplicating, and rotating collectives keep their previous membership if the runtime-supplied rotation cannot satisfy the configured minimum size.Behavioral Impact
No live runtime behavior changes in this PR. The pallet is added to the codebase but is not wired into the Subtensor runtime until the governance wiring PR.
Migration / Spec Version
The pallet defines storage, but this PR does not add it to the runtime. No live storage migration or spec-version bump is required here.
Testing
Suggested local verification:
cargo test -p pallet-multi-collective