Skip to content
CryptoDecentral

Note

Receive-Only Lightning Is Not a Merchant Stack

Most Lightning talk collapses into shop tills or routing businesses. Receive-only tips need a payable request, inbound capacity, and often a static entry point — not a merchant stack.

2026-09-09 · lightning, receive-only, bolt-11

Receive-Only Lightning Is Not a Merchant Stack

Most Lightning talk collapses into one of two pitches: run a shop till, or run a routing business. Receive-only tips are a different problem. A gratitude signal, a remittance ping, a “thanks for the note” zap — those need a payable request, enough inbound capacity for a non-custodial node to accept it, and often a static entry point so you are not regenerating a QR for every thank-you. They do not need inventory SKUs, settlement dashboards, or a payment-processor brand.

This note is educational. It walks what a BOLT-11 invoice actually encodes, why inbound liquidity is the receive-side constraint, how LNURL-pay and static internet identifiers turn a sticky QR into fresh invoices at the protocol layer, and why that framing matters as a civil-liberty and remittance-signal habit in South Africa and the wider Global South. It is not a wallet ranking, not a checkout tutorial, and not advice to open a shop on Lightning tomorrow.

What an invoice is (BOLT-11)

Lightning’s Basis of Lightning Technology (BOLT) documents define the network as off-chain Bitcoin transfer by mutual cooperation, with on-chain enforcement when peers disagree. BOLT #0’s glossary is blunt: an invoice is a request for funds — destination, amount, expiry, purpose — so the payer can later prove successful payment. You do not paste a Bitcoin address and hope; you present a signed payment request.

BOLT #11 specifies that request as a Bech32 string built for QR codes:

  1. A human-readable part: ln + BIP-173 currency prefix (lnbc on Bitcoin mainnet, lntb on testnet, and so on), plus an optional amount with multiplier letters (m / u / n / p). Amount can be omitted for donation-style “any amount” requests.
  2. A data part: a Unix timestamp, tagged fields, and a compact secp256k1 signature over the human-readable part concatenated with the data (excluding the signature itself). The recovery id lets wallets recover the payee node’s public key when the optional n field is absent.

Required tagged fields matter more than folklore:

  • p — 256-bit SHA-256 payment_hash. The recipient later reveals the preimage; that preimage is proof of payment.
  • s — payment secret, so forwarding nodes cannot casually probe who the final recipient is.
  • d or h — short UTF-8 description, or a hash of a longer description when the inline field is too small.

