# BUIP222: Tiered Proposal Framework — NXIP and NRC **URL:** \ **Category:** BUIPs\ **Created:** [February 4, 2026, 10:41am UTC](https://forum.bitcoinunlimited.info/t/buip222-tiered-proposal-framework-nxip-and-nrc/640 "2026-02-04T10:41:38Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![vgRunner](https://forum.bitcoinunlimited.info/letter_avatar_proxy/v4/letter/v/958977/32.png) [@vgRunner](https://forum.bitcoinunlimited.info/u/vgRunner)\ **Post date:** [February 9, 2026, 8:34am UTC](https://forum.bitcoinunlimited.info/t/buip222-tiered-proposal-framework-nxip-and-nrc/640/16 "2026-02-09T08:34:02Z")
> [@AndrewStone](#): > > Yes, you have never written any proposal, so you have no experience with the existing system. Yet you are going to “fix” it. The fact that I haven’t written a proposal doesn’t mean I don’t understand how the existing system works. And I’m not trying to fix it — a system like NXIP/NRC simply doesn’t exist today. The specs site is a documentation site. NXIP, NRC, and specs can and should coexist, they serve different purposes. > [@AndrewStone](#): > > Simultaneously, features have been added to Otoplo (without having yet formally proposed them) that are incompatible with features that have existed in Wally for years (wallet/app login). So every wallet needs to implement the same features as every other wallet? There’s no room for differences? I’m building features that the community has been requesting in Discord and Telegram — features that make sense for a wallet. Should I block community requests just because Wally does things differently? And what if Wally’s approach isn’t the best one? Should every wallet repeat the same patterns without question? Ironically, this is exactly the kind of problem that a proper NXIP/NRC process would solve — we’d have a shared, discussed standard before implementation, instead of discovering incompatibilities after the fact. > [@AndrewStone](#): > > I have not explicitly asked you to discontinue these features and implement TDPP support, but I have asked other people who work on Otoplo. It is hard to imagine you are unaware of this, and the timing of this BUIP is totally coincidental. Nobody ever communicated such a request to me. If someone had asked me to pause a feature to discuss it, I would have. But that never happened. Assuming otherwise without checking with me directly is unfair. > [@AndrewStone](#): > > I think that if that’s the case, you should retract this BUIP, write your spec, and open it as an MR into the spec repo and we can go from there! Why retract? The specs site documents features after implementation with a technical focus. NXIP/NRC is about proposing and discussing features _before_ implementation, with a proper review process. These are fundamentally different things. I can’t add something that doesn’t exist to a system that wasn’t designed for it. How do you currently communicate to the ecosystem what’s been implemented and what hasn’t? How do apps signal “we support this standard but not that one”? There’s no mechanism for any of this today. Let me give concrete examples. Tailstorm is already being worked on in the full node. The marketing team is promoting it. It requires a hard fork. Yet where is the Nexa-specific technical design? Where is the architecture document describing how Tailstorm is implemented in Nexa? Where should the community find information about this — from messages in Telegram? Same with Falcon for post-quantum signatures. The algorithm itself has public documentation, but where are the Nexa-specific technical specs? How is Falcon integrated into Nexa’s transaction signing? What are the architectural decisions? These documents don’t exist. We’ve accepted core protocol changes, yet there is no public place to find any information on the design decisions behind them. This is precisely the gap that NXIP/NRC would fill. > [@AndrewStone](#): > > Have you ever opened an MR to propose a change to the spec repo? For example, a new spec? > Why not use the existing system rather than creating a new one? The specs site is a documentation site, not a proposal system. Using it as one doesn’t make it one. > [@AndrewStone](#): > > Did you open an MR to fix the specs where you found problems? Or did you just leave the problem to other people? I opened issues, which is a valid and standard way to contribute — especially when you’re working part-time with limited hours. For someone like you with deep knowledge of the C++ codebase and strong English, fixing a spec might take an hour. For me, it could take days. Opening an issue so the right person can address it efficiently is the responsible thing to do. You yourself have opened issues on Rostrum rather than fixing them in Rust — for exactly the same reason. Dagur knows Rust better, so it’s more efficient for him to handle it. This is how teams work. You can’t expect everyone to “fix it yourself first” as a prerequisite for raising problems. > [@AndrewStone](#): > > How is creating yet-another-pile-of-unmaintained-data going to help? The hard work is cleaning specs up, updating them as time passes, and making them better for the next person. Who is doing this hard work? This is exactly the point. NXIPs/NRCs are written _before_ implementation. Once they reach Final status, they don’t need ongoing maintenance — they’re a historical record of what was proposed, discussed, and decided. The specs site, on the other hand, is living documentation that needs frequent updates. These are two different things with two different maintenance models. This proposal isn’t trying to replace the specs site. It’s trying to establish a proper framework for proposals _before_ implementation — the same framework that virtually every other blockchain project uses. This benefits not just us as developers, but the entire community. When an NXIP is accepted, it can be announced publicly. The community can read, understand, and discuss upcoming changes before they go live. And once it’s Final, it serves as a permanent, clear reference. The alternative is what we have today: important protocol decisions discussed privately, implemented without public review, and promoted to the community before anyone outside a small group has had a chance to weigh in. --- _[View the full topic](https://forum.bitcoinunlimited.info/t/buip222-tiered-proposal-framework-nxip-and-nrc/640)._