RFC: Mina Decentralized Treasury – Decentralized On‑Chain Community Treasury

[WillCove]

Thanks for clarifying, that makes sense. I realized I’ve been thinking about the treasury slightly differently.

My (unofficial) thinking is that treasury disbursement should live at the organizational level, rather than the individual project level. If projects want to receive grant funding (e.g. Nori), they would go to the core team(s) (o1Labs) in the ecosystem who have grant budgets, rather than the treasury.

Then, o1Labs (or other core teams that might emerge) go to the treasury on a recurring basis to make a case for treasury funding, which the ecosystem of block producers then gives feedback & decides on. This would include an evaluation of the results of the previous funding cycle & the return on that investment.

I agree with @Pete that o1Labs should be the team issuing grants at this stage, but I’m envisioning that process lives within their company balance sheet rather than the treasury. This ensures that they’re bought in on supporting the teams that receive funding, which didn’t happen holistically with zkIgnite or Navigators. We had good input and support on select projects, but it was disconnected and yielded poor results. Because the technical expertise is so concentrated within their org, if a project doesn’t receive full buy-in, it will be unlikely to succeed.

In order for this to work, this would require:
a) o1Labs leadership to confirm that they are going to be running Mina ecosystem grants programs NOW and going forward (this was my understanding after leaving MF 3 months ago)
b) a reasonably high quorum % and high bond % to prevent non-serious proposals
c) at some point, new or spinout core teams w/ technical expertise who can also run grant programs

if we don’t have confidence in the above, then I agree that a council model for project-level grants is the better way to go in the short term.

[garethtdavies]

Interesting. Doesn’t this seem an insanely convoluted way of giving o1Labs funds to distribute via grants? And we need to wait 6-12 months to do this?

[WillCove]

On timing, they should be giving out grants now, not in 6-12 months. I can’t speak to what’s actually happening behind the scenes. Tagging @bkase for reference.

on process, perhaps you’re right… just wanted to share my framing.

[maht0rz]

I’d like to add that in my opinion the decentralized treasury is a project with a long term vision, and i do agree that in the meantime we should figure out a way to keep things in motion until the decentralized treasury is up and running.

I did some thinking about how to approach passing criteria in an effective way given the current on chain activity and setting realistic expectations. What i’d suggest is to apply a curve between proposal amount & treasury balance, and an expected turnout (quorum), something like this:

Proposal size: 0 → TREASURY_BALANCE
Required quorum: 5% → 75%

The curve could be non linear as well.

I think this way we should be able to arrive at a solution that can reasonably and effectively allow for funding to be distributed, while minimizing risks surrounding bad decisions on how the funds are spent.

I am still not very much in favour of adding a council mechanism, it’d add additional layers of complexity, which will make this harder to ship. More complexity = more room for bugs, which we don’t want. I’d actually say that the originally proposed voting delegation mechanism can act in a similiar fashion. We should not forget that even with a council mechanism, we’d have to implement mechanisms for electing the council in a permissionless, token weighted and iterative fashion.

[jim_certhum]

I’m really happy you brought up Polkadot’s OpenGov, because it’s the first thing that came to my mind when reading the RFC.

It really is a model for all of the things that can go wrong (and many that can go right), with a fully on-chain, decentralized model, and I recommend everyone interested in this topic to research the OpenGov implementation that is not aware of it.

Unfortunately, over the years it’s seen many complications, including alliance building behind the scenes - counter to the idea of openess in on-chain governance, and those whom may not have had the best interest of the network (or one that ran counter to the community) being able to push through proposals which had a majority of the community against it. This lead to a large amount of money thrown at sub-standard proposals, and general negative sentiment within the community of OpenGov. Eventually, after a lot of pressure, W3F stepped in and started a delegation program with foundation tokens on an application basis. While this has had a positive impact, it still created an overly political situation, where some delegates wield their voting power in ways that might seem unethical to some.

