SHOCKNET primary-source snapshot

Last reviewed: 2026-08-08 UTC

Why this snapshot exists

Lightning.Pub and ShockWallet already had solid product-layer notes, but the named operator boundary above them was still implicit.
This addendum captures the stronger company/entity layer around SHOCKNET: the integrated stack framing, bootstrap and shared-node packaging, white-label positioning, and the first-party claim that Lightning.Pub plus ShockWallet belong to one coordinated ecosystem.

URL: https://www.shock.network/
Key takeaways:
- The homepage says SHOCKNET built the Lightning-Nostr stack so builders can run shared nodes, ship apps, sell data, which is the clearest first-party statement that the organization wants to be read as a coordinated operating stack.
- The site presents multiple adjacent products under one suite rather than treating Lightning.Pub or ShockWallet as isolated repos.
- The page repeatedly frames control and monetization as operator-level concerns: your node, your keys, your revenue.

URL: https://lightning.pub/
Key takeaways:
- The Lightning.Pub landing page positions the product for family-and-friends sharing, business operations, and remote node management rather than for solo-node purism.
- It emphasizes Nostr-native accounts, automated channel management, multi-layer accounting, webhooks, and app connectivity.
- The same page tightly couples Lightning.Pub to ShockWallet’s dashboard flows, which reinforces that the broader stack is meant to be consumed as one integrated operator package.

URL: https://shockwallet.app/
Key takeaways:
- ShockWallet says users can start through bootstrap, self-hosted, or trusted shared-node modes, which is important because the named operator is packaging multiple trust models rather than one neutral wallet binary.
- The FAQ explicitly says Lightning.pub is the engine behind ShockWallet and that both belong to the SHOCKNET open-source ecosystem.
- The site also pushes white-label deployment and business-facing packaging, which strengthens the case for a separate entity note.

URL: https://raw.githubusercontent.com/shocknet/Lightning.Pub/master/README.md
Key takeaways:
- The README describes Lightning.Pub as a Nostr-native account system for running Lightning infrastructure for friends, family, or customers.
- It documents bootstrap peering, guest nprofile sharing, admin connection strings, and ShockWallet pairing, which makes the cross-product onboarding path concrete.
- The README also shows that the operator story is not just about software features but about reducing the deployment and networking burden through one branded distribution.

URL: https://raw.githubusercontent.com/shocknet/wallet2/main/README.md
Key takeaways:
- The README calls ShockWallet the reference client for Lightning.Pub and highlights multiple-node connections, recurring payments, and multi-device sync.
- It says an optional bootstrap node is default on mainnet for new users, which is strong evidence that trust posture and migration workflow are being packaged at the ecosystem level.
- It also frames CLINK as part of the same push to make app connections and delegated Lightning usage easier, which helps justify keeping the company/operator note separate from the product notes.

SHOCKNET clears the bar for a company/entity split because the useful question is not only what do Lightning.Pub and ShockWallet do? but which named operator packages bootstrap onboarding, shared-node business logic, CLINK integration framing, and white-label workflow into the default path users and operators actually inherit?
Keep projects/lightning-pub on the node-side middleware surface.
Keep projects/shockwallet on the client-shell and shared-node-access surface.
Use companies/shocknet for the named operator boundary above those products.