Beyond Private Keys: How to Safeguard the Security Boundaries of Web3 from Wallets, L2 to Supply Chains?

By: rootdata|2026/07/09 10:27:27
0
Share
copy

As security risks expand from a single point to a chain, users' defenses must evolve from merely protecting private keys to adopting a comprehensive set of habits.


Written by: imToken


In June, the crypto world experienced a series of security incidents spanning multiple sectors.


PeckShield's latest monthly security report indicates that there were 40 major hacking incidents in June, with total losses reaching as high as $75.87 million. What is even more concerning is that these attacks were not concentrated on a single attack vector; instead, they covered vulnerabilities in wallet signature implementations, L2 protocol flaws, and third-party service supply chain attacks, with multiple defenses failing in the same month.


As Web3 security risks expand from a single entry point to the entire chain's interaction paths, every user must reconsider a crucial question: Are my Crypto assets still safe?



1. The Importance of Wallet Signature Implementations Beyond Private Keys


The security incident that occurred in June on the Cardano ecosystem wallet SecondFi serves as a clear example.


SecondFi was formerly known as the Cardano ecosystem wallet Yoroi. From June 21 to 23, attackers transferred approximately 16 million ADA from some SecondFi user addresses, involving about 374 wallets, which amounted to around $2.4 million based on the price at the time of the incident. SecondFi later stated that they had implemented emergency measures to protect approximately 129 million ADA that could be affected.


What makes this incident particularly unique is that the affected users did not actively give their mnemonic phrases to the attackers; the issue lay in the wallet's underlying signature implementation. According to security agency BlockSec's analysis, the signature nonce was incorrectly derived from public transaction messages, omitting the secret nonce prefix required by standard implementations.


This meant that whenever users signed transactions using the affected version of the wallet, the public signature data published on the chain would expose enough information to derive the address's private key. Therefore, attackers did not need to invade users' phones or obtain mnemonic phrases; they only needed to analyze the publicly available on-chain data to potentially recover the corresponding address's signing private key.


From the user's perspective, the wallet appeared to be functioning normally, as the mnemonic phrases were not exposed through pop-ups, passwords were not cracked, and transactions were indeed initiated by the users themselves. However, from a cryptographic standpoint, as long as a user's address had generated some valid signatures through the affected version, the public transaction and signature data could help attackers derive that address's signing private key.


Ultimately, wallet security depends on whether private keys are generated correctly, whether signatures are completed strictly according to cryptographic standards, and whether these critical codes can be externally audited and verified. This underscores the importance of keeping core wallet components open source.


Of course, this is a specific implementation flaw of a particular wallet version and not a universal issue for all self-custody wallets. For instance, imToken's TokenCore has its core code repository publicly hosted on GitHub, covering key management, address derivation, and transaction signing functions.



While open source does not guarantee that the code is free of vulnerabilities, nor does it mean users can completely let their guard down, for the most sensitive cryptographic and signing components in wallets, open source at least provides an essential premise: security researchers, developers, and the community can inspect the code, reproduce issues, and conduct ongoing testing, rather than relying solely on an unverifiable black box.


For ordinary users, these incidents correspond to several more practical security principles.


  • First, wallets should always be downloaded through official websites or official app stores and updated promptly to secure versions;
  • Second, it is advisable not to store all assets in the same daily interaction wallet; large long-term assets can be stored in hardware wallets or independent cold wallets, isolating them from hot wallets that frequently connect to DApps.
  • More importantly, once the wallet's official confirmation indicates a vulnerability in key generation or signature implementation, merely importing the original mnemonic phrase into another wallet usually does not resolve the issue;

Because importing the same mnemonic phrase into other wallets does not change the addresses and private keys that have already been exposed. Affected assets need to be transferred to a new address that has never signed through the vulnerable version; for ordinary users, a more prudent approach is typically to follow the official emergency process to create a completely new wallet and mnemonic phrase before completing asset migration, rather than repeatedly importing or operating the original address.


2. L2 is Not Just a 'Cheaper Ethereum,' But a Complex Trust Chain


In addition to wallets, multiple incidents in June also pointed to risks associated with increasingly complex L2 systems.


On June 14 and 18, two outdated Rollup deployments related to Aztec were attacked, resulting in total losses of approximately $4.35 million.


It is important to note that the attacks targeted legacy deployments such as Aztec Connect, which are no longer in active use, and do not equate to an attack on the current Aztec Network mainnet itself. However, the issues exposed by these two incidents are quite alarming for the entire ZK Rollup field.


In one of the incidents, attackers exploited inconsistencies between the number of transactions and the actual processed data, causing the system to record a deposit internally while bypassing the corresponding balance deduction process on L1.


The other incident stemmed from a lack of constraints in the zero-knowledge proof circuit, where the system validated a formally valid proof but failed to ensure that the private state tree used in that proof was entirely consistent with the publicly used state root on Ethereum for settlement. As a result, attackers could generate proofs around a fabricated state tree and extract assets from the L1 contract.


These types of issues are difficult to summarize with the traditional question of whether a contract contains a line of vulnerable code. After all, zero-knowledge proofs can demonstrate that a computational process adheres to established rules, but the prerequisite is that the rules themselves are correct and complete. If developers forget to constrain a critical variable, the proof may still be mathematically valid while demonstrating a result that does not align with the actual settlement state.


The subsequent security incident involving Taiko exposed another type of L2 trust chain risk.


On June 22, the SGX-based proof verification process of Taiko was exploited, resulting in losses of approximately $1.7 million. According to BlockSec's analysis, attackers used a SGX enclave signing private key that had previously been submitted to a public GitHub repository, while also exploiting a flaw in the on-chain verification contract that did not reject DEBUG mode Enclave, allowing malicious provers to register as legitimate instances.


