The previous article discussed BIP and reviewed those hardware wallet incidents.
In fact, BIP is not a standard exclusive to hardware wallets. The BIP32, BIP39 and BIP44 set comprises public technical specifications for key generation and hierarchical deterministic derivation, and any wallet can implement these rules.
The wallet app on your phone can likewise use BIP39 to generate a mnemonic and BIP32 to perform hierarchical deterministic key derivation, following the standard BIP44 paths.
The cryptographic foundations of these two types of wallets are the same system.
What truly creates the difference comes down to two core elements: where the private keys are stored, and where transactions are signed.
Differences in the storage and signing environments further give rise to divergent security risks, custody obligations and paths to legal remedies, ultimately producing entirely different legal consequences.
I. One set of standards, two implementations
First, the similarities between the two:
BIP39 governs mnemonic and seed generation, BIP32 governs hierarchical deterministic key tree derivation, and BIP44 standardizes account paths.
These specifications are conventions at the software level and do not restrict the hardware device on which they run. One intuitive phenomenon illustrates this:
A mnemonic generated by a hardware wallet can be imported into a mobile hot wallet and, as long as the derivation path matches, all assets can be fully restored; the reverse operation holds equally true.
What determines the entire key system is the mnemonic and the algorithm, not the wallet device itself.
Cryptographic algorithms themselves are neither superior nor inferior to one another; a hardware wallet does not mean stronger cryptography—it merely changes the environment in which the private key is stored and signatures are made.
So what exactly does this difference in environment mean?
A hardware wallet's private key is generated and stored locally inside the device, and transaction signing is likewise completed inside the device.
Most models store the private key in a dedicated secure element, while some models rely on a general-purpose microcontroller, open-source firmware and a PIN code for protection.
Only the transaction to be signed is passed in from outside, and the signature result is output externally; the private key is never exported from the hardware device throughout the process.
A hot wallet's private key is kept locally on a phone or computer, possibly as an encrypted file or in the system keychain;
when performing signature computations, the private key may even briefly exist in plaintext in the device's memory, and the signature computation is completed directly on an internet-connected terminal.
Hot wallets rely entirely on the screen of the phone or computer system, and malicious programs have the opportunity to tamper with the content displayed on the page; the transaction information you see may not be the content actually signed.
II. High-incidence risks of the two types of wallets
Hardware wallets inherently resist remote theft from the internet.
The private key is not exposed on an internet-connected device, so even if an attacker gains complete control of your computer, they cannot directly obtain the private key. When hardware wallets run into trouble, it mostly comes down to the three types of scenarios mentioned in the previous article:
1. Defects in the factory entropy source.The Coldcard incident is a typical example: the firmware code's judgment logic was written incorrectly, the hardware's true random source was in fact not enabled, and the seed was generated based on a predictable chip ID and timer. On early models, the security entropy dropped directly from 128 bits to 40 bits, so the seed could be brute-forced in bulk from the moment it was generated.
2. Supply chain tampering.In the Ledger modified-device incident, the secure chip itself was intact, but the distributor installed an additional hardware module inside the device. At the moment the user initialized the device and the mnemonic was displayed in plaintext on the screen, the mnemonic was stolen and transmitted externally.
3. Risks arising from user custody errors.If a photo of the mnemonic is stored on a phone with cloud synchronization enabled, or the physical copy of the mnemonic is kept in the same place as the hardware wallet, then once it is leaked, all protections become effectively useless.
In the case of hardware wallet theft, it is almost never the case that a hacker remotely steals the private key over the network. A hardware wallet isolates network attacks, but the risk shifts to physical transfer and human custody behavior.
The risk of software hot wallets, by contrast, arises from the device being connected to the internet.
The private key runs on an internet-connected terminal, and once the device is compromised, the private key faces a risk of leakage.
Trojan programs, keyloggers and screen recording are traditional attack methods; automatic cloud synchronization of wallet backup files on mobile phones is a high-frequency point; and counterfeit wallet apps in app stores can also directly trick users out of their mnemonics.
There is also another category that many users find hard to detect:
The private key was not stolen and no transfer occurred; instead, the user manually signed a token authorization transaction granting a strange contract the authority to dispose of the assets. This transaction is entirely lawful on-chain, and the signature was completed by the user personally. Afterwards, it is very difficult to find a technical vulnerability in the wallet program, but this is a security risk in an interaction scenario, not a defect in the wallet's underlying algorithm.
This is further compounded by the screen-tampering risk mentioned earlier: malicious programs tamper with the interface so that the page displays address A, while the actual signature points to address B.
III. Boundaries of Legal Liability
1. Users' custody obligations differ.
Self-custody is not a statutory concept under PRC written law, but a consensus has formed in practice:Where self-custody is chosen, the private key is controlled by the holder, and the corresponding custody obligation also rests with the holder.
When using a software hot wallet, users bear broader security obligations:
keeping device systems updated, not installing software of unknown origin, not clicking unfamiliar links, and not backing up seed phrases by screenshot.
Once a theft occurs, failure to satisfy any one of the above may be found to constitute fault on the part of the user.
The scope of obligations for hardware wallet users is relatively narrower:
the core is to keep the seed phrase from being disclosed; as long as the seed phrase is secure, network attacks cannot harm the assets; but once the seed phrase is leaked, all hardware-level protections are reduced to zero.
The difference in the logic of fault determination between the two is:
for software wallets, fault is dispersed across every instance of daily device use;
for hardware wallets, risk is concentrated at the key junctures of seed phrase generation, transcription, and backup.
2. The targets of accountability and the paths to pursue it differ.
Hardware wallets are physical electronic products, so in theory a product liability tort path is available.
In practice, however, the evidentiary obstacles are considerable. China currently has no mandatory national standard for hardware wallets, and the relevant industry standards are mostly recommendatory. Product defects must therefore be established through industry practice and technical appraisal.
At the same time, judicial practice in China is divided on the proprietary attributes of virtual currency, and the criteria for determining the amount of loss are inconsistent. Where devices are purchased overseas, practical obstacles also arise, including jurisdiction, cross-border evidence collection and enforcement of judgments.
Even if a product defect can be established, that does not mean compensation can be obtained smoothly.
Software hot wallets are software services, and the position for safeguarding rights is even more difficult.
Being open source does not mean there is no responsible entity, but many project entities are located overseas, and community-driven open-source wallets may have no clearly identified operating entity at all, making it difficult even to identify a proper defendant.
Even for software hot wallets maintained by a formal commercial company, the user agreement will generally state that the software is "provided and used as is, with no guarantee that it is absolutely free of defects"; and even if a court orders the service provider to pay compensation, at most it will compensate only the money you paid to the platform.
Most hot wallets, however, are provided to users free of charge, and users have paid nothing, which means that, at the contractual level, compensation for losses is almost impossible to obtain.
3. The position regarding reporting to the authorities and recovering stolen assets differs.
Theft from a hot wallet is mostly a remote network intrusion, and the electronic evidence spans multiple devices and multiple servers, making the chain of evidence lengthy.
Once the assets enter a mixer or a cross-chain bridge, the difficulty of recovering them rises sharply.
In practice, we also frequently encounter a case-filing challenge: how to prove that the transfer was not carried out by the user personally.
The theft of hardware wallet assets mostly stems from mnemonic phrase leakage, device substitution, or unauthorized transfers by others after taking custody on the user's behalf; such cases often involve physical movement and personal contact leads, making it easier to secure testimonial and physical evidence.
IV. There Is No Absolutely Secure Wallet
Hua Ge does not favor directly recommending a particular product, but usage can be differentiated by scenario:
For large-value, long-term holdings,give priority to hardware wallets with a trusted screen, keeping network-attack variables isolated.
What needs protection is not the hardware device but the mnemonic phrase; a damaged device can be repurchased, but if the mnemonic phrase is lost, the assets are permanently extinguished.
For daily high-frequency interactions and small-value use,software hot wallets are more convenient.
But remember: as far as possible, do not store assets beyond the range of losses you can bear.
Many people understand self-custody simply as a technology, but in fact it is more like a risk-allocation arrangement: with no platform to backstop it, all risks are ultimately borne by the asset holder.
Whether a hardware wallet or a software hot wallet, as long as the mnemonic phrase is generated in accordance with the BIP specifications, the mnemonic phrase is the core credential for the assets; if a Passphrase is additionally set, that passphrase likewise needs to be properly safeguarded.
Once a mnemonic phrase is leaked, self-custody security is rendered ineffective, regardless of which type of wallet device you use.
One final question
What is the approximate ratio of hardware wallets to software wallets in your current asset holdings? Have you ever considered whether you could fully recover all your assets if your phone were lost or your computer were infected with malware?
In the next article, Huage will discuss the legal issues behind BIP39 mnemonic phrases: custodial arrangements, estate division, and criminal misappropriation. In these scenarios, do those twelve mnemonic words constitute a document of title to property, evidence in a case, or a latent source of liability?
Lawyer WeChat: fortunefukun
