What is a BIP? Bitcoin Improvement Proposals explained

A BIP (Bitcoin Improvement Proposal) is a public design document that describes a change to Bitcoin, or a shared standard for the software built around it. Anyone can write one. BIPs are how ideas get written down, reviewed and given a number, but a BIP does not change Bitcoin by itself: a proposal only takes effect when people choose to run software that implements it.

Updated 2026-10-20 · 9 min read

What is a BIP?

A Bitcoin Improvement Proposal is a document with a fixed structure: a header with metadata, a short abstract, the motivation, a technical specification and the reasoning behind it. Most BIPs describe one concept, feature or standard. Some document processes, best practices or past incidents, such as the March 2013 chain fork post-mortem.

BIPs cover every layer of Bitcoin:

• Consensus rules every node enforces, like Pay to Script Hash, SegWit and Taproot.
• Peer-to-peer networking, like compact block relay and encrypted transport.
• Wallet standards that let you move between apps, like seed phrases (BIP 39), HD wallets (BIP 32) and PSBTs.

All BIPs live in the public bitcoin/bips repository on GitHub. The repository is a publication medium and archive: it records every change to every BIP, and nothing is ever deleted. BIP Explorer shows the same documents with plain-English summaries, the current status and links between related proposals.

A short history: BIP 1, BIP 2 and BIP 3

The BIP process has been rewritten twice.

• BIP 1 (2011), written by Amir Taaki, created the process. By its own account it was "derived heavily from Python's PEP-0001", the proposal process used by the Python language. It defined three types (Standards Track, Informational and Process) and the idea of a champion who writes the proposal and builds support for it.
• BIP 2 (2016), by Luke Dashjr, replaced it with more objective rules for changing a BIP's status. It used nine statuses, renamed Accepted to Proposed, required an implementation before a BIP could become Proposed, added a comments system and introduced licensing rules. It also brought in the Layer header from BIP 123.
• BIP 3 (2025), by Mark "Murch" Erhardt, replaced BIP 2 with a simpler process. It cut the statuses from nine to four, replaced the Standards Track type with Specification, dropped the comments system, renamed the Created header to Assigned (the date a number was given) and added optional Deputies who can help authors.

If you read older articles, the status names will look different. BIP 3 maps them like this:

You can compare the two process documents side by side in BIP 2 vs BIP 3.

What do the BIP statuses mean?

Every BIP has exactly one of four statuses. Three are steps forward; the fourth is an exit that can be taken at any point.

1. Draft: the proposal has been opened as a pull request, assigned a number by a BIP editor and merged into the repository. The authors are still working on it, and its details may change.
2. Complete: the authors have finished their planned work and recommend the BIP for adoption. A Specification BIP can only reach Complete once it includes or links to a working reference implementation and test vectors. After this, only small fixes and clarifications should be made.
3. Deployed: the BIP is settled and in active use. Anyone can request the move with evidence, for example an established project shipping it in mainnet releases, or a soft fork's activation criteria being met on the network. A Deployed BIP is considered final; breaking changes need a new BIP.
4. Closed: the BIP is of historical interest only. A Draft can be closed if it has stalled for a year and its authors don't say within four weeks that they're still working on it. Complete BIPs are closed only by their authors, and a Deployed BIP can be closed once it is no longer in use.

Process BIPs work slightly differently: they move to Deployed when they reach rough consensus on the mailing list, after at least a month of open discussion, and they stay living documents that can keep being amended the same way.

A status describes where a document is in this workflow. It is not a vote or an endorsement, which is why BIP Explorer shows it as a badge rather than a verdict.

What are the three BIP types?

BIP 3 defines three types:

• Specification: technical rules that can be implemented, where software can be checked for compliance. Consensus changes, network messages, address formats and wallet standards are all Specification BIPs. This type replaces BIP 2's Standards Track.
• Informational: describes a design issue or gives guidelines and information, without defining something to implement. BIP 9, which explains the version bits signalling mechanism, is Informational.
• Process: describes or changes a process around Bitcoin, rather than the protocol itself. BIPs 1, 2 and 3 are Process BIPs; see the process topic.

What is a BIP layer?

Many BIPs also carry a Layer header, using the classification from BIP 123. Lower layers are harder to change because more software has to agree:

Who are the BIP editors and what do they do?

BIP editors are volunteers who run the repository. At the time of writing, BIP 3 lists five: Bryan Bishop, Jon Atack, Mark "Murch" Erhardt, Olaoluwa Osuntokun and Ruben Somsen.