Attackers then forged L2 state proofs, leading Ethereum contracts to accept a non-existent L2 state, ultimately extracting assets from bridging funds. The root cause was that the key used to sign the trusted execution environment was made public, and the remote authentication rules did not thoroughly check the operating environment's attributes, causing a 'certified' proof to lose its originally intended trustworthy meaning.



Meanwhile, Base experienced a halt in mainnet block production from June 25 to 26. In a post-incident review, Base indicated that the two interruptions stemmed from the same block construction logic flaw: a failed transaction did not correctly clear previously recorded states, leading to subsequent transactions being incorrectly calculated for Gas and generating blocks containing invalid state transitions. As other nodes could not accept these blocks, the network ultimately ceased to progress. Base stated that the integrity of the chain was not compromised during the incident, and user funds remained secure.


This was not a case of asset theft or an external attack, but rather a technical failure affecting network availability and recovery capabilities. However, from a broader security perspective, availability itself is also a part of the L2 security model.


For users, whether a chain is secure depends not only on whether hackers can forge assets but also on whether blocks can continue to be produced, cross-chain bridges can function normally, nodes can recover quickly, and whether users still have viable exit paths when the system encounters failures.


Therefore, when using L2, users should not only compare transaction fees and airdrop expectations. For smaller-scale, newly launched, or rapidly evolving L2s, it is advisable to avoid storing large amounts of assets that exceed actual usage needs for extended periods; before cross-chain transactions, users should confirm that they are using the official bridge and understand withdrawal times, pause mechanisms, and emergency exit methods; when encountering network halts, cross-chain anomalies, or official security alerts, users should refrain from repeatedly submitting transactions or continuing to bridge assets.


A more prudent approach is to manage assets of different purposes and risk levels separately, rather than placing all liquidity on the same L2, the same cross-chain bridge, or relying on a single exit mechanism.


3. Contracts May Not Be Breached, but Third-Party Services Can Also Bring Attacks to Users


If the issues with wallets and L2 still occur at relatively lower-level technical components, then the incident involving Polymarket illustrates that even the web front end closest to users can also become an entry point for funds.


On June 25, Polymarket announced that a third-party vendor it used had been compromised, allowing attackers to inject malicious scripts into the Polymarket front end accessed by some users.


According to statistics from security agencies and on-chain analysts, the incident resulted in approximately $3 million in user asset losses, involving about 11 wallets. The stolen funds were subsequently bridged from Polygon to Ethereum and exchanged for approximately 1,893 ETH. However, Polymarket later stated that it had removed the affected dependencies and would fully refund the impacted users.


The key point of this incident is that the domain name users accessed may still be the correct Polymarket domain, and the existing disclosures did not point to vulnerabilities in Polymarket's core smart contracts; the issue primarily lay in the third-party front-end dependencies loaded by the webpage.



This serves as a mirror; nowadays, most Web3 applications do not run entirely on-chain. The webpages users see, such as trading interfaces, still heavily rely on traditional internet infrastructure and third-party software packages. Any one of these dependencies being attacked could allow legitimate websites to display incorrect information to users, replace payment addresses, or induce wallets to sign malicious transactions.


Therefore, 'the URL is real' does not necessarily mean 'all the code being loaded at this moment is secure,' and 'the contract has passed the audit' does not equate to the entire interaction path between users and contracts being risk-free. In the face of such front-end and supply chain attacks, ordinary users find it challenging to independently check every segment of code loaded on the webpage, but they can still mitigate potential losses by reducing the permissions of single interactions:


  • Use a separate DApp interaction wallet: Long-term savings wallets should avoid directly connecting to various DeFi, NFT, prediction markets, and airdrop websites. Daily interaction wallets should only hold funds intended for immediate use, so even if issues arise with the front end or authorization, the impact is relatively limited;
  • Focus on actual operations before signing, rather than just looking at webpage buttons: Just because a webpage says 'Log In,' 'Claim,' or 'Confirm Order' does not mean the signature popping up in the wallet is the same action;
  • Do not rely on inertia to continue operating when the webpage exhibits anomalies: If a page suddenly requests re-importing mnemonic phrases, downloading additional plugins, or displays transaction content inconsistent with the webpage description, users should pause interactions, confirm the situation through multiple official channels of the project, and check or revoke historical authorizations that are no longer in use;

From the perspective of wallet products, this also means that the role of wallets is changing.


They should not merely be tools for storing private keys and popping up signature windows; they also need to help users understand transaction intentions, identify abnormal authorizations, display asset changes, and provide sufficiently clear warnings before high-risk interactions occur.


However, wallets cannot eliminate all risks for users. A more realistic security model is for wallets, protocols, L2s, third-party service providers, and users to collectively reduce the attack surface, rather than shifting all responsibility to any one party.


In Conclusion


In the past, it was often said that whoever holds the private key holds the on-chain assets.


This statement still holds true, but it does not encompass the entire process of user assets from 'generating transaction intentions' to 'completing on-chain settlements.' Today's Web3 security is no longer just about protecting a set of mnemonic phrases; it is about safeguarding the entire path from wallet key generation, transaction display, signature execution, to network verification and final settlement.


Of course, this does not mean that users need to shy away from all on-chain interactions. For users, truly effective security habits mean managing asset purposes, risk levels, and interaction scenarios separately: long-term assets heavily isolated, daily interactions with small amounts, low authorization for unfamiliar DApps, and multiple verifications for high-risk operations.


After all, as security risks expand from a single point to a chain, users' defenses must evolve from merely protecting private keys to adopting a comprehensive set of habits.


Let’s strive together.

You may also like

iconiconiconiconiconiconicon
Customer Support:@weikecs
Business Cooperation:@weikecs
Quant Trading & MM:bd@weex.com
VIP Program:support@weex.com