community-led treasury, potentially funded by transaction fees or inflation, could ensure long-term ecosystem growth without reliance on centralized entities.
But I could se some red challenge’s Funding uncertainty implementation risk I hope there will be good on chain governance
But then it’s a very promising step toward growth decentralization , but why proposal wasn’t a year ago
About voting rules I like the rules there are strong for promoting flexibility governance but again has its bad rules engagement dependence
I hope this message comes across with the right sentiment, because currently it’s a strange situation.
Although I can see the value of a decentralized treasury… and with a healthy ecosystem and engaged community it would be a really exciting prospect.. but…
if you ask anyone who is still holding Mina, a decentralized treasury is fairly low on their list of wants.
To give a reality check, if Mina continues to decline the only people voting on proposals will be the 13 people who have voiced their opinions on this thread (half of whom are either current or ex employees).
It’s sad to say but the vast majority of the community that still exists is currently either angry, frustrated or disengaged.
As someone who very much cares about the project, in the short term i would really like to see @bkase and o1 Labs put forward some grant opportunities for specific Mina infrastructure (perhaps things that can be built on top of Nori could be one?) and breathe some fire back into the project.
Wdyt @hgedia @acityinohio @maht0rz ?
Hey Pete. I feel there is some misunderstanding here. o1Labs is currently supporting many of the existing builders. We recently published an update here : o1Labs’ MINA Treasury Update
o1Labs will certainly look to support new projects in the near future once we feel the underlying base is ready. The Mina foundation led decentralised treasury workstream is independent of the o1Labs grants and one does not mean the absence of the other.
Thanks for the link, yes i did see that and i know these things can work independently of each other.
This is great for current projects, but a serious statement of intent would be a more outward looking perspective in the short term (now).
Thanks for sharing your thoughts @Pete. FWIW it’s a totally fair sentiment and I didn’t take it the wrong way. I wish there was more community energy here too…but the reality is, there isn’t right now. The only real way to win folks back (or attract new ones) is to deliver meaningful progress on the protocol itself. I know o1Labs is heads-down on exactly that, and they now have the focused resources to make it happen.
That said, not to overemphasize it, but a lot of what the community has been asking for (like core development, marketing, ecosystem growth) is firmly in o1Labs’ hands now. Still, the decentralized treasury remains critical for the broader ecosystem; it’s the mechanism that can empower independent projects, grants, and innovations without bottlenecking through centralized entities…like the MF of the past.
Ultimately, our mandate as the Mina Foundation has always been to decentralize power and control to the community…even if it’s a significantly smaller, more core group than we saw a few years ago. It’s a foundational pillar of our mission, and we’re duty-bound to execute on it, regardless of the current headwinds.
It might not feel like the most pressing need in this moment, but it’s both a) our mandate and b) optimizing for an ideal future. In that future, o1Labs delivers on new, exciting initiatives that reignite growth, and when that happens, projects can tap directly into protocol-level funding instead of routing through the Foundation as gatekeepers. I get why it might seem lower-priority today, but I believe the dedicated community members still here will be glad we prioritized this not too long from now, as it sets the stage for a truly self-sustaining ecosystem.
(edit: oh and for more context on the “why the treasury” question we posted some clarifications on the latest transparency report here: https://x.com/MinaFoundation/status/1958088666028429628 . honestly it’s pretty much the same reply said differently, but posting it just in case you or others on the forum wanted answers to other questions raised in the report)
Thanks @acityinohio I know it’s been a long term commitment for some time to decentralize the Treasury and i was part of the small group testing and giving feedback to the team at the foundation (Remi and Ben etc) who started the process way back in January 2024.
I think everyone is onboard with the initiative, but my concern is that without other short term incentives the teams who have experience building on Mina will have moved on to other projects and attracting new teams will be a challenge.
With so many other zk and hyped projects, there’s a real risk of Mina sleepwalking into oblivion. I probably have more connection and contact with the Mina ‘community’ than anyone else so I’m accutely aware of the current sentiment around the project, so that’s not something I say lightly.
Anyway I’ve hijacked this thread on enough tangents… decentralized systems still need someone to decide how they are implemented, and I know @maht0rz is the perfect person to do that.
Thank you, Gregor, for putting up this small risk registry. I think it’s an excellent way to address the issue.
I’m also strongly in favor of a fourth “Spam” option for voting and for rejecting return of the bond only when there were enough “Spam” votes for the proposal.
Putting myself in builder’s shoes, running a small team and arranging financials for it, it would be a considerably risky scenario to dedicate a substantial amount of money to something that is essentially a bet on that community will take the proposal seriously and likes it enough to vote positively.
In general, it’s uncommon for a startup to pay 10% upfront for the permission to pitch to investors. Even early positive feedback doesn’t guarantee actual funding transfers. People could change their mind at the last moment, which is perfectly reasonable—except when you lose 10% of hypothetical funding amount on the failed attempt.
In my opinion, we should encourage builders to submit innovative projects, not discourage them with a high probability of a financial penalty for proposing an idea that isn’t conservative enough to be almost-surely voted for.
Thank you, Matej, for submitting this RFC. I see some incredible work in arranging this proposal, and I think that the technical design behind it is solid. I’ve also reviewed the insightful follow-up discussions, though I joined them quite late in the process.
I have a few questions regarding the technical implementation details of this design. These are relatively low-level concerns that I’m curious about, but they may ultimately affect our assessment of whether a hard fork is truly not required for this project.
I want to highlight that I’m by no means the most knowledgeable person when it comes to writing zkApps, so if my questions seem naive, I apologize for potentially diverting the discussion. However, it would still be helpful for me to understand a few design details you’re considering.
Staking Ledger Access and Voting Mechanics
As I understand it, a key component in this zkApp design is the ability to reference the staking ledger that corresponds to a specific historical state. I have a few questions about this:
Ledger Snapshot Timing: Could you specify more precisely which ledger we will be using for voting?
Will it always be the staking ledger at the time the vote is cast, or will it be the staking ledger at the time the proposal was submitted?
Assuming that voting for a proposal may take at least a few days, and considering that in the future we might reduce slot times leading to shorter epochs, we could have situations where the staking ledger changes during the voting period. If in this design code looks to the ledger state that was captured at the time of proposal submission, this isn’t a concern, of course.
Programmatic Ledger Access: How do you plan to programmatically access that ledger from the zkApp? If you could share some zkApp code snippets that demonstrate the ability to, for example, assert that the staking ledger root hash equals a specific value within the zkApp code, that would be extremely useful for understanding how this will work in practice.
Stake Delegation Computation Feasibility
Regarding the section that states:
“Mina Protocol’s ledger is a Merkle tree of accounts, where each account has a balance and a delegate. There’s no ‘total delegated stake’ per BP, since it’s not necessary for the consensus protocol (due to how VRF is implemented). This means that in order to determine the voting weight of an account, we need to iterate over all accounts delegated to the BP (or any valid voter) and sum up the delegated balance of each account.”
If I understand correctly, you’re saying that we will need to run computation over the entire ledger, and as a result, we’ll have some sort of tree-like structure containing information that maps each block producer to their total delegated stake — unless this information will be provided somehow by the protocol itself.
Do you think it’s actually feasible to create such a mapping using existing zkApp mechanisms, and would it be practical to perform this computation in practice? I mean, if it’s a very intensive computation that runs once and then the result can be posted to a zkApp, I think it’s perfectly viable unless it takes an impractical amount of time to compute. My intuition is that it’s probably possible, but I wanted to double-check because if the answer is that it’s not practical, then we would need to introduce a protocol-level feature, which would most definitely require a hard fork.
Looking forward to your insights on these technical details.
I support the idea of a decentralized treasury (which was wanted to be created several years ago). I really like the basic structure of this project. However, I think that the quorum range needs to be defined more precisely.
Thanks for your comments @georgeee!
The original idea was to have a “governance lifecycle” consisting of “periods” where the entire lifecycle is fixed to a staking ledger which existed at the start of the lifecycle. We could snapshot this using a precondition for the staking ledger hash, therefore any subsequent operation of the treasury within the lifecycle, such as voting, would be subject to the state of the staking ledger at the start of the lifecycle. Furthermore we’re already working on the underlying circuits, one of them being a “transform” circuit of the staking ledger into a voting ledger, so that the vote delegation feature might work. That way the vote delegates can tap into a voting ledger merkle witness, and vote with their delegated balance directly. This would not be possible purely with a staking ledger merkle witness, since the staking ledger only contains individual accounts, not summed up delegate balances.
As I’ve highlighted above, any zkApp that might be part of the final treasury implementation will have precondition access to the staking ledger hash at the given time. Additionally the plan is to use actions to dispatch votes, and then when the eventual treasury operator (should be permissionless) rolls up actions, they will need to provide a proof of transforming the staking ledger into a voting ledger, and then using the voting weights from the new ledger itself when tallying the votes.
I believe the precondition for accessing the staking ledger hash is network.stakingEpochData.ledger.hash.
You can find a WIP version of the voting ledger circuit here.
I really like the direction of this proposal
But I believe Mina has a unique chance to design a next-generation decentralized treasury that can be smarter, fairer, and more secure than what we see in Ethereum or Solana.
Here are a few suggestions to strengthen the design:
1. Governance fairness
Introduce zk-based private voting to prevent vote buying and manipulation.
Consider quadratic voting or vote-capping with zkProofs, so power is distributed among many holders, not only whales.
2. Security & trust
Use ZK Fraud Proofs so that any member can challenge and prove if a proposal execution is malicious or invalid.
Move beyond traditional multisig: implement a zk-powered emergency mechanism that can halt bad transactions without centralizing control.
3. Smart funding
Instead of one-time grants, funds should be released only when teams prove progress with zk-based milestones (e.g. zkProofs on commits or usage data).
This ensures funds are spent on real results, not just promises.
4. Transparency with lightness
All proposals, votes, and treasury actions should be provable and synced on-chain, in a way that even a mobile client can verify.
This would make Mina’s treasury the most lightweight but trustless DAO in the ecosystem.
If we combine these ideas, Mina could pioneer a treasury that’s not just “another DAO”, but a zk-native governance system that other ecosystems will look up to.
I fully support the long-term vision of a decentralized treasury, but I believe we should not overlook the short-term dynamics that actually drive adoption.
Token price is not only speculation ، it reflects market confidence. A strong price attracts developers, builders, and new community members, while a weak one risks disengagement and stagnation.
That’s why I think the treasury design should consider mechanisms that directly reinforce both stability and growth for example, buybacks, targeted staking incentives, or ecosystem grants tied to real utility. This way, Mina can balance immediate confidence with sustainable progress, sending a clear signal that we are serious about building and thriving.
Just a quick nudge to keep this thread and proposal going.
@maht0rz @acityinohio where are we up to with this ATM?
I’m sure they everyone is aware that Mina is in a very fragile position and without strong leadership and prompt actions it will be too late to do anything meaningful however the decentralised treasury is built.
I’m receiving messages almost everyday from long term Mina holders, node runners and devs who have given up on the project and while i realize the foundation made a committment to build a decentralised treasury I don’t believe Mina currently has the luxury of time in order for this too be anything other than a token gesture.
Please do not let the ego of wanting to look back and say “At least we achieved something”, get in the way of doing something useful with the funds that are left over.
Please also don’t reply with stock answers, I was part of the team giving feedback to the Evan’s decentralised idea two years ago and we’re no closer now.
Anyway apologies for the stern words, watching Mina slowly implode is very disappointing after putting so much effort into it.
@Pete you can check out the implementation progress in this repository. As per the original estimated timeline, we’re currently 1 month into the MVP development, with another 5 months of development left overall. I am quite confident we are actually ahead timeline wise when it comes to the development work. We’ll be releasing an actual demo you can run (with a CLI) in the coming weeks, but in the meantime you can run the test suites as its still early in development (1/6 estimated months).
Thanks for the reply, I’m not doubting that there will be something useable in 5 months.
What I’m worried about @acityinohio is that sentiment is in such a downward trajectory that Mina will essentially cease to exist in a meaningful way in 5 months.
Thoughts?
Hi Pete. As @maht0rz mentioned, we are making progress on the treasury and it will be in a testable state really soon.
Beyond that, we’ve also been talking with Aragon (who have been doing decentralized treasury work and DAOs since they existed as concepts) about providing feedback and support for the treasury deployment — nothing set in stone yet but should be shortly, and I expect they’ll provide some input and discussion here too.
In other positive news, we are actively investigating buybacks to deploy to the treasury and hope to begin that program soon (again, and am bound to say this: all contingent on regulatory discussions but I’m very very optimistic there). Nori is releasing a testnet of their bridge. The next performance-improving hardfork is on the horizon, and the Rust node is progressing thanks to o1. There are improvements coming to the Ledger implementation to allow you to do more than just hold MINA on your hardware wallet. More is coming. It may not all be flashy, but it’s setting up the groundwork for Mina to be in a good position for the future.
But yeah, it’s not all roses; your frustration is shared. I was not expecting Brandon to leave o1 and it took me by surprise. That said I did have a chance to catch up with Nicole and Deepthi — they are dedicated to Mina and very much want to improve the ecosystem writ large and want a culture of focused shipping at o1.
I don’t know what the future holds but all of us at the Mina Foundation are dedicated to doing right by the ecosystem in deploying this treasury, and I know everyone at o1 feels the same way.
Thanks or the reply, I appreciate all the efforts you are doing and understand you’ve not been dealt the best hand in the current situation. All the things you have mentioned are really positive. Excellent!
I know Nicole and she is incredibly professional and conscientious.
In my experience sentiment can be a powerful tool, but an even stronger enemy and in the short term buybacks in some form or another could send the right signals that the Foundation / O1 Labs are attempting to rescue Mina.
So I scrolled a bit as I was away for a few months and just randomly saw this. I want to point out certain things I see as important.
1 Mina = 1 vote shouldn’t be the way. That just causes more centralization of power where it’s already concentrated. About Zkpassport, it can be done with passports and even most ID cards as all use the same standard. The issue was limitation on chain considering all the forks and upgrades coming. It can be utilized but either way even if there is no Zkpassport kind of solution there are many ways to avoid going 1 Mina = 1 Vote and that should be one of the efforts.
We want to use the treasury effectively but the problem is there is no way to know the value of Mina at any given time. That’s why milestone based funding and many other payment methods will not work. If we want to attract builders it either needs to be a stable coin or needs to be an all at once payment. If we try to index to USD by zk then a crash could happen and some big proposal could get a significant percentage of the treasury. If we are not doing that than builders lose outright. When there are so many funding opportunities on the market and builders also need to risk Mina’s price performance for 3 to 9 month time frames no one will spend time on this. We need to remember we also compete in the open market. We can’t attach good enough teams and developers with that structure. Considering how hard it’s to develop on mina I am sure we need them.
Thanks for the thoughtful updates and transparency @acityinohio . It’s encouraging to see concrete steps being taken — from the treasury’s progress and potential Aragon collaboration, to the buyback discussions, Rust node work, upcoming hardfork, and Ledger improvements. These may not be the flashiest headlines, but they’re exactly the kind of foundational efforts that set up long-term sustainability.
Transitions and unexpected departures can be challenging, but it’s reassuring to hear about the commitment from Nicole, Deepthi, and the broader teams at the Foundation and o1. Community sentiment plays a big role, and seeing visible actions like buybacks alongside continued technical improvements will go a long way in reinforcing confidence. Excited to see Mina positioned for long-term strength.