BUIP222: Tiered Proposal Framework — NXIP and NRC

BUIPs
1

BUIP222: Tiered Proposal Framework — NXIP and NRC

Submitted By: vgrunner
Date: 04 February, 2026

Overview

This BUIP proposes the establishment of a comprehensive, tiered proposal and specification framework for the Nexa ecosystem by introducing two new specification tracks:

  1. NXIP (Nexa Improvement Proposal) — A new specification track for core protocol changes, consensus modifications, network architecture, node software features, and hard fork requirements. Modeled after Bitcoin’s BIP and Ethereum’s EIP systems.

  2. NRC (Nexa Request for Comments) — A new specification track for application-layer standards, implementation specifications, token standards, and interoperability guidelines. Modeled after Ethereum’s ERC system.

The existing BUIP system remains unchanged and continues to govern Bitcoin Unlimited organizational matters. This separation will provide clarity, improve developer experience, enhance ecosystem transparency, and establish Nexa as a mature blockchain platform with proper governance and documentation infrastructure.

Motivation

The Current State

The existing BUIP system has served Bitcoin Unlimited well for organizational governance. However, as Nexa has grown into a distinct blockchain network with its own protocol, consensus mechanisms, and expanding developer ecosystem, several critical gaps have emerged:

1. No Centralized Technical Specification Repository

Currently, there is no designated location where the community can track proposed or implemented changes to Nexa’s core architecture, protocol specifications, or consensus rules. Developers seeking to understand the technical evolution of Nexa must piece together information from scattered forum posts, code commits, and informal discussions. This lack of organization creates barriers to entry for new developers and makes it difficult for existing participants to stay informed about the network’s technical direction.

2. No Application Standards Framework

Nexa’s application layer lacks a formal standards process. Developers building wallets, exchanges, token systems, NFT platforms, and other applications have no authoritative reference for implementation specifications. This leads to fragmentation, incompatible implementations, and duplicated effort across the ecosystem.

3. Conflation of Organizational and Technical Governance

The current BUIP system combines fundamentally different types of proposals—organizational decisions (membership, budgets, marketing) and technical specifications (protocol changes, standards)—under a single process. These categories have different stakeholders, different review requirements, and different lifecycles. Organizational decisions affect the governing body (Bitcoin Unlimited) and require democratic participation from members. Technical specifications, however, require deep technical review and expert consensus, with implementation ultimately enforced by the network’s nodes and economic actors.

4. Barrier to Ecosystem Growth

Mature blockchain ecosystems (Bitcoin, Ethereum, Solana, etc.) all maintain dedicated, publicly accessible specification repositories. The absence of such infrastructure for Nexa signals immaturity to potential developers, enterprises, and partners evaluating the ecosystem. Establishing proper specification tracks is essential for Nexa’s growth and adoption.

Why Separate Specification Tracks Matter

Blockchain networks benefit from distinct documentation and review processes for different types of specifications:

  • Organizational decisions affect the governing body (Bitcoin Unlimited) and require democratic participation from members.
  • Protocol specifications require deep technical review and expert consensus, with implementation ultimately enforced by the network’s nodes and economic actors.
  • Application standards require community input and technical review, but adoption is voluntary and driven by practical utility rather than mandate.

By introducing NXIP and NRC tracks, we enable:

  • Faster iteration on technical specifications through developer-led review
  • Clearer accountability and expertise requirements for different proposal types
  • Better discoverability and documentation for developers
  • Alignment with industry best practices that developers from other ecosystems will recognize

Proposed Action

1. NXIP — Nexa Improvement Proposal (New)

Scope: NXIPs define specifications and standards for Nexa’s core protocol and node software:

  • Consensus rule changes
  • Hard fork specifications and activation mechanisms
  • Network protocol modifications (P2P layer, message formats)
  • Core architecture changes
  • New cryptographic primitives or signature schemes
  • Block structure modifications
  • Transaction format changes
  • Mining algorithm adjustments
  • Reward distribution mechanisms
  • Any change that affects node interoperability or consensus

Examples of potential NXIPs:

  • NXIP-001: Tailstorm Block Structure — Specification for the Tailstorm architecture enabling increased throughput and reduced confirmation times (reference: [2306.12206] Tailstorm: A Secure and Fair Blockchain for Cash Transactions)
  • NXIP-002: Post-Quantum Cryptographic Signatures — Implementation specification for quantum-resistant signature schemes
  • NXIP-003: Revised Block Reward Algorithm — Specification for modified emission schedule or reward distribution mechanism
  • NXIP-004: Enhanced Script Opcodes — Definition of new opcodes for improved smart contract functionality

