# PeerPay URI Scheme for BRC-29 Payments Deggen () ## Abstract This BRC defines the `peerpay` URI scheme, a compact, human-shareable encoding for initiating a [BRC-29](/payments/0029.md) peer-to-peer payment. The URI encodes the recipient's identity key (a DER-encoded compressed secp256k1 public key) and an optional satoshi amount, enabling wallets, QR codes, NFC tags, and clickable links to trigger BRC-29 payments without requiring a Paymail address or an active HTTP endpoint. ## Motivation BRC-29 payments require the sender to know the recipient's identity key. Today that key is typically discovered through Paymail ([BRC-28](/payments/0028.md)) or an out-of-band channel. There is no standardised URI format that a recipient can publish, print, or embed to let any BRC-29–capable wallet initiate a payment in a single tap or scan. The `bitcoin:` URI scheme (BIP-21) solves this for address-based payments. `peerpay` solves the equivalent problem for identity-key–based BRC-29 payments: it is self-contained, stateless, and requires no server-side resolution. ## Specification ### Syntax ``` peerpay-URI = "peerpay:" identity-key [ "?" query ] identity-key = 66HEXDIG ; 33-byte DER-encoded compressed secp256k1 public key query = param *( "&" param ) param = sats-param / extension-param sats-param = "sats=" 1*DIGIT ; payment amount in satoshis (BSV) extension-param = token "=" *pchar ``` * `identity-key` MUST be exactly 66 lowercase hexadecimal characters representing a 33-byte compressed public key (prefix byte `02` or `03`). * `sats` MUST be a non-negative integer. A value of `0` is treated as unspecified. Wallets SHOULD allow the user to override the amount when `sats` is absent. * Unknown query parameters MUST be ignored by conforming parsers to allow forward-compatible extensions. * The scheme name `peerpay` is case-insensitive per RFC 3986; implementations SHOULD normalise to lowercase before processing. ### Example ``` peerpay:020307452080baba84b28027a4f4152fd9d29bb4f9c966684f71e7f9427380f2a4?sats=12345 ``` This URI requests a payment of **12 345 satoshis** to the identity key `020307452080baba84b28027a4f4152fd9d29bb4f9c966684f71e7f9427380f2a4`. Amount omitted (wallet prompts user): ``` peerpay:020307452080baba84b28027a4f4152fd9d29bb4f9c966684f71e7f9427380f2a4 ``` ### Wallet Handling When a conforming wallet receives a `peerpay` URI it MUST: 1. Decode and validate `identity-key` as a 33-byte compressed secp256k1 public key. 2. If `sats` is present and greater than zero, pre-populate the payment amount field with that value; otherwise prompt the user for an amount. 3. Present the payment confirmation UI. 4. On confirmation, execute a [BRC-29](/payments/0029.md) payment to the decoded identity key for the agreed amount. Wallets MUST NOT broadcast a transaction before the user explicitly confirms. ### Registration Implementers wishing to register the `peerpay` URI scheme with IANA should follow the procedures in RFC 7595. Until formal registration, the scheme is treated as a provisional BSV-ecosystem convention defined by this BRC. ## Security Considerations * **Key validation** — Wallets MUST reject URIs whose `identity-key` is not a valid compressed secp256k1 public key. Accepting an invalid key would result in unrecoverable funds. * **Amount tampering** — URIs transmitted over untrusted channels (e.g. QR codes rendered by third-party services) may have the `sats` value altered. Wallets SHOULD display the amount prominently and require explicit user confirmation. * **No authentication of the URI itself** — A `peerpay` URI does not attest to the identity of the party who generated it. Higher-level trust is the responsibility of the channel through which the URI was received (e.g. a signed message, a verified website). * **Replay** — Paying the same `peerpay` URI multiple times sends separate independent BRC-29 payments. Applications that need idempotent payments MUST apply their own deduplication logic. ## Implementations Any wallet or application that implements [BRC-29](/payments/0029.md) payments can add `peerpay` URI handling by registering the scheme with the host operating system and parsing the URI as described above. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://bsv.brc.dev/payments/0125.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.