"The private key was not leaked" is the most dangerous placebo: How to choose truly reliable crypto products?

If a crypto product has never suffered a user private key leak, does that mean it is secure enough?

The answer is obviously not that simple.

As is well known, from late September to the end of October, the crypto industry went through a rather intense security stress test, with a series of far-reaching security incidents exposed one after another, from the world's leading centralized trading platforms to long-established well-known hardware wallet manufacturers.

If you carefully examine the official announcements after these incidents, you will notice a recurring phrasing: "there is no evidence that private keys were leaked," or "user private keys and seed phrases were not affected."

But the entry points attackers look for may not lie in private keys at all—when an exchange's internal permissions can be stolen, when third-party security products become a springboard into management systems, when hardware devices are implanted with malicious modules, and even when users' real names, contact information, and home addresses are exposed due to data leaks, simply emphasizing that "private keys were not leaked" is clearly insufficient to cover all the risks users face.

After all, private key security is only the starting point of crypto asset security, not the end point.

This also means we need to re-examine a question: in today's crypto world, how exactly should one judge whether a product is truly secure and reliable?

1. How Do Attackers Bypass Private Keys, and How Are Assets and Data Compromised?

A previous article mentioned that if you observe recent security incidents together, you will notice an obvious trend: attackers do not necessarily need to directly break cryptography and private keys themselves; instead, they may look for breakthrough points across the entire "chain of trust."

From employee endpoints and third-party security products to the software supply chain, service containers, and even transaction authorization processes, a crack in any one link may render an otherwise seemingly rigorous security system ineffective:

• In the Bybit incident, attackers used social engineering to compromise the device of a Safe developer, obtaining the relevant access credentials and thereby controlling front-end resources in Safe's wallet infrastructure;
• In the Bitget incident, attackers exploited a vulnerability in a third-party security product to obtain internal high-privilege credentials, then bypassed existing risk controls through forged withdrawal instructions;
• In the latest Binance incident, the attack path most likely began with the compromise of a DevOps engineer's laptop (though Binance later said further investigation found other intrusion points, and the full attack path remains to be confirmed);

The three incidents involved third-party wallet infrastructure, a third-party security product, and an internal development and operations environment, respectively.

This also explains why traditional cold wallets and multi-signature mechanisms cannot cure all problems. After all, what attackers actually exploit are precisely those trust links that can influence final transaction execution but have not been sufficiently independently verified.

In the final analysis, in a centralized asset management system, attackers may not need to directly obtain user private keys; as long as they can control transaction instructions, approval processes, or wallet execution systems, they may trigger unauthorized asset transfers.

Beyond the asset execution chain, another type of risk is more easily underestimated by ordinary users: data leaks.

In May 2025, Coinbase disclosed an insider data theft incident. Attackers bribed some overseas customer service personnel and used their normal work permissions to access the internal customer support system, stealing some users' personal information, account details, and transaction-related information.

Coinbase said the incident did not result in the direct leakage of user passwords, private keys, or funds, but the attackers obtained this information precisely to carry out targeted social engineering attacks later, impersonating official customer service to induce users to transfer assets.

The Keystone incident further demonstrates that user data leaks can also affect hardware wallet device authenticity verification.

On October 20, Keystone's official website was accessed without authorization. According to its subsequent disclosure, attackers exploited a vulnerability in a third-party data monitoring tool on the website to obtain some users' purchase records and the WebAuth keys used to verify device authenticity.

This means that even if users' seed phrases and private keys are not directly leaked, attackers may still use stolen verification keys to create counterfeit devices that pass official authentication, causing users to unknowingly use risky hardware wallets.

Not to mention the device and supply chain security issues revealed by Ledger, which also require manufacturers to ensure that during hardware production, certification, logistics, and sales, there is no possibility of devices being replaced, tampered with, or implanted with malicious modules.

These problems may appear to occur in different parts of a product, but ultimately they may converge on the same outcome: users losing control of their own assets.

Therefore, the fact that private keys have not been directly leaked does not mean the product's overall security system has not been breached, especially as the rapid development of AI is further amplifying this risk.

2. How Can One Judge Whether a Crypto Product Is Secure and Reliable?

Having understood these incidents, let us return to the question ordinary users truly need to face: if they want to choose a relatively secure and reliable crypto product, what exactly should they look at?

Compared with brand awareness, product features, and marketing claims, imToken believes at least three dimensions deserve priority consideration.

1. Private Key Control: Who Actually Controls the Assets?

