NIP-002: Payment URI Scheme - #2
Open
codewordneptune wants to merge 2 commits into
Open
Conversation
Documents a `neptunecash:` payment URI convention (BIP 21 equivalent) for links, QR codes, and deep-linking: motivation, the existing undocumented `NPT:` QR practice, the URI specification with provisional test vectors, open questions, and a comparison of payment URI schemes in other cryptocurrencies. The scheme is spelled out in full rather than as a bare `neptune:`, because the Neptune Privacy (XNT) fork also answers to "Neptune" and OS-level URI handler registration is a single global namespace. The same reasoning gave Bitcoin Cash `bitcoincash:`. Based on the RFC and review discussion in Neptune-Crypto/neptune-core#959.
This was referenced Aug 4, 2026
Major additions and corrections from multi-round review against neptune-core sources, peer payment URI specs (BIP 21, ZIP 321, EIP-681, Solana Pay, SEP-0007), and independently re-derived QR capacity tables: - Six-step Parsing section: decode exactly once, after splitting, on values only; names and amounts matched literally; '+' is a literal plus; malformed escapes, invalid UTF-8, fragments, '//' authority syntax, and empty components reject; duplicates reject even for unknown names; explicit req- classification order. - Amount grammar: digits on both sides of the separator, no leading zeros, at most 30 decimal places, bounded by max supply; exact decimal arithmetic required, binary floating point forbidden (Neptune's nau range exceeds IEEE 754 exact integers, unlike Bitcoin's and Zcash's atomic units). - Address types: four-type table with mainnet HRPs, base plus network character rule (m/t/z/r), deterministic rejection classification, closed-world rule for future types; whole nsymk family banned since raw symmetric encodings carry the spending key and digest-only display strings share the HRP. - Security considerations are normative: confirmation before signing or broadcasting, inert rendering of untrusted metadata which never determines the destination, no wallet-controlled persistence of nsymk URIs, EcHybrid and viewing addresses MUST NOT be presented as public or reusable requests. - QR guidance corrected and quantified: generation payloads need level L from version 36 up; parameterized generation URIs need mixed-mode segmentation (549-byte query budget at 40-L); worst-case EcHybrid URI is 1773 bytes, fitting version 31-L single-segment byte mode. - 36 test vectors covering the new rules, including case-sensitive names, exactly-once decoding, decode-order injection, and leading-zero rejection. - Migration guidance for the legacy NPT: payload, handler registration etiquette and scheme-squatting note, resolved rationale sections recording the scheme-name poll and QR decisions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Author
|
@Sword-Smith, @aszepieniec, ready for review. The poll favored neptunecash: and Thorkil gave the go-ahead, so the latest commit is the revised spec: parsing rules, test vectors, address-type rules, security and QR guidance. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds NIP-002, a payment URI scheme for payment links, QR codes, and deep-linking, following up on the RFC discussion in Neptune-Crypto/neptune-core#959. Format follows NIP-001 (#1).
Feedback especially welcome on:
neptunecash:rather than theneptune:originally proposed in the RFC. Open question 2 in the document explains the change: the name "Neptune" is now contested by a fork, and OS-level URI handler registration is a single global namespace.