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

[maht0rz]

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

---

The Mina Foundation has been working on a new Decentralized Treasury for funding Mina ecosystem development and projects, which will be fully on-chain and controlled by the Mina community.

This is the first phase of the development and deployment process - the Request for Comments (RFC) on the proposal. From Aug 1 - Aug 31, 2025, community members are invited to review, provide feedback, and ask questions about the Decentralized Treasury proposal in the comments of this thread or on Mina’s Discord.

Abstract

This RFC specifies the design, governance model, security mechanisms and rollout strategy for the Mina Decentralized Treasury – a fully on‑chain treasury owned and controlled by the Mina community. The treasury is implemented as a set of upgradable, permissionless Mina zkApps providing a trust-minimised mechanism to utilize and distribute funds for the advancement of the Mina ecosystem. All proposal handling, voting, execution and accounting is done in a provable manner, in accordance with the zkApps protocol.

Motivation

The Mina ecosystem requires a transparent, censorship‑resistant and trust‑minimised mechanism for managing community funds. Moving the treasury on‑chain eliminates single‑party custodianship, enables token‑weighted community governance, and provides verifiable execution of treasury decisions without a protocol‑level hard‑fork. Successful implementation of this RFC would significantly increase transparency in the funding decision making process within the ecosystem.

Mina Foundation plans to commit a significant amount of funds from its community and grants budget towards the Mina Decentralized Treasury.

Conceptual overview

• The treasury has to be able to distribute $MINA tokens.

• We should aim for the treasury to be fully “on-chain” or provable, thus not having any processes which cannot be programmatically enforced.

• Mina’s protocol works with an account ledger, which is a Merkle tree of accounts, where each account has a balance and a delegate; this can be used to determine the voting power of each account.

• Consensus / staking works with epoch-based snapshots. While the ledger itself is merkelized, root hash of the ledger is available for current or past epochs.

• Given we want to use the $MINA balance as the voting weight, we need to prevent double spending of the voting power.

• In order to achieve higher voting participation, we should make use of delegated governance, e.g. by using staking delegation as voting delegation, unless overridden by the delegator. At the same time, there should be minimal to no technical barrier to enter the system as a proposer or a voter.

• Since treasury funds should be fully held by the treasury zkApps it affects the design of the Mina Foundation delegation program.

• Any infrastructure associated with the Mina Decentralized Treasury should be permissionless and self-hostable, in order to allow for open community participation.

• Technical implementation must be focused on security and auditability.

Members of the Mina ecosystem seeking funding for their work, either future or retrospective, should create proposals to spend treasury funds. Remaining members of the ecosystem should thoughtfully evaluate the proposal and vote either for or against the proposal, granting or denying funding.

Proposal System

Mina Decentralized Treasury is designed around proposals, which are voted on by the Mina token holders. Once a proposal has been passed, it can be executed – for example funds being withdrawn from the treasury.

Proposal Types

The following proposal types should be supported by the treasury:

• Treasury Spend – Transfer of MINA or custom tokens from the treasury to a recipient account.

• Treasury Upgrade (Optional) – Change of verification keys (code upgrade) for one or more treasury zkApps.

Proposal contents

Each on‑chain proposal must include a URI pointing to a Markdown text (e.g., GitHub Gist, HackMD). The treasury contracts do not host proposal contents, instead they hold a reference (e.g. URL, hash, or else).

Lifecycle Periods

In order to ensure fair voting and consideration for all proposals, a lifecycle mechanism can be put into place. Either the whole treasury as a whole, or individual proposals go through the following stages:

1. Proposal Period – New proposals accepted.

2. Exploration Period – Community discussion, no voting.

3. Voting Period – Votes recorded on‑chain.

4. Cooldown Period – Votes can be tallied, but proposals can’t be executed yet. Timelock in place allowing the break‑glass key to intervene.

5. Post Cooldown Period – Proposals can be executed, if they have passed and break-glass did not intervene during the cooldown period.

Periods may be globally synchronised or per‑proposal, subject to configuration. Lifecycle periods help anchor the period or individual proposals to their respective historical ledger snapshot, in order to determine voting weights.

Spam Prevention

