# MINA Foundation Governance Recommendation Report

**URL:** <https://forums.minaprotocol.com/t/mina-foundation-governance-recommendation-report/7027>\
**Category:** Governance\
**Created:** [December 10, 2025, 10:18am UTC](https://forums.minaprotocol.com/t/mina-foundation-governance-recommendation-report/7027 "2025-12-10T10:18:48Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![maht0rz](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/maht0rz/32/1967_2.png) [@maht0rz](https://forums.minaprotocol.com/u/maht0rz)\
**Post date:** [December 10, 2025, 10:49am UTC](https://forums.minaprotocol.com/t/mina-foundation-governance-recommendation-report/7027/2 "2025-12-10T10:49:29Z")

</div>

Thank you for the thoughtful review and for helping pressure‑test our governance design - sticking to our initial goal of designing a system that is safe, clear, and permissionless from the start, with room to iterate based on real participation and outcomes. Here’s a few thoughts on how we plan to accommodate the recommendations moving forward.

### Participation and Approval

We’re adopting an adaptive approach with a (potentially) positive turnout bias and a modest adjustment for larger asks. Bigger proposals should earn broader support; routine ones remain passable without risking deadlock.

### Voter Eligibility

Voting will use snapshot ledger balances for all token holders. Given Mina’s lack of an unbonding period, stake‑only gating doesn’t create the intended “skin‑in‑the‑game” and is difficult to enforce in a permissionless setting, or without major protocol level changes. Safeguards instead come from adaptive thresholds, transparency and community scrutiny.

### Bonding

A simple bond (target 10%) serves as spam protection and is refunded on acceptance. This keeps the process open and avoids subjective delivery adjudication. We expect retro‑style proposals to play a meaningful role, which naturally mitigates non‑delivery risk. Reason for this decision is both conceptual, and technical feasibility in comparison to milestone based proposals and delivery tracking.

### Lifecycle and Timing

Governance stages are aligned to Mina epochs, with longer windows to ensure reliable snapshots and avoid congestion‑driven timing risks. Identity checks, where applicable, occur after approval and before execution in cooldown. Lot of this stems from how the zkApp protocol works, especially when it comes to snapshoting the staking ledger deterministically.

### Content and Templates

Proposals will be based on templates and be posted via GitHub Gist or the Mina Research Forum (we’re still considering which option to use), anchored by an on‑chain content hash. This keeps the experience simple and auditable, with room to expand into more decentralized storage and automation later. Main point to mention here is that the treasury itself is a smart contract, and does not have any tangible reach or access to the contents of the proposal, apart from the content hash.

### Disbursement Cadence

We’re starting without fixed funding rounds. Proposals of different sizes move continuously through the lifecycle and are governed by the adaptive participation/approval rules. If participation and safety data suggest pacing or caps would help, we’ll bring those in with clear guidance. More importantly we plan to roll out the treasury in chunks, increasing the amount of funds available over time, as trust in the treasury implementation grows (pending 3rd party audits).

### Proposal Execution

The report suggests milestone-based, on‑delivery payments to ensure positive proposal outcomes. We’re choosing a simpler path: disburse funds upon approval, with no milestone gating or delivery tracking. This preserves a permissionless, low‑friction process, avoids subjective moderation or disputes, and keeps operational overhead low. Accountability will come from clear proposal standards, public transparency, community scrutiny, identity checks where applicable before execution. In practice, we expect retro funding to play a meaningful role, aligning incentives without adding protocol‑level adjudication.

### Safety and Escalation

A zkApp‑based multisig provides a supermajority veto (e.g., 3/5 or 5/7) with a clear conflict‑of‑interest policy: members abstain from token voting while serving. Identity checks (where applicable) are verified by the multisig before disbursement, at least until the break-glass is in place.

---

_[View the full topic](https://forums.minaprotocol.com/t/mina-foundation-governance-recommendation-report/7027)._