Process:

  • NXIPs will be maintained in the proposals monorepo under the Nexa organization (gitlab.com/nexa/proposals)
  • Proposals are submitted as Markdown files (.md or .mdx) via Merge Request
  • NXIPs follow a lifecycle: Draft → Review → Accepted → Final (or Rejected/Withdrawn)
    • Draft → Review: Requires approval from 3 developer members (author + 2 reviewers) confirming the spec is complete and well-formed
    • Review → Accepted: Requires consensus among the dev team, indicating commitment to implement
    • Accepted → Final: Implementation complete

Implementation Expectations:

  • NXIPs defining consensus changes or hard fork requirements should be implemented by all node software implementations to maintain network compatibility
  • NXIPs defining optional features may be implemented at the discretion of individual node software projects
  • The NXIP document must clearly indicate whether the proposal affects consensus

2. NRC — Nexa Request for Comments (New)

Scope: NRCs define application-layer standards and implementation specifications:

  • Token standards and metadata specifications
  • NFT creation and metadata standards
  • Wallet implementation guidelines
  • Address derivation paths and account structures
  • Token Description Document (TDD) specifications
  • API standards for services and applications
  • Data encoding standards
  • Interoperability specifications between applications
  • Best practices for specific use cases

Examples of potential NRCs:

  • NRC-001: Token Description Document Standard — Specification for on-chain and off-chain token metadata
  • NRC-002: NFT Metadata Standard — Standardized format for NFT attributes, media references, and provenance
  • NRC-003: Single-Address Account Derivation — Variation of BIP-44 supporting Nexa’s single-address account pattern for simplified wallet UX
  • NRC-004: Wallet Connect Protocol — Specification for dApp-to-wallet communication

Process:

  • NRCs will be maintained in the proposals monorepo under the Nexa organization (gitlab.com/nexa/proposals)
  • Proposals are submitted as Markdown files (.md or .mdx) via Merge Request
  • NRCs follow a lifecycle: Draft → Review → Accepted → Final (or Rejected/Withdrawn)
    • Draft → Review: Requires approval from 3 developer members (author + 2 reviewers) confirming the spec is complete and well-formed
    • Review → Accepted: Requires consensus among reviewers that the standard is ready for adoption
    • Accepted → Final: Standard is stable and in active use

Implementation Expectations:

  • NRCs are recommendations, not mandates
  • Applications are not required to implement every NRC
  • NRCs represent community-agreed best practices and standards for interoperability
  • Applications implementing NRCs should indicate compliance for user awareness
  • The goal is ecosystem coherence through voluntary adoption, not enforcement

3. Escalation to BUIP

NXIPs are intended to be resolved through developer discussion and review. In most cases, technical proposals will reach consensus among those actively working on Nexa development.

However, in cases where an NXIP cannot be resolved through developer discussion, or where BU membership has concerns about a specific proposal’s direction or implications, the matter can be escalated to a BUIP vote for resolution. This serves as a permanent safeguard ensuring that the broader Bitcoin Unlimited membership retains ultimate oversight over significant technical decisions. Such escalation should be rare, reserved for genuinely contentious matters that cannot be settled through normal technical review.

NRCs, being voluntary application-layer standards, do not require an escalation path. If there is disagreement with an NRC, an alternative NRC can simply be proposed offering a different solution.

4. GitLab Repository Structure

A unified proposals monorepo will be established:

gitlab.com/nexa/proposals/
├── README.md
├── mkdocs.yml              # Site generation config
├── NRCs/
│   ├── README.md
│   ├── NRC-template.md
│   ├── nrc-0001-token-description.md
│   ├── nrc-0002-nft-metadata.md
│   └── ...
├── NXIPs/
│   ├── README.md
│   ├── NXIP-template.md
│   ├── nxip-0001-tailstorm.md
│   ├── nxip-0002-qc-signatures.md
│   └── ...

