CLN
CLN is not a Nostr social client. It is a Lightning node implementation that can sit behind Nostr Wallet Connect, BTCPay, Umbrel, Start9, RaspiBlitz, Cashu mints and custom payment services when the operator wants direct node control.
CLN is Core Lightning, not a wallet skin
CLN is the short name most operators use for Core Lightning. It is a Lightning Network node implementation, not a consumer Nostr app and not a wallet interface in the same category as Alby, ZEUS or a mobile ecash wallet. The official docs describe Core Lightning as Blockstream's open-source Lightning implementation optimized for performance and modular expandability. That modular character is why CLN keeps appearing in Nostr payment maps: it is a backend that other products can talk to.
The reader-facing distinction matters. A Nostr app may show a zap button, a checkout button, a donation flow or a wallet-connect prompt, but the money may ultimately move through a CLN node. In that setup, CLN is the engine room. It holds channel state, interacts with Bitcoin Core, manages peers, receives and pays invoices, exposes RPC methods and lets plugins extend behavior. The social app is only the surface.
This also means CLN should be judged with node-operator questions, not app-store questions. You should ask who runs the node, where the database lives, how channels are backed up, which plugins are loaded, what credentials or runes are granted, how upgrades are handled and which Nostr relay carries wallet requests. CLN can give a Nostr user a more direct wallet path, but only if the operational layer is understood.
The project is active and mature
The main repository is `ElementsProject/lightning`. When checked on June 13, 2026, the GitHub API reported 3,071 stars, 999 forks, 348 open issues, creation in June 2015, a June 10, 2026 push and a June 12, 2026 repository update. The repository description calls it a Lightning Network implementation focused on spec compliance and performance. That is a long-running codebase, not a weekend NWC adapter.
The current release state is also important. The GitHub releases API showed `v26.06.1 Quantum-Resistant Lightning Channel II` as the latest stable release, published on June 5, 2026. The larger `v26.06` release introduced a series of operator-facing and developer-facing changes around payment flow, channel close behavior and internal watch infrastructure. Recent commits included watchman startup and typed watch API work, which fits CLN's long pattern of exposing node internals carefully rather than hiding them all behind one hosted dashboard.
Maturity does not mean low effort. CLN is mature because it gives operators powerful surfaces: JSON-RPC, plugins, gRPC, REST, command line tooling, database options, Tor support, Docker images and platform packages. Each of those surfaces adds responsibility. If a Nostr app connects to a CLN-backed wallet, the comfort of the app should not distract the reader from the fact that a real Lightning node is underneath.
CLN sits behind applications
A practical CLN deployment often appears through something else. The installation docs point readers toward third-party applications such as Ride the Lightning, Umbrel, BTCPay Server, RaspiBlitz and Start9 for graphical or packaged experiences. That is how many users meet CLN: not by starting `lightningd` from a terminal, but by choosing a stack that bundles it.
This bundled shape is common in the Nostr world too. A merchant may run BTCPay Server with a Lightning backend. A node appliance may package Core Lightning. A Cashu mint may use CDK payment backends that support CLN. A Nostr client may only know that it received a NWC connection string, while the wallet service behind that string is a CLN plugin. The same backend can serve several product layers.
That is why a CLN article should not oversell the user interface. CLN gives the node its payment brain. The visible app decides how much of that brain is exposed. A good CLN-backed Nostr integration shows enough context to know whether the node can only create invoices, whether it can spend, whether it can list transactions and how the operator can revoke the connection.
This also protects the reader from a common misunderstanding. If a Nostr client says it supports NWC, that does not tell you which wallet implementation, node backend or permission layer sits behind the connection. CLN may be present only as the final Lightning executor. The user may never see `lightning-cli`, the data directory or the channel list. The safest product copy makes that boundary plain: app on the outside, NWC bridge in the middle, CLN node underneath.
The installation path is operator work
The official installation page gives several routes: release binaries, Docker images, source builds and third-party applications. It also makes the Bitcoin Core dependency explicit. A CLN node is not a standalone web wallet. It needs a Bitcoin backend, a data directory, network ports, configuration, channel liquidity and ongoing maintenance.
For source builds, the docs list dependencies such as SQLite support, compression libraries, Python tooling and Rust tooling when Rust plugins like `cln-grpc`, `clnrest`, `cln-bip353` or `wss-proxy` are built. The same page shows Docker usage with mounted Lightning data and exposed ports. These details matter because a broken data mount, old plugin directory, missing Bitcoin backend or accidental container reset can become a funds problem.
A reader should treat CLN like production infrastructure even when the use case is small social payments. The amount may be tiny, but the node still has keys, channels, peers and irreversible state. The right early test is not a large zap from a favorite Nostr app. It is a low-value node setup, a successful invoice, a small payment, a restart, a backup check, a plugin check and then a NWC connection with strict permissions.
Plugins are the reason CLN fits Nostr
CLN's plugin system is the bridge between node software and application-specific behavior. The plugin docs describe plugins as a way to extend Core Lightning and expose additional functionality. Built-in plugins and third-party plugins can add APIs, automate routing choices, connect external services, generate notifications or change how operators interact with the node.
Nostr Wallet Connect fits naturally into that model. NIP-47 does not require every wallet to redesign itself. A wallet service can listen for encrypted Nostr events, interpret wallet requests, check permissions, call the underlying wallet and publish responses. For CLN, a plugin can become that wallet service, translating NWC requests into CLN actions such as creating an invoice, paying an invoice or returning selected node information.
The plugin model is powerful because it keeps CLN focused on node responsibilities while letting Nostr-specific logic live outside the core. It is also risky because plugin quality varies. A plugin may be young, lightly audited, under-maintained or too generous with node authority. Before using a CLN NWC plugin with real funds, review its repository activity, release history, permissions model, relay handling, secrets storage and method mapping.
NIP-47 turns node authority into delegated app access
Nostr Wallet Connect is defined by NIP-47. In plain terms, an app asks a wallet service to perform wallet actions over Nostr. The app does not receive the node's raw keys. It receives a connection string or pairing data, sends encrypted requests through relays, and waits for the wallet service to answer. The wallet service decides what the app is allowed to do.
With CLN, the wallet service is usually not CLN itself in isolation. It is CLN plus an NWC plugin, credentials and relay configuration. That plugin holds or receives enough authority to call CLN. If the app is allowed to `pay_invoice`, the plugin can ask CLN to spend. If the app is limited to invoice creation, the blast radius is different. If the app can read balances or transactions, the privacy boundary is different again.
This is the central mental model for the reader: NWC is not a harmless login. It is delegated wallet authority. It can be beautifully scoped, or it can be dangerous. A CLN-backed connection should have a label, a narrow method set, a small budget where the plugin supports budgets, an expiry or revocation path, and a relay choice the operator understands.
The current CLN NWC plugin landscape is small
The strongest current CLN-specific NWC lead is `daywalker90/cln-nip47`, described by its repository as a Core Lightning plugin to connect wallets via Nostr Wallet Connect. GitHub API data checked on June 13, 2026 showed the repo was created on April 2, 2025, pushed on June 8, 2026 and updated on May 25, 2026, with MIT licensing. Its latest release was `v0.1.9`, published on April 23, 2026.
The older `thesimplekid/cln-nostr-wallet-connect` repository is also relevant because it shows an earlier CLN plugin approach for NIP-47 support. Its GitHub metadata showed creation in March 2023 and a last push in July 2024. That does not make it useless, but it does change how a reader should evaluate it. For new work, the more recently active project deserves closer attention.
This small plugin landscape is a useful caution. CLN itself is mature; NWC-on-CLN is younger. The reader should separate those two statements. A bug in a NWC plugin is not the same as a bug in Core Lightning. A weak permission model in a connector does not mean CLN is weak. It means the bridge between Nostr and CLN needs the same skepticism you would bring to any wallet-access adapter.
RPC, REST and gRPC are different doors
CLN exposes a JSON-RPC command surface that operators and applications can use through `lightning-cli` and the node's RPC interface. The docs also cover REST APIs and gRPC APIs. These are not cosmetic alternatives. They are different doors into a live payment node, and each door needs access control, network boundaries and logs that match the deployment.
The REST documentation describes REST access through CLN's `clnrest` plugin, while the gRPC documentation covers certificate-based gRPC usage through the `cln-grpc` plugin. These interfaces are useful for dashboards, mobile tools, automation and services that cannot live inside CLN's process. They also create extra places where secrets, certificates or firewall rules can be mishandled.
A Nostr Wallet Connect plugin may call the local RPC interface rather than asking the Nostr app to do so directly. That is the right shape: the external app should not get broad node credentials. But the plugin itself still needs a safe relationship with CLN. If it stores a broad rune, runs as the same user, exposes logs or accepts requests from too many relays, the app-facing boundary may be weaker than it appears.
Runes and credentials shape the blast radius
Modern CLN deployments often use runes or scoped credentials to limit what external tools can do. The broad idea is simple: do not hand a dashboard, plugin or service unlimited control when it only needs one task. A receive-only service should not be able to spend. A reporting service should not need payment authority. A zap client may need a narrow spending path with limits.
For NWC this principle becomes visible. The remote app may feel friendly, but under the hood it is asking a node-backed wallet to perform methods. If the plugin's CLN access is broad and the NWC permission layer is broad, the user has stacked two broad permissions. If both layers are scoped, the risk is smaller. That distinction matters more than the branding of the client.
The safest CLN-backed Nostr connection is boring: one app, one purpose, one relay policy, one connection label, minimum methods, small spend limit, short lifetime, easy revocation and readable logs. That does not remove all risk, but it turns a mysterious wallet URL into an accountable permission object.
Backups are not optional
CLN's backup and recovery story is part of the product, not an afterthought. The docs separate the `hsm_secret`, advanced database backup and wallet recovery topics because Lightning node state is more complex than a simple seed phrase. The `hsm_secret` is used to derive the HD wallet's master key, but channel state and database state still matter.
The securing-keys documentation explains that `hsm_secret` can be encrypted, but also warns that this is not the same as a locked Bitcoin Core wallet. `lightningd` needs access to keys while operating. If an attacker controls a running node, encryption at rest is not a magic shield. If the operator loses the password to an encrypted `hsm_secret`, access to funds can be lost.
For Nostr use, backups matter because social payments encourage casual balances. A user may think a CLN-backed zap wallet is just a small app account. It is still a live Lightning node or node account. Before connecting a Nostr client, confirm `hsm_secret` handling, static or emergency backup process, database backup process, channel backup expectations, restore testing and upgrade rollback limits.
Upgrades can change the database
The official upgrade documentation is blunt about database changes: upgrades often change the database, and downgrades are generally not possible once that happens. By default, CLN is conservative about non-release database upgrades. That is exactly the kind of warning that should be visible to anyone using CLN as payment infrastructure for Nostr apps.
The v26.06.1 release date matters here because active software moves. A CLN operator may want the latest bug fixes and features, but a NWC plugin, dashboard, packaged node distribution or payment service may lag behind. Version drift can produce strange symptoms: a Nostr app cannot pay, a plugin fails to start, a REST API changes behavior, or a database migration blocks a downgrade path.
The practical rule is to test upgrades in the stack you actually use. CLN version, Bitcoin Core version, node package, NWC plugin version, relay configuration and dashboards should be checked together. A clean CLN release does not guarantee a clean Nostr wallet-connect experience if the plugin or packaged app has not caught up.
Release notes matter to Nostr apps
Core Lightning release notes are not just node-operator trivia. The v26.06 cycle included payment and node-behavior changes that can affect applications built on top. Blockstream's announcement highlighted features such as `xpay`, `xkeysend`, `sendamount`, BOLT12 payment-proof work, longer channel close grace behavior and a new Bitcoin watch plugin direction. These features influence how reliable and observable a CLN-backed wallet service can feel.
For Nostr, reliability often gets misattributed. If a zap fails, the user may blame the social client. The actual problem could be channel liquidity, a CLN payment method, plugin startup, a relay delay, an expired invoice, a route failure or an NWC permission mismatch. Reading release notes gives builders better instincts about where a failure might be happening.
The reader does not need to follow every CLN commit. But if CLN is the node behind a public payment flow, release awareness is part of care. Watch for security fixes, plugin changes, database migrations, payment command changes, deprecations and backup instructions. Lightning is money software; the release channel is not just a feature newsletter.
Relay choice changes the NWC experience
NWC requests travel through Nostr relays. The relay does not hold the CLN node's funds, but it can affect availability, latency and metadata. If a relay is down, slow, filtered or blocked, the app may fail to reach the wallet service. If a relay is public and heavily observed, it may reveal timing and connection patterns even when request contents are encrypted.
A CLN operator should think about NWC relays the way they think about any dependency. Which relay is used? Is it shared with a large public audience? Is a private or paid relay preferable? Does the plugin support multiple relays? How does it recover after disconnects? Does it log enough to diagnose request failure without leaking sensitive payment details?
This is one of the places where Nostr makes the payment system more flexible and more complex at the same time. A web app can speak to a wallet without a direct TCP connection. That is useful. But the relay layer becomes part of the payment path, and the operator has to monitor it like infrastructure.
Liquidity is the hidden user experience
A CLN-backed Nostr wallet can look perfect while the payment path is liquidity-starved. Lightning payments need channel capacity, routing options, fee awareness and failure handling. A Nostr app may only display a spinning payment state, but CLN has to find a route, satisfy amount and fee constraints, and update channel state. If the node has poor outbound liquidity, zaps fail. If inbound liquidity is weak, receives fail. If channel peers are offline, the user experience looks broken even when the software is behaving honestly.
This is why CLN fits operators who want to understand their node. The node can expose details about peers, channels, invoices, payments and failures that a simple wallet interface may hide. That information is useful when a Nostr payment fails repeatedly to one recipient or through one amount range. The cause might be a relay delay, but it might just as easily be a channel problem, an invoice issue, a fee limit or a payment command behavior that changed across releases.
For NWC, liquidity should shape permissions and expectations. A receive-only connection can be useful even with limited outbound capacity. A spending-capable zap connection needs enough outbound liquidity and a clear maximum spend budget. A merchant or community bot needs monitoring because missed payments can become trust problems. CLN gives you the raw material to debug these issues, but it does not make liquidity disappear.
Packaged nodes change the support boundary
Many readers will not install CLN from source. They will meet it inside Umbrel, Start9, RaspiBlitz, BTCPay Server, Nodana, a Docker stack or a managed server. That is practical and often the right choice, but it changes the support boundary. The package decides the CLN version, plugin paths, configuration defaults, update timing, service supervision, firewall defaults and how logs are exposed.
A packaged node can make CLN approachable while adding its own assumptions. One package may expose a friendly app store and automatic updates. Another may emphasize self-hosted services and backups. BTCPay may use CLN as a commerce backend. A Nostr wallet connector may need to be installed beside the package rather than inside it. If a NWC plugin README assumes a bare CLN install, the packaged-node user has to translate paths, permissions and service restarts into the package's model.
The reader should not treat packaging as a minor detail. Before putting a public Nostr payment path on top of CLN, check whether the package supports the plugin version you want, whether updates are delayed, whether the data directory is easy to back up, whether custom plugins survive upgrades and whether the package exposes enough logs to debug NWC requests. Convenience is valuable, but it should not hide the parts that move money.
Observability decides whether users get answers
Payment support is where backend quality becomes visible. If a Nostr user says a zap failed, the operator needs a way to decide whether the failure happened in the client, the relay, the NWC plugin, CLN, a channel peer, the invoice or the receiving wallet. Without logs and timestamps, every failure becomes folklore. With logs, the operator can map one user action to one request and one node result.
CLN operators should keep observability practical rather than invasive. You need enough detail to diagnose method calls, plugin startup, relay connections, invoice creation, payment attempts, timeouts and permission failures. You do not need to leak secrets, full NWC URLs, bearer credentials, private labels or sensitive invoice metadata into public support channels. A good setup makes the boring facts easy to find and the dangerous facts hard to expose.
For a public Nostr payment service, write down the support path before there is an incident. Which logs are checked first? How is a connection revoked? How is a stuck plugin restarted? How are users told the difference between an unpaid invoice, a failed route and a revoked permission? CLN can give strong answers, but only when the operator treats the node as infrastructure rather than an invisible box behind a purple button.
Privacy is practical, not automatic
CLN supports operator practices that can improve privacy, including Tor-oriented setups and careful node configuration. But privacy does not arrive simply because the backend is self-hosted. A public node advertises channels and peers. A NWC app may learn balances, invoices or transaction history depending on permissions. A relay may observe timing. A hosted dashboard may add its own data flow.
The right privacy question is always specific. Is the Nostr app allowed to read balance? Can it list transactions? Does it create invoices that reveal user labels? Does it pay arbitrary invoices? Which relay transports requests? Is the CLN node public, private, Tor-only or behind a packaged node appliance? Does the plugin write sensitive request content into logs?
CLN gives the operator more control than a hosted custodial account, but control only helps when it is used. Separate connections by app. Avoid sharing broad credentials. Use scoped runes or plugin permissions where available. Rotate and revoke old NWC URLs. Keep relay choices deliberate. Treat payment metadata as something to minimize, not something that disappears.
What to test before connecting a Nostr app
Start with the CLN node alone. Confirm that Bitcoin Core is synced, CLN starts cleanly, peers connect, a small invoice can be created, a small invoice can be paid, channels have the liquidity needed for the intended use and logs are understandable. Restart the node and confirm state survives. Test backup and restore steps before treating any app as production.
Then test the plugin path. Install the chosen NWC plugin from a release you can identify. Read its README, issues, releases and configuration examples. Use a tiny budget. Connect one Nostr app. Grant only the methods the app truly needs. Test invoice creation, payment, balance reads or transaction reads one at a time. Revoke the connection and confirm the app loses access.
Finally test the relay path. Disconnect the relay, change networks, restart CLN, restart the plugin and repeat the payment request. Watch how failures appear to the user. A good CLN-backed Nostr setup should fail clearly. If a payment request hangs without explanation, the operator needs better logs, better relay redundancy or a simpler permission design.
Who should choose CLN behind Nostr
CLN is a strong fit for operators, builders and merchants who want direct Lightning control and are willing to maintain it. It fits BTCPay-style commerce, node appliances, Cashu mint operators, custom Nostr payment services, developer experiments and users who want a serious backend instead of a hosted wallet. It is especially attractive when plugins and automation are part of the product.
It is a weaker fit for readers who want all wallet responsibilities abstracted away. If you do not want to think about Bitcoin Core, channels, liquidity, backups, releases, plugins, relays or permissions, a CLN node may be the wrong first wallet. A hosted NWC wallet, a mobile wallet or a packaged node can reduce the load, though each option moves trust somewhere else.
The clean takeaway is this: CLN can be one of the best Lightning anchors behind Nostr payments, but it is infrastructure. Used carefully, it lets Nostr apps ask for narrow wallet actions while the operator keeps the node. Used casually, it can expose too much payment authority through a plugin or connection string. The difference lives in setup, not branding.
Sources worth opening
Read the Core Lightning website and docs beside the current GitHub releases, then compare the NIP-47/NWC documents with the CLN NWC plugin repositories. CLN is node infrastructure, so the useful reading path is installation, API surface, plugin model, backup, key security, release status and delegated app permissions.
- Core Lightning official website
- Core Lightning documentation portal
- Core Lightning installation documentation
- Core Lightning plugin documentation
- Core Lightning JSON-RPC documentation
- Core Lightning REST API documentation
- Core Lightning gRPC API documentation
- Core Lightning securing keys documentation
- Core Lightning HSM secret documentation
- Core Lightning advanced database backup documentation
- Core Lightning upgrade documentation
- Core Lightning using Tor documentation
- ElementsProject/lightning GitHub repository
- ElementsProject/lightning GitHub API metadata
- Core Lightning releases
- Core Lightning v26.06.1 release
- Core Lightning v26.06 release
- Blockstream Core Lightning v26.06 announcement
- daywalker90/cln-nip47 repository
- daywalker90/cln-nip47 GitHub API metadata
- daywalker90/cln-nip47 v0.1.9 release
- thesimplekid/cln-nostr-wallet-connect repository
- thesimplekid/cln-nostr-wallet-connect GitHub API metadata
- NIP-47 Nostr Wallet Connect
- nwc.dev
- Awesome NWC
- BTCPay Server Lightning Network documentation
- Umbrel app store Core Lightning
- RaspiBlitz project
- Start9 Core Lightning package
- Ride The Lightning
- Cashu Development Kit introduction
- OpenSats Cashu Development Kit project
- Lightning BOLTs repository
- Bitcoin Core
- Core Lightning Docker images
