This is a discussion thread for House of Stake Proposal (HSP) 001, which is a meta proposal laying out some details about the proposal process including proposal types, workflow, and the template.
You can find the draft proposal in this pull request: Create HSP-001.md by lrettig · Pull Request #2 · houseofstake/proposals · GitHub
Overall I’m confused by the process for submitting proposals:
I get github is good for record keeping, but then why do separate on website vs just fetching from github? approving/not approving doesn’t get recorded on github. which one is source of truth, what if something changed between github and proposal on the website?
What would make sense to me:
It will take a bit of time to implement, but meanwhile - gov forum + proposal on the website makes sense to me. What is the purpose of github here?
It’s the canonical document repository. I’m basing this on the EIPs repository for Ethereum, which I think has done a great job of being a structured, searchable, indexable, canonical repository, built on markdown and github.
I share your vision for doing everything on chain and we should work with Agora to make this happen—we’ve already begun this conversation—but I think it’ll be a long time until we have something that works as well as simple markdown + github. The idea is to do the simplest possible thing for now.
I did my best to lay out the full process here—note that this is a draft and is still subject to change, but feedback is very welcome: House of Stake: Proposal Process - HackMD. We’ll get this cleaned up and finalized and installed on Proposal & Voting Process | House of Stake as the canonical description of the process.
I admit that there’s some redundancy among the three platforms, but I think each serves a different purpose. Here’s how I see it:
In the future, we should look towards merging all three of these.
Something else to consider: we can get quite far with automation. We could have a button here on the forum that moves a draft HSP to a Github PR automatically, we could have a shade agent that updates the HSP status on Github after a vote, etc. But I think we should run through the process manually a few times before we try to automate it.
Lane
I completely agree that this step is unclear.
Right now, “sufficient support” is based only on subjective opinion.
In addition, there is no media support or communication from HoS.
Most people in the ecosystem don’t even know that proposals exist or that they are expected to comment on them.
This is exactly why we need a proper media and communication framework, as suggested in this proposal:
https://gov.near.org/t/hsp-005-house-of-stake-social-media-governance-operations-charter/41692
At the same time, censorship by NF contractors (Community Squad) in chats and even on this forum must be removed.
In my view, the forum should simply serve as a temperature check:
• share the idea
• collect feedback
• allow open discussion
Whether someone comments or not should be their choice —
but this step must not become a blocker or an unofficial gate for the Screening Committee to decide what moves forward.
In the current process, every author manually uploads their proposal,
and there is no agreed template or format.
Reviewers use the mandate criteria — in theory, that makes sense.
However, I have a serious concern:
These mandates can be interpreted flexibly to block proposals that NF or certain individuals do not like.
How do we prevent this?
One possible solution:
• Implement an AI agent that evaluates proposals objectively against the mandate.
• The AI outputs a transparent pass/fail result with clear reasoning.
• Reviewers cannot “bend” the mandate based on personal or political preference.
This is especially important because some proposals directly affect members of the Screening Committee themselves.
What guarantees that they will not interpret the mandate in their own favor and block proposals that challenge their position.
They are doing it on github, because they don’t have onchain system in the first place.
Please see my post about danger of github governance - Unwritten Rules of the Game - by Illia Polosukhin
This process continues the github governance instead of actually leaning into onchain tools that we have been building.
We have already github process for technical discussions, analogue for EIPs - called NEPs. I don’t see a need for another alternative process here.
These are all stored onchain, including a canonical number. It’s searchable by all the tools that can read onchain state. Explorers and wallets can integrate easily into them and make it accessible and visible for everyone.
There is already canonical number for proposals, for example This is a test proposal, please ignore
Which is also why actually putting “HSP-003” here on the forum doesn’t make sense, unless you create a draft first in the gov platform.
Sure, but unclear to me why. More complex process with more gatekeepers who are not elected create for a brittle result.
The thing that make sense to be right now:
That said 1 → 2 should be defined a lot better and ideally all just goes to gov platform and add comments there.
And 3 can be replaced by having a good visualization of the proposals and making sure search and AI can access it.
I also think it would be best to get a list of all the on chain governance tooling available to us as of right now if that’s what is being recommended instead of the github.
That’s a great starting point, and that would be very helpful. If I can do the things I can currently do with Github instead using NEAR onchain tooling, all the better. And if not, then we can start a specific list of user stories and figure out what needs to be built. For me, right now, this includes things like having an audit log/commit history for updates, having commit hashes so I know the latest canonical version, being able to easily update proposals in markdown format, change statuses, etc. – in addition to basic functionality like universally viewable URLs, rendering of markdown, search, etc. I can come up with a more comprehensive list.
Discourse (i.e., this forum) supports a lot of these things, but there are some key missing things. It doesn’t have the accountability or decentralization that git/github have: commit hashes that refer to a specific version of a document, and that break if force pushes occur, pull requests and reviews and approvals for changes, the ability to pull a copy of a repository locally, etc.
The governance frontend currently allows you to post a proposal, but there’s no editing, history, tracking changes, linking multiple versions of a proposal or related proposals, etc. For effective governance we need those things too. Github is still the best tool for that, for now.
Obviously I agree here. Maybe we can repurpose the screening committee to also manage the HSP repository/be the “HSP editors.”
I’ll give it some more thought. Maybe we can make the github step optional, or fully automate it as you suggest.
L
Good that I discovered that thread.
The text of proposals should be on-chain and it’s the source of truth. It’s supported right now, except for 16Kb log limitation that is in the process of being removed.
The on-chain proposals should NOT be editable. That’s why there shouldn’t be versions of the proposals. There is no point to edit them, because once they are approved or rejected the voting starts and they should not be edited. Basically, don’t submit the proposal until the text is finalized.
We can build an automation to pull all proposal text into github automatically (for search). We can organize them into folders: pending, in-progress, rejected by screening, voted YES, voted NO (and other options).
I like the idea of using simple AI wrapper to determine whether proposal fits the template. It’s non binding, but a helping tool for authors to address feedback automatically before posting it on forum for discussions.
Adapting the flow from the HoS chat:
memo: Option<String> on every transaction happening with the contracts (including voting). So rationale can be given on-chain (and maybe mimicked on forum).memo), since the vote can be changed, the on forum discussion can be important.Tools to build (non-blocking):
memo. Note, the contract changes are not required, just indexing and UI.Open questions:
I don’t see a need to involve GitHub.
However, assuming it’s required, are you expecting pull requests to be merged before participants create on-chain proposals? If so, will the screening committee actually enforce that by rejecting any proposals not found in the canonical repository?
If proposals are first submitted on-chain, is a better search feature the only reason to automatically cross-post to GitHub?
I listed a few more missing features above. From my perspective, these are the minimum requirements, which Github fulfills today. Of course I’m open to other solutions that fulfill these requirements:
git blame.Those are the things that come to mind at the moment. Will give it some more thought.
L