Their job is administrative and editorial. For each new proposal they check that the idea was discussed on the mailing list, that it is on topic and of interest to more than one project, that the title, type and layer are right, that the license is acceptable, and that the motivation, specification and backward compatibility are covered well enough to implement. Then they assign a number, list the BIP in the README and merge it. They can also fix typos and broken links themselves.

What editors do not do is judge whether a proposal is a good idea or likely to be adopted. BIP 3 says so explicitly. Getting a number means a proposal is well formed and has attracted real interest, nothing more.

How to write and submit a BIP

BIP 3 describes the path from idea to published proposal:

1. Research first. Many ideas have been proposed before. Search the mailing list archive and existing BIPs (the BIP Explorer search covers every proposal and its summary).
2. Check it needs a BIP. BIPs are for ideas that matter to several projects. A change that only affects one wallet or one node implementation belongs in that project's own issue tracker.
3. Post the idea to the Bitcoin Development Mailing List in a dedicated thread, and collect feedback before writing a full draft. BIP 3 asks authors not to open a pull request "out of the blue".
4. Write the draft in Markdown or MediaWiki, with a preamble, Abstract, Motivation and Copyright section, plus a Specification, Rationale, Backward Compatibility section and reference implementation where they apply. Split large ideas into several focused BIPs.
5. Open a pull request to bitcoin/bips, with a file named after a working title such as bip-title.md. Never pick your own number: only editors assign numbers, and only once the proposal has moved beyond the idea stage.
6. Keep improving it. After the BIP is merged as Draft, you update it through further pull requests. When your work is done, you move it to Complete yourself.

Do BIPs decide what Bitcoin runs?

No. BIP 3 is direct about this: "BIPs do not define what Bitcoin is", and "no formal or informal decision body governs Bitcoin development or decides adoption of BIPs". A BIP is a recommendation from its authors.

What Bitcoin actually is at any moment is decided by the software people run. Wallet developers choose which standards to support. Node operators choose which consensus rules to enforce. A consensus change only becomes real when enough of the network runs software that enforces it. Many BIPs, including some with numbers and long discussions, were never adopted, and that is part of the process working as designed.

How do soft forks get activated?

A soft fork tightens the rules, so blocks that follow the new rules are still accepted by old nodes. That makes it possible to upgrade without splitting the network, but only if enough of the network enforces the new rules at the same time. Activation mechanisms coordinate that moment. The soft forks guide covers them in detail; in short:

• Flag dates. BIP 16 (P2SH) was enforced from April 2012 based on a fixed timestamp.
• Version number supermajorities. BIP 34, BIP 66 and BIP 65 activated when 95% of recent blocks carried a higher version number.
• Version bits. BIP 9 lets miners signal readiness for several soft forks at once, one bit each, with a 95% threshold (1,916 of 2,016 blocks in a retarget period). The CSV package of BIPs 68, 112 and 113 activated this way at block 419,328 in July 2016.
• SegWit. BIP 141 activated at block 481,824 on 24 August 2017, after BIP 91 locked it in, against the background of BIP 148, a user-activated soft fork.
• Taproot. BIPs 340, 341 and 342 activated at block 709,632 on 14 November 2021, through Speedy Trial signalling.

BIP 8 describes an alternative to BIP 9 that uses block heights and can force activation at the end of the signalling period. The two are compared in BIP 8 vs BIP 9. Which mechanism to use for a future soft fork is itself a subject of debate.

How to read a BIP

Every BIP starts with a preamble. The headers tell you most of what you need before reading a word of the specification:

• BIP, Title and Authors identify it. Deputies are extra owners who help the authors.
• Status and Type, as described above, and Layer for many Specification BIPs.
• Assigned: the date the number was given (called Created before BIP 3).
• Requires, Replaces and Proposed-Replacement link it to other BIPs.
• Discussion points to the mailing list threads where it was debated, and Version tracks changes after it reached Complete.

Then read in this order: the Abstract for what it does, the Motivation for why, and the Rationale for the alternatives the authors rejected. The Specification is the precise part that implementers follow, and Backward Compatibility tells you what breaks for software that ignores it. Test vectors, when present, are the fastest way to check an implementation.

How to use BIP Explorer

BIP Explorer puts the whole repository in one place, with a plain-English summary at the top of each BIP and the full original text below it.

• Search by number, title, author or keyword, and filter by status or type.
• The map shows every BIP by year and area of Bitcoin, with lines for proposals that build on or replace each other.
• Topics group BIPs by subject, such as wallets, addresses, Taproot or governance.
• Status pages list every Deployed, Complete, Draft and Closed BIP.
• Guides like this one explain the ideas behind groups of BIPs. A good next step is the most important BIPs.

The about page explains where the data comes from and how it is available to developers.