A proposer must lock a bond equal to a configurable percentage of the proposal value (e.g., 10 %). Bonds are returned if the proposal passes; otherwise they are burned or frozen. This measure prevents treasury abuse, as in acting as a signal or a preliminary filter to concentrate attention of voters.

Governance Model

To ensure the highest stake participation possible, the treasury employs voting power delegation mechanisms, following the already established delegated proof of stake model of the consensus. This allows the treasury to accommodate votes from individuals looking to participate directly, and also from token holders willing to delegate their decision making power to a delegate.

Voting weights

To calculate voting weights and prevent multiple counts of the same stake, the system uses an epoch‑based historical snapshot of the account ledger. Nullifier commitments ensure an account’s balance is applied to at most one proposal outcome.

Voting Rules

• Direct Vote – An account without a staking delegate casts its own vote.

• Staking‑Delegate Vote – If an account has a staking delegate and no voting delegate, the staking delegate votes on its behalf.

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

• Self‑Override – Setting the voting delegate to self allows direct voting even when staked elsewhere.

Vote Types

• Yay – Support the proposal. Counts toward passing the proposal and enabling execution if quorum and majority are met.

• Nay – Oppose the proposal. Counts against passing the proposal and helps prevent execution.

• Abstain – Neutral stance. Does not affect the outcome but counts toward quorum participation.

Note: Concrete vote type naming is subject to further discussion

Passing Criteria (Configurable)

• Quorum: ≥ 50 % of total eligible supply at snapshot.

• Majority: ≥ 60 % (or parameterised, e.g., 75 %) of votes cast in favour.

In order to prevent the treasury from “deadlocking” itself, as in not being able to pass a proposal due to low participation, a dynamic/moving quorum can be considered for implementation.

Note: Passing criteria are subject to further research.

Double‑Spend Resistance

Nullifiers combined with ledger snapshots prevent an account balance from contributing voting power more than once per proposal.

Safety Mechanisms

In order to ensure a smooth transition towards a community owned Mina Decentralized Treasury, the following mechanisms can be put in place to prevent malicious participants from exploiting the treasury:

• Break‑Glass Multisig – Temporarily able to halt execution during the cooldown period.

• Upgradable Contracts – Allow critical bug fixes.

• Progressive Fund Migration – Funds transferred in tranches, reducing blast radius of potential issues.

Break-Glass Multisig

The break glass mechanism is a safety feature to allow for intervention in case of a bug or exploit in the treasury zkApps. Specifics of how the mechanism works are subject to further discussion. In a simplest form it could be a multisig of trusted ecosystem participants.

This mechanism could for example prevent a proposal from being executed (paid out) if it’s deemed to be malicious, harmful or a result of an exploit of the treasury zkApps.

Eventually thanks to the treasury upgradability, the break glass mechanism can be removed, and the treasury can be fully owned by the community.

Additionally, the break-glass mechanism can be used by the governing entity behind the treasury to ensure the treasury operations remain aligned with relevant legal and regulatory frameworks. However, any such use would require clearly defined scope and transparency guarantees, consistent with the intended governance processes.

Foundation Delegation Program

To maintain the shape and form of the existing delegation program, treasury funds may be split across multiple sub‑treasuries, each delegating to distinct block producers while remaining governed by the same on‑chain rules.

Technical Details

Staking Ledger

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 we are to enforce quorum/majority requirements, we also need to sum up the total circulating supply in any given ledger snapshot (unless explicitly exposed by the protocol itself).

JIT Vote Tallying

We could implement the zkapp/circuits in a way which does not require voters to do any heavy lifting proving wise, they could be just ‘dispatching actions’ with signatures authorizing their vote, instead of having to compute their voting power at the time of the vote. Similarly the UI could be optimistically (out of the prover) computing vote results on the fly, until the votes are tallied (actions are rolled up) at a later stage.

Security Considerations & Risks

• Bonds mitigate, but do not eliminate, griefing attacks; parameters should be reviewed post‑MVP.

• Break‑glass authority introduces centralisation risk and should be sunset as planned.

• Low participation may create a governance deadlock where quorum is not met and no proposals are able to pass. In order to mitigate this risk, dynamic moving quorum may be implemented as part of the treasury design.

Audit plan

