Self-Custody and Wallets: How Holding Your Own Keys Actually Works, and How to Check the Hardware

Ten hardware wallet projects publish firmware source code on GitHub. Over the twelve months to 6 August 2026, the busiest of them recorded 2,582 commits across all 52 weeks. The quietest recorded five commits across four weeks.² Both devices are sold today, both are described as open source, and both are recommended in the same listicles. That spread—three orders of magnitude in maintenance activity between products marketed as equivalent—is the most useful thing we can tell you about choosing one, and it is not in any review.

This page is the standing reference for self-custody: what holding your own keys actually involves, what the hardware does and does not do, how to back it up, how it fails, and how to check a vendor rather than trust one.

What self-custody actually means

A crypto wallet does not hold coins. Coins are entries on a ledger, and the ledger is the chain. What a wallet holds is a private key: a number large enough that guessing it is not a strategy, which produces the signatures that authorise a change to the ledger. Self-custody means you hold that number and nobody else does.

Almost every modern wallet derives all of its keys from a single seed, usually presented to you as twelve or twenty-four words. Those words are the wallet. The device is a convenience; the app is a convenience; the words are the asset. Anyone with the words has the money, from anywhere, forever, without needing your device or your PIN.

This is the trade the whole category rests on. Custody with a company means you can be defrauded, frozen, or caught in a bankruptcy, but you can also ring somebody. Self-custody removes all of that and replaces it with a single unforgiving condition: keep the words, and keep them private. There is no reset. We look at how the two failure modes compare, and how often each ends in the money coming back, in a separate count.

Hot, cold, and the distinction that actually matters

The usual split is hot wallets, which are connected to the internet, and cold wallets, which are not. It is a useful shorthand and a slightly misleading one, because almost all cold wallets touch a connected computer at some point in their lives.

The distinction that matters is narrower: does the private key ever exist in the memory of an internet-connected general-purpose computer? On a hardware wallet, the key is generated on the device and signing happens on the device; what crosses the cable is an unsigned transaction going in and a signature coming out. On a browser extension or a phone app, the key is decrypted into the memory of a machine that also runs everything else you run.

That is why the answer for most people is both. A software wallet holding an amount you would be annoyed but not ruined to lose, for daily use. A hardware wallet holding the rest, touched rarely.

What a hardware wallet actually protects you from

It protects you from remote key extraction. That is the whole product. Malware on your laptop cannot read a key that never arrives on your laptop.

It offers partial protection against blind signing, and only if you use it properly. The screen exists so you can verify the destination address and amount on a device the attacker does not control. A user who approves whatever appears without reading the screen has bought a slower software wallet.

• It does not protect you from a compromised seed phrase. If the words leak, the device is irrelevant.
• It does not protect you from signing a malicious transaction you approved. Token approvals are the common version: you grant a contract permission to move a balance, and it does.
• It does not protect you from physical coercion, which is why the passphrase feature exists and why a decoy wallet is a real strategy for people with a real threat model.
• It does not protect you from losing the backup. The single most common way self-custodied crypto disappears is not theft. It is that nobody can find the words.

The measurement: how hard is anyone actually working on your firmware

Hardware wallet reviews compare screen size, coin support and price. None of them compare the thing that determines whether the device is still safe in three years, which is whether anybody is still maintaining it. That is measurable, publicly and repeatably, and we are not aware of anyone publishing it.

Method. We took ten hardware wallet projects that publish firmware or device-application source on GitHub, and pulled three endpoints from the public GitHub REST API on 6 August 2026: the repository record, the 52-week commit participation series, and the releases list.⁴ Commit counts are the repository owner’s own published history. No account, key or scraping was involved, and anyone can reproduce every figure below with a browser.

Finding 1. Maintenance activity spans three orders of magnitude. Commits over the trailing 52 weeks: Trezor 2,582 across 52 active weeks; BitBox02 1,048 across 51; Keystone 3 805 across 47; Blockstream Jade 373 across 49; Ledger’s Bitcoin application 348 across 44; Coldcard 315 across 46; Krux 280 across 40; SeedSigner 254 across 31; Foundation Passport 2 91 across 25; and OneKey’s firmware repository 5 commits across 4 weeks.²

Finding 2. Consistency separates the field more cleanly than volume. Four projects committed in at least 46 of the last 52 weeks. Three committed in fewer than 32. A repository that goes quiet for five months is not necessarily abandoned, but it is a repository that would not have shipped a fix quickly if one had been needed in those five months.

