Cashu: update SECURITY.md for the Cashu trust model before general availability
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Documentation
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- markdown, rust, sqlite
- Domain
- documentation, security
Research direction
Start with SECURITY.md, then read docs/cashu/README.md around C10 and the Cashu trust-model references in api/cashu.rs and the spec’s risk #9. Update the in-scope and out-of-scope lists, clarify mint custody, and make the seed-recovery advisory match the shipped restore and backup mechanisms, including NUT-09 and escrow limits. Done means the security guidance accurately reflects the shipped Cashu behavior and the release-blocking checklist is updated.
Written by the indexing model from the issue text.
Description
Summary
SECURITY.md describes a client that handles "private keys, Lightning payments, and end-to-end encrypted messages". Once Cashu mode reaches users (C5/C6 onward of docs/cashu/README.md), that model is materially incomplete. This issue tracks updating it as part of the Cashu release-blocking checklist (Wave 4 / C10), so it lands before general availability — not after.
What changes with Cashu mode
- A new in-scope attack surface: the embedded wallet. Ecash proofs are bearer assets stored in a local DB (
cdk-sqlite). Theft or corruption of that DB is direct loss of user funds — a failure class that does not exist in Lightning mode. The Rust core scope list should name it. - Third-party mints belong in the out-of-scope list, exactly as third-party relays, Lightning wallets and Mostro nodes already are: "Cashu mints operated by others — report to their own projects."
- The "non-custodial" framing needs a qualifier. In Cashu mode the mint custodies value while ecash is held and while an escrow is locked. The client remains non-custodial in the key sense, but the trust model shifts — the spec itself acknowledges this (risk #9) and asks the client for transparency. The Security Model section should say it plainly.
- The User Advisory needs precision about what the seed recovers. The C2 wallet deliberately uses the identity's BIP-39 seed (
api/cashu.rs→current_bip39_seed(); the design comment says "the ecash is recoverable from it"), so a restore scan (NUT-09) can rebuild the spendable balance from seed alone — but that depends on three things the advisory should not gloss over: the scan feature is not implemented yet (norestorein the API surface — a C10 candidate next to backup), the mint must support NUT-09, and escrow-locked tokens are not seed-derived (they are recovered via the 2-of-3/refund paths instead). SECURITY.md should state exactly what the seed recovers and under which conditions, so a reinstalling user knows what to expect.
Proposal
- Add a line to the C10 release-blocking list in
docs/cashu/README.md: "SECURITY.md updated for the Cashu trust model (embedded bearer-asset wallet in scope, third-party mints out of scope, seed-vs-backup recovery advisory)". - Draft the actual SECURITY.md changes when C10 lands, so the text matches what shipped (e.g. exact backup mechanism).
Nothing here blocks the current PR series; filing it now so it cannot be forgotten between "the flows work" and "users can choose a Cashu node".
- Dominant language
- Dart
- Stars
- 11
- Forks
- 9
- Avg merge
- 13h 4m
- Merged PRs (30d)
- 259
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MostroP2P/app
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Add-invoice screen stays on "Sent, waiting for the node" after a late acceptance on a sell orderOpenbug priority: medium
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
area: ui
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MostroP2P/app#341 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
bggRGjQaUbCoE/PiliPlus#3235 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
intel/rohd-wave-viewer#11 ·
-
DOCS UPDATE: README.md and BACKEND.md reference a search-meetings edge function that does not existOpendocumentation
Difficulty 1/5 1-3 hours Newbie friendliness 93/100
AOSSIE-Org/Ell-ena#337 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 66/100
Maintainers usually reply within 1 day
-
cat: puzzle
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
lichess-org/mobile#3826 ·
Maintainers usually reply within 2 days