Introducing FRPs for Busy Nerds
Formal Research Proposals (FRPs) are an important part of how protocol-level ideas are introduced and debated. They often shape design decisions, incentives, and downstream market structure. However, in practice, FRPs are difficult to follow for anyone who is not already deeply embedded in the discussion.
The core issue is not a lack of documentation, but fragmentation. An FRP’s specification may live in one document, while its motivation is discussed in forum posts, tradeoffs are clarified in GitHub comments, and critical design context appears in side discussions or call notes. Understanding what an FRP is actually proposing often requires piecing together information from many sources and already knowing where to look.
This project exists to reduce that friction. I repeatedly ran into this problem myself, trying to understand FRPs by jumping between specs, forum threads, and implementation notes, and eventually decided to solve it in the most direct way possible: by doing the aggregation and structuring myself.
Scope and intent
FRPs for Busy Nerds is a curation effort, not a rewrite. It does not introduce new ideas, modify proposals, or reinterpret author intent. Instead, it collects existing material and organizes it into a single, readable structure.
The goal is to make it easier for readers to understand:
- what problem the FRP is trying to solve,
- why the proposed mechanism was chosen,
- what tradeoffs and risks are explicitly or implicitly accepted,
- and why the proposal matters in practice.
All content is derived from primary sources, including original FRPs, forum discussions, research notes, and related implementation commentary.
Audience
This is intended for:
- researchers evaluating protocol-level proposals,
- builders assessing implementation implications,
- operators and practitioners concerned with real-world effects.
It assumes technical familiarity.
Sharing for feedback
I’m sharing this here because many FRPs particularly those related to MEV, auctions, and market structure, are discussed within the Flashbots ecosystem. Feedback from readers on structure, clarity, and usefulness would be valuable.
I’m committed to maintaining and updating this project over time. I welcome feedback, corrections, and suggestions from readers.
Thank You
Offical Link: Here
