The Midnight Improvement Proposal Process

Problem statements and proposals

The repository holds two kinds of documents.

A Midnight Problem Statement (MPS) is a solution-agnostic description of friction, a gap, or an opportunity in the ecosystem. If you are hitting a wall with the core protocol, a missing cryptographic primitive, an asset custody constraint, a visibility gap in the node, an MPS puts that problem on the record using the MPS template. Nearly thirty have been filed so far.

A Midnight Improvement Proposal (MIP) is a concrete, technically precise proposal to change the ecosystem. MPS documents define what needs solving; MIPs propose how. A MIP that addresses a specific MPS gets listed in that problem statement, so anyone can trace a problem to the solutions competing to solve it.

You do not need a solution to contribute. Raising a well-motivated problem is a contribution on its own.

The life of a MIP

The full process is specified in MIP-0001, which was itself the first proposal through the pipeline. The short version:

• Idea. Vet it publicly in the Discussions tab or on Discord. Small fixes do not need a MIP.
• Draft. Copy the MIP template, GPG sign commits, and open a PR named mip-xxxx.md (literal x's).
• Numbering. MIP editors review the draft, assign a number, and merge it. Numbering is not acceptance; it gives the draft a stable identifier.
• Discussion and refinement. The community shapes the proposal in GitHub Discussions. Meaningful changes convert to issues that inform follow-up PRs.
• Proposal. The authors file an issue asking the editors to consider it. Status moves to Proposed and substantive edits stop.
• Community commentary. A review window of at least two weeks where anyone can weigh in.
• Editor vote. The MIP Editors vote to accept or reject.
• Implementation and deployment. Accepted MIPs get implemented, and protocol changes go live in a network upgrade, at which point the MIP becomes Active.

Ground rules: a MIP describes the change; it does not implement it. If there is accompanying code, keep it in a separate repository and link to it rather than including it in the PR. Commits must carry verified signatures, and while AI tools are welcome for drafting, the named human author is accountable for the content and for submitting the PR.

The six token types

Now the running example: what should a token on Midnight look like?

A token on Midnight can live natively in the ledger's UTXO layer or inside a Compact contract's state, and each of those can be shielded or unshielded. Without agreed standards, every issuer invents its own surface, and wallets, indexers, and bridges have no uniform way to recognize any of them.

The community conversation (Discussion #142 in the repo) organized the space into six token types:

• Shielded native tokens exist purely as private Zswap UTXOs. Once minted, they move wallet to wallet at the protocol level with no contract involvement.
• Unshielded native tokens are the transparent sibling: protocol-level UTXOs with publicly visible values and owners, spent with no contract round trip. NIGHT itself has this shape.
• Shielded contract tokens keep balances inside contract state with privacy-preserving semantics: programmable logic over private holdings.
• Unshielded contract tokens are the familiar account-based model: an address-to-balance mapping, ERC-20 style, fully programmable and fully public.
• Hybrid shielded and
• Hybrid unshielded tokens combine native UTXO custody with contract-mediated behavior. These are the least specified because they depend on custom spend logic the protocol does not yet expose.

Naming the six types turned one vague need ("we should have token standards") into a map, where each token type could get its own focused proposal.

The token MIPs so far

MIP-0004 proposes a standard for contract tokens. It extends the OpenZeppelin FungibleToken contract for Midnight with conversion circuits (shield, toUtxo, unshield, fromUtxo) so account-based balances convert to native ledger UTXOs and back without changing the total supply.

MIP-0011 proposes a standard for shielded native tokens. The issuing contract mints and burns but is never a balance keeper; coins move at the protocol level after minting. A reference implementation ships in the OpenZeppelin Compact Contracts library.

MIP-0014 proposes a standard for unshielded native tokens. The contract acts as an issuer, not a custodian: it is in the loop only to mint and burn, while holding and transfer stay fully native.

All three are up for debate in the repository's Discussions tab, and feedback given before ratification is what shapes the final standards.

A need was raised, discussion broke it into six token types, proposals claimed pieces of it, and each faces its two-week commentary window and editor vote on its own merits

Getting involved

If something in the protocol is in your way, write it up as a MPS. If you have a concrete design, draft a MIP. If you have opinions about proposals in flight, the token standards among them, the commentary periods are public.

Start here:

• Read MIP-0001 for the full process
• Browse the open problem statements to see what needs solving
• Join the conversation in Discussions or on Discord
• Fork the repo and draft your first proposal from the templates