LNURL is a family of bech32-encoded URLs that help wallets interact with services over HTTPS for pay, withdraw, auth, and more. Lightning Addresses (name@domain) typically resolve to LNURL-pay.
Why this matters
Users hate pasting huge BOLT11 strings. LNURL and Lightning Addresses make Lightning feel like emailing money, with server-side responsibilities you must secure.
Analogy
LNURL is a short coat-check ticket that maps to a locker (HTTPS API) where the real invoice is minted when you arrive.
Pay flow (simplified)
Loading diagram…
// Pseudo-flow
// 1) decode lnurl -> https URL
// 2) fetch JSON
// 3) request invoice for amount
// 4) pay bolt11Common mistakes
- Trusting amounts displayed by a service without checking invoice fields
- Skipping success/error URL handling on withdraw
- Logging sensitive k1 secrets from auth flows
Worked mental model
Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.
Hands-on habit
Every protocol idea should be paired with one local experiment:
- Reproduce the happy path on regtest (or Polar for Lightning)
- Break it on purpose (wrong fee, expired invoice, offline peer)
- Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
That habit turns reading into builder instinct.
Glossary check
Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.
Resource order
Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.
Next steps
Open channels, move from UX protocols to the capacity that carries payments.