第 14 课：MIPs and the Research Forum

Changing a blockchain is harder than changing an app. You can't ship a fix and have it live everywhere by lunch, because you don't control the machines it runs on.

Monad's answer is the same one Ethereum and most serious open protocols use: a formal proposal process. Changes are documented, discussed publicly, debated, and either accepted or rejected based on merit. The process is called MIPs, short for Monad Improvement Proposals. It's modeled directly on Ethereum's EIPs, and the two systems work the same way for the same reasons.

If you're a vibecoder, you don't need to write MIPs. But you should know what they are, how to read one, and how to find the conversations happening around them. The places where MIPs and EIPs get discussed are public. Most builders don't read them, which means the ones who do have early visibility into where the chain is going.

By the end of this lesson you'll know:

1. What a MIP is
2. How to read one efficiently
3. What the lifecycle looks like
4. Where the conversations happen

What a MIP Is

A MIP is a document. That's what it is at the most basic level.

The document proposes a change to Monad. The change might be technical (a new consensus mechanism, an optimization to block propagation), it might be economic (a fee structure adjustment), it might be procedural (a change to how the network upgrades itself). Whatever the change is, the MIP describes it precisely enough that anyone reading the document can understand what's being proposed and why.

MIPs follow a consistent structure. They have a number (MIPs are numbered sequentially, so MIP-1 came first, MIP-10 came tenth). They have an author or set of authors. They have a status (draft, accepted, rejected, implemented). They have a body that lays out the motivation, the specification, the rationale, and the trade-offs.

The format isn't bureaucratic for its own sake. It exists because protocol changes are high-stakes and need to be evaluated rigorously. A proposal that says "Monad should be faster" is useless. A proposal that says "here's how to change the block propagation protocol to let validators vote before fully decoding the block + here's the cryptographic argument that it's safe + here's the implementation plan" is something the community can actually evaluate.

The proposal process serves another purpose, too: it creates a permanent record. Every MIP that's been accepted is part of the protocol's documented history. You can read MIP-1 today and see exactly what the first formal change to Monad was, and why. The same will be true of MIP-100 a few years from now. The record is the protocol's institutional memory.

How MIPs Relate to EIPs

Monad inherits the EVM from Ethereum and maintains broad compatibility with it, but it doesn't copy every change automatically. When Ethereum ships a new opcode or EIP, Monad adopts what makes sense and skips what doesn't.

For example, when Ethereum was considering an EIP that would have complicated gas calculations, Monad planned to pass on it. (Ethereum later scrapped it anyway.) In practice, most changes come through, so the Solidity compiler, developer tooling, and execution model stay shared across the EVM ecosystem.

