I’m the developer of Aura, an open-source, Bitcoin-only self-custody wallet for iOS. It requires no account or email, and the keys remain on the user’s device.
But I don’t think “open source” alone should be treated as proof of security.
Before trusting a new wallet, what evidence matters most to you: reproducible builds, an independent audit, recovery compatibility, the server privacy model, a long public development history, or something else?
We’re especially looking for honest criticism of our recovery flow and Electrum connection model—not compliments.
Source: https://github.com/aurabitcoinwallet/aura-wallet
App Store: https://apps.apple.com/us/app/aura-bitcoin-wallet/id6749847943
On an internet-connected device, I wouldn't feel the keys could ever be truly safe.
I'd also be concerned about an app update (automatic or manual) brining malicious code.
Recovery compatibility is just bare-minimum. If it's not bip39, why even bother.
Of the things you listed, I guess reproducible builds is most important.
But you'd really have to show some kind of feature that isn't already available in longstanding wallets for me to even bother. Nunchuk, Blue, Cake, etc.
That’s a fair criticism. Aura is a hot wallet on a network-connected phone, so it should not be presented as equivalent to cold storage; the trust boundary includes the OS and the app-update chain.
Recovery uses BIP39/BIP32 with standard BIP44, BIP49, and BIP84 derivation, so compatibility is the floor, not a selling point. CI currently checks TypeScript and linting, wallet invariants, official Bitcoin vectors, signing tests, CodeQL, and an Android build. But to be precise: we do not yet publish reproducible-build proof that matches the App Store binary to a source commit. That is a real gap, and we should document and close it rather than hand-wave it.
The practical differentiation we’re aiming for is transparent recovery across common derivation paths, custom Electrum-server support, coin control, multisig, and a focused mobile UX. Those features only matter if the release process is verifiable. Your comment makes reproducible releases the clearest next trust milestone—thank you.
One of the factors I consider is the source code language.
I want to be able to understand how the software is doing specific things whenever I have a question.