Under the current BIP process defined by deployed BIP 3, anyone may author a proposal, but only BIP Editors assign numbers and publish qualifying drafts. BIPs are classified as Specification, Informational or Process, move through Draft, Complete, Deployed and Closed states, and remain author recommendations whose adoption is determined outside the repository by implementations, users and the broader ecosystem.
A BIP is a public design document for Bitcoin. It can define a technical feature, interoperability rule, process, guideline or historical record. The repository provides a common citation target and permanent revision history. A BIP is not legislation, a protocol command or an automatic software update. Individual nodes and applications only enforce or implement rules contained in software they actually run.
BIP 3, titled Updated BIP Process, is Deployed and replaces BIP 2. It modernized the workflow, reduced editorial discretion, replaced the old Standards Track category with Specification, simplified statuses and made clear that the repository is a publication medium and archive rather than a voting system or adoption tracker.
The process begins before GitHub. Authors are expected to research prior work and discuss a concrete idea with the Bitcoin Development Mailing List. When the draft has materially progressed, they open a pull request without assigning their own number. A BIP Editor assigns a number only after the proposal is on-topic, formatted correctly and has moved beyond raw ideation; the editor then merges it into the repository.
A Specification BIP defines implementable technical rules affecting a feature or interoperability; before Complete it must include or reference a working reference implementation and comprehensive test vectors. An Informational BIP records design information or guidance. A Process BIP governs a Bitcoin-related process rather than protocol interoperability and may become a living document when deployed.
Draft means work is still progressing. Complete means the authors consider planned work finished and recommend adoption or implementation; for Specification BIPs this requires implementation and test-vector evidence. Deployed means the BIP is demonstrably in active use or, for qualifying process documents, has achieved the required rough consensus. Closed marks material that is no longer active and is retained for history rather than deleted.
BIP Editors perform administrative and editorial work: they check scope, formatting, prior discussion, licensing and readiness, assign numbers and maintain metadata. BIP 3 explicitly says editors do not decide whether a proposal is likely to be adopted. Publishing a controversial proposal therefore does not certify its technical merit, safety, popularity or consensus status.
The number is primarily a stable reference. BIP 39 is a widely implemented mnemonic standard, BIP 141 documented SegWit consensus rules, BIP 174 defines PSBT, BIP 50 is a post-mortem of the March 2013 chain fork, and many other numbered BIPs remain Draft or Closed. Number assignment does not imply chronological importance, implementation or endorsement.
A specification can exist without production code, production code can experimentally implement a draft, and deployment or activation is another event again. Consensus-changing BIPs are especially important to separate from activation mechanisms: a document can describe rules, another BIP can describe deployment, and nodes only enforce those rules when their software and activation conditions say so.
BIP 141 is a Specification BIP whose rules became part of Bitcoin consensus through SegWit activation. BIP 174 is an interoperability format used by wallets and signers without changing block validity. BIP 50 documents an incident rather than proposing a protocol feature. BIP 3 itself is a Process BIP. These examples show that saying 'a BIP was adopted' can mean very different things depending on type and scope.
Modern BIPs carry structured metadata such as status, type, assigned date, license, discussion links, version and optional Requires, Replaces and Proposed-Replacement fields. After Complete, significant changes are tracked in a changelog with semantic-style version numbers. A breaking change to a mature specification should generally become a new BIP rather than silently redefining what existing implementations were built to satisfy.
Start with the current document in the official repository, not a screenshot or old article. Check its type, status, version, authors, discussion links, dependencies and changelog. Then verify implementation status in the relevant software project and, for consensus proposals, verify deployment and activation separately. The strongest question is not 'Does this BIP exist?' but 'What exactly is specified, who implements it, and what evidence shows it is active?'
For the clearest picture, read this entry together with Soft Fork, Consensus rules, Bitcoin Core, Bitcoin, Hard Fork, BIP 39. The reverse links also lead from Soft Fork, Blocksize War, Bitcoin Core, Luke Dashjr.