In fact, this has been a wider criticism of OpenGov. Many of those that have a substantial voting power whether through delegated voting power or their own heavy bags, creating a ‘kiss the ring’ scenario of grant applicants that know they only need to target a few of those voters to give their proposal a good chance of passing. In fact, in many parts of the world receiving a kickback for a vote in this kind of situation would be perfectly acceptable business practice (and even in parts of the world where it isn’t acceptable, of course there are those that don’t care), and so that should be considered as a possible outcome in part of a truly decentralized treasury. I have no doubt that in this model, it will create a big target on Mina for those that want to exploit it, and they can overwhelm the community.

That’s not to say I think it couldn’t work, but maybe in discussing up it front, ways to avoid these pitfalls could be put in place before the occur, learning from the lessons of other chains.

Personally, I think Moonbeam strikes a good balance (full disclosure, I’ve been a community-elected member of the Moonbeam Grants Committee for over 3 years, so of course I would like how they do it), where there are community elected stewards paired up with Foundation members to perform due diligence on applicants, ensure that grantees align with goals of the network including short and long-term objectives, and act as a layer of protection from abuse of the treasury (whether intentional or unintentional). The committee is still accountable to the community and the network, and the community as the final say on the committee make up and the structure of the program, with parts of the program where approval of certain grants do have a final on-chain vote from the community.

[Pete]

Thanks for your comments @jim_certhum it definitely adds another perspective to managing decentration in a fair and transparent way.

I’ll look at the Moonbeam thing, sounds very interesting. I think it’s really important for the perfect not to get in the way of the good and in my experience things can often get buried under the weight of difference perspectives and opinions until finally nothing gets decided.

I’d like to think that everyone is agreeable that in the short term that O1 Labs could devote some time and funds in order to attract interest from high quality dev teams and for projects to get off the ground on Mina asap.

Simultaneously the idea of a decentralized treasury can be fully rounded through a combination of discussions and feasibility in the coming weeks.

We really need to rebuild the momentum that has been lost in the last 6 months or so and reignite excitement among holders otherwise there may be nobody around to use it.

[gregor]

I like the decentralized treasury idea!

To address the concern re concentrating decision making in a few BPs (who might not be qualified or even interested in those decisions), maybe we should move away from 1 MINA = 1 vote, and instead do quadratic voting. This would significantly mitigate the power that big players have, without taking away the concept that more skin in the game gives you more votes.

The main technical hurdle for quadratic voting is that you need some sort of sybil protection / proof of humanity to make it work. I think zkpassport in o1js was fairly close to being delivered, and it wouldn’t be hard to build a reasonable anti-sybil system with that.

Re spam protection, I want to +1 @45930’s initial concern that good-faith proposals should receive back their bonds. Otherwise “risky” proposals that are fairly likely to fail will simply not be proposed, which could filter out good proposals. Just give 3 voting options: Yes, No, Spam.

[maht0rz]

Thanks @gregor! We’ve considered quadratic voting but decided to stick to historical snapshots due to technical complexities you’ve mentioned. Also zkPassport would probably limit the particupants to supported countries (like EU passports?).

We have also considered conviction voting - lock tokens for a time to increase your voting weight. This is also not technically possible with historical snapshots, and locking tokens on chain would require everyone to make their accounts zkApps (at least?).

Rationale behind the original spam prevention mechanism was to nudge proposers to engage in preliminary signaling on e.g. Mina Research. One of the motivations here is to reduce the effort required of the ‘governing body’ to engage with proposals on-chain - make the system easier, and less often required to interact with - get more participation.

My expectation was that the discussion around proposals will actively happen prior to making the proposal on chain - that being said it maybe suggests making the exploration period shorter.

[gregor]

Thanks for your answer @maht0rz!

Also zkPassport would probably limit the particupants to supported countries (like EU passports?).

I don’t think this is a major concern, almost all countries support e-passports: GitHub - zkpassport/circuits: ZKPassport circuits for generating passport and national ID zero-knowledge identity proofs

