Governance and Proposal Flow

The governance framework of HashStrategy is designed to balance inclusive participation, secure capital deployment, and efficient execution. Given the protocol’s mission to accumulate Bitcoin through scalable mining operations, proposals frequently involve meaningful capital allocation and operational risk. The governance process ensures that each proposal is thoughtfully evaluated, transparently debated, and executed under the oversight of a community-elected validator council.

Stage 1: Governance Forum & Request for Comments (RFC)

Any staked $HS token holder may initiate a proposal by posting a draft HashStrategy Improvement Proposal (HIP) to the official governance forum. This begins the Request for Comments (RFC) phase, which must remain open for a minimum of seven (7) days.

During the RFC period, the community is encouraged to:

• Review the proposal in detail

• Raise risks, implementation concerns, or edge cases

• Recommend revisions to improve clarity or execution

To proceed to the next stage, a proposal must receive:

• At least three (3) unique comments from community members

• At least one (1) reply or acknowledgment from a validator

Stage 2: Temperature Check (Non-Binding Community Vote)

Once the RFC concludes, a temperature check may be initiated to gauge community sentiment. This non-binding, off-chain vote is conducted through Realms or a compatible governance interface.

Voting Parameters:

• Eligibility: Staked $HS token holders

• Duration: 3 to 5 days

• Quorum: At least 2% of total staked $HS

• Approval Threshold: Simple majority (>50%)

If the temperature check passes, the proposal advances to a formal on-chain validator vote. If it fails, the proposer may revise and resubmit after a 7-day cooldown period.

Stage 3: Validator Vote (Binding Decision)

Proposals that pass the temperature check enter a binding vote conducted on-chain. Validators are assigned voting power based on the amount of $HS delegated to them, subject to a governance-imposed cap to ensure decentralization.

Voting Parameters:

• Eligibility: Validators (Council Token holders)

• Duration: 5 to 7 days

• Quorum: At least two-thirds (2/3) of total validators must participate

• Approval Threshold: At least two-thirds (2/3) of the voting weight from participating validators must vote “Yes”

• Voting Weight Cap: No single validator may exercise more than 40% of the total voting weight in any given vote

This dual-layer threshold ensures both representative participation (by count) and economic alignment (by weight), while the weight cap protects the protocol from governance centralization.

Stage 4: Execution Timelock

Once approved, proposals enter a seventy-two (72) hour execution timelock. This delay serves several purposes:

• Allows the community to review the final version

• Creates a buffer for emergency veto actions if necessary

• Provides time for operational coordination by the operations team

After the timelock period expires, the proposal is executed either via on-chain instruction or through an authorized multisig, depending on its nature.

Veto Option

To preserve decentralization and ensure token holder oversight, any proposal approved by validators remains subject to a community veto during the execution timelock. The veto is a direct vote by staked $HS token holders and is not mediated through validator delegation. It allows the broader community to reject proposals they believe are misaligned, malicious, or inconsistent with the protocol’s long-term vision.

Trigger Conditions:

• Must be initiated within 72 hours of Validator approval

• Requires participation from at least 10% of total staked $HS

• Must achieve a simple majority “No” vote

If successful, the veto nullifies the proposal and prevents execution.