Vetting a Wallet

“Open source” appears on almost every wallet website. It is rarely false outright, and it is frequently misleading. The useful question is not is there a repository but does the published code correspond to the software I am running?

Four ways the claim degrades

• Stale repository. The repository exists but its last meaningful commit predates the current release by months. Whatever shipped, you cannot see it.
• Partial openness. The desktop client is open; the firmware, the bootloader, or the backend service is not. The open part is real and also not where the interesting risk lives.
• Source-available, not verifiable. You can read the code but cannot confirm the binary was built from it. Reading is a much weaker guarantee than reproducing.
• Retroactive redefinition. A project markets itself as open source, is challenged, and quietly removes the claim — or keeps the claim and redefines it. Check archived versions of the site if the history matters to you.

The argument you will hear against opening code

The most common justification for closing a wallet’s source is that open code lets attackers publish convincing clones that steal from users. Clone apps are a genuine problem. But the reasoning does not survive contact with how software distribution works: clones are built by decompiling and repackaging published binaries, which closed source does nothing to prevent, and the defence against them is code signing and verified publisher accounts, not secrecy.

Closing the source does not stop the attacker who repackages your binary. It only stops the reviewer who would have found your bug.

You will also hear a subtler version aimed specifically at hardware: even fully open firmware does not prove what is executing on the device, so openness is a mantra rather than a guarantee. The first half of that is technically true and worth taking seriously — verifying execution on a device you do not control is genuinely hard. The second half does not follow. Being unable to verify one layer is not an argument for refusing to let anyone verify the layers that can be verified.

What to actually check

1. Open the repository and compare the date of the latest release tag with the version number the app reports.
2. Look at whether releases are tagged and signed at all, or whether binaries appear on a website with no corresponding tag.
3. Read the issue tracker — specifically, closed issues about security. Are they answered technically or dismissed?
4. Check the licence. Source-visible licences that forbid redistribution are legitimate, but they are not the same thing as open source, and they change who is realistically going to review the code.

Three different mechanisms are often confused. They answer three different questions.

Checksums verify integrity, not authenticity

A published SHA-256 hash lets you confirm that the bytes you downloaded are the bytes that were published. It protects against corrupted downloads and mirrors that serve altered files.

It does not protect you if the attacker controls the website, because then they publish their hash next to their file. A checksum read from the same page as the download is only as trustworthy as that page. This is why serious projects also mirror their hashes in a separate location such as a code repository.

Signatures verify authorship

A cryptographic signature proves the release was produced by whoever holds the signing key. This is stronger than a hash, because a compromised website cannot forge it without also stealing the key.

The catch is key distribution: you must obtain the correct public key from somewhere independent, and confirm it has not silently changed between releases. A signature you verify against a key you fetched from the same compromised page proves nothing.

Reproducible builds close the last gap

A reproducible build means an independent party can compile the published source and obtain a byte-identical binary. This is the only mechanism that actually connects “the code is public” to “the program on my machine is that code”.

Where a project supports this, third parties can and do confirm each release. Where it does not, the published source is a statement of intent rather than a verifiable fact — there is no way for anyone outside the build server to detect a discrepancy between what was published and what was shipped.

“Audited” is close to meaningless without four additional facts. Ask for all four.

An unfixed audit is worse than no audit

The dangerous case is a project that commissions an audit, receives findings, does not act on them, and continues to advertise that an audit took place. This is not hypothetical: there are documented cases where independent security researchers published advisories recommending that users avoid a wallet until specific issues were resolved, the issues went unaddressed, and the wallet later suffered a large-scale compromise affecting many users at once.

When you find an audit, search for the findings separately. A published report that lists unresolved high-severity items, next to a marketing page that says “audited”, tells you exactly how the organisation treats security work.

Continuous review beats a one-off audit

A single audit is a snapshot of one commit. The code changes weekly afterwards. The stronger signal is evidence of ongoing review: a dedicated release engineer who inspects every build before it ships, dependency review, and a documented process for what happens between an audit and the next release.

This role is expensive — a competent full-time reviewer costs real money every month — which is exactly why most free wallets have never had one. When a project does have this function, it usually says so, because it is a genuine differentiator.

A privacy policy is written by lawyers to describe what the software is technically capable of doing. Read that way, it is one of the most informative documents a vendor publishes — and almost nobody opens it.

The phrases that carry weight

• “We do not collect information that identifies users directly.” The qualifier is load-bearing. Indirect identification is not excluded, and it is usually straightforward when the same party also shipped you a physical device to a postal address.
• “Even if the following information is collected…” Conditional framing around a list means the list is collected. Read it as a specification of the telemetry.
• Retention periods tied to tax or financial law. A clause committing to keep transaction-related records for a fixed number of years tells you records exist and are durable.
• Disclosure to authorities “where legal provisions apply”. Every company complies with valid legal process; that is not the finding. The finding is that there is something to disclose.
• “Detecting and preventing violations of law.” This describes monitoring of user activity as a designed function, not an incidental capability.

