Mina Decentralized Treasury: Deployment Framework

Summary

The Mina Decentralized Treasury (DT) funds initiatives that help the Mina ecosystem grow. Community members submit funding proposals, and MINA holders vote on them. Mina Foundation is deploying it with Aragon, which provides governance and operational stewardship during the initial deployment.

The treasury opens in three phases. Each phase is a separate deployment of the DT App with a larger allocation and higher participation requirements. Break glass stays active through the transition and for an initial period after Final.

How the DT App works

The DT App is a Mina-native zkApp. It runs the proposal lifecycle, works out the participation and approval each proposal needs from the size of the request, tallies votes against Mina chain state, and pays out proposals that pass.

The app was audited and security reviewed, and tested against several chain-state datasets, including mainnet. Some governance parameters are fixed within a deployment, which is why the treasury grows through successive deployments rather than one.

Proposals and the bond

Proposal templates and best practices will be shared ahead of the Test phase. There are three kinds of proposal:

• Grants: one-off requests worth less than USD $10,000 at the time of the proposal, with a tangible benefit to the Mina community.
• Funding requests: requests worth USD $10,000 or more at the time of the proposal, with a clear and measurable benefit to the Mina ecosystem.
• Public goods: ongoing operations or infrastructure that benefits the Mina community and ecosystem.

For the Test phase, each proposal needs a bond of 1% of the amount requested, which discourages spam. The bond may be raised in later phases if spam becomes a problem. If the proposal executes, the bond is paid out with the approved amount to the recipient address. If it doesn’t pass, doesn’t 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. Larger requests can be split into milestones; ongoing costs fit the public goods category.

Lifecycle

Every proposal goes through four stages, each one Mina epoch long (about a week since the Mesa upgrade), so about four weeks in total. The stages are fixed in the app.

1. Submission: the proposer submits the proposal and its on-chain payload. The description must match the payload.
2. Exploration: the community reviews the proposal and gives feedback.
3. Voting: validators and self-delegating MINA holders vote. Votes must be recorded in at least five different slots for the proposal to be tallied.
4. Cooldown: a final epoch before a passed proposal executes.

KYC

Before any payout, the recipient completes KYC (individuals) or KYB (entities) with Blockpass, an independent provider. Verification covers identity, beneficial owners where relevant, and sanctions screening, and stays valid for 12 months unless ownership or operational structure changes materially. It usually takes about a week when all documents are complete, so start early.

Mina Foundation confirms each result. Identity documents stay with Blockpass and Mina Foundation; Aragon, DT participants and the community only rely on whether verification passed. If it fails or isn’t completed, or the address fails sanctions or risk screening, the break-glass signers veto the proposal and it isn’t paid.

Break glass

Five signers hold the break glass: three appointed by Mina Foundation and two by Aragon. Any three can veto a proposal, or halt the treasury during a security incident, by submitting a signed proof to the DT App. Signers can be replaced when the app is redeployed.

The default is not to intervene. The signers act only on these grounds:

1. Obvious violation of law. A clear and severe breach, such as illicit finance, sanctions evasion or serious intellectual property theft. Proposers are responsible for legal compliance; signers don’t audit proposals for it.
2. Direct conflict with Mina’s purpose. The proposal’s main effect works against the purposes in Article 2 of the Mina Foundation Deed: decentralized software, the Mina protocol and its technology, applications including zkApps, the Mina community, and a sustainable decentralized organization. Disagreement over strategy or viability doesn’t count.
3. KYC/KYB failure. The recipient fails or doesn’t complete verification, or the address fails sanctions screening.
4. Imminent risk to funds. A credible threat that treasury funds will be stolen, frozen or impaired.
5. Governance capture. Vote buying, bribery, coercion, or one group using concentrated voting power to benefit itself at the treasury’s expense.
6. Attacker benefit. A large one-sided transfer to a few accounts with no plausible benefit to the protocol.
7. Security incident. A critical vulnerability, active exploitation, or an infrastructure attack that makes operation unsafe.
8. Procedural or technical irregularity. A malformed payload, wrong accounts or parameters, or a mismatch between the description and the payload.

Every intervention is posted on the Mina forum with the proposal, the reason, and what the proposer needs to change to resubmit.

The Steward Key

Aragon deploys each phase of the DT App with its deployment key, the Steward Key. In the Test and Scale Up phases, the Steward Key can return the treasury’s funds to Mina Foundation’s Custodian Wallet in an emergency, such as a parameter error, with Mina Foundation’s written approval. It can’t veto proposals or halt the treasury.

The Final deployment is set up so that funds can only move through passed proposals, with no emergency return. Once the conditions for removing break glass are met, its signer keys are sent to a burn address and the Steward Key is destroyed.

Adaptive thresholds

A proposal passes when it reaches both the required participation and the required approval:

Approved ⇔ (Y + N + A ≥ RequiredParticipation) ∧ (Y + N > 0) ∧ (Y / (Y + N) ≥ RequiredApproval)

Y, N and A are yes, no and abstain voting weight. Abstain counts towards participation but not approval.

With x = min(proposalAmount / treasuryBalance, 1) and curve(x, c) = x / (x + c(1 − x)):

• RequiredParticipationBp = 2,000 + 3,000 × curve(x, 0.05)
• RequiredApprovalBp = 5,100 + 1,900 × curve(x, 0.10)

By default, before the per-deployment factor, participation rises from 20% to 50% and approval from 51% to 70% as the request grows to the whole treasury. Example values:

• 1% of the treasury: 25.04% participation, 52.74% approval
• 10%: 40.68% participation, 60.99% approval
• 50%: 48.56% participation, 68.27% approval
• 100%: 50.00% participation, 70.00% approval

These participation values are the default range, before the per-deployment factor. Each deployment’s participation settings will be confirmed before it goes live.

Phases

• Test: 1,000,000 MINA. Participation requirements are lowest, to support initial proposal activity.
• Scale Up: 20,000,000 MINA. Participation requirements increase, so proposals need broader voting participation.
• Final: up to 34,000,000 MINA. Participation requirements are at their highest.

By the time break glass is removed, the framework is designed so that passing the largest request takes more MINA than that request could pay out.

Test to Scale Up happens as soon as the Test treasury is spent, two proposals pass in a row, or two months go by. Scale Up to Final happens as soon as the Scale Up treasury is spent, three proposals pass in a row, or three months go by. MINA left in a phase moves into the next deployment.

Voting power

When the parameters were set, the top 10 validators held about 32.95% of voting power, and holdings were concentrated among the largest accounts. In the Final phase, participation requirements are at their highest and rise with the size of the request. The thresholds don’t assume that any particular validator, exchange or large holder will vote.

Next steps

Aragon will operate the DT App and its required infrastructure for an initial 24 months under its agreement with Mina Foundation, including the infrastructure that keeps the app synchronized with Mina chain state. After the remaining deployment and security readiness work, Mina Foundation and Aragon will open the Test phase with 1M MINA.

Terms, parameters and processes, including the bond, may change before deployment. Final values for each deployment will be confirmed before it goes live.