PeerPay URI Scheme for BRC-29 Payments

Deggen ([email protected])

Abstract

This BRC defines the peerpay URI scheme, a compact, human-shareable encoding for initiating a BRC-29 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) 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 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 can add peerpay URI handling by registering the scheme with the host operating system and parsing the URI as described above.