The ordinals BIP pull request was closed on March 4th, 2026 after being open for over three years.
This is Rodarmor's debrief about the ordinals bip pr being closed. It's a short blog post. He describes what he sees as some flaws in the BIP process and offers a number of suggestions. Before we get to his suggestions, I think it is interesting to consider this:
What's the purpose of a BIP?What's the purpose of a BIP?
My layman's mind thinks that the purpose of a BIP is to allow people to coordinate around new ideas in Bitcoin.
For instance, BIP 329 specifies a format for utxo labels. There are no doubt many different ways to format and store the data for labels, but it becomes significantly more useful for bitcoiners if we are all using the same specification -- it's nice if you can export your labels from Sparrow Wallet and import them in to Liana Wallet.
Regarding the ordinals BIP, is coordination the thing they seek? I've been feeling like: clearly people are already coordinating around this, why not just publish your standard somewhere (for instance an ordinals github repo) and leave it at that? What is the reason it needs to be included in the specific BIPs repo at https://github.com/bitcoin/bips/tree/master?
I suspect that some of why it is important to the ordinals people to have their thing included in the bitcoin/bips repo and have a number assigned by the BIP editors, is that they feel that it gives them legitimacy, helps with advertising, and potentially landing more investment money.
If I apply these questions to something like BIP 329, my answer is that it's nice to have a single standard to which everyone can point. So why isn't that my answer for the ordinals BIP? Well, it's because I don't like what it does and it is not clear to me that any group gains legitimacy in the eyes of Bitcoiners because BIP 329 exists.
This will not be the last time that someone people use bitcoin in ways that many bitcoiners don't like; nor will it be the last time such uses attempt to get codified. Probably, the trouble here comes from there being a centrally controlled repository of standards for a decentralized system.
In my ignorance, I am inclined to say that it wouldn't hurt bitcoin if there were two or three or more BIPs repositories. Rodarmor seems like a very capable guy: he could spin up a new repo and call it "hell bips" or "evil bips" or something and just mirror the current bips repo while adding the new things he finds interesting. If people think this is useful, I'm sure it would see some traction. Then Rodarmor could take on the role of "evil BIP editor" and implement a BIP process more to his taste -- and disappoint and frustrate the evil BIP authors whom he refuses to include in his evil BIP repo. If it is useful, the market will gravitate towards it. Am I being too glib here?
Maybe such a second BIP repo would cause some coordination problems because there is now more than one place where BIPs can go, but I suspect bitcoiners are capable of dealing with that trouble.
Anyhow, I think such a response would be better than trying to nail down what the scope of all possible "good" BIPs should be.
Rodarmor's suggestions for the BIP editorsRodarmor's suggestions for the BIP editors
- BIP editors should provide specific feedback as to why a pull request isn't being merged. Even if it is eventually closed, it is far preferable to know why and to be able to understand and respond. It is deeply unsatisfying as a contributor to have to ask in private for feedback, or hope that an editor will explain their thinking in a Twitter thread.
- BIP editors should moderate PR threads. Hundreds of duplicative and off-topic comments make following discussion challenging. Additionally, without moderation it is impossible for a BIP author to know which pieces of third-party feedback are substantive and should be addressed, and which can be ignored.
- Create a process for resolving disputes. I suggest that if the BIP editors cannot come to an agreement to merge or close a PR after three months, it should be closed and the author should be invited to re-submit it after a year.
- The BIP editors should, whenever questions of the scope of the BIPs repo come up with respect to a particular BIP, explain what they believe the scope of the repo is, and how it relates to the BIP in question. Whenever there is enough clarity and agreement, the scope of the repo should be codified in writing in a process BIP. If BIPs which were previously accepted are later decided to be out-of-scope going forward, this should be clearly documented, since accepted BIPs are otherwise a reasonable way for an outsider to determine the scope of the BIPs process.
- The BIP editors should not act unilaterally in closing a controversial PR. Unilateral action by a BIP editor does not clarify the scope of the repository, is clearly undesirable in principle, and makes such action more likely in the future.
No.
...meaning you believe it is better that there is only one bip repo?
meaning, casey is full of shit and entitlement.
The BIP repo maintainers can do whatever they want.
So can casey.
fork off to another repo.
Ah, yes. I believe "fork off to another repo" is my feeling as well.
This sounds best suited to another group of volunteers to me. A moderator's life is hell.
A lot of this feedback is good, but if you only participate in the process when you want something from it, and do not balance your demands with empathy/assistance/burden-sharing, you should have low expectations.
I have a cousin who would say "stop shoulding all over the place"
One steelman argument for Ordinals being a BIP is that sats of certain "rarity" levels are awarded directly to miners. (Of course, all sats are directly awarded to miners, but follow me here...)
Since the choice to split & sell these sats marginally affects the profitability of miners who obtain them, it is worth documenting how they are identified.
you make an interesting point. there will probably always be a case to made that something is "in scope" no matter how explicitly scope is defined. This is why I'm partial to people forking the bip repo and making the thing they want to see in the world. I wonder though if I'm just ignorant and there are very strong reasons why such a thing shouldn't be done.
The BIP editors moderating PR threads critique is understandable frustration but probably misdiagnoses the problem. BIP editors don't have the incentive or bandwidth to moderate every technical controversy — and you probably don't want them to, because then the question becomes 'which editor's opinion controls the thread?'
What ordinals revealed is that the BIP process doesn't have a clean mechanism for handling proposals that are technically correct but contested on values grounds. The original ordinals spec works — it's clever — but whether it should be a BIP is a question about what Bitcoin is for, not a technical one. The existing process isn't equipped to separate those two questions.
The irony is that closing it might be the most honest outcome. If the BIP process can't handle value-contested proposals without drama, leaving the spec outside the BIP namespace at least signals 'this exists but isn't something we've endorsed as Bitcoin infrastructure.'
The "evil bips" repo idea is funny but probably correct. A single canonical repo for a decentralized system creates a bottleneck that looks a lot like a governance chokepoint. If the standard is useful, people adopt it regardless of which repo hosts it.