A Filecoin Improvement Proposal is a design document for changing Filecoin: the protocol, the standards clients share, or the governance process itself. It sets out the change precisely and argues for it, and its git history becomes the permanent record of how the decision was made. A change to a single client doesn't need a FIP; anything that affects several implementations, or that they all need to agree on, does.
99 FIPs are in the repo today. The rest of this page follows them through the process.
How a FIP moves
The path in FIP-0001, with how many FIPs are at each stage today.Core FIPs go Last Call → Accepted → Final (when shipped in a network upgrade). Other FIPs go straight from Last Call to Final. Medians cover stage changes in the last 2 years.
Where open FIPs are now
Every FIP in Draft, Last Call or Accepted, longest in stage first.Draft 7
- FIP-0039 Filecoin Message Replay Protection4.3 years in stage
- FIP-0078 Remove Restrictions on the Minting of Datacap3.1 years in stage
- FIP-0080 Phasing Out Fil+ and Restoring Deal Quality Multiplier to 1x3.0 years in stage
- FIP-0096 Convert fundraising remainder address(es) to keyless account actor(s)23 months in stage
- FIP-0110 Allow Shorter Deal Durations12 months in stageLast discussed: Core Devs #85 · Nov 7
- FIP-0111 Add Support for EIP-7702 (Set Code for EOAs) in the FEVM10 months in stageLast discussed: Core Devs #86 · Dec 8
- FIP-0121 Remove the Fil+ Actors (f06, f07, f080)4 days in stage
Last Call 1
- FIP-0119 Increase maximum sector lifetime to 10 years5 days in stage · Review ends Nov 18 (est.)Last discussed: Core Devs #95 · Oct 28 · Implementers · Nov 3
Accepted 3
- FIP-0067 PoRep Security Policy & Replacement Sealing Enforcement3.2 years in stage · Not in an upgrade yetLast discussed: Core Devs #95 · Oct 28
- FIP-0082 Add support for aggregated replica update proofs2.1 years in stage · Not in an upgrade yetLast discussed: Core Devs #71 · Jun 6 · Implementers · Jun 10
- FIP-0107 Implicit Messages in Block Receipts2 months in stage · NV30 candidate (carried over)Last discussed: Core Devs #95 · Oct 28 · Implementers · Nov 3
Time in stage is measured from when the FIPs README showed the change, which can lag the decision by a few days. Upgrade candidates come from the NV30 planning discussion.
Proposing a FIP, step by step
From FIP-0001's work flow and proposing.md.- Test the ideaAsk the community first, in FIP Discussions, whether the idea is new and has support. It saves writing a proposal that prior work already ruled out.
- Write the draftFork the FIPs repo and write the proposal from the template. Add a
discussions-tolink so people know where to comment (it can't be a pull request). - Open a pull requestAn editor reviews the first PR, checks it's complete and well formed, assigns a number and merges it. The FIP is now a Draft.
- IterateRefine the Draft with follow-up PRs. Non-core FIPs need an implementation before moving on. For core FIPs, ask for a slot on a Core Devs agenda and prepare the matching change to the Filecoin spec.
- Last CallWhen the Draft is mature, ask for Last Call. The editor sets a
review-period-end, normally 14 days out. Material changes or unresolved objections send it back to Draft. - Accepted or FinalA clean Last Call makes a core FIP Accepted and any other FIP Final. Accepted core FIPs go to the implementers and into upgrade scope planning.
- Ship itA core FIP becomes Final once at least two clients implement it, the spec is updated and the community adopts it, which normally means its network upgrade has activated.
Each status change is a pull request from the author, reviewed by an editor. If an author steps away, they or the editors can hand the FIP to a new champion.
Types of FIP
Set in each FIP'stype and category headers.Changes that need a consensus upgrade (a network upgrade), or that will matter for one. These are the FIPs that go through Accepted and ship in an upgrade.
Changes to how data propagates or to Filecoin's network protocols.
Client API and RPC standards, and conventions such as method names.
Design notes, guidelines or conventions that don't propose a protocol change. Following them is optional. Kept as FRCs (Filecoin Request for Comments) in their own folder.
Changes to processes around Filecoin, including governance and the FIP process itself. Usually need community consensus.
A one-off state change to fix something the normal protocol can't, such as a bug that destroyed value. Only allowed under tightly defined criteria.
Counts come from the FIP files' headers and the FRCs folder. 8 technical FIPs don't name a subcategory in their header. Keeping a FIP to one focused idea makes it more likely to succeed.
What goes in a FIP
FIP-0001's required sections, in order. Start from the template.- PreambleHeader fields: number, short title, authors, status, type, category,
discussions-to, and where relevantrequires,replacesorreview-period-end. - Simple SummaryA plain-language explanation anyone can follow.
- AbstractAbout 200 words on the technical issue.
- Motivation (optional)Why the current protocol falls short. Optional in the template, but protocol changes without it may be rejected.
- SpecificationDetailed enough that independent teams can build interoperable implementations.
- RationaleWhy this design: alternatives considered, related work, and how objections were handled.
- Backwards CompatibilityRequired whenever something breaks: what, how badly and how it's handled.
- Test CasesRequired for consensus changes; linked where useful for others.
- Security ConsiderationsRequired for every FIP. A FIP can't become Final until reviewers judge this section sufficient.
- ImplementationsNeeded before Final, not before Draft: "rough consensus and running code".
- Copyright WaiverFIPs are public domain (CC0).
How long stages take
Stage changes in the last 2 years, from the FIPs README history.| Change | FIPs | Median time |
|---|---|---|
| Draft → Last Call | 12 | 14 days |
| Last Call → Accepted | 10 | 28 days |
| Accepted → Final | 19 | 47 days |
Every change, with dates and commits, is on the Timeline.
Stage guide
Paraphrased from FIP-0001, which is the authority.| Stage | What it means | What moves it on | Where it's discussed | Now |
|---|---|---|---|---|
| Idea | An idea is raised and debated in FIP Discussions before anyone writes a draft. | The author opens a draft PR on the FIPs repo when the idea has support. | FIP Discussions | 6 |
| Draft | The FIP editor has merged the draft and assigned a number. Authors keep refining it through follow-up PRs. | The editor moves it to Last Call when it's mature and, for non-core FIPs, implemented. | FIP Discussions, Core Devs, implementers' calls | 7 |
| Last Call | A final review window, normally 14 days (the review-period-end date). Material changes send it back to Draft. | A clean Last Call makes a core FIP Accepted, or any other FIP Final. | The FIP's discussion thread | 1 |
| Accepted | Core FIPs only. The proposal is approved and in implementers' hands; when it ships is decided in network upgrade planning, outside the FIP process. | It becomes Final once implemented in at least two clients, the spec is updated and it's adopted, normally when its network upgrade activates. | Upgrade scope planning, implementers' calls, Core Devs | 3 |
| Final | The current state of the art. Only errata are fixed from here. | Can later be Superseded by a newer Final FIP. | — | 73 |
| Rejected | Fundamentally broken, or a core FIP Core Devs won't implement. | 3 | ||
| Withdrawn | The author has withdrawn the proposal. | 3 | ||
| Superseded | Was Final, but another Final FIP has replaced it. | 2 | ||
| Active | Informational or organizational FIPs that are never "done" and may be updated in place, such as FIP-0001. | 2 | ||