The short version: downloading from the right website doesn't prove you got the right file. Checking a signature does — and it takes about two minutes, once you know what you're actually proving.

There's a cat in the colony who won't eat anything until she's been round it twice. Food arrives, everyone else piles in, and she circles — nose down, ears back, deeply unconvinced. Then she eats the same food as everyone else and I feel slightly stupid for having watched the whole performance.

She's right, though, and the others are just lucky. Most food is fine. The circling costs her twenty seconds. The one time it isn't fine, she's the one who doesn't find out the hard way.

Downloading a wallet works like this, and almost nobody circles.

1. The problem nobody mentions

You go to the project's website. You click Download. You run the installer. At no point did anything verify that the file you received is the file the developers built.

Things that can go wrong between their build machine and your disk:

You're on the wrong site. A typo in the domain, a sponsored search result above the real one, a link from a forum post. The site is a perfect copy. The download is not.

The real site was compromised. It happens — to open-source projects, to companies, to everyone eventually. The binary gets swapped, sometimes for days before anyone notices.

The download was tampered with in transit. HTTPS makes this hard, but "hard" and "impossible" differ, especially on networks you don't control.

A mirror or CDN served something else. Big projects distribute through infrastructure they don't entirely own.

A wallet is the one piece of software where this matters most, because a malicious build doesn't have to do anything dramatic. It just has to show you an address that isn't yours, or quietly send your seed somewhere during setup.

2. What a signature actually proves

Most wallet projects publish, next to the download, two extra files: a list of hashes and a signature over that list.

The hash is a fingerprint of the file. Change one byte of a 200 MB installer and the fingerprint changes completely. So if you compute the hash of what you downloaded and it matches the published one, you have the exact file they listed.

The signature is what makes that meaningful. Anyone who swapped the installer could also swap the hash list — unless the hash list is signed by a key only the developers hold. Verifying the signature tells you: this list of fingerprints was produced by the holder of this key.

Chain the two together and you get the thing you actually wanted: the file on my disk is the file the key-holder published.

3. Doing it, concretely

Two steps. The first is the one most people skip, and it's the one that matters.

Step one: get the developers' key from somewhere other than the download page. This is the whole exercise. A key fetched from the same page as the binary proves nothing — anyone who could swap the binary could swap the key, and your verification will pass beautifully against the attacker's own signature. Get it from the project's source repository, a key server, the maintainer's own well-established presence, a Linux distribution's package of it, or a copy you saved years ago. Cross-check the fingerprint against more than one of those.

Step two: verify, then hash. Verify the signature over the hash file first. Then compute the hash of your download and compare it to the entry in that file. Most projects document the exact commands; on Linux it's typically a gpg --verify of the signature file followed by sha256sum --check.

Two details that trip people up: the output "Good signature" accompanied by a warning that the key is not certified is normal — it means the signature is valid and you simply haven't told your keyring you trust that key. And compare the whole fingerprint, not the last four characters. Short fingerprints can be forged; people have done it to make a point.

Save the key once and every future release takes thirty seconds.

4. When you can't, or won't

Not everything can be verified this way, and I'd rather say that than pretend.

Mobile apps. You cannot verify an App Store or Play Store build yourself. The store's review and signing is the control, and it's weaker than you'd like — fake wallet apps reach both stores regularly. The defence available to you is: get the install link from the project's own site rather than searching the store, check the developer name and the install count, and keep meaningful amounts off the phone.

Browser extensions. Same situation, worse. Treat them as hot wallets, permanently.

Hardware wallets. The device checks its own firmware signature at boot, and the companion app checks what it installs. That's genuine protection and it's built in — what it doesn't cover is the device's journey to you, which is a different article and a different risk.

5. The uncomfortable half

I've described a real control. Now the limits, because this one gets oversold by people who enjoy the ritual.

Verification proves provenance, not safety. You've proven the file came from the key-holder. You have not proven the key-holder is honest, that their build machine was clean, or that the code doesn't have a catastrophic bug. A signed malicious release is still signed. It has happened.

The circularity is real and mostly unresolved. You verify the binary using a key you fetched from... somewhere. For most people, that somewhere is the project's website or GitHub, which is the same trust anchor as the download. Done that way, the signature check mostly protects against a compromised mirror or a tampered transfer — real threats, but narrower than the ceremony suggests. Getting the key from a genuinely independent source is what closes the gap, and it's the step almost everyone omits.

It defends against the wrong attack for most people. The way wallets actually get drained is a fake site at the top of search results, a "support agent" in a Telegram group, a seed typed into a phishing page, or a clipboard swap. Signature verification stops none of those. If you have an hour to spend on security, bookmarking the real site and never typing your seed anywhere beats verifying every release for a decade.

And it has a failure mode of its own: confidence. Someone who has performed the ritual feels protected and relaxes about things that matter more. The circling cat is right to circle. She'd be wrong to conclude that circling makes her immortal.

Do it anyway — it's cheap, and it's the only part of this chain you can personally check. Just file it under one control among several, not under done.

Twenty seconds of circling, most days for nothing. The value of a check isn't in the times it passes. 🐾⚡