“Open source” isn’t the same as verifiable. What should a new Bitcoin wallet prove before you trust it with your first sats?

I’m the developer of Aura, a Bitcoin-only self-custody wallet. This isn’t a launch post, and I’m intentionally leaving out the download link.

The recent discussions here about wallet entropy and reproducible firmware made me rethink how developers use “open source” as if it closes the trust problem. It doesn’t.

Public code alone doesn’t prove that:

- the binary in an app store came from the published commit;

- key generation is actually using the entropy source the code appears to use;

- recovery works outside the original app;

- an Electrum server or notification service cannot learn more than users expect;

- or an audit still applies to the version people are installing today.

My current idea of a minimum “evidence package” for a new wallet is:

1. Signed release tags and a documented, independently verifiable build path.

2. A plain-English threat model: what stays on-device, what leaves, and what a compromised device or server can do.

3. Published key-generation and storage details, derivation paths, and recovery test vectors.

4. An independent audit tied to a specific commit, including its scope and unresolved findings.

5. Own-node support and an honest privacy explanation for public Electrum servers.

6. A public security contact and a changelog that clearly identifies security-relevant changes.

For transparency: Aura currently publishes its source and release tags, documents its BIP39 and BIP44/49/84 recovery paths, signs transactions locally, and supports a custom Electrum server.

It does not currently have a published independent audit or a public method for reproducing the App Store binary. Those are real gaps, and I don’t want to hide them behind the words “open source.”

If you could require only two items before trying a new wallet with a small amount, which two would they be?

And what single missing item would make you walk away immediately?