Optional but operationally important: expiry (x, default 3600 seconds), min_final_cltv_expiry_delta (c), fallback on-chain addresses (f), private-route hints (r), and feature bits (9). Lightning Labs’ invoice docs restate the same map and note the common lightning: URI prefix (not lightning://) so operating systems can hand the string to a wallet.

Frame: A BOLT-11 invoice is a signed, time-bounded request with a payment hash — not a reusable Bitcoin address wearing Lightning lipstick. Reuse patterns live in other layers (LNURL-pay, offers); the invoice itself is one shot.

Why inbound liquidity is the receive problem

Channels are the substrate. BOLT #0 describes a channel as mutual Bitcoin locked so both signatures are required to spend; balances update by exchanging new commitment transactions. When you open and fund a channel yourself, Lightning Labs’ liquidity docs state the starting geometry plainly: all capacity sits on your outbound side. You can send. You cannot receive until capacity moves toward the remote side — either because someone paid you, opened a channel toward you, or you deliberately rearranged balances.

Inbound liquidity (also called remote liquidity) is simply how many sats a channel can still accept from the network. Outbound is how many you can still push. They sum to channel capacity; every successful payment slides the split. Merchant-shaped receive drains inbound and must replenish it. Tip-shaped receive is the same physics at smaller stakes: an invoice with zero inbound capacity is an unpayable request, however correct the Bech32 checksum looks.

Educational consequence for non-custodial receive: generating invoices is cheap; being reachable is not free. Reachability is channel topology plus inbound capacity, not a logo on a tip jar. Custodial balances hide that constraint behind an IOU. Self-custody does not — which is why “receive-only” is a liquidity literacy problem before it is a product category.

LNURL-pay and static QR patterns (protocol level)

BOLT-11 invoices expire and are typically single-use. Stick a one-shot invoice on a printed flyer and it dies. LNURL specs solve the static entry point without pretending the invoice itself is reusable.

LUD-01 defines LNURL as a Bech32-encoded HTTPS or Onion URL. Wallets decode it, then interact with the service by JSON. Uppercase is preferred in QR codes (same Bech32 space-saving habit as invoices).

LUD-06 (payRequest) is the tip-relevant flow:

  1. Wallet GETs the decoded URL.
  2. Service returns callback, minSendable, maxSendable, metadata (as a raw JSON string; must include text/plain), and tag: "payRequest".
  3. User picks an amount inside the advertised bounds.
  4. Wallet GETs callback?amount=<millisatoshi>.
  5. Service returns a fresh Bech32 invoice (pr) for that amount.
  6. Wallet verifies the invoice amount matches what the user chose, then pays.

The sticky QR encodes a URL that mints invoices, not a permanent payment hash. That is the mechanism behind many “static Lightning tip” UX patterns — protocol literacy, not a vendor pitch.

LUD-16 layers human-readable internet identifiers (user@domain) on the same payRequest response: wallets GET https://domain/.well-known/lnurlp/username (or Onion equivalent) and continue as LUD-06. A default _@domain shorthand exists. Again: educational shape of a static receive handle, not a recommendation of any particular host.

BOLT #12 offers (listed in BOLT #0’s index) are the Lightning-native negotiation path for reusable payment identifiers. Treat them as living specification work alongside LNURL — verify against the BOLTs you are reading — and remember most tip UX you still see in the wild is BOLT-11 plus LNURL-style minting.

Why receive-only is a civil-liberty / remittance-signal framing

In South Africa and much of the Global South, small value moves already live inside high-friction rails: mobile-money fees, FX spreads on diaspora support, weekend banking freezes, and platforms that can freeze an account after a ToS vibe-check. A receive-only Lightning tip is not “replace the entire remittance industry.” It is a narrow signal path: gratitude for open work, a family ping, a mutual-aid thank-you — without standing up a merchant stack that invites card-scheme rules, chargeback theatre, or a processor that can gate your inbox.

Civil liberty here is about dependency shape. Who can unilaterally refuse the thank-you? A custodial tip button inherits that operator’s politics and downtime. A non-custodial receive path inherits channel and liquidity reality instead — harder, more honest, and closer to cash-like peer signals when it works. Opaque ledgers and Nostr zaps sit in adjacent lanes; Lightning’s contribution is fast Bitcoin-denominated conditional payments with proof-of-payment preimages, not default privacy. Match the tool to the threat model you actually wrote down.

Receive-only also resists mission creep. Tips do not need SKU catalogues. Remittance signals do not need yield products. Keeping the problem small is how educational framing stays FSCA-safe and politically useful: autonomy of receipt, not a storefront pitch wearing orange branding.

What this note deliberately does not do

It does not rank wallets, LSPs, or Lightning service providers. It does not sell merchant processors, POS apps, or “accept crypto at your till” funnels. It does not discuss prices, yields, submarine swaps as a product, liquidity marketplaces as investments, or personalised custody advice. It does not claim non-custodial receive is always easy, always private, or always the right remittance tool — inbound capacity, routing failures, phone compromise, and KYC edges at cash-out still exist. BOLT-12 maturity across implementations varies; LNURL adds an HTTP(S)/Onion dependency the pure BOLT-11 string does not.

Educational takeaway: receive-only Lightning is invoice literacy + inbound capacity + (often) a static minting URL. Merchant stacks are a different problem. Confusing the two is how tip jars turn into compliance theatre — or into unpayable QR codes that look modern and settle nothing.

Related on CryptoDecentral

Further reading (primary)

Sources

All notes