Skip to content

Latest commit

 

History

History
189 lines (120 loc) · 9.76 KB

File metadata and controls

189 lines (120 loc) · 9.76 KB
hsp 1
title House of Stake Proposal Process
description The purpose and guidelines for House of Stake proposals
author Lane Rettig <lane@near.foundation>
discussions-to https://gov.near.org/t/proposal-hsp-001/41682
status Living
type Meta
category Governance
created 2025-10-10

Abstract

HSP stands for House of Stake Proposal. An HSP is a design document providing information to the NEAR House of Stake community, or describing a change to House of Stake governance processes or environment. This document (HSP-001) describes what an HSP is, the HSP types, the proposal workflow, and the template that all HSPs must follow.

Scope

This document lays out the governance of the https://github.com/houseofstake/proposals/ repository, which contains a canonical set of House of Stake proposals and policy documents. Its scope does not include other aspects of House of Stake governance.

What is an HSP?

An HSP is the primary mechanism for proposing decisions, collecting community input, and documenting governance choices made by the House of Stake. HSPs provide a transparent, versioned record of all proposals and their outcomes.

For House of Stake participants, HSPs are a convenient way to track governance activity and understand what decisions have been made. HSP authors are responsible for building consensus within the community and documenting dissenting opinions.

HSP Types

There are three types of HSP:

Decision - A binding proposal that, if approved, results in specific action or resource allocation. Decision proposals include treasury allocations, economic parameter changes, technical governance decisions, and operational initiatives. Decision proposals require formal voting and quorum.

Sensing - A non-binding proposal used to gauge community sentiment on a topic before committing resources to a full Decision proposal. Sensing proposals help authors understand community preferences and refine ideas. They do not require the same rigor as Decision proposals.

Meta - A proposal that describes a process or proposes changes to governance processes themselves. Meta proposals include changes to the HSP process, voting procedures, governance structure, constitutional amendments, and House of Stake operational guidelines. This document (HSP-001) is a Meta proposal.

HSP Workflow

Status Definitions

Every HSP has a status that indicates where it is in its lifecycle:

Draft - The initial state when an HSP is first submitted and merged into the HSP repository. The author is actively developing the proposal and incorporating feedback.

Review - The author marks the HSP as ready for formal community review. The proposal should be complete and well-formed at this stage.

Last Call - Final review period before voting. This status lasts 14 days by default. The community has a final opportunity to provide feedback. Substantive changes during Last Call move the proposal back to Review.

Voting - For Decision proposals only. The proposal is being voted on by veNEAR holders. This period typically lasts 7 days.

Final - The proposal has been approved and implemented (for Decision proposals) or has reached its final form (for Meta and Sensing proposals). Final proposals should only be updated to correct errors or add non-normative clarifications.

Rejected - The proposal was voted on and did not pass (Decision proposals) or the community consensus was negative (Sensing proposals).

Withdrawn - The author(s) have withdrawn the proposal. This state is final and the HSP number cannot be reused.

Stagnant - Any HSP in Draft or Review that has been inactive for 6 months or more. Authors or editors can resurrect a Stagnant proposal by moving it back to Draft.

Living - A special status for HSPs that are continually updated and never reach finality. HSP-001 is a Living proposal.

Process Flow

  1. Idea - Before drafting, authors should discuss their idea on the governance forum to gauge interest and refine the concept.

  2. Draft Submission - Author writes the proposal following the HSP template and submits it as a PR to the https://github.com/houseofstake/proposals repository. Once properly formatted, it receives an HSP number and is merged as Draft.

  3. Community Discussion - The Draft HSP is discussed on the governance forum. Authors incorporate feedback and iterate on the proposal.

  4. Review - When the author believes the proposal is ready, they move it to Review status. This signals that the proposal is complete and ready for formal evaluation.

  5. Last Call - An editor moves the proposal to Last Call, setting a 14-day deadline. This is the final opportunity for community feedback before voting (Decision) or finalization (Sensing/Meta).

  6. Voting (Decision only) - Decision proposals proceed to an on-chain vote by veNEAR holders. Voting period is typically 7 days. The proposal must meet quorum and approval thresholds defined in the House of Stake governance documents.

  7. Final/Rejected - Based on vote results (Decision) or community consensus (Sensing/Meta), the proposal becomes Final or Rejected.