What typically gets collected

Wallet telemetry commonly includes device and session identifiers, IP addresses, feature usage events such as opening the app or initiating a transaction, operating system and locale attributes, timestamps, partner-supplied identifiers used to distinguish users, and the list of crypto accounts configured in the wallet.

Individually these look innocuous. Together they are a longitudinal record linking a network identity to a set of holdings and a behavioural pattern — which is precisely the dataset that makes someone a target.

Referral programmes deserve a second look

A wallet that pays you for bringing in friends must be able to attribute new users to referrers. That requires linking installations to identities, which is in direct tension with the privacy properties people install a self-custody wallet to obtain. The reward mechanism is not the problem; the identity graph it requires is.

Holding your own keys and revealing your entire financial history are not mutually exclusive. A wallet can be perfectly non-custodial and still route every query through servers the vendor controls.

What the vendor sees when it proxies

When your wallet asks the vendor’s backend for balances and history rather than querying the network directly, that backend necessarily learns:

• Every address in your wallet, including ones you have never spent from
• Your complete balance and transaction history, correlated across assets
• Your IP address, and therefore approximate location, on every launch
• Timing patterns — when you check, when you move funds

That is a more complete picture of your finances than most banks hold, assembled by a company you never signed a custody agreement with.

How to tell

1. Look for a node setting. Wallets designed for privacy let you point at your own node or a chosen public one. If there is no such setting, the endpoint is fixed and it is theirs.
2. Watch the restore speed. This is the sharpest tell available to a non-technical user. Genuine light-client synchronisation over a real chain takes minutes and requires the app to stay open. If you import a seed phrase and a full multi-asset balance appears in two seconds, the wallet asked a server that already had the answer indexed.
3. Read the docs for “SPV” claims critically. Some wallets describe themselves as light clients while in practice loading data from vendor infrastructure. The interface looks like a wallet; the wallet is largely a front end for a remote service.

A related trap: a slow restore is often mistaken for lost funds. Users import a seed, see a zero balance, panic, and conclude they have been robbed — when the wallet simply had not finished scanning. Waiting is the correct response. Instant restores are the ones that should raise an eyebrow.

Ask early: where does the revenue come from, and is it enough? An unfunded team maintaining security-critical software is a slow-motion risk, regardless of intentions.

Models, ranked by how they align with you

Promoted assets are a specific hazard

When a wallet surfaces “trending” tokens or integrates market data feeds, understand that placement in those feeds is frequently a commercial arrangement rather than a signal of quality. Rankings, listings, and featured slots across the industry are routinely paid for. A wallet that presents them as neutral discovery is steering your allocation on someone else’s behalf.

The same applies to a prominent stablecoin or chain integration on a hardware wallet’s homepage. That is placement, not endorsement, and it is not a security assessment of the asset.

A wallet that earns money from where you put your coins is not a neutral place to keep them.

Every non-trivial codebase has vulnerabilities. What distinguishes vendors is the response process — and unlike code quality, the response process is fully visible from outside.

Signals of a mature process

• A published security contact and a documented disclosure policy
• A bug bounty with stated scope and payouts
• Public post-incident write-ups with timelines, including what went wrong internally
• Fixes shipped in days, with users actively notified that they must update
• Credit given to reporters

Signals of an immature one

• No disclosure channel — researchers must find an executive on social media
• Reports acknowledged, then silence for weeks
• Findings characterised as “implausible” before being assessed
• Discussion of the reporter’s motives or emotional state instead of the finding
• Questions deleted or users quietly restricted in official community channels
• Marketing claims silently edited after they are contradicted

The disclosure timing trap

There is a real dilemma in how to ship a security fix. Announce it loudly and you tell attackers exactly where to look, but users update quickly. Ship it quietly and attackers get less warning, but most users never update. Both are defensible.

The failure mode is doing both badly: drawing attention to security fixes in release notes while not telling users they urgently need to install them. That combination gives attackers the hint without giving users the head start — and it is a documented pattern in this industry, not a theoretical one.

Rigorous evaluation starts by replacing “is this wallet safe?” with a precise question: which parties can compromise my funds, under what capability, and what would it cost them?

The trust set

For any wallet, enumerate every party in this list and decide whether you are content to trust each one:

Reduce the set before you evaluate it

The most effective move is not evaluating each party more carefully — it is removing parties. Generating your seed offline and independently removes the wallet developer from the key-generation step. Verifying addresses on a dedicated device removes the host computer from address integrity. Splitting keys across vendors via multisig means no single vendor compromise is sufficient.

