RoadmapsProjects
Sign in./start

Learn

RoadmapsProjects

Contribute

DiscoverIssues

Account

Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute.

Learn

RoadmapsProjectsStart Building

Contribute

DiscoverIssues

Account

Sign inDashboardSettings

Legal

PrivacyTerms

© 2026 Pull // all rights reserved

PrivacyTerms

lesson // lightning

LNURL

Implement LNURL-withdraw, pay, and auth for better wallet UX.

intermediate4 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Explain LNURL as bech32-wrapped HTTP endpoints
  • Implement pay and withdraw flows safely
  • Relate Lightning Addresses to LNURL-pay

study // plan

Lessons are primers. Depth comes from required reading, interactive labs, reflection, and a hands-on check with evidence — the BOSS study pattern.

Research on Bitcoin Search

Reflection prompts

  1. Explain LNURL to a teammate without jargon — what problem does it solve?
  2. What would break in production if you misunderstood LNURL?
  3. Which BOLT (or implementation doc) is the source of truth for this topic, and what did you verify there?

Lab // Polar check

After reading, run one hands-on check related to LNURL. Prefer local regtest or Polar over mainnet.

evidence required

  • ·Command output or screenshot from your local lab
  • ·One sentence on what you observed vs expected
  • ·Link to the required reading section you used

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…

LNURL-pay mints a fresh BOLT11 through an HTTPS handshake.
// Pseudo-flow
// 1) decode lnurl -> https URL
// 2) fetch JSON
// 3) request invoice for amount
// 4) pay bolt11

You inherit web risks

Phishing, TLS failures, and malicious metadata become Lightning UX risks. Validate domains and amounts carefully.

Common 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:

  1. Reproduce the happy path on regtest (or Polar for Lightning)
  2. Break it on purpose (wrong fee, expired invoice, offline peer)
  3. 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.

further reading

  • docsLNURL specifications
  • articleLightning Address
  • docsAlby documentation

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track
prevBOLT12 OffersnextOpening Channels

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.