Security and UX checklist

Protect keys, verify what is signed, and limit who and what can touch either. These checks assume you handle keys or transactions; if you build a watch-only tool, mark the ones that do not apply.

• S-01Keys come from a vetted random source

  Generate keys and seeds with the operating system's cryptographically secure random generator, through an established library. Never seed from timestamps, taps or home-made randomness.

  N/A
• S-02Secrets never reach logs, analytics or crash reports

  Seed words, private keys and passphrases stay out of every log, telemetry event, crash dump and support ticket. No support channel should ever ask a user for them.

  N/A
• S-03Signing is gated by authentication

  Require device unlock, a PIN or biometrics before signing or revealing secrets. Rate-limit attempts, lock automatically after inactivity, and decide what happens after too many failures.

  N/A
• S-04Addresses are validated before anything is sent

  Check format, checksum and network on every pasted or scanned address. Reject test-network addresses on the main network and the reverse, and say why in plain words.

  N/A
• S-05What is shown is exactly what is signed

  Build the confirmation screen from the final transaction: outputs, change, fee and total. If anything changes after the user confirms, ask again.

  N/A
• S-06Clipboard and lookalike-address defences are in place

  Display full addresses in readable groups, flag a clipboard that changes after pasting, and warn when a new recipient looks suspiciously similar to a saved one.

  N/A
• S-07Every network call and third party is inventoried

  List each server the app contacts and what it can learn: addresses, balances, IP address, timing. Remove what you can and disclose the rest in settings.

  N/A
• S-08Dependencies are pinned, minimal and reviewed

  Lock versions, read changelogs before upgrading, remove packages you can live without, and treat anything that touches keys or transactions as code you must understand.

  N/A
• S-09Updates are signed and verifiable

  Distribute builds through channels users can verify. Sign releases, publish checksums and explain how to check them. Plan in advance how you would ship an emergency fix.

  N/A
• S-10A written threat model exists and is revisited per feature

  One page is enough: what you protect, who might attack, where the trust boundaries sit. The wizard's risk register is a starting point. Revisit it whenever scope changes.

  N/A
• S-11Test networks first, with edge cases covered

  Exercise every value-moving flow on a Bitcoin test network. Automated tests should cover fee rounding, dust-sized outputs, change handling, insufficient funds and malformed input.

  N/A
• S-12Web apps only: strict CSP and no third-party scripts near keys

  Serve key-handling pages with a strict content security policy and without third-party scripts, tag managers or widgets. Keep them apart from marketing pages.

  N/A
• S-13Custodial services only: duties, limits and an incident runbook

  Separate who can request, approve and execute withdrawals. Set limits and delays for large movements, keep most funds in colder storage, reconcile your ledger against the chain, and rehearse incident response.

  N/A
• S-14Independent review happens before real value is at stake

  Have someone outside the team review the design and the code that handles keys and transactions. Fix findings, publish what was and was not covered, and claim no more than the review supports.

  N/A

Most losses begin as confusion. These checks make ownership, timing, fees and recovery understandable to the person holding the phone.

• U-01Key ownership is stated in plain words

  The first screen and the balance say whether the user or you hold the keys. Avoid vague words such as secured or protected unless you also say by whom.

  N/A
• U-02Units are unambiguous

  Pick a primary unit, label it, and format amounts consistently. If you show both bitcoin and satoshis, make the relationship explicit and never mix them in one field.

  N/A
• U-03Pending and confirmed states are explained

  Name the stages of a payment, explain that blocks arrive about every ten minutes on average, and never mark a payment final at the moment of broadcast.

  N/A
• U-04The send confirmation shows everything

  Full recipient, amount, fee, total deducted and any change, on one screen. No truncated addresses and no hidden fee lines.

  N/A
• U-05Fee choices describe time versus cost

  Offer a default that suits most people, a short scale of options in plain language, and a route to speed up a payment that is stuck.

  N/A
• U-06Backup is required, verified and rehearsed

  Show the backup once, verify it before continuing, and provide a way to test a restore. Explain what the backup does and does not contain.

  N/A
• U-07The receive flow is safe by default

  Show a fresh address, a QR code and copyable text together with the network name. Explain gently why reusing addresses is discouraged.

  N/A
• U-08Errors say what happened, what is safe and what next

  Every error has those three parts. Avoid blaming users, avoid codes without words, and make retries safe so nothing is ever sent twice.

  N/A
• U-09Offline and degraded states are designed

  When a data source is unreachable, show the last known state with a timestamp, say what cannot be done right now, and recover without a restart.

  N/A
• U-10Onboarding teaches ownership in a few screens

  Cover who holds the keys, what a backup is and what cannot be undone. Defer everything else until it matters, and keep a glossary within reach.

  N/A
• U-11Irreversibility is explained before the first send

  Say once, plainly and without scare tactics, that sent payments cannot be reversed by the app, and suggest a small first payment.

  N/A
• U-12Empty states teach the next step

  A new account with a zero balance should show how to receive first, not a broken-looking blank. The same goes for empty history, an empty address book and first launch.

  N/A
• U-13Privacy choices are visible and opt-in

  A settings page lists what third parties can see. Analytics stay off until the user turns them on, and never include addresses or amounts.

  N/A
• U-14Accessible by default

  Text meets contrast guidelines, controls have labels and generous tap targets, amounts and addresses are readable by screen readers, and information is never carried by colour alone.

  N/A