Benefits of a monorepo structure:

  • Unified navigation: Single location for all Nexa specifications
  • Cross-referencing: NXIPs and NRCs can easily reference each other
  • Simpler maintenance: One repository to manage, one CI/CD pipeline
  • Version control: Full history of proposal evolution and discussions
  • Merge Request workflow: Structured review process with inline comments
  • Issue tracking: Ability to track implementation status and related discussions
  • Accessibility: Public repositories allow anyone to read and reference specifications
  • Static site generation: The repository can be configured to automatically generate a public documentation website (using tools like GitLab Pages, MkDocs, or similar), providing easy navigation and search for all proposals
  • Familiarity: Developers from other ecosystems are accustomed to this model (Bitcoin’s BIPs, Ethereum’s EIPs/ERCs)

5. Governance Summary

Aspect BUIP NXIP NRC
Scope BU organization, membership, operational matters Core protocol, consensus, node software Application standards, implementation specs
Location BU Forum GitLab repository GitLab repository
Format Forum post Markdown (.md/.mdx) Markdown (.md/.mdx)
Approval BU membership vote 3 devs (Draft→Review), dev consensus (→Accepted) 3 devs (Draft→Review), consensus (→Accepted)
Implementation As decided by vote Required for consensus; optional otherwise Voluntary/recommended
Escalation — Can escalate to BUIP if contentious —

Expected Benefits

  1. Developer Experience: Clear, discoverable documentation for protocol and application standards reduces friction for new and existing developers.

  2. Ecosystem Maturity: Establishes Nexa alongside Bitcoin and Ethereum as a blockchain with professional governance and specification infrastructure.

  3. Transparency: All technical evolution of the network is tracked, versioned, and publicly accessible.

  4. Faster Innovation: Technical proposals can move through review without waiting for membership vote cycles, while still maintaining quality through expert review.

  5. Community Trust: Open specification processes build confidence among developers, businesses, and users that Nexa is governed transparently.

  6. Interoperability: Standardized NRCs enable wallets, exchanges, and applications to work together seamlessly.

  7. Historical Record: Future developers and researchers can understand why decisions were made by reviewing proposal discussions and rationale.

  8. Membership Oversight: The BUIP escalation path ensures that contentious technical decisions remain subject to democratic oversight when necessary.

Conclusion

The establishment of NXIP and NRC tracks represents a natural evolution in Nexa’s governance as the network matures. This framework provides the structure necessary to support a growing ecosystem while maintaining the democratic principles that have guided Bitcoin Unlimited—the existing BUIP process remains available as an escalation path for contentious technical matters. By adopting industry-standard practices for technical specifications, we position Nexa for sustainable growth and broader adoption.

2 Likes
2

There is no doubt that the BIP and EIP systems have been very successful and much emulated elsewhere. We do have BUIPs as outlined above, however the major difference is that BUIPs are integrated into a membership voting process, whereas BIPs and EIPs, etc, are not. Some coins have on-chain governance, such as Algorand, but Nexa does not.

From my own personal view, I see the NXIP proposal as very welcome indeed, and it is explained well here, also with NRC as an important component.

However, this BUIP could be simplified, by not making the BUIP system part of it (no changes to the BUIP system are proposed above). NXIPs would not have their own voting protocol, they would exist to facilitate Nexa development discussions and proposal revisioning. Many development proposals can be quite happily discussed and concluded by those doing Nexa development, with or without external comment.

The BUIP system has a role where a NXIP cannot be resolved by development discussion, or it is resolved and there is concern within the BU membership about the functionality a specific NXIP. A BUIP can be raised to conclude or close a NXIP if necessary.

I suggest removing the complicating text about the BUIP process, and simply point out in a paragraph that contentious NXIPs can be resolved by a BU membership vote through the BUIP process. This should be a rare event, but is a permanent safeguard and control.

3

Thanks for the feedback. I’ve simplified the proposal by:

  • Removing the detailed BUIP section since no changes to the BUIP process are proposed
  • Adding a short “Escalation to BUIP” section clarifying that contentious NXIPs can be escalated to a membership vote as a safeguard (this should be rare)
  • NRCs don’t need an escalation path — if there’s disagreement, an alternative NRC can simply be proposed

The governance comparison table remains for clarity, but the focus is now squarely on introducing NXIP and NRC tracks.

1 Like
4