Finding 3. “Open source” is doing a lot of work. Of the ten repositories, only three carry a license GitHub recognizes as a standard open-source identifier—Apache 2.0 for BitBox02 and for Ledger’s Bitcoin app, MIT for Blockstream Jade and SeedSigner. The remaining repositories carry custom or non-standard license files, which GitHub reports as unidentified.¹ Source-available and open-source are not the same thing, and several well-regarded devices are the former while being marketed as the latter.

Finding 4. The most widely sold device is the one you can inspect least. Ledger’s device operating system is not public; what is public is the application layer. The 348 commits above measure the Bitcoin app, not the firmware that holds the key. We are not saying that is wrong—there is a defensible secure-element argument for it—but a buyer comparing “open source” badges across a shelf is not comparing like with like.

Finding 5. Release cadence is not comparable across the field. Only seven of the ten projects publish dated GitHub Releases; the other three tag versions without them, so a release count would have silently understated three vendors. Among the seven that do, releases in the trailing year ranged from 21 (Keystone 3) down to 1 (SeedSigner).³ We report this as a secondary measure precisely because it is not clean.

What this measurement does not show

It does not show code quality. A thousand commits can be churn and fifty can be careful. Commit volume measures that somebody is there, not that they are good.

It does not show security. No commit count would have predicted any specific hardware wallet vulnerability, and none of these figures should be read as a safety ranking.

It does not account for development happening elsewhere. A quiet public repository can mean a vendor has moved work to a private one or to a successor project. In OneKey’s case we can tell you the public firmware repository recorded five commits in a year; we cannot tell you that the company stopped working, and we are not saying so.

It does not cover closed vendors at all. Several devices with meaningful market share publish nothing, and a device that cannot be measured is not thereby safe. It is unmeasured.

The threat model, in rough order of how often each one happens

Security advice is usually a list of everything that could go wrong, ordered by how frightening it sounds. That is the wrong ordering. Here is ours, ordered by how often we see it end in money actually being gone.

• The backup is lost, destroyed or was never written down properly. No attacker involved. This is the most common outcome and it is entirely preventable.
• The seed phrase is entered into something. A fake support agent, a cloned wallet site, a “validate your wallet” prompt, a migration tool. The seed is the money, and the entire attack industry is organized around getting you to type it.
• A malicious approval is signed. Common on smart contract chains: you approve a contract to spend a token balance, and it does, sometimes months later. Approvals persist until revoked and most people never revoke any.
• The device or backup is found by someone with physical access. Usually not a burglar. Usually somebody who already had a reason to be in the house.
• Address substitution. Malware or a compromised interface swaps the destination address after you copy it. This is what the device screen is for.
• A supply-chain compromised device. Rare, well documented, and the reason for buying direct and refusing any device that arrives pre-initialised.
• An actual firmware vulnerability exploited against you. Real, and last on this list, because it is the least likely thing to happen to any individual holder.

Notice that the top three require no technical skill from the attacker and no flaw in any product. They are process failures. Which is why the boring parts of this page—test the restore, keep two copies, never type the words—matter more than which device you buy.

The seed phrase, and the part everybody gets wrong

The words are generated by the device from hardware randomness. Write them down, on the card supplied or on something better, and understand that this is the whole of your security model.

• Never type them into anything. No legitimate app, support agent, airdrop or migration tool will ever need them. Every single request for them is theft.
• Never photograph them, which puts them in a cloud backup, which puts them in an account protected by a password.
• Paper burns and inkjet ink fades. Steel backup plates exist because house fires exist.
• Two copies in two places. One copy is a single point of failure; a dozen copies is a dozen chances to be found.
• Test the restore before you fund it, with a small amount, on a wiped device. An untested backup is a hypothesis.
• Store the passphrase separately if you use one. A passphrase added to the seed creates a different wallet entirely, and forgetting it is indistinguishable from never having had the money.

The BIP-39 word list is public and the derivation is standardized, which is why a seed from one vendor generally restores on another. That portability is the strongest argument for standard-compliant devices: it means the vendor going out of business is an inconvenience rather than a loss.

Software wallets, approvals, and the mess on smart contract chains

A browser extension or phone wallet is a key stored encrypted on a general-purpose machine, unlocked with a password. That is a reasonable design for spending money and a poor one for storing it. Treat the balance in one the way you treat the cash in your pocket: enough to be useful, not enough to be a disaster.

