Senate
The Senate is the Bittensor governance body responsible for approving or disapproving proposals made by the Triumvirate. It is the review and voting side of Bittensor’s bicameral governance structure (Glossary: Senate, Governance Overview).
The term names the collective review body. It is different from senator, which names an individual delegate role inside that body (Senate).
Governance Role
The Senate sits after the Triumvirate in the proposal path. The Triumvirate creates proposals, and the Senate reviews those proposals by voting to approve or disapprove them (Glossary: Triumvirate, Senate).
This gives the term a narrow role boundary. Senate names the review side of governance, while Triumvirate names the proposal-origin side (Glossary: Bicameral Legislature).
Voting Mechanism
Senate voting is a governance review action. Senators cast approval or disapproval votes on Triumvirate proposals, and the vote result determines whether the proposal clears the Senate review step (Senate).
That makes Senate voting different from public proposal visibility. Proposals can be inspected, but the authority to approve or disapprove belongs to the senator role described in the Senate documentation (Senate).
Governance Position
The Senate is one side of Bittensor’s bicameral governance structure. Bicameral legislature names the two-body arrangement, Triumvirate names the proposal-origin side, and Senate names the approval-side review body (Glossary: Bicameral Legislature, Governance Overview).
In that structure, a proposal is the item under review. A proposal hash is the identifier for that item. The Senate is the body that records approval or disapproval of the item during review (Glossary: Proposal Hash).
This is why Senate language works best after the proposal-origin context is clear. It identifies the review side of the path, not the whole governance system (Governance Overview).
Proposal Records
Proposal records and proposal hashes make Senate review traceable without changing the Senate’s role. A visible proposal, a Senate-approved proposal, and a completed governance change are separate parts of the governance path (Governance Overview, Glossary: Proposal Hash).
This status boundary keeps Senate approval in context. Senate review is an important gate, while proposal status and later application require the surrounding governance record.
Representation Boundary
Senators are delegates seated in the Senate. The Senate is the collective body; a senator is one voting member inside that body (Glossary: Senate, Senate).
That distinction keeps body language and member language separate. The Senate names the review body’s aggregate role, while senator names an individual delegate who can cast a vote.
Security Role
Senate approval matters because governance replaced direct sudo-style privileged authority with a proposal review path. Sudo names the older privileged-authority concept; Senate names the approval body in the governance process (Governance Overview: security, Glossary: Sudo).
That makes the Senate a review safeguard, not a privileged key holder. Privileged authority belongs to the governance path, not to an exposed administrative key in this article’s scope.
Network Scope
Bittensor documentation separates mainnet, testnet, and localnet environments (Bittensor Networks, Introduction to Bittensor). Senate examples need that environment attached because local tests, testnet activity, and mainnet governance have different scope.
A local example can illustrate mechanics. A testnet example can show shared non-production behavior. Mainnet Senate activity is the production governance-review context.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Senate, that sequence changes how an example should be read, because the surrounding network state differs at each stage.
In localnet, senate can be exercised in an isolated development environment, where the surrounding chain state reflects local configuration rather than production history.
On testnet, senate can be observed in a shared, non-production network whose state is kept separate from mainnet.
On mainnet, senate applies on the live, production Bittensor network, where the surrounding state is real and persistent.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A senate example from one environment should not be read as representing another environment.
Reader Boundary
Senate should be read as governance-body vocabulary. The term points to proposal review and voting inside the bicameral governance structure (Glossary: Senate, Governance Overview).
When the focus is proposal origin, Triumvirate is more precise. When the focus is an individual delegate, senator is more precise. When the focus is the two-body structure, bicameral legislature is more precise.
Delegated Stake Extends Senate Representation
The Senate page describes senators as delegates who control a significant portion of total network stake. That stake weight is not limited to what each senator holds directly. Network members who delegate stake to a seated senator are represented through the delegate they chose.
Official wording ties holder opinion to delegate choice rather than to a separate Senate ballot for every account. A holder can make their governance preference known by delegating with an organization whose Senate positions align with their interests (Senate).
This extends the Senate beyond its seated members without changing who casts votes. Individual senators still approve or disapprove proposals, while delegated stake connects broader network participation to those seated delegates.
References: Senate, Glossary: Delegation
Stake Threshold Governs Senate Membership
Senate participation is not automatic for every registered participant. The Senate requirements page states that a coldkey must register on a subnet as a hotkey-coldkey pair, hold more than two percent of the network’s total stake through self-stake or delegation, and elect to participate before that pair can vote on Triumvirate proposals.
The Glossary: Senate adds that the body is formed from the top delegate hotkeys. When all twelve Senate seats are filled, a new eligible delegate replaces the lowest-stake seated member rather than adding a thirteenth seat (Senate).
Those rules connect Senate vocabulary to documented weight and capacity limits. The term names a review body whose seated membership reflects stake ranking and an opt-in choice, not merely public access to proposal records.
References: Senate, Glossary: Senate
Majority Is Calculated From Seated Senators
Senate approval depends on how many senators are actually seated, not on the body’s maximum size. The Governance Overview states that a proposal needs more than half of seated senator approvals before it can move toward execution, and that twelve seats may exist without all twelve being occupied at once.
The same page illustrates the arithmetic with a smaller seated set. When only three senators hold seats, the approval threshold becomes two approvals even though the Senate can grow larger over time (Governance Overview).
That seated-count rule keeps Senate review language precise. A proposal hash can accumulate visible votes, but clearing the Senate gate means reaching a majority among delegates currently seated in the body, not among an assumed full roster of twelve.
References: Governance Overview, Glossary: Proposal