Due diligence has a ceiling. Architecture does not. Prefer designs where being wrong about a vendor is survivable.

This is the deepest and least visible failure mode in the entire category, and the one where reading the code matters most.

BIP39 standardises the encoding of entropy into words. It does not standardise the generation of that entropy. Two twelve-word phrases can be visually indistinguishable, both valid, both passing checksum, and differ by a hundred bits of real unpredictability. The wallet chooses the entropy source; the standard only says how to write the result down.

The documented failure

The canonical case is a widely used mobile wallet whose key generation drew on the device clock as its effective source of randomness. Because the timestamp space over any given period is small and enumerable, an attacker could generate every candidate phrase for a range of moments, derive the corresponding addresses, check them against the chain, and sweep any that held funds. The issue was assigned a CVE and investigated by a national standards body after funds were stolen.

Two details make this case instructive beyond the specific product:

• It affected one platform and not the other. The builds that could be compared against published source were fine; the builds that could not be independently verified were the ones carrying the flaw. Verifiability and correctness turned out to be correlated in exactly the way you would predict.
• The flawed code used a well-regarded cryptographic library. Importing a good library does not help if it is fed a bad entropy source. Library provenance is not a substitute for reviewing how it is called.

The adversarial version

Weak entropy can also be deliberate and far harder to detect. A generator seeded from a value the vendor knows — a hidden constant, a device identifier, an unpublished salt — produces phrases that pass every statistical test an outsider can run, while remaining reproducible by the party who knows the secret. From the outside, backdoored randomness and good randomness are indistinguishable without reading the generator.

The demonstrated hardware version of this is starker still. A researcher showed that with control of a device’s display and buttons, the onboarding process could be modified so that key generation ran with entropy forced to zero — producing a phrase that looked like a normal wordlist output while being entirely predictable — and the warning that would have alerted the user could be suppressed on the same screen the user was trusting.

Removing the vendor from key generation

Practical options, in rough order of accessibility:

1. Dice. 128 or 256 bits from physical dice rolls, converted to a BIP39 phrase using a documented, offline procedure. Slow, auditable, and dependent on no software you did not choose.
2. Multiple independent sources combined. Mix device-generated entropy with user-supplied entropy where the wallet supports it, so that neither source alone determines the result.
3. Cross-implementation verification. Whatever generated the phrase, confirm that an unrelated implementation derives the same addresses from it. This does not prove the entropy was strong, but it proves the phrase is standard and portable.
4. Vendor-diverse multisig. If keys come from different vendors with different generators, a weakness in one does not by itself unlock the funds.

PENGER exists partly because of this: the plate is a medium for a phrase you generated on your own terms, encoded by hand, with no software involved in the recording step. See the simulators to practise the encode and decode cycle before committing anything to metal.

For hardware, evaluation must extend past the code to the physical object and everyone who touched it. The full technical treatment is in Hardware Wallets: What They Actually Protect; here we cover it as a vendor-assessment question.

Questions to put to a hardware vendor

• Is there cryptographic attestation, and what exactly does it cover? Attestation that validates one chip while a second, unattested chip drives the screen and buttons covers less than it appears to.
• What is the returns policy for devices? This is the question most buyers never ask. If a vendor accepts returns of sealed-looking units and returns them to sale, then a unit you buy may have been in a stranger’s possession. For most electronics this is a non-issue. For a device whose entire purpose is holding secrets, a resale pipeline is an open supply-chain channel that an attacker can enter cheaply and repeatedly.
• What is the position on third-party resellers? Some vendors have publicly stated that buying from open marketplaces is acceptable because attestation protects the user. Treat that claim with scepticism proportional to how much of the device attestation actually covers.
• What does the tamper-evidence actually prove? Holographic seals are cheap to reproduce. Some vendors omit them deliberately and rely on attestation instead, which is a coherent position — but it means the seal is not part of your defence, and you should know that rather than assume a seal you can see is meaningful.

An attacker who compromises a wallet’s update or distribution mechanism does not need to defeat the wallet’s cryptography. They are handed the ability to run code on every user’s machine, at once, delivered through the exact channel users have been trained to trust.

Why it beats every other attack

• It scales to the entire user base in a single action
• It arrives via the official path, defeating “only download from the official site”
• It can be brief — a window of a few hours is enough to do serious damage
• It is difficult to attribute afterwards, and easy to describe as an isolated incident

The dependency variant

Modern wallets ship code that loads further code at runtime — connection kits, analytics, remote configuration, feature flags. Each of these is a channel through which a third party can change behaviour after installation without any update the user consents to.

A documented instance of this class: a widely used wallet-connection library, distributed via CDN and loaded at runtime by many independent applications, was compromised through a legitimate account that had never been deactivated after the holder left the organisation. Because the loader trusted whatever the CDN returned, malicious code propagated not just to that vendor’s users but into a long list of unrelated applications that had embedded the same library. The blast radius extended far past the company that was breached.

