Cowrie Research

webln

3 min read

WebLN

  • Name: WebLN
  • URL: https://www.webln.dev/
  • Category: browser-to-wallet interoperability standard / Lightning web-app provider API / permissioned wallet-connectivity infrastructure
  • Tags: bitcoin-ecosystem
  • Summary: WebLN is a browser injection API for Lightning apps, not a wallet and not a broad request protocol. The point is the permissioned provider surface between a webpage and whatever wallet wins the browser slot, not some deeper settlement or negotiation layer.
  • What it does:
    • Defines a common provider model so web apps can request access to a user’s Lightning wallet or node from the browser
    • Standardizes core methods such as enable, getInfo, sendPayment, keysend, makeInvoice, signMessage, and verifyMessage
    • Ships a client library that can be installed from npm/yarn or loaded directly in the browser for Lightning-enabled web applications
    • Publishes TypeScript-oriented docs, typings, and error handling guidance so both apps and wallet providers can implement compatible behavior
    • Supports a growing ecosystem of wallet providers and clients, with the docs explicitly listing Joule, Alby, BlueWallet, kwh, and Blixt Wallet as examples
    • Enables Lightning-native web use cases beyond payments alone, including invoice creation, decentralized identity and authentication flows, and message-signing-based verification
  • Key claims:
    • The official docs describe WebLN as “a library and set of specifications for lightning apps and client providers to facilitate communication between apps and users’ lightning nodes in a secure way”
    • The docs say WebLN provides “a programmatic, permissioned interface” for letting applications ask users to send payments, generate invoices, and more
    • The reference repo describes WebLN as “a way of interacting with a user’s Lightning node via the browser,” which is the clearest signal that it should be cataloged as interoperability infrastructure rather than as a wallet app
    • The docs explicitly say developers may want WebLN if they accept or make Lightning payments, want decentralized identity/authentication in their app, or are building a wallet provider for web apps
    • The repo’s provider interface includes both payment flows and identity-style methods like signMessage and verifyMessage, showing the surface is broader than invoice submission alone
    • The documentation’s “WebLN In the Wild” section lists both provider implementations and production applications, reinforcing that WebLN acts as a shared coordination layer between many wallets and many apps
    • The repo warns that the spec is still in early stages and subject to change, which is important context when treating it as a living interoperability surface rather than a finalized standard
  • Whitepaper: No canonical standalone WebLN whitepaper or litepaper surfaced in this pass. The clearest current sources of truth are the official documentation site and the reference GitHub repository; see ../../whitepapers/webln-primary-sources-2026-05-03.md.
  • Sources:

Internal linkages

Control surface

  • The real leverage sits in provider injection, permission prompts, method coverage, and which wallet-browser combination becomes the default path for Lightning web apps.

  • Last reviewed: 2026-06-05 UTC

Graph View

Backlinks