Before the treasury can be rolled out, a comprehensive independent multi-party audit needs to be conducted. Additionally extensive community testing should be concluded on devnet. Both of these measures combined should minimise the risk of technical issues or bugs occurring in production post-rollout. Audit is planned to be executed in two phases, in alignment with the development phases for MVP & advanced features. This enables earlier minimalistic mainnet rollout, before development of all features is completed.

Rollout Plan

First mainnet deployment of the Mina Decentralized Treasury is planned post-audit, after devnet testing has been completed and no breaking bugs were identified. The amount of funds rolled out to the decentralized treasury at various stages is subject to Mina Foundation’s discretion and policies, and shall be subject to ongoing assessment based on project’s progress.

Protocol Compatibility

The design relies solely on the existing Mina zkApp protocol and requires no hard‑fork.

Timeline

Phase	Indicative Schedule*	Focus
RFC	Month 1	Publish specification; gather stakeholder feedback.
MVP	Months 2‑4	Implement core treasury zkApps & UI; public devnet demo.
Safety & Performance	Months 5‑6	Add spam bonds, break‑glass, prover parallelisation, basic upgradability.
Audit	Months 7‑8	Comprehensive external audit; address findings.
Rollout	Month 9	Initial mainnet deployment with limited funds. Requires complete audit.
Advanced Features	Months 10‑11	Multiple BP delegation, voting delegation, upgrade framework.
Decentralisation	Ongoing post‑Month 11	Remove break‑glass; migrate remaining Foundation funds.
Improvements	Continuous	Bug fixes and performance enhancements.

Note: Every tangible development update will be reflected on devnet as soon as possible, in order to shorten the community feedback & testing lifecycle

Legal Considerations

Mina Foundation will collaborate with relevant regulatory authorities and advisors as appropriate to ensure compliance with applicable law and regulations.

[cottoncity]

very goood determination

[45930]

Nice proposal Matej! I like the basic structure of it, and left some questions about individual details below!

@maht0rz

In order to achieve higher voting participation, we should make use of delegated governance, e.g. by using staking delegation as voting delegation

I see the appeal of this, but it also gives BPs who have been around forever outsized influence. Were any alternatives considered? For instance, what if an account has to opt into their stake being delegated explicitly for the purpose of this decentralized treasury governance? We could also fiddle with the quorum threshold to be require less participation if we ensure the participation is legitimate.

@maht0rz

A proposer must lock a bond equal to a configurable percentage of the proposal value (e.g., 10 %). Bonds are returned if the proposal passes; otherwise they are burned or frozen.

Could we make the vote 2 separate things: Y/N approval of spending and Y/N this proposal was made in good faith? A failing proposal that was made in good faith can get their bond back. I think it’s reasonable to expect a proposer to read the process and put together a proposal that has all the required info. Failure to show that kind of basic attention to detail should be considered spam and lose the bond. But a proposal that is well structured and made in good faith, that’s simply determined to be not valuable at this time should receive their bond back IMO.

@maht0rz

Treasury Spend – Transfer of MINA or custom tokens from the treasury to a recipient account.

Will the only operation mode be complete payment upfront? Milestone evaluation seems tricky with a decentralized organization, but it also seems very risky to just prepay large payments. Could payments be made monthly by default, but allow for the break-glass multisig to stop payments and put the contract on pause? It could enter a challenge state where there is a new proposal to stop funding of the previous proposal. If that proposal fails, the original project could get the bond and the back payment that they lost out on, and if it passes, the original proposal is set to “did not deliver”. Just spit-balling here!

[maht0rz]

Thanks Coby, glad you like it!

I see the appeal of this, but it also gives BPs who have been around forever outsized influence. Were any alternatives considered?

Plan is to eventually implement a standalone voting delegation. Don’t think outsized influence is a concern with being around for a long time as a delegate, these stats seem to confirm that the stake distribution is pretty good: Minascan Block Explorer

Could we make the vote 2 separate things: Y/N approval of spending and Y/N this proposal was made in good faith?

Goal for the bond mechanism is to nudge proposers to engage in community signaling before making an actual proposal, this can be done in multiple ways, e.g. discord or github discussions. Ultimately we want to narrow the focus of voters, since we want to increase participation, the thought was the proposals should be as high quality as possible - bond is one way to push things in this direction.

Will the only operation mode be complete payment upfront? Milestone evaluation seems tricky with a decentralized organization, but it also seems very risky to just prepay large payments.

