Lightning Transport Protocols: BOLT12, CLINK, L402 and NWC Design & Comparison
Summarising here some notes I've been consolidating about the comparison of the four protocols that currently serve as transport layers for Lightning Network interactions, written from the perspective of the architectural decisions that define what each protocol can and cannot do.
## Overview
The Lightning Network has no single standardized transport layer. When a wallet needs to request an invoice, a node needs to send a payment, or an app needs to authorize a transaction, each pair of participants must agree on how to communicate. Four protocols have emerged in the past years competing for this role, and each makes fundamentally different choices about where identity lives, how messages route, and what infrastructure the endpoints must run.
Before looking at the protocols themselves, it helps to name the constraints that from my perspective any viable Lightning transport has to navigate:
**Receive without a server.** If a protocol requires an HTTP endpoint or a hosted wallet service to receive payments, it excludes self-custodial mobile users, Tor users, and anyone behind a Carrier-grade NAT. Those are most of the people who would benefit most from self-sovereign Lightning.
**Traverse NAT and firewalls.** The majority of Lightning nodes are not reachable on the open internet because most implementations decided Tor was the default. A transport that depends on inbound TCP connections or publicly routable IP addresses will only work for a minority of deployments.
**Support both, sending and receiving, on the same layer.** Unidirectional protocols force developers to stitch together multiple systems. Every seam is a place where user experience degrades, a key gets exposed, or a payment fails silently.
**Minimize external dependencies.** Every dependency on DNS (censorship), HTTP (surveilllance) infrastructure, a specific relay operator, or a third-party routing node is a potential point of failure by censorship or surveillance.
With those constraints in mind, here is how the four protocols compare (in alphabetical order):
| Dimension | BOLT12 | CLINK | L402 | NWC (Nostr Wallet Connect) |
| --------------------------- | ------------------------------------------------------------------------------- | -------------------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ |
| **Transport Layer** | Lightning onion messages (BOLT #12) | Nostr relay events (kind 21001/21002/21003) | HTTP (REST/gRPC) | Nostr relay events (NIP-47, kind 23194/23195) |
| **Identity** | Node pubkey (blinded paths) | Nostr pubkey (NIP-05 optional) | Macaroon or token plus preimage (stateless) | Nostr pubkey (per-connection ephemeral keys) |
| **Encryption** | Onion encryption (hop-by-hop) | NIP-44 (end-to-end) | TLS (transport) plus macaroon HMAC | NIP-44 preferred; NIP-04 legacy still common |
| **Directionality** | Bidirectional (offer leads to invoice request leads to invoice) | Bidirectional (Offers, Debits, Manage) | Unidirectional (server gates access) | Unidirectional (wallet as service) |
| **Receive without server** | Yes. Onion messages only. | Yes. Nostr relay only. | No. Requires HTTP server. | No. Requires hosted wallet service. |
| **Works behind NAT or Tor** | Partial. Onion messages unreliable in practice. | Yes | No. Requires inbound HTTP. | Yes (relay mediated) |
| **Infrastructure Required** | Onion-message-capable LN node (CLN, LDK, or Eclair) | Nostr relay (ephemeral events, no storage) | HTTP server or reverse proxy (Aperture) | Nostr relay (durable events) plus hosted wallet service |
| **Static Identifiers** | `lno1...` offers | `noffer1...`, `ndebit1...`, `nmanage1...` | HTTP 402 plus `WWW-Authenticate` header | `nostr+walletconnect://...` URI. No static receive code. |
| **Invoice Format** | BOLT12 invoices (native) | BOLT11 (returned over Nostr) | BOLT11 (returned in 402 response) | BOLT11 (returned over Nostr) |
| **Preimage Return** | Inherent (protocol native) | Yes | Required. Authentication fails without it. | Yes (wallet dependent) |
| **Maturity** | Spec merged September 2024. CLN, LDK, Eclair native. LND via LNDK sidecar only. | Early production. Zeus, Lightning.Pub, ShockWallet, CLINK SDK. | Production. Lightning Labs Aperture used in Loop and Pool. | Production. Alby, Primal, Damus, Phoenix, and others. |
| **Web Compatible** | Not natively. Requires onion-message bridge. | Yes (Nostr DM over WebSocket) | Yes (native HTTP) | Yes (via Nostr relay WebSocket) |
| **AI Agent Ready** | Low. No agent tooling exists. | Emerging. SDK exists, no MCP yet. | High. MCP server in Aperture. Lightning Agent Tools released. | High. SDKs in JavaScript, Rust, Python, Go. MCP gap remains. |
| **LND Support** | Via LNDK sidecar only (no native LND support) | Yes, via Lightning.Pub on top of LND | Yes, native LND REST | Yes, via LNC, CLNRest, LndHub |
***
## BOLT12 (Offers)
**Philosophy.** Extend the Lightning protocol itself. Keep everything inside the LN graph. No external transport. No web infrastructure. No Nostr.
### How It Works
The receiver publishes a static `lno1...` offer. This string encodes the receiver's terms: accepted currency, optional amount, description, and a blinded path that routes to the receiver's node without revealing its identity. The sender's wallet reads the offer and sends an `invoice_request` message over Lightning onion messages, traveling through the blinded path. The receiver's node generates a fresh BOLT12 invoice with a unique payment hash and returns it over the same onion message channel. The sender then pays via standard HTLC forwarding. Each payment gets its own hash and preimage, so the offer itself is safe to publish anywhere.[^2] BOLT12 has been heavily [discussed here in SN](https://stacker.news/search/r/deSign_r?q=%22BOLT12%22&what=posts)?
### Design Decisions That Shaped BOLT12
The decision to use onion messages as the transport layer was the defining architectural choice. Onion messages are the only communication channel that exists inside the Lightning protocol itself, so staying native meant accepting their constraints. These messages are asynchronous, have no guaranteed delivery timeline, and must be routed through participating nodes that may be offline or slow. The tradeoff was deliberate: protocol purity and privacy (blinded paths prevent the sender from learning the receiver's node identity) in exchange for reliability and web accessibility.
The blinded path design was a second defining decision. Rather than exposing the receiver's node pubkey, the offer encodes a path through intermediate nodes. This means the sender never learns who the receiver is. But it also means the offer is tied to specific routing topology. If the intermediate nodes go offline, the offer becomes unreachable until the receiver publishes a new one.
### Pros
* Native to Lightning. No external dependencies. No HTTP. No Nostr. No DNS.
* Privacy by design. Blinded paths hide the receiver's node identity. Fresh payment hash per invoice.
* Reusable static offers. Safe to publish on websites, in podcast feeds, and on QR codes.
* Spec merged. Officially part of the BOLT specification as of September 24, 2024, the first new BOLT added since 2017.[^1]
* Pull payments. Can request invoices, which makes agent-to-agent flows possible.
* Subscription ready. Supports recurring payment flows natively.
### Cons
* Onion message unreliability. Asynchronous delivery over the LN graph can be slow. Not practical for web applications that expect synchronous responses.
* Not web friendly. Browsers cannot send onion messages. Requires a bridge or dedicated node client.
* LND holdout. LND has no native support. Available only through the experimental LNDK sidecar daemon.[^3]
* Three native implementations (CLN, LDK, Eclair) but the dominant node implementation is not among them.
* No existing agent tooling. Zero MCP servers or agent-facing SDKs despite architectural suitability.
### End User Experience
For the end user, BOLT12 is invisible when it works and mystifying when it does not. A user who scans a BOLT12 offer from a merchant's website expects to pay instantly. If the onion message takes thirty seconds to deliver or never arrives at all (because an intermediate node in the blinded path is offline), there is no clear error message. The user sees only a spinner or a timeout. The privacy benefits are real but invisible, while the reliability problems are immediate and frustrating. For node operators, the experience is better: CLN users enable offers with a flag and get reusable payment codes without maintaining a web server. But for the typical mobile wallet user, BOLT12 remains years away from being a reliable daily driver.
***
## CLINK (Common Lightning Interface for Nostr Keys)
**Philosophy.** Use Nostr as the transport layer for all Lightning interactions. Replace HTTP callbacks, onion messages, and pre-shared secrets with signed events published to Nostr relays.
### How It Works
The publisher creates a `noffer1...` string. This bech32-encoded payload carries the recipient's Nostr pubkey, a recommended relay URL, and offer metadata including pricing hints. When a client scans or pastes this string, it decodes the TLV data, generates an ephemeral keypair, NIP-44 encrypts a request payload, and publishes a kind 21001 event to the recommended relay. The recipient's wallet (for example Lightning.Pub) picks up the event, generates a BOLT11 invoice, and publishes a response. The client sanity checks that the invoice amount matches the offer and then hands it off to the existing payment flow.[^4]
CLINK extends this pattern in two additional directions. Debits (kind 21002, encoded as `ndebit1...`) authorize a remote party to request payments from your node. Manage (kind 21003, encoded as `nmanage1...`) enables delegated node administration with configurable permissions.[^5] All three use the same Nostr event infrastructure, the same NIP-44 encryption, and the same relay-based delivery.
### Design Decisions That Shaped CLINK
The choice to build on Nostr rather than invent a new transport was the decisive architectural move. Nostr provides cryptographic identity (every message is signed), a relay-based delivery model (no inbound connections needed), and a well understood event system. CLINK did not need to solve identity, encryption, or message routing. It inherited those from Nostr and defined only the application-layer semantics: what events mean, how offers encode, how debits authorize. [Few](https://stacker.news/items/1003716/r/deSign_r) [conversations](https://stacker.news/items/1018586/r/deSign_r) here on SN as early as last year.
The ephemeral event design was a deliberate departure from NWC's approach. CLINK events do not require relay persistence. A relay that refuses to store events can still forward them. This means CLINK works with lightweight relays that have no disk footprint, and it leaves no permanent metadata trail of who requested what from whom.
The decision to define three distinct interaction patterns (Offers, Debits, Manage) rather than a single generic RPC method reflects a different philosophy about protocol design. Each pattern encodes a specific relationship: someone offering to be paid, someone authorized to request payment, someone delegated to manage permissions. This makes the protocol more constrained and therefore more analyzable. A wallet can make precise policy decisions about each pattern without interpreting opaque RPC arguments.
### Pros
* No web server required. Operates entirely over Nostr relays. Ideal for mobile, Tor, and behind-NAT setups.
* Bidirectional. Same transport for sending, receiving, offers, debits, and delegated management.
* Builds on Nostr identity. Leverages existing key infrastructure, NIP-05 names, and web-of-trust.
* Ephemeral events. Works with relays that do not persist data. No storage footprint.
* Blinded path support available. Privacy on par with BOLT12.
* Trivially web friendly. Nostr direct messages use WebSocket transport. No onion-message hurdles.
### Cons
* Tied to Nostr ecosystem. Requires Nostr relay infrastructure. Centralization risk if relays consolidate.
* Immature. Spec still evolving. Limited wallet and node implementations.
* Nostr relay dependency. If the recommended relay is down, the offer is unreachable, though multi-relay configuration mitigates this.
* Fast-growing smaller community. Far fewer developers and integrations than NWC or L402.
### End User Experience
For the end user, CLINK offers the simplest mental model. You have a reusable string that lets people pay you. You share it like a Lightning Address, but nothing breaks if your server goes down because there is no server. The wallet handles the Nostr communication transparently. When you want to authorize a marketplace to pull payments from you (for example a subscription or a usage-based service), you share a debit pointer and set a budget. The marketplace requests payment when needed, your wallet checks the budget, and approves or rejects automatically. The user never sees an invoice, never copies a BOLT11 string, never waits for an onion message. The experience is closer to Venmo than to raw Lightning, but without the custodial dependency.
The main friction today is wallet availability. A user who wants to try CLINK needs ShockWallet or a patched version of another wallet. That is a real barrier. But for users already in the Nostr ecosystem, CLINK integrates naturally. The same key that signs their notes can sign their payment requests. Recently [Zeus](https://stacker.news/items/1492370/r/deSign_r) and [Ametyst](https://stacker.news/items/1510180/r/deSign_r) have implemented CLINK.
***
## L402 (Lightning HTTP 402 Protocol)
**Philosophy.** Activate HTTP's long dormant 402 status code. Combine Lightning Network payments with cryptographic authentication tokens to create a pay-per-request protocol for web services.
### How It Works
The client sends an HTTP request to an L402-gated endpoint. The server responds with HTTP 402 Payment Required and a `WWW-Authenticate` header containing a token (a macaroon is the recommended format) and a BOLT11 Lightning invoice. The token commits to the payment hash of the invoice, which enables stateless verification. The client pays the invoice and obtains the preimage. The client retries the original request with an Authorization header of the form `L402 <base64(token)>:<hex(preimage)>`. The server validates the token's HMAC chain and confirms that the SHA-256 hash of the preimage matches the payment hash stored in the token. If both checks pass, the server serves the resource. No database lookup is required.[^8][^9] Read [what stackers are saying](https://stacker.news/search/r/deSign_r?q=%22L402%22&what=posts) about L402.
### Design Decisions That Shaped L402
The stateless verification design was the key architectural insight. By embedding the payment hash in the token, the server can verify payment without contacting a database or a Lightning node at the time of request. This makes L402 suitable for distributed systems where validation and resource serving may happen on different machines.
The choice of macaroons (rather than JWTs or simple API keys) reflects a specific set of requirements. Macaroons support attenuation: a service can hand a macaroon to a client and the client can derive a more restricted macaroon for a sub-agent. They also support third-party caveats, which could enable delegation to other payment services. The protocol specification was updated in bLIP-0026 to use the generic term "token" rather than "macaroon," opening the door to alternative formats, but macaroons remain the reference implementation.
The decision to use HTTP as the transport was pragmatic but limiting. HTTP is universal, works with every programming language, and is trivially compatible with existing web infrastructure. But it also constrains L402 to request-response patterns where the client initiates contact. There is no server-to-client payment flow, no push notification, no persistent connection.
### Pros
* Web native. Pure HTTP. Works with curl, browsers, and any HTTP client. Zero new infrastructure.
* Stateless verification. Servers do not need a payment database. The token plus preimage is self-validating.
* Token agnostic. The bLIP-0026 specification uses "token" rather than "macaroon" as the key name. Any token format that commits to the payment hash works.[^10]
* Agent native. Agents can discover, pay, and consume APIs without human registration. Aperture ships with an MCP server for native agent control.[^11][^13]
* Production ready. Aperture has been used in production by Lightning Labs for Lightning Loop and Pool since launch.[^12]
* Standardized. Formalized as bLIP-0026, a Bitcoin Lightning Improvement Proposal.[^10]
### Cons
* HTTP only. Limited to web and API gateways. Does not address P2P payments, wallet-to-wallet, or mobile transport.
* Failure driven model. The protocol begins with a rejection (402). Requires a round trip of pay and retry.
* No identity layer. Stateless by design. No persistent user identity between requests. Not suitable for ongoing budgeted relationships where the user expects to be recognized.
* Preimage required. Payment succeeds but API access fails if the wallet does not return the preimage. Common wallets including Primal and OpenNode do not expose preimages.
* Unidirectional. Server gated. The client is always the payer. No offer semantics, no debit semantics, no receive flow.
### End User Experience
For the end user, L402 is interesting primarily because of what it removes. No signup form. No API key management. No billing dashboard. The first time you hit an L402-gated endpoint, your wallet fires, you approve the payment, and the resource loads. Every subsequent request uses the cached macaroon until it expires or the balance depletes. For one-shot API access (for example a single LLM inference or a data lookup), this is the best experience available. You pay exactly once and move on.
The friction appears when the user's wallet does not return preimages. The payment succeeds, the money leaves the wallet, but the API still returns 402 because the client cannot construct the credential. The user sees a confusing state: charged but denied access. This is not a theoretical edge case. It happens with several widely used wallets today. The protocol is unforgiving about this.
***
## NWC (Nostr Wallet Connect)
**Philosophy.** Remote control for Lightning wallets over Nostr. Define a standardized API that lets applications send payment requests to a wallet and receive responses, with permission scoping built in.
### How It Works
The wallet generates a connection URI with the format `nostr+walletconnect://<wallet_pubkey>?relay=<relay_url>&secret=<client_secret>`. This URI encodes the wallet's public key, a relay for communication, and a randomly generated secret that the client will use to sign and encrypt messages. The user shares this URI with an application by scanning a QR code, following a deeplink, or entering it manually. Once connected, the application sends encrypted NIP-47 events to the wallet via the relay.[^6] The event kind is 23194 for requests and 23195 for responses. Supported methods include `pay_invoice`, `make_invoice`, `lookup_invoice`, `get_balance`, `get_info`, and `list_transactions`. The wallet verifies that the requesting key is authorized for the specific method, decrypts the payload, executes the operation, and returns the result. NWC has been largely [discussed here](https://stacker.news/search/r/deSign_r?q=%22NWC%22&what=posts) too.
### Design Decisions That Shaped NWC
The decision to model NWC as a remote procedure call protocol rather than a transport protocol was architectural, not accidental. NWC assumes a client-server relationship. One side (the wallet) is always the service provider. The other side (the app) is always the client. This makes NWC excellent for its intended use case (apps that need to trigger payments from a user's wallet) and unsuitable for anything that requires symmetric peer-to-peer interaction.
The per-connection keypair design was a pragmatic security decision. Each NWC connection uses an ephemeral key pair rather than the user's main Nostr identity key. This means a compromised connection does not expose the user's primary key, and revoked connections leave no ability to request new payments. The tradeoff is that managing connections becomes a UX problem. The user needs to generate, share, and revoke connection strings. NWC wallets have addressed this with QR codes and deeplinks, but the mental overhead is higher than a protocol where identity is implicit.
The decision to use Nostr relays rather than direct connections was about NAT traversal and mobile compatibility. A mobile wallet behind a carrier-grade NAT cannot accept inbound TCP connections. By placing a relay in the middle, NWC ensures that both parties can communicate regardless of their network topology. The cost is that the relay sees all event metadata (though not the encrypted payload content) and becomes a potential bottleneck or surveillance point.
### Pros
* Production ready. Widely deployed across Alby, Primal, Phoenix, Damus, and others. Over 350,000 users.[^7]
* Permission scoped. Granular controls including daily limits, per-transaction caps, and method-level scoping.
* Mature SDKs. JavaScript, Rust, Python, Go. WebLN adapter for browser-based wallets.
* One-click connections. OAuth-like flow for publicly accessible wallets. Nostr flow for mobile or self-hosted.
* Wallet agnostic. Works with custodial, self-custodial, and node-backed wallets.
* Strong agent readiness. A well designed MCP server wrapping NWC would unlock broad AI agent Lightning payments.
### Cons
* Wallet as service, not transport. NWC is fundamentally a remote RPC protocol. It assumes a persistent, hosted wallet service on the other end. There is no NWC flow where two parties interact directly.
* Cannot receive without a hosted service. Receiving a payment via NWC requires a wallet service that is always on and internet reachable. A mobile wallet behind NAT cannot receive NWC requests. This is an architectural constraint, not an implementation gap.
* No static payment codes. NWC defines how to control a wallet remotely, not how to advertise a payable identity. There is no NWC equivalent of a Lightning Address or BOLT12 offer. Receiving requires pairing LNURL or CLINK on top.
* Durable event storage. Unlike CLINK's ephemeral events, NWC typically relies on relay persistence. This creates a metadata footprint of payment activity.
* Preimage dependent. Some NWC wallets do not return preimages, which breaks downstream protocols like L402.
### End User Experience
NWC delivers the most polished experience of any protocol in this comparison, within its domain. A user who wants to zap a note on a Nostr client clicks a button, scans a QR code that their wallet generates, and from that point forward the zaps happen without further ceremony. For in-app payments (topping up a balance, buying a digital good, tipping a creator), the flow is similar. The wallet connection is set up once and the app handles the rest.
The limitations show up when the user wants to do anything outside the app-to-wallet pattern. Receiving money, for example, requires a separate protocol. The user needs a Lightning Address or an LNURL link. If the user is self-custodial and running their own node behind NAT, receiving is a configuration challenge. The wallet app needs a bridge service that is publicly reachable, or the user must rely on a custodial provider. This split between sending (NWC, great) and receiving (some other protocol, variable) is the single biggest UX gap in the NWC ecosystem.
For users who are not running their own node, NWC works seamlessly. The wallet provider handles the infrastructure. The user just connects and pays. But that convenience comes with a tradeoff. The wallet provider sees the user's payment history, controls availability, and can impose spending limits. For many users this is acceptable. For users who want self-sovereign Lightning, it is a real compromise.
***
## Conclusion: What Each Protocol Teaches us about Sats Transport Design
The four protocols designed for different problems, and each one' strengths map directly to the constraints they chose to accept.
BOLT12 is the most principled protocol in this group from a pure Lightning perspective. It is native, private, and spec-canonical. For developers working on Lightning node implementations or protocol research, BOLT12 is the right foundation. The user benefit is subtle but real over time. Reusable offers eliminate the invoice generation step. Blinded paths protect receiver privacy. Subscription flows become possible without external infrastructure. But the practical constraints are severe. LND does not support it. Onion messages are unreliable. The web is inaccessible without bridges. BOLT12 is the long term answer for in-protocol payments, but most developers building user-facing applications today will find these constraints too limiting.
CLINK is the only protocol that started from a different question. Not *"how do we control a wallet remotely"* or *"how do we gate an API"* or *"how do we define offers inside the existing protocol.*" The question was ***"how do two parties communicate about Lightning payments over a decentralized network without any of them running a server?"*** That question leads to a different set of design decisions. Identity comes from Nostr keys, not from a node pubkey or a pre-shared secret. Transport comes from Nostr relays, not from the LN graph or HTTP. The protocol is bidirectional by construction because anything less would leave half the payment lifecycle uncovered.
For developers, the benefit of CLINK is architectural economy. A single protocol gives you offers for receiving, debits for pull payments, manage for delegation, and identity for persistence across sessions. You do not stitch together NWC for sending, LNURL for receiving, and L402 for API access. You wire up one SDK, define your policies against one event model, and the transport handles the rest. The developer experience today is constrained by the small ecosystem, but the surface area is well defined and the SDK is functional.
For end users, the benefit of CLINK is a unified mental model. One identifier that lets people pay you. One authorization flow that lets services request payment from you. One wallet that manages both without distinguishing between "sending mode" and "receiving mode." The UX ideal is an environment where the wallet passively listens for payment requests, applies the user's policy (auto approve small amounts, ask for confirmation on large ones, reject unknown requesters), and the user never copies an invoice or waits for a message to deliver. That is the design target CLINK is aiming at. Whether the ecosystem reaches critical mass is an open question, but the architecture is built for a world where sovereign peers interact directly, not for a world where every payment goes through a hosted intermediary.
L402 solves API monetization with cryptographic rigor. For developers who want to charge per request for an API endpoint without building a billing system, L402 is elegant and production proven. The stateless verification design means you can scale authentication without scaling a payment database. The user benefit is the elimination of signup friction. No account creation, no API key provisioning, no credit card form. Pay once and the resource is yours. But L402 is unidirectional and HTTP bound. It does not help a mobile wallet receive a payment, and it breaks silently when the wallet does not return a preimage. For its narrow domain it is excellent. Outside that domain, it is not applicable.
NWC solves wallet remote control better than anything else in the ecosystem. For developers building an app that needs to trigger payments from a user's existing wallet, NWC is the right choice today. The SDKs are mature, the deployment surface is wide, and the permission model gives reasonable safety guarantees. The user benefit is clear. Users connect once and pay without friction. The architectural limitation is equally clear. NWC is not a transport protocol. It does not define how two peers discover each other, how they negotiate payment terms, or how they maintain a relationship over time. For those things, you bring another protocol.
This was a great exercise to place everything we have on the table for a fair analysis. Users don't care about the tech powering their everyday tools, but yes, it needs to work. More than spotlighting all of them, the answer is now for you to take, build and use the protocols that best suit your needs.
***
## Footnotes
[^1]: BOLT12 officially merged into Lightning specification, September 2024. [https://x.com/niftynei/status/1838568847701360861](https://x.com/niftynei/status/1838568847701360861) ; [https://www.nobsbitcoin.com/bolt12-offers-officially-merged-into-lightning-spec/](https://www.nobsbitcoin.com/bolt12-offers-officially-merged-into-lightning-spec/)
[^2]: LDK Blog, "BOLT12 Has Arrived." [https://lightningdevkit.org/blog/bolt12-has-arrived/](https://lightningdevkit.org/blog/bolt12-has-arrived/)
[^3]: BOLT12 Developers Overview, LNDK documentation. [https://bolt12.org/developers](https://bolt12.org/developers)
[^4]: CLINK Protocol by ShockNet. [https://clinkme.dev](https://clinkme.dev/) ; [https://github.com/shocknet/clink-demo](https://github.com/shocknet/clink-demo)
[^5]: CLINK SDK (`@shocknet/clink-sdk`) on npm. [https://www.npmjs.com/package/@shocknet/clink-sdk](https://www.npmjs.com/package/@shocknet/clink-sdk)
[^6]: NIP-47: Nostr Wallet Connect Specification. [https://github.com/nostr-protocol/nips/blob/master/47.md](https://github.com/nostr-protocol/nips/blob/master/47.md)
[^7]: NWC Protocol Overview and Documentation. [https://nwc.dev/](https://nwc.dev/) ; [https://docs.nwc.dev/](https://docs.nwc.dev/)
[^8]: L402 Introduction and Motivation. [https://github.com/lightninglabs/L402/blob/master/introduction.md](https://github.com/lightninglabs/L402/blob/master/introduction.md)
[^9]: L402 Protocol Specification and Aperture Reference. [https://docs.lightning.engineering/the-lightning-network/l402](https://docs.lightning.engineering/the-lightning-network/l402)
[^10]: L402 bLIP-0026 Specification. [https://github.com/Roasbeef/blips/blob/697ae354c205f1aacc450e72067c92a7f2467321/blip-0026.md](https://github.com/Roasbeef/blips/blob/697ae354c205f1aacc450e72067c92a7f2467321/blip-0026.md) ; [https://github.com/lightning/blips/pull/26](https://github.com/lightning/blips/pull/26)
[^11]: Aperture Reverse Proxy Documentation. [https://docs.lightning.engineering/lightning-network-tools/aperture](https://docs.lightning.engineering/lightning-network-tools/aperture)
[^12]: Lightning Labs (2026). "The Future Is Now: Why L402 Is the Internet-Native Payments Protocol for Agents." [https://lightning.engineering/posts/2026-03-11-L402-for-agents/](https://lightning.engineering/posts/2026-03-11-L402-for-agents/)
[^13]: The Block (February 2026). "Lightning Labs Releases AI Agent Tools for Native Bitcoin Lightning Payments." [https://www.theblock.co/post/389584/lightning-labs-releases-ai-agent-tools-for-native-bitcoin-lightning-payments](https://www.theblock.co/post/389584/lightning-labs-releases-ai-agent-tools-for-native-bitcoin-lightning-payments)
https://stacker.news/items/1513920