Every runtime-loaded dependency is a party with the ability to change your wallet’s behaviour tomorrow, without shipping an update and without asking you.

What to assess

Some vendors offer an optional service that backs up your key material to third parties, so that a lost device or lost phrase does not mean lost funds — typically by splitting encrypted key shares across several custodians and releasing them after identity verification.

The engineering is often genuinely sophisticated, and the user need is real: irreversible loss is the single largest cause of destroyed crypto. But an accurate evaluation has to separate three claims that get argued as one.

Claim 1: it is a backdoor

Not in the strict sense. A feature that requires possession of the device, knowledge of the PIN, and explicit opt-in is not a covert access mechanism, and describing it as one obscures the actual issue.

Claim 2: the risk only applies if you enable it

This is where the argument fails. The security-relevant fact is not whether you enable the feature — it is that the device firmware now contains a code path capable of exporting key material off the device. Before, that capability did not exist and no compromise could invoke it. After, the capability exists and its use is gated by authorisation logic. The question shifts from “can keys leave?” to “is the gate correct, in all versions, forever?” That is a materially weaker guarantee, and it applies to every user of that firmware.

Claim 3: it contradicts what was promised

This one is fair and matters for vendor assessment. Where a vendor has stated for years that keys can never leave the device, and then ships a mechanism for keys to leave the device, the specific feature is less important than what it reveals: architectural guarantees you were given were in fact product decisions, revisable later without your involvement.

There is a related honesty signal worth noting. When a vendor’s own leadership publicly advises that people for whom privacy is the highest priority should not use the product, that is useful information delivered plainly, and it should be taken at face value rather than dismissed as a slip.

Most of what has been described requires resources you do not have. These do not. Each one converts an assumption into a tested fact.

1. Cross-implementation derivation

Take your phrase and derive addresses in two unrelated implementations — ideally one of them offline and one you compiled yourself. Matching addresses prove the phrase is standard, the derivation paths are conventional, and you are not locked to one vendor’s interpretation. Mismatches almost always mean a non-standard derivation path, which is exactly the sort of thing you want to discover now rather than during a recovery.

2. The full recovery drill

Wipe the device. Restore from your physical backup only — not from a note, not from memory. Confirm the balance. Do this on a schedule, and do it before the holding is large. An untested backup is a hypothesis.

3. The canary wallet

Maintain a phrase, generated the same way as your real one, holding a small balance, in a wallet you leave installed and occasionally open. If it is ever drained, you have learned something urgent about your setup while the cost is trivial. This detects classes of compromise — weak generation, a malicious update — that produce no other visible symptom until it is too late.

4. Address verification discipline

Confirm receiving addresses on the device screen, not only in the host application. Software running on your computer generates and displays addresses, and code that can modify what your screen shows can substitute an address before you ever copy it — including regenerating the QR code so both representations agree with each other and disagree with reality.

This attack class has been documented in shipped products, and required no administrative privileges on the host. The defence is entirely in your hands: the address is not confirmed until the device with its own screen has shown it to you. Note that vendors do not always enforce this for incoming transactions the way they enforce confirmation of outgoing ones, and the feature is sometimes present but undocumented and not part of the default flow.

5. Network observation

If you can, watch what the wallet contacts on first launch. You are looking for whether it queries a public node or a vendor endpoint, whether analytics fire before you consent, and whether anything is transmitted during seed generation or import. This is straightforward with a local proxy and is the fastest way to settle the question in Does It Talk to the Chain, or to the Vendor? definitively.

6. Read the generator

Where source is available, one function matters more than the rest of the codebase: the one that produces entropy. Find it. Confirm it calls the platform CSPRNG, that nothing supplements or replaces that with time, device identifiers, or constants, and that the result is not logged, transmitted, or stored anywhere. This is a short read, and it is the highest-value hour you can spend on any wallet’s code.

Score each dimension from 0 to 3. The purpose is not the total — it is to make yourself write down what you actually know, and to expose which conclusions rest on evidence and which rest on reputation.

How to read your own scores

• Key sovereignty below 3 is disqualifying. Everything else is a refinement on top of owning your keys. If you do not own them, refinements do not apply.
• Entropy provenance and update integrity are the two dimensions where a low score cannot be compensated elsewhere. A weak seed cannot be protected by good storage; a hostile update defeats good habits.
• Failure survivability outranks vendor quality. A mediocre vendor inside a 2-of-3 across three vendors is a better position than an excellent vendor holding your only key. Diversification is doing work that no amount of research can do.
• Reputation is not a dimension. Popularity measures marketing reach. Some of the most-recommended products in this field have the longest incident histories, precisely because scale attracts both users and attackers.