I have a few questions about the process for NXIPs and NRCs.

  1. The definition above says that 3 developer members can approve both an NXIP and NRC. I am assuming that is B.U. Member Developers, is this correct?

  2. How does that work in relation to the B.U. Lead Developer?

  3. Can the Lead Developer veto a proposal?

  4. How does this work in relation to paid BU development work, if an NXIP or NRC is approved does that imply approval for paid development time to work on that initiative?

  5. I believe there already is a proposed NRC process with 3 NRCs already defined, is this a formalisation of that process or is this something different?

Thanks

5

Thanks for the questions.

Yes. That said, this proposal is intentionally high-level on the specifics. In practice, NXIPs (protocol/node changes) should be reviewed by those working on node software, and NRCs (application standards) by those building applications (some people do both). Everyone is welcome to provide feedback on both.

The Lead Developer’s input carries weight, but this isn’t a single-person decision. Proposals should reach consensus among the dev team. If there’s disagreement (and no majority to either side), the proposal stays in Draft/Review status until we work it out.

No individual veto power. The expectation is open discussion and working toward agreement. If someone strongly disagrees with an accepted NXIP, they can raise a BUIP to escalate it to membership vote - same as anyone else.

Approval of an NXIP/NRC doesn’t imply additional budget. These proposals relate to Nexa’s development and exist for the benefit of the network. Work on accepted proposals falls under normal BU development activities.

this formalizes and extends what already exists. The current NRCs lack a proper repository, public visibility, and structured process. The goal is to establish a public, discoverable specification system (like BIP/EIP/ERC) where developers, wallets, exchanges, and users can easily see what standards exist, track new proposals, and indicate support (e.g., “we implement NRC-001”).

6

The way I read the proposal is that the author and any two developers constitute consensus, is this the intention or am I reading it incorrectly?

7

Thanks for the response. Just to be clear this BUIP is saying that an approved NXIP or NRC will not imply additional budget, but does authorize B.U. paid devevlopers to work on that initiative under their existing contract.

8

I’ve updated the proposal to clarify the two-stage process:

  • Draft → Review: Requires 3 developer members (author + 2 reviewers) — this confirms the spec is complete and well-formed, similar to how BIP/EIP editors check that a proposal meets basic quality standards
  • Review → Accepted: Requires consensus among the dev team — this is the actual commitment to implement

So no, 3 developers alone don’t constitute full approval. They only gate the spec into the review stage. Moving to Accepted requires broader dev team consensus.

Correct.

9

Thanks for the clarification.
What defines the dev team? BU member developers? Paid BU developers etc.
I’m trying to think through how this would work in practice.

10

Since Nexa currently has one primary node implementation, “dev team” in practice means BU developers actively working in BU. That said, anyone in the community is welcome to propose an NXIP or NRC — the process is open.

If additional node implementations emerge in the future, the NXIP process should evolve to include representatives from each client team, with consensus reached across implementations. But for now, with a single implementation, BU developers are the relevant parties for reaching consensus on protocol changes.

11

I find this proposal disingenuous, inaccurate, and exploitable. Let us begin with disingenuous. There are currently a few alternate development proposals, most recently around tokens, that have been implemented and deployed in non-BU products. But at BU we have allowed them to be implemented in the explorer and in Otoplo in an effort to support external work.

Coming out of that is the following proposal GroupTokensV2.md · main · Griffith / Group Tokens v2 · GitLab . I am not sure how similar this is to the existing alternate token system in neubla, but they are likely very similar due to having the same author. This may be why the proposal is never changed based on feedback.

This group V2 has not achieved much traction within repeated development meetings, and attempts to circumvent the BU review process and inject it into forthcoming products, because it is primarily a reorganization of existing standards and functionality, without adding valuable new features. Repeated observations that the few features it adds could be easily and efficiently implemented either with a smart contract or incrementally to the existing standard (such as was done with the decimals field) are ignored.

The BUIP is an end run around developers inability to respond to manifest flaws in their proposals.

Moving on to exploitable and inaccurate. To be honest, I am lately exhausted doing retroactive specification work. What I mean is by the time you have pointed out and suggested solutions for multiple significant flaws in something you realize that you are doing the majority of the intellectual labor. Therefore, I am not going to bother to enumerate an exhaustive list of problems, I shall only state a few of them. Yet it should be understood by voters that proposals like this cannot override the BU Articles.

Inaccuracies:

spec.nexa.org and its underlying repository is the “Centralized Technical Specification Repository”

