Mina Treasury Governance Review
by Tanisha Katara, Aragon
01 OBJECTIVE
Mina Foundation is working towards launching a community-owned capital allocation system that can reinvigorate ecosystem growth and signal long-term economic confidence.
The objective of this report is to provide a pragmatic and future-resilient treasury governance strategy that is safe today, resilient tomorrow and owned by all in the future. This work is grounded in real tokenholder distribution data, attack-surface modelling, and alignment with the Foundation’s objectives.
Our analysis acknowledges that the RFC parameters were exploratory and intended for further refinement. For instance, a 50% static quorum requirement could result in governance deadlock, requiring a coalition of the top ~179 wallets to pass any proposal. We propose the following recommendations for each of the parameters and progressively decentralising as the system proves its resilience.
Our goal is to enable Mina fund ecosystem growth while maintaining the governance and security standards expected of a leading L1 protocol.
02 HOLISTIC REVIEW AND PRIORITY PLANNING
This matrix outlines all key parameters across Governance, Treasury, Security, and Regulatory domains, mapped to their implementation priority. It shows which elements are essential for Phase 1 launch, which are planned for Phase 2, and which require long-term evolution, giving a clear view of what the project must focus on immediately versus later stages.
03 RECOMMENDATIONS: GOVERNANCE PARAMETERS
Important for Phase 1 Launch
3.1 Quorum Setting
A hard 50% quorum is likely too low or, in some cases, too high for routine treasury proposals unless Mina Foundation can reliably mobilise the largest custodial/whale wallets. Many proposals will likely fail on quorum, not on merits.
Here is why:
Per the RFC, Quorum, i.e q = 50% of S (i.e., at least 0.5 * S of stake must cast votes for proposal to be valid), where S = total eligible supply at snapshot (sum of balance_mina).
The attacker would need 50% of the total supply (≈ 629,662,058 MINA). To reach a majority at 60% of quorum, the Attack threshold (m = 60% of quorum) = ≈ 377,797,235 MINA (this equals 0.30 × S, i.e. 30% of total supply).
As per the high-level simulations we conducted, we derived that a few wallets can sufficiently reach a static attacker threshold. Excluding the top 2 custodial wallets, it takes the top 39 addresses to reach a 30% attacker threshold and the top 218 addresses to reach 50% quorum.
Note: These numbers are to be re-checked and re-evaluated during the simulation stage of this project.
This highlights a high degree of token concentration and indicates that even a single large custodian or staking pool could theoretically satisfy quorum or exert decisive influence over treasury votes under current parameters.
To further analyse, we modelled a realistic expected voter turnout for Mina governance using actual on-chain token distribution data and then applied conservative participation assumptions for each type of token holder.
The simulation assumed the following voter turnout distribution:
Even with these optimistic-but-realistic assumptions, the simulation showed that the hard quorum of 50% is not reliably reachable. It is reached too easily by the very large wallets, but too hard for small and medium wallets to hit in isolation.
Recommendations:
Recommendation 1: Adaptive quorum (Preferred)
Instead of fixing a single quorum and approval threshold forever (e.g. “20% turnout and 60% yes”), adaptive quorum biasing makes both depend on turnout*
The mechanism rules are simple:
-
At low turnout, you need a heavier super-majority of YES for the proposal to pass (positive bias / “super-majority approve”).
-
As turnout increases, the required YES margin gradually relaxes.
-
At 100% turnout, it collapses back to a plain 50%+1 majority.
The simple formula for a positive turnout bias adaptive quorum is as follows:
A = Aye votes (tokens)
N = Nay votes (tokens)
Ab = Abstain votes (tokens)
t = turnout = A + N + Ab (total voting tokens)
T = total issuance / circulating supply
Adding multipliers for higher treasury asks
Introduce a new variable S, where S = Proposal Amount / Total Treasury Balance (Current)
Numeric Example:
-
Turnout: r=0.4r = 0.4r=0.4 (40% of supply votes)
-
Base threshold:
Small grant, say 0.2% of treasury
b(s)=0 ⇒ still need ~61.3% YES.
Larger grant, 2% of treasury (s=2%s=2\%s=2%, Tier 2):
b(s)=0.05 ⇒ need ~66.3% YES.
Same turnout, but a larger treasury ask must clear a slightly higher YES threshold. This will be further simulated and improved in the simulation stage of this research.
Here’s the approach we would take to holistically design adaptive quorums:
Before encoding onchain rules for adaptive quorums, we would test and audit them off-chain. For test runs, we could take real-world voter turnouts from other ecosystems and map them to realistic outcomes.
Recommendation 2: Tiered quorums (If there is no bandwidth for Adaptive Quorums)
Here’s the approach we would take to holistically design tiered quorums so that we can balance out the right quorum thresholds:
3.2 Majority Threshold
Majority thresholds need to go hand-in-hand with the above-recommended quorum methodologies.
Here is why:
Any group of addresses that can collectively control ~30% of supply can effectively hit the majority threshold assuming quorum is hit. At 75% majority threshold, addresses collectively controlling 37.5% of supply can effectively hit the majority threshold.
Recommendations:
Recommendation 1: Tiered majority thresholds in Adaptive Quorums (Phase 2 launch)
When we use adaptive quorums, the majority threshold is not fixed. It *automatically changes based on turnout.
Positive Turnout Bias: At lower turnout, the AYE requirement is very high (e.g., 80% of votes must be YES). As turnout increases toward 100%, the requirement relaxes toward 50% YES (simple majority).*
We will test on 3 modes of adaptive quorums (positive bias) with multipliers for higher treasury asks on MINA’s tokenholder distribution and evaluate the best option to set adaptive quorums:
Recommendation 2: Tiered majority thresholds with tiered quorums
Here’s the approach we would take to holistically design tiered threshold levels as per tiered quorum levels:
3.3 Vote Weights / Eligibility to Vote
Who should be allowed to vote on treasury allocations is a critical question and probably one that we should start with. This matters because any voting power not backed by real economic exposure becomes a pure governance attack surface.
We first mapped the two fundamentally different voter groups in Mina governance:
We performed an extensive and high-level attack vector mapping:
Recommendation:
The initial recommendation was to launch a simple Phase 1 onchain Governance with staked token holders only. This does not eliminate all the attack vectors but significantly reduces the risk from attack vectors 1 and 3. For instance, in the Buy-Vote-Dump attack vector, an attacker must bear heavy downside. In the vote-buying marketplace, participants are less likely to lease slashable stakes. For Proxy bribe attacks, recipients now have slashable loss exposure.
However, as staked unlocking is currently not feasible on the protocol, the recommendation is to alert the break-glass mechanism and establish escalation pathways to report and action on potential attack vectors.
Adaptive Quorums, along with multipliers for higher treasury funding asks, should be prioritised to prohibit attacker gaming without skin in the game. These guardrails will allow the system to scale without exposing itself to bigger attack vectors. The escalation pathway is elaborated in section 5.3.
3.4 Bonding Mechanics
10% bond seems like a reasonable deposit to avoid spam while keeping the barrier to entry low.
Should the bond be returned or burned?
Recommendation:
- Refund bond if proposal is accepted and delivered
- Burn only for unqualified/malicious/spam proposals
From a governance perspective, if you permanently burn the bond, proposers will just increase their funding ask by the burn % to make themselves whole.
From a tokenomics perspective, this does not reduce net dilution — it just passes the cost to the treasury. Burning bonds does not guarantee token sink benefit and, in some cases, may create reflexive inflation.
How should bonds be refunded for different grant types?
Acceptance alone only reflects intent or potential. Delivery demonstrates outcome. Without tying bonds to delivery, we risk proposers getting funds approved but never delivering work, resulting in a net negative ROI for the treasury and the token.
Here’s how we could tie Grant types to bond refunds to ensure delivery without creating community voting overhead:
Note: Community veto, unlike affirmative voting that kicks in voter fatigue and governance deadlocks, is a light-weight, simpler voting mechanism that requires a simple majority objection to stall disbursement of funds.
3.5 Abstain Weight
As per the RFC, Abstain helps reach quorum but does NOT help pass or reject the proposal. This is a resilient design and should be included in Phase 1.
Here is how we would approach a short simulation design to check if abstention could potentially create any governance deadlocks with quorum and majority threshold levels:
3.6 Proposal Lifecycle Duration
Without clear period definitions, proposals risk rushed approval, low participation, or inability to safely intervene before funds are released.
Mapping TLDR:
[Pre-Discussion]* → Proposal (3d) → Exploration (7d) → Voting (7d) → Cooldown (7–14d)
* Pre-discussion is a social layer, intentionally not formalised in protocol.
Break-glass committee may intervene at ANY point (emergency override/pause).
3.7 Proposal Templates and Content Host
A consistent and verifiable proposal format is essential to ensure legitimacy and censorship-resistance of governance decisions without forcing large payloads fully on-chain in Phase 1.
We recommend the following approach:
1. Standardise Proposal Templates (min. 2 canonical types)
-
Treasury Spend Proposal (funding, grants, public goods)
-
Treasury Upgrade / System Change (governance mechanism changes, parameter updates) — Can also be explored in Phase 2
Case study: Gitcoin’s Clarity Framework, to improve proposal quality, decomposability, and evaluation consistency.
2. Integrate Lightweight CI (automation) at Submission Layer
-
Content is hash-matched against the on-chain URI. Max content size ≤ 1 MB
-
If missing or tampered → proposal cannot enter the voting stage
-
Title, scope, budget, deliverables and other required fields automatically validated (This feature can be in Phase 2)
3. Explore potential content hosting options
04 RECOMMENDATIONS: TREASURY & PARAMETERS
Important for Launch Phase 1
4.1 Disbursement Cadence
A disbursement cadence defines how fast the treasury can be allocated into the ecosystem. We need to balance responsible capital outflow with operational agility, and minimize capture risk during early governance.
Recommendation:
Adopt a simple and clear Funding Round Model, similar to Optimism, Ethereum ESP, and Gitcoin Grants:
-
Treasury opens funding rounds
-
Fixed budget per round (e.g., ≤15% of treasury per quarter — cap to prevent rapid depletion)
-
Proposals are collected, ranked, and approved only within that allocation window
-
Milestone-based disbursement post-approval — funds are not released upfront in full
As treasury governance matures, we can explore an adaptive cadence that is adjusted based on participation and disbursement caps increase only when governance participation is strong.
05 RECOMMENDATIONS: SECURITY PARAMETERS
Important for Phase 1 Launch
5.1 Break Glass Composition
The goal is to avoid “Foundation as a single point of failure” while keeping execution nimble.
Recommended composition from geographically distributed areas with relevant competencies:
- 3 internal Foundation members (geographically distributed for jurisdictional resilience)
- 1 representative from o1Labs (technical insight)
- 1 external governance/security expert (security and risk oversight)
5.2 Break Glass Veto
The Break Glass Committee acts as a final safety fail-safe empowered to veto a malicious or system-threatening proposal before funds are irreversibly disbursed.
Because the value-of-veto (treasury at risk × probability of exploit) is high during the early lifecycle of governance, a supermajority threshold is recommended to minimize collusion risk while preserving executable speed.
Recommended veto threshold:
Minimum 3 of 5 or 5 of 7 (supermajority, not simple majority)
5.3 Break Glass Committee: Escalation Pathway
In the event of suspected collusion, bribery, or governance misbehavior, any participant may securely submit a report to the Break Glass Committee through an authenticated and optionally confidential channel.
A trustless ticketing system will be opened to facilitate these submissions. Reports filed through this system will automatically flow into a dedicated, monitored email alias accessible only to the Break Glass Committee. The whistleblower’s identity will never be revealed, ensuring full protection and encouraging good-faith disclosures.
All allegations must be substantiated with verifiable evidence, such as on-chain transactions, proposal IDs, signatures, or other material proof. Upon receipt, the Committee will verify the claim, assess its severity, and may exercise one or more of the following powers:
-
Pause: Temporarily halt governance processes or fund disbursements.
-
Freeze: Lock specific smart contracts, funds, or decision pathways until review concludes.
-
Remediate: Enact corrective actions to reverse or mitigate the impact of identified misconduct.
-
Dismiss: Reject unfounded claims after due diligence.
-
Reward: Recognize and optionally reward whistleblowers who acted in demonstrable good faith, contributing to the protocol’s long-term security and integrity.
To discourage frivolous or malicious reporting, a small refundable bond may be required when submitting a ticket. This bond may be slashed if the whistleblower is found to be engaging in spam, harassment, or bad-faith behavior, or refunded upon validation of a legitimate claim.
All validated reports and subsequent actions will be transparently documented through official governance channels, maintaining a balance between confidentiality, accountability, and community trust.
06 METHODOLOGIES USED
6.1 Mapping Attack Vectors and Stakeholder Groups
We began by first identifying all possible voter archetypes (staked, unstaked, delegated, delegated to unstaked address, etc.) and mapped how power currently flows across them.
From there, we mapped who could realistically exploit the system and listed all economically viable attack vectors from vote-rental markets and short-sell exploits to BP/validator cartels and asymmetric risk games. This ensured no governance model was evaluated in isolation from adversarial realities.
6.2 In-depth Kick-off Exercise
We conducted a structured orientation with the Foundation to align on:
-
strategic intent of governance (security vs legitimacy vs decentralization)
-
Timelines and efficiency (centralized speed now vs progressively decentralized future)
-
non-negotiables (e.g., token bonding, avoid regulator flags, minimize friction to ship)
This let us operate with true architectural clarity and roadmap, not designing in the abstract.
6.3 Quantitative Derivation and Simulation
We ran basic live simulations on real MINA token holder distribution using BigQuery to test:
-
how many wallets are needed to hit quorum in reality
-
attack feasibility under different turnout biases (positive / negative)
-
economic thresholds for Sybil, cartel, and griefing attacks
-
sustainability of treasury disbursement over repeated cycles
This grounded all recommendations in economic truth.
6.4 Stakeholder Grouping and Identification Maps
We segmented stakeholders into buckets based on skin-in-the-game, influence, coordination density, and alignment risk.
This allowed us to recommend who should be empowered in Phase 1, and who should enter via progressive decentralization, avoiding capture while still rewarding proven operators.
6.5 Timeline Bucketing and Prioritization Matrix
Finally, we mapped outcomes against time assigning what must happen now vs later vs never.
-
Phase 1: Safety and central control with break-glass
-
Phase 2: Conditional devolution based on measurable maturity
-
Phase 3: Decentralize further and bring efficiency once resilience is proven
07 NEXT STEPS
We would love to help down-select and define parameters. Here’s the exhaustive list of items that we would like to support with:
7.1 Economic Simulations (Modeling & Parameter Finalization)
-
Stress-test quorum / majority thresholds under realistic voter turnout distributions and under different tiers
-
Simulate adaptive quorum curves (positive / neutral / negative bias) and deadlock risk
-
Model attack feasibility (vote rental, buy-vote-dump, cartel capture, Sybil dilution) under real MINA holder concentration
-
Simulate treasury disbursement runway under fixed vs adaptive cadence (6–12+ cycles)
-
Model bond % slashing outcomes for malicious vs abandoned vs successful delivery scenarios
-
Run volatility-adjusted risk models for cooldown extensions on high-value (>5%) proposals
-
Model impact of abstain-heavy scenarios on pass/fail legitimacy with tiered governance
-
Category-based fund allocation simulation (to support “slam-dunk” and “flex-tier” buckets)
-
Finalize spam / proposal filter policy
-
Define non-funding proposal governance path
-
Structure fund category design (infra, community, moonshots, etc.)
-
Define Phase 1 funding round cadence and spending caps
-
Decide delegate compensation model (if any: committee, milestone, retro?)
7.2 Governance Charter and Committee Formation
-
Finalize Phase 1 voter eligibility (staked MINA with validator skin-in-the-game only)
-
Finalize Break Glass Committee composition (confirm 3 MF + 1 o1 + 1 external governance/security expert)
-
Define charter + explicit veto limitations + sunset mechanism
-
Define proposal lifecycle commitments (3d Proposal → 7d Explore → 7d Vote → cooldown)
-
Define when delegation overrides are allowed (e.g., stake delegators vs passive holders)
-
Confirm bond policy (refund if pass, burn/slash if malicious → finalize % tiers)
-
Validate final Phase 1 → Phase 2 decentralization triggers (participation threshold, # of cycles executed safely, etc.)
-
Define Break-glass sunset rules
7.3 Proposal Templates, Submission Rules & Moderation Layer
-
Define acceptance criteria (must-have fields: intent, budget, milestones, accountability, beneficiary wallet, conflict disclosures, etc.)
-
Draft official proposal templates (Treasury Spend, Treasury Upgrade — minimum two types)
-
Establish moderation rules for Phase 1
-
Build notifications and coordination engine and processes for smooth governance tracking in Phase 1
7.4 Cross functional, Operational Track
-
Community onboarding & feedback on UX design (with Emily)
-
Regulatory alignment check (flag to legal – KYC/KYB for payouts)
-
Treasury budget monitoring & escalation workflow (with Foundation Finance)
-
Governance MVP tool stack (front-end voting, explorer view, proposal DB infra)
-
Wiki and reading materials review for community voting and onboarding experience
08 ASSUMPTIONS TESTED FROM THE RFC
Quorum: ≥ 50% of total eligible supply at snapshot
Majority Threshold: ≥ 60% Yes (configurable up to 75%)
Voting Stance Options: Yes / No / Abstain (Abstain counts toward quorum)
Proposal Bond: Configurable % (e.g., 10% of requested amount)
Bond Treatment: Returned if proposal passes, burned or frozen if rejected
Ledger Snapshot: Based on historical epoch snapshot (not real-time balances)
Lifecycle Stages: Proposal → Exploration → Voting → Cooldown → Execution
Delegation Rule: Default voting power flows from staking delegation unless manually overridden
Upgradeability: Treasury contracts (zkApps) are upgradeable post-launch
Break-Glass Governance: Exists in early phases; explicitly intended to sunset later
09 REFERENCES & LINKS
-
Treasury RFC:https://forums.minaprotocol.com/t/rfc-mina-decentralized-treasury-decentralized-on-chain-community-treasury/6924
-
Governance Forum: https://forums.minaprotocol.com/c/governance/27
-
Excalidraw Mappings: https://excalidraw.com/#json=ZwBsibX1NZd_d1QzcTKAM,A9gYzofz_yWa4mfHTDKtXw
-
Recommendation Pipeline WIP: https://docs.google.com/document/d/1N6xkz6Okm-n4V9YB-6gC-Z7tsnvuVQog9jPpfOO3ZH4/edit?tab=t.0
-
MINA Foundation <> Aragon Kick off Exercise: https://docs.google.com/document/d/1Sl8L1hgDKsz1JGxxHu7oLcUdTp-H_OGUhW9NugQ2MZQ/edit?pli=1&tab=t.0
-
Analysis: Sybil Attacks: https://docs.google.com/document/d/1twXscXwARrSBg-QTJ4preGugkQ-ZRIUGBbniC4pb6Lg/edit?tab=t.0
-
Stakeholder mapping: https://docs.google.com/spreadsheets/d/1OvWyPAIm23Bt2GUN8R13N_tOpNw0eEfnKNLa_tMTG8I/edit?gid=0#gid=0
-
Big Query Simulations of MINA tokenholders: https://console.cloud.google.com/bigquery?ws=!1m7!1m6!12m5!1m3!1smina-ledger-export!2sus-central1!3sa8db721e-aed2-46f0-bc9e-664f45615301!2e1
-
Delegation Policy: https://minaprotocol.com/blog/mina-foundation-delegation-policy
-
Validator List: https://minascan.io/mainnet/validators/leaderboard