CraysCoinos
Coinos is easiest to understand as a practical Bitcoin payment counter that moved onto the web: a wallet account, a merchant point of sale, a Lightning address, a Nostr profile and an NWC connection manager living behind one browser app.
A Bitcoin wallet built for people standing at a counter
Coinos is not trying to feel like a node dashboard. Its public story starts with a much more ordinary scene: someone wants to receive sats at a cafe, event table, small shop or personal payment page without explaining channels, liquidity, invoice expiry and node management first. That merchant-first instinct is still visible in the product. A Coinos account gives a user a balance, a username, a Lightning address, a public payment URL, QR codes, payment history and settings that include point-of-sale details.
The project was created by Adam Soltys in Vancouver. In a Bitcoin News interview published on March 18, 2025, Soltys described the first version as a tool for local merchants: they could enter a Bitcoin address, get payment notifications and know the fiat value at the time of sale. After Lightning became more practical, he rebuilt Coinos as a Lightning wallet. That background matters because Coinos has always cared less about looking ideologically pure on a feature matrix and more about making payment acceptance feel immediate.
The current repositories describe Coinos as a web-based Bitcoin and Nostr client. That wording is useful. Coinos is a wallet, but it is also a web app, a point-of-sale surface, a payment page, a Nostr account surface and an NWC wallet service. It belongs in the Nostr wallet conversation because it lets Nostr apps control payments over Nostr Wallet Connect and because Coinos itself has been moving toward a combined Bitcoin wallet and Nostr client experience.
The hosted service is simple by design
The hosted Coinos experience is deliberately approachable. The Plan B Academy tutorial walks through creating an account with a username and password, landing in a wallet interface, receiving through QR codes, sending to addresses or usernames, and installing the web app to a phone home screen. The PWA manifest names the app Coinos, describes it as the easiest way to get started with Bitcoin, starts at /start, runs in standalone display mode and registers Bitcoin protocol handlers.
That simplicity is the selling point. A new user can open the browser, register, receive a Lightning payment, show a payment page or install the app like a mobile wallet without entering an app store. A merchant can configure point-of-sale settings, local currency, email notifications and integrations such as Square. Coinos also exposes a Lightning address and LNURL-style receive paths, which makes it easy for other people to pay without sharing a new invoice every time.
The tradeoff is custody. Soltys has been open about the hosted model being custodial by default because running Lightning channels is still too much work for many normal users. That does not make Coinos useless. It makes it an onboarding and spending wallet, not a place to park life savings. The reader should understand Coinos the same way they would understand any easy hosted wallet: excellent for small payments and merchant demos, serious only after the custody model, account security and exit path are clear.
The self-hosting story is real, but not tiny
Coinos is open source under AGPL-3.0 and split across a Svelte front end and a TypeScript server. The front-end repository says the app can be used as a front end to personal Bitcoin and Lightning nodes or that someone can host a public instance where anyone registers with a username and password. The server repository contains the API implementation and deployment notes.
A full Coinos site is not just one static web app. The server README lists Coinos Server, Bitcoin Core, Liquid, Core Lightning, KeyDB, Nostr and Cashu Nutshell as the broader component set. It also says the most essential services are Coinos Server, a Bitcoin node, Core Lightning and KeyDB. That is a real stack, not a toy. A serious self-hosted Coinos deployment means operating money infrastructure, databases, Lightning connectivity and web/API security.
This distinction is important because Coinos can be both easy for an end user and complex for an operator. The hosted service hides the stack. Self-hosting exposes it. If a business wants Coinos as its own payment system, the question is not only whether the interface is friendly. The question is who will run Bitcoin Core, Core Lightning, database backups, DNS, TLS, uptime, liquidity, withdrawal policies, Nostr relays and software updates.
Coinos accepts more than one Bitcoin rail
Coinos is not a single-rail Lightning wallet. The product and code paths cover Lightning, LNURL, BOLT11 invoices, BOLT12, on-chain Bitcoin, Liquid, internal Coinos transfers, username sends and ecash-related routes. The Plan B Academy walkthrough describes receive options for Bitcoin on-chain, Lightning and Liquid, plus references to ecash. The server payment types include internal, bitcoin, lightning, fund, liquid, ecash, reconcile and bolt12.
For users, this breadth is convenient because payment senders do not all use the same rail. One person may scan a Lightning invoice, another may use a Lightning address, another may send on-chain, and another may use Liquid. Coinos tries to make the receive surface ordinary: choose the rail, show a QR code, optionally set amount and memo, and let the sender pay.
For operators and careful users, breadth also increases the number of possible failure modes. Lightning failures are different from Liquid address mistakes. BOLT12 has different support assumptions from BOLT11. On-chain deposits have confirmation and fee questions. Internal username payments depend on the hosted account system. Coinos is useful because it hides much of that complexity at the interface, but good use still starts with knowing which rail a payment is actually using.
The NWC implementation is concrete, not just a badge
Coinos matters to Nostr because its server implements Nostr Wallet Connect. NWC lets an app request wallet actions through Nostr relay events. A wallet service advertises what it can do, listens for encrypted requests and answers with encrypted responses. In Coinos, that service is wired into the server's Lightning, internal payment, invoice and user-account logic.
The current Coinos NWC method list includes pay_keysend, pay_invoice, get_balance, get_info, make_invoice, lookup_invoice and list_transactions. The implementation publishes NWC capability information as kind 13194 events, listens for kind 23194 requests and returns kind 23195 responses. That gives connected apps the core set they usually need: pay a Lightning invoice, create one, check balances, ask what the wallet supports and reconcile transactions.
The implementation details are worth noticing because they affect reliability. Coinos keeps an internal handled-event set to avoid processing the same NWC request twice, rejects stale request events, publishes missing info events when the relay has lost them and replies with NIP-47-style errors rather than leaving clients hanging. That is the kind of plumbing that separates a real wallet service from a QR-code demo.
Budgets are the safety feature to understand first
An NWC connection is not a harmless login token. It is a wallet-control credential. Coinos treats each connected app as an app record with a pubkey, secret, name, spending limit, maximum fee and budget renewal period. The Nostr settings page shows each app connection, the amount already spent, the maximum amount, the renewal period, payment history, edit access, QR display, copy action and a direct connection link.
When an app asks Coinos to pay an invoice, the server checks the connection record and user, calculates spending during the current budget period and compares the next payment against the app's maximum amount. If the budget would be exceeded, Coinos returns a QUOTA_EXCEEDED error. If the connection is no longer valid, it returns an authorization error and points the user back to the Nostr settings page.
That budget model is the reader's main protection against NWC mistakes. A spending limit is not a philosophical nice-to-have. It is the wall between a useful app connection and an app that can drain all available funds. For zaps, games, bots, point-of-sale testing or social clients, keep the allowance small, set a renewal period that matches the use case and delete stale connections instead of collecting them.
Coinos handles amountless invoices and slow payments carefully
A small but important NWC detail is amountless BOLT11 support. NIP-47 lets a client provide the amount in the request when the invoice itself has no amount. Coinos checks for the invoice amount first, falls back to the requested amount in millisats and returns a clear error if neither is available. That matters because amountless invoices show up in real payment flows, and wallets that reject them without explanation create confusing app behavior.
The server also has specific handling for slow Lightning payments. Earlier payment code could make a slow but ultimately settled payment look like a timeout. The current implementation calls the Lightning send path, checks for the payment preimage, then falls back to polling before returning either success, payment failure or an explicit still-in-flight error that tells the client to check status with lookup_invoice.
Readers do not need to memorize the code, but they should remember the practical lesson: NWC payments are asynchronous money operations. A good app should be able to reconcile with lookup_invoice or list_transactions instead of assuming that every payment is instantly final. Coinos exposes those methods, so a compatible client has enough tools to behave responsibly.
Rate limiting protects the wallet without going silent
Coinos rate-limits NWC requests per pubkey at 60 requests per minute. The code comments explain why this is intentionally higher than an earlier limit: normal clients can send a few balance checks, a payment and lookup calls quickly, and silently dropping over-limit requests made failures indistinguishable from lost replies. The current path returns a RATE_LIMITED error instead.
That is a good example of wallet engineering in a live ecosystem. NWC is not only a protocol document. It has to survive impatient mobile clients, flaky relays, repeated taps, reconnect loops, app bugs and automated payment tools. A silent drop feels like the wallet disappeared. A typed error lets the app back off and lets the user understand that the connection is still alive.
The limit also reminds readers that NWC is not meant to be abused as a high-frequency money API with no operational consequences. Coinos is useful for social zaps, normal app payments, merchant testing and small automated flows. If an app needs heavy transaction throughput, the operator should test limits, failure responses, reconciliation and account risk before presenting it to users.
Zaps connect Coinos payments back to Nostr social context
Coinos is not only moving invoices around. Its NWC payment path can detect internal invoices whose memo includes zap request data and then call its zap receipt handler. The server-side Nostr code understands NIP-57-style zap receipts, relay tags, pubkeys and event references. That matters because Nostr payments are often social payments: a zap belongs to a note, article, profile or live interaction, not only to a balance sheet.
This is one reason Coinos is more interesting than a generic hosted Lightning account. It sits close enough to Nostr to understand Nostr login, signing, zap receipts and NWC app permissions. A user can use Coinos as a wallet, but the product direction points toward a combined social-payment identity where posting, signing and paying are not separate universes.
There is also a privacy caution here. Social zaps attach payment behavior to public or semi-public context. NWC app permissions can link apps, spending and account identity. Hosted wallet accounts can add another layer of metadata. Coinos can make the experience smooth, but smoothness does not remove the need to decide which identity, wallet balance and app connection should touch each other.
Nostr signing is present in several forms
Coinos has Nostr signing paths beyond NWC. The front-end Nostr code supports encrypted nsec storage, NIP-49-style encrypted private key handling, direct secret-key use, browser extension signing and a Nostr Connect flow through wss://relay.nsec.app. The user-facing Nostr component offers browser extension, Nostr Connect and secret key options when an event needs to be signed.
The settings page also includes Nostr account controls: it can show an npub, copy or reveal credentials where appropriate, sync with a browser extension and save Nostr settings. The Plan B Academy walkthrough describes a Nostr section in preferences where users can link a Nostr account to Coinos.
The important distinction is between a Nostr identity key and an NWC wallet-service connection. A Nostr signing key lets a user sign events. An NWC secret lets an app request wallet actions. They may live near each other in the interface, but they carry different risks. A person should be careful about storing nsec material in any wallet, and careful again when handing out app spending credentials.
Parsing matters because Coinos has to read messy payment inputs
A wallet like Coinos lives or dies by its input parser. The front-end parser recognizes Nostr references, Lightning invoices, LNURL, Bitcoin and Liquid URIs, Cashu tokens, payment requests, Coinos usernames and other common strings a user may paste or scan. That is not glamorous, but it is the part of the wallet most people touch every day.
Good parsing makes the send screen feel calm. A user should be able to paste a Lightning invoice, scan a QR code, enter a username, open a Bitcoin link or handle a Nostr string without being forced to know the technical family first. Coinos tries to route those inputs to the correct payment flow, profile flow or receive/send screen.
Bad parsing is expensive in a money app. A Bitcoin address sent on the wrong rail, an unsupported invoice, a malformed LNURL or a confused Nostr reference can turn into lost time or worse. Before using Coinos for a business workflow, test the exact codes, invoices, usernames, Lightning addresses and NWC connection strings your customers or apps will actually use.
Ecash is present, but should be read carefully
Coinos has Cashu and ecash-related code paths, dependencies and payment types, and Adam Soltys has discussed eCash as part of the product's future. The server README lists Cashu Nutshell in the broader Coinos component set, and the server dependencies include Cashu tooling. The payments and invoice code includes an ecash type, and the routes include save, get, claim, melt and receive paths.
At the same time, the current server route marks minting as disabled in the visible code path. That means the right reader-facing description is not that Coinos is a finished Cashu mint for everyone. The accurate description is that Coinos is exploring and integrating ecash-related flows while its primary public wallet experience remains Bitcoin, Lightning, Liquid, internal account transfers and NWC.
This distinction matters because Cashu has a different trust model from a hosted Lightning account. Ecash can improve bearer-style privacy, but a mint still matters, redemption still matters and operator risk does not vanish. If Coinos exposes more ecash functionality in the future, readers should evaluate it on the same careful terms used for any mint-backed wallet.
Merchant tools are part of the product, not a side quest
Coinos keeps returning to merchants. The tutorial highlights a point-of-sale preferences area, local currency display, notifications and Square connection. The source tree includes settings pages for Square and Shopify. The server and payment code contain account, payment and invoice logic that fits a payment-page and merchant workflow rather than only person-to-person tipping.
That merchant orientation is why Coinos deserves attention from Nostr readers who care about commerce. Nostr often talks about zaps, creators and open social identity. Coinos shows a more mundane but important path: a business can accept Bitcoin payments through a web wallet, share a payment page, receive Lightning address payments and potentially connect app-controlled payment flows through NWC.
The key word is potentially. A merchant should still test settlement timing, fees, refunds, accounting export needs, staff access, device security, 2FA, Square or Shopify behavior, NWC app permissions and withdrawal processes. A beautiful payment QR code is only the front counter. The back office still needs transaction history, reconciliation and a clear plan for moving funds to safer custody.
Open issues show where to test before trusting automation
Coinos is active, and active projects have open issues. The UI issue list currently includes NWC QR-code usability concerns, including requests to increase the quiet area around the NWC QR in dark mode and allow pinch-to-zoom in the PWA. Another UI issue mentions NWC memo/description storage. The server issue list has discussed NWC payment status behavior and request-generation needs for onboarding flows.
These are not reasons to dismiss Coinos. They are reasons to test it like money software. QR quiet area problems matter because a connection string that cannot be scanned reliably creates support pain. Memo storage matters because merchants and apps need payment context. Payment status behavior matters because an automated app has to know whether money actually moved.
Before connecting Coinos to BTCPay, Damus, a bot, a shop workflow or any app that spends without a manual wallet tap, run a small test matrix: create a connection, pay a tiny invoice, pay an amountless invoice if needed, make an invoice, check balance, list transactions, scan the QR from the real device, test dark mode and then revoke the connection. That is not paranoia. It is normal hygiene for app-controlled money.
Security starts with account custody and device habits
For a hosted Coinos account, the most obvious risks are account takeover, weak passwords, missing two-factor authentication, browser compromise and oversized balances. The Plan B Academy tutorial explicitly points users to safety settings such as security code and two-factor authentication. Use them. A browser wallet is convenient precisely because it is close to everyday devices, and everyday devices are where many compromises happen.
For a Nostr-connected Coinos setup, add the NWC risks: leaked connection strings, apps with too much budget, stale app connections, confusing renewal periods and clients that do not reconcile payment state well. An NWC string should be treated like a limited spending credential. Store it carefully, do not paste it into random websites, and rotate it when the purpose is over.
For self-hosted Coinos, the security burden gets wider. The operator has to care about the node, Lightning liquidity, server updates, database integrity, backups, access controls, domain security and incident response. Open source is valuable because it can be inspected and self-hosted. It does not turn an operator into a security team by itself.
How Coinos compares with other Nostr wallet paths
Coinos sits between several categories. It is easier for a newcomer than running a personal Lightning node. It is more merchant-oriented than many social-client wallets. It is more web-first than mobile-native wallets. It is broader than a simple NWC bridge because it has account, POS, Nostr, Lightning, Liquid and self-hosting surfaces in one project.
That makes it different from Alby Hub, Cashu.me, Zeus, LNbits, Bitvora or a pure Nostr signer. Alby Hub is a personal wallet-service hub. Cashu.me is an ecash wallet. Zeus is a node-control and Lightning wallet experience. LNbits is an account and extension platform around Lightning infrastructure. Bitvora is developer-facing payment and wallet infrastructure. Coinos is the approachable web counter: receive, send, show a QR, manage an NWC app, link Nostr and keep moving.
The best fit is small, practical payments where ease matters: onboarding someone to Bitcoin, taking payments at a local event, testing Nostr app payments, giving a creator a Lightning address, running a simple merchant setup or experimenting with NWC without building a full wallet backend. The weaker fit is large savings, deep self-custody, advanced Lightning channel control or compliance-heavy business accounting.
What to check before using Coinos with a Nostr app
First, confirm what balance you are willing to expose to an app-controlled connection. Keep it small. Then create a dedicated NWC app connection with a clear name, a maximum amount, a maximum fee and a renewal period that matches the app. Do not reuse one unlimited connection across social clients, bots, shops and experiments.
Second, test the exact methods your app needs. If the app only pays invoices, pay_invoice may be enough. If it creates invoices, it needs make_invoice. If it reconciles payments, it should use lookup_invoice or list_transactions. If it displays wallet status, it may call get_balance and get_info. Coinos supports these methods, but app behavior still depends on relay connectivity and client implementation.
Third, verify the user experience on the real device. Scan the NWC QR in light and dark mode, copy the connection string, trigger one tiny payment, check the payment history, watch the budget counter and revoke the connection. A Nostr app that cannot survive this tiny drill should not receive a larger allowance.
Sources worth opening
Open the Coinos repositories, the server NWC implementation, the Nostr settings code, the PWA manifest, Adam Soltys interviews, Plan B Academy's Coinos walkthrough, NIP-47, NWC documentation and current GitHub issues before relying on it for merchant or app-controlled payments.
- Coinos live wallet
- Coinos UI GitHub repository
- Coinos Server GitHub repository
- Coinos UI README
- Coinos Server README
- Coinos UI package.json
- Coinos Server package.json
- Coinos PWA manifest
- Coinos official app icon
- Coinos NWC server implementation
- Coinos server Nostr library
- Coinos settings: Nostr page
- Coinos new NWC app server action
- Coinos new NWC app page
- Coinos app connection details server action
- Coinos app connection details page
- Coinos UI Nostr signing library
- Coinos Nostr signing component
- Coinos parser for payment and Nostr inputs
- Coinos invoice generation code
- Coinos payment execution code
- Coinos payment routes
- Coinos ecash routes
- Coinos payment type definitions
- Bitcoin News interview with Adam Soltys
- Plan B Academy Coinos tutorial
- Awesome NWC wallet list
- Nostr Wallet Connect official site
- NWC documentation
- NIP-47: Nostr Wallet Connect
- NIP-57: Lightning zaps
- NIP-07: browser signer API
- NIP-46: Nostr Connect remote signing
- NIP-49: private key encryption
- Coinos server issue 74: generate NWC connection string through API
- Coinos server issue 80: NWC payment result behavior
- Coinos UI issue 160: NWC QR quiet area
- Coinos UI issue 161: zoom NWC QR in PWA
- Coinos UI issue 146: NWC memo description
- BTCPay Server discussion about Coinos NWC
- Core Lightning documentation
- Bitcoin Core project
- Liquid Network overview
- Cashu protocol documentation
- Adam Soltys Bitcoin developer donation profile