HSP Template

All HSPs must use the standard template with the following structure:

Required Frontmatter

---
hsp: <number>
title: <max 44 characters>
description: <max 140 characters>
author: <name(s) and contact info>
discussions-to: <forum URL>
status: <Draft|Review|Last Call|Voting|Final|Rejected|Withdrawn|Stagnant|Living>
type: <Decision|Sensing|Meta>
category: <category name>
created: <YYYY-MM-DD>
requires: <HSP number(s)> (optional)
---

Required Sections

Abstract - 2-3 sentences summarizing what the proposal does.

Context & Alignment - What does the reader need to know? What previous proposals or community discussions relate to this? What prior art is relevant? Does this proposal rely on or modify existing policies, practices, or budgets? Which principles of the HoS Constitution or NEAR values does this proposal uphold?

Situation - What problem does this address? What happens if we don't act?

Mission - What are the objectives and expected outcomes?

Approach - What strategy will be used? What are risks and limitations?

Technical Specification - Detailed implementation details. What exactly changes?

Backwards Compatibility - Does this introduce incompatibilities? How will they be addressed?

Milestones - Key milestones, timeline, and deliverables at team milestone.

Budget & Resources - Requested resources and funding (if applicable), including source of funding (treasury, inflation, other).

Team & Accountability - Who is responsible and accountable? How will progress be reported, and how often?

Security Considerations - Security implications must be discussed for all proposals.

Conflict of Interest - The author(s) must state that they've read and agree with the House of Stake Conflict of Interest policy, and must state any conflicts of interest, if relevant.

Copyright - Standard CC0 copyright waiver. Note that proposals that don't include this waiver won't be considered.

Optional Sections

Proposals may omit sections that are not applicable, but should justify their omission. Additional sections may be added if they improve clarity.

Proposal Categories

To help organize and filter proposals, authors should specify one of the following categories:

  • Economic Governance - Treasury, inflation, fees, token economics
  • Technical Governance - Protocol changes, smart contracts, infrastructure
  • Legitimacy & Engagement - Policies, procedures, community initiatives
  • Grants & Funding - Grant programs, funding allocations
  • Operations - House of Stake operational matters
  • Other - Proposals that don't fit above categories

What Makes a Good HSP?

A successful HSP should:

  • Solve a clear problem - Articulate the issue and why it matters
  • Provide complete specification - Include enough detail for implementation
  • Show net improvement - Demonstrate that benefits outweigh costs and risks
  • Build consensus - Engage with community feedback and address concerns
  • Be well-scoped - Focus on a single proposal or tightly related set of changes
  • Consider alternatives - Explain why this approach vs. others
  • Address security - Discuss security implications thoroughly

HSP Editors

Editors are responsible for:

  • Assigning HSP numbers
  • Ensuring proposals follow the template
  • Merging properly formatted proposals
  • Updating proposal statuses
  • Maintaining the HSP repository

The initial editors will be designated by the House of Stake. Over time, the community may elect or appoint additional editors through the governance process.

Shepherding Your HSP

As an HSP author, your responsibilities include:

  1. Vetting the idea - Discuss on forums before writing formal proposal
  2. Writing clearly - Follow the template and write for broad audience
  3. Building consensus - Engage constructively with feedback
  4. Iterating - Refine based on community input
  5. Coordinating implementation - For Decision proposals, work with implementers
  6. Documenting dissent - Note significant opposing viewpoints

Style Guidelines

  • Format - Use markdown formatting
  • Titles - Max 44 characters, descriptive, no HSP number in title
  • Descriptions - Max 140 characters, complete sentence
  • Dates - ISO 8601 format (YYYY-MM-DD)
  • Linking - Link to other HSPs as HSP-###
  • Language - Clear, accessible, professional but not overly formal

Amendments to HSP-001

This document (HSP-001) has Living status and may be amended through the standard HSP process. Proposed changes should be discussed on the governance forum before being incorporated.

Copyright

Copyright and related rights waived via CC0.