Lightsats primary sources — 2026-05-01

Project status in this pass

  • No canonical standalone whitepaper or litepaper surfaced.
  • The clearest current source of truth is the official site, the public API reference, and the open GitHub repo for the main app and scheduler.
  • The evidence in this pass points to Lightsats being a hosted Bitcoin gifting and onboarding workflow with backend reminder/reclaim logic, not a decentralized protocol.

Primary-source snapshots

1) Top-level README

  • URL: https://github.com/lightsats/lightsats/blob/main/README.md
  • Key excerpt:
    • The README opens with “Gift sats without losing them✌🏼” and sends users to https://lightsats.com to create a tip.
    • It also links a roadmap and API docs, which makes clear that Lightsats is meant to be operated as an ongoing product rather than as a one-off demo.

2) Homepage product framing

  • URL: https://github.com/lightsats/lightsats/blob/main/app/pages/index.tsx
  • Key excerpt:
    • The homepage source highlights three core product promises: “Gift sats without losing them,” “Progress tracker,” and “Onboarding is on us.”
    • The explanatory text says unclaimed sats return to the sender, that tippers can follow recipients along their journey, and that recipients are guided into installing their own wallet to withdraw.
    • This is the clearest concise framing of Lightsats as a gifting-plus-onboarding workflow.

3) API reference

  • URL: https://lightsats.github.io/Lightsats-API-docs/
  • Key excerpt:
    • The docs say: “Welcome to the Lightsats API! You can use our API to access Lightsats API endpoints to automate the management of Lightsats tips.”
    • The table of contents includes endpoints for getting all tips, getting a single tip, creating a tip or tip group, funding tips, deleting tips, and updating tips.
    • The example response fields also include claimedFromPrintedCard and claimWebhookUrl, which strongly suggests Lightsats is more than a simple hosted invoice page.

4) Profile and wallet-linking flow

  • URL: https://github.com/lightsats/lightsats/blob/main/app/pages/profile.tsx
  • Key excerpt:
    • The profile page includes first-party fields for Lightning Address and references LNURL-auth wallet linking.
    • The page explicitly nudges users without a Lightning Address to get one from Alby.
    • This is useful evidence that recipient onboarding into Lightning wallets is part of the intended product flow, not an afterthought.

5) Scheduler README

  • URL: https://github.com/lightsats/lightsats/blob/main/scheduler/README.md
  • Key excerpt:
    • The scheduler is described as a Fly machine run on a schedule “to manage things such as sending reminders to tippees to withdraw their tips.”
    • This is important because it shows operational backend logic around claim/withdrawal state rather than a stateless protocol pattern.

6) Scheduler implementation

  • URL: https://github.com/lightsats/lightsats/blob/main/scheduler/src/index.ts
  • Key excerpt:
    • The scheduled job fetches reminders from /api/reminders, posts reminders back to that endpoint, fetches expired reclaimable tips, and calls /api/tipper/tips/{id}/reclaim.
    • In plain terms: Lightsats runs explicit reminder and reclaim loops in backend infrastructure.

7) App environment example

  • URL: https://github.com/lightsats/lightsats/blob/main/app/.env.example
  • Key excerpt:
    • The app is configured around LNBITS_URL, LNBITS_API_KEY, and LNBITS_USER_ID, with optional Twilio, Short.io, Sentry, and SMS-related settings.
    • This is a strong operational signal that Lightsats is built as a hosted Lightning application stack with centralized service integrations.

8) Reminder logic

  • URL: https://github.com/lightsats/lightsats/blob/main/app/pages/api/reminders.ts
  • Key excerpt:
    • The reminder route says it will only send reminders for tips that are CLAIMED but not withdrawn, and explicitly notes it only sends reminders for CUSTODIAL tips “for now.”
    • The route sends reminder emails or SMS messages with a withdrawal link.
    • This is some of the strongest primary-source evidence that the current operating model is application-layer and custodial in at least part of the flow.

Working conclusion

Lightsats is best understood as a hosted Lightning gifting and onboarding control plane. The decisive clues were the reclaim-if-unclaimed promise, bulk/group and printed-card flows, the first-party API for tip lifecycle management, LNbits-centric service wiring, and a dedicated scheduler that sends reminders and reclaims expired tips.