Glossary / Developer reference
R parameter
- Definition
- The R parameter is the BIP72 addition to a bitcoin URI that replaces the payment address with a URL your wallet is expected to fetch a signed request from.
Specified in BIP-72.
Scanning a QR code carrying an r parameter tells your wallet to fetch a web page before it shows you anything. BIP72 arrived on July 29, 2013 and used a bare r rather than the req-r spelling reserved for mandatory keys, so older wallets could ignore it and pay the address instead. No checkout you meet today will hand you one.
How it works
The r parameter is a query key holding a percent-encoded HTTPS URL, and BIP72 defined two shapes for it. The compatible shape keeps a normal address in the URI and appends the key after it, so a wallet that has never heard of the payment protocol pays the address while a wallet that understands r ignores the address and fetches the request. The stripped shape drops the address entirely, giving something like bitcoin:?r=https://store.example/i/8f3a, which older software cannot pay at all.
Making the key optional was a deliberate reading of BIP21, whose grammar splits unrecognized parameters into two classes: anything prefixed req- must cause a wallet to refuse the URI, anything else may be skipped. Naming the field r rather than req-r therefore chose graceful degradation. BIP72 spelled out the opposite behavior as well, so a merchant who genuinely could not accept a bare address payment could write req-r and force incompatible wallets to stop rather than send funds the checkout would not reconcile.
What came back from the URL was a protocol buffer served under the MIME type BIP71 registered for it. BIP73 then added content negotiation, letting the same link return a payment request to a wallet and an ordinary human web page to a browser, distinguished by the Accept header the client sent.
Where you see it
The r parameter turns up nowhere in current use. Bitcoin Core stopped following these URLs when release 0.20.0 removed payment protocol support, and the merchant tooling that once generated them has been replaced by software issuing plain BIP21 URIs and Lightning invoices. A payment page that still produces an r parameter is running an integration nobody has touched in years, and paying by another route is the sensible response.
The habit the field should leave you with outlasts the field. A QR code is unreadable to a human, so scanning one is an act of trust in whatever produced it: a screen, a printed invoice, a sticker stuck to a machine. The r parameter made that literal by handing your wallet a URL to contact, which also exposed your IP address to the merchant's server before you agreed to anything. The same exposure exists in a duller form with an ordinary address QR code that somebody has quietly swapped. Confirm the destination on a display the scanner does not control, which on a hardware wallet means the device's own screen, and compare enough characters to be sure rather than glancing at the first four.
R parameter vs bitcoin URI
A bitcoin URI is the whole string; the r parameter was one optional key inside it. What separates them is direction of authority. Keys such as amount, label and message decorate a destination that already sits in the URI, and a wallet can ignore every one of them and still send money to the right place. The r parameter inverted that relationship: wherever it was understood it overrode the address completely, moving the decision about where funds go from the string in front of you to a server somewhere else.