We’ve considered quadratic voting but decided to stick to historical snapshots due to technical complexities you’ve mentioned.

I get that, it would be too much of a burden to require fancy tech like that in the first iteration.

But IMO a good idea to consider for a later extension. The ability implement a private and fair voting system is one of the core value propositions of Mina, so it’d be ideal dogfooding.

@maht0rz

Rationale behind the original spam prevention mechanism was to nudge proposers to engage in preliminary signaling on e.g. Mina Research. One of the motivations here is to reduce the effort required of the ‘governing body’ to engage with proposals on-chain - make the system easier, and less often required to interact with - get more participation.

I don’t buy this idea of nudging people towards making sure the proposal will pass, even before the voting period. People will engage in preliminary signaling anyway. Otherwise they’ll lose the vote.

IMO, the risk of losing significant money for any proposal that is not already consensus at the time of the vote, makes the whole system dead from the beginning. The danger is that nothing unexpected or controversial will be proposed.

Mina needs to take risks and new directions at this stage. So any form of gate-keeping for good-faith proposals is a bad idea.

[gregor]

@maht0rz btw if you’re going with 1 MINA = 1 vote, I’d be strongly in favor of including the ability to self-override a delegated vote in the initial 6 month roadmap.

This shouldn’t be hard to implement, and it feels much more important to let people vote themselves despite keeping MINA staked, than to implement a more general voting delegation system.

[maht0rz]

What about making the bond’s release subject to reaching quorum (participation) and not subject to approval? that way we can keep “abstain” instead of “spam”, and not showing up to the vote will result in loosing the proposal automatically, so yeah that’d be a passive bond loss, and with your approach it’d have to be pro actively marked as spam. Not sure which one is “better”, need to think about it a bit more i believe.

[maht0rz]

Yep, vote delegation override is part of the plan, it very well may happen that the advanced delegation mechanics will make it to the first version too.

[gregor]

you could have both ‘abstain’ and ‘spam’. ‘spam’ simply counts as a ‘no’ in the tally.

that way you avoid mixing ‘I don’t care about the outcome’ with ‘this is spam and should be punished’. these are very different intentions and shouldn’t be mixed!

[gregor]

proposals get punished if the number of ‘spam’ votes are > 50% (or a different threshold)

[maht0rz]

I find the idea of having to ‘send a tx’ just to mark someone as spam feels more complicated than letting people ignore the proposal in order for it to loose the bond. Once we make you loose the proposal only if you BOTH dont pass participation AND approval thresholds then if you find the proposal ‘not spam’ but still want to abstain but not make them loose the deposit, then you can vote abstain. Change from the original could be you keep the bond if you met participation, but did not get an approval (thus abstain makes sense)

so the interaction pyramid is like:

1. vote yes/no
2. vote abstain → not a vote, but prevents loosing the deposit so kinda like ‘mark as not spam’
3. ignore → make them loose the deposit

but the version you propose could make sense too, just trying to strike balance between invariants and making sure we can ship a secure version to production in a reasonable timeframe

EDIT: just to add, the idea i’m proposing here keeps the scenario of loosing the bond the easiest, defacto the default behavior. But i hear your concerns about proposers being afraid to propose, in a case the system is not as active as we hope it’ll be

[acityinohio]

Really glad to see all of this discussion here, and appreciate the thoughtfulness of the comments and participants. Thanks for kicking it off @maht0rz!

Just wanted to add my 2 cents here — I’m also not in favor of an explicit council model (particularly when the voting delegation model can effectively emulate one writ large if the voting stake goes to individuals). In terms of increasing participation, I think there may also be some clever incentives we could leverage to increase voting participation, but they may be beyond the scope of this effort (and likely are extremely gameable without thorough consideration).

