Proposal
A proposal is the governance item that the Triumvirate puts forward for Senate review. It is the object being considered in Bittensor governance, separate from the bodies that create, review, or execute governance actions (Glossary: Proposal, Governance Overview).
The term names the item in the governance path. It does not by itself say whether the item has been approved, rejected, finalized, or applied.
Governance Role
Bittensor governance separates proposal creation from proposal review. The Triumvirate originates proposals, while the Senate approves or rejects them before privileged changes can proceed (Governance Overview, Glossary: Triumvirate).
That makes a proposal the item moving between governance roles. The Triumvirate is the origin body; the Senate is the review body; the proposal is the plan or action placed in front of that review process.
This is the main governance boundary. Bicameral legislature names the two-body structure, Triumvirate names the origin body, Senate names the review body, and proposal names the item being reviewed (Glossary: Bicameral Legislature, Senate).
The distinction also keeps proposal language separate from older sudo vocabulary. Sudo refers to privileged administrative authority, while a proposal belongs to the governance process that replaced single-key administration with proposal review (Glossary: Sudo, Governance Overview).
This makes proposal vocabulary useful for privileged-change review, not ordinary subnet activity. Subnet work and scoring belong to incentive-mechanism context, while proposals belong to governance context (Understanding Subnets).
Bicameral Context
Bittensor governance uses a bicameral structure for proposal handling. The Triumvirate is the proposal-origin side, while the Senate is the review and approval side (Glossary: Bicameral Legislature, Senate).
That structure gives the proposal a path through governance. It starts as an item created for review, then moves through Senate voting and later governance stages when the process continues.
Proposal Hash
A proposal hash is the identifier used to reference a proposal during voting (Glossary: Proposal Hash).
The distinction matters because the hash is not the same as the governance item itself. The proposal is the item under review, while the hash is the reference used to point to that item in governance records and voting context.
A hash also does not carry the proposal’s status by itself. The same proposal can be referenced during review, after approval, or after rejection, so the governance context around the hash still matters (Glossary: Proposal, Senate).
The pair is straightforward: proposal names the governance item, and proposal hash names a compact reference to that item.
Review Flow
The governance overview presents proposals as part of a bicameral process involving the Triumvirate and Senate (Governance Overview). A proposal can be created, reviewed by senators, voted on, and then finalized through the governance process if it has the required support.
The useful boundary is the stage being discussed. A submitted proposal, an approved proposal, and an applied change are related states, but they do not mean the same thing. Proposal wording should therefore stay attached to the governance stage that the surrounding context shows.
This stage boundary is especially important in summaries. Calling something a proposal explains what item is under governance review; the governance record explains what happened to it.
The same stage boundary keeps approval language precise. Senate approval is a review result, while finalization or application belongs to later governance context (Governance Overview).
Relationship to Subtensor
Subtensor is Bittensor’s layer-one blockchain and system of record (Glossary: Subtensor). Proposals belong near Subtensor vocabulary because accepted governance actions can affect privileged Subtensor behavior through the governance process (Governance Overview).
That relationship does not make every Subtensor change a proposal. Proposal language should be used when the focus is the governance item submitted for Senate review.
The relationship also does not make a proposal a chain layer. Subtensor is the system of record, while a proposal is a governance item that may request a privileged change affecting that system (Glossary: Subtensor, Glossary: Proposal).
Network Scope
Bittensor documentation separates localnet, testnet, and mainnet environments (Bittensor Networks, Introduction to Bittensor).
Proposal examples should keep that environment boundary attached. A localnet or testnet example can illustrate governance mechanics, but it is not evidence of a mainnet governance outcome or production parameter change.
The concept is stable across environments, while the proposal status and impact belong to the environment where the governance record exists.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For proposal vocabulary, that sequence changes how readers should interpret governance proposals, Senate review, and privileged-change examples.
In localnet, proposal examples can be exercised in an isolated environment. Local governance configuration and proposal lifecycles reflect local chain state rather than production governance history.
On testnet, proposals can be observed in a shared, non-production network. Testnet Senate review and proposal outcomes are separate from mainnet governance state (Governance Overview).
On mainnet, a proposal is part of the live governance path for privileged network changes on the production Bittensor network (Glossary: Proposal).
The Bittensor Networks reference separates mainnet, testnet, and localnet. A proposal example from one environment should not be read as representing production governance outcomes in another environment.
Reader Boundary
A proposal is the governance item submitted into review (Glossary: Proposal, Governance Overview).
When the focus is the voting body, Senate is the more precise term. When the focus is the origin body, Triumvirate is more precise. When the focus is the identifier used during voting, proposal hash is more precise.
When the focus is a completed network effect, proposal alone is also too broad. The governance record must show the relevant review state before a proposal should be described as approved, rejected, or applied (Governance Overview, Senate).
Senators Cast Approval or Disapproval Votes
The Senate voting documentation describes senators choosing approval or disapproval after entering a proposal hash obtained from the proposals overview. Proposal status reading should therefore name the vote type senators record, not only that a proposal exists.
Public viewing and senator voting remain separate paths in that reference. Anyone can inspect proposals currently before the Senate, while senator votes decide whether the item meets the approval threshold described in governance material.
Governance Examples Can Request New Subnets
The Governance Overview example shows a Triumvirate member creating a proposal whose calldata calls a privileged subnet-creation extrinsic. Proposal vocabulary therefore covers governance items that can request network-level changes such as adding a subnet, not only hyperparameter edits.
Readers should pair that example with Senate review context. The proposal names the reviewed item; the calldata names the privileged action senators are deciding whether to authorize.
Compromise Requires Triumvirate and Senate Control
Governance security material states that approving privileged actions under the governance protocol
requires compromising a Triumvirate member and controlling a Senate majority, rather than a single
sudo key alone (Governance Overview).
That threat model keeps proposal reading tied to bicameral review. A proposal is the reviewed container; Senate majority and Triumvirate close remain separate conditions before execution (Glossary: Bicameral Legislature).