xmr.club
EN 中文 ES RU
← all guides
guide · long-form explainer

How to verify a wallet binary before running it

A modified wallet binary is the most dangerous attack you can run against a self-custody user — one swap of the download and every key the wallet ever generates is stolen. The mitigation is signature verification, and nearly every Monero wallet ships the tooling. This is the practical workflow.

Why this matters

Wallet binaries are statically distributed by the project (GitHub releases, project website, mirrors). Each of those distribution points is a target. CDN compromise, DNS hijack, and (in some jurisdictions) compelled-signing have all been observed. The defense is to verify the binary against a signature you separately trust — typically a GPG key controlled by the project maintainer.

The minimum-viable check (every wallet)

  1. Download the binary plus the matching SHA256SUMS or hashes.txt file the project publishes alongside it.
  2. Compute the local hash: sha256sum monero-wallet-cli (Linux/macOS) or Get-FileHash (PowerShell).
  3. Compare the local hash to the line in the published file. Match = file is bit-identical to what the project published.

This catches CDN tampering and transit corruption. It does not catch a compromised project key — for that, go to step 2.

GPG signature verification (the real defense)

  1. Import the maintainer's GPG key from a separate source than the download — keyserver, the maintainer's personal site, or a published fingerprint from a years-old commit. Don't import from the same domain that served the binary.
  2. Verify the SHA256SUMS signature: gpg --verify SHA256SUMS.sig SHA256SUMS. Look for "Good signature from <maintainer>" and the expected fingerprint.
  3. Verify the trust chain: check that you've used this fingerprint for previous releases. Web of trust signatures from people you actually know strengthen this.
  4. Now proceed with the hash check from step 1.

Reproducible builds — the gold standard

Some Monero-ecosystem projects (the Monero CLI itself, Feather Wallet) publish reproducible build instructions. You compile the source on your own machine and the resulting binary is byte-identical to what the project shipped. If yours doesn't match, either your build environment is wrong or the project's release was tampered with. This is the most rigorous defense — see reproducible-builds.org for background.

Failure modes by wallet

  • Mobile wallets: app-store signing replaces GPG verification. You're trusting Apple/Google + the publisher's developer account. Less rigorous but still meaningful. Cross-check the publisher's account name matches what the project documents.
  • Web wallets: can't be verified — code is delivered fresh on every page load. Don't use web wallets for amounts you'd miss.
  • "Portable" downloads via Telegram / Discord links: never. Get binaries from the canonical project domain, not a chat link.
  • Pre-compiled in a "convenience" repo: unless the repo owner publishes signatures themselves, treat it as un-verified and re-pull from the canonical source.

Where the wallets we recommend stand

  • Monero GUI / CLI: SHA256SUMS + GPG-signed by binaryFate (long-standing fingerprint). Reproducible builds documented.
  • Feather Wallet: SHA256SUMS + GPG-signed by tobtoht. Reproducible builds documented.
  • Cake Wallet: mobile, relies on app-store signing. Desktop builds carry checksums.
  • Monerujo: Android, F-Droid + Play Store, both signed. APK SHA256 published.

Picks

  • Monero GUI — Official desktop. GPG-signed, reproducible-build documented.
  • Feather — Desktop XMR wallet. GPG-signed, reproducible-build documented.
  • Monerujo — Android. F-Droid + Play Store, both signed. APK SHA256 published.
  • Cake Wallet — Mobile (app-store signed). Desktop builds carry SHA256 checksums.