Idea: Mina Improvement Proposal process

The intention of this post is to introduce the idea of Mina Improvement Proposals by sketching out a draft MIP process.


  • Promote high quality feature proposals for Mina Protocol and a robust process for validating and deciding upon protocol changes
  • Encourage speed and fluidity in the process (allow Mina to iterate quickly as a protocol generally)
  • Transparent, high participation, decentralised decision making
  • Leverage the good work done by other projects


  • Further decentralisation of the Mina ecosystem
  • Empower the community to participate and reach decisions on changes to the protocol in a way that is accessible and inclusive for all members

What next?

  • Seeking review and feedback here on MinaResearch from ecosystem participants, community and interested parties
  • Adapt and iterate based on participant feedback
  • Poll the community to assess sentiment on the process and to gather further feedback
  • Test in beta mode by running a series of decisions through the process in advance of the next hard fork.

Some ideas for providing feedback:

  • As a potential author, do you believe this is an open and transparent process? If not, what aspects need to be more clear?
  • As a community member, do you believe this process is inclusive and encourages broad participation? If not, what are the barriers to participation?
  • Do you believe any other docs, resources or tools are required for the process to run fluidly?
  • Do you have any other comments or questions?

Mina Improvement Proposals

What is a MIP?

MIP stands for Mina Improvement Proposal. An MIP is a design document providing information to the Mina community, or describing a new feature for Mina or changes to the parameters of the protocol. The MIP should provide a concise technical specification of the feature and a rationale for its inclusion in the protocol. The MIP author is responsible for championing their proposal, building consensus within the community and incorporate feedback.

MIP Rationale

The Mina Foundation intends MIPs to be the primary mechanism for proposing new features, collecting community input on an issue, and for documenting design decisions that have gone into Mina. It is intended to be a highly participatory and transparent process for complex decision making on changes to the Mina Protocol. In the long term, the vision for Mina is for more decentralized decision making, and during every iteration, we will work towards that goal.

The MIP Process

This document is not intended to be the end state process for MIPs, but rather servers as a draft proposal to encourage discussion and feedback from community and all stakeholders. The process will be evaluated and adapted on a regular basis, based on participant feedback and robustly testing in beta mode by running a series of decisions through the process.

The process described here is inspired by the long track record in this area by other projects, particularly Ethereum.

Types of MIP

A Standards Track MIP describes any change that affects most or all Mina protocol, such as a change to the network protocol, a change in consensus or block validity rules, to the zero-knowledge cryptography or any change in the accounts or rules around MINA. Standards Track MIPs, as well as serving as the design document, should include a reference implementation where appropriate.

Process discuss requirement for this type

Meta discuss requirement for this type

MIP format and structure

Template and Github repo for the beta version of MIP to be created once the ‘Idea’ has been vetted

MIP Process

Idea - The MIP is put forward by the author(s) for community discussion and sentiment gathering on Mina Research and via Polling e.g., ( The MIP is not tracked within the MIP repository.

Draft - The MIP has been formally drafted and submitted to the Github repository. The MIP is checked by the MIP Editors for compliance and is merged when it has been validated.

Review - Dev Teams, Community and Advisory Group provide feedback on the MIP

Last call This is the final review window for an MIP before moving to Finalization. The MIP Editors will assign Last Call status and set a review end date, typically 2 weeks later.

If this period results in the identification of high impact issues the MIP will be moved back to Review.

Finalization The proposal is deemed to have met all the appropriate criterias consensus to be considered and the Dev Teams are in a position to incorporate the changes into the implementation schedule

Inactive A MIP that has been deemed to be inactive for a period of 1 month.

Withdrawn - The MIP Author(s) have withdrawn the proposed MIP. The proposal can no longer be resurrected using this MIP number. If the idea is pursued at later date it is considered a new proposal.

MIP Workflow

How to create a MIP

1. Submit a MIP Idea to MinaResearch

If you have an idea you would like to propose, first search through previously proposed or discussed ideas in this MinaResearch. If your idea is original or sufficiently distinct, start a new conversation thread to enable a discussion with the community on MinaResearch (see guidelines here). You should seek feedback and try to build informal consensus, as well as keep track of any critical feedback so that you can address it later.

For complex decisions, it is recommended that the Author start with gathering criteria and information from the community for complicated solutions. The Author is encouraged to poll the community at this point for the criteria that a good solution/proposal would fulfil, or to gather sentiment for the idea generally.

2. Create a Draft MIP and submit it to the MIP repository

Once you’ve allowed enough time for feedback and a properly formatted (see below section) draft MIP has been written, it should be submitted to the MIPs GitHub repository as a pull request, accompanied by a summary of the discussion so far in the comment section, with links where possible.

A member of the MIP Working Group will assign a MIP number, select the appropriate MIP type (Standards, Informational, or Meta and begin the validation process)

3. Wait for approval and/or feedback from the MIP Editors

A MIP editor will assign a MIP number, select the appropriate MIP type and merge the pull request if the conditions have been met. Otherwise, the Author will receive a written notification and reasons why their draft was not merged.



Responsible for vetting the idea, gathering sentiment, writing the MIP, championing MIP through process, gathering and incorporating community feedback including alternative and dissenting views. Multiple authors can contribute to one MIP, but one person must be identified to submit and edit it.

MIP Editors

The MIP Editors are here to ensure the MIP is complaint to the process at all times and that process is fluid and there is progression of MIPs through the process . If you have questions regarding the MIP process, they can point you in the right direction.

Dev Teams

The team responsible for checking technical specifications and implementing the MIP once finalized.

Advisory Group

A group comprised of subject matter experts representative of impacted developers and community members. It is important that impacted stakeholders for a particular MIP are identified and included in the process. This is not a fixed group and impacted participants may vary for each MIP.

What belongs in a successful MIP?


MIP Formats and Templates

MIPs should be written in markdown format. There is a template to follow <TO BE UPDATED)

MIP Header Preamble



lots to absorb, many thanks for posting Brian. quick question… Is there a bigger sized image of the MIP process? hard to read this one…


Had to read it three times to fully understand it :slight_smile:
Really, looks TOTALLY great, love to see things going this way.


Good point, higher resolution image attached now

1 Like

Many thanks for posting this Brian, I had to read it at least 4 times! :grinning:

I would be very interested to get your thoughts on how to define ‘final consensus’ for ideas to be implemented eg, with a community vote or a vote by the Advisory group (or both) and also who would be eligible to be included in these votes.


Interesting ideas :slight_smile:

Also, typo in “The MIP Process”:
“rahter” vs “rather” :slight_smile:


Hey everyone. I created this poll to gather sentiment and feedback on where the community’s thoughts are on the MIP process!


Hey @Pete - so the ‘Review’ stage should generally result in a “rough consensus” between devs, community and advisory group on whether the MIP should be implemented. This “rough consensus” rests on the assumptions the MIP is not contentious enough be a threat to the network and that is technically sound. As regards voting, the author is encouraged to poll the community regularly (it would be cool in future to research some more advanced voting like delegative voting and quadratic voting and these type of things).