Community

Wallets / Safety

Wallet Security, Recovery and Small Permissions

Wallet safety in Nostr is not one password tip. It is the habit of keeping keys, budgets, relays, mints, backups and app permissions small enough that mistakes stay survivable.

Wallet Security, Recovery and Small Permissions visual
Wallets Safety Value, permission, custody and proof before the next payment.
Wallets665 wordsSafety

Wallet Security, Recovery and Small Permissions

Wallet safety in Nostr is not one password tip. It is the habit of keeping keys, budgets, relays, mints, backups and app permissions small enough that mistakes stay survivable.

The safest wallet is the one you understand under stress

Wallet security advice often sounds like a lecture. Use strong backups. Do not paste secrets. Verify addresses. Update software. All true, all easy to ignore. Nostr adds a reason to make the advice concrete: wallets are no longer isolated apps. They can connect to social clients, live rooms, commerce pages, creator tools, games and remote services.

That makes permissions more important than slogans. You may not be giving an app your whole wallet, but you may be giving it the right to spend within a budget. You may not be publishing wallet state in plain text, but you may be storing encrypted events on relays. You may not be trusting a bank, but you may be trusting a mint, wallet service or node operator.

The practical rule is boring and powerful: keep the blast radius small.

Use small balances while learning

The first wallet you connect to a new app should not hold meaningful money. Test with small amounts. Send a zap. Receive a zap. Create an invoice. Revoke the connection. Restore the wallet or reconnect it somewhere else. Only then decide whether the product deserves more trust.

This is not because every wallet is suspicious. It is because wallet UX is still young. NWC, Cashu, zaps and Nostr clients are improving quickly, and quick-moving software is exactly where small experiments beat heroic confidence.

Backups are part of the product

A wallet that cannot explain backup is not finished. For a node-connected Lightning wallet, the backup story may involve seed material, channel state, static channel backups, node access and database backups. For a hosted wallet, it may involve account recovery and operator policy. For Cashu, it may involve token proofs, wallet state and mint availability. For NWC, it may involve revoking connection strings rather than recovering them.

Write the recovery path down before you need it. If the product cannot tell you how to recover or exit, keep the balance tiny.

NWC permissions should be disposable

A NWC connection is not meant to become a lifelong secret. Create it for a job, budget it for that job, expire it if possible and revoke it when the job ends. A social client that sends zaps needs a different allowance from a merchant tool that creates invoices. A game needs a tiny budget. A back office integration needs auditability.

If a wallet UI does not show app connections clearly, you are operating partly blind. Good wallet services show connection names, budgets, renewal periods, last activity and revoke controls. That is not extra polish. That is the security interface.

Cashu safety is mint safety plus token safety

With Cashu, the word custody changes shape. You hold bearer tokens, but the mint is still the issuer and redeemer. You need to trust the mint enough for the amount and use case. You also need to protect token proofs and wallet state. If those disappear, the cash-like UX becomes cash-like loss.

Use trusted mints for meaningful amounts, diversify carefully only when you understand the consequences, and treat experimental mints as experimental. Privacy benefits do not cancel operational risk.

Receipts are not accounting by themselves

Zap receipts, NWC transaction lists, wallet histories and Cashu token records each answer different questions. A creator or merchant may need more than one layer: social receipt, wallet record, invoice, settlement state, refund policy and tax record.

This is especially important for Crays-style creator sales and awards. A fun visible signal can start the flow, but any serious sale needs a product record behind it.

A simple safe routine

Use one wallet for experiments and another for meaningful balances. Keep app connections scoped. Review them monthly. Use small budgets for social apps. Keep recovery notes offline. Avoid pasting secrets into websites. Prefer signers and connection flows that keep main keys away from random pages. When a wallet feels unclear, do not fund it yet.

Security becomes humane when it becomes a routine instead of a panic.

Sources worth opening

Open these when you want the specification, product documentation or implementation trail behind the article.

Useful next pages

Back to Wallets
A digital finance dashboard for wallet permissions, invoices and payment state.
People discussing self-custody and wallet decisions in a finance setting.
A team table where payment permissions and custody decisions become concrete.
Digital asset community energy around Bitcoin value movement.
An open doorway through technical diagrams for portable wallet access.

Recovery starts before the first zap

The dangerous wallet moment is rarely dramatic. It is a phone replacement, a browser reset, an expired NWC connection, a lost note with a Cashu token, a mint that no longer responds, a Lightning node database that was never backed up or a web client that once received a powerful secret and is still sitting in your history. Recovery is not one password practice. In the Nostr wallet layer it is a map of several small authorities: Nostr identity keys, wallet keys, app connection secrets, Lightning node access, mint trust, encrypted wallet events, proofs, invoices and receipts.

NWC best practices put budgets, unique keys and sub-wallet isolation close to the center of the design. That is not just developer neatness. It is how a mistake stays small. Alby Hub's connection controls show the same idea in product form: connection name, permissions, budget, budget renewal and expiration are security features because they let you remember what you allowed. A wallet connection you cannot name is already harder to recover from. A permission you cannot expire is not a temporary permission in any practical sense.

Cashu recovery has three doors

Cashu changes recovery because the value is carried by bearer-style proofs while the mint remains the issuer and redeemer. Cashu describes ecash as digital bearer tokens stored on your device. NIP-60 gives Cashu wallets a Nostr-shaped state model: wallet events, encrypted token events and optional spending history. NIP-61 adds nutzaps, where a P2PK-locked token can be published as the payment event and later redeemed by the recipient.

So your recovery path has at least three doors. You need the local wallet or its backup. You need the encrypted state or proof material that lets another wallet know what exists. You need the mint to remain available enough to redeem or swap the proofs. A seed phrase style mental model is too small for this. If a Cashu wallet page promises portability but cannot explain proofs, mint URLs, NIP-60 state, NIP-61 receiving keys and backup limits, keep the balance experimental. Privacy benefits are real, but they do not rescue money from an unavailable mint or a deleted proof.

Receipts are memory, not recovery

Zap receipts are socially useful because they create public memory. They are not your wallet backup. NWC transaction lists can help you understand spending. They are not proof that the receiving side will always reconcile correctly. Cashu redemption events can help a recipient mark a token as claimed. They are not a substitute for keeping the wallet state alive. If you use zaps for applause, a missing receipt is annoying. If you use payments for access, orders, awards, creator revenue or refunds, you need a product record that sits beside the Nostr event.

This matters for any Crays wallet flow that touches fan access, creator commerce or awards. A public payment signal can be part of the experience. It should not be the only accounting layer. The safer design separates the social object from the business object: zap for public support, invoice or order record for a sale, NWC permission for the app action, wallet history for settlement, private support trail for disputes. That separation sounds formal until something goes wrong. Then it becomes kindness.

The monthly permission audit

Use a routine that a normal person can actually keep. Once a month, open your wallet service and read every app connection. Delete anything you do not recognize. Lower budgets that were created for tests. Rotate secrets after testing developer tools. Make sure temporary event pages and live rooms have expired permissions. Check whether your Lightning address still points to the intended wallet. Try one tiny incoming and one tiny outgoing payment. If you use Cashu, redeem a small token in a second wallet and confirm you understand where proofs and mint trust live.

The point is not paranoia. It is muscle memory. Nostr makes app switching easier than platform switching, and that is a gift. But money should not follow every experiment forever. Security in this ecosystem is the art of making every permission small enough, named enough and recoverable enough that curiosity stays affordable.