Summary
Blink's QR scanner rejects QR codes containing a plain Lightning Address (e.g. oink@coinos.io) or the URI form (lightning:oink@coinos.io) with "Invalid QR Code — This is not a valid Bitcoin address or Lightning invoice".
Expected behaviour
Scanning a QR that contains a Lightning Address should open the Send flow with the address pre-filled, the same way it already does when a user pastes or types one into the Send field.
Actual behaviour
Scanner only accepts BOLT11 invoices, on-chain addresses, and bech32-encoded LNURL1... strings. Plain Lightning Addresses — even wrapped in the lightning: URI scheme — are treated as invalid.
Why it matters
Lightning Addresses are the most human-readable payment identifier in the ecosystem and are increasingly used on merchandise, donation signs, hardware displays (e.g. Bitcoin block clocks), and printed materials. Expecting content creators to bech32-encode every address into an LNURL1... blob for QR compatibility creates friction — most other popular wallets (Phoenix, Wallet of Satoshi, Zeus, Alby, Muun, etc.) already handle this.
Steps to reproduce
Generate a QR code with content oink@lightningpiggy.com (or lightning:oink@lightningpiggy.com)
Open Blink → Scan
Observe "Invalid QR Code" error
Suggested fix
In the QR scan handler, after BOLT11 / on-chain / LNURL detection fails, check whether the decoded string matches the Lightning Address pattern (^[a-z0-9._-]+@[a-z0-9.-]+.[a-z]{2,}$, optionally with lightning: prefix stripped). If so, route it through the existing Lightning Address send flow.
Summary
Blink's QR scanner rejects QR codes containing a plain Lightning Address (e.g. oink@coinos.io) or the URI form (lightning:oink@coinos.io) with "Invalid QR Code — This is not a valid Bitcoin address or Lightning invoice".
Expected behaviour
Scanning a QR that contains a Lightning Address should open the Send flow with the address pre-filled, the same way it already does when a user pastes or types one into the Send field.
Actual behaviour
Scanner only accepts BOLT11 invoices, on-chain addresses, and bech32-encoded LNURL1... strings. Plain Lightning Addresses — even wrapped in the lightning: URI scheme — are treated as invalid.
Why it matters
Lightning Addresses are the most human-readable payment identifier in the ecosystem and are increasingly used on merchandise, donation signs, hardware displays (e.g. Bitcoin block clocks), and printed materials. Expecting content creators to bech32-encode every address into an LNURL1... blob for QR compatibility creates friction — most other popular wallets (Phoenix, Wallet of Satoshi, Zeus, Alby, Muun, etc.) already handle this.
Steps to reproduce
Generate a QR code with content oink@lightningpiggy.com (or lightning:oink@lightningpiggy.com)
Open Blink → Scan
Observe "Invalid QR Code" error
Suggested fix
In the QR scan handler, after BOLT11 / on-chain / LNURL detection fails, check whether the decoded string matches the Lightning Address pattern (^[a-z0-9._-]+@[a-z0-9.-]+.[a-z]{2,}$, optionally with lightning: prefix stripped). If so, route it through the existing Lightning Address send flow.