If a proposer is after a large payment, its up to the community to determine if the risk is justified. The easiest proposal is for retrospective funding - requires the proposer to have some skin in the game and put in the work before requesting funding.

We want to keep things streamlined on purpose, not to over-encumber anyone participating in treasury governance.

Hope i’ve addressed all your questions, thanks again for taking your time to read & comment.

[garethtdavies]

I like the dogfooding of zkApps for this purpose, but I could see it as a project that will take a long time to implement (and even then contains a multisig component).

The suggested quorums are not feasible, not least as a huge amount of MINA currently sits on centralized exchanges (not shown in your prior link). The current epoch Nakamoto coefficient is just 7 (>50% of all stake is in these 7 addresses), so it is not well distributed. The top 2 addresses contain ~250 million MINA and not currently active in block production.

I don’t like the delegated voting approach for this purpose. Previous zkApp funding rounds had multiple members reviewing proposals. This could be far too burdensome for block producers to review all proposals, as it may not be a skill they necessarily have (not to mention any centralization concerns). I’d suggest direct voting with a much lower quorum.

[maht0rz]

I’m of the opinion that a moving quorum is the way to go, since having a super low quorum would simply open up a governance attack vector. But you’re right, if we go with an unfeasable quorum criteria, and the engagement is low, we won’t be able to pass any proposals as a community. I will try to analyze how much stake is ‘active’ and propose what a reasonable quorum or quorum range could be. Would appreciate all the help we can get to determine the right initial criteria.

What if quorum would not be counted against the circulating/total supply, but instead against stake active in the epochs staking ledger (active as in producing blocks?). Need to think if there’s a way to programatically determine who is producing blocks just by observing the staking ledger. Keeping in mind this needs to be provable as well. Summoning @mrmr1993 who might know more

[garethtdavies]

But any address in the ledger could produce blocks i.e. become active, particularly in the context of an attack, so I don’t think that’s feasible. I did some research as part of MIP1 to calculate active stake ref MIPs/MIPS/mip-0001-remove-supercharged-rewards.md at e655ea8ae37433e11a6061c7858f10ba78a8a87e · MinaProtocol/MIPs · GitHub where it was in the low 80s% but would be much lower now (I’ll run the numbers for a recent epoch).

I think the realistic quorum number depends significantly on whether we are delegating voting or not. As above, I don’t believe this is a good idea for block producers to be responsible for this.

Edit, for epoch 27 (last completed one), I get 858,389,365 MINA was active out of 1,239,044,144, so 69%.

[maht0rz]

I think the following options are possible, but not necessarily all of them are viable:

Note: We have to keep in mind all the invariants of the systems below, such as accounts that are not delegated should be able to vote on their own.

Direct voting by $MINA holders, no delegation
Allows anyone to vote directly, but would make it near impossible to achieve reasonable participation that would reflect the majority stake opinion. Since you’d have to get quite a lot of accounts to vote, this would also congest the network and is pretty much operationally infeasible in my opinion.

Delegating $MINA voting power, by mimicking consensus/staking delegation
Building on top of the rationale from the first option, trying to gather more stake / voting weight. Easiest way to achieve this is by re-using the staking delegations since they are already in place. Chains such as Tezos use this model for protocol upgrades themselves. I believe this option to be the most operationally feasible while achieving the highest stake participation possible - therefore trully reflecting majority opinion. If you’re not aligned with how your delegate is voting, you are free to redelegate. This has the potential to kickstart a lively governance & delegation environment.

Delegating $MINA voting power, by choosing a voting delegate
If we choose to omit the staking delegation entirely, we’re left with a system where you either vote on your own or choose a voting delegate. This would again require activation of large amounts of accounts to participate in voting – potentially opening attack vectors due to inherently low participation.

Combining all of the above
The system we propose is a combination of the above, where the baseline for voting weight are staking delegations, with the possibility for a voting delegation override. If you set the voting delegate to your own address, you can vote yourself.

Note: Voting delegation is part of the advanced features, and may be implemented in a separate stage from the initial rollout as shown in the timeline.

We have to carefully evaluate the options above especially in the context of setting the initial passing criteria – the analysis of active BP stake provided by @garethtdavies is going to be really important.