spec.nexa.org is also the “Application Standards Framework”, it contains the standards for application level protocols.

The BUIP process was originally conceived to propose technical changes, “operational” BUIPs came later. It is simple enough to just divide them into categories.
We have used the BUIP process many times to successfully to propose technical changes. Many changes have been proposed and adopted, by many authors, including the author of the GroupV2 spec.

I’m guessing that this proposal exists because the author simply does not like what the above standards repository says, and is guessing based on dev meetings that if GroupV2 is proposed as a BUIP it will be voted down.

Exploitable:

Who decides who the “developer members” are?

“Requires consensus among the dev team”. But “consensus” is not defined. Undefined “consensus” results in politics of power and influence.
If you want to actually learn something important about human nature, read The Tyranny of Stuctureless .

A similar “consensus” based approach is what caused the Bitcoin Cash hard fork and the subsequent stagnation of both Bitcoin and Bitcoin Cash. It should be observed that Bitcoin Cash did not actually restart implementation of significant features until every other major development team had departed, resulting in a “consensus-of-one” that was able to make progress.

“Requires approval from 3 developer members”: This is a carte blanche for any group of 3 people to run off and do whatever they want. The is probably the ultimate aim of this BUIP, to be blunt.

Finally, voters should be aware of course that nothing is stopping the larger community from adopting any discussion or organizational process. They do not need to get BU’s permission to do so. In fact, the dev team first saw the GroupV2 specification in a different format a year or two ago titled something like “NRC001: Group V2” (NRC). However, the author’s attempt to create an independent NRC system was met with apathy, so we see materially the same specification reappear now.

In sum, I recommend that members vote “no” to this BUIP, due to the fact that it is inaccurate, exploitable, and unimplementable according to the BU Articles.

1 Like
12

For details of why it is and will be a tremendous waste of BU resources to allow any 3 developers to pursue whatever they want, let me attach my groupV2 review for your examination. respond with detailed feedback (!1) · Merge requests · Griffith / Group Tokens v2 · GitLab

GroupV2 is very relevant to this BUIP because it is an effort that a subset of our developers have continued to pursue, for over a year now, even though its flaws have been repeatedly verbally communicated and the engineers have been directed (again repeatedly) to come up with a much simpler, directed approach to solve the exact problem.

13

Group V2 is not similar to the NRC proposals. They do not touch the same area. Group v2 is only about on-chain consensus logic. The nebula token standards and NRC stuff are entirely about off-chain data. The NRC stuff was originally called groupv2 for a short period of time in 2023 but as someone pointed out at the time, it did not actually change the group system it only fixed some off-chain data formats. If having a similar name to an old proposal is causing confusion i can change the name from the current WIP groupv2 proposal to something else.

This is an outright lie. The proposal has been edited many times (see git history for recent changes) including following the last dev meeting after which it was edited directly due to feedback from vgrunner, steven, and yourself. It is an actively changing proposal based on review and feedback from others. It is currently on version 3.

Edit: The original proposal suggested moving things into utxo via an op_group opcode. the proposal has changed a lot since then.

This is also an outright lie. It is not possible for Group v2 to “circumvent the BU review process” because it requires a hardfork to be implemented. It must be approved and merged into the full node for it to activate. Bringing the proposal up for discussion in the dev meetings is directly exposing it to the BU review process, the complete opposite of circumvention.

It does add new features and fixes issues with the current system. The purpose of the proposal is to allow for NFT generation without destroying an authority permission in all relevant authorities because it is currently not possible to mint an NFT without doing that.

This BUIP was written by vgrunner. i do not understand why your entire response focuses on me. I am not the author.

Groupv2 probably would be voted down in its current state. This is why i have not put it up for a BUIP this round. It is not done and is still taking on feedback. It may be eventually be put to a BUIP once it is better formed but, again, Group v2 requires a hardfork. It must go through BU developer review. Dodging the BUIP process was never an option unless everyone agreed on the proposal unanimously.

14

What exactly is disingenuous about this? I never wrote any proposal. This BUIP is not related to any specific proposal — it’s to formalize a framework for future proposals. Please point to where I’m being disingenuous.

Who tried to override what? Nothing in this BUIP contradicts the Articles. If it does, please quote the specific conflict.

