Bitcoin Improvement Proposals, usually called BIPs, give the Bitcoin community a shared format for describing technical specifications, operational guidance, and development processes. They help people discuss the same document, compare implementations, preserve design rationale, and refer to a proposal by a stable number.
A BIP does not define Bitcoin by itself. It does not bind node operators, miners, wallet developers, exchanges, application builders, or users. Publication in the bitcoin/bips repository means the document met the repository’s topic, maturity, formatting, and editorial requirements. It does not mean the proposal won a vote, received protocol approval, entered Bitcoin Core, shipped in a release, activated on the network, or achieved broad adoption.
This guide was reviewed July 25, 2026 against the live bitcoin/bips repository, BIP 3 version 1.4.0 and its December 9, 2025 changelog entry, and Bitcoin Core 31.1 implementation documentation at commit 9be056a8a72b624dae9623b2f7bded92c2a21c91. Repository rules and individual BIP headers can change, so readers should verify the live document and its history.
The current process document
The live BIP repository identifies BIP 3, “Updated BIP Process,” as the deployed process document. BIP 3 replaced BIP 2 and reduced the current workflow to four statuses: Draft, Complete, Deployed, and Closed. It also uses three types: Specification, Informational, and Process.
Older BIPs and articles may use the historical term “Standards Track” or statuses defined by BIP 1 or BIP 2. Those records remain useful history, but they should not be copied into a description of the current process without noting the change. When a header and an old essay disagree, check the live BIP, its changelog, and the process version in force.
BIP 3 is itself a Process BIP and may continue to receive amendments through the process it describes. That makes a review date important: “the BIP process” is not a timeless sentence detached from repository history.
What belongs in a BIP
A potential BIP should concern Bitcoin broadly enough to benefit from a common specification or durable public record. Examples include consensus proposals, peer-to-peer protocol behavior, application or wallet interoperability, APIs, implementation guidance, and development processes.
A minor change limited to one project normally belongs in that project’s issue tracker or pull request. A BIP is most useful when multiple independent projects, reviewers, or users need a shared document.
The process begins before a pull request. Authors are expected to research prior work, test whether the idea has broader interest, and present it for public technical discussion. Complicated systems may be split into several BIPs so that each document has a focused responsibility.
Authors, deputies, editors, and reviewers
Authors own the initial recommendation. They write the document, gather feedback, address objections, clarify tradeoffs, and may promote implementation or adoption. BIP 3 also allows authors to name deputies who can help maintain and advance the proposal.
Reviewers test the proposal’s clarity, internal consistency, technical soundness, interoperability, security assumptions, and compatibility. Review can reveal serious flaws, but review volume is not a formal approval count.
BIP Editors perform administrative and editorial work. They check scope, format, maturity, and readiness for publication; assign numbers; maintain the index; and merge qualifying documents. BIP 3 explicitly limits that role: editors do not decide whether a proposal is likely to be adopted. Number assignment and repository merge are publication actions, not protocol governance.
No editor, maintainer, company, software project, mining pool, or mailing-list participant has unilateral authority to make the Bitcoin ecosystem adopt a BIP.
Numbering and repository publication
Before number assignment, a draft generally uses a working title and BIP: ?. Only BIP Editors assign numbers. Under BIP 3, a proposal should have materially progressed beyond early ideation before it receives one. Evidence can include substantial public discussion, independent projects exploring adoption, or extended technical work responding to feedback.
A number is an identifier, not a ranking. Low and high numbers do not measure importance, quality, support, or deployment. Gaps and historical documents are normal.
Once merged, the repository provides a canonical publication location and change history. Authors can continue proposing updates through pull requests. After a proposal reaches Complete, noteworthy changes should be tracked through a version header and changelog. A document can therefore be “BIP 341” while still having a revision history that readers must inspect.
The three current BIP types
A Specification BIP defines implementable technical rules. Independent software can be evaluated for compliance with the specification. A Specification BIP should be precise enough to support interoperable implementations and, before reaching Complete, must include or reference a working reference implementation and comprehensive test vectors.
An Informational BIP documents a design issue, guideline, or other information. It can be influential without defining interoperable behavior. Complete is often the final successful status for an Informational BIP because there may be nothing to “deploy” as software.
A Process BIP describes or changes a process surrounding Bitcoin development. It is not a consensus rule. Its effect depends on the relevant community adopting the process. BIP 3 describes rough-consensus conditions for moving Process BIPs to Deployed and allows deployed process documents to evolve through later amendments.
Historical “Standards Track” language generally maps to the older process vocabulary. Under the live BIP 3 process, Specification is the current type name.
The four current statuses
Draft means the proposal has been published but planned work remains. Draft does not mean implemented, safe, rejected, or close to activation.
Complete means the authors consider the proposal clear, comprehensive, and ready for adoption, implementation, or deployment. For Specification BIPs, the process requires a working reference implementation and comprehensive test vectors. Complete is an author and document-maturity claim, not proof of ecosystem support.
Deployed should be used only after a Complete BIP is settled and evidence shows active use. BIP 3 gives examples of convincing evidence: an established project deploying support in mainnet software releases, a soft-fork proposal meeting its network activation criteria, or demonstrated rough consensus. The applicable evidence depends on the proposal, and Deployed still does not mean every wallet, node, service, or user supports the feature.
Closed marks a document that is primarily historical or no longer actively advanced or used. Closed BIPs remain in the archive. A closed proposal can still explain past decisions or influence later work.
Status should be read together with the type, layer, version, changelog, and dated implementation evidence.
Layers are not approval levels
BIP headers may classify a proposal by layer using BIP 123 vocabulary: Consensus (soft fork), Consensus (hard fork), Peer Services, API/RPC, or Applications. The layer identifies the affected system boundary.
A consensus-layer BIP can propose new block or transaction validity rules, but the document alone does not activate them. A Peer Services BIP can standardize network messages without changing block validity. An Applications BIP can define wallet, address, signing, or interchange behavior that software may adopt independently. API/RPC proposals concern interfaces rather than network consensus.
A proposal can also combine several documents. Taproot, for example, separates the Schnorr signature scheme, version 1 output rules, and tapscript behavior across BIPs 340, 341, and 342. The package still required implementation, release, deployment, activation, and application support beyond repository publication.
A BIP is one rung in an evidence chain
When someone says “BIP X is supported,” ask which event they mean:
- Idea discussed: a concept exists in public discussion.
- BIP drafted: structured text exists.
- Number assigned and document merged: the repository published it.
- Status changed: a transition was recorded under the BIP workflow, with type- and status-specific evidence requirements.
- Implementation written: code exists somewhere.
- Code merged: a project accepted code into a branch.
- Software released: users can obtain a version containing the code.
- Feature enabled: the software or operator configuration enables behavior.
- Consensus deployed or activated: network validity rules changed under the specified mechanism.
- Adoption observed: wallets, services, miners, nodes, or users actually use it.
These events can occur years apart, in a different order, or not at all. A merged implementation may remain unreleased. A released implementation may keep code disabled. A deployed consensus rule can have uneven wallet support. A widely used application standard can be adopted without changing consensus.
Bitcoin Core’s role and limits
Bitcoin Core publishes a release-specific doc/bips.md file listing BIPs its software implements and the version or pull request associated with support. That file is useful implementation evidence, but it applies to Bitcoin Core—not every implementation—and must be read at an exact tag or commit.
A Bitcoin Core pull request does not amend a BIP automatically. A BIP merge does not merge code into Bitcoin Core. A Bitcoin Core release does not force upgrades. Alternative implementations can implement the same active consensus rules through different code, and applications can adopt wallet or protocol BIPs on independent schedules.
Miners choose block-building systems and transaction-selection policy. Node operators choose validation software and configuration. Wallets choose address, signing, fee, and user-interface support. Services choose integration timelines. Users decide what software and transaction types they accept. These roles interact, but none is a central approval body.
How to evaluate a BIP today
Start with the live BIP header. Record the type, status, layer, assigned date, version, dependencies, replacements, and discussion links. Then read the specification, rationale, compatibility section, security analysis, test vectors, and changelog.
Next, look outside the BIP repository:
- Find independent implementations and identify exact versions.
- Distinguish code in a development branch from released code.
- Check whether support is default, optional, experimental, or disabled.
- For consensus proposals, verify the deployment mechanism and actual activation state.
- For peer protocols, verify negotiation and interoperability evidence.
- For wallet or application standards, verify sender and receiver compatibility.
- Read tests, audits, issue history, and unresolved review objections.
- Date every maturity or adoption claim.
The most reliable conclusion is often narrow: “BIP 341 is marked Deployed; Bitcoin Core documents validation support and mainnet activation; a particular wallet’s support must be checked separately.” That is more accurate than saying “Bitcoin approved Taproot.”