When it comes to BP expertise and voting, the expectation is not that they’d be experts themselves, but that they’d follow the discussion around the proposal and vote based on their subsequent opinion.

Question now is, how do we balance out operational/implementation feasibility with ensuring the setup is truly representative of majority stake opinion? Keeping in mind that distributing funds from the treasury affects all the token holders equally, both beneficially and risk wise – therefore it’s my opinion we should not try to build a system where a narrow subset of the stake has all the decision power.

Electing a council for the treasury
One solution that comes to my mind, which would address the concerns you’ve raised around even BPs themselves not having sufficient resources, time or expertise to consider voting on proposals. Would be to put a council vote in place. Individuals could run for council, there could be e.g. 9 seats with a 3 month term (just ballpark figures right now really). And then this subset of accounts known as the council, which would be elected by the stake majority (same principle as used for proposals in the original system), would be responsible for voting on individual proposals in the given council lifespan.

Note: Adding a council inherently increases complexity of the solution and it’s not something i’ve accounted for in the estimates too. Council could always be added in the next iteration of the decentralized treasury upgrade at a later stage.

Edit: After further deliberation, i think the council model would increase centralisation risk and potentially introduce gatekeeping or other concerns, as saw in the Polkadot ecosystem which pioneered the council approach.

Ultimately what this comes down to is how often and how much of the stake can we activate in order to represent the majority opinion. Designing a system that narrows down interaction points, while allowing individuals to permissionlessly participate directly if they want to is in my opinion the most transparent and fair way to do this.

[garethtdavies]

The council model is essentially getting back to the existing model with zkIgnite. Indeed, that seems objectively superior to this solution, not least as there was some accountability for the funds via milestone deliverables.

A funding council appointed via on-chain governance, but with that council managing the funds (via multisig) seems a decent compromise.

[Pete]

Thanks @maht0rz for the hard work that has gone into this. It’s a really hard problem to solve and in some ways it looks to solve the ultimate question of ‘what is democracy‘?

My own personal opinion about this proposal is that it there was a more active community some of the options suggested would be more attractive.

If participation is expected to be low then essentially we will still have a small percentage of the community actively making the decisions, except they will mainly be staking providers who (as mentioned) might not have the skills, time, interest to research proposals or the impartiality to judge on them.

At least with a council as @garethtdavies suggested there could be a chance to ignite debate and greater interest in decision making, which in turn could ultimately lead to greater participation and further decentralisation at a more advanced stage.

[maht0rz]

I actually think the council model is not superior to actual decentralized governance, even with delegated voting power. Polkadot’s governance is a good example of what adverse effects the council model may have, they’ve also moved towards a council-less model.

Having reasonable participation is still a major concern, we could introduce quorum/approval curves based on the amount of $MINA requested, requiring lower participation for smaller proposals. Or if we trully anticipate the turnout to be so low, perhaps setting the initial quorum to be like ~20% and then applying moving quorum in a range of 20-60% could be a good way to go.

[KiarraManaudou]

The initial quorum can always be set low and then raised to an optimal level based on statistics.
I’m afraid it will take a long time to implement this idea. A year or more is too long.
Don’t you think need to move in short and quick steps?

[maht0rz]

It’s estimated to take around 5-6 months to implement, with the remaining time being spent on audits & testing. Do you have any suggestions on how to get this out to mainnet faster without compromising safety & security? The multi-party audit itself will take 2-3 months.

[Pete]

Have been thinking about this last few days and ultimately if there is going to be low participation then why do we even need it at this moment in time?

Obviously a decentralized treasury is great but what problem is it solving when actually the elephant in the room is that there is no real utility on Mina atm.

Maybe it’s better to do this when there is more in chain activity?

What about for now the BD team at o1 put forward proposals themselves on what they think should be built for Mina and let teams submit proposals. They should know better than anyone what’s needed.

It’s not the perfect solution but from listening to the (very frustrated) Mina Community on a daily basis they just want collaborations and products that can be used.

I would be happy to see @maht0rz carry on with protokit and come back to this later when it is relevant.

[Flyerin]

You should be able to vote independently of each account's delegation. And provide an easy mechanism for voting even without having to stop delegated staking

[Jays]