EIPs are the proposal process for changes to that shared layer. They go through the same kind of structured process MIPs do: drafts get written, the community debates them, accepted proposals get bundled into network upgrades (Ethereum's upgrades are named after Devcon cities — Shanghai, Cancun, Prague), and eventually they're live.

How to Read a MIP

A MIP is a structured document, and once you know the structure, reading one is fast. Most MIPs follow the same template:

Header. The first few lines tell you what you're looking at: the MIP number, the title, the authors, the status, and the date. If the status is "draft," the proposal is still being shaped. "Review" means the author is asking for feedback. "Last call" is a final two-week window before it locks. "Final" means it's settled and only gets edited to fix mistakes. Two other fields to notice: type and category. "Core" is the one that matters most, because it means the change touches the protocol every validator runs.

Abstract. A one-paragraph summary of the proposal. This is the most important section for a quick read. If you read nothing else, read the abstract. It tells you what's being proposed and what it does.

Motivation. Optional. Why this change matters. What problem does it solve? What's broken in the current design? Why is this worth the effort of changing?

Specification. The technical details. This is the meat of the MIP and the longest section. It describes exactly what changes, in enough detail that someone implementing it would know what to do. For a vibecoder, this is the section that might feel dense. Skim it on first read. Come back to specific parts if they matter.

Rationale. Why the proposal was designed this way and not some other way. What alternatives were considered? Why were they rejected? The rationale tells you what trade-offs were made and how the authors thought about them. This is often the most interesting section for understanding the design.

Backwards compatibility. Optional, unless something breaks. Will existing things break? If yes, how? If the change isn't backwards compatible, this section explains why the break is necessary and how the network will transition.

Test cases. Optional for most MIPs, required for anything that changes consensus. Input and expected output pairs, so the teams building the software have something to check their work against.

Reference implementation. Optional. A link to code, if one exists. Some MIPs come with a pull request or a prototype already implemented. Others are purely conceptual until the community decides whether to pursue them.

Security considerations. What could go wrong? What new attack surfaces does the change create? Every protocol change introduces some risk, and this section is where the authors lay out what risks they thought about.

Copyright waiver. One line at the bottom putting the document in the public domain. Every MIP has it.

The right way to read a MIP is in two passes. First pass: read the abstract, the motivation, and skim the rationale. You're trying to understand what's being proposed and why.

Second pass, if you care: read the specification carefully, look at the reference implementation if there is one, and check the security considerations. Most readers don't need the second pass for most MIPs. The first pass is enough to follow the conversation.

Real MIPs are usually shorter than that list suggests. For example, MIP-12, which cut Monad's block time from 400ms to 300ms, is an abstract, two small tables, and a note on backwards compatibility.

The Lifecycle of a MIP

A MIP doesn't appear fully formed. It goes through stages, and each stage involves different kinds of work.

Idea. Before anything is written down, someone has an idea. The idea might come from a researcher working on a specific problem, or from a community member who noticed something off, or from a developer who's been thinking about a design improvement. At this stage, the idea is informal. It might come up in Discord, in a meeting, in a research forum post.

Draft. The author writes the idea up as a MIP draft. The draft might be rough at this point: the motivation is clear but the specification is incomplete, or vice versa. The draft is posted publicly so others can comment.

Discussion. The draft is debated. People point out problems. Alternative designs get proposed. The author iterates, sometimes rewriting large sections, sometimes splitting the proposal into multiple MIPs, sometimes abandoning the idea entirely. This phase can take weeks or months. The discussion happens on the research forum, in GitHub, in Discord, and sometimes in dedicated meetings.

Acceptance or rejection. At some point, the community reaches consensus. Either the MIP is accepted (it'll be implemented), it's rejected (the idea isn't right, or isn't right for now), or it stalls (no one's actively pushing it and it sits in draft). Acceptance isn't formal voting in most cases; it's a rough consensus among the core contributors and the broader community that this is the right thing to do.

Implementation. An accepted MIP gets implemented in code. This is its own substantial body of work, often involving multiple pull requests, code reviews, testing, and deployment. The implementation may surface issues that weren't visible from the design alone, which sometimes sends the MIP back to the discussion phase for revision.

Activation. The implementation gets deployed to mainnet. Often there's a rollout period where the change can be tested on testnets first, or where it's deployed with a flag that lets validators opt in gradually. Eventually, the change is live.

Different MIPs move through this lifecycle at different speeds. A small change might go from draft to activation in a few months. A large architectural change like Deterministic RaptorCast takes longer, because the discussion, implementation, and rollout are all bigger.

Where the Conversations Happen

This is the part most people don't realize: the protocol's evolution happens in public, and the venues are open. You can read every conversation if you want to.

For Monad specifically:

• MIPs GitHub repo (github.com/monad-crypto/MIPs). The canonical source of truth for MIPs themselves. Each MIP is a markdown file in this repo. If you want to know what a MIP actually says, this is where you read it.
• Monad research forum (forum.monad.xyz). Where MIPs and broader research ideas get discussed in long-form. Threads on the forum often precede formal MIPs by weeks or months. Researchers post drafts here for feedback before turning them into formal proposals.

For Ethereum:

• Ethereum Magicians forum (ethereum-magicians.org). Where new EIPs get pitched and discussed informally before they become formal proposals. If someone has an idea like "I think this opcode should work differently," this is where they post it first.
• EIPs GitHub repo (github.com/ethereum/EIPs). The formal proposals themselves. You can read the full text of any EIP, see the discussion in the pull request, and watch it evolve.
• All Core Devs calls. Bi-weekly zoom calls where Ethereum client teams (Geth, Nethermind, Besu, others) discuss what's going into the next upgrade. They're recorded and posted publicly. Watching one will tell you more about how Ethereum actually evolves than any blog post.
• Solidity team weekly calls. The Solidity compiler maintainers hold public calls on Google Meet, currently Mondays at 9am EST / 3pm CET and Wednesdays at 8am EST / 2pm CET. Meeting links are in the contributing section of the Solidity docs. These calls cover language-level changes, separate from EVM changes.
• Solidity forum (forum.soliditylang.org). Language-level discussions about Solidity itself. Good place for ideas about syntax or compiler features.

A useful rule of thumb: if you want to know what a change is, read the MIP or EIP. If you want to know how the community feels about it, read the forum thread or watch the call. If you want to know how it's being built, read the GitHub pull request.

A Concrete Example: MIP-10

The cleanest way to understand MIPs is to walk through an active one. MIP-10 is Deterministic RaptorCast — RaptorCast is the chunk-distribution layer you saw in the Monad Architecture lesson. Here's how it looks through the MIP lens.

Motivation. RaptorCast v0 has two weaknesses. First, a malicious leader can pick which Raptor encoding symbols to send, which lets them slow down specific validators while sending individually-valid chunks. Second, the Merkle roots in v0 only cover 32 chunks at a time and aren't bound to a specific block, which means a malicious leader can construct a root whose chunks are drawn from two different blocks. Both are real attacks that v0 has no defense against.

Proposal. Make the encoding deterministic. Derive a seed from public data (the round, the leader's identity, the proposal timestamp), and pin every chunk's position to that seed. Put the entire encoding under a single Merkle root instead of one root per 32-chunk batch. The root becomes a binding commitment to the whole block.

Why this works. Determinism removes the leader's freedom to pick which chunks to produce. There's exactly one valid encoding per round, so the asymmetric-liveness attack disappears. The single root makes the commitment binding to a specific block, so the mixed-commitment attack disappears too. Both fixes come from the same architectural change.

Trade-offs. Per-packet Merkle proofs grow from about 100 bytes to up to 280 bytes, because the tree is deeper. That's the cost. The benefit is that validators can vote on a block as soon as they've verified one chunk against the root, without waiting to decode the full block. The vote bandwidth goes up slightly; the consensus latency goes down significantly. The trade is clearly worth it for a chain pushing throughput.

Implementation. The reference implementation lives in pull request #2811 in the monad-bft repository. It implements v1 alongside v0, with a four-stage rollout plan so the network can transition gradually. Three earlier PRs (cleaning up v0's chunk validation, adding a round-robin assignment mode, and replacing dynamic dispatch in the chunk assigner) were merged first to make the v1 changes possible.

Status. Implementation merged, rollout in progress.

If you wanted to follow MIP-10 yourself, you'd read the MIP-10 document in the MIPs repo, then look at PR #2811 on GitHub for the implementation details. Any relevant forum threads would give you the community discussion. The pieces complement each other: the MIP tells you what, the forum tells you why and how the community feels about it, and the GitHub PR tells you how it actually works in code.

How to Write a MIP

You probably won't, but here's the shape of the process in case you ever do, or in case you want to understand how the authors of existing MIPs got there.

Start with an idea worth proposing. The bar for "worth proposing" is higher than it sounds. The idea should solve a real problem, fit into the existing architecture without breaking things gratuitously, and be specific enough that someone could implement it. Vague ideas don't make good MIPs. Ideas that have already been explored and rejected don't make good MIPs either.

Talk to people first. Before writing anything formal, float the idea on the research forum or in Discord. See if others have already thought about it. See what objections come up. The early conversations save you from spending weeks on a draft only to discover that someone has already proposed essentially the same thing.

Write a draft. Use the standard MIP template. Be precise. Don't gloss over the trade-offs; the rationale section is often the part the community cares about most, because it tells them how you thought about the problem. If you can produce a reference implementation, even a rough one, do it. Code makes a proposal real in a way that prose doesn't.

Submit and iterate. Post the draft as a pull request to the MIPs repo. The first round of feedback will be brutal in the way that good technical feedback always is. Take it seriously, revise the proposal, and engage with critics in good faith. Most accepted MIPs went through several rounds of substantial revision before they got accepted.

Accept that not all proposals get accepted. Many MIPs get rejected, and that's the system working as intended. A rejected MIP that's clearly argued and well-considered is still a contribution: it documents an idea, the reasons for rejecting it, and the alternatives that won. Future contributors can learn from it.

What This Means for You

You don't need to write MIPs or read every one to be effective on Monad. Most of your work as a vibecoder will be about building apps, not about the protocol. But knowing the proposal process matters for a few reasons.

It helps you read protocol news intelligently. When a Monad blog post says "Deterministic RaptorCast is now on testnet," you know what that means and where to find more detail. When someone in Discord mentions "MIP-10," you know it's a proposal, you know how to look it up, and you know whether it's a draft or an implemented change.

It helps you participate when you have something to contribute. Maybe you spot a bug, or notice an inefficiency in something user-facing, or have a design suggestion for the developer experience. The forum is where you'd raise it. The MIP process is where it would go if it became a real proposal. Knowing the system means you can engage with it.

It helps you predict the chain's evolution. Protocols are built by people, and the people building Monad are publicly discussing what's coming next. Reading the research forum gives you advance notice on changes that will affect what you can build.

Talking About MIPs

A short glossary.

A MIP is a Monad Improvement Proposal. It's a structured document proposing a change to the Monad protocol.

An EIP is the Ethereum equivalent. Changes to the EVM itself go through EIPs and propagate to Monad.

The MIPs repository is the canonical source for accepted and proposed MIPs. It lives on GitHub.

The research forum is where MIPs and broader research ideas are discussed publicly. Threads on the forum often precede formal MIPs.

Ethereum Magicians is the equivalent forum for Ethereum. It's where EIPs get pitched and discussed informally.

A draft MIP or EIP is one that hasn't been accepted yet. Drafts are open for discussion and may change substantially or be abandoned.

An accepted proposal is one the community has agreed to implement. It may or may not be live in the codebase yet.

A reference implementation is the code that turns a proposal into a working change. It usually lives in a pull request against one of the protocol's repositories.

All Core Devs refers to the bi-weekly Ethereum core developer calls where upgrade decisions get made. The recordings are public.

What to Do Next

The next time you hear someone reference a MIP or EIP number in a conversation, look it up. Two minutes of reading turns "I don't know what they're talking about" into "I know exactly what they're talking about."

Up next

Next up: Reading the Monad Codebase — you've now read how proposals get argued over, so it's time to see where they end up once they ship.