This is the most basic and most important question when judging the security architecture of a crypto product.

First, it is necessary to distinguish between two completely different models: custodial and non-custodial.

Take centralized exchanges as an example. Users usually manage their assets through an account system. After depositing funds, the assets enter a wallet system controlled by the exchange, and the platform records user balances through an internal account system and is responsible for withdrawals, risk control, and fund management.

The advantage of this model is convenience. Users do not need to manage private keys themselves, but it also means users must trust the platform's asset custody, internal permissions, and operational management mechanisms. Once the platform experiences system failures, loss of control over internal permissions, or fund management problems, users may be unable to access or withdraw assets normally.

Non-custodial wallets are different.

When users create a wallet, the private key is generated in the local environment and kept by the users themselves. The wallet mainly handles key management, transaction construction, and signing, while the actual assets are recorded on the blockchain.

Structurally, there is a clear difference between the two:

• Centralized custody: user → platform account and permission system → platform-controlled wallet → on-chain assets;
• Non-custodial wallet: user holds the private key → wallet provides management and signing tools → on-chain address directly controlled by the user;

This means the non-custodial model reduces the platform's role as asset custodian and also reduces the links in which users must rely on a centralized platform to control assets.

Of course, this does not mean non-custodial wallets are absolutely secure.

Users need to back up seed phrases themselves, protect device security, and take responsibility for every transaction and signature. Once a seed phrase is leaked, or the user actively signs a malicious transaction, assets may still be lost.

Therefore, when choosing a wallet, one should at least clarify three questions: Is the private key generated on the user's device or by the server? Will the private key and seed phrase be uploaded to the service provider's servers? Does the user truly hold signing authority and can the user restore assets in other compatible wallets?

2. Data Privacy: How Much Information About You Does the Product Actually Collect?

The second dimension is privacy protection, which many users tend to overlook.

In the process of using crypto products, users may leave behind a large amount of information, including email addresses, phone numbers, identity verification materials, device information, purchase records, shipping addresses, and even account balances and transaction history.

Not every product needs to collect all of this data.

For example, centralized exchanges usually need to conduct identity verification because they involve account systems and compliance requirements; whereas a basic non-custodial wallet, whose core function is to manage keys locally and initiate on-chain transactions, does not need to grasp users' real identity information in the same way.

The most noteworthy point here is whether a product follows the principle of data minimization.

For example, are users' real identities, contact information, device information, and on-chain addresses unnecessarily linked?

Once such data is stored in a centralized manner, attackers can more easily build complete user profiles, leading to the "$5 wrench attack." After all, no matter how strong the encryption algorithm is, it cannot solve the problem of attackers directly locating the asset holder (further reading: "Web3 Wallets' "Troubled Times": In the AI Era, How to Understand the Evolution of the "Spear and Shield" of Crypto Security?").

3. Security Architecture: Is There a Continuously Verified Security Mechanism?

The third dimension is the technical security capability behind the product.

For software wallets, focus should be on private key generation, encrypted storage, transaction signing, and code security; for hardware wallets, further attention should be paid to secure chips, firmware integrity, device authentication, and supply chain management.

But regardless of the type of product, there are some general criteria for judgment.

First, whether the core code is reviewable. Open source does not mean absolute security, but at least it gives external developers and security researchers the opportunity to review critical code.

Second, whether it has undergone independent security audits. One can look at whether the product cooperates with professional security institutions, which modules the audits cover, which versions they correspond to, and whether the issues found have been fixed.

It should be noted that an audit report is only a security assessment at a specific time and within a specific scope, and it does not mean the entire product will be free of vulnerabilities from then on.

Third, whether a vulnerability bounty and continuous testing mechanism has been established. Because security is not a one-time task, as products continue to upgrade and integrate new chains and third-party components, the attack surface also keeps changing. Therefore, whether there are public vulnerability feedback channels, vulnerability bounty programs, and well-established version review and permission management mechanisms are all indicators worth watching.

Finally, one should also examine whether the product has sufficient security transparency. For example, after a security incident occurs, whether it can promptly disclose the scope of impact, cause of the attack, user response measures, and remediation progress is also an important standard for measuring whether a product deserves long-term trust.

Ultimately, security audits, open source, hardware isolation, and bug bounties are not talismans on their own.

A truly reliable security system should be able to isolate risk to the local level as much as possible, so that even if a problem occurs in one link, it will not easily escalate into a total loss of user control over assets.

3. How Can Web3 Products Build a Long-Term Security System?