Let’s be honest here. The current specs site documents features AFTER implementation. The purpose of NXIP/NRC — like BIP/EIP/ERC — is to propose and discuss features BEFORE implementation, with versioning, history, and public review.

These are fundamentally different things, and you know this.

And let’s talk about the current state of spec.nexa.org:

I’m probably among the few people who have actually implemented core Nexa features at the application layer. I had to read C++ code for 80% of the things because the specs site simply doesn’t cover them. So I ask you directly: does spec.nexa.org currently serve developers well? Does it contain complete documentation for all features?

I’ll say this once: this BUIP has nothing to do with GroupV2. I’m not the author of GroupV2. I’ve even pointed out flaws in it to its author. Stop trying to conflate the two.

This proposal exists because Nexa needs to grow. Developers need to understand and review core features BEFORE they’re implemented — with versioning, discussion, and history. That’s it.

This is factually incorrect, and I have to wonder if you actually read the proposal.

The 3 developer members are required to move from Draft to Review — not to Accepted. This is a quality gate, similar to how BIP/EIP editors check that a proposal is complete and well-formed before it enters review.

Moving to Accepted requires consensus among the dev team. That’s the commitment to implement.

To be blunt: if you’re going to publicly attack a proposal, at least read it correctly first.

So this is how it works? You, as the lead dev whose voice carries significant weight, recommend a “no” vote before I’ve even had a chance to respond or discuss? You know exactly what happens when you do this — members will vote “no” without reading the proposal, simply because you told them to.

Have I ever disrespected you to deserve this treatment? Even when we’ve disagreed, I’ve never dismissed your opinions or suggestions. I expected the same courtesy.

And “unimplementable”? Bitcoin has BIP. Ethereum has EIP/ERC. Every mature blockchain has a proposal system like this. What exactly makes it unimplementable for Nexa?

Or is the real concern that decisions might be made where you find yourself in the minority? Because if BU is the kind of organization where one person’s voice is the final word, then let’s stop calling it a “decentralized org” and just call it what it is.

Again — this BUIP is not about GroupV2. I’m not going to keep repeating myself.

But since you keep bringing it up: maybe the reason developers keep pursuing alternatives is because there’s genuine feedback that the current implementation has problems. Instead of dismissing that feedback, perhaps consider why multiple people independently came to similar conclusions.

I’m happy to discuss and refine this proposal based on constructive feedback — that’s the entire point of the BUIP process. What I won’t accept is having my proposal misrepresented and dismissed before I’ve had a chance to engage.

I’d ask that members read the proposal themselves before voting.

15

What exactly is disingenuous about this? I never wrote any proposal.

Yes, you have never written any proposal, so you have no experience with the existing system. Yet you are going to “fix” it.

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). 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.

But maybe it is coincidental, and if so, I am sorry for making assumptions and strongly disagreeing with this BUIP. 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! After having gone through the process, if you have ideas on how to change it, we can talk about them, or you could raise a BUIP with specific suggestions.

Let’s be honest here. The current specs site documents features AFTER implementation. The purpose of NXIP/NRC — like BIP/EIP/ERC — is to propose and discuss features BEFORE implementation, with versioning, history, and public review.

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?

Did you ever even bother to ask what to do? “Hey, I want to make a spec, what should I do?” (no)

If you had other bothered to ask, I would have said “open a MR with your spec to the spec repo, and we will work on it and discuss it in the dev meetings. If we cannot come to an agreement, you can then open a BUIP for the members to vote on your technical proposal.”

Did you open an MR to fix the specs where you found problems? Or did you just leave the problem to other people? 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?

You have made 0 contributions to spec.nexa.org.

stone@theBlock:/ssd/git/cwik/nexaspec/mirror$ git log --no-merges --oneline --author “Andrew” | wc -l
143
stone@theBlock:/ssd/git/cwik/nexaspec/mirror$ git log --no-merges --oneline --author “Griffith” | wc -l
36
stone@theBlock:/ssd/git/cwik/nexaspec/mirror$ git log --no-merges --oneline --author “Andrea” | wc -l
18
stone@theBlock:/ssd/git/cwik/nexaspec/mirror$ git log --no-merges --oneline --author “vgrunner” | wc -l
0

(a bunch of other devs also have a couple of contributions apiece)

16

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.

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.

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.

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.

The specs site is a documentation site, not a proposal system. Using it as one doesn’t make it one.

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.

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.