# Mina Decentralized Treasury: How It Works and What Comes Next **URL:** \ **Category:** Governance\ **Created:** [October 23, 2026, 9:02am UTC](https://forums.minaprotocol.com/t/mina-decentralized-treasury-how-it-works-and-what-comes-next/7123 "2026-10-23T09:02:44Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Aragon](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/aragon/32/2499_2.png) [@Aragon](https://forums.minaprotocol.com/u/Aragon)\ **Post date:** [October 23, 2026, 9:02am UTC](https://forums.minaprotocol.com/t/mina-decentralized-treasury-how-it-works-and-what-comes-next/7123/1 "2026-10-23T09:02:44Z")
# **Mina Decentralized Treasury Deployment Framework** ## **Summary** The Mina Decentralized Treasury (DT) is an onchain funding mechanism designed to support the continued development, adoption, and success of the Mina ecosystem. It allows community members to submit funding proposals and MINA holders to evaluate and vote on how treasury funds are allocated. ## **Overview** Mina Foundation is preparing to deploy the DT as a new mechanism for funding ecosystem initiatives through onchain community participation. The DT will be introduced progressively. An initial allocation will be deployed with defined governance and security safeguards. Subsequent deployments will make larger treasury allocations available under higher participation requirements, with the Break Glass safeguard remaining active during the transition. Aragon has already supported Mina Foundation with governance research and parameter design in advance of this effort and will now provide governance and operational stewardship during its initial deployment. This framework explains how the DT App will operate, how proposals will move through the governance process, which safeguards will ensure its success, how voting thresholds are calculated, and how the treasury will progress through successive deployment phases. ## **1. How the DT App Works** The DT will be deployed via a Mina-native zkApp, referred to here as the DT App, to manage treasury funds and enforce the governance process. The DT App supports a predefined proposal lifecycle. It calculates adaptive participation and approval requirements based on the size of each funding request, tallies and verifies votes using Mina chain state, and executes treasury disbursements for successful proposals. The DT App has undergone [several audits](https://reports.zksecurity.xyz/reports/mina-treasury-1/) and [rigorous testing](https://github.com/trailofbits/publications/blob/master/reviews/2026-06-mina-decentralizedtreasury-securityreview.pdf) against multiple chain-state datasets, including mainnet, devnet, and purpose-built configurations. This testing checks that the app tallies votes correctly, handles edge cases, and stays in sync with Mina chain state so its proofs remain valid on the network. Some governance parameters are fixed within each deployment of the DT App. Therefore, the DT will progress through successive deployments with larger treasury allocations and corresponding participation requirements. This phased approach limits treasury exposure during initial operation and allows the system to progress from a smaller initial deployment to the full treasury allocation over time. ## **2. Proposal Lifecycle and Proposer Guidelines** The purpose of the DT is to fund initiatives that contribute to the adoption, development and success of the Mina ecosystem. Clear and well-scoped proposals give MINA holders the information they need to evaluate how treasury funds should be allocated. Proposal templates and best practices will be shared ahead of the Test Phase to guide submissions. Proposals fall into three categories: - **Grants** are smaller, one-off requests worth less than USD $10,000 at the time of the proposal, for initiatives that provide a tangible benefit to the Mina community. - **Funding Requests** are requests worth USD $10,000 or more at the time of the proposal, for initiatives that provide a clear and measurable benefit to the Mina ecosystem. - **Public Goods Proposals** support ongoing operations or infrastructure that benefits the Mina community and ecosystem. The proposal template asks contributors to provide the amount requested, a summary of the expected benefit to the Mina ecosystem, an explanation of how impact can be assessed, a full description of the proposal, and any relevant milestones. The proposal description must accurately correspond to the onchain payload. For the Test Phase, each proposal requires a bond equal to 1% of the requested amount, to discourage proposal spam. The bond may be raised in later phases if spam becomes a problem. When a proposal executes, the bond is paid out together with the approved amount to the proposal’s recipient address. If the proposal does not pass, does not reach the participation it needs, or is vetoed, the bond stays in the treasury. Before submitting, share a draft on the forum and in Discord, gather feedback, and build support with validators and MINA holders. Consider splitting larger requests into milestones, and use the Public Goods category for ongoing costs: smaller requests need less participation to pass. **Proposal lifecycle** During development of the DT App, technical requirements led to a simplified lifecycle in which each of the four stages is one Mina epoch in length. After the Mesa mainnet hardfork, each epoch is approximately one week, resulting in a full proposal lifecycle of approximately four weeks. These parameters are fixed in the DT App and cannot be changed without redevelopment and additional audit. The proposal lifecycle consists of four stages: 1. **Proposal Submission:** The proposer submits a complete proposal together with the corresponding onchain payload. 2. **Exploration:** The community has one epoch to review the proposal and provide feedback. 3. **Voting:** Validators and individual MINA holders with self-delegation can vote during the one-epoch voting window. For a proposal to be tallied, its votes must be recorded in at least five different slots. 4. **Cooldown:** Approved proposals enter a final one-epoch period before execution. https://info.minadt.com/flow > **[How the Mina Decentralized Treasury works](https://info.minadt.com/flow)** > > Interactive flow chart of the Mina Decentralized Treasury, its proposal process, checks, funds and safeguards. Proposers are responsible for submitting proposals that are legible, complete and informative. The community determines whether a proposal merits funding through the voting process. While the Break Glass safeguard is active, its role is limited to the predefined intervention criteria below. It does not assess proposals against subjective standards of quality or feasibility. Those decisions remain with voters. Funding recipients are expected to proactively report key deliverables and milestones to the community. ## **3. Phased Treasury Deployment** The total deployable treasury is approximately 55 million MINA. The treasury will be introduced through three successive DT App deployments. This approach limits exposure during initial operation, allows real-world voting participation and proposal activity to be observed, and increases participation requirements as more treasury capital becomes available. The DT App has been rigorously tested and audited across multiple datasets, including live mainnet data. The phased rollout provides an additional safeguard by beginning with a comparatively small live deployment before progressing to larger allocations. ### **Test Phase** The Test Phase will deploy **1 million MINA**. Its purpose is to provide real-world data on voting participation and proposal volume while limiting the amount of treasury capital exposed during the initial deployment. The Break Glass will remain active. Aragon deploys the DT App and holds its deployment key, the Steward Key. During this phase the Steward Key can return the treasury’s funds to Mina Foundation in an emergency, with the Foundation’s written approval, so the treasury can be redeployed if parameter errors or other failure modes emerge. Participation requirements are intended to be lowest during this phase to support initial proposal activity. ### **Scale Up Phase** The Scale Up Phase will aim to deploy **20 million MINA.** The Break Glass and the emergency return described above will remain in place. Participation requirements are intended to increase relative to the Test Phase, requiring broader voting participation for proposals to pass. ### **Final Deployment** The Final Deployment will make **up to 34 million MINA** available. The Final Deployment is set up so that funds can only move through passed proposals, with no emergency return. The Break Glass will remain active initially. Once the conditions for its removal are met, its signer keys will be sent to a burn address, permanently removing the Break Glass, and the Steward Key will be destroyed. After the Break Glass is removed, the voting and participation requirements encoded in the DT App will remain as the governance safeguard against treasury-draining proposals. **Deployment parameters** Each deployment has its own treasury size and its own participation settings. The values for each deployment will be confirmed before it goes live. Key terms - Treasury: the amount of MINA in a deployment. It is also the most any single proposal can request from that deployment. - Participation: how much voting weight takes part in a vote. Yes, no and abstain votes all count towards it. - Approval: the share of yes votes among yes and no votes. Abstentions don’t count here. - Pmin and Pmax: the lowest and highest participation a proposal can require. Small requests need close to Pmin; a request for the whole treasury needs Pmax. - Amin and Amax: the lowest and highest approval a proposal can require, on the same sliding scale. - Modifier: a per-deployment factor applied to the participation requirement, so early deployments remain achievable and later, larger ones are harder to capture. The value for each deployment will be confirmed before it goes live. - Pmax / Treasury: how many times larger the highest participation requirement is than the treasury it protects. When this is above 1, passing the largest request takes more MINA than that request could pay out. - Bond: the deposit a proposer puts up with each proposal (1% of the request in the Test Phase), paid out with the approved amount when the proposal executes. - Epoch: Mina’s unit of time for the lifecycle, about one week. Each of the four stages lasts one epoch. ### **Transition between deployments** The DT will move between deployments according to the following approved criteria. For the transition from the **Test Phase to the Scale Up Phase** , the transition will occur as soon as any one of the following conditions is met: - the treasury deployed to the Test Phase is spent; - two consecutive proposals pass; or - two months have elapsed since the initial deployment went live. Any MINA remaining in the Test Phase deployment will then be drained and deployed to the Scale Up Phase. For the transition from the **Scale Up Phase to the Final Deployment** , the transition will occur as soon as any one of the following conditions is met: - the treasury deployed to the Scale Up Phase is spent; - three consecutive proposals pass; or - three months have elapsed since the Scale Up deployment went live. ## **4. Voting Power Distribution** The distribution of MINA voting power is an important input into the participation thresholds used by the DT. Current voting power is concentrated among a relatively small number of large accounts and validators. The analysis underlying the approved parameters found that the top 10 validators account for approximately 32.95% of voting power, while holdings are also highly concentrated among the largest individual accounts. This concentration means that participation requirements need to balance two considerations. They must remain achievable given the distribution of active voting power, while still requiring sufficiently broad participation relative to the amount of treasury capital that a proposal can access. In the Final Deployment, participation requirements are at their highest, rising with the size of the request, so the largest requests need the broadest support from MINA holders. The higher threshold materially increases the amount of voting power required as the amount at stake grows. The resulting framework combines adaptive participation and approval thresholds, progressively larger treasury deployments, the temporary Break Glass safeguard, and a proposal bond, 1% in the Test Phase, that is paid out only when a proposal executes. This approach reflects the current distribution of onchain voting power without relying on assumptions about whether any specific validator, exchange or large holder will participate in a particular vote. ## **5. Break Glass Safeguard** The DT App includes a temporary Break Glass safeguard that can veto proposals when one or more of the predefined intervention criteria below are met. Three of five signers must agree and submit a signed proof to the DT App for an intervention to take effect. ### **Composition** The initial five signer seats are: - 3 Mina Foundation - 2 Aragon Each organization will appoint its signers independently. Signer accounts can be reassigned when the DT App is redeployed. Break Glass signers and their appointed owners must complete the applicable KYC/KYB requirements. ### **Intervention criteria** The Break Glass is a security and compliance safeguard with an exhaustive set of binding grounds for intervention. The default position is non-intervention. Any action must be justified under one or more of the criteria below and will be documented publicly. #### **a. Obvious Violation of Applicable Law** The legal compliance of a proposal remains the responsibility of its author. Neither the Break Glass signers, Mina Foundation, Aragon, nor the broader community are responsible for proactively auditing proposals for legal or regulatory compliance. The Break Glass may intervene when a clear, unambiguous and severe violation of basic legal standards is identified before execution. This includes direct engagement in illicit financial activity, criminal enterprise, severe intellectual property theft or explicit breaches of sanctions frameworks. The Break Glass does not act as a general regulatory review board or legal gatekeeper. Complex, ambiguous or jurisdiction-specific legal questions are not themselves grounds for intervention. #### **b. Direct Conflict with Foundational Purpose** The Break Glass may intervene when the primary effect or operational outcome of a proposal directly contradicts or sabotages the purposes set out in Article 2 of the Mina Foundation Deed. Those purposes are to: - promote and develop decentralized software architectures; - promote and develop the Mina protocol and its underlying technology; - support applications using Mina protocol technology, including zkApps; - support the Mina protocol community; and - promote the development of a sustainable, decentralized organizational entity supporting and represented by those building on and using the protocol. Examples include proposals that maliciously redirect treasury assets toward unrelated or competing blockchain ecosystems; deliberately compromise or disable the Mina technical stack, zkApp ecosystem or core infrastructure; intentionally harm the Mina community; or subvert the transition toward a sustainable decentralized governance model. This criterion cannot be used to veto proposals because of subjective disagreements over strategy, ideology or project viability. Where a proposal plausibly serves the purposes above, the funding decision remains with MINA holders. #### **c. KYC/KYB Failure** The Break Glass will veto a proposal when the recipient fails to complete or pass the required KYC/KYB process. The same applies when an address fails applicable sanctions or risk screening at any stage. These requirements are intended to prevent treasury funds from reaching sanctioned, unknown, unverified, unlinked or otherwise high-risk recipients. KYC/KYB checks are carried out through a reputable independent third-party screening provider and communicated to proposers so that they have sufficient time to complete the process before payout. #### **d. Imminent or Active Risk to DT Funds** The Break Glass will intervene when there is a clear and credible threat that DT funds will be stolen, frozen or materially impaired if no action is taken before a proposal executes or the contract continues operating. Examples include a governance proposal that would transfer a significant portion of the treasury to an attacker or attacker-controlled contract, or the discovery of an exploit or bug that enables repeated draining of treasury funds. #### **e. Governance Capture and Malicious Voting** The Break Glass may intervene when there is evidence that the governance process itself has been compromised through capture or vote manipulation. Indicators include a single entity or tightly coordinated group controlling sufficient voting power to pass proposals that benefit themselves at the expense of the DT; a proposal passing by a narrow margin in the face of unusually high and well-reasoned opposition, providing reason for additional scrutiny; or evidence of bribery, vote buying or offchain coercion that corrupts the voting process. Under these conditions, the basis for intervention is that the voting process itself has been compromised. #### **f. Proposals Whose Primary Effect Is Attacker Benefit** The Break Glass may intervene when a proposal exists for the sole benefit of an attacker. Indicators include a sizable and one-sided transfer of value to a narrow set of accounts without commensurate benefit to the protocol, or an action with little or no legitimate governance justification beyond exploiting a temporary governance or market condition. The assessment should consider who benefits, who bears the risk and whether there is a plausible pro-protocol rationale for the proposal. #### **g. High-Severity Security or Infrastructure Incidents** The Break Glass may intervene in response to the discovery of a critical DT App vulnerability that can be exploited on short notice, the active exploitation of a live bug affecting protocol components, or an infrastructure attack that makes normal operation unsafe. In these circumstances, the Break Glass can pause affected proposals or veto proposals that would exacerbate the incident or prevent necessary mitigation. #### **h. Procedural or Technical Irregularities in a Proposal** The Break Glass may delay or cancel proposals when procedural or technical errors could cause unintended execution. This includes malformed, misencoded or technically incorrect proposals, including incorrect accounts or parameters; a material mismatch between the offchain proposal description and the onchain payload; or a violation of established process requirements, including required discussion periods or audits. In these cases, the purpose of intervention is to prevent erroneous execution, not to substitute the signers’ policy judgment for that of voters. ### **Principles for Break Glass intervention** The Break Glass is intended as a last-resort mechanism. Substantive disagreements alone are not grounds for intervention, except where a proposal directly conflicts with Mina Foundation’s foundational purpose as described above. Every intervention must be publicly justified and documented. The Break Glass is also transitional. Signers can be reassigned during redeployments, and the safeguard will ultimately be removed once the DT reaches the approved conditions for operating without it. ### **Documentation** Every Break Glass intervention will be documented on the Mina research forum. At minimum, the record will include the proposal name and a link to the proposal, together with the reason for intervention, including why the proposal was vetoed and what is expected of the proposer if they wish to resubmit. ### **Timing of interventions** The Break Glass can intervene at any point in the proposal lifecycle. In practice, intervention is expected primarily during Exploration, where a proposal is clearly malicious or its payload materially differs from the proposal text; during Voting, where the proposer has not completed the required KYC/KYB process; or during Cooldown, where a malicious or non-KYC/KYB-compliant proposal was not identified earlier. ## **6. KYC/KYB and Recipient Verification** Proposers must complete the KYC/KYB process required by Mina Foundation before treasury funds can be disbursed. Verification is carried out through a Foundation-approved independent third-party provider and includes identity validation, beneficial-owner screening where applicable, and sanctions screening. A completed verification remains valid for up to 12 months, provided there are no material changes to the entity’s ownership or operational structure. Teams without a formal legal entity must designate a primary legal representative or lead individual to complete verification on behalf of the group before payout. The verification process typically concludes within one week when all required documentation is submitted accurately and in full. Proposers should therefore begin the process sufficiently early to ensure verification is completed before execution. Identity records and corporate documents remain offchain with the verification provider and Mina Foundation. Any personal data shared for these purposes will be treated in accordance with the applicable privacy policies and legal retention requirements. These documents will not be shared with Aragon, DT participants or the broader Mina community. The system instead relies on the verification result. If a proposer fails to complete or pass verification, or the recipient address fails applicable sanctions or risk screening, the Break Glass will veto the proposal and prevent payout. ## **7. Adaptive Participation and Approval Thresholds** Participation requirements are an important safeguard against governance attacks, but they also need to remain achievable for legitimate proposals. The DT addresses this through adaptive participation and approval thresholds. Rather than applying the same threshold to every proposal, the requirements increase with the size of the funding request relative to the treasury available in that deployment. Smaller requests therefore require less participation, while proposals seeking a larger share of the treasury require both greater participation and stronger approval. During the initial deployments, the Break Glass provides an additional safeguard against governance attacks and malicious or extractive proposals. This allows participation requirements to begin at lower levels while the amount of treasury capital exposed is limited. As larger amounts of MINA are deployed, participation requirements increase. At the point where the Break Glass is removed, the framework is designed so that the amount of MINA required to participate on the largest funding request is greater than the amount of MINA that proposal can distribute. Before that point, the required participation can be lower because the Break Glass remains available as a final safeguard against malicious proposals. ### **How adaptive thresholds are calculated** A proposal is approved when both the required participation threshold and the required approval threshold are met: `Approved ⇔ (Y + N + A₀ ≥ RequiredParticipation) ∧ (Y + N > 0) ∧ (Y / (Y + N) ≥ RequiredApproval)` Where: - `Y = yay voting weight` - `N = nay voting weight` - `A₀ = abstain voting weight` - `Abstain counts for participation, but not approval.` - `Approval is only measured over yay+nay votes.` The thresholds are dynamic. For example, let: - `B = 10,000` - `x = min((proposalAmount / treasuryBalance), 1)` - `curve(x, c) = x / (x + c(1 - x))` With current constants: - `RequiredParticipationBp = 2,000 + (5,000 - 2,000) * curve(x, 0.05)` - `RequiredApprovalBp = 5,100 + (7,000 - 5,100) * curve(x, 0.10)` - `RequiredParticipation = stakingEpochTotalCurrency * Modifier * RequiredParticipationBp / 10,000` The Modifier is a per-deployment scaling factor. Its value for each deployment will be confirmed before that deployment goes live. The thresholds rise from: - `Participation required (default range, before the deployment Modifier): Pmin 20% → Pmax 50%` - `Approval required: Amin 51% → Amax 70%` As proposal size grows relative to treasury balance, both requirements increase. Proposal size is capped at 100% for threshold purposes, so anything at or above the treasury balance uses the maximum thresholds: 50% participation at the default range, before the deployment Modifier, and 70% approval. Example values, with participation shown at the default range, before the deployment Modifier: `001% treasury request: 25.04% participation, 52.74% approval` `010% treasury request: 40.68% participation, 60.99% approval` `050% treasury request: 48.56% participation, 68.27% approval` `100% treasury request: 50.00% participation, 70.00% approval` Participation requirements for each deployment will be set and confirmed before it goes live. ## **8. Stewardship and Next Steps** Aragon will operate the DT App and its required infrastructure for an initial period of 24 months under its agreement with Mina Foundation. This includes the application itself and the infrastructure required to keep the DT App synchronized with Mina chain state. Following completion of the remaining deployment and security readiness work, Mina Foundation and Aragon will proceed with the initial deployment of the DT. Aragon will support the operation and governance of the DT as a neutral steward, applying the approved parameters and safeguards described above and transparently documenting any Break Glass intervention. As the DT progresses through successive deployments, voting behaviour, proposal activity and technical performance will be monitored to support reliable operation. Most importantly, the DT creates a transparent mechanism for directing treasury funding toward initiatives that contribute to the adoption and success of the Mina ecosystem. The proposal guidelines and templates will provide contributors with a clear path to submit funding requests, while allocation decisions are made through MINA holder voting. _This post is a progress update on the build and administration of the Mina Decentralized Treasury. Terms, parameters and processes described here, including the bond, may change before deployment. Final values for each deployment will be confirmed before it goes live._ ---
**Author:** ![jq-rs](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/jq-rs/32/2347_2.png) [@jq-rs](https://forums.minaprotocol.com/u/jq-rs)\ **Post date:** [October 23, 2026, 11:37am UTC](https://forums.minaprotocol.com/t/mina-decentralized-treasury-how-it-works-and-what-comes-next/7123/2 "2026-10-23T11:37:59Z")
A legitimate proposal should not automatically lose its bond simply because the community votes against funding it. That would make applying unnecessarily risky, particularly for smaller teams. I hope this rule is not permanent i.e. is only for the Test Phase. ---
**Author:** ![Aragon](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/aragon/32/2499_2.png) [@Aragon](https://forums.minaprotocol.com/u/Aragon)\ **Post date:** [October 23, 2026, 4:48pm UTC](https://forums.minaprotocol.com/t/mina-decentralized-treasury-how-it-works-and-what-comes-next/7123/3 "2026-10-23T16:48:20Z")
For anyone who wants to dig in further: [info.minadt.com](https://info.minadt.com) has a walkthrough of how proposals move through the process, the interactive flow, and a threshold calculator. ---
**Author:** ![garethtdavies](https://yyz1.discourse-cdn.com/flex035/user_avatar/forums.minaprotocol.com/garethtdavies/32/1224_2.png) [@garethtdavies](https://forums.minaprotocol.com/u/garethtdavies)\ **Post date:** [October 23, 2026, 5:09pm UTC](https://forums.minaprotocol.com/t/mina-decentralized-treasury-how-it-works-and-what-comes-next/7123/4 "2026-10-23T17:09:39Z")
What’s the plan for the initial factor for threshold? Mesa MIPs only had ~15%, and that’s a major protocol upgrade.