Returning to wallet products themselves, taking imToken's security philosophy as an example, the core lies in letting users hold asset control as much as possible while reducing the possibility of private key and sensitive information exposure through product architecture and continuous security review.

1. Non-Custodial Architecture: Putting Private Keys Truly in Users' Hands

Unlike platforms that require centralized custody of user assets, imToken adopts a non-custodial wallet architecture.

In this model, when users create a wallet, the private key is generated locally and kept by the users themselves. imToken does not store users' private keys and seed phrases, nor does it use a centralized account system to control on-chain assets on behalf of users.

Currently, the imToken software wallet uses secure random number sources provided by iOS and Android systems to generate private keys locally, and its core code TokenCore has been open source since 2018.

For the imKey hardware wallet, seed phrases and private keys are generated through a true random number generator (TRNG) built into the secure chip, providing an independent hardware security foundation for key generation.

The significance of this design is not just to give users a seed phrase.

More importantly, it reduces, from the architectural level, the need for service providers to access and centrally manage user private keys, and lowers the risk of directly affecting users' asset control when platform servers, internal personnel permissions, or centralized custody systems encounter problems.

2. From Data Privacy to Code Audits: Security Goes Beyond Private Keys

The non-custodial architecture solves the issue of asset control, but a wallet still needs to face security challenges brought by applications, servers, third-party components, and external interactions.

In terms of data privacy, imToken has publicly stated that the product uses development tools such as Sentry and Firebase for error reporting and statistics, but does not collect sensitive data involving wallet security. This means that necessary product operation statistics and core security information such as user private keys and seed phrases need to maintain clear boundaries in product design.

In terms of technical review, imToken has long cooperated with professional security institutions such as SlowMist to conduct security audits of software wallets, hardware wallets, and smart contracts.

At the same time, the product also has a dedicated internal security team to review code permissions, version updates, and third-party dependencies, and to conduct black-box and white-box security testing before product launch.

Together, these mechanisms form a continuous security management system covering the entire process from key generation and storage to code updates, external audits, and vulnerability discovery and remediation, rather than relying only on a single technology or a one-time security certification.

3. Security Is Not About Never Being Attacked, but About Preventing Risk From Easily Reaching Assets

For users who hold large amounts of crypto assets for the long term, relying solely on everyday internet-connected devices may not be the most appropriate way to manage assets.

In addition to using hardware wallets, imToken also supports transmitting transaction information between an offline wallet and a watch-only wallet via QR codes.

Specifically, users can prepare an old phone that is no longer connected to the internet, install imToken and create an offline wallet, and then use a QR code connection method supporting the ERC-4527 protocol to work in coordination with a watch-only wallet on another internet-connected device.

When users need to transfer funds, the internet-connected device constructs an unsigned transaction and passes it to the offline device via QR code; after verifying the transaction contents, the offline device uses the local private key to complete signing, then sends the signed result back to the internet-connected device via QR code for broadcasting.

Throughout the process, the offline device's private key never needs to touch the internet. This is equivalent to adding a physical isolation layer in the daily asset management process, reducing the possibility of cyberattacks directly reaching the private key.

For users who want further hardware-level protection, the imToken ecosystem also offers the imKey hardware wallet.

imKey uses the Infineon SLE78 series secure chip, whose underlying M7893 security controller platform has passed CC EAL6+ enhanced certification and supports capabilities such as secure storage, secure boot, and true random number generation.

At the same time, imKey also provides verification mechanisms such as device binding codes, first-time activation processes, and device activation status checks to help users identify whether the device is in the expected usage state.

These measures are especially worth understanding in the context of the recent Ledger and Keystone incidents. Hardware security is not just about whether the chip itself is reliable enough; it also requires consideration of device sourcing, initialization, and authenticity verification.

Of course, device authentication mechanisms are not absolute anti-counterfeiting guarantees. Users should still purchase through official channels and carefully check device status when using it for the first time.

Final Thoughts

Looking back at a series of security incidents involving Binance, Coinbase, Ledger, and Keystone, we will find that the security boundaries of crypto products are becoming increasingly complex.

What users need to protect is no longer just seed phrases and private keys, but also identity information, purchase records, device authenticity, and sensitive data that may be exposed throughout the entire usage process.

For ordinary users, when choosing a crypto product, they may first ask themselves three questions:

Who controls my private key? Do I truly have control over my assets? What data does the product collect about me? Will this information be over-collected, retained for a long time, or handed over to third parties? How does it prove it is secure enough? Does it have