In general, with my Mina Foundation Interim CEO hat on: I also wanted to reiterate that deploying this is the primary, enduring focus of a significantly scaled-down Mina Foundation. We’ve promised to deliver on a decentralized treasury for many years, and (IMHO) we over-prioritized the theoretical components of what a perfect version of this would look like at the expense of actually shipping something that gives MINA users in the ecosystem a more directed voice in directing funding. Frankly, it’s regrettable something couldn’t have shipped when the community was more active.

But while we can’t change those decisions in the past, we can at least commit to fixing things now. And while @maht0rz or myself won’t be able to address every concern, I know @maht0rz will do his best to incorporate constructive feedback into the design as long as it doesn’t jeopardize the timeline. It’s unlikely to make everyone happy, but I’d rather have something deployed as a basis that can be improved upon rather than waiting another ~4 years for something perfect.

[gregor]

@maht0rz

so the interaction pyramid is like:

1. vote yes/no
2. vote abstain → not a vote, but prevents loosing the deposit so kinda like ‘mark as not spam’
3. ignore → make them loose the deposit

but the version you propose could make sense too, just trying to strike balance between invariants and making sure we can ship a secure version to production in a reasonable timeframe

EDIT: just to add, the idea i’m proposing here keeps the scenario of loosing the bond the easiest, defacto the default behavior. But i hear your concerns about proposers being afraid to propose, in a case the system is not as active as we hope it’ll be

yeah so it comes down to what we want the “default” to be, in case no one interacts with a proposal: reject and punish, or only reject.

it might be worth enumerating the potential risks we’re trying to address here, and think about how they are affected by a “punish-by-default” policy:

• Risk: Many spam-like proposals, that try to obtain small amounts of MINA from the treasury, put a strain on voting representatives, who have to actively send txs to prevent them.
  @maht0rz I guess this is what your last proposal tries to avoid. I don’t think it’s a actual risk though, in both of our proposal, because just the threat of losing the bond is already enough to avert spam. It would just be stupid to burn 10% of the potential reward to spam a chain, I think the “economics of spam” only works if the potential reward is much larger than 10x of the cost.
  • To mitigate this better I propose that there should be a minimum bond size. On the order of a few 1000 MINA. So the bond size is e.g. max(1000, 0.1*amount).
  • With that change, I’m confident that in my proposal, the bond threat itself is enough to prevent frequent spam. So people will not actually have to send txs to prevent it.
• Risk: Malicious, well-funded proposals that represent serious attacks on the treasury.
  This one is different than small-scale spam, because whoever decides to target a very large reward and is willing to bond 10% of it, will also accumulate significant amounts of MINA to be able to influence the vote. So for this scenario, “doing nothing” as in your proposal is not a sufficient community response, people actually have to step in and vote no, in both of our proposals.
• Risk: Interesting proposals are scared away by the danger to lose bonds.
  As I said before, I think this is a real risk present in your proposal (but not in mine because it’s not the default). The possibility of having people vote “abstain” makes it slightly better, but not much: People who are not in favor, but acknowledge that the proposal is good faith, are forced to pick between “no” (expressing their preference) and “abstain” (mark as not spam). It’s not clear that they will choose abstain. In my proposal, people are not forced to make that pick, a “no” vote doesn’t imply that it’s spam.

[garethtdavies]

@maht0rz

it very well may happen that the advanced delegation mechanics will make it to the first version too.

Can you clarify what those are? If it is a seperate delegated vote then that seems close to ideal as essentially an on-chain elected council.

[maht0rz]

@maht0rz

Voting Delegate Override – An account with voting delegate overrides staking delegation.

@garethtdavies this section of the RFC outlines that there should be a way to override the staking delegation with a custom voting delegate, as you say essentially enabling a council like model but with no built in council mechanics. Also this feature is listed under ‘advanced features’ in the roadmap — that’s why i’ve mentioned we might prioritize it into an earlier version too, since based on preliminary feedback (including yours) it seems more important than we originally envisioned.

[abs]

I could see it as a project that but yeah I like the path of that .about . Voting Rules