Process: LUD number conflicts and missing merge governance

[AxelHamburch]

Summary

This is a meta-issue about a structural problem in this repository:
LUD numbers are being self-assigned by PR authors before merge, with no central
assignment process. The result is multiple open PRs competing for the same number,
and technically sound proposals sitting unmerged for years.

This is not a spec proposal. It asks for a governance decision.

---

The Current Conflict Map

Claimed Number	PR	Description	Status
LUD-21	(merged)	verify base spec	✅ Official
LUD-21	#200	pinLimit for withdrawRequest	Open since Feb 2023
LUD-21	#207	Amount in local unit	Open
LUD-21	#243	Onchain addresses as optional field	Open
LUD-22	#252	Payee Data	Open
LUD-22	#283	Lightning address request	Open (self-renumbered to #23)
LUD-24	#242	Chained LNURLs	Open

Three separate PRs claimed LUD-21 after it was already merged. Two PRs claimed
LUD-22 simultaneously. This is not a one-off — it is a systemic issue.

---

Root Cause

There is no documented process for:

• Who assigns LUD numbers
• What criteria trigger a merge
• Who has merge authority and is actively exercising it

PR authors self-assign numbers at submission time. Without coordination, conflicts
are inevitable.

---

A Concrete Example: PR #200

PR #200 (pinLimit for withdrawRequest) illustrates the problem:

• Open since February 2023 — over 2 years
• 2 formal approvals from active community members
• Already in production in at least 3 projects: Bolt Card Wallet, SwissBitcoinPay, LifPay
• Technically backward-compatible and optional
• Main objection ("is this a real problem?") has since been answered by real-world adoption
• Originally claimed LUD-21 — that number is now taken by a merged spec

The proposal is sound. It has no home because the process is broken, not because
the spec is wrong.

---

Confusion Risk: "LUD-21" now means two different things

In the community, "LUD-21" is used to refer to both:

1. The official verify spec (merged)
2. The PIN/pinLimit proposal (PR LUD-21: pinLimit for withdrawRequest - resolves #201 #200, unmerged but widely implemented)

This ambiguity is already causing implementation confusion. Implementations
referencing "LUD-21 PIN support" are not implementing the official LUD-21.

---

Proposed Solutions

Option A — Number assigned at merge, not at PR open

PRs use a placeholder like LUD-XX or LUD-DRAFT. A maintainer assigns the
final number only when the PR is approved and ready to merge. This is how most
successful spec repos work (e.g., BIPs, SLIPs).

Option B — Maintainer triage queue

A designated maintainer reviews open PRs quarterly and either assigns a number
(signaling merge intent) or closes with a reason. No open-ended limbo.

Option C — Community vote for stalled PRs

PRs open longer than 12 months with 2+ approvals and production implementations
get a 2-week comment window, then a maintainer makes a binding decision.

---

Questions for Maintainers

1. Is this repository still actively maintained?
2. What is the criteria for merging a LUD?
3. Can we establish a LUD-XX placeholder convention for new PRs?
4. What needs to happen for PR LUD-21: pinLimit for withdrawRequest - resolves #201 #200 to either be merged or formally closed?

Happy to help draft a CONTRIBUTING.md or governance document if that would
move things forward.

[andrerfneves]

It's been pretty organic during the earlier days, but lots of folks moved on to other projects. I'm currently working on a new lnurl[dot]dev website and lightningaddress[dot]com site to improve understanding of the protocol and showcase the many innovations around it. Was hoping to dedicate more time to this repo as well in this process.

Recently met with @ethanrose and few others and touched on the LUD21 issue specifically. Also want to solve this and merge these.

My view is we come up with a CONTRIBUTING format / process that is straightforward, and we ensure some sense of longevity when designing these extensions. Tbh, it would be great to do a little clean up such that there's a proper plugin/hook system available, but I don't see that being easy to pull off.

Do we need X number of wallets/implementations running it in production in order to prove it? Are we going to set specific criteria here?

[AxelHamburch]

Thanks for the context and for still being engaged with this — good to know
the LUD-21/pinLimit issue is already on your radar.

To answer your question on criteria directly: I'd suggest something like:

• 2+ approvals from community members
• At least one wallet-side and one service-side production implementation
• No unresolved technical objections

I've opened two PRs that try to put this into practice:

• Draft: LUD-XX – pinLimit for withdrawRequest (PIN protection for NFC/Boltcard) #290 — a clean resubmission of the pinLimit proposal (originally PR LUD-21: pinLimit for withdrawRequest - resolves #201 #200),
  using LUD-XX as a placeholder so the number gets assigned at merge time.
  Two verified production implementations are linked in the spec.
• docs: add minimal CONTRIBUTING.md #291 (or whichever number) — a minimal CONTRIBUTING.md that documents
  the criteria above and the LUD-XX placeholder convention. Nothing fancy —
  just enough that contributors and reviewers have a shared reference.

Happy to adjust either based on your feedback. And agreed on the plugin/hook
system — would be ideal long-term, but not a blocker for moving forward with
what we have today.

[andrerfneves]

Sounds good to me. Let's get #291 merged in to begin the cleanup

[AxelHamburch]

I've already implemented this myself. I used it in my ZapBox project. In the backend, I used an LNbits wallet with the BoltCards extension. Since it works, I've written a pull request #67 to make it a permanent part of the code.

[andrerfneves]

Closing this since we've begun making the necessary changes.