Cowrie Research

clink-primary-sources-2026-05-03

3 min read

CLINK primary sources — 2026-05-03

Project status in this pass

  • No canonical standalone CLINK whitepaper or litepaper surfaced.
  • The clearest current source of truth was the canonical CLINK README, the GitHub repository page, and the demo-client materials.
  • The materials consistently frame CLINK as a Nostr-native interoperability specification for Lightning interactions rather than as a single wallet feature or a product-specific API.
  • The surrounding SHOCKNET materials also show that CLINK already has reference implementations across server, wallet, bridge, SDK, and demo surfaces.

Primary-source snapshots

1) Canonical README

  • URL: https://raw.githubusercontent.com/shocknet/CLINK/master/README.md
  • Key excerpt:
    • The README says CLINK defines Nostr-native standards for Lightning interactions using Nostr transport, identity, and encryption.
    • It says the primary goal is to provide standardized Nostr-native methods for common Lightning interactions while reducing dependence on traditional web infrastructure.
    • It defines CLINK Offers (noffer1...), CLINK Debits (ndebit1...), and CLINK Manage (nmanage1...) as the core protocol family.

2) GitHub repository page

  • URL: https://github.com/shocknet/CLINK
  • Key excerpt:
    • The repository page says CLINK unlocks new use cases relative to LNURL, BOLT12, and NWC.
    • It explains that CLINK is committed to Nostr as the foundation for a next generation of decentralized Lightning applications.
    • It also highlights the implementation-status section and the specification pages.

3) Implementation-status section in README

  • URL: https://raw.githubusercontent.com/shocknet/CLINK/master/README.md
  • Key excerpt:
    • The README names Lightning.Pub as a reference server, ShockWallet as a wallet implementation, Bridgelet as a bridge, and the CLINK SDK plus web demos as implementation surfaces.
    • This is strong evidence that CLINK is already being treated as a shared protocol layer rather than a private internal draft.

4) Demo client README

  • URL: https://raw.githubusercontent.com/shocknet/clink-demo/master/README.md
  • Key excerpt:
    • The demo README says it showcases the three core interactions defined by CLINK: Lightning-address discovery, Offers, and Debits.
    • It says everything flows through Nostr without HTTP callbacks, WebSockets, or Tor-like onion messages.
    • It walks through turning a Lightning Address into a clink_offer, requesting an invoice from a noffer, and paying via an ndebit flow.

5) Surrounding product materials

  • URL: https://raw.githubusercontent.com/shocknet/wallet2/main/README.md
  • Key excerpt:
    • ShockWallet’s README says SHOCKNET is pushing the boundaries of Nostr and Lightning integration with CLINK to create more secure app connections with better UX than currently available.
    • This helps confirm that CLINK is meant as reusable application-service infrastructure across the broader SHOCKNET stack.

Working conclusion

CLINK is best cataloged as Lightning interoperability and wallet-to-service control-plane infrastructure. The deciding evidence in this pass was the recurring combination of protocol naming, static identifiers (noffer, ndebit, nmanage), explicit event-kind tables, reference implementations across several products, an SDK plus web demo, and the explicit contrast with NWC, LNURL, and BOLT12. The key distinction is that CLINK is standardizing interactive Lightning workflows over Nostr rather than merely providing one product’s wallet API or a thin transport wrapper.

Graph View