The specific hazard on chains with smart contracts is the token approval. To let an application move a token on your behalf, you sign a permission. Interfaces routinely request unlimited permissions because it saves the user a transaction later, and those permissions do not expire. A wallet that interacted with thirty applications over two years may be carrying thirty standing authorisations, any one of which is a live route to the balance if the contract behind it is upgraded, exploited or was malicious from the start.

Two habits fix most of this. Grant the amount you are actually spending rather than accepting the default, where the interface allows it. And periodically review and revoke standing approvals, which every major chain now has a public tool for. If you have used the same address for years and never revoked anything, that is the highest-value hour of security work available to you, and it costs only gas.

Signature requests deserve the same skepticism. Not every signature is a transaction; some are off-chain messages that authorise something on a marketplace or a bridge. A message you cannot read in plain language is a message you should not sign.

Multisig, and when it is worth the complexity

A multisignature wallet requires several keys to authorise a transaction—two of three, three of five—so no single key loss and no single key theft is fatal. It is the correct answer for meaningful sums, for shared treasuries, and for anyone whose threat model includes a person rather than only software.

It is also strictly more complex, and complexity is itself a risk. You now have several devices, several backups, and a wallet descriptor that must also be backed up, because the keys alone will not always let you reconstruct the wallet. A two-of-three that nobody in your household understands is worse than a single seed that one person can find. We cover the mechanics in our multisig explainer.

Inheritance, which almost nobody plans for

Self-custody has a specific failure mode that custody does not: the owner dies and the keys die with them. There is no probate process that can compel a blockchain.

The workable approaches are a sealed instruction letter held with your will, describing where the backup is without containing it; a multisig where a key sits with a solicitor or a trusted family member; or a timelocked recovery path. What does not work is assuming someone will figure it out. They will find a metal plate with twenty-four words on it and no idea what it is for.

Sending money without losing it

Every transfer is irreversible and there is no support desk. Three habits, in order of value.

Verify the address on the device screen, not the computer screen. Compare the first and last several characters, and the middle if the device shows it. Address-substituting malware relies on you checking the machine it has already compromised.

Send a test amount first, for any transfer large enough to matter or any destination you have not used before. The fee is the cheapest insurance in the industry.

Check the network as carefully as the address. The same address format exists on several chains, and sending an asset on the wrong network is one of the few mistakes that is sometimes recoverable and usually is not. Where a chain uses a memo or destination tag, omitting it is functionally the same error.

How to check a vendor yourself

• Find the source repository and look at the commit graph. Everything in our measurement above is one page on GitHub. Quiet for six months is a fact you can see in ten seconds.
• Read the license file, not the marketing page. If GitHub does not display a recognized license, the terms are custom and worth reading.
• Check whether builds are reproducible, meaning you can compile the published source and get the binary the vendor ships. This is the only thing that connects the open source you can read to the firmware on your device.
• Look for a security disclosure policy and a history of disclosed issues. A vendor with no disclosed vulnerabilities has either an exceptional record or no researchers looking.
• Buy direct from the manufacturer. Supply-chain tampering on resold devices is a documented attack, not a theoretical one.
• Check the device is not pre-initialised. A device that arrives with a seed phrase already written on a card is an attack, always, without exception.

What would change these conclusions

A vendor moving its firmware to a public repository with a recognized open-source license and reproducible builds would move it up this page, and we would say so at the next re-run.

A published, independent standard for hardware wallet firmware maintenance—disclosure windows, patch commitments, end-of-support dates—would make commit counting unnecessary, which would be a better outcome than us being right.

On OneKey specifically, evidence that development continued in another public repository over the period would change our finding, and we would correct it.

Where this sits in the rest of our coverage

This page is the standing reference for self-custody and wallets. It is re-run quarterly at the same URL with a revision date and a changelog line, not republished as a new post.

• Crypto exchanges explained — the custodial alternative, and what proof of reserves does not prove.
• DeFi explained — what happens to custody once you deposit into a contract.
• What is a multisig wallet — the mechanics of splitting a key.
• Rugpulls are 1.5% of crypto losses, stolen keys are 63% — where the money actually goes.
• Bitcoin explained — the asset most self-custody exists to hold.

Next measurement from this page: the same ten repositories re-counted on 6 November 2026, with any vendor that has published a reproducible-build attestation in the intervening quarter noted separately.

Revision history

6 August 2026 — first publication. All repository figures pulled from the public GitHub REST API on 6 August 2026. Next scheduled re-run 6 November 2026.