ShockWallet

• Name: ShockWallet
• URL: https://shockwallet.app/
• Category: Lightning.Pub client shell / shared-node wallet access
• Tags: bitcoin-ecosystem nostr-ecosystem
• Summary: ShockWallet is the phone-and-web client shell for Lightning.Pub. Guest invites, recurring permissions, synced sessions, and light admin reach are the point. Small client note, not a wallet anchor. The named operator boundary around bootstrap defaults, white-label packaging, and the broader stack now lives in shocknet.
• What it does:
  • Connects to Lightning nodes over Nostr and supports multiple node connections instead of just one embedded wallet backend
  • Acts as the reference wallet client for Lightning.Pub, including guest-style shared-node onboarding via nprofile connection flows
  • Supports synced usage across web, Android, and iOS, with multi-device state sync described as using NIP-78
  • Supports recurring payments, pre-authorized payment requests, and static-offer style receive flows for external apps and services
  • Includes an early admin surface for operators using Lightning.Pub
• Key claims:
  • The homepage calls ShockWallet “The Lightning wallet for friends, family, and business” and frames it as part of an open-source stack for sharing a node over Nostr, which is the clearest signal that this is shared-node infrastructure dressed as a wallet client
  • The canonical README says ShockWallet is the reference wallet client for Lightning.Pub, supports multiple node connections, recurring payments, pre-authorized app payments, and multi-device sync via NIP-78; that is enough to classify it as a service-access client rather than a plain consumer wallet
  • SHOCKNET’s site and GitHub organization place ShockWallet beside Lightning.Pub, CLINK, and other Lightning-and-Nostr tooling, which reinforces that the wallet sits inside a broader operator stack instead of standing alone as the main product
• Whitepaper: No canonical standalone ShockWallet whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the official homepage, the canonical repository README, the SHOCKNET site, and the SHOCKNET GitHub organization; see ../whitepapers/shockwallet-primary-sources-2026-05-03.md.
• Sources:
  • https://shockwallet.app/
  • https://raw.githubusercontent.com/shocknet/wallet2/main/README.md
  • https://www.shock.network/
  • https://github.com/shocknet
  • https://raw.githubusercontent.com/shocknet/Lightning.Pub/master/README.md

Internal linkages

• Direct stack beneath it: lightning-pub.
• Company / operator boundary for bootstrap defaults, ecosystem packaging, and white-label workflow: shocknet.
• Stronger wallet-connectivity read: alby.

Protocol / company boundary

• Keep this note on the client-side access shell: guest onboarding, recurring permissions, multi-device sync, shared-node session handling, and the light admin surface.
• Use shocknet when the sharper question is who packages ShockWallet with Lightning.Pub, controls the bootstrap narrative, and sells the broader operator-facing stack.
• That split matters because what does ShockWallet expose? and which named operator packages the easiest path into that stack? are related but not identical questions.

Control surface

• Most authority still lives in Lightning.Pub and the connected node stack. ShockWallet mainly decides how that shared-node authority reaches user devices: guest onboarding, recurring-payment consent, synced sessions, and light admin actions.

• The named operator and product-packaging shell above that client experience now points upward to shocknet when the question is bootstrap defaults, stack distribution, or white-label positioning.

• Treat it as the client shell for a stronger service layer, not as a wallet-category anchor on its own.

• Last reviewed: 2026-08-08 UTC