Cowrie Research

clink

3 min read

CLINK

  • Name: CLINK
  • URL: https://github.com/shocknet/CLINK
  • Category: Lightning interoperability specification / Nostr-native payment-and-debit protocol / wallet-to-service control plane
  • Tags: bitcoin-ecosystem
  • Summary: CLINK is a small Nostr-native Lightning protocol family for reusable offer, debit, and management flows. The useful point is the Nostr transport and delegation model, not some new Lightning base layer: it is mostly a service-side alternative to LNURL-style callbacks and a broader workflow cousin to Nostr Wallet Connect.
  • What it does:
    • Defines Nostr-native standards for common Lightning interactions between wallets, nodes, apps, and services
    • Specifies CLINK Offers via static noffer1... codes so applications can request fresh BOLT-11 invoices over Nostr without requiring a public HTTPS endpoint
    • Specifies CLINK Debits via static ndebit1... authorization pointers for event-driven payment requests and approvals
    • Specifies CLINK Manage via nmanage1... delegation flows so external applications can manage offers and related actions for a user or service
    • Documents concrete event kinds for the protocol and an implementation table spanning wallet, server, bridge, SDK, and demo surfaces
    • Positions itself as Nostr-native infrastructure that can still integrate with traditional web application flows through bridges and webhooks
    • Publishes a demo client and SDK showing address discovery, invoice generation, and debit-based payment flows
  • Key claims:
    • The canonical README says CLINK defines Nostr-native standards for Lightning interactions using Nostr transport, identity, and encryption, which strongly supports cataloging it as interoperability infrastructure rather than a product feature
    • The same README says CLINK’s goal is to standardize common Lightning interactions without traditional web-infrastructure dependencies while remaining web-friendly and self-custodial
    • The README explicitly frames CLINK Offers as noffer1... static payment codes and CLINK Debits as ndebit1... authorization pointers, making the spec more like a family of interactive protocols than a single endpoint pattern
    • The README contrasts CLINK with NWC, saying NWC is focused on wallet remote control while CLINK defines broader interactive service and payment workflows over Nostr, which is an important classification clue
    • The repository materials publish event kinds and an implementation-status table naming Lightning.Pub, ShockWallet, Bridgelet, the CLINK SDK, and web demos, which shows CLINK already behaving like a shared protocol surface
    • The demo README says everything flows through Nostr without HTTP callbacks, WebSockets, or Tor-like onion messages, and it demonstrates Lightning-address discovery, offer-driven invoice generation, and debit-driven invoice payment, which grounds the protocol in concrete operational flows
    • The GitHub repository page explicitly positions CLINK against LNURL, BOLT12, and NWC, which is useful mainly as a classification clue: this is a narrower Nostr-mediated workflow layer, not a Lightning category anchor
  • Whitepaper: No canonical standalone CLINK whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the canonical spec README, repository page, and demo-client materials; see ../whitepapers/clink-primary-sources-2026-05-03.md.
  • Sources:

Internal linkages

Control surface

  • The real leverage sits in relay dependence, pointer issuance, wallet or service defaults, and how much debit or management authority a user gives an app through static CLINK pointers.

  • Last reviewed: 2026-06-05 UTC

Graph View

Backlinks