I think the decentralized treasury proposal is well thought-out. It adds transparency, puts funding decisions in the hands of the community, and uses zkApps for provable and automated execution. The mechanisms like spam bonds, cooldowns, audits, and progressive fund migration are reassuring.

That said, there are still some key concerns:

• Voter participation: a 50% quorum might be too high and risks blocking decisions.

• Whale influence: without strong delegation usage, voting power could become too concentrated.

• Break-glass multisig: useful for safety early on, but it needs a clear path to removal.

• Accessibility: we’ll need simple guides and UI/UX to ensure everyone can participate.

I also think Pete raises a valid point: while a decentralized treasury is critical long-term, the bigger issue today is the lack of real utility and on-chain activity. The community seems to be asking more for products, collaborations, and things they can actually use before complex governance structures.

Maybe a phased approach would work better: in the short term, the o1 BD team and core contributors could proactively propose and fund key initiatives, while builders deliver tangible value. Then, once on-chain activity grows and engagement is higher, the treasury can be rolled out fully for maximum impact.

In short: I support the treasury proposal and its design, but I believe our immediate priority should be driving ecosystem utility and adoption, so that when governance is fully decentralized, it’s both relevant and effective.

[WillCove]

@Pete At this point, I think a decentralized treasury is the best tool for incentivizing the activity everyone wants. The Foundation isn’t capable of driving this forward any longer, and on-chain activity isn’t going to arrive out of thin air. Since the token launch, o1Labs was funded through foundation contracts, and this is an important transparent mechanism for Mina holders to decide on that process going forward. It’s both an accountability mechanism for the core teams, and an incentive mechanism for new teams to participate without pre-existing relationships.

[WillCove]

Thanks @maht0rz for all of your efforts on this, and @garethtdavies for the comments.

Given the huge changes across the Mina ecosystem in the last 6 months, I’m supportive of the council-less model and spending the time upfront to decentralize the process as much as possible.

@garethtdavies to address your point regarding funding tied to delivery milestones in zkIgnite, an alternative solution would be to encourage new proposers to break their projects down into smaller chunks, and increase those chunks when (or if) their reputation increases with successful delivery.

The challenges with a council approving milestones were:

a) it got fuzzy when projects adjusted their milestones halfway through after learning new information (we had an approval process for changes, but still…)

b) technical expertise varied across the council (people ended up informally delegating their decisions to the same 1-2-3 people who were the most technical)

c) in some cases, projects aimed to fulfil their milestones even when their ‘value thesis’ changed. for example, they learned new info but decided to keep on the same track because they wanted to be paid

for those reasons, having a one-off payment system that’s heavily weighted towards reputation & repeat projects feels like the best approach for ensuring delivery.

Edit:

I also fully agree that the quorum levels need to be researched further, and I’m in support of bonds to prevent spam proposals.

[garethtdavies]

All good points, but my concerns were more rooted in the proposed delegated voting, and putting the onos on the block producers - any council is essentially a way to do this to at least a group of motivated and knowledgeable individuals.

[Pete]

Thank for the comments. I do understand the thoughts and reasons behind it and if circumstances were different i think it would be amazing. My only hesitation is the time and resources that are going to be burned on it, when it could be spent on more pressing matters.

The issue we have is that the holders (it’s hard to even say community ATM) are so disappointed with the way Mina has progressed that i think to many of them out will just feel like rearranging the deck chairs on the Titanic. IMO What they really want is things they can use Mina for.

Even if it is done quickly and takes 6 month the decision making process will still be made by people who may not be qualified to decide, may not be interested / don’t have the time in researching the proposals or won’t vote for anything that might be good for Mina but bad for them. It will only be useful if people are engaged with Mina in a meaningful way.

There are probably several key projects that are needed now to help the next wave of builders that could be put out to tender. Who is better placed to know what these are than O1 Labs? This is what non web3 businesses do successfully everyday. There’s no reason why a mixed panel couldn’t use something like zkVot to choose who to award the grant to.

This is also great optics and a smart marketing angle for O1 to say, ‘we’re in charge and we’re doing x, y and z’. Rather than ‘if you wait 6 months we’ll let you decide’.

Get these built and go from there. IMO pragmatism beats idealism in this situation.

https://x.com/minacryptocom/status/1952295255547756897?t=Wd0ACOChwgUSyX1uoBMwww&s=19