# How to limit altering proposals after they are posted?

**URL:** <https://forum.polkadot.network/t/how-to-limit-altering-proposals-after-they-are-posted/11831>\
**Category:** Governance\
**Created:** [February 21, 2025, 11:42am UTC](https://forum.polkadot.network/t/how-to-limit-altering-proposals-after-they-are-posted/11831 "2025-02-21T11:42:42Z")\
**Posts on this page:** 3\
**Page:** 2

<div class="post-metadata">

**Author:** ![olanod](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/olanod/32/804_2.png) [@olanod](https://forum.polkadot.network/u/olanod)\
**Post date:** [April 11, 2025, 6:38am UTC](https://forum.polkadot.network/t/how-to-limit-altering-proposals-after-they-are-posted/11831/22 "2025-04-11T06:38:24Z")

</div>

Happy to work on **B** (and **A**?) as it’s already in our roadmap 🙂

For context I’m working on a runtime that runs ink-like programs([VOS](https://forum.polkadot.network/t/virtual-operating-system-for-jam-program-with-wink-and-zink/11973)) in a server environment(and the browser, embedded hardware and maybe JAM?), the runtime exposes a simple HTTP/WS RPC API used to call functions of any of the installed WASI(wink) programs.  
The reason A and B could tackled simultaneously is that our governance API will be another wink program that simply interacts with a virtual filesystem(hidden away by the wink macro), I plan to use matrix as a decentralized eventually-consistent encrypted storage exposed to wink programs as a filesystem(allows DAOs and their members to share private “files”/state), git can be another(even easier to implement) virtual filesystem.

---

<div class="post-metadata">

**Author:** ![aaron2048](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/aaron2048/32/3406_2.png) [@aaron2048](https://forum.polkadot.network/u/aaron2048)\
**Post date:** [April 14, 2025, 1:44pm UTC](https://forum.polkadot.network/t/how-to-limit-altering-proposals-after-they-are-posted/11831/23 "2025-04-14T13:44:02Z")

</div>

Hey all - this is something that came up early on for us on the Moonbeam side. We went with the Github approach and the Foundation hosts a specific [github repository](https://github.com/moonbeam-foundation/treasury/tree/main) for it.

However, it’s a bit of a pain to manage. As has been pointed out above, the UX is not wonderful.

Separately, we’re looking at integrating the [Storage Hub](https://github.com/Moonsong-Labs/storage-hub) project into Moonbeam in order to provide immutable, verifiable storage.

We’ll be focused primarily on AI use cases but we’re also interested broadly in problems of this nature. APIs will be available which should make it relatively straightforward to integrate other systems to try and streamline UX.

However, we’re just getting started so it will probably be toward the end of 2025 when storage features are live Moonbeam so perhaps this particular use case can’t wait until then. Regardless, I thought I would mention it all the same as Moonbeam’s storage capabilities could serve as a general purpose solution for the broader Polkadot ecosystem…

---

<div class="post-metadata">

**Author:** ![nino\_apillon](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/nino_apillon/32/9767_2.png) [@nino\_apillon](https://forum.polkadot.network/u/nino_apillon)\
**Post date:** [May 2, 2025, 12:27pm UTC](https://forum.polkadot.network/t/how-to-limit-altering-proposals-after-they-are-posted/11831/24 "2025-05-02T12:27:37Z")

</div>

We have opened a topic that addresses Opengov feedback and the idea directly tackles the question of how proposal documents are filed.

We would love to hear your feedback:

> [@UX Bounty - Enhancing Referenda Feedback loop: Introducing Section-Based Voting and Feedback Mechanism](https://forum.polkadot.network/t/ux-bounty-enhancing-referenda-feedback-loop-introducing-section-based-voting-and-feedback-mechanism/12790):
>
> Dear Polkadot Community, The UX Bounty proposes an enhancement to our current referendum voting system to foster deeper engagement and more nuanced feedback. Pain Points: Gdocs Currently, referenda on OpenGov lack a standardized format for proposal documents. Many proposals are shared via Google Docs, which often do not include version history, change tracking and/or archival value after the vote concludes. This issue has already been widely acknowledged by the ecosystem and is being activel…

[Previous page](https://forum.polkadot.network/t/how-to-limit-altering-proposals-after-they-are-posted/11831.md?page=1)
