CoinOS primary sources — 2026-05-02

Project status in this pass

  • No canonical standalone whitepaper or litepaper surfaced.
  • The clearest current source of truth was the CoinOS frontend/server repository corpus and linked public site/docs URLs.
  • The public coinos.io and coinos.io/docs routes exposed mostly client-rendered shell output to basic fetch tooling in this pass, so the GitHub READMEs were materially more useful than the rendered site for recovering product structure.

Primary-source snapshots

1) Frontend repository README

  • URL: https://raw.githubusercontent.com/coinos/coinos-ui/master/README.md
  • Key excerpt:
    • The README says CoinOS is a web-based Bitcoin and Nostr client.
    • It says users can either use CoinOS as a front end to their personal Bitcoin and Lightning nodes or host a public instance where anyone can register with a username and password.
    • It also points developers to API documentation exposed at a /docs route when running the app.

2) Classic frontend README

3) Server repository README

  • URL: https://raw.githubusercontent.com/coinos/coinos-server/master/README.md
  • Key excerpt:
    • The README describes CoinOS as a stack of coordinated components rather than a single web page.
    • It lists CoinOS Server, Bitcoin, Liquid, Core Lightning, KeyDB, Nostr, and Cashu Nutshell among the integrated pieces used to support the full feature set.
    • It documents Docker-based bootstrapping plus setup flows that create Bitcoin and Liquid wallets and load sample data, reinforcing that operators are deploying an actual payments-and-node environment.

4) Public site and docs routes

  • URLs:
  • Key excerpt:
    • Both routes were reachable in this pass but returned mostly Svelte/client-bootstrap shell content to basic fetch tooling.
    • That still confirms public website and docs endpoints exist, but not that they are the best retrievable source of operational truth without a browser-rendered pass.

Working conclusion

CoinOS is best cataloged as a web-based Bitcoin-and-Nostr wallet/control-plane stack that can either front personal infrastructure or operate as a public multi-user service. The most decisive evidence in this pass was the repeated combination of self-hostability, multi-rail Bitcoin support, and a backend architecture that coordinates node software plus communication/payment components rather than